C++ the Clear Winner In Google's Language Performance Tests 670
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.'"
Sensationalism at its finest (Score:4, Informative)
RTFA and take a good hard look at what they compared it to: Java, Scala, and Go. This post is a complete non-story.
... and? (Score:4, Informative)
Language shoot-out confirmed (Score:4, Informative)
This jibes with "common sense" and the computer-language shoot-out [debian.org]
It's not useless. It's nice to see multiple studies with different approaches coming to the same conclusions.
Re:C/C++ faster but produces more bugs (Score:4, Informative)
Well when you put it that way, it's not a surprise. C and C++ are different languages with different approaches for effectively achieving low error rates. If you approach them as a single "C/C++" language, you'll end up inheriting the weaknesses of both languages without likewise inheriting the strengths of either.
Re:Common knowledge (Score:5, Informative)
A GC is a net loss, but don't think it doesn't have good effects mixed in there. Allocation of memory is a few instructions with a GC; malloc() can't hope to be in that same league. On a whole, GCs improve the memory locality of your program as it runs, with some substantial hiccups at the collections; manual memory management hinders it as your heap becomes more fragmented.
On a whole I think most programs nowadays should be written in a managed language; the performance gap just doesn't matter for most things.
Re:Common knowledge (Score:3, Informative)
On a whole I think most programs nowadays should be written in a managed language; the performance gap just doesn't matter for most things.
I've been developing professionally (disclaimer: in C++ ;-) ) for 10 years now, I've put up with people saying exactly this for 10 years, and for 10 years it hasn't been generally true at all.
I don't mean to say managed languages have no place - I love using Python for scripting, and we've started doing GUI work in C#/.Net (oh no!) at my company as well, but there's always a dark performance corner where you end up having to go back to a language that gives you more low-level control. The performance gap doesn't matter in "some" things, but it matters at least once in every project I have worked on.
More technically specific:
malloc() can't hope to be in that same league
So you write custom memory allocators for the specific cases that you need that perform better than malloc or indeed the generic allocator of any managed language. Note "allocators" - plural, we have more than one custom allocator for specific cases. I absolutely concur with Google though that this is "at a level of sophistication that would not be available to the average programmer.'"
Re:C/C++ faster but produces more bugs (Score:3, Informative)
Your C# example is BS. What you are referring to is when you want the resource to be cleaned up. C# will clean up the resource, but the question is when. Using the using keyword means an explicit IDisposable interface is called when the object goes out of context. Otherwise it is called when the object is garbage collected.
Re:Common knowledge (Score:5, Informative)
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.
No it isn't, it's just the Boehm GC with half a dozen small patches applied.
Oh, and in a multi-threaded application, free() can be more expensive (in a latency sense) than malloc()
Not really. Recent malloc() implementations use per-thread pools, so free() just returns the memory to the pool (so do most GCs). Multithreading is where you really start to see a big win for GC though. If you're careful with your data structure design, then you can just about use static analysis to work out the lifetime of objects in a single-threaded environment. When you start aliasing them among multiple threads, then it becomes a lot harder. You end up with objects staying around a lot longer than they are actually referenced, just to make sure that they are not freed while one thread still has access to them.
It's also worth noting that most examples of manual memory management outperforming GC are, like most examples of hand-crafted asm outperforming a compiler, are quite small. If you can do whole-program analysis and write special cases for your algorithm, then you can almost certainly outperform general code, whether it's a compiler optimisation or a garbage collector[1]. If you try to do this over an entire program, then you're very lucky - most of us need to deal with libraries, and a lot of us are writing libraries so can't control what the people calling our code will be doing.
As an anecdote, I recently implemented GC support in the GNUstep Objective-C runtime. I tested a few programs with it, and found that memory usage in normal operation dropped by 5-10%, with no noticeable performance change. The code inside the runtime was simplified in a few cases because it now uses the general GC rather than a specialised ad-hoc GC for a few data structures that need to have multiple critical-path readers and occasional writers.
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()
This will cause a serious performance hit on modern malloc() implementations. The memory will be allocated from one thread's pool and then returned to another, meaning that almost every allocation in your 'performance critical' thread is going to require acquiring the global allocation lock. I'd be surprised if code using this pattern scaled to more than 4-8 cores.
[1] Although, interestingly, Hans Boehm's team found that per-object allocator pools that most of the C++ advocates in this thread are suggesting have very poor performance compared to even a relatively simple GC. They tend to result in far more dead memory being kept by the program (reducing overall performance, by making swapping more likely) and, if implemented correctly, required much more synchronisation than a per-thread general allocator in multithreaded code.
Re:I don't know about that (Score:5, Informative)
Talk to Java heads they'll tell you Java is already faster than C++. They can show you some contrived tests to demonstrate this too!
Take a look at the comments on http://jeremymanson.blogspot.com/2011/06/scala-java-shootout.html [blogspot.com] about the paper:
Here's one from the top:
The benchmark did not use Java collections effectively. It was generating millions of unnecessary objects per second, and the runtime was swamped by GC overhead. In addition to the collections-related fixes I made (as described in the paper), the benchmark also used a HashMap when it should have just stored a primitive int in Type; it also used a LinkedList where it should have used an ArrayDeque. In fact, after being pressed on the matter by other Googlers (and seeing the response the C++ version got), I did make these changes to the benchmark, which brought the numbers down by another factor of 2-3x. The mail I sent Robert about it got lost in the shuffle (he's a busy guy), but he later said he would update the web site.
Changes which, I might add, are still far easier for the average Java peon-on-the-street to understand than the C++ equivalents. The fact that the paper was comparing one program in C++ that had been optimized to within an inch of its life with another program, in Java, that had had someone spend about an hour "cleaning it up a little," makes for a grossly unfair comparison.
The fact that the "naive" (far more common) programs were all relatively the same speed was insightful.
Re:I don't know about that (Score:4, Informative)
BTW, a little extra digging reveals that the code was written by a C/C++ compiler writer who's a novice developer in Java/Scala. I'd say that the fact he did so well, comparatively speaking, in Java and Scala would be more noteworthy than the current takeaway.