5 ms·
Wouldn't the JIT:ed code be optimized for the specific CPU, whereas the AOT perhaps can not make use of certain instructions? Also, when making a comparison off
by rijoja 7y ago
Wouldn't the JIT:ed code be optimized for the specific CPU, whereas the AOT perhaps can not make use of certain instructions? Also, when making a comparison off the different models one must keep in mind that the software that processes the code have different characteristics.
- mcguire 7y agoThat's what people keep telling me.
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- mdasen 7y agoJIT'd code isn't just about specific CPUs, but about optimizing hot paths. For example, you don't want to inline a commonly used function all over the place, but if there's one area that calls it 10,000 times per second while the others call it once a minute at most, you can re-write the program at runtime having observed that hot code path. To get an intuition for JITs: there are pieces of your code that you know will always be run in a certain way (or mostly run in that way), but it isn't provable at compile time that it will always be that way. JITs can notice that pattern and optimize it (or even provide optimizations for common, but not exclusive paths).
- gdxhyrd 7y agoNote that some compilers do the same at compile time by using profiling information.
- ncmncm 7y agoWhile they could, in principle, do this, does anybody actually do it in production?
- Jimmy123456789 7y agoThey are referring to the HotSpot VM default behaviour. That is how the HotSpot VM works. It's happening right now, while you read this sentence, in millions of production deployments.
- jacques_chester 7y agoYes, if you have Java code that runs for more than a few minutes in production.
- gdxhyrd 7y agoThe difference from one set of instructions to the other is typically irrelevant.
- ncmncm 7y agoOn average. In cases where it is not, and it matters, you probably are not programming it in Java or Go.