Re: General byte-codes reference

A project I was on full time last year (www.research.ibm.com/ninja)
showed that "Java" could reach 85-101% of Fortran performance on
numerical programs written in Java where reals were the primary data
type, and approximately 65-90% on programs using complex numbers. See
the '99 JavaGrande projeceeding, the (I think) Mar. 2000 TOPLAS (From
Flop to MegaFlops: Java for Technical Computing, Moreira, Midkiff and
Gupta), and the 2000 ACM Int. Conf. on Supercomputing. All 3 should
be in the ACM Digital library.


I put Java in quotes for two reasons. First, we used the PowerPC fma
instruction, which doubles the peak performance of our target
machines. Currently this is not legal in Java, but there is a JSR
moving forward to (it is hoped) make it legal. In any case, this is a
Java specific issue, not an interpreted vs. compiled issue. Second,
our base compiler was a static compiler, and so we didn't count the
cost of the compilation in the run-time. Our work on quasi-static
compilation (see Quicksilver:A Quasi-static compiler for Java,
Serrano, Bordawekar, Midkiff and Gupta, OOPSLA '2000 for details)
shows that with the right compilation model this isn't too
far-fetched, and that a form of static compilation of Java is possible
that fully respects Java semantics.


Sam Midkiff


On 20 Dec 2000 17:24:02 -0500, sjmeyer@www.tdl.com (Steve Meyer)
wrote:
>This might be slightly off topic but nearly all compiler writing area
>conference proceedings are filled with papers on better and "faster"
>"methods" for virtual machine (aka byte code) optimization. However,
>as I read the papers, performance comparison is always against "slow"
>current Java interpreted performance not against same program written
>or compiled into C where academic optimizations would would be so
>small it would not be visable on bar charts.

Return to the comp.compilers page.
Search the comp.compilers archives again.