views:

789

answers:

9

I would like to preface this with I'm not trying to start a fight. I was wondering if anyone had any good resources that compared C++ and C# for mathematically intensive code? My gut impression is that C# should be significantly slower, but I really have no evidence for this feeling. I was wondering if anyone here has ever run across a study or tested this themselves? I plan on running some tests myself, but would like to know if anyone has done this in a rigorous manner (google shows very little). Thanks.

EDIT: For intensive, I mean a lot of sin/cos/exp happening in tight loops

+7  A: 

C# will be slower in general, but not significantly so. In some cases, depending on the structure of the code, C# can actually be faster, as JIT analysis can frequently improve the performance of a long-running algorithm.

Edit: Here's a nice discussion of C# vs C++ performance

Edit 2:

"In general" is not really accurate. As you say, the JIT compiler can actually turn your MSIL into faster native code that the C++ compiler because it can optimize for the hardware it is running on.

You must admit, however, that the act of JIT compiling itself is resource intensive, and there are runtime checks that occur in managed code. Pre-compiled and pre-optimized code will always be faster than just JITted code. Every benchmark comparison shows it. But long-running processes that can have a fair amount of runtime analysis can be improved over pre-compiled, pre-optimized native code.

So what I said was 100% accurate. For the general case, managed code is slightly slower than pre-compiled, pre-optimized code. It's not always a significant performance hit, however, and for some cases JIT analysis can improve performance over pre-optimized native code.

Randolpho
"In general" is not really accurate. As you say, the JIT compiler can actually turn your MSIL into faster native code that the C++ compiler because it can optimize for the hardware it is running on.
Ed Swangren
Of course, there is going to be some penalty due to runtime checks... so perhaps "In general" wasn't misleading :)
Ed Swangren
"Pre-compiled and pre-optimized code will always be faster than just JITted code" - This is false. JITs have access to dynamic information that a static compiler does not. It can use this information to perform [i]dynamic[/i] optimizations. Something a static compiler can not do.
Falaina
Oh, actually you metnion "for some cases JIT analysis can improve performance over pre-optimized native code." which I do agree with :) It's just your earlier quote (which I mentioned above) seems to conflict with this.
Falaina
@Falaina: What you quoted is 100% accurate. Read it again. But what you said wrote afterward **is also** accurate, and if you read further into my post, I acknowledge it. JITters have access to runtime analysis that can improve performance. But only after runtime analysis, and only if the assembly stays loaded and/or runs continuously. If you have, for example, a small command line program that computes a quick computation, C++ wins, every time. If you do the Fibonacci Sequence on a server, however, a well-coded C# program can outperform C++.
Randolpho
Heh... looks like we cross-posted. Ignore the "read it again" snark. Also ignore the "said wrote" part -- I wrote "said" and decided to change it to "wrote" but failed. :)
Randolpho
I do admit, that is why I left the second comment :)
Ed Swangren
Yeah, I didn't notice your comments until I had done the edit. I type too slowly, I guess. Or too much. :)
Randolpho
I don't think runtime checks apply to any mathematical stuff, aside from bounds checks with matrix multiplication or other array stuff (which can be avoided entirely with unsafe code).
JulianR
Vitali
I would argue that it would always be faster in C++ (or faster in fortran). The reason being if you are doing a highly computational intensive task that is going to take a long long time then you have already experimented and found the appropriate compiler settings to optimize the code for the specific hardware you are using. Of course that's what the JIT is doing automatically at runtime and it the C++ programmer gets the flags wrong then C Sharp will win. But if you want really fast then use fortran its still a decade ahead on optimization for numerical applications.
Martin York
@Martin York: Optimizing C++ is less about compiler switches/flags and more about the compiler's capability and the structure of the code. The compiler can only interpret certain blocks of codes in certain ways; a poorly structured loop, for example, is unlikely to be unrolled by the compiler. Inlining is not guaranteed, even with hints. JIT analysis, on the other hand, can look at the history of a loop execution and modify the compilation to unroll it, or choose to inline larger methods than might have been inlined by the compiler. Will this always work? No. But the possibility *is* there.
Randolpho
+5  A: 

For straight mathematical functions asking if C# is faster than C++ is not the best question. What you should be asking

Is the assembly produced by the CLR JITer more or less efficient than assembly generated by the C++ compiler

The C# compiler has much less influence on the speed of purely mathmatical operations than the CLR JIT does. It would have almost identical performance as other .Net languages (such as VB.Net if you turn off overflow checing).

JaredPar
+5  A: 

There are extensive benchmarks here:

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=csharp&lang2=gpp&box=1

Note this compares the Mono JIT to C++. AFIAK there are no extensive benchmarks of Microsoft's implementation out there, so almost everything you will hear is hearsay. :(

joemoe
no extensive benchmarks of Microsoft's @ iirc the license doesn't allow publication of benchmarks.
igouy
+2  A: 

I would consider using Mono.Simd to accelerate some operations. The minus is that on MS runtime it's not accelerated.

Yakeen
+5  A: 

I think you're asking the wrong question. You should be asking if C++ on can beat out the .NET family of languages in mathematical computation. Have a gander at F# timing comparisons for Runge Kutta

wheaties
Yes, that is what I meant, I understand that all .NET languages go to IL and then to machine code
Steve
+1 for using the right language for the job. Great evidence in the link.
Austin Salonen
For what it's worth, it appears that F# can not only easily translate into parallel processes but also can optimize repetitious tasks such as what you see in that link. I'd say it's not as wonder as the link makes it out to appear but it's pretty darn exciting to see done on an interpretted language.
wheaties
+2  A: 
Jerry Coffin
Well, its not premature if its a 2x slowdown for mathematically complex code. That's avoiding a time trap
Steve
Does not address the question at all, -1
Ed Swangren
Jerry, do you have a link to that restriction (or discussions about it) ?
Henk Holterman
Ed, it addresses the question (are there any studies...) **very well**.
Henk Holterman
+4  A: 

You do not define "mathematically intensive" very well (understatement for: not at all).

An attempt to a breakdown:

  • For the basic Sin/Cos/Log functions I would not expect much difference.

  • For linear algebra (matrices) I would expect .NET to loose out, the (always enforced) bounds checking on arrays is only optimized away under some circumstances.

You will probably have to benchmark something close to your intended domain.

Henk Holterman
+1  A: 

For basic math library functions there won't be much difference because C# will call out to the same compiled code that C++ would use. For more interesting math that you won't find in the math library there are several factors that make C# worse. The Current JIT doesn't support SSE instructions that you would have access to in C++.

stonemetal
+6  A: 
Crashworks
Thanks, that was what I was looking for!
Steve
Glad to help, but please remember that I'm citing a specific case here -- one particular kind of linear algebra, where I'm comparing C#' JIT output to my carefully hand-optimized-and-almost-assembly C++.
Crashworks