Is there any C#/F# performance comparison available on web to show proper usage of new F# language?
+3
A:
Here are a few links on (or related to) this topic:
- http://cs.hubfs.net/forums/thread/3207.aspx
- http://strangelights.com/blog/archive/2007/06/17/1588.aspx
- http://khigia.wordpress.com/2008/03/30/ocaml-vs-f-for-big-integer-surprising-performance-test/
- http://cs.hubfs.net/blogs/f_team/archive/2006/08/15/506.aspx
- http://blogs.msdn.com/jomo_fisher/
What I seem to remember from another post on Robert Pickering's blog (or was it Scott Hanselman?) that in the end, because both are sitting on the same framework, you can get the same performance from both, but you sometimes have to 'twist' the natural expression of the language to do so. In the example I recall, he had to twist F# to get comparable performance with C#...
Benjol
2008-09-29 07:04:06
The converse is also true if you benefit from features unique to F#, such as `inline`.
Jon Harrop
2010-04-21 15:20:23
A:
Natural F# code is slower than natural C# code. However, natural F# is much shorter than natural C# code. My experience is to code in F# first and optimize only the parts that matter. It might be easier to write the slow functions in C# rather that to try to tweak F#. There are a number of features that contribute to slowness: references (vs. class instance variables), F# comparison (<=) vs. System.Collections.Generic.Comparer, tail calls, F# sequences are twice slower than LINQ. However, it makes sense to start in F# then profile, disassemble and optimize.
Stefan Savev
2010-01-02 22:01:34
Interesting points, but you'd need to check on more than just one runtime; with CLI 2, x86 and x64 had very different tail-call; it has obviously been beefed up in part due to supporting F#, but this may skew C# profiles.
Marc Gravell
2010-01-02 22:06:02
A:
Why bother coding in f# if it's slower? It just sounds like a pointless distraction to me. Microsoft Visual Studio has to bring in it's share of Microsoft revenue every 2-3 years. That means they have to come up with something meaty besides a few extra bells and whistles to make IT departments and programmers pull out their wallets for a the new version.
Why does every new MS language have to be slower than a previous language? When are they going to start moving in the other direction and come up with new languages that perform faster than previous ones?
pedrodems
2010-04-23 13:41:56
Although it might be "slower" people may still want to use it, it all depends on their needs. Besides, they can always get the express editions =D
Jamie Keeling
2010-04-23 13:45:04
.NET is slower than COM, COM is slower than C, C is slower than Assembly. Do you want to build Line of Business applications with Assembly just because Assembly is much faster than .NET? No!!!The performance alone will not be the reason to choose a language/framework, if the language/framework increases the level of abstraction and if performance is good enough with the current hardware then definitely it is worth considering it.F# increases the level of abstraction and also highly useful on multicore machines.
funwithcoding
2010-04-29 19:25:36
Performance is everything with mobile devices. If performance wasn't important, Apple wouldn't be using C for their iPhones. On the other hand, I suppose their is a market for languages with even higher level of abstraction than vb or c# for people who don't have much programming experience. I just hope Microsoft does not eventually make it impossible to write in unmanaged languages.
pedrodems
2010-07-26 14:58:34
.NET is only slower than COM when it has to deal with COM :-) or when people use consumer-grade convenience classes. It's a huge library and very easy to slip into classes that "do everything". If you are disciplined to stick to a few core classes, POCO-s, ints and arrays your perf in C# can soar to the sky, especially with judicial multi-threading. The reason why every new language turns out slower in some way is that no one wants to pay for development time, people and effort for exceptional new language and debuger. Mobile stuff has a memory problem which always kills perf.
ZXX
2010-10-13 04:04:16