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/

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.

I don't think that is a good idea.

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.

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.

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++

johnsfine: Thank you!

That was an amazing reply and I appreciated it!

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.

SigTerm: Awesome!

Thank you and you are right! Performance should be measured and off course I will!

Thanks!

I suggest to get acquainted with:

http://en.wikipedia.org/wiki/Armadil...%2B_library%29
http://eigen.tuxfamily.org/index.php?title=Main_Page
http://www.linalg.org/
http://en.wikipedia.org/wiki/Matrix_Template_Library
http://math.nist.gov/iml++/

, etc.

See:
http://shootout.alioth.debian.org/

I vote mostly for C, but Fortran is good for math as well.

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

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.

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.

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.

Thank you!

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.

Thank you guys!

Thanks to all of you! I'm calling this one SOLVED!