C++ the Clear Winner In Google's Language Performance Tests

Paul Dubuc writes "Google has released a research paper (PDF) that suggests C++ is the best-performing language on the market. It's not for everyone, though. They write, '...it also required the most extensive tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer.'"

C/C++ faster but produces more bugs

[GoodnaGuy]

Yes its true that C/C++ is generally faster than other languages, but when it comes to writing bug proof code, its not so good. Its very easy to write past the end of arrays and use bad pointers amongst other things. From a career point of view, C/C++ is bad. I should know, my main expertise is in it and I am struggling to find a job. There seems to be way more jobs for Java and C# programmers.

Environment, conditions and parameters

[meburke]

Notice one of the comments pointed out that Borland Pascal was one of the fastest executing languages next to ASM. I remember that Borland Pascal (in 19991) executed almost 10 times faster than Borland C++ on a consistent basis on the same systems.

This only points out that tests need to compare apples and apples. I would be quite surprised if any C++ can execute a FFT as fast as my Leahy FORTRAN95.

If I was going to pick only one language to work with, it would probably be LISP, but Haskell comes a very close second. I like code that does exactly what I want it to do with no side effects.

There is much more to comparing languages than is reported in the article, including testing the language's suitability for a given task.

Assembly

[Baby Duck]

If pure speed is the sole criterion with tuning effort having zero consideration, wouldn't masterful Assembly or opcode be the fastest?

Re:C/C++ faster but produces more bugs

[Anonymous Coward]

If you can't figure out how to free memory that you've alloc'd, please stop programming as you suck at it.
I've been a professional programmer for over 20 years and of all the programmers I have worked with only the shitty programmers can't figure it out.

It's just not that hard.

Re:C/C++ faster but produces more bugs

[Anonymous Coward]

Seriously, everybody using heap directly in C++ should reconsider his coding practice. Memory management, automatic or manual, is something that should never be exposed at interface level. And, unlike Java, in C++ you can actually achieve this.

Good code in C++ is simply not using heap, except perhaps for some low-level implementation stuff. If you are concerned about buffer overruns or 'delete' responsibility, you are not using C++ correctly. In my C++ code, I have hardly one new/delete per 10K lines of code (with total codebase maintained about 500K lines)

Re:Common knowledge

[Anonymous Coward]

Things are not so rosy on systems where RAM is scarce and/or there is no swap, as you can watch with the headaches of Android developers. On Android each allocation seems to take a chunk of your soul and the SDK comes with tools that help the programmer detect where they happen so they can avoid them. Most of the time pre-allocating chunks of memory yourself is more efficient than letting Android do it. So tell me, where is the advantage over malloc there?

Re:... and?

[Canberra Bob]

It would have been interesting to a C, C++ and Fortran shootout on some heavy number crunching. Throw in some OpenGL, OpenCL and assembly for good measure. We always get to see how high level languages compare, when in reality for most apps that are written in higher level languages raw speed is one of the lesser factors when choosing a language. Yet we never see shootouts between the lower level languages which would be used if speed truly was a concern.

Re:Common knowledge

[Pseudonym]

Why shouldn't a GC language where the GC has to search through lists regularly instead of you telling the memory management what to clean up by giving it the pointer be faster?

When you're doing serious structure-hackery (as opposed to, say, string-hackery or numeric-hackery) in a non-GC language, you often end up having to structure your code around variable lifetimes, rather than structuring it around the algorithms like you're supposed to. The lack of GC can mean that some algorithms are not viable, and can result in the developer picking a worse algorithm instead. This kind of cost won't easily show up on a profile, but the cost is there, and it's nonzero.

Compiler writers in particular know this, which is why even GCC uses GC. Yes, it's home-built application-specific carefully-applied-and-tuned GC, but it's GC nonetheless. I have a theory that one of the reasons why most languages use GC is that most languages are optimised for writing their own compiler in.

Oh, and in a multi-threaded application, free() can be more expensive (in a latency sense) than malloc(). A well-tuned memory allocator maintains multiple arenas, so it can can allocate memory from whichever one has the lowest thread contention. But deallocating memory requires returning it to the arena from whence it came; you have no choice in this. Some high-performance applications (e.g. database servers) have been known to avoid the latency of free() by handing off critical memory blocks to a dedicated thread which just sits in a loop calling free(). Essentially, it's a GC thread, only it's a manual one.

Don't get me wrong. I don't use Java for pretty much anything (definitely more of a C++-head). But one should never underestimate the cost of manual memory management, or of any other resource for that matter.

Also

[Sycraft-fu]

It often turns out programmers are not as good at the assembly as they might think. I'm not saying a little hand tuned assembly isn't useful for some things but the "I can do better than a compiler," attitude usually has no basis in reality. Good ones are pretty clever at optimizing things. So maybe if you have an area of your code that uses a lot of time (as determined by a profiler, don't think you are good at identifying it yourself) and write a hand tuned in-line assembly version (maybe starting with the assembly the compiler generates). However you don't go and write the whole program in assembly.

C++, of course, is something you can quite easily write a very large program in, or operating system for that matter. Not quite as easy as a fully managed language, but perfectly feasible to deal with large scale and indeed it is what a large number of projects use.

Re:... and?

[TheRaven64]

It would have been interesting to a C, C++ and Fortran shootout on some heavy number crunching

No it wouldn't. For this kind of algorithm, C, C++ and Fortran will generate the same compiler IR and you'll get exactly the same code out of the back end. The difference between compilers will be much greater than the difference between languages. Actually, it is already. For C, C++ and Fortran, EKOPath is 10-200% faster than GCC in real-world tests and synthetic benchmarks. There's more difference between GCC and EKOPath for C than there is between my Smalltalk compiler with Smalltalk and GCC with C, which is why language benchmarks are largely meaningless when you're talking about serial code.

Language benchmarks are important when it comes to parallel code. For example, in Erlang I've written code that scaled up to 64 cores without even trying. In C/C++ I'd have to think very carefully about the design for that. Go is similar: it encourages you to write concurrent code. Idiomatic Go on a 64-processor machine would be a lot faster than idiomatic C++ on the same system, even if the C++ compiler did a lot more aggressive optimisation.

Re:I don't know about that

[mario_grgic]

That's because Java floats are not the same as C floats so compiler can't use the CPU's FPU to do the work for it directly. Java float types make more wider guarantees than C floats (that are usually just restricted to underlying hardware float). This is exactly the reason why Fortran beats C or C++ when it comes to numerical computation. The Fortran compiler can output faster code because language makes some guarantees and it's easier/possible to optimize it better.