Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted more than 3 years ago | from the meep-meep dept.

Google 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.'"

cancel ×

670 comments

Sorry! There are no comments related to the filter you selected.

Common knowledge (4, Insightful)

PitaBred (632671) | more than 3 years ago | (#36446386)

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

Re:Common knowledge (5, Funny)

Anonymous Coward | more than 3 years ago | (#36446412)

It's been common knowledge for at least a decade that Java is 6 months away from being quicker than c++.

Re:Common knowledge (2)

rvw (755107) | more than 3 years ago | (#36446838)

It's been common knowledge for at least a decade that Java is 6 months away from being quicker than c++.

Just wait for Java++! Oh wait...

Re:Common knowledge (5, Insightful)

AuMatar (183847) | more than 3 years ago | (#36446422)

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

Re:Common knowledge (1)

drolli (522659) | more than 3 years ago | (#36446478)

Oh yes. 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?

The magic of the buzzwords creates a reality distortion field around the code.

(I like java, but i know how to profile code.).

Re:Common knowledge (5, Informative)

EvanED (569694) | more than 3 years ago | (#36446568)

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 (2, Interesting)

Anonymous Coward | more than 3 years ago | (#36446642)

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:Common knowledge (3, Funny)

EvanED (569694) | more than 3 years ago | (#36446676)

Just for future reference, not everything I say is necessarily applicable in every situation. For instance, Java does not run very fast at all on my abacus. It would also be possible to craft some programs where the Java version would exhibit pathologically bad behavior and/or the C++ version would behave particularly well, and the consequences of GCs moving things around wouldn't be a big deal.

Re:Common knowledge (3, Informative)

MadKeithV (102058) | more than 3 years ago | (#36446684)

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:Common knowledge (1)

drolli (522659) | more than 3 years ago | (#36446708)

Yes i also prefer gc languages, but the task in the article was very specific.

I would even say that if you have such a very specific task, you write (or custiomize) your own malloc (not unusual when doing numerics) to prevent thing like heap fragmentation. (on the other hand, one could write a specific gc...)

Re:Common knowledge (0)

Anonymous Coward | more than 3 years ago | (#36446802)

I really think GCs are overrated. Honestly, in C++ you don't even deal with memory management that often. And if you do, it's encapsulated in an object. You're also able to allocate on the stack a lot more in C++ than in, say, C; and with things like scoped_ptr, shared_ptr, etc, the memory management really becomes trivial. Not to mention the fact that your code will run with predictable response times, unlike long-running Java code when the GC sweep kicks in.

There are many other aspects of C++ that are far more painful than memory management, so I'm not sure why the focus always seems to lie there.

Java is fast (4, Insightful)

wurp (51446) | more than 3 years ago | (#36446590)

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.

Re:Java is fast (4, Insightful)

Splab (574204) | more than 3 years ago | (#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]).

Re:Java is fast (0)

Anonymous Coward | more than 3 years ago | (#36446742)

Yes, you are right, Java will only be slower 99% of the time. If someone says 100% he is an idiot.

Re:Java is fast (1)

wurp (51446) | more than 3 years ago | (#36446770)

Usually slower, yes. Enough slower to make you turn your nose up? You're just being precious.

Re:Common knowledge (0)

Anonymous Coward | more than 3 years ago | (#36446692)

I develop almost all of my scientific simulation software using Java but I feel sick when someone claims Java is/can be as fast as C/C++.

Java is used for simplicity and ease of development not because of its speed. If you need speed, C++/C (well developed code and algorithms of course) is the way, at least with existing options.

I have done many experiments to confirm that (all versions of java) and I won't continue to do hat forever.

Re:Common knowledge (1)

essayservices (2242884) | more than 3 years ago | (#36446544)

you'll get more about languages from uk [goo.gl] .

Re:Common knowledge (2)

Rookitown (1489425) | more than 3 years ago | (#36446660)

This paper was created with the sole purpose of getting accepted for an up coming Scala conference. Also, copied from my post on OSnews:

This paper has some pretty serious issues as has been discussed extensively https://groups.google.com/forum/#!topic/golang-nuts/G8L4af-Q9WE [google.com] and http://www.reddit.com/r/programming/comments/hqkwk/google_paper_com [reddit.com] ...
For instance nearly all the optimization for the C++ code could have been applied to the Java code. Also according to Ian Lance Taylor:

Despite the name, the "Go Pro" code was never intended to be an example of idiomatic or efficient Go. Robert asked me to take a look at his code and I hacked on it for an hour to make a little bit nicer. If I had realized that he was going to publish it externally I would have put a lot more time into making it nicer.

I'm told that the program as compiled by 6g is significantly faster now than it was when Robert did his measurements.

So yeah, in general a fairly floored benchmark, see the threads I linked for more details. I'm sure there's equivalent Java and Scala biased threads floating around as well!

Re:Common knowledge (1)

rottenSoul (900240) | more than 3 years ago | (#36446664)

google are fairly unique in having a single feature to polish over many years. Most of us in the dev world dont have the luxury of time to polish usecs from a call.

Re:Common knowledge (1)

beelsebob (529313) | more than 3 years ago | (#36446758)

More importantly... Did anyone ever care about that? I spend my days writing computer game engines, and I don't remember the last time I worried about the performance of a language.

Sensationalism at its finest (4, Informative)

Toksyuryel (1641337) | more than 3 years ago | (#36446400)

RTFA and take a good hard look at what they compared it to: Java, Scala, and Go. This post is a complete non-story.

Garbage collection (1)

MrEricSir (398214) | more than 3 years ago | (#36446426)

FTA: "All languages but C++ are garbage collected, where Scala and Java share the same garbage collector."

That's got to play a factor here.

Re:Garbage collection (1)

Toksyuryel (1641337) | more than 3 years ago | (#36446480)

Because clearly C is garbage collected. It all makes sense now.

Re:Garbage collection (1)

MrEricSir (398214) | more than 3 years ago | (#36446588)

Because clearly you need to re-read this thread. It will all make sense then.

Re:Garbage collection (0)

Anonymous Coward | more than 3 years ago | (#36446644)

C isn't even a factor in the type of development they do. Why compare to a language that's only relevant in a few specific fields?

C++ hardly fits Google as it is. Their style guide is an unholy abomination (albeit probably a necessary one for a corp of that size). Not surprising that they're looking into more modern languages.

Re:Garbage collection (1)

jd (1658) | more than 3 years ago | (#36446766)

I'm sure there's a malloc replacement library out there that does GC. :)

Re:Sensationalism at its finest (-1)

Anonymous Coward | more than 3 years ago | (#36446430)

You're jumping to conclusions, unless you've already seen the accompanying video [youtube.com] .

Re:Sensationalism at its finest (1)

Anonymous Coward | more than 3 years ago | (#36446448)

rick-roll.

Re:Sensationalism at its finest (1)

Tablizer (95088) | more than 3 years ago | (#36446440)

I thought Pascal should be included, and I bet it would make a pretty good showing.

Re:Sensationalism at its finest (0)

Anonymous Coward | more than 3 years ago | (#36446502)

Assuming the program was written similarly, the speed would be very close to the same. If it did a lot of fancy pointer stuff that is difficult to do in Pascal, C might end up faster. If you did a lot of string manipulation, pascal would come out a lot faster. (because, for example, it knows the length of strings without having to crawl them looking for null bytes and such).

Re:Sensationalism at its finest (0)

Anonymous Coward | more than 3 years ago | (#36446540)

eventually the cpu has to do this.. I don't see how any language could get around it. searching through strings is a necessary evil.

Re:Sensationalism at its finest (0)

Anonymous Coward | more than 3 years ago | (#36446582)

Pascal strings are prefixed with the string length instead of being null-terminated, so looking up the length is O(1).

Re:Sensationalism at its finest (0)

Anonymous Coward | more than 3 years ago | (#36446606)

Every know and then yes. But you can cache the length in an object variable ... like ... pascal ...

Re:Sensationalism at its finest (1)

mikael_j (106439) | more than 3 years ago | (#36446610)

Well, without speaking specifically about Pascal and C/C++ there is the simple matter of how the strings are dealt with. While with one language creating a string and storing it in memory may very well mean that the program just allocates enough memory and dumps the string there with another language the string stored in memory might come with some form of metadata/properties, so rather than having n bytes allocated to your string and being forced to scan through it looking for the null byte you know that, as a hypothetical example, the first eight bytes of memory allocated for the string are a 64 bit number that gives the exact length of the string. Of course, it all depends on what the program is doing with the data.

Re:Sensationalism at its finest (2)

EvanED (569694) | more than 3 years ago | (#36446602)

If you did a lot of string manipulation, pascal would come out a lot faster. (because, for example, it knows the length of strings without having to crawl them looking for null bytes and such).

I like Pascal strings as much as the next guy and think it's rather better than the C model, but it's not like you can't track lengths yourself and eliminate that performance difference.

BTW, one subtle difference between C and C++ is in templates. Templates can reveal a lot more information to the compiler. The classic example here (which is probably an unusual case, but whatever) is std::sort in vs qsort from stdlib.h; std::sort typically blows qsort out of the water because it can do way more inlining.

Re:Sensationalism at its finest (1)

AHuxley (892839) | more than 3 years ago | (#36446832)

Ada too :)

Re:Sensationalism at its finest (1)

jd (1658) | more than 3 years ago | (#36446760)

I agree. The article is nonsense. Whilst one of the comments suggested comparing it to assembly, that's perhaps a bit unfair. However, to be a test of "languages on the market" I would have expected the following to be there for certain:

  • C99
  • D (Digital Mars' language)
  • Fortran 2008
  • Erlang
  • Forth

Now, if you want to consider "the best", then you'd also want to include a few of the more experimental languages:

  • Occam-Pi
  • Unified Parallel C
  • AspeCt-oriented C
  • NESL

The problem with selecting benchmarks is that it's easy to pick languages your favourite language will do better at. The challange is to use a wide enough range of methodologies that you cannot predict ahead of time which one will do best at what.

More languages. (1)

miffo.swe (547642) | more than 3 years ago | (#36446408)

This had been much more fun if there had been more languages and compilers benchmarked. Really interesting read though.

... and? (3, Informative)

Durandal64 (658649) | more than 3 years ago | (#36446418)

Wow, they compared a whole four languages: C++, Java, Go and Scala, of which, C++ is the fastest. Is this seriously a surprise to anyone?

Re:... and? (1)

drolli (522659) | more than 3 years ago | (#36446536)

they should have included fortran IMHO.

Re:... and? (3, Interesting)

Canberra Bob (763479) | more than 3 years ago | (#36446748)

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:... and? (1)

beelsebob (529313) | more than 3 years ago | (#36446824)

Better yet, throw in Single Assignment C, and then run the heavy number crunching on a machine with many cores/cluster and see what happens.

Re:... and? (1)

junglee_iitk (651040) | more than 3 years ago | (#36446670)

What do you suggest then? Assembly?

Re:... and? (2)

Morth (322218) | more than 3 years ago | (#36446700)

C would have been an interesting language to compare. We actually rewrote some C code to C++ and saw a speed benefit. Ofc, the original C code was very object oriented in this case, using structs with function pointers.

Re:... and? (1)

maxwell demon (590494) | more than 3 years ago | (#36446744)

Well, let's look at their list:
* C++: compiled to machine code, doesn't have GC.
* Go: compiled to machine code, does have GC
* Java, Scala: compiled to bytecode, does have GC.

So except for the bytecode/GC combination, each class has only one language inside.
For machine code/no GC, they should at least have added Fortran (which is often considered the fastest for numerics; it would be interesting if that claim still holds).
For machine code/GC, they could e.g. have added D.

And of course they should have tested with a set of algorithms representing different types of algorithms (I guess the performance characteristics differ greatly whether you look e.g. at numerics or string handling).

Re:... and? (0)

Anonymous Coward | more than 3 years ago | (#36446836)

How about we start with ICC, GCC, PGCC, and Clang. And that is just to get started with implementations of C++. (Languages are not efficient. Implementations of languages are efficient.) Then we can move on to Chez Scheme, Ikarus Scheme, PLT Scheme (aka Racket), GHC Haskell, SML, MLton, and OCaml, as well as various implementations of common lisp, Fortran (with and without BLAS/LAPACK), Pascal, Erlang, etc.

The bottom line is that the paper was not rigorous and has about the technical quality I'd expect from one of my undergraduates (too many uncontrolled variables). As a paper reviewer (which I have been but not for this paper), I'd have to strongly reject the paper as it provides no useful, meaningful information due to its lack of rigor.

Re:... and? (1)

Vintermann (400722) | more than 3 years ago | (#36446674)

On a single algorithm! I hope it was a good one.

Re:... and? (0)

whiteboy86 (1930018) | more than 3 years ago | (#36446706)

>C++ is the fastest. Is this seriously a surprise to anyone?

Sure it is, lots of managers have been brainwashed to the point of Java evangelism. Sun corporation and others tried very hard to push their corporate agenda languages and also trying to discredit C/C++ in the process, sadly nothing important has been ever written in them and those who fall for this are still fixing their code, slowness, portability after-issues, garbage collection stalls and other funny nightmares it gave them. IEEE/ISO multiple times rejected them for some good reasons, but one in particular, corporate lock-in.

Re:... and? (1)

jd (1658) | more than 3 years ago | (#36446808)

If I'd assigned someone a project like that, I'd have mandated a minimum of 12 languages (4 popular, 4 traditional, 4 experimental) with a further breakdown mixing various methodologies (you want some parallel languages, some functional, some procedural, some stack, some OO, and maybe some with more exotic forms of abstraction).

My suspicion is that C++ will rank good against some, not so good against others, but where the balance shifts according to what you're trying to do.

Now, if you're insisting on pure OO vs OO, then the same 4:4:4 breakdown applies (where traditional might include a Smalltalk variant or spinoff). OO hasn't followed a linear path from then to now, it has branched in many directions and is still branching today. You've got to have a sensible analysis of then, now and future, to know how a language truly rates at any given task.

C/C++ faster but produces more bugs (3, Interesting)

GoodnaGuy (1861652) | more than 3 years ago | (#36446424)

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.

Re:C/C++ faster but produces more bugs (2)

RotsiserMho (918539) | more than 3 years ago | (#36446476)

There may be more jobs, but in my (albeit limited) experience all the fun ones require C++ :)

Re:C/C++ faster but produces more bugs (4, Insightful)

Erbo (384) | more than 3 years ago | (#36446520)

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.

Re:C/C++ faster but produces more bugs (0, Interesting)

Anonymous Coward | more than 3 years ago | (#36446586)

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 (3, Insightful)

Vintermann (400722) | more than 3 years ago | (#36446818)

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.

Re:C/C++ faster but produces more bugs (2, Interesting)

Anonymous Coward | more than 3 years ago | (#36446614)

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:C/C++ faster but produces more bugs (1)

Anonymous Coward | more than 3 years ago | (#36446656)

Jeez, your code must not do anything interesting if you don't use memory.

Re:C/C++ faster but produces more bugs (0)

Anonymous Coward | more than 3 years ago | (#36446776)

I guess you never heard of the the C++ standard library or any other modern C++ libs. Current best practice is that, except in specific situations like legacy or very high performance code, you do not manage memory manually. And why would you? There's tons of classes like std::vector, list, unique_ptr, shared_ptr as well as tons of libs to handle it for you in a fail-safe and flexible manner.

Consequently used modern C++ doesn't behave any different from a GCd language. You never have to worry about memory. You just use it.

Re:C/C++ faster but produces more bugs (0)

Anonymous Coward | more than 3 years ago | (#36446840)

Add std::array, std::aligned_storage (both used for stack allocation), stack-based allocators, etc.

Re:C/C++ faster but produces more bugs (0)

Anonymous Coward | more than 3 years ago | (#36446786)

Not using 'exposed' heap is not the same as not using memory. Use containers instead. Heap is such terrible low-level concept...

Here you have some examples of C++ code written this way: http://www.ultimatepp.org/www$uppweb$examples$en-us.html. Some of them are quite complex.

No heap needed. And code usually gets simpler than in Java...

Re:C/C++ faster but produces more bugs (0)

msclrhd (1211086) | more than 3 years ago | (#36446704)

Use shared_ptr (Boost, C++TR1 or C++0x) for single objects to manage their lifetimes. Use std::vector, std::list or another suitable container for arrays/lists of objects. Use RAII classes for other resources.

Automatic memory management/garbage collection does not cover resource management. Consider the following in Java/C#:

public void foo()
{
      File f = new File('somefile.txt');
}

The garbage collector will correctly clean up the memory, but not the resource, so you need to do something like:

public void foo()
{
      using (File f = new File('somefile.txt'))
      { // ...
      }
}

In C++, the file object will be correctly scoped. If you wanted to create a file object for use elsewhere in a place where a generic device could be used, you can write:

std::tr1::shared_ptr create_file(const char *filename)
{
      return std::tr1::shared_ptr(new file(filename));
}

void foo()
{
      std::tr1::shared_ptr f = create_file("somefile.txt"); // ...
}

no need to worry about freeing up the memory or the resource as the code will do that for you (shared_ptr and file respectively).

Re:C/C++ faster but produces more bugs (0)

Anonymous Coward | more than 3 years ago | (#36446754)

if you start adding helper stuff from other languages to c++, it bogs it down. there's no way around that.

Re:C/C++ faster but produces more bugs (0)

Anonymous Coward | more than 3 years ago | (#36446718)

Apparently the last time you've used C++ was in 1998. Arrays, manual memory management, buffer overflows, memory leaks, resource tracking, allocation waste haven't been issues in a very long time except for in language-feature-constrained corporate environments.

C++ has many much more serious problems hurting it but those aren't among them.

Re:C/C++ faster but produces more bugs (1)

maxwell demon (590494) | more than 3 years ago | (#36446778)

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.

If you have problems managing your memory in C++, you must not have heard of RAII. Or of container classes.

Re:C/C++ faster but produces more bugs (3, Informative)

smellotron (1039250) | more than 3 years ago | (#36446530)

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.

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:C/C++ faster but produces more bugs (0)

Anonymous Coward | more than 3 years ago | (#36446532)

I disagree. If you know and understand computers, c++ is fairly easy as it doesnt obfuscate things the way java does. If you dont know what bitbanging is, never tried memory debugging or find the concept of "pointers to pointers" confusing you are better off with java, but pros should know their c.

I have worked with c/c++ for the last six years, and Ive never seen anyone use much java in the oil/gas industry (Applets not included).

Re:C/C++ faster but produces more bugs (1)

j_sp_r (656354) | more than 3 years ago | (#36446780)

And if you want to do bitbanging (or low level rs232 communication for that matter) and realtime programming Java makes you want to pull your hairs out. Don't start on JNI. Although developing anything high-level is much easier than c++.

Re:C/C++ faster but produces more bugs (1)

msclrhd (1211086) | more than 3 years ago | (#36446624)

And in C#/Java it is easy to not cleanup a resource by not closing/destroying the resource -- not placing it in a try...finally or using block.

Or, to use your examples, in C#/Java it is easy to create bugs by not properly trapping a NullPointerException or ArrayOutOfBounds exception causing the program to close unexpectedly!

I'm not saying that C/C++ are simple, or that they are not error prone, just that you need to be careful in all languages you program in. Any program has bugs in it.

Re:C/C++ faster but produces more bugs (0)

Anonymous Coward | more than 3 years ago | (#36446752)

I'd rather have my program crash with an uncaught exception that be the entry point for a compromise

Re:C/C++ faster but produces more bugs (1)

Luna Argenteus (1938902) | more than 3 years ago | (#36446772)

Meanwhile in Finland, Linus Torvald is writing one of the very rigorous stuff that is the Linux kernel mainly in C and some critical parts in Assembly.

Language shoot-out confirmed (3, Informative)

istartedi (132515) | more than 3 years ago | (#36446446)

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.

basic (4, Funny)

theheadlessrabbit (1022587) | more than 3 years ago | (#36446454)

They didn't test BASIC? Lame...

What? No FORTRAN?? (2)

paulatz (744216) | more than 3 years ago | (#36446456)

I'm disappointed, everybody knows that when the going get tough FORTRAN get going

Google = Captain Obvious (1)

DMFNR (1986182) | more than 3 years ago | (#36446458)

What was even the point of comparing these 4 vastly different languages? Java and Scala both run in virtual machines so it's obvious a native compiled language is going to beat them out. C++ is a very mature and popular language with a heritage going back to an even more mature language, so obviously it'll beat out just about anything. I think the Go language is pointless to being with, but this would have been much more interesting if they did some benchmarks comparing it to some other compiled languages like Pascal, BASIC, FORTRAN, C/C++, or D just to see where it stands in the group. This just reeks of someone coming up with some busy work to make it look like they have something to do at Google.

Re:Google = Captain Obvious (2)

SpryGuy (206254) | more than 3 years ago | (#36446484)

The fact that they left out C# seems odd as well. It makes me wonder what the point was, really.

Re:Google = Captain Obvious (2)

Daniel Dvorkin (106857) | more than 3 years ago | (#36446562)

In the absence of evidence to the contrary, it's reasonable to assume that C#'s performance results would be about the same as Java's. Testing C vs. C++ vs. Fortran would much more interesting. (There is no such language as "C/C++" and it's really irritating when people lump them together, as many commenters on this story have.)

Re:Google = Captain Obvious (1)

maxwell demon (590494) | more than 3 years ago | (#36446806)

In the absence of evidence to the contrary

Which is exactly the point. You compare performance exactly in order to create evidence one way or the other.

Re:Google = Captain Obvious (1)

steveha (103154) | more than 3 years ago | (#36446740)

The fact that they left out C# seems odd as well. It makes me wonder what the point was, really.

Google has an official list of four languages that they approve for use: Java, JavaScript, C++, and Python.

Most of their business runs on Java. Search, Google Maps, etc.

YouTube mostly runs on Python, IIRC.

So, they compared C++, on their list; Java, on their list; Scala, which is not on their list but runs on the JVM and thus would work for them; and a language invented at Google. They didn't test Python, but if they had it would have come in last place (and I say that as one who loves Python; it's reality).

Why is it surprising that Google was testing languages that Google might use for projects?

P.S. Exciting things are happening in the Python world with the PyPy project. PyPy is a Python system that is written in Python. You might expect that to be slow, and for years it was slow; but it includes a Just-in-Time compiler that generates native machine code, and it isn't slow anymore. In fact, it is now faster than the C Python, because it can optimize away lots of stuff that C Python has to do.

http://pypy.org/ [pypy.org]

steveha

So get more power (1)

Anonymous Coward | more than 3 years ago | (#36446460)

A slower language just means you need to buy more rack space. A more expensive development language (like C++, which needs more skilled coders, more debug time, etc.), means that you need to buy more developer man-hours. As far as the business world is concerned, I thought everyone had come the conclusion already that as far as business apps go, C++ isn't generally worth it.

Leave C++ for the games, the operating systems, and the frameworks that the higher level languages run on. But since everyone already knows this, TFA is kind of pointless.

Stupid sensational headline (0)

Anonymous Coward | more than 3 years ago | (#36446464)

They only benchmarked 4 languages.

write (0)

Anonymous Coward | more than 3 years ago | (#36446492)

people should write dissertation [essayservices.co.uk] on this..

Environment, conditions and parameters (3, Interesting)

meburke (736645) | more than 3 years ago | (#36446498)

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.

Re:Environment, conditions and parameters (5, Funny)

Daniel Dvorkin (106857) | more than 3 years ago | (#36446528)

I remember that Borland Pascal (in 19991) executed almost 10 times faster than Borland C++ on a consistent basis on the same systems.

Apparently, the reason it executed so fast was because it was reaching 18000 years into the future to run on the computers of the galaxy-spanning civilization built by the hyperspatial god-beings who will be our distant descendants. Man, Borland had some great tech in its day.

Ehhh... I... don't believe that. (1)

eddy (18759) | more than 3 years ago | (#36446726)

I don't know about that, maybe it was faster than Borland C++, but I did a lot of work (disassembly) on Borland Pascal compulation units and executables back in the day, and the code was horrible. HORRIBLE. Didn't even have the most basic peephole-optimizations (though someone wrote an external application to do that). It was fast to compile though, due to being one-pass, but that right there sacrifice optimizations.

So if TP/BP was faster than BC++, it was only because BC++ must have been even worse than I can imagine.

Re:Environment, conditions and parameters (1)

Vintermann (400722) | more than 3 years ago | (#36446738)

> I would be quite surprised if any C++ can execute a FFT as fast as my Leahy FORTRAN95.

Have you looked at the Fastest Fourier Transform in the West (FFTW)? [fftw.org] It's written in C - but the funny thing is, it's written in C by an OCaml program.

I think this is the way forward for truly performance intensive code. Not doing it in C++, but writing dedicated compilers for specific subroutines, churning out C, assembly, or compiler specific intermediate language code. Functional languages should excel at this, they have been ruling the program transformation/analysis space for a long time.

Assembly (3, Interesting)

Baby Duck (176251) | more than 3 years ago | (#36446506)

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

Re:Assembly (3, Funny)

MachDelta (704883) | more than 3 years ago | (#36446560)

A prof of mine used to say that "writing a program in assembly is like writing a novel in math."

Anything longer than a haiku and you''ll want to blow your brains out.

Re:Assembly (2)

should_be_linear (779431) | more than 3 years ago | (#36446854)

No, I learned programming in assembler (Zilog Z80), and used asm (MC68000, 8086-386, ARM) often until maybe 1995 when I realized that modern C/C++ compilers are generating faster code then I was able to write in asm by some 20%. For "ordinary" programs this is the case until today, more so with increasing quality of compilers. Exception is some small specialized functions, like inner loop of video encoder, where you can use SSE still better then compiler.

piss n vinegar (2)

Phantom of the Opera (1867) | more than 3 years ago | (#36446592)

Of course its going to be a C that wins. It's pushed close to the iron. C++ is for the careful, exacting personalities. I simply don't have the patience to use it on a day to day basis. Scripting is for the frenetic like me. If you pick a scripting language, you're selling out performance for keeping your rapid development and sanity. You can write beautiful safe stuff in C++ too. Use what you're comfortable with.

Average Programmers... (2)

sparky1240 (1387499) | more than 3 years ago | (#36446604)

'...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.' I think that's the problem in a lot of systems today. Too many "average" programs are being written by too many "average programmers" - and this is why there are the problems such as memory leaks, etc. I feel too many have been spoilt by the ridiculous memory and processing speeds available in todays computers. What ever happend to understanding how functions perform and refining code to be lean and mean?

Re:Average Programmers... (1)

phantomfive (622387) | more than 3 years ago | (#36446842)

I don't think that quote is right. If you look at the optimizations done in the C++ version, their main performance increases was made by using hash_map instead of map. This is easily within the sophistication of the average programmer, at least, no harder than their Java optimizations, which were:

"Replaced HashSet and ArrayList with much smaller equivalent data structures that don’t do boxing or have large backing data structures."

Also, I don't think the test was quite fair for Java. Here is what the paper says:

Note that Jeremy deliberately refused to optimize the code further, many of the C++ optimizations would apply to the Java version as well.

In other words, partially optimized Java is slower than fully optimized C++? Well isn't that amazing. If they're going to do it, they ought to optimize it all the way.....

Best permorming language on the market? (0)

Anonymous Coward | more than 3 years ago | (#36446608)

And they test against only three other languages? What kind of BS is that?

So what about C, Fortran, Ocaml, CL, Haskel? Last I heard C & Fortran were every bit as fast as C++ (if not faster) and the other three can produce very fast code.

Nope - Java refused to go in to the ring (2)

sgt101 (120604) | more than 3 years ago | (#36446620)

From the paper (section 6,E: Java Tunings) ". Note that Jeremy deliberately refused
to optimize the code further, many of the C++ optimizations
would apply to the Java version as well.'

JVM issues, really. (0)

Anonymous Coward | more than 3 years ago | (#36446646)

To a great extent, this is not about the superiority of C++ compilers, but about the limitations of the JVM as a compiler backend (and possibly, if I read it right, some problems with the garbage collector). Go is still too much under development to be a realistic comparison point for high performance code.

For example, one of the C++ tuning optimizations that they used was changing a linked list of pointers to basic blocks to a vector of basic blocks. This eliminates a level of indirection, requires fewer allocations/deallocations, and probably has better caching behavior. But the JVM cannot even produce the same representation due to its incapability of expressing a flat sequence of records/structs (unlike, say, the .NET CLR). They were also using some handcrafted internal Google data structures for tuning and some fairly low-level optimizations.

I doubt that the results would be as lopsided if the comparison occurred with a language with a more versatile IR and a mature backend (such as OCaml).

Moot Point (1)

Anonymous Coward | more than 3 years ago | (#36446654)

Assembler is by far the best performing language. But most of the time, Java performs well enough with modern hardware, so that performance becomes a moot point. As the article mentions, Java is the easiest to implement. It also has the advantage of being cross platform, something which the article doesn't address.

C++ is like sex in high school... (2, Insightful)

Anonymous Coward | more than 3 years ago | (#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.

real C (0)

Anonymous Coward | more than 3 years ago | (#36446696)

If you speedtune c++ enough it will resemble pure c. In that case you want c to get rid of the annoying c++ ABI and for a further increase in speed.

Performance often not critical (1)

Frans Faase (648933) | more than 3 years ago | (#36446722)

The cases in which performance is critical, are getting less and less, now that hardware is getting faster and faster. Not strange that Microsoft is focussing on JavaScript and HTML5. It seems that at the moment the greatest effort in performance improvement is put into JavaScript.

seriosuly? (1)

blarghmaster (2252372) | more than 3 years ago | (#36446804)

trollfood / fanboi-food post is obvious debating the effectiveness/awesomeness/speediness of a programming language is like saying "apples are better cuz oranges have hidden pips"

Google specific code (0)

Anonymous Coward | more than 3 years ago | (#36446812)

From the research paper:
"In all implementations, we use the default, idiomatic data structures in each language, as well as default type systems, memory allocation schemes, and default
iteration constructs. All four implementations stay very close to the formal specification of the algorithm and do not attempt any form of language specific optimization or adaption."

"We believe that this approach highlights features and characteristics of the languages and allows an almost fair comparison along the dimensions of source code complexity, compilers and default libraries, compile time, binary sizes, run-times, and memory footprint."

From the research paper:
"At time of this writing, the cpp_pro version depended strongly on Google specific code and could not be open-sourced."

We aren't given the source code so I can only speculate, but the above comments don't seem to jive. If you are trying to only use default libraries, types, etc of the languages and not use language specific optimizations or adaptations, then I have a little trouble coming up with how you could have "Google specific code" upon which the C++ improved version depends.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>