Don't forget c++0x and the Chevy volt!

they actually needed to do a study?

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.

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

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

the firefox team already divided it by infinity five years ago

*warning: false dilemma ahead*
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++.

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.

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

don't forget that "printf("0x%08x\n", x);" is still completely valid c++ code. The fact that some people prefer iostreams is no reason eveyone should use them (c++ is not pre 1.5 java!).

IMHO no one should use c++ exceptions before reading and understanding at least some parts of GOTW.ca or the nicer version in Herb Sutters's 'exceptional 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.

you are right. The original author must have confused them with SUN.

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

It's good to know that Jack Bauer is out there to protect us! (uuhmm, wait...)