tags:

views:

738

answers:

7

Does anyone know how well F# measures with regards to performance, compared to C#. I have a C# raytracer with a lot of vector manipulations, ray-collission algorithms etc. and throught they might be more easily expressed in F#. I'm not asking for how well F# is at expressing math problems, something which has been answered here, but rather if I should expect better or worse performance? As raytracing is very performance intensive, even small cases of poor performance can be a problem in the wrong places.

Edit:

It seems that there are already a lot of questions on the subject that I couldn't find (there are no results if you actually search for anything with the term 'F#'). One good point here was the following answer:

F# provides some performance-related features that can make a difference.

Firstly, the implementation of delegates on .NET is currently quite inefficient and, consequently, F# uses its own FastFunc type for high-performance first-class functions.

Secondly, F# uses .NET metadata to convey inline functions so that they can be exported across APIs and, of course, that can dramatically improve performance in certain circumstances.

Finally, pattern matching can be extremely laborious to express in C# because the language lacks pattern matching but it is almost impossible to maintain optimized C# code equivalent to many non-trivial pattern matches. In contrast, the F# compiler aggressively optimizes pattern matches during compilation.

Conversely, the C# compiler is better at optimizing loops using IEnumerables and is better at optimizing computations over value types (e.g. complex arithmetic).

Cheers, Jon Harrop.

+2  A: 

F# will behave the same as C# for calculations (since it is all just IL). Just sure to represent your vector as a struct - since you will be constructing many of those objects which are short lived.

Units of measure has zero impact on performance, in fact at compile time the units of measure information is removed entirely. So you actually cannot tell that your F# code has units of measure on it.

Chris Smith
+2  A: 

In fact, in theory, an x86 machine can only execute x86 assembly which is of an imperative nature, therefore, theoretically it's possible to achieve the performance of a functional language imperatively. So you can write C# programs that are equal or better than their F# counterparts. The keyword here is can. It doesn't mean all C# programs are better than F# programs or anything like that. Generally, F# performance is very acceptable in most problems. There are some cases where F# performance lags too much behind C#, but generally, it's OK for most applications. However, if you want to have fine-grained control on what your code actually does, functional languages are not for you. You have more optimization opportunity in C# than you have in F#. By the way, by F#, I don't mean writing imperative code, but normal functional approach (if you want to write code imperatively, I don't think F# makes much sense).

Mehrdad Afshari
In theory you are right, in practice F# has better performance than C# due to much more aggressive optimizations, F# simply outputs better IL, sometimes much better.
Pop Catalin
In practice, results are heavily dependent on what you are writing. There are both cases where F# is better and cases where it lags *far* behind. By the way, my comparison was more about "Functional F#" and "C#". Some problems cannot be efficiently expressed as a composition of functions.
Mehrdad Afshari
A: 

My initial reaction is that the performance will be the same due to both C# and F# outputting MSIL. But the structures you use might turn out different IL. The topic has been discussed in detail at the links here on SO.

olle
A: 

F#'s performance is about the same as C#'s they are both compiled to IL which is the important factor (unlike IronPython and IronRuby which are interpreted and therefore much slower). The performance of an algorithm depends much more on it's implementation than on the choice of F# or C#, as F# would help implement it in few lines of code you have much better chance of spotting optimisations in F# than in C#.

Also this article has a similar take on the perf issue: http://diditwith.net/2008/04/03/ApplesAndOranges.aspx

Robert
+1  A: 

Maybe you already know, but maybe not.

Google on the name "Luke Hoban", he has made a ray tracer with C# 3.0 and now works in Microsofts F# team.

See also: http://blogs.msdn.com/lukeh/ and http://blogs.msdn.com/lukeh/archive/2007/04/03/a-ray-tracer-in-c-3-0.aspx .

He should know.

tuinstoel
He admits himself that the raytracer is not efficient, he seems to do it more as an exercise rather than to create a good raytracer.
Morten Christiansen
Maybe you can mail him and ask your question?
tuinstoel
Yeah, I might just do that.
Morten Christiansen
Yes, that raytracer is not very efficient, but it's a good experiment for of Linq.
Joan Venge
A: 

F# is better suited for parallel programming. So out-of-the box it can be faster as C# (on multi-cores/cpu).

But then again, you can optimize C# to use this as wel, but it will be a lot more work.

GvS
+4  A: 

Yes, F# will perform better.

Here are some performance results for a single-thread algorithm implemented in different languages (benchmarking activation function approaches for the neural networks):

C#:

10^7 iterations using Sigmoid1() took 3899,1979 ms
10^7 iterations using Sigmoid2() took 411,4441 ms

Pure C:

10^7 iterations using sigmoid1: 628 ms
10^7 iterations using sigmoid2: 157 ms

F#:

10^7 iterations using sigmoid1: 588.843700 ms
10^7 iterations using sigmoid2: 156.626700 ms

More details

Rinat Abdullin
Amazing :) F# is faster than pure C. Very Nice find! I knew F# often was faster than C# but being faster than C is simply amazing ...
Pop Catalin
Yep, surprised me as well. However, I've not been using the latest C compiler, so it yet may outperform F# slightly))
Rinat Abdullin