This isn't really a reply to your question, but possibly the question behind it. For CPU heavy tasks, I've always used multiple processes. It's a balance between the concurrent GCs, and reduced GC pressure, on the one hand, and the cost of IPC and forking on the other. But if you can arrange your worker processes to do a significant chunk of work and avoid going into a global GC, it's probably well worth the cost of forking.


From: vseloved@gmail.com
Date: Fri, 9 May 2014 01:36:58 +0300
To: sbcl-devel@lists.sourceforge.net
Subject: [Sbcl-devel] Feasibility of a concurrent GC for SBCL


I've searched in this list and elswhere and haven't found any discussions on the topic of implementing concurrent GC in SBCL.

We develop a CPU-heavy application, and in our production setup and experiments there's a huge loss in CPU utilization because of GC pauses with the increase of the number of processor cores (for instance, going from 8 to 16 cores, basically, doesn't increase throughput of the application, because all of the gain is lost in GC). So this topic became quite important to me.

Has anyone explored this direction before? What are the main obstacles (besides the obvious need to devote a hefty amount of time to it) in implementing one of the existing concurrent GC approaches in SBCL? Maybe, someone wanted to approach it, but didn't have motivation?

I'd be grateful for any pointers and can provide more detail here or in the personal communication if needed.


Vsevolod Dyomkin
skype, twitter: vseloved

------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: 3 signs your SCM is hindering your productivity Requirements for releasing software faster Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce
_______________________________________________ Sbcl-devel mailing list Sbcl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel