Re: General byte-codes reference

midkiff@watson.ibm.com (Sam Midkiff)
21 Dec 2000 14:55:46 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: General byte-codes reference anton@mips.complang.tuwien.ac.at (2000-12-11)
Re: General byte-codes reference midkiff@watson.ibm.com (2000-12-11)
Re: General byte-codes reference Norman_member@newsguy.com (Norman Culver) (2000-12-18)
Re: General byte-codes reference brangdon@cix.compulink.co.uk (2000-12-18)
Re: General byte-codes reference patc@acm.org (Pat Caudill) (2000-12-18)
Re: General byte-codes reference sjmeyer@www.tdl.com (2000-12-20)
Re: General byte-codes reference midkiff@watson.ibm.com (2000-12-21)
Re: General byte-codes reference anton@mips.complang.tuwien.ac.at (2000-12-31)
| List of all articles for this month |

From: midkiff@watson.ibm.com (Sam Midkiff)
Newsgroups: comp.compilers
Date: 21 Dec 2000 14:55:46 -0500
Organization: AT&T Worldnet
References: 00-12-030 00-12-073 00-12-095
Keywords: Java, interpreter, performance
Posted-Date: 21 Dec 2000 14:55:46 EST

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.



Post a followup to this message

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