Subject: Re: Lisp io performance. From: Erik Naggum <erik@naggum.no> Date: 1999/01/21 Newsgroups: comp.lang.lisp Message-ID: <3125927560875222@naggum.no> * cbarry@2xtreme.net (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_. #:Erik -- SIGTHTBABW: a signal sent from Unix to its programmers at random intervals to make them remember that There Has To Be A Better Way.