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!
Marc