8 ms·

One day, Rust needs a GC. Reference counting is a just crappy GC. Modern GC can perform better than this so Rust is actually hurting its own performance by not

One day, Rust needs a GC. Reference counting is a just crappy GC. Modern GC can perform better than this so Rust is actually hurting its own performance by not having one. A good GC would make heavily concurrent apps much easier to build with Rust. And would have better performance than the typical Arc Mutex objects passed around right now

_flux 5y ago
Tracing GC is troublesome for any non-memory resource, such as network connection or file handle, due to its untimely release, but otherwise I actually agree: reference counting is a GC mechanism—not a very good one, but it's the only one I'm aware of that works both for memory and resources. I would enjoy someone test a model where the type system guarantees (or at least lets you detect the situation) that you cannot store such non-memory objects behind a traced GC node (these would include plain memory objects that need to be registered/unregistered precisely). It might be that it would be needlessly annoying to use just compared to just RC. Or maybe it would be best of both worlds?
- pjmlp 5y ago
  Not when the language also supports value types and region allocators (e.g. IDispose in .NET). You can even turn it into RAII proper, by turning into a compilation error not handling those interfaces properly. Again with .NET, there are SafeHandles as well, alongside the MarshalInterop APIs. This is nothing new actually, Mesa/Cedar for Xerox PARC used reference counting with a cycle collector, while other descendent languages down to Modula-3 and Active Oberon always combined value types, tracing GC and C++ like resource handling capabilities. Oh Common Lisp also has similar capabilities, specially the ZetaLisp predecessor from Lisp Machines. Then Eiffel not only had this, it was also probably the first Algol like language to support non nullable references. Sadly they decided to ignore all of this in Java, and then its world domination kind of made everyone else ignore it as well. Thankfully even Java is improving their story in this regard, while languages like D, Nim and yes .NET kind of show what was already available for several decades.
  - _flux 5y ago
    I must be missing something. How is it possible to precisely collect a resource with tracing GC? And if you need to update counters when you make duplicates of object references, you are not using a tracing GC where the benefits are the cheap duplication of object references, cheap allocations and cheap (batched) releases, but the downside is not being able to precisely and automatically do it when the value is available for collection. Seems to me it is impossible to have both automatic precise release of a resources and collection-based GC? As I understand it, even the documentation for IDisposable in .NET says as much at https://docs.microsoft.com/en-us/dotnet/api/system.idisposable?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.idisposab...: > The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams. > Use the Dispose method of this interface to explicitly release unmanaged resources in conjunction with the garbage collector. The consumer of an object can call this method when the object is no longer needed. So this is the interface you can use to explicitly release a resource, because the GC gets around to it only later at some unspecified time. About SafeHandle it says at https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.safehandle?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.i...: > The SafeHandle class provides critical finalization of handle resources, preventing handles from being reclaimed prematurely by garbage collection and from being recycled by Windows to reference unintended unmanaged objects. Doesn't seem it's at all helpful for automatic precise release of resources.
    - zozbot234 5y ago
      > the benefits are the cheap duplication of object references, cheap allocations and cheap (batched) releases, but the downside is not being able to precisely and automatically do it when the value is available for collection. Note that you don't need GC to reap these benefits, if desired. You can allocate an arena and do secondary allocations inside it, then deallocate everything in a single operation. Arena deallocation is not timely or precise, but it does happen deterministically.
astrange 5y ago
Tracing GC has poor memory performance because it has to access rarely used or swapped out pages to scan them for pointers. And of course, the peak memory use is much higher since it doesn't free everything as soon as possible. There may be advantages if you can use it to add compaction, but I don't think you need a GC to do that necessarily.
- pjmlp 5y ago
  Actually it is the other way around. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages No wonder that M1 has specific architecture optimizations that help streamline ARC boilerplate code, while Swift 5.5 will bring more aggressive optimizations (disabled by default, because application can crash if weak/owned references are annotated improperly => WWDC 2021 talk)
  - astrange 5y ago
    This isn't representative of application code and there isn't even any mention of the metrics I mentioned… > No wonder that M1 has specific architecture optimizations that help streamline ARC boilerplate code No it doesn't. I told you it didn't the last time you said this.
    - pjmlp 5y ago
      > This isn't representative of application code and there isn't even any mention of the metrics I mentioned… Yeah, that is the usual answer when benchmarks prove how much urban myth reference counting performance is actually like. > No it doesn't. I told you it didn't the last time you said this. Did you? There is more important stuff in life to store on my brain than a list of who replies to me on hacker news. Anyway, https://github.com/apple/swift/blob/main/stdlib/public/SwiftShims/RefCount.h https://github.com/apple/swift/blob/main/stdlib/public/Swift... https://twitter.com/ErrataRob/status/1331735383193903104 https://twitter.com/ErrataRob/status/1331735383193903104
      - astrange 5y ago
mhh__ 5y ago
I would need some data on that but I have to say that it always makes me laugh when people only take about the GC in threads about D. It's so good for productivity. I don't really like it but I can't describe just how much of a non-issue it is for us (The company I work for)

_flux 5y ago

Tracing GC is troublesome for any non-memory resource, such as network connection or file handle, due to its untimely release, but otherwise I actually agree: reference counting is a GC mechanism—not a very good one, but it's the only one I'm aware of that works both for memory and resources. I would enjoy someone test a model where the type system guarantees (or at least lets you detect the situation) that you cannot store such non-memory objects behind a traced GC node (these would include plain memory objects that need to be registered/unregistered precisely). It might be that it would be needlessly annoying to use just compared to just RC. Or maybe it would be best of both worlds?

pjmlp 5y ago
Not when the language also supports value types and region allocators (e.g. IDispose in .NET). You can even turn it into RAII proper, by turning into a compilation error not handling those interfaces properly. Again with .NET, there are SafeHandles as well, alongside the MarshalInterop APIs. This is nothing new actually, Mesa/Cedar for Xerox PARC used reference counting with a cycle collector, while other descendent languages down to Modula-3 and Active Oberon always combined value types, tracing GC and C++ like resource handling capabilities. Oh Common Lisp also has similar capabilities, specially the ZetaLisp predecessor from Lisp Machines. Then Eiffel not only had this, it was also probably the first Algol like language to support non nullable references. Sadly they decided to ignore all of this in Java, and then its world domination kind of made everyone else ignore it as well. Thankfully even Java is improving their story in this regard, while languages like D, Nim and yes .NET kind of show what was already available for several decades.
- _flux 5y ago
  I must be missing something. How is it possible to precisely collect a resource with tracing GC? And if you need to update counters when you make duplicates of object references, you are not using a tracing GC where the benefits are the cheap duplication of object references, cheap allocations and cheap (batched) releases, but the downside is not being able to precisely and automatically do it when the value is available for collection. Seems to me it is impossible to have both automatic precise release of a resources and collection-based GC? As I understand it, even the documentation for IDisposable in .NET says as much at https://docs.microsoft.com/en-us/dotnet/api/system.idisposable?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.idisposab...: > The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams. > Use the Dispose method of this interface to explicitly release unmanaged resources in conjunction with the garbage collector. The consumer of an object can call this method when the object is no longer needed. So this is the interface you can use to explicitly release a resource, because the GC gets around to it only later at some unspecified time. About SafeHandle it says at https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.safehandle?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.i...: > The SafeHandle class provides critical finalization of handle resources, preventing handles from being reclaimed prematurely by garbage collection and from being recycled by Windows to reference unintended unmanaged objects. Doesn't seem it's at all helpful for automatic precise release of resources.
  - zozbot234 5y ago
    > the benefits are the cheap duplication of object references, cheap allocations and cheap (batched) releases, but the downside is not being able to precisely and automatically do it when the value is available for collection. Note that you don't need GC to reap these benefits, if desired. You can allocate an arena and do secondary allocations inside it, then deallocate everything in a single operation. Arena deallocation is not timely or precise, but it does happen deterministically.

astrange 5y ago

Tracing GC has poor memory performance because it has to access rarely used or swapped out pages to scan them for pointers. And of course, the peak memory use is much higher since it doesn't free everything as soon as possible. There may be advantages if you can use it to add compaction, but I don't think you need a GC to do that necessarily.

pjmlp 5y ago
Actually it is the other way around. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages No wonder that M1 has specific architecture optimizations that help streamline ARC boilerplate code, while Swift 5.5 will bring more aggressive optimizations (disabled by default, because application can crash if weak/owned references are annotated improperly => WWDC 2021 talk)
- astrange 5y ago
  This isn't representative of application code and there isn't even any mention of the metrics I mentioned… > No wonder that M1 has specific architecture optimizations that help streamline ARC boilerplate code No it doesn't. I told you it didn't the last time you said this.
  - pjmlp 5y ago
    > This isn't representative of application code and there isn't even any mention of the metrics I mentioned… Yeah, that is the usual answer when benchmarks prove how much urban myth reference counting performance is actually like. > No it doesn't. I told you it didn't the last time you said this. Did you? There is more important stuff in life to store on my brain than a list of who replies to me on hacker news. Anyway, https://github.com/apple/swift/blob/main/stdlib/public/SwiftShims/RefCount.h https://github.com/apple/swift/blob/main/stdlib/public/Swift... https://twitter.com/ErrataRob/status/1331735383193903104 https://twitter.com/ErrataRob/status/1331735383193903104
    - astrange 5y ago

mhh__ 5y ago

I would need some data on that but I have to say that it always makes me laugh when people only take about the GC in threads about D. It's so good for productivity. I don't really like it but I can't describe just how much of a non-issue it is for us (The company I work for)