Hacker News Reader

Comment by userbinator | Hacker News Reader

C is the fastest, with C++ approximately the same

There's no C++ features really being used here besides true/false (which basically gets treated as 1 and 0 in most compilers[1]) so there shouldn't be any difference between the two - even the generated code should be identical. The C++ code even uses printf instead of cout, which is one area where I would expect a difference. Thus I'm surprised by the large difference between C and C++ at the low end.

[1] On x86 and other ISAs with flags, booleans can be returned in them, which is an optimisation that I haven't seen compilers do (yet) on x86. It's common on embedded ISAs like 8051 though.

View on HN

Merely including <iostream> results in std::cout/std::cerr/std::cin being constructed on startup even if they're never used (as in this case). This doesn't take very long, but when the actual work being tested takes under a millisecond...

Based on the graph available in the post, the only difference I see between C and C++ performance is on low n. At higher values of n, they have the same performance (as expected). That discrepancy is easily explained by considering start-up time, which C++ could certainly suffer from. Combine that with the consideration that the values for n where the two differ result in a computation time < ~10ms, which is about the range where startup time is going to significantly impact results.

This is also easy to see by looking at the second derivative of the graphs. When n is large enough to outweigh startup time, the graph should be linear. The areas where the second derivative is non-zero indicate that start-up time is affecting results.

You can see that all the languages have some kind of startup time impacting results. Java in particular has the same performance as C/C++ under this test, but has a significantly larger startup time.

Really experiments like this should split the results to explicitly show these two aspects of performance. Measure startup time and measure the time running the actual test code separately. Though that might be more challenging on JIT'd languages.

The differences at the low end of the chart are the startup costs, which get amortised out at the high end.

You could only return bools in the flags for static functions that don't have their address taken, because this would break the established API. It'd also generally only be useful if the function result is immediately used in a test.

The difference between C and C++ might have to do with that: http://www.cplusplus.com/reference/ios/ios_base/sync_with_st...

Probably some library initializaion takes enough time to affect the results. I wonder what is taking time in this case.

I'm pretty sure I remember Delphi using the carry flag to return boolean values.

Reply on news.ycombinator.com