Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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 -- Ignore unavailable to you. Want to Upgrade?

To: Scott McPeely who wrote (8463)	3/22/1998 10:13:00 PM
From: Scott McPeely	Read Replies (1) \| Respond to 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.