I wish the whole point was in that sentence: I'd put in my signature.

Screw benchmarks! What does teh internetz say?

Evert on 03/16/2009 2:17 PM
Quote:
double distance = sqrt(dx * dx + dy * dy + dz * dz);
Here's the one I get if I just follow C++ / nbody from the first link.http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=gpp&id=4
Definitely different.

There are currently 3 C++ nbody programs.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=all

Why? Not all algorithms translate well to the languages. You wouldn't use the same algorithm in Haskell that you would in C for example. Not all optimizations would have the same effect too.

I don't think that's a problem. They seem do disallow the graver cheating (no implementing a function in C, and then calling it from a language X and calling that a program in language X). The bigger problem (plaguing most benchmarks) is that their programs are unrealistic and artificial, being small and unflexible. And this point is why it's called a language benchmarks game.

Isaac Gouy, please use the

<quote>
</quote>

tags .

IMO, the main reason why performance-critical applications are still written in C++ is that most of them stem from a codebase from way back when C++ was simply the most advanced language available. Parsing SQL commands, optimizing queries, managing data streams and all that are a major pain to implement, and if you have an existing codebase that solve those problems well enough, you better stick to it rather than re-code the entire thing in a newer language.
About the GC: C# at least allows for manual memory management when needed (using unsafe code), so the argument that GC is what breaks performance isn't entirely valid. In the hands of a skilled programmer, I'm pretty certain that C# can and will produce code that is at least comparable in terms of efficiency. There may even be cases where JIT compilation yields an advantage: the JIT compiler may choose to use optimizations specifically for the system it currently runs on, taking advantages for which a C++ version would have to jump through quite some hoops for(e.g. producing 64 bit code when it runs on a 64 bit CPU, taking advantage of vendor-specific CPU instructions, optimizing for memory usage or cpu clocks based on the system specs, ...).
No matter what application you write, as soon as a certain critical mass in terms of program size is reached, it becomes very likely that memory management needs to be organized in some way; in C++, people usually end up implement either a smart pointer or a garbage collector anyway (or use an existing library), while C# and Java have it built in. (And as stated above, C# at least gives you enough control to bypass it where the extra performance is worth the effort).

Then there's the JIT compilation overhead; but since JIT compilation happens only at load-time, it doesn't affect runtime performance once the application is fully loaded; especially with databases, the startup time is relatively uninteresting (when the server goes down, you're screwed anyway unless you have a failover).

Yet another possibility I expect future applications to use is to split up the codebase into a performance-critical lower layer (written in C++) and a higher level 'user code' layer (written in a more comfortable language). Microsoft makes this fairly easy, although managed C++ (which can be used to glue plain C++ together with other managed code) has very ugly syntax.

I also think that your definition of 'major' (performance critical) doesn't match what the rest of us can agree on (large code base, large user base, large number of features).

At compile time. Which, for C++, is before shipping. Halfway compiled languages perform their final compilation step at run time, which means they can take optimizations based on the specific system they are actually running on, instead of the system they were compiled for.

Let me rephrase then: The fact that C# offers GC, and that C#'s GC is turned on by default, doesn't necessarily break runtime performance. In C#, you are free to mix GC'ed code (a.k.a. 'managed') and manual-allocation code ('unsafe code' in C# lingo), with all the consequences this implies. However, where GC is hard to implement or use in C++ (as you state yourself, it's so hard that most people resort to smart pointers, which are typically faster but have a problem with reference cycles), and manual allocation is relatively 'easy', C# reverses the situation by making manual allocation slightly harder (you need to put relevant code inside an unsafe {} block, and your application needs to acquire permission to run unsafe code), and GC'ed code very easy.

I'm not sure, no. What the VM does at runtime, is basically a secret to me. However, when and if the most basic method (a plain compilation from the IM / bytecodes into the current platform's machine code) is NOT chosen, the only obvious reason I can think of is that whatever they use instead is faster in most cases.

Not necessary, no. Only if the development team chooses to use this option. It would, however, turn a 'major application written in C++' into a 'major application written in C# / Java / ..., with some low-level functions written in C++'. The fact that the Paint.NET team chose to use C# even for low-level functions shows that even things like image processing can be coded in C# efficiently enough to not mandate C++.
As for databases; I think the main reason we haven't seen one written in C# or Java is that in order to succeed at that level, one has to compete with the current major players (MySQL, PostgreSQL, Oracle, SQL Server), all of which have been around longer than C# or Java and tap into a huge code base; and since the rise of C# and Java, there hasn't been any entirely new competitor, in any language. I have no idea how well a Java-based heavy-load database would perform, but to be honest, neither does anyone else, simply because there is no such thing yet.

I didn't say you have to. I just presented it as an alternative to using C++ for everything, so as to draw the benefits from both worlds. This doesn't mean that it is impossible to use C# for everything.

I have never heard of any such thing, except for Microsoft's 'managed C++', which is basically C++ with some syntax extensions for garbage-collected types that compiles into IL instead of machine code.
'As long as compiling C/C++ programs from source takes' is a bit vague - 'Hello world' takes less than a second, but large projects might easily amount to several minutes, maybe even hours, for a full build.