3 ms·
If you cache everything, you're just doing AoT compilation. But in general, I would say that the performance advantages of JIT have never really materialized o
by deong 12y ago
If you cache everything, you're just doing AoT compilation.
But in general, I would say that the performance advantages of JIT have never really materialized outside of a few specific types of code. In theory, there should be room for them to appear, but in theory, we're all running Itanium chips. In practice, we haven't been able to write software to take advantage of those theoretical possibilities very well.
Look at it this way -- there are a lot of really smart people working at Google on Android, and despite having a completely working JIT environment and centuries of man-effort to devote to it, they went with a complete rewrite of the runtime in order to gain speed. They wouldn't have done that if there were easier paths to efficiency.
- david87600 12y agoGood Points ... I've been doing Java development for 14 years and it is just plain slower for most things I've done. Sure you can write loop which will optimize correctly but most of the code executes more slowly or suffers from class loading slowness or GC delays. This is why my android phone needs a quad-core 1.5 GHZ processor to feel as fast as an IPhone 4S.
- rockdoe 12y agoIf you cache everything, you're just doing AoT compilation. Not at all. That's a false dichotomy. You can restore the past JIT-ed code from the cache and do new profile directed optimizations. Java JITs already do this, just not (AFAIK!) HotSpot. there are a lot of really smart people working at Google on Android ...and yet their previous runtime was 3 times slower than Sun's one, requiring a full rewrite. Sorry, that's just an appeal to authority, not an argument.
- deong 12y ago"You can restore the past JIT-ed code from the cache and do new profile directed optimizations." Sure, but now you're paying for the compilation/runtime analysis stage more than once. If the JIT compiler is actively doing any profiling of your code, that's time and watts being spent not running the program the user wanted you to run. In order for it to be a net gain, you have to improve the efficiency of the user's program enough through JIT to pay for this repeated cost of doing the analysis however often you do it. You can profile more intensively and more often, thus improving the generated code, but now you need to improve it a lot. Or you can profile lightly or infrequently, but now you have way less information with which to improve it. In practice, it seems to be very hard to do significantly better than just running it through a good compiler once.
- rockdoe 12y agoIn practice, it seems to be very hard to do significantly better than just running it through a good compiler once. Why aren't the other Java runtimes doing it, then?
- deong 12y agoI can only guess, but I'd say it's a combination of factors. First, the JIT on my quad-core i7 can be pretty intense. I'm more willing to pay the overhead than I am on a device that has a tiny battery and gets hot in my pocket. So the JIT on my desktop is going to be better than the one on my phone. Second, Java is mostly a server language these days. The types of programs that run on servers are going to be more amenable to profile-guided optimizations than UI heavy event handling code that constitutes a large part of phone apps. And on desktops and servers, it just doesn't matter that much. Particularly on a server, startup time is pretty much irrelevant. So the downsides to JITs are minimized due to the nature of the workload.
- pjmlp 12y agoThey are though. There are quite a few JVM with AOT compilers available.