[rescue] San Antonio, TX area rescue

[Francisco Javier Mesa-Martinez]

On Fri, 6 Dec 2002, Joshua D Boyd wrote:

> On Fri, Dec 06, 2002 at 03:25:17AM -0500, dave at cca.org wrote:
>
> > One weird thing about the Connections Machines is that lisp was
> > highly optimized for them - it was supposedly the best language
> > to program the beast in. Arguably, the CMs were "lisp supercomputers"
> > (a slight exageration, but not by much).
>
> It's not that strange if you take into account that the original purpose
> was to be an AI machine, and this was the heydey of lisp for AI.

Nope, this is a common misconception. Thinking machines got its name
because at that time, the brain was supposed to be a SIMD like machine,
and the C-1 (and later the c-2/200) were the biggest SIMD machines
proposed at that time. Therefore they claimed that this is a "thinking"
machine since it mimics part of the neuronal processing with its single
bit serial processors. Plus the machine uses storage and processing
clusters, much like neurons are used for storage/processing in the brain
(plus nearest neighbor interconnection fabrics which also mimic neuronal
synapses). This is purelly for a machine that mimics the "processing" of
the brain, but has nothing to do with the cognition part of it, which is
wat AI usually deals with.

The CM machines were geared towards scientific processing, not AI. Since
the machine was not expectacularly fast under *lisp (surprise there), and
then they found out that actual FP performance sucked, thus they added a
bunch of Weitek co-pros to speed up the FP ops.


 > Lisp can be extremely fast, with some work.  In fact, most
of the
> current lisps (ACL and CMUCL in particular) easily rival other languages
> for speed.  Garbage collection can interupt the speed, but that can be
> reconfigured to only run at specific times.

Lisp was never that slow, only that a lot of people were forced to learn
the language using crappy interpreters. Since interpreted codes is always
far slower that compiled lisp code (listener, versus executable). You can
certainly do tons of things with Lisp, for example Genera was a complete
OS/devel environment written in lisp, that could even run C and Fortran
code in the old Symbolics. Then you also have to be careful with which
lisp dialect you are dealing, as there are serious performance issues.

Theoretically any stack architecture should do great running lisp code,
plus recursion (which is a fundamental strength of lisp calculus) maps
very well into tight code loops that preserve locality.

 >
> JPL used to use lisp extensively for embeded applications, and Naughty
> Dog (maker of Jax and Dexter, and Crash Bandicoot) still uses lisp
> extensively in performance intensive programs.
>
> Still, it would be interesting to know more about *lisp, especially how
> it went about spreading the load around to so many CPUs.

Usually parallel lisp in SIMD tries to map recurrence and evaluation loops
into a systolic pipeline sort of processing. Since you are limited by the
I/O constraints of the system, you start one evaluation at one IO port and
let it propagate through the array. You can do things like futures, and
such to take care of evaluations which are still pending in the recursion
pipeline.

In any case the strength of the CM's was C* which had very good support
for SIMD parallelization of loops and plural variables, which allowed the
machines to operate as very deep "Vector" machines, so most of the
previous code in CRAY et al could be easily ported. However you have
monstruous latencies, huge throughput though...