7 ms·

If you cache you lose most of the benefits of a jit, might as well AOT one time for everyone.

• rockdoe 12y ago
  Arguments please. The post you are responding to already rebuffs this.
  • SigmundA 12y ago
    See DCKings response. You can reduce startup time of jitting but not eliminate with multistage interpret and background jit with persistent caching and how much complexity and overhead did you add to your runtime and battery power use to get that far? Jitted languages are not known for their performance, they are faster than interpreted ones and slower than the AOT ones generally speaking. So what performance benefit did jit bring compared to a good AOT compiler?
• Twirrim 12y ago
  I'm not sure I understand how. You've gone through the JIT process of live profiling, hot spot detection, compiled down to native code etc. etc., then saved it along the way so that next launch you can start fast with everything already optimised (but also in a position to continue to learn and improve should the opportunity arrive.) Your first run or two will be slower, beyond that you should be as fast as your code will go.
  • deong 12y ago
    What magical extra CPU, memory, cache, and battery have you introduced into that third run to handle the process of "continuing to learn and improve should the opportunity arise"? Because if you're using the same one that's running the user's program, then you won't be running as fast as the code can go. You have to pay for profile guided optimization. That optimizer is another program running on your CPU. It needs memory, time slices, access to secondary storage, etc. It's worth it only if the user code can be improved so much that the total of the two is smaller than what you would have gotten by just compiling it once. And that's not easy to do for general purpose computation.