LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (http://www.linuxquestions.org/questions/programming-9/)
-   -   C and C++ performance comparison in numerical computation (http://www.linuxquestions.org/questions/programming-9/c-and-c-performance-comparison-in-numerical-computation-898164/)

ejspeiro 08-18-2011 05:53 PM

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/

johnsfine 08-18-2011 06:54 PM

Quote:

Originally Posted by ejspeiro (Post 4447166)
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++

ejspeiro 08-18-2011 07:08 PM

johnsfine: Thank you!

That was an amazing reply and I appreciated it!

SigTerm 08-18-2011 07:51 PM

Quote:

Originally Posted by ejspeiro (Post 4447166)
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.

ejspeiro 08-18-2011 08:35 PM

SigTerm: Awesome!

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

Thanks!

Sergei Steshenko 08-19-2011 07:31 AM

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.

H_TeXMeX_H 08-19-2011 07:39 AM

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

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

ta0kira 08-19-2011 08:51 AM

Quote:

Originally Posted by ejspeiro (Post 4447166)
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

johnsfine 08-19-2011 09:08 AM

Quote:

Originally Posted by ta0kira (Post 4447724)
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 (Post 4447724)
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.

ta0kira 08-19-2011 09:41 AM

Quote:

Originally Posted by johnsfine (Post 4447744)
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

ejspeiro 08-19-2011 10:46 AM

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!

ejspeiro 08-19-2011 10:52 AM

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!

ejspeiro 09-01-2011 09:46 PM

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


All times are GMT -5. The time now is 12:50 AM.