SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : All About Sun Microsystems
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Scott McPeely who wrote (8463)3/22/1998 10:13:00 PM
From: Scott McPeely  Read Replies (1) of 64865
 
From rec.games.programmer:

*********************************************************************
>In the February issue of JavaWorld there was an article that
>measured the speed of applications written in C++ and
>compiled to native x86-code versus a Java version of the
>same applications running java bytecode on an (generally
>available) optimized JIT (Just In Time) Compiling Java VM.

Yes. Seen it, debunked it. It's bullshit.

>The results were that the java applications were on every
>test 0-5% slower and on one test more than 50% faster
>than equivalent programs written in C++.

And what were those tests? That's right, looped
integer division. IDIV is one of the slowest instructions
on x86, taking 42 clocks. It doesn't pair noticably.

Even with a decode step to run raw bytecode (ie: no JIT),
the IDIV *still* dominates the timings (about 2/3 of
execution time, I reckon, in that case).

Pairing, stalls and flow dependencies account for a 3x
speedup going from naive (each C instruction becomes a
pre-defined chunk of asm) debug code to an optimised
build. Guess which category these JIT VMs' code falls
into...

>Nturally the figures depends on how the programs were
>written, but the specifications were fairly detailed and
>ranged from looping floating-point divisions to
>up/down-casting of classes in certain circumstances.

No, that's the entire range. It was integer divides and
down-casting. That's it.

(BTW - they're wrong about why RTTI isn't used. It's not that
it's too slow, it's that 99%+ of the time the types can be
determined at compile time)

>The reason for Java's suprising speed is that

the article is complete bullshit.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  

HomeMailHotSubjectMarksPeopleMarksKeepersSettings
Terms Of UseContact UsCopyright/IP PolicyPrivacy PolicyAbout UsFAQAdvertise on SI
© 2025 Knight Sac Media.  Data provided by Twelve Data, Alpha Vantage, and CityFALCON News