[gambit-list] Cosmic convergence

Marc Feeley feeley at iro.umontreal.ca
Sat Jan 14 17:35:01 EST 2006

On 14-Jan-06, at 4:24 PM, Bradley Lucier wrote:

> So, yes, "We want our SMP!"
> Brad

SMP is hard.  Several things have to be implemented:

1) Memory management needs a facelift.  If there are several  
processors, you probably need each one to allocate in a (small) local  
heap, to avoid having to enter a critical section on each  
allocation.  Garbage collection needs to be parallel, otherwise you  
won't get full benefit from your parallel hardware.  Given that many  
things related to memory management have to change to get this  
working, its probably a good idea to go to the (relatively small)  
extra trouble of making the garbage collector incremental (so that  
you don't have to barrier-sync the processors before the GC can  
start).  All of this **will** slow down object access, allocation and  
garbage collection speed (per processor), I estimate the overhead  
will be 20-50% on memory intensive programs.

2) The runtime system has to be made OS-thread-safe.  This means that  
OS mutexes are used to implement critical-sections.  This may hurt  
performance (currently several critical-sections are implemented by  
simply disabling generation of interrupt checking code, or by knowing  
that C code cannot be interrupted by other threads).

3) The thread model has to be extended.  My idea currently is to  
support two types of threads: OS threads, and lightweight threads  
(implemented with continuations).  The runtime system has basically  
no notion of physical processor, it only knows about OS threads.   
Each OS thread defines an execution context for Scheme (think of it  
as a virtual machine) with its own local heap and lightweight thread  
scheduler.  An OS thread can access objects allocated in some other  
OS thread's local heap.  When the system starts up the runtime system  
starts as many OS threads as there are physical processors.  The OS  
threads can steal lightweight threads from other OS threads in order  
to balance the work.  Supporting lightweight thread priorities will  
be a real challenge in this model (unless the lightweight thread  
scheduler is centralized, but this will be a performance bottleneck).

I have started looking into this and even have changed a few things  
in gambit.h to accomodate this model, but it sounds like several  
months of delicate implementation work... your 8-way opteron may be  
outdated when I'm finally done!


More information about the Gambit-list mailing list