4 ms·

When tail latency (high-percentile latency) is important GC is not a good choice. Wait-free (threads progress independently) concurrent algorithms also need wai

When tail latency (high-percentile latency) is important GC is not a good choice. Wait-free (threads progress independently) concurrent algorithms also need wait-free memory reclamation with bounded memory usage to be able to guarantee progress. But most software are throughput-oriented.

pjmlp 5y ago
Additionally, not all GCs are made alike, and languages like D, F#, C#, Nim, Swift, among others, also offer value types and manual memory management, if desired.
- elcritch 5y ago
  Also Swift and Nim w/ ARC use reference counting, which generally give much better latency and lower memory overhead. Reference counting is part of the reason iOS devices don’t need as much RAM. Nim’s ARC system also doesn’t use atomic or locks which means it’s runtime overhead is very low. I use it successfully on embedded devices for microsecond timed events with no large tail latencies.
  - pjmlp 5y ago
    Reference counting is a GC algorithm. I wouldn't buy into much Apple marketing regarding its performance though, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages It makes sense in the context of tracing GC having been a failure in Objective-C due to its C semantics, while automating Cocoa's retain/release calls was much safer approach. Swift naturally built on top of that due to interoperability with Objective-C frameworks. Nim has taken other optimizations into consideration, however only in the new ORC implementation. Still, all of them are much better than managing memory manually.
    - elcritch 5y ago
      > I wouldn't buy into much Apple marketing regarding its performance though, I wouldn’t make claims on Swifts overall performance, but just it’s memory usage (really Obj-Cs) and particularly for GUI development. Java’s GCs have always been very memory hungry, usually to the tune of 2x. Same with .Net. Though to be fair Go’s and Erlang’s GCs have much better memory footprints. Erlang’s actor model benefits it there. Agreed, they’re all better than manual memory management.

pjmlp 5y ago

Additionally, not all GCs are made alike, and languages like D, F#, C#, Nim, Swift, among others, also offer value types and manual memory management, if desired.

elcritch 5y ago
Also Swift and Nim w/ ARC use reference counting, which generally give much better latency and lower memory overhead. Reference counting is part of the reason iOS devices don’t need as much RAM. Nim’s ARC system also doesn’t use atomic or locks which means it’s runtime overhead is very low. I use it successfully on embedded devices for microsecond timed events with no large tail latencies.
- pjmlp 5y ago
  Reference counting is a GC algorithm. I wouldn't buy into much Apple marketing regarding its performance though, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages It makes sense in the context of tracing GC having been a failure in Objective-C due to its C semantics, while automating Cocoa's retain/release calls was much safer approach. Swift naturally built on top of that due to interoperability with Objective-C frameworks. Nim has taken other optimizations into consideration, however only in the new ORC implementation. Still, all of them are much better than managing memory manually.
  - elcritch 5y ago
    > I wouldn't buy into much Apple marketing regarding its performance though, I wouldn’t make claims on Swifts overall performance, but just it’s memory usage (really Obj-Cs) and particularly for GUI development. Java’s GCs have always been very memory hungry, usually to the tune of 2x. Same with .Net. Though to be fair Go’s and Erlang’s GCs have much better memory footprints. Erlang’s actor model benefits it there. Agreed, they’re all better than manual memory management.