By: Juho Snellman (jsnell+rwt.delete@this.iki.fi), October 20, 2006 8:38 am
Room: Moderated Discussions
Rob Thorpe (rthorpe@realworldtech.com) on 10/19/06 wrote:
>Yep. I don't think it's unreasonable either.
>I think the best approach is that taken by SBCL and some other lisps: provide two
>builds, a single threaded and multi-threaded build. The single threaded build has
>different GC code that removes most of the locks and complexity the MP case introduces.
While there are places where the threaded and non-threaded builds of
SBCL have significantly different performance characteristics, memory
allocation or GC isn't one of those places. The changes related
to consing are minor (an extra lock on the slow allocation path, a couple of
extra segment register prefixes on the fast allocation path, acquiring
a couple of locks when a GC is started, etc). Any overhead from that those
differences is completely lost in the noise, when compared
to the full amortized cost of allocation (including GC).
>Yep. I don't think it's unreasonable either.
>I think the best approach is that taken by SBCL and some other lisps: provide two
>builds, a single threaded and multi-threaded build. The single threaded build has
>different GC code that removes most of the locks and complexity the MP case introduces.
While there are places where the threaded and non-threaded builds of
SBCL have significantly different performance characteristics, memory
allocation or GC isn't one of those places. The changes related
to consing are minor (an extra lock on the slow allocation path, a couple of
extra segment register prefixes on the fast allocation path, acquiring
a couple of locks when a GC is started, etc). Any overhead from that those
differences is completely lost in the noise, when compared
to the full amortized cost of allocation (including GC).