Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Java is fast (Score 1) 670

sorry, read my post (and the paper) again: "original c++" > "original java". After expert improvements (Jeremy Manson): "original c++" == "improved java" (see my orignal quote). I am assuming here that by "original C++ implementation" the article refers to the c++ version without any tuning (mainly no hash_set, which is not official standard, yet).
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.

Comment Re:Java is fast (Score 2) 670

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...

Comment Re:... and? (Score 1) 670

It is relevant, because Java (especially the SUN hotspot VM, so this includes scala) must have been the most ambitioned attempt to create a fully hw-independent, garbage collected and jit-ed "language platform" ever. Java is the best representative for any comparison of "non-native" vs. "native". Still, contrary to what has been claimed, in most cases you can only achieve "sub-native" performance (especially when you consider that the java vm, by design, makes it impossible to directly exploit stuff like SSE, which can have a huge impact).

Comment Re:Maybe they've grown up a bit (Score 1) 546

yes, it is much better to make things clear to other programmers (which most of the time also helps the compiler find potential errors better).
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.

Comment Re:Maybe they've grown up a bit (Score 1) 546

yes, that seems to be the common knowledge and i am still avoiding pointer arithmetics where possible (recently i like stl iterators though, as a way to give the compiler (and other humans) as much information as possible about the real intention of the code). And still, replacing the array indexing got me speedups >5% for inner-loop stuff on gcc, on more than one occasion (i don't remember the details using icc).

Comment Re:Maybe they've grown up a bit (Score 3, Interesting) 546

how true
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.

Comment Re:surprise surprise (Score 2, Insightful) 327

well, now that he knows which chemicals to use and which wires to tap, it should take considerably less than 6 months to do it again. Basically the security of this tpm seems to be mainly based on obscurity (in this case complicated hardware).

Slashdot Top Deals

Nothing succeeds like excess. -- Oscar Wilde