Tim Bradshaw <email@example.com> wrote:
| However, multithreaded GCs are something that are going to have to be
| faced if you want to run on reasonable-sized multiprocessors, or you just
| crash into Amdahl's law (if GC and other serial memory management is 10%,\
| then a 10 processor machine is not a very big limit to scaling any more:
| large commercial machines already seem to be between 6 and ?20? times that).
Indeed. SGI routinely ships 64-P & 128-P machines, and have even shipped
a few 256-P & 512-P machines. These are "single-system image" (single copy
of the operating system) CC-NUMA (single cache-coherent memory space, though
access times to "local" and "other-node" memories are different) machines.
Of course, we have *lots* of compiler & library hooks for writing multi-
processing code in C, C++, and Fortran (especially the latter!), and
several flavors of "user" and "operating-system" threads to choose from
(SGI "sprocs", POSIX threads, copy-on-write fork(), etc.), depending on
what kind of sharing you want between the threads (e.g., total, partial,
or no sharing of address spaces, open files, etc.), and the usual primitives
for synchronization (spin-locks, semaphores, condition variables, etc.).
But I have long wondered whether there was a Common Lisp anywhere that
could do something useful with all those CPUs. Is there? Anybody know?
| I realise these things are *very* hard to do, and probably have
| significant overhead.
I'm sure. My guess is that at a minimum you'd want some sort of real-time
or at least incremental GC, so you could run the mutator on some CPUs while
running the collector on others, and for efficiency you'd almost certainly
need separate allocation pools per mutator thread, so you could do lock-free
allocation "most" of the time. Stuff like that...
Rob Warnock, 41L-955 firstname.lastname@example.org
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043