[SOLVED] C and C++ performance comparison in numerical computation
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
View Poll Results: Which language would you use for HPC codes?
C and C++ performance comparison in numerical computation
Hi there!
I have been writing this library as a summer project and I thought on writing it on C++ and then write a C wrappers collection (interface) so that C user could use it.
But then I thought... shouldn't I write the numerical cores in C and do the interfaces in C++?
My question is: up to which point is C better than C++ for required-performance codes such as numerical PDEs?
I asked that question to the guy who developed Overture and he told me that as long as I could keep my C++ code just as a C code, performance shouldn't be compromised. Nonetheless, Overture has every numerical core written in C and Fortran and the interface written in C++.
Thanks in advanced! \m/
Last edited by ejspeiro; 08-18-2011 at 07:03 PM.
Reason: Typo' fixed
Click here to see the post LQ members have rated as the most helpful post in this thread.
I thought on writing it on C++ and the write a C wrappers collection (interface) so that C user could use it.
Sounds good. I often do C++ code with C wrappers so the code can be delivered as a .a or .so file. C++ interface (name mangling and other factors) may be unstable across changes of compiler or version. C interface is much more stable. If delivering source code rather than binary, my reason for a C interface isn't important, but your reason still might be.
Quote:
But then I thought... shouldn't I write the numerical cores in C and do the interfaces in C++?
I don't think that is a good idea.
Quote:
My question is: up to which point is C better than C++ for required-performance codes such as numerical PDEs?
Depends on the skill and performance awareness of the programmer. If you are skilled and performance aware, it is never hard to get at least as good performance in C++ as you would have in C. But it is sometimes very hard to get the same high performance in C as might be easy in C++.
If you are less skilled, there are many performance pitfalls in C++, ways in which a less skilled programmer might unknowingly kill performance in C++, where a similar performance mistake in C would be more obvious.
Quote:
I asked that question to the guy who developed Overture and he told me that as long as I could keep my C++ code just as a C code, performance shouldn't be compromised.
Nor improved!
C++ does not inherently add any overhead. If you code the same thing in C++ as you would have in C, you get the same performance. I wouldn't write performance critical code that way. I would write it better in C++ than in C. But I'm unusual.
Quote:
Nonetheless, Overture has every numerical core written in C and Fortran and the interface written in C++.
Maybe for historical reasons? I don't know.
Lots of performance critical numerical code is written in Fortran, maybe because that is what the algorithm experts writing the code have learned to think in. It sure isn't from any real advantage of Fortran compared to C++
My question is: up to which point is C better than C++ for required-performance codes such as numerical PDEs?
Well, if you don't know what are you doing, then you can mess up in either language. Both languages are compiled, so performance mostly depends on your programming skills/knowledge. If you want good performance, pick decent algorithm and profile your program frequently to detect bottlenecks. Measure your program's performance instead of trying to guess it.
But then I thought... shouldn't I write the numerical cores in C and do the interfaces in C++?
My question is: up to which point is C better than C++ for required-performance codes such as numerical PDEs?
If you don't use allocations and deallocations in the iterative part of the solver there shouldn't be much of a difference, unless your algorithm is so tight that extra dereference operations (e.g. accessing vtables or nested structures, using non-pointer iterators) cause a noticeable degradation. I implemented a sorting algorithm several years ago that ran so tightly that I saw a performance difference between val = a? b : c; and if (a) val = b; else val = c; with simple iterator operations. With indefinite-iteration algorithms such as PDE solvers, however, it's better to reduce the number of iterations and number of copy operations first.
Kevin Barry
unless your algorithm is so tight that extra dereference operations (e.g. accessing vtables or nested structures, using non-pointer iterators) cause a noticeable degradation.
In the performance critical portions of numerical PDE code, if the programmer is competent, I would not expect any access to vtables nor non-pointer iterators, nor the type of structure nesting that takes extra accesses. This is a situation in which templating is very powerful for writing general purpose source code that has no run time cost for its generality.
Quote:
Originally Posted by ta0kira
it's better to reduce the number of iterations and number of copy operations first.
There is typically more room for improvement in making the sequence of copy operations more cache friendly than in actually reducing the number of copy operations. Either way, you're in a very difficult area already studied by some very good algorithm experts. Unless you're part of a really strong professional team, you may be better off following published algorithms keeping your own focus on code quality vs. trying to beat the published experts on algorithm.
I don't want to get much more specific about what should or shouldn't be in numerical PDE code, because that could get too close to some of my closed source professional work.
There is typically more room for improvement in making the sequence of copy operations more cache friendly than in actually reducing the number of copy operations. Either way, you're in a very difficult area already studied by some very good algorithm experts. Unless you're part of a really strong professional team, you may be better off following published algorithms keeping your own focus on code quality vs. trying to beat the published experts on algorithm.
Yes, I wasn't suggesting that the average engineer set out to come up with a PDE algorithm. I failed to be concise in my effort to generalize to whomever might be writing PDE software. Certainly there are numerous mathematicians specializing in PDE and numerical analysis who are better suited for such tasks than most individuals. OP could be on either side, which I was trying to account for.
Kevin Barry
Sergei: Wow! Those are excellent links, particularly I learned a lot while reading about Armadillo for C++. Similarly, IML with SparseLib++ seem both very useful.
Thank you!
H_TeXMeX_H: The website about benchmarks for programing languages is very cool! I could run a couple of them to back my desicion up about selecting the language.
ta0kira: Your comment was very useful! I will take care of the iterative parts! Thank you for tailoring your answer toward PDE solvers development!
I believe that performance in numerical simulation is important but correctitud also matters. In early stages of development, I will focus of correctitud rather than in performance; nonetheless, performance will not be disregarded in an point!
johnsfine: Thank you for your remarks! YES, I like templates, specially in this kind of libraries where one generally keep different versions to account for different data types for the scalars involved in you algorithm.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.