-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/29/10 11:37 , Casper Bang wrote: > I'll still claim it's non-deterministic, you can not possibly know > certain aspects of the hardware (word length, branch predictor, > hyper- treading/pipeline-swap support, CAS-support etc.) and > software (which gen an object is in, what will be inlined, which > compacting strategy, where there are safe-points, context-switches > and write-barriers). > > Don't get me wrong, that's the wonder of the JVM/JIT. But > sometimes it would be nice to be able to just rely on AOT > compilation so you'd truly know what you are getting. Btw. I never > really understood why the JVM doesn't just cache an already JIT'ed > memory image which can then just be loaded next time without > verifier and profiler running, especially when running stuff in > client-mode. Let me give my interpretation, as a totally non-expert of JIT. Even if it's deterministic, it is in controlled conditions (the microbenchmark context). In the real world, a lot of different things will happen at the same time, and determinism goes away. Still, I find that the JIT native code dump could be useful for guessing the upper bound, in some cases. I mean, if you have to compute a FFT and are discussing with a C/C++ guy, it would be nice to see the dump. If it's comparable with the C/C++ code, you could tell the C/C++ guys that, at least in optimal cases, there are no big differences (this is already a strong point in a discussion, as still many people completely lacking the JIT culture don't get the point). So, at this point it makes sense a broader-horizon benchmark. If the code is much worse than C/C++, you already know that you'll have a possible performance hit in that section and would probably make sense to evaluate, together with all the other requirements and constraints, to use native code or such. I would run a broader-horizon benchmark all the same, but probably spend less time with it. I mean, I expect that there will be cases in which the code is good and other in which isn't, and that could be an architectural hint. Furthermore, it would be interesting to repeat the same comparison after an upgrade of the runtime, e.g. when they say that there are JIT improvements. Maybe you discover that the code in the optimistic scenario has improved since the past and you can change your mind.
- -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." java.net/blog/fabriziogiudici - www.tidalwave.it/people [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxRUlYACgkQeDweFqgUGxenWwCdF82gU3Z94avvYjmxb0Pnt7Eh MLoAn2qh8IlwU8WvqJtc8aUzx30SnocE =pvdD -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
