Subject: Re: Lisp io performance.
From: Erik Naggum <>
Date: 1999/01/21
Newsgroups: comp.lang.lisp
Message-ID: <>

* (Christopher R. Barry)
| Not that this has anything to do with the immediate problem at hand, but
| it's cool that Lisp has been implemented before to do such massively
| parallel processing.

  massively parallel computing really isn't like a multiprocessor: there
  aren't any "threads" in them.  MPC is about breaking down a sequential
  problem into time-independent parts and has a granularity that is
  miniscule compared to the very bulky "thread" thingies.  e.g., an MPC
  conceptually executes the several computations in a LET binding, time-
  independent assignments, and the like on separate processors.  some of
  the benefits of this is actually achieved in modern processors for a
  small number of parallel computations that use independent registers.

  OS-level threads are really the wrong solution to the wrong problem:
  because the OS likes to suspend the whole process and wake it up when the
  kernel has serviced a request (which is bad design), you "need" a means
  to make the kernel let some other, independent part of the process run,
  but the right way is to send requests to the kernel for execution and
  pass a continuation along, so you can go on with other things.  so this
  OS-level thread stuff really is about blocking system calls, not so much
  about exploiting symmetrical multiprocessors.  however, it wouldn't be
  very hard to create a Common Lisp with SMP support -- it just had to work
  its way down to the machine level in an unprecedented fashion, which the
  OS-level threads themselves make it very hard for us to do, because they
  solve the problem "well enough" that people don't bother to do all the
  extra work it takes to get it _right_.

  SIGTHTBABW: a signal sent from Unix to its programmers at random
  intervals to make them remember that There Has To Be A Better Way.