Ah! �But! �Sista has an advantage that other adaptive optimizers don't. �Because it optimizes from bytecode to bytecode it can be used during a training phase and then switched off.

Real time applications requires an upper bound guarantee in their response time. In some cases, the lack of this guarantee can be just an annoyance, as happens in video games. In some mission critical applications the results can not be good, if this time constraint is not met. An example of a mission critical system could the flight controls of an airplane, or the cooling system of a nuclear reactor.

For these application, it is not possible to rely in an adaptive optimizer that can be triggered sometimes. In these application you have to either:

- Extend the language to hand optimize some performance critical sections of code.

- Use another language to optimize these critical section.

- Use another language for the whole project.

The additional option is to "train" the optimizer by running the application before deploying and capturing the optimised methods. �Discuss this with Cl�ment and he'll explain how straight-forward it should be. �This still leaves the latency in the Cogit when it compiles from bytecode to machine code. �But

a) I've yet to see anybody raise JIT latency as an issue in Cog

b) it would be easy to extend the VM to cause the Cogit to precompile specified methods. �We could easily provide a "lock-down" facility that would prevent Cog from discarding specific machine code methods.

And of course, you have to perform lot of profiling.

Early and often :-).

Because we can have complete control over the optimizer, and because Sista is byetcode-to-bytecode and can hence store its results in the image in the form of optimized methods, I believe that Sista is well-positioned for real-time since it can be used before deployment. �In fact we should emphasise this in the papers we write on Sista.