Hacker News Reader

Comment by chris_st | Hacker News Reader

Minor clarification -- the CM1 was the 4096-processor machine.

The CM2 had (well, those delivered to customers, anyway) a minimum of 8,192 processors, and up to a maximum 65,535. I worked on one for a number of years. I heard (but never saw) that for internal development at Connection Machines each developer had a single 512-processor board to work on.

You're spot on about the single-bit processor thing though. In their *Lisp implementation, you could declare an integer to be as many bits as you wanted, up to the max 128k bits each processor had.

View on HN

> I heard (but never saw) that for internal development at Connection Machines each developer had a single 512-processor board to work on.

From at least ~1989 on there were a bunch of machines of various sizes and states of assembly around the building at Thinking Machines. You'd connect to the appropriate front-end and cmattach whatever geometry needed. Certain groups did have dedicated CM-2s, particularly those needing specialized configurations (framebuffer, DataVault, etc).

If you knew where the machine running your code lived, you could go sit late at night and watch the LEDs throbbing. The machine really did have a presence.

Cool, thanks for the update. Yeah, the LEDs were cool -- legendarily good for debugging, but I never heard or saw any way to do that.

The CM-2 also had hardware floating-point units (off-the-shelf chips from Weitek, paired with groups of 32 bit-serial processors, via custom chips with "transposers", which would transpose 32-bit floats read bit-serially out of 32 bit-processors memories, into 32-bit floats presented in parallel to the FPU chips).

Aka "Slice-wise" mode. The FP units were optional (the project I was on didn't need FP, so we didn't have them). IIRC slice-wise mode was only available via their parallel FORTRAN compiler.

The distinction was slightly more subtle -- "slice-wise" was a storage mode for data in which a 32-bit float would be stored as one bit in the memory of 32 processors, so the "transposers" could be bypassed going in and out. It was supported by the Fortran compiler and by a microcode-like internal layer called "CMIS" (which was, I think, available to at least some customers -- I worked there).

Code in other languages still used the FPUs, if available -- but they paid the "transpose in, transpose out" overhead on every operation.

Thanks for the clarification -- interesting to know!

Is there a *Lisp compiler that generates code to run on current computers?

I don't think so. I'd imagine that stuff was lost to the ages.

Today's compilers that generate a similar set of code are OpenCL, CUDA, DirectX / HLSL, Opengl's GLSL, Apple Metal, AMD HIP, and Intel ISPC.

-----------

Today's computers (or really, GPUs), aren't 4096x wide devices or 65536x wide devices. GPUs are 32-wide or 64-wide natively, and then MIMD'd into parallel parts after that. (AKA: CUDA has the Grid -> Block -> Thread model. I'm pretty sure that Star-Lisp was only Grid -> Thread, with no "intermediate" block in between).

----------

You probably can get a similar effect as the original CM-2 by compiling into AND/OR/XOR and shift-instructions for AVX512 though?

Or maybe AND/OR/XOR + shift instructions on AMD's CDNA2+ processor (64x wide and 64-bit, for 4096-wide SIMD per core). It'd be pretty terrible, all else considered, because modern GPUs have a slight MIMD factor there.

In some form it existed: https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/...

Lots of other stuff here http://www.softwarepreservation.org/projects/LISP/parallel#C...

Wouldn't have to generate code for current SIMD units, just being able to compile *Lisp code and run it on a common computer would make me very happy.

There was a variant of GCC (called GCC*, of course) that compiled the C* dialect into "ordinary" C that would run on ordinary computers. You might be able to track that down.

Reply on news.ycombinator.com