Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
My point is that, you can get pretty much the same performance out of java and c++, but you need a good java programmer to do that. On the other hand you need a failry good programmer to get a working c++ version at all.
Jeremy Manson brought the performance of Java on par with the original C++ implementation
essentially they say that you need some kind of expert to produce java code that is on par with "straight forward c++". This corresponds somehow to my own experience (java can be fast, if you put in the effort). On the downside, you need some kind of expert to create normal (=good) c++ code in the first place...
BUT: If I was, for any reason, forced to choose a single language to use (i.e. get work done) in the future, it would probably be c++.
Without much effort, I only could only reproduce a speedup of about 1.5% using stl iterators vs. array indexing in a micro benchmark (max element in an int-array). The original scenarios are harder to reproduce in an isolated benchmark. Anyway, it is only measurable on intel core/core2/nehalem cpus. On recent amd cpus there is no difference. My original point was to counter the STL-is-100-times-slower-than-anything-else comments, though.
I had this funny 'aha' moment doing some simple operations on all elements of an int array: using a stl::vector and an iterator is actually faster than a plain-c int-array indexed by the loop-counter. The stl version boils down to pure pointer arithmetics, while the c version has the indexing overhead. Sure you can do the equivalent in c (as fast as an stl iterator, surprise, surprise), but honestly I like to keep away from this kind of stuff, most of the time.