Linked by Christopher W. Cowell-Shah on Thu 8th Jan 2004 19:33 UTC
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
More News »
Sponsored Links



So, Rayiner has is right. These benchmarks are mostly testing parts of the operating system, not necessarly the runtimes all that much. That's why the I/O scores are all so close. The only anomaly here is that Java is probably using strict IEEE arithmetic for the trig stuff, which is why it's so slow. I think another poster mentioned how to turn that off.
It's these kinds of benchmarks that I get nervous about when people start saying "Java is just as fast as C." Well, I'm a Java programmer, and I love the language, and it really has gotten a LOT faster over the last few years, but there are some things in Java that are just inherently difficult to optimize away. I'm talking about things like array bounds checking, every data structure being a reference to an object, GC, and all data types being signed (try working a lot with byte values in Java and see how much ANDing you end up doing to combat sign extension issues). These structural choices in the language design cause extra overhead that C programs just don't suffer. Now, those are also some of Java's greatest strengths in terms of making programming safer, but they do have a price. Fancy VMs can reduce that price, sometimes to zero for certain sections of code (the latest Hotspot does an excellent job getting rid of array bounds checking in many instances), but it's asymtotic.
Now, here's what I think: for most types of programs, C or Java are just fine, particularly given today's fast CPUs and spacious memory supplies. Both of those favor Java and tend to make the difference small for anything real-world. Even the purely interpreted languages like Perl or Python are fine for all but the heaviest workloads.