Is C/C++ worth it?(lemire.me)
lemire.me
Is C/C++ worth it?
http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/
25 comments
Is that one feature worth every limitation of C/C++ versus the competition? Maybe in a few narrow problem domains, but not for the average dev, IMO.
C is the Latin of computer programming. You can compile it anywhere and interface it with anything, no matter how low-level.
C++ is more esoteric, significantly harder to learn, and not as portable, but it's still better than most and runs wickedly fast if implemented according to best practices.
This is not for "average devs", not in a world where there are dozens of first-class languages better suited to general problem solving, but some domains it is still imperative to go either C, C++ or some combination.
Do average devs write kernels? Device drivers? 3D game engines? Fluid dynamics simulations? Image transformation algorithms? Network routing stacks? No, but people do, and it's a good thing they have C or C++ to solve their problems.
C++ is more esoteric, significantly harder to learn, and not as portable, but it's still better than most and runs wickedly fast if implemented according to best practices.
This is not for "average devs", not in a world where there are dozens of first-class languages better suited to general problem solving, but some domains it is still imperative to go either C, C++ or some combination.
Do average devs write kernels? Device drivers? 3D game engines? Fluid dynamics simulations? Image transformation algorithms? Network routing stacks? No, but people do, and it's a good thing they have C or C++ to solve their problems.
>C is the Latin of computer programming. [...]
>C++ is more esoteric, significantly harder to learn, and not as portable....
Does that make C++ the Sanskrit of computer programming, then? :)
On a more serious note, I just found myself upvoting every single post that acknowledged the difference between C and C++. Why? Because they're very different (you can't even say C++ is a superset of C anymore), and using C++ competently requires knowing the differences. It always makes me think these posts that compare the writer's favorite language to this mythical "C/C++" language are written by people who don't know either C or C++ very well.
Edit for clarity: I note that the actual title of the post is "Is C++ worth it?" so the author doesn't seem to be making this mistake, except in one instance where he refers to "C/C++ programmers". In that case, he might actually be referring to "C programmers or C++ programmers," so I can forgive him the abuse of language.
>C++ is more esoteric, significantly harder to learn, and not as portable....
Does that make C++ the Sanskrit of computer programming, then? :)
On a more serious note, I just found myself upvoting every single post that acknowledged the difference between C and C++. Why? Because they're very different (you can't even say C++ is a superset of C anymore), and using C++ competently requires knowing the differences. It always makes me think these posts that compare the writer's favorite language to this mythical "C/C++" language are written by people who don't know either C or C++ very well.
Edit for clarity: I note that the actual title of the post is "Is C++ worth it?" so the author doesn't seem to be making this mistake, except in one instance where he refers to "C/C++ programmers". In that case, he might actually be referring to "C programmers or C++ programmers," so I can forgive him the abuse of language.
For what it's worth, the original title was changed to "Is C++ worth it?" after the fact.
I'd say in even fewer problem domains than you might think at first glance... once you've kicked out all the domains where you can cleanly compartmentalize your low level interactions.
What I find lacking in a lot of these discussions, beyond the cursory "unless you need super performance" is the context of what the code is for, and what the users expect.
For instance, in the scientific computation that I do, most code will be used in finished form on the order of 10s of datasets at most. Occasionally, we step out from R or Matlab or Python and use C/C++ if a) we know we'll use a function thousands of times in multiple contexts, b) we're writing code to be used by other people, or c) we're working in a time/resource constrained environment, like a supercomputer or shared cluster with many users, where we pay for time.
I imagine the "modest" 2x improvement would not matter at all if: a) your users are going to batch process a bunch of files just a couple times, but want the most up-to-date features possible, so you optimize for production speed, not performance, or b) you are writing the code for yourself, so letting it run in the background or on a cluster for 2 days instead of 1 doesn't make a huge difference.
On the other hand, if I were writing a photo-editing program where users call the same feature over and over and over to get the photo looking just right, I would definitely prioritize performance, and a 2x improvement is a very noticeable speedup over a competitor's. A lot of products I use every day are actually like this.
For instance, in the scientific computation that I do, most code will be used in finished form on the order of 10s of datasets at most. Occasionally, we step out from R or Matlab or Python and use C/C++ if a) we know we'll use a function thousands of times in multiple contexts, b) we're writing code to be used by other people, or c) we're working in a time/resource constrained environment, like a supercomputer or shared cluster with many users, where we pay for time.
I imagine the "modest" 2x improvement would not matter at all if: a) your users are going to batch process a bunch of files just a couple times, but want the most up-to-date features possible, so you optimize for production speed, not performance, or b) you are writing the code for yourself, so letting it run in the background or on a cluster for 2 days instead of 1 doesn't make a huge difference.
On the other hand, if I were writing a photo-editing program where users call the same feature over and over and over to get the photo looking just right, I would definitely prioritize performance, and a 2x improvement is a very noticeable speedup over a competitor's. A lot of products I use every day are actually like this.
First off, putting C and C++ in the same category is plain wrong. One is a low level language, and the other is a high level language with tons of features, and rich libraries.
When it comes to performance, you either require it or you don't. There is no place in between. When performance is a requirement, C++ can be a very good option. It's a great balance between performance and high level feature set.
With experience, we (programmers) become more pragmatic and get better at picking the right tool for the job.
When it comes to performance, you either require it or you don't. There is no place in between. When performance is a requirement, C++ can be a very good option. It's a great balance between performance and high level feature set.
With experience, we (programmers) become more pragmatic and get better at picking the right tool for the job.
Please don't call it C/C++
C is a vibrant, separate language from C++ that has wonderful applications separate from it.
C++ doesn't need to be called C as well, that's what the first character of it's name means. It's also has nothing like a ABI, so is far from C as can be in that regard.
C is a vibrant, separate language from C++ that has wonderful applications separate from it.
C++ doesn't need to be called C as well, that's what the first character of it's name means. It's also has nothing like a ABI, so is far from C as can be in that regard.
Does it really serve anyone to have another ridiculous language war every time someone posts a microbenchmark that shows their favourite language winning?
No it doesn't. But the article in question isn't about whether Java is better than C++. It notes that Java and Javascript environments are getting better, so you have to work harder to optimize your C++ to the point where it is faster. Which is still possible, just harder.
Who the hell is writing C when JavaScript is an option? I mean, I love C, and I don't know JavaScript well, but they don't really live in the same problem domain.
I too love C. And I would use it over JavaScript any time. But that's mainly because I can't stand JavaScript ;) For prototyping and problems which are just easier to handle in higher level languages I'd go for Python.
I think it's a shame that the client side of the web is basically limited to JS, because seriously, that's the only reason so many people started coding in it in the first place. I believe that if we could, many devs would prefer other languages.
I think it's a shame that the client side of the web is basically limited to JS, because seriously, that's the only reason so many people started coding in it in the first place. I believe that if we could, many devs would prefer other languages.
node.js
I was under the impression that application programming using node.js was done primarily in JavaScript...
No. . . but it's going to happen anyway.
The same thing happened when (non-GC) HLLs started to overtake assembly language. And the discussions will continue to be equally context-free. And I'm sure that just like the last time around, the most vociferous participants in the debate will be people who don't have to work with terribly high performance demands anyway. On account of the people who do usually being way too overexposed to the mountains of nuance (and aware that the only reliable way to find the best option in any particular case is to do some measuring for that particular case) to feel comfortable making the kinds of categorical statements that make for good blogging.
The same thing happened when (non-GC) HLLs started to overtake assembly language. And the discussions will continue to be equally context-free. And I'm sure that just like the last time around, the most vociferous participants in the debate will be people who don't have to work with terribly high performance demands anyway. On account of the people who do usually being way too overexposed to the mountains of nuance (and aware that the only reliable way to find the best option in any particular case is to do some measuring for that particular case) to feel comfortable making the kinds of categorical statements that make for good blogging.
Well, two points:
1. Using raw pointers as opposed to vectors gives 2x the performance on my machine.
2. This is a microbenchmark with extremely simple array indexing pattern. JVMs can optimize away the array bounds checks penalty in this case but those become hard to do once your access patterns become anything other than "i" or "i-1". For example, even more general linear subscripts are hard to correctly optimize for array bounds checks, let alone anything non-linear. How do I know? Compiler researcher here :)
However, still impressive to see JVMs advance.
1. Using raw pointers as opposed to vectors gives 2x the performance on my machine.
2. This is a microbenchmark with extremely simple array indexing pattern. JVMs can optimize away the array bounds checks penalty in this case but those become hard to do once your access patterns become anything other than "i" or "i-1". For example, even more general linear subscripts are hard to correctly optimize for array bounds checks, let alone anything non-linear. How do I know? Compiler researcher here :)
However, still impressive to see JVMs advance.
IMHO you can't effectively ask this question at such a broad level. A better question would be "is C/C++ worth it for my project?". Or with respect to the contents of the blog post, "is C/C++ worth it for performing a cumulative sum?"
This isn't to say that major strides haven't been made in the performance of high level VMs, interpreters and compilers. But for some classes of applications, it's arguably not worth trying to avoid C or C++. Audio software is bound by very stringent realtime requirements (you absolutely cannot miss a sample vector -- dropouts are bad bad bad), such that GC becomes problematic in many cases. If you're writing a raster effects chain, a sensible thing to do in C would be to pass a pointer to your frame buffer through a chain of function pointers operating on the data in place and avoiding copying at all costs.
Point being, the more constraints like these that pile up, the harder time a compiler will have guessing what kind of performance characteristics you're looking for, and though I'm sure there are ways to get around these problems in higher level environments, you may end up finding that the time you spend tuning things to get it just right would have been better spent getting your hands dirty with some C. But as with everything, YMMV.
This isn't to say that major strides haven't been made in the performance of high level VMs, interpreters and compilers. But for some classes of applications, it's arguably not worth trying to avoid C or C++. Audio software is bound by very stringent realtime requirements (you absolutely cannot miss a sample vector -- dropouts are bad bad bad), such that GC becomes problematic in many cases. If you're writing a raster effects chain, a sensible thing to do in C would be to pass a pointer to your frame buffer through a chain of function pointers operating on the data in place and avoiding copying at all costs.
Point being, the more constraints like these that pile up, the harder time a compiler will have guessing what kind of performance characteristics you're looking for, and though I'm sure there are ways to get around these problems in higher level environments, you may end up finding that the time you spend tuning things to get it just right would have been better spent getting your hands dirty with some C. But as with everything, YMMV.
These kind of extremely simple loops are exactly the sort of thing where almost _any_ language can optimize things into levels of performance that approach hand-tuned asm (which itself isn't always the way to go for anything complex, but for simple codes, frequently still is).
If you actually wanted this code to go fast you'd use SSE, of course - and make a big mess of prefetches and intrinsics and so on. On a good day you might get the same result out of icc.
That being said, the guy is right - most of the time. A range of performance differences extending up to 2-5x between (say) Java and C++ (as shown on, say, the Programming Languages Shootout) shouldn't be decisive to most programmers who aren't writing code that's CPU bound.
Of course, while this argument can be made in favor of Java over C++ (not my personal taste, but still), it could be equally made for Python or Ruby over either. :-) This is especially true where the 'low performance' scripting language is just driving highly optimized math routines done over large chunks of data.
If you actually wanted this code to go fast you'd use SSE, of course - and make a big mess of prefetches and intrinsics and so on. On a good day you might get the same result out of icc.
That being said, the guy is right - most of the time. A range of performance differences extending up to 2-5x between (say) Java and C++ (as shown on, say, the Programming Languages Shootout) shouldn't be decisive to most programmers who aren't writing code that's CPU bound.
Of course, while this argument can be made in favor of Java over C++ (not my personal taste, but still), it could be equally made for Python or Ruby over either. :-) This is especially true where the 'low performance' scripting language is just driving highly optimized math routines done over large chunks of data.
His benchmark did not mention anything about memory consumption. I'd imagine that C/C++ used a fraction of the memory Java used in his microbenchmark.
A little story - I wrote a DJing application in one language and then released it for the HP Touchpad, Android, and Playbook. I'm going to release it for the BB10. I released a second app using the same framework for Android, and another app for iOS.
.. Surprise! It's all in C++. It uses libSDL for input and audio, and openGL for graphics. With that framework I also released an app for iOS. Everything under the sun has a SDL port.
The downside was I had to write my own UI widget framework and cannot do any native features. The upside is "write once, port to everywhere".
.. Surprise! It's all in C++. It uses libSDL for input and audio, and openGL for graphics. With that framework I also released an app for iOS. Everything under the sun has a SDL port.
The downside was I had to write my own UI widget framework and cannot do any native features. The upside is "write once, port to everywhere".
It depends. As always, premature optimization (which includes premature language optimization) is the root of all evil.
If you have specific reasons for starting with C or C++, great. Go for it. Have fun.
One the other hand, if you are picking either because, for example, you have a vague sense you want performance and/or low-level control... It's probably worth looking at your alternatives and thinking about your tradeoffs.
If you have specific reasons for starting with C or C++, great. Go for it. Have fun.
One the other hand, if you are picking either because, for example, you have a vague sense you want performance and/or low-level control... It's probably worth looking at your alternatives and thinking about your tradeoffs.
Lies, damn lies, and benchmark statistics
Why does he use a vector for the C++ version, but an array for the java version. It seems like it'd be a lot more comparable to use an arraylist in java, (either that or just a standard array in C). Nonetheless, the having the time slowed by the call to cout has a pretty large effect as well. It seems like this was rather setup to favor the java version from the beginning
There are two things about the C++:
1) why use a class for the timer?
2) It's not clear if the order of operations ensures that the timer is stopped before the first print operation happens. Thus your C++ may be including some part of the cout print operation
1) why use a class for the timer?
2) It's not clear if the order of operations ensures that the timer is stopped before the first print operation happens. Thus your C++ may be including some part of the cout print operation
Re: 2, I am surprised if operations with side-effects get called out of order.
Site's down, so I can't pull up the exact link, but the java code basically did
get time
do it
get time again
print timing info
cout << .... << some_method_which_stops_time_and_returns << ...
Evaluation order is implementation-defined. I'm pretty sure all of the arguments are evaluated before any printing is done at all. The code
cout << "asdf:" << b()
(cout << "asdf:") << b()
cout.operator<<("asdf:").operator<<(b())
int f() {
static int a=0;
return a++;
}
cout << f() << " " << f() << endl;
Code is at https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...
Fwiw, I just ran it after fixing the time call, and it doesn't seems to significantly change the result on my (low spec) machine.
Fwiw, I just ran it after fixing the time call, and it doesn't seems to significantly change the result on my (low spec) machine.
Sorta, yes. It can evaluate one of the operator<<'s before doing the timer. The following:
cout << "smarter sum " << N/(1000.0*time.split()) << endl;
operator<<(endl,
operator<<(N/1000.0*time.split(),
operator<<(cout, "smarter sum ")
)
);
Here's the link to the github account where the code is:
https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...
Even if they're doing whole program analysis, the fact that oeprator<<() and WallClockTimer.split() are side-effectful and I believe that means that it would be invalid for the compiler to find the current time before the first section of the print statement is finished.
Even if they're doing whole program analysis, the fact that oeprator<<() and WallClockTimer.split() are side-effectful and I believe that means that it would be invalid for the compiler to find the current time before the first section of the print statement is finished.
While most of these discussions tend to focus on performance benchmarks as the primary criteria, there is another factor to consider.
To a large extent, it depends on the target platform. If you developing an application to work across the widest possible range of desktop and mobile platforms, C++ is your best bet.
Using C++, you can have a single code base that can be compiled for Windows, OSX, Linux, iOS, Android and WinMo. There is no other language that gives you that.
The UI code is not portable in any case, but that would be a common problem regardless of language.
To a large extent, it depends on the target platform. If you developing an application to work across the widest possible range of desktop and mobile platforms, C++ is your best bet.
Using C++, you can have a single code base that can be compiled for Windows, OSX, Linux, iOS, Android and WinMo. There is no other language that gives you that.
The UI code is not portable in any case, but that would be a common problem regardless of language.
I always hate these tests because what is being compared is always lost. Are you trying to compare the best possible performance in these languages or the speed of the average program? The problem with that invariably ends up being the amount of work/knowledge gets put into the implementation. For example, gettimeofday is a terrible function to use for measuring performance. Furthermore, people for some reason get religious about languages. Every language has its benefits and costs. Use whatever language is appropriate to your situation.
I actually couldn't load the site, HN has apparently nuked it. But I can deduct from the comments that it's another benchmark comparison.
Aren't we missing something essential though? C and C++ give you the possibility to make self-contained, lean applications - using the right frameworks you can also target as many platforms as you want. Java, python etc. have in common that they all require a runtime environment, including all the compatibility and update problems.
Aren't we missing something essential though? C and C++ give you the possibility to make self-contained, lean applications - using the right frameworks you can also target as many platforms as you want. Java, python etc. have in common that they all require a runtime environment, including all the compatibility and update problems.
Interpreters will always have an information advantage, they get to optimize based on what the system is actually doing, rather than clever profiles.
The big question is, is that information ever worth it? Does the cost of examining the running system completely overshadow any possible benefit?
So far, no. it's not worth it. It'll be really interesting to see what happens with massive parallelism though.
The big question is, is that information ever worth it? Does the cost of examining the running system completely overshadow any possible benefit?
So far, no. it's not worth it. It'll be really interesting to see what happens with massive parallelism though.
Well, compilers can always look at what happens during the actual operation of a program and then use that information to redo the compilation better. That's a lot of effort, but it can make a big difference. For a while the Windows version of Firefox was noticeably faster than the Linux version because the people packaging it for Windows did this but the Linux packagers didn't.
See http://en.wikipedia.org/wiki/Profile-guided_optimization
See http://en.wikipedia.org/wiki/Profile-guided_optimization
Maybe there will be two classes of applications. The elite, like browsers that are constantly fed data about how people use them, regularly updated so optimization is compiled right in; and the not so elite, that rely on per-run startup optimization for good performance.
IIRC gcc already links in a runtime system for recovering runtime type information about dynamic cast. It's not hard to imagine C++x20 (or whatever) including some kind of runtime optimizer.
IIRC gcc already links in a runtime system for recovering runtime type information about dynamic cast. It's not hard to imagine C++x20 (or whatever) including some kind of runtime optimizer.
Check out the Synthesis Kernel: http://en.wikipedia.org/wiki/Self-modifying_code#Massalin.27...
It uses run time information to modify its own code to perform optimally. It was incredibly fast, but the difficulty in using SMC far outweighs the benefits in most applications.
It uses run time information to modify its own code to perform optimally. It was incredibly fast, but the difficulty in using SMC far outweighs the benefits in most applications.
[deleted]
what about changing your code to the following? any noticeable speed changes?
size_t size = data.size(); for (size_t i = 1; i != size; ++i) { data[i] += data[i - 1] ; }
size_t size = data.size(); for (size_t i = 1; i != size; ++i) { data[i] += data[i - 1] ; }
[deleted](2)
Was down for me. Cached copy:
http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/
http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/
You posted the original link instead of a mirror.
It is down for me, too. You can read the article via Google's search results preview but it isn't linkable and there is no Google Cache link.
It is down for me, too. You can read the article via Google's search results preview but it isn't linkable and there is no Google Cache link.
http://www.google.com/search?q=cache:http://lemire.me/blog/a...
Searching for cache:URL often works even when the search results don't link to the cached version for whatever reason.
Searching for cache:URL often works even when the search results don't link to the cached version for whatever reason.
Maybe if it used C the site would still be up!
How would Objective-C compare?
C is worth it. C++ is not.
Thanks for the nuanced analysis.
At least we could still make this point : Since C/C++ is not a language, C/C++ is not worth it.
They should make a C/C++ standard for those people who insist on using the C++ features they like, thus necessitating compiling in C++ mode, while ignoring most of what C++ has to offer.
Maybe call it C+ since that's the grade I'd give that kind of half-baked code.
Maybe call it C+ since that's the grade I'd give that kind of half-baked code.
Every professional shop that uses C++ and has been around for any time uses a subset of C++. What that particular subset is, is completely different for almost every shop.
Java is great - right upto the point where it isn't/
Do a similar example where you want to replace the values in situ and find that Java is making a copy of the entire array every time. At that point you are stuck, there is no way out. C may be difficult but it lets you do anything you want.
note: yes Java may have a flag that says do int array in place, in this case - but you know what I mean.
Do a similar example where you want to replace the values in situ and find that Java is making a copy of the entire array every time. At that point you are stuck, there is no way out. C may be difficult but it lets you do anything you want.
note: yes Java may have a flag that says do int array in place, in this case - but you know what I mean.
Pretty much all unixes are written in C, and using the language of the OS means you can talk to it the same way the developers do, rather than through an FFI; even the best FFIs suffer from the fact that there will be some impedance mismatch between languages.