Hi everyone, Though the people involved in the native code conversation might be interested in this email I recently recieved from Jeff Kesselman. Regards Young. :::::::::::::::::::::::::::::::::::::::::: Young Ly Liquid Edge Games http://www.roboforge.com :::::::::::::::::::::::::::::::::::::::::: >>>FWD OLD EMAIL At 12:12 PM 8/31/00 +1200, you wrote: >We are looking at the possibility of compiling to native code. It's hard >to distinguish between sale hype and actual results when looking at native >java compilers (That is without spending the resources benchmarking our own >program with different compilers). Have you had any experience with java >native code compilers? Are they worth looking into? I should refer you to Chapter 9 of my book :) Pardon me if I drop into lecture mode, but I do talks on this and related subjects fairly regularly. But in a nutshell, no we don't have any real positive experiences with staticcompilers nor do we expect them to have any real performance wins. Remember that Java with a JIT runs native code already-- its just compiled at run time rather then build-time. The fact of the matter is that JITs have a number of advantages over static compilers: (1) More information is available at run-time then build time. As an example if you compile at build time you have to compile for a specific minimal hardware configuration-- typically Pentium multi-processor safe code in the Windows environment. Hotspot looks at what actual processor configuration you are running (P1/P2/P3, single or multi-processor) and compiles code optimized for that envrionment. This is just one of many examples of situations where you have more optimization info available at run-time then build time. (2) In cases of ambiguity, a static compiler must opt for the safest course. A dynamic compilers can "guess" aggressively and then back those optimizations out if they prove wrong. Again, Hotspot today does "aggressive inlining". It will inline calls assuming they only have one target and then abck those inlines out if it turns out multiple pieces of code get called from that point due to polymorphism. Except for a few specific gotchas, like arrray bounds checking, Java today actually compares quite favorably with static C code. You can look at some independent comparison benchmarks at http://www.aceshardware.com/Spades/read.php?article_id=153 The man who wrote that article is an independent software consultant who does not work for any of the Java vendors (us, IBM, etc...) Static compilers may prove to have their use in terms of crunching code for size in embedded applications, as it eliminates the need to drag the compilation mechanism into the run-time environment. Beyond that, I wouldn't recommend them as a sensible optimization path. JK Jeff Kesselman Performance Engineer Sun/Java Software Co-author of Java(tm) Platform Performance ISBN: 0-201-70969-4 =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
