8 ms·

.NET is also regularly improving their GC, aren’t they?

by Semaphor 5y ago

DougBTX 5y ago
Also notably Go, though really all GC languages which care about performance, of which there are quite a few.
- the8472 5y ago
  Go isn't playing in the same league though since their GC is non-generational and non-compacting. A lot of the difficulties implementing concurrent GCs comes from moving things between generations and compacting.
  - DougBTX 5y ago
    I had this benchmark[0] in mind while writing the comment, though perhaps Go does well there by avoiding GC rather than having fast GC as-such? That would explain why its performance is close to the non-GC languages. [0] https://awesomeopensource.com/project/ixy-languages/ixy-languages https://awesomeopensource.com/project/ixy-languages/ixy-lang...
    - throwaway894345 5y ago
      Without digging into that benchmark, Go leans on stack allocation a lot more than many GC languages, and that’s a big part of why Go is able to achieve otherwise impressive performance. The same mechanism (idiomatic value types) that allows Go to elide GC in many cases also permits better cache coherency—there are fewer pointers into random regions of the heap so cache lines need to be flushed less frequently.
  - stingraycharles 5y ago
    Is that a good or bad thing? What’s the trade-off being made here?
    - 5e92cb50239222b 5y ago
      https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
      - vips7L 5y ago
        That article is beyond out of date when it comes to Java GC.
    - throwaway894345 5y ago
      Compacting GC tends to have cheaper allocs and longer pauses (allocs need to be moved to different regions of memory and pointers to those allocs need to be rewritten to point to the new memory regions) while noncompacting has the opposite: slow allocations and small pause times.
      - kaba0 5y ago
        Though many part of compaction can be moved to a parallel thread, can’t it? The actual stop-the-world time can be quite small that way (using read-barriers though)
        throwaway894345 5y ago
        I’m not so sure about barriers, but compacting requires rewriting pointers that are shared with the mutator threads, so it seems hard to parallelize.
        kaba0 5y ago
        As far as I know, this is the “secret” of ZGC at least, it replaces the usual write barriers with read ones. So a parallel thread is free to move an object to a new place, and any thread trying to access it will at that point lock said object. This will have a performance impact (the usual write barriers have better throughput because they only “lock” when writing an object), but more of the GC can be parallelized. But I’m by no means anywhere close to an expert in the topic.
  - isbvhodnvemrwvn 5y ago
    Shenandoah is also not generational, at least the implementation I looked at a year ago wasn't.
    - the8472 5y ago
      It's region-based, the regions serve a similar purpose to generations but in a more granular fashion.
  - Thaxll 5y ago
    The problem is that there is not benchmark for GC, but from my experience the Go GC is very good, aka sub 1ms.
    - SureshG 5y ago
      Is this the case very large go heaps? ZGC claims sub ms pause for TB heap size.
pjmlp 5y ago
Not only the GC, since version 7, most of the Midori stuff has been landing on C# (and to some extent F#), turning into a kind of "Managed C++". Contrary to the WebAssembly speech, CLR was one of the very first VMs to have support for C like languages, but those capabilities were only fully surfaced to the original Managed C++ (.NET 1.0) and C++/CLI (2.0 onwards). So now those capabilities are being exposed into C# as well. For example stack allocation of arrays is now also valid in safe contexts. You can apply using to any type that has Dispose() without inheriting from IDispose. Memory slices are now also a thing and native function pointers for example.
- kinjba11 5y ago
  > apply using to any type that has Dispose() without inheriting from IDisposable Last I saw, this was still being debated by the LDT and weighed against similar proposals such as introducing a `defer` keyword like Swift/Go.
  - pjmlp 5y ago
    You can use it today on C# 9.
    - kinjba11 5y ago
      Can you link to any documentation/examples?
da_chicken 5y ago
Yes, although I'd say that .NET is still a little tied up with how fractured their environment is. There is a lot of tech debt sunk into the .Net Framework, and it'll be awhile before it really gets flushed away.
- Semaphor 5y ago
  > There is a lot of tech debt sunk into the .Net Framework I’m working on a website that has been growing since 1996… The chances of us ever migrating to .NET 5 and onwards is basically zero.

.NET is also regularly improving their GC, aren’t they?

DougBTX 5y ago

Also notably Go, though really all GC languages which care about performance, of which there are quite a few.

the8472 5y ago
Go isn't playing in the same league though since their GC is non-generational and non-compacting. A lot of the difficulties implementing concurrent GCs comes from moving things between generations and compacting.
- DougBTX 5y ago
  I had this benchmark[0] in mind while writing the comment, though perhaps Go does well there by avoiding GC rather than having fast GC as-such? That would explain why its performance is close to the non-GC languages. [0] https://awesomeopensource.com/project/ixy-languages/ixy-languages https://awesomeopensource.com/project/ixy-languages/ixy-lang...
  - throwaway894345 5y ago
    Without digging into that benchmark, Go leans on stack allocation a lot more than many GC languages, and that’s a big part of why Go is able to achieve otherwise impressive performance. The same mechanism (idiomatic value types) that allows Go to elide GC in many cases also permits better cache coherency—there are fewer pointers into random regions of the heap so cache lines need to be flushed less frequently.
- stingraycharles 5y ago
  Is that a good or bad thing? What’s the trade-off being made here?
  - 5e92cb50239222b 5y ago
    https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
    - vips7L 5y ago
      That article is beyond out of date when it comes to Java GC.
  - throwaway894345 5y ago
    Compacting GC tends to have cheaper allocs and longer pauses (allocs need to be moved to different regions of memory and pointers to those allocs need to be rewritten to point to the new memory regions) while noncompacting has the opposite: slow allocations and small pause times.
    - kaba0 5y ago
      Though many part of compaction can be moved to a parallel thread, can’t it? The actual stop-the-world time can be quite small that way (using read-barriers though)
      - throwaway894345 5y ago
        I’m not so sure about barriers, but compacting requires rewriting pointers that are shared with the mutator threads, so it seems hard to parallelize.
        kaba0 5y ago
        As far as I know, this is the “secret” of ZGC at least, it replaces the usual write barriers with read ones. So a parallel thread is free to move an object to a new place, and any thread trying to access it will at that point lock said object. This will have a performance impact (the usual write barriers have better throughput because they only “lock” when writing an object), but more of the GC can be parallelized. But I’m by no means anywhere close to an expert in the topic.
- isbvhodnvemrwvn 5y ago
  Shenandoah is also not generational, at least the implementation I looked at a year ago wasn't.
  - the8472 5y ago
    It's region-based, the regions serve a similar purpose to generations but in a more granular fashion.
- Thaxll 5y ago
  The problem is that there is not benchmark for GC, but from my experience the Go GC is very good, aka sub 1ms.
  - SureshG 5y ago
    Is this the case very large go heaps? ZGC claims sub ms pause for TB heap size.

pjmlp 5y ago

Not only the GC, since version 7, most of the Midori stuff has been landing on C# (and to some extent F#), turning into a kind of "Managed C++". Contrary to the WebAssembly speech, CLR was one of the very first VMs to have support for C like languages, but those capabilities were only fully surfaced to the original Managed C++ (.NET 1.0) and C++/CLI (2.0 onwards). So now those capabilities are being exposed into C# as well. For example stack allocation of arrays is now also valid in safe contexts. You can apply using to any type that has Dispose() without inheriting from IDispose. Memory slices are now also a thing and native function pointers for example.

kinjba11 5y ago
> apply using to any type that has Dispose() without inheriting from IDisposable Last I saw, this was still being debated by the LDT and weighed against similar proposals such as introducing a `defer` keyword like Swift/Go.
- pjmlp 5y ago
  You can use it today on C# 9.
  - kinjba11 5y ago
    Can you link to any documentation/examples?

da_chicken 5y ago

Yes, although I'd say that .NET is still a little tied up with how fractured their environment is. There is a lot of tech debt sunk into the .Net Framework, and it'll be awhile before it really gets flushed away.

Semaphor 5y ago
> There is a lot of tech debt sunk into the .Net Framework I’m working on a website that has been growing since 1996… The chances of us ever migrating to .NET 5 and onwards is basically zero.