3 ms·

GCs are faster if you have 4 times the needed RAM. Most everyone in the industry doesn't care about wasting RAM.

pjmlp 6y ago
Nope, reference counting is a GC algorithm, and having a tracing GC doesn't preclude other forms of memory management, e.g. D or .NET Native.
- mpweiher 6y ago
  Mixing tracing GC with other forms of memory is an open research project. Doesn't mean it hasn't been "done", for example Google has talked about getting their GCs to interop in Chrome, but it's (a) really hard and (b) so far results are, at best, "mixed".
  - pjmlp 6y ago
    Let's see Swift when catches up with .NET 5 improvements. Apple's talk about RC over GC is just marketing speak for the failure to have a tracing GC in Objective-C that wouldn't crash left and right when integrated with C like code. It was a very sound decision given Cocoa semantics, and the difficulty to make anything written in C not to fall apart with segfaults, but lets not oversell it. Likewise Swift RC makes sense from having to integrate with Objective-C runtime and existing ecosystem, but again that is all about it. There is no RC implementation with comparable performance to tracing GC languages that isn't just yet another tracing GC from the amount of runtime support needed to make it actually fast.
    - mpweiher 6y ago
      So we are agreed that mixing tracing GCs with any other form of memory management (including another GC) is an unsolved problem. Good. Swift is a disaster, also agreed. So? For the rest: actual research disagrees with your forceful but unsubstantiated assertion: https://2013.splashcon.org/details/oopsla-2013-papers/21/Taking-Off-the-Gloves-with-Reference-Counting-Immix https://2013.splashcon.org/details/oopsla-2013-papers/21/Tak... And once again, tracing GCs do well in microbenchmarks where you only check the cost of local operations. They are horrible when you take the global effects into account, with those local/benchmarking advantages not translating into real world use. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf Very similar to JITs, which also do massively better in microbenchmarks than in production code: http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html Oh, and integrating well and without high cost to fast languages where you have even more control is actually an important feature.
      - pjmlp 6y ago
        No we don't agree, unless you can make a point on how D, Active Oberon, Go, Modula-3, Eiffel, .NET, Nim, among several others, integration of tracing GC alongside stack, global and off heap memory allocation happens to be a research project.
        mpweiher 6y ago
        Those aren't actually integrated. They just live side-by-side.
        pjmlp 6y ago
        It is definlty integrated for the users of those languages.

Nope, reference counting is a GC algorithm, and having a tracing GC doesn't preclude other forms of memory management, e.g. D or .NET Native.

mpweiher 6y ago
Mixing tracing GC with other forms of memory is an open research project. Doesn't mean it hasn't been "done", for example Google has talked about getting their GCs to interop in Chrome, but it's (a) really hard and (b) so far results are, at best, "mixed".
- pjmlp 6y ago
  Let's see Swift when catches up with .NET 5 improvements. Apple's talk about RC over GC is just marketing speak for the failure to have a tracing GC in Objective-C that wouldn't crash left and right when integrated with C like code. It was a very sound decision given Cocoa semantics, and the difficulty to make anything written in C not to fall apart with segfaults, but lets not oversell it. Likewise Swift RC makes sense from having to integrate with Objective-C runtime and existing ecosystem, but again that is all about it. There is no RC implementation with comparable performance to tracing GC languages that isn't just yet another tracing GC from the amount of runtime support needed to make it actually fast.
  - mpweiher 6y ago
    So we are agreed that mixing tracing GCs with any other form of memory management (including another GC) is an unsolved problem. Good. Swift is a disaster, also agreed. So? For the rest: actual research disagrees with your forceful but unsubstantiated assertion: https://2013.splashcon.org/details/oopsla-2013-papers/21/Taking-Off-the-Gloves-with-Reference-Counting-Immix https://2013.splashcon.org/details/oopsla-2013-papers/21/Tak... And once again, tracing GCs do well in microbenchmarks where you only check the cost of local operations. They are horrible when you take the global effects into account, with those local/benchmarking advantages not translating into real world use. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf Very similar to JITs, which also do massively better in microbenchmarks than in production code: http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html Oh, and integrating well and without high cost to fast languages where you have even more control is actually an important feature.
    - pjmlp 6y ago
      No we don't agree, unless you can make a point on how D, Active Oberon, Go, Modula-3, Eiffel, .NET, Nim, among several others, integration of tracing GC alongside stack, global and off heap memory allocation happens to be a research project.
      - mpweiher 6y ago
        Those aren't actually integrated. They just live side-by-side.
        pjmlp 6y ago
        It is definlty integrated for the users of those languages.