I am confused and would appreciate if you enlighten me. F# uses same CLR as C# and underlying code is identical then how can one suggest that a function runs faster when written in F# than C#? If I use only immutable variables in C# and performance needs to be as high as possible then why use F#?
C# – F# and C# ‘s CLR is same then why is F# faster than C#
\clr%fc
Related Solutions
When you want to treat lambda expressions as expression trees and look inside them instead of executing them. For example, LINQ to SQL gets the expression and converts it to the equivalent SQL statement and submits it to server (rather than executing the lambda).
Conceptually, Expression<Func<T>> is completely different from Func<T>. Func<T> denotes a delegate which is pretty much a pointer to a method and Expression<Func<T>> denotes a tree data structure for a lambda expression. This tree structure describes what a lambda expression does rather than doing the actual thing. It basically holds data about the composition of expressions, variables, method calls, ... (for example it holds information such as this lambda is some constant + some parameter). You can use this description to convert it to an actual method (with Expression.Compile) or do other stuff (like the LINQ to SQL example) with it. The act of treating lambdas as anonymous methods and expression trees is purely a compile time thing.
Func<int> myFunc = () => 10; // similar to: int myAnonMethod() { return 10; }
will effectively compile to an IL method that gets nothing and returns 10.
Expression<Func<int>> myExpression = () => 10;
will be converted to a data structure that describes an expression that gets no parameters and returns the value 10:
larger imageWhile they both look the same at compile time, what the compiler generates is totally different.
One of the Roslyn engineers who specializes in understanding optimization of stack usage took a look at this and reports to me that there seems to be a problem in the interaction between the way the C# compiler generates local variable stores and the way the JIT compiler does register scheduling in the corresponding x86 code. The result is suboptimal code generation on the loads and stores of the locals.
For some reason unclear to all of us, the problematic code generation path is avoided when the JITter knows that the block is in a try-protected region.
This is pretty weird. We'll follow up with the JITter team and see whether we can get a bug entered so that they can fix this.
Also, we are working on improvements for Roslyn to the C# and VB compilers' algorithms for determining when locals can be made "ephemeral" -- that is, just pushed and popped on the stack, rather than allocated a specific location on the stack for the duration of the activation. We believe that the JITter will be able to do a better job of register allocation and whatnot if we give it better hints about when locals can be made "dead" earlier.
Thanks for bringing this to our attention, and apologies for the odd behaviour.
Best Answer
underlying code is identical? Doubtful. In general, F# will be faster in some things and slower in others. The same is true of C#. Or even VB. Each language has its pluses. If there is an overall performance plus in most areas, it is in the compiler.
If I use only immutable variables in C# and performance needs to be as high as possible then why use F#? No reason to switch for performance alone, if in fact there is a real difference, unless perf is your problem. As far as why switch if you are only using features that are fine in C#, I would say "don't switch".
I like F#. There are some "problems" it solves much better than C#. But, even if I have a problem it solves better, I am not necessarily switching, as I have to consider the developers in the mix. Currently, I know of few in this organization that know anything about F#, so I would have to make a good business case to switch.
Ultimately, you have to look at the "business problem" and determine a path. You have to consider the "better" language as part of the mix, but you also have to examine core competency, etc.