CODEWITHSUNDEEP
c#.netf#garbage-collection
MyBug18
MyBug18

Reputation: 2230

GC for interop between F# and C#

After doing some searching about functional language and garbage collection, I figured out that GC design for normal imperative language (like Java, C#) is pretty different to GC for functional language, like Haskell.

It was no surprise for me, because I'm aware of it that the only way to change the state of variable in functional language is to make new object based on previous one, and then destroy it, which would result significant amounts of garbages.

What I've got curious is, if dotnet project uses both C# and F#, then how will the GC work? I think that the code from F# will generate super many garbages, which would maybe hard to handle with normal GC of C#.

Upvotes: 0

Views: 325

Answers (2)

Phillip Carter
Phillip Carter

Reputation: 5005

The other parts of your question have been answered, so I'll focus on this one:

What I've got curious is, if dotnet project uses both C# and F#, then how will the GC work? I think that the code from F# will generate super many garbages, which would maybe hard to handle with normal GC of C#.

This is an interesting point to consider, but underlying this question are two assumptions:

  1. A typical F# program produces significantly more garbage than a typical C# program, so much so that it makes a noticeable difference
  2. The .NET GC struggles to handle the amount of garbage generated by typical F# programs

Both are actually untrue. You can certainly write atypical programs in both languages that will overwhelm the .NET GC - though you might find it a lot more difficult than you'd initially think - so it's more a question of how often you could unintentionally get into that position with F# compared with C#.

I don't think this point has been studied much. F# is used quite heavily in finance and analytical modeling domains, where resource utilization does matter. It is also increasingly used for web service and cloud development, where the amount of time spent in the GC for a long-running process matters. But there isn't much data to suggest either than F# is substandard for these scenarios when compared with C#, or that it performs just fine. My inclination is to say that it is adequate for these scenarios, judged solely on the number and type of bugs filed on the language.

Additionally, as of F# 4.5 there are increased capabilities for low-level, zero allocation programming with Span<'T>, byref-like structs, pointer types, and corresponding compiler analysis of programs that use them. These are also atypical for F# usage, but for performance-sensitive scenarios they make the language really shine. Take this as a grain of salt, but some of the benchmarks on the Language Benchmarks Game would indicate that performance is not much of a problem.

Upvotes: 3

Asti
Asti

Reputation: 12667

All .NET targeted languages eventually compile down to IL and are executed in the same runtime.

cli

The GC is an essential part of how managed languages work. However, garbage collection isn't necessarily much worse in a functional programming paradigm. Most objects are reclaimed in gen 0 and never make it to gen 1.

What you pay for in allocations you take back in thread-safety, parallelism and optimizations.

Of course, there's no rule that mutations are illegal. F# is a multi-paradigm language, and you can still write performant imperative code where required, and in fact, several core library functions are written this way.

let mutable sum = 0
for i in 0..9 do
    sum <- sum + i

Upvotes: 3

Related Questions