2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>: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.Great.Would it also be possible from the outside to make sista-like optimisations? I'm thinking of a few possibilities such as replacing some dictionary constant building code and a few others (i.e. a kind of [ ] once and the #(( )) of Dolphin) which could be handled at the user level (by tracking if it has to be recompiled if someone, say, changes the implementation of Dictionary).
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. ��Buta) I've yet to see anybody raise JIT latency as an issue in CogHow many instructions you spend on average in Cog per generated instruction?
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.That one is interesting. It sounds like a great benefit would be to have a limited API to the Cog JIT for that sort of requirements.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.I'm not sure of that "real-time" aspect is a good idea. More real-time than others dynamic optimisers, maybe. Note that Java Real-Time suggest turning off JIT and switch to ITC.
The word you're looking for there is AoT Compiler :)
Regards,Thierry