For something to call itself Java it needs to be licensed from Oracle which confirms that implementation meets the requirements.

There is no such thing in C++ or C.

While there is no such body which owns the C++ language such as Oracle does (well, it supposedly doesn't, but as long as it controls the language certification unit tests (which it isn't supposed to but does anyways, just like sun did) then this licensing will be required) the standard does dictate that a conforming non-standalone implementation of the C++ language provide the standard library (which takes up about half of the standard text).

I think the OP and the consequent answers show a very important lesson: C++ can be made to run as fast / faster than other languages but you have to learn its intricacies first.

The other lesson we learned was that buffering is important, no matter the language

[quote name='Fiddler' timestamp='1297968142' post='4775509']
I think the OP and the consequent answers show a very important lesson: C++ can be made to run as fast / faster than other languages but you have to learn its intricacies first.

The other lesson we learned was that buffering is important, no matter the language
[/quote]
Except for French because the input doesn't matter as the return is always hate.

/french burn

[quote name='Antheus' timestamp='1297883077' post='4775063']
For something to call itself Java it needs to be licensed from Oracle which confirms that implementation meets the requirements.

There is no such thing in C++ or C.

While there is no such body which owns the C++ language such as Oracle does (well, it supposedly doesn't, but as long as it controls the language certification unit tests (which it isn't supposed to but does anyways, just like sun did) then this licensing will be required) the standard does dictate that a conforming non-standalone implementation of the C++ language provide the standard library (which takes up about half of the standard text).
[/quote]

Then again, noone interprets the C++ standard in quite the same way, so this is mostly a moot point anyway.

I would be interested to see software image manipulations algorithm implemented in C++ and Java and see how they perform side by side. I was meant to do this for a while now, but never got around to it.

For the record, the Java version ran in 5.5s on my machine, and the C++ and the C99 versions both ran in 5.3s.

When stdout is redirected to /dev/null, the Java version clocks in at 0.069s, the C++ version at 0.014s, and the C99 version at 0.020. I assume the larger difference is due to the expense of the JVM startup, which is generally amortized in real world applications and is hidden by the terminal buffering in the non-redirected runs. The C++ version is slightly faster because it does not have the runtime interpreter required by printf in the tight loop, just what amounts to a [font="Courier New"]memcpy[/font].

I am using GCC 4.5.2 for C and C++ and OpenJDK 6 for Java on an Intel i5-540 (2.53 GHz 64-bit quadcore) running Ubuntu 11.04 alpha 3.

For the record, the Java version ran in 5.5s on my machine, and the C++ and the C99 versions both ran in 5.3s.

When stdout is redirected to /dev/null, the Java version clocks in at 0.069s, the C++ version at 0.014s, and the C99 version at 0.020. I assume the larger difference is due to the expense of the JVM startup, which is generally amortized in real world applications and is hidden by the terminal buffering in the non-redirected runs. The C++ version is slightly faster because it does not have the runtime interpreter required by printf in the tight loop, just what amounts to a [font="Courier New"]memcpy[/font].

Java strings use char internally, which are 16-bit. The C++ version uses string, which are 8-bit. Shouldn't matter all that much, but might either require twice as much work for memcpy or perhaps even some codepage conversion when dumping to console.

For the original console output example, the most important question is: What terminal application received the output of those programs? In my experience, when running programs with tons of console output, the performance bottleneck is often not the program itself, but the terminal emulator. Many terminal emulators suck at processing large amounts of output.

On Linux, for example, gnome-terminal used to be notoriously slow, and only got a little better over time. Konsole has always been very fast in my experience. Similarly, some IDEs have horribly slow output window implementations.

You may have ended up benchmarking your IDE your terminal emulator instead of your program.

There are a few mishaps that happen when beginners try to benchmark things. Often they don't turn on release mode since debug mode has a lot of checks to assist the programmer.

I'd like to point out that if you're using Visual Studio you need to run the executable without the debugger attached as well as turning on release mode, that is CTRL+F5 instead of just F5. Otherwise the results will not be representative. In my application the difference can be an order of magnitude or more.

Also what simple benchmarks like this usually fails to capture is how the language features can change the implementation of an algorithm, leading to vastly different performance characteristics compared to a "straight port". For example using list comprehension etc vs an explicit for loop in Python, or template metaprogramming in C++, like in this example. These things will matter when writing a full-blown application in that language.