Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment: Re:Java is fast (Score 1) 670

by sim82 (#36449278) Attached to: C++ the Clear Winner In Google's Language Performance Tests
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

by sim82 (#36447618) Attached to: C++ the Clear Winner In Google's Language Performance Tests

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

by sim82 (#36447182) Attached to: C++ the Clear Winner In Google's Language Performance Tests
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

by sim82 (#32507058) Attached to: GCC Moving To Use C++ Instead of C
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

by sim82 (#32493500) Attached to: GCC Moving To Use C++ Instead of C
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

by sim82 (#32421190) Attached to: GCC Moving To Use C++ Instead of C
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.

The meta-Turing test counts a thing as intelligent if it seeks to devise and apply Turing tests to objects of its own creation. -- Lew Mammel, Jr.

Working...