Call for Interest: Clojure (or Lisp?) Code Camp with BLM focus

[Elias Mårtenson]

Den tors 3 dec. 2020 20:58Pascal Costanza <pc at p-cos.net> skrev:

>
> We evaluated Go and Java for their concurrent, parallel GCs, and C++ for
> its reference counting. Interestingly, reference counting is often
> described as more efficient than GC, but in our case that’s not true:
> Because there is a huge object graph at some stage that needs to be
> deallocated, reference counting incurs more or less the same pause that a
> non-concurrent GC does. That’s why we don’t expect Rust to fare better here
> either.


I'm surprised that you seem to acknowledge the myth that refcounting is
somehow more efficient in any way compared to a good GC.

Refcounting suffers from a worst-of-both-worlds situation where both
allocations and release operations are potentially slow. Allocations need
to scan the allocation tree for free memory, and upon release it has to
again search the tree to determine where to record it. And that's not even
mentioning the overhead during pointer handoff.

A GC language by contrast can optimise allocations down to a single
instruction, zero instructions for release and no overhead for pointer
transfer.

In practice, when comparing heap memory allocation between Java and C++ the
former readily beats the latter. C++ code may still be faster due to the
fact that it can often avoid heap allocations altogether by storing things
on the stack. C++ developers also go to great length to avoid using
reference counting as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201204/4c94ef85/attachment.htm>