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.'"
Common knowledge (Score:5, Insightful)
I thought this was common knowledge. Did anyone ever doubt that?
Re:Common knowledge (Score:5, Funny)
It's been common knowledge for at least a decade that Java is 6 months away from being quicker than c++.
Re: (Score:3)
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...
I don't know about that (Score:3, Funny)
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! Of course they never seem to have a good answer for why if this is the case all performance important apps (like games, audio software, etc) are written in something else or why Java linpack pulls like 750Mflops on a system where native compiled (from C) Linpack gets 41Gflops. However they are sure it is faster!
Re:I don't know about that (Score:5, Interesting)
Re: (Score:3)
This is exactly the reason why Fortran beats C or C++ when it comes to numerical computation.
Those are different guarantees. Fortran provides some better floating point facilities for numerics, like errors on a loss of precision, but those don't affect speed on common hardware. The main thing about FORTRAN is that the lack of array aliasing and pointers makes optimization much easier. C now has the restrict keyword which gives you similar options for optimization.
Re: (Score:3)
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.
Re:Common knowledge (Score:5, Insightful)
There's a lot of Java-ites who claim that Java is just as fast. They're idiots, but they're vocal.
Re: (Score:2)
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 (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: (Score:2, Interesting)
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: (Score:3, Funny)
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: (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
Re: (Score:3)
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.
Me too, and I really can't remember the last time I worried about memory management or had a memory leak in C++. It's just all automatic when you do it properly.
The problem with GC is that they told people to use it for things other than RAM. For files, network connections, etc. GC is a very bad idea. You need those resources freed in a timely manner, not when some mindless robot thinks it might be worth doing.
In Java there's no way to automate this process (no equivalent to C++ stack unwinding) so every t
Re: (Score:2)
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: (Score:3)
The allocation/deallocation advantages that GC languages have can be given to C++ through techniques such as memory pools.
It's actually something seen on the all too common "hey this code is faster in Java than C++" examples that you see from time to time. They will be allocating and de-allocating many small objects. Without using a memory pool the C++ code will be slower whilst the Java program which internally uses a memory pool through its garbage collector will be faster. Of course, if you use a memory
Re:Common knowledge (Score:5, Insightful)
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.
Re:Common knowledge (Score:4, Interesting)
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.
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: (Score:3)
So, if memory management is issue today, something is wrong...
Developers.
Most CS courses went with GC-capable languages. Plus side: students can concentrate on algorithms and are shielded from even trivial details of computer architecture. Minus side: programming is all about resource management (resource being: CPU, memory block, file or even programs themselves) and new slew of developers are struggling with anything scaled from lab assignment to the real world magnitudes.
Recently seen anguish of a developer who tried to open 100K files. And it didn't worked.
Java is fast (Score:5, Insightful)
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:
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 (Score:5, Insightful)
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]).
Java threading (Score:2)
You mean suspend/resume? That was deprecated like 10 years, but functions required to do it right were in from the beginning (since 1.0).
Re: (Score:3)
2-3Ghz Cpus have been out for ages, they are so fast, signals can't travel any meaningful distance within a single cycle - it makes a lot more sense to core up than to try and beat the speed of light. And you pointing out a core clock from 700 to 1Ghz in 3 years is good is actually just proving my point. 8-10 years ago you would expect a double up every 18 months, it's just not economically and physically viable to keep that race going.
And yes, they might have new instructions and they might be doing more p
Re: (Score:2)
Usually slower, yes. Enough slower to make you turn your nose up? You're just being precious.
Re: (Score:2)
Disclaimer: I never liked the concept of Java and its oddly insane ability to have multiple security bugs at any given time.
Good job Java, you slow down our systems and let hackers gain access. Way to keep small businesses down! (Sorry, I'm feeling very sardonic right now.)
Re: (Score:3)
Does throwing insults somehow might you right?
You (and the mods who rated your comment "insightful") would do well to take an objective look at the facts here. If you'd bothered to RTFA, you'd realise that this is an apples to oranges comparison. The C++ code was optimised far beyond the Java code:
"E. Java Tunings: Jeremy Manson brought the performance of Java on par with the original C++ version. This version is kept in the java_pro directory. Note that Jeremy deliberately refused to optimize the code furt
Re: (Score:3)
If you need speed, C++/C (well developed code and algorithms of course)
And that's the clincher. Badly written Java is often faster than badly written C++, because the Java programmer just lets the VM do certain things while the C++ programmer writes their own slow and buggy version. And, on a big project, it only takes a little bit of bad code to offset the performance of the rest.
Re: (Score:2)
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
Re: (Score:2)
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.
Re:Common knowledge (Score:4, Insightful)
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.
Garbage collection (Score:2)
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: (Score:2)
Because clearly you need to re-read this thread. It will all make sense then.
Re: (Score:2)
I'm sure there's a malloc replacement library out there that does GC. :)
Re: (Score:2)
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:
Now, if you want to consider "the best", then you'd also want to include a few of the more experimental languages:
The problem with selecting benchmarks is that it's easy to pic
Re: (Score:2)
Re: (Score:2)
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 class
Re: (Score:3)
std::sort typically blows qsort out of the water because it can do way more inlining.
You need to qualify that with 'in microbenchmarks'. In real code, the excessive special casing and inlining that C++ templates encourage causes program size to bloat hugely, which impacts instruction cache usage. An instruction cache miss costs 150+ cycles. A function call with working branch prediction costs half a dozen.
Re: (Score:2)
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,
... and? (Score:4, Informative)
Re: (Score:2)
they should have included fortran IMHO.
Re:... and? (Score:4, Interesting)
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: (Score:2)
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? (Score:4, Interesting)
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: (Score:2)
What do you suggest then? Assembly?
Re: (Score:3)
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: (Score:3)
Re: (Score:2)
On a single algorithm! I hope it was a good one.
Re: (Score:2)
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
C/C++ faster but produces more bugs (Score:3, Interesting)
Re: (Score:2)
Re:C/C++ faster but produces more bugs (Score:5, Insightful)
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: (Score:2, Interesting)
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 cod
Re: (Score:2)
You've clearly never programmed in C++. Or, more likely, all of your C++ code has been C code in a very thin disguise.
Re: (Score:3)
That you got 5 Insightful indicates that most people are quite ignorant of many of C++'s features.
It's very easy to have "automatic memory management" in C++ without resorting to GC. STL containers and reference-counted smart pointers make this trivial. I have written numerous commercial applications in C++ and most of them do not have a single explicit "delete" or "free" statement. And I get templates, which lets the optimizer do some amazing things.
Re:C/C++ faster but produces more bugs (Score:4, Insightful)
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: (Score:2)
It's not that I can't figure it out. It's that I don't *care*.
And a lot of programmers shouldn't. It's a perfectly automatizable problem that can be done by the machine itself. In most cases it's just inefficient to do that manually. You might as well be writing the machine code yourself.
Granted, there are some cases in which it's necessary to manage memory by hand. But those are the exception, not the norm.
If you are spending time figuring out the memory that all your programs are allocating, chances are t
Re: (Score:2)
I can assure you, those things have absolutely nothing to do with someone "having problems" with memory management. If you do it wrong, you will still do it wrong regardless of tools, features, methods and ideologies involved. The point is, you have to understand what you are doing, not choose the tools or follow the instructions that supposedly will do it for you.
Re: (Score:2)
but there's no program path which will ever access it again, and thus it should be discarded
Memory management does not work that way (also lol halting problem).
Re: (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: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: (Score:2)
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: (Score:2)
You shouldn't be trapping either of those exceptions. They are both indicative of an incorrect assumption on the part of the programmer which means that the program's state is no longer trustworthy. The only safe thing to do is get out and start again.
Re: (Score:2)
Any given programmer ALWAYS produces a constant (amount * severity) of bugs per time.
Re: (Score:3)
No, you mean YOU aren't so good. A good c programmer won't produce any more bugs than a good any-other-language programmer; we know how to handle memory, multi-threading, and those other issues that terrify those who have only worked with languages with training wheels permanently attached.
Re: (Score:2)
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++.
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.
basic (Score:5, Funny)
They didn't test BASIC? Lame...
What? No FORTRAN?? (Score:2)
Environment, conditions and parameters (Score:4, Interesting)
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 (Score:5, Funny)
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. (Score:2)
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
Re: (Score:2)
> 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, the
Homoiconicity (Score:2)
" Functional languages should excel at this, they have been ruling the program transformation/analysis space for a long time."
I think the key is homoiconicity, not functionalness. Prolog isn't a functional language, and it's mainly used for domain specific languages/one-off compilers.
Assembly (Score:4, Interesting)
Re:Assembly (Score:4, Funny)
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.
Also (Score:4, Interesting)
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: (Score:3)
Re: (Score:2)
Reasonable c/c++ code can be as good as (or even better than) hand-tuned assembler. There's just no benefit to writing in ASM for most things.
Basically, c/c++ code should nearly transform back into the equivalent assembler-generated code for almost anything, as long as your compiler is good.
piss n vinegar (Score:3)
Average Programmers... (Score:2)
Re: (Score:2)
"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, t
Re: (Score:2)
Of course on Slashdot everyone is above average.
Nope - Java refused to go in to the ring (Score:3)
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.'
C++ is like sex in high school... (Score:2, Insightful)
... 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 o
Performance often not critical (Score:2)
Re: (Score:2)
It's not for everyone, though. (Score:2)
Nope, C++ certainly not for everyone. But the most powerful tools rarely are.
business is different (Score:2)
Many talk about time to develop, and certainly C/C++ sucks in that capacity. And many talk about code complexity and liklihood of bugs due to memory management, and certainly there's much to be said there too. But C/C++ fails me in one very simple business category: code robustness.
Every project I work on has clients doing one very important thing -- turning the entire thing upside-down and backwards three times. In C/C++, I'd get to start from scratch every time. In Perl, I get to shuffle a few lines o
Business is different (Score:2)
Many talk about time to develop, and certainly C/C++ sucks in that capacity. And many talk about code complexity and liklihood of bugs due to memory management, and certainly there's much to be said there too. But C/C++ fails me in one very simple business category: code robustness.
Every project I work on has clients doing one very important thing -- turning the entire thing upside-down and backwards three times. In C/C++, I'd get to start from scratch every time. In Perl, I get to shuffle a few lines of co
Re:Business is different (Score:4, Insightful)
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.
This just in (Score:2)
Not a language shootout.... (Score:4, Insightful)
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.
Re: (Score:3)
The fact that they left out C# seems odd as well. It makes me wonder what the point was, really.
Re: (Score:3)
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: (Score:2)
Here's some strong evidence to the contrary:
http://reverseblade.blogspot.com/2009/02/c-versus-c-versus-java-performance.html [blogspot.com]
Re: (Score:2)
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