3 ms·

If you're seeing significantly worse performance with F#, then that's pretty unusual (most people see very similar perf characteristics, with some things slight

by kvb 13y ago

If you're seeing significantly worse performance with F#, then that's pretty unusual (most people see very similar perf characteristics, with some things slightly faster in F# and some in C#). You might want to fire an email to fsbugs@microsoft.com explaining your scenario - the F# team is quite responsive. The RyuJIT project shows that .NET JIT performance is still on the radar, though I haven't seen any indication that SIMD is on the roadmap. To your final point, it's clearly true that C# is familiar to a wider variety of developers than F# is. However, I've been impressed by the uptake of some F# libraries, like FAKE. F# reads so mush like pseudocode in some cases that it's easy for people to buy in even if they're not especially familiar with the language.

kevingadd 13y ago
Glad to hear it. The main problem I noticed the last time I used F# is that it generates more function calls, along with more heap references (vs stack-allocated structs) for things like boxed values, generators, etc to do simple tasks compared with C#. Is it the case that you can optimize all this out using parts of the language I don't know about?
- kvb 13y ago
  F# supports value types just like C# does, so I wouldn't expect more boxing on the F# side. Some types like tuples that are used more in F# than in C# are reference types, so you might want to avoid them in your inner loops, but that generally just means writing F# that looks a bit more like C#. Likewise, as to the number of function calls, it's probably a question of style more than features, though you can do things like use the `inline` keyword to make sure that particular functions always get inlined at call sites, which can be a big win in some cases (it also allows you to write type-safe generic math code, which is an oft-lamented unsupported scenario in C#). Lots of people are making good use of F# in contexts where heavy computational requirements exist (e.g. finance or scientific computing), but I'm not too familiar with projects using it where more real-time requirements exist (though I think someone's in the midst of porting Quake III to F#, so it'll be interesting to see how that goes).

by kvb 13y ago

kevingadd 13y ago

Glad to hear it. The main problem I noticed the last time I used F# is that it generates more function calls, along with more heap references (vs stack-allocated structs) for things like boxed values, generators, etc to do simple tasks compared with C#. Is it the case that you can optimize all this out using parts of the language I don't know about?

kvb 13y ago
F# supports value types just like C# does, so I wouldn't expect more boxing on the F# side. Some types like tuples that are used more in F# than in C# are reference types, so you might want to avoid them in your inner loops, but that generally just means writing F# that looks a bit more like C#. Likewise, as to the number of function calls, it's probably a question of style more than features, though you can do things like use the `inline` keyword to make sure that particular functions always get inlined at call sites, which can be a big win in some cases (it also allows you to write type-safe generic math code, which is an oft-lamented unsupported scenario in C#). Lots of people are making good use of F# in contexts where heavy computational requirements exist (e.g. finance or scientific computing), but I'm not too familiar with projects using it where more real-time requirements exist (though I think someone's in the midst of porting Quake III to F#, so it'll be interesting to see how that goes).