Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Google Programming Technology

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.'"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Common knowledge (Score:5, Insightful)

    by PitaBred ( 632671 ) <slashdot&pitabred,dyndns,org> on Wednesday June 15, 2011 @02:05AM (#36446386) Homepage

    I thought this was common knowledge. Did anyone ever doubt that?

  • by AuMatar ( 183847 ) on Wednesday June 15, 2011 @02:11AM (#36446422)

    There's a lot of Java-ites who claim that Java is just as fast. They're idiots, but they're vocal.

  • by Erbo ( 384 ) <amygalert@nOsPaM.gmail.com> on Wednesday June 15, 2011 @02:28AM (#36446520) Homepage Journal
    And, while C++ will always necessarily be faster to execute, there's no question that the other three languages will be faster and more straightforward to develop in. (Which, in general, makes them a net win, as programmer time is almost always more expensive than computer time, except in certain corner cases which should be obvious.)

    Why? Three words: Automatic memory management.

    No more worrying about whether you've allocated the right buffer size for your data...and maybe allocated too little resulting in an overrun screw, or allocated too much and wasted the memory. And no more forgetting to free that memory afterwards, resulting in a memory leak. You can write expressions like "f(g(x))" without having to worry about how the return value from "g" is going to be freed, allowing a more "natural" coding style for compound expressions.

    I maintain that automatic memory management, while not great for code-execution performance, is probably the single biggest boon to developer productivity since the full screen-mode text editor. (Not saying "emacs" or "vi" here. Take your pick.)

    Granted: You can retrofit a garbage-collecting memory manager onto C++...but that code will rob your C++ code of some of that enhanced execution performance which is probably the reason why you chose to develop in C++ in the first place.

  • Java is fast (Score:5, Insightful)

    by wurp ( 51446 ) on Wednesday June 15, 2011 @02:41AM (#36446590) Homepage

    In some situations Java will be faster than unoptimized C++ - JIT compilation will do enough of a better job than vanilla C++ to make the difference. In general, C++ will clearly be faster. However, I think what most of the people you're qualifying as idiots get up in arms about (rightly) is the assumption that so many programmers seem to make that Java will be many times slower than C++. That's (usually) just wrong.

    In particular, here's what Google's analysis had to say about it on page 9:

    Jeremy Manson brought the performance of Java on par with the original C++ implementation

    They go further to say that they deliberately chose not to optimize the Java further, but several of the other C++ optimizations would have applied to Java.

    For most programming tasks, use the language that produces testable, maintainable code, and which is a good fit for the kind of problem you're solving. If it performs badly (unlikely on modern machines), profile it and optimize the critical sections. If you have to, write the most critical sections in C or assembly.

    If you're choosing the language to write your app based on how it performs, you are likely the one making bad technical decisions.

  • by Anonymous Coward on Wednesday June 15, 2011 @02:49AM (#36446666)

    ... most people are doing it wrong.

    Good use of C++ fills a very small niche of people that want a relatively high-level language but care about a statement like "the compiler generates good code for this"... You want some of the properties of C, like being close to the hardware and generating straightforward machine code. Add to that some things that make OO easier. Add type safety. Add templates and function objects, which due to inlining gives you much better machine code than the typical C approach of a function pointer and a void* to provide such extensibility. What you have is kind of like "a better C". It has a lot of quirks and baggage, but with the proper understanding of the good and the bad it's really good for the sort of niche where these choices make sense.

    The problem I have encountered is that bad C++ programmers are a dime a dozen. I don't think I've ever had any co-workers who would understand my previous paragraph. I know from reading books and papers and Internet that people who "get" C++ exist. The best I can say is that the vast majority of people using a C++ compiler don't know what they are doing. Instead I've met a lot of people writing C++ code who probably should be writing in Java anyway; they discard most of what C++ is good for, usually because they don't really understand it and they're trying to write Java-ish code in C++. The results aren't pretty.

    In a way I agree with what Linus said in one of his famous emails, where some silly person was suggesting to rewrite git in C++. To paraphrase: Choosing C as a language is good even if the only thing it accomplishes is it keeps out the bad C++ programmers.

    I guess the silver lining is that no two people can agree on what "good" C++ is. So maybe I'm just being too harsh in my assessment.

  • Re:Java is fast (Score:5, Insightful)

    by Splab ( 574204 ) on Wednesday June 15, 2011 @02:51AM (#36446680)

    For me it doesn't matter which language is faster, I'm using the one that solves my problem the fastest (e.g. shippable product fastest) and right now, Java is the main player for me.

    Also, since our CPUs aren't getting any faster, we need to use languages that makes threading easier the safest way and on that topic, Java is miles ahead of C++. (Java used to have an utterly broken threading model, but these days it works [tm]).

  • by Vintermann ( 400722 ) on Wednesday June 15, 2011 @03:20AM (#36446818) Homepage

    So, you never have any memory leaks? Or double frees? Convenient for you that you're an anonymous coward, because it would probably be a quick issue to call you on. I've met some extremely careful coders (among other things, the developer of one of the first projects to reach zero defects in Coverity's open source scan effort), and none of them make such ridiculous statements.

  • by martin-boundary ( 547041 ) on Wednesday June 15, 2011 @03:27AM (#36446864)
    It's reasonable to doubt that C++ is faster than ASM, and it's reasonable to doubt that C++ is faster than C. And if we're talking about hand tuned numerical libraries, it's reasonable to doubt that C++ is faster than FORTRAN.
  • by antifoidulus ( 807088 ) on Wednesday June 15, 2011 @03:56AM (#36447032) Homepage Journal
    There is no such thing as a real "computer language speed test", this is really a test of compilers, environments, VMs/interpreters, and environments. The first question that has to be raised is of course when the program is running on hardware, what "language" is it written in? The hardware sure doesn't give a shit. You can compile almost any language into native code, including VM driven languages such as Java and PERL. Now granted TFA states that they ran their loop 15k times to try to minimize the effect of the load time and run as much JIT compiled code as possible, but that's still not the same as compiling it directly into native code.

    Which brings up another point, are they really testing the "programming language"(which is just a bunch of specification and usually implementation hints) or are they testing the compiler/environment they are on. Code compiled with GCC and ran on a Linux box will probably perform differently than code compiled with Microsoft's compiler running on Windows which will behave differently than code compiled with LLVM/CLanger running on OS X...... You can probably say the same thing about Java compilers, I'm assuming they used the Oracle reference javac, but there are other Java compilers out there. How do you test the speed of the "language" when so much of that performance depends on the compiler and environment you are running other?

    Which leads into my final point, when does a language stop becoming something written in that language? Although not tested this time, probably the best example of this point is Ada. Anyone who has coded in Ada knows how insanely strict it can be, it constantly does things like bounds checking to ensure that data stored in subtypes is within the bounds of those types. However on most Ada compilers most of these checks can be disabled with just a couple compiler flags. Obviously the resulting code is going to be faster than if you kept the checks in, but does it stop becoming Ada at that point? You can make a similar case for Java and JNI. JNI is completely legal in the Java language specification, but when you use JNI does your program stop being a Java program? Could you have optimized it further by using JNI?

    This is merely a test of whatever compilers/VMs they used in whatever environment they ran the code in, nothing more, nothing less.
  • by Unoriginal_Nickname ( 1248894 ) on Wednesday June 15, 2011 @04:39AM (#36447228)

    Boost/0x shared_ptr can't handle circular references.

    That's why people focus on memory management when they talk about C++: it's filled with 'gotchas' that will completely fuck you up if you don't completely understand everything you are doing. That's why so many C++ 'fans' hate automatic memory management. It's not because they're attached to the idea of manual memory management, it's because C++ forces you into a culture of paranoia and it's difficult to adjust to a world where the standard library isn't out to kill you.

  • by serviscope_minor ( 664417 ) on Wednesday June 15, 2011 @09:33AM (#36449412) Journal

    It's really painful to write C/C++ code

    That's because if you treat C and C++ as one language, then you suck as a C++ programmer.

I've noticed several design suggestions in your code.

Working...