Atari Transputer Workstation
dunfield.classiccmp.org
dunfield.classiccmp.org
The old people cry, "This is all the same (stuff that's been going on forever," the young cry, "This is the future, old man."
The truth is somewhere in the middle.
"The future is already here, it's just unevenly distributed," very much describes the cycles, but I feel like in some ways this was more obvious 15 years ago, when PC evolution was the focus (nowadays it seems like mobility takes up a lot of bandwidth, which is a huge thing that feels small).
Things like GPUs hitting a tipping point where some feature that had been around for 4-8 years was now ubiquitous enough that software would assume that it was available - and fast. UI expectations ratchet up almost overnight even though the underlying technology has been simmering for years. This was quite pronounced in the 90's, but continued well into the 00's.
Everyone I think can see those, but the epicycles take a bit more study or time. Big architectural changes are driven by cost inequalities in our technologies, and those cycle. Eventually the right somebodies gets fed up and we get SSDs, or 10G Ethernet. Each of those makes some previously abandoned solutions viable again, and they sneak back in (often having to relearn old mistakes).
This multiprocessing idea dates back almost to the very beginning of private sector computing. The ILLIAC IV (1975) was intended to scale to 16 cores but some hardware problems capped it at 4 cores. Those processors were 64bit, and connected to ARPAnet a year before the Cray 1 was born.
Sequent revisited this idea in the late 80's, early 90's, using Intel x86 processor arrays.
We now have a handful of programming languages that have features that could be useful in aggressively NUMA systems (in particular,Scala, Elixir, and Rust). We'll probably see single-box clusters coming around again.
I'm a huge advocate for teaching History of Computing, and try to slip some into my classes (I teach computer engineering, but close enough) - maybe some year I'll manage to sell running a whole elective course.
If I had to pick one class that I would call fundamental to my understanding of CS, it would be CS2110 (Computer Organization and Programming) from Georgia Tech.
It started off with building stuff using logic gates, like APUs. Then it moved onto other stuff. It all culminated into building your own simplistic CPU pipeline (in an emulator) and making a small game for Gameboy Advance. Dealing with hardware limitations of that handheld console, as well as learning some interesting tricks the devs had to employ for it to add stuff like parallax backgrounds, felt eye-opening.
I am responding in trepidation, because I am certain you and everyone at HN must know what I am about to say.
Computer Science is not the science of computers, nor is it remotely the history of computers. The "computer" in Computer Science is not a machine... it is a person, "one who computes." Nor is Computer Science programming, not strictly speaking, though programming is often among the tools utilized by a computer scientist. Computer Science is and only is a subset of Mathematics, and properly initially belongs in the Math Department of a university.
The simplest analogy I have heard, which I think most now have, is that a computer is to a computer scientist what a telescope is to an astronomer. Astronomy is not the science of telescopes, nor the history of telescopes, though I would expect most Astronomy curriculums to include some overview of how telescopes work and their history, but not as some core and essential tract within the study. So in that many machines were utilized to forward the pursuit of Computer Science, so long as it is focusing on the computer science and not the nuts and bolts computer, your idea has merit.
If I am not mistaken, Computer Engineering probably doesn't spend much more than a brief overview of the history of the actual hardware. The CE undergraduate degree is overflowing as it is.
IMO, what you are suggesting belongs in the curriculum of the History of Technology, which is a perfectly valid and endlessly fascinating pursuit.
This machine is neat, and I was using computers during this era, so it makes my mouth water, "what if I had access to that?" But unless it was actually used by someone, a computer scientist, for and to advance actual Computer Science (and that can not merely be programming or creating business applications or games, but needs to at least be efforts towards computational systems), it is entirely irrelevant to the field of Computer Science.
Also, in the sense that Computer Science predates hardware by millennia, the History of Computing (i.e. the history of the activity of one who computes) is already covered in C.S.
Suggested to me years ago, which I completely agree with, since "computer" is now an ambiguous term, Computer Science should change its name to avoid the all to common mistake of assuming CS has to do with desktops and servers. Computer Science is really the science of reckoning, so it should be called "Reckoning Science" to avoid further confusion.
I would agree that a branch of CS deals exactly with the mathy part, e.g. algorithms, graph theory and so on. Then there is the systems branch; the UX/UI branch touching upon psychology etc.; a branch dealing with didactics etc. I don't see why there shouldn't be a history of CS branch under the larger umbrella.
Personally, I think "informatics" is a better name than "computer science", but that's just my biased opinion.
We care about parallel and distributed algorithms more because we have real parallel machines and big distributed systems of many machines. It's not an obscure graduate offshoot about future hypotheticals and exotic high-end machines.
We care about cache efficiency and memory access efficiency a whole lot more, because the ratio of speeds in a typical computer has changed.
And we're not spending so much of our time studying n-way tape merges anymore... even though they may come "back" because of these shifting constraints.
Real changes in what's typically limiting and what we're trying to do with computers shift the emphasis of computer science around.
And the tick-tock cadence between individual resources and centralized resources... across scaling horizontally and scaling vertically... between single fast machines and distributed systems... can be expected to continue.
I got taught history of OSes and programming languages on my degree, during the various lectures on OS architectures and compiler design.
Although OpenGL, Glide and hardware blitters (like Amiga) were all the rage on those days, we also got to learn about PHIGS and other older graphic programming stacks.
This is the beauty of a proper 5 year engineering degree instead of a 6 months bootcamp. Time to learn everything properly.
Astronomy is not about telescopes, but neither is it entirely about stars ('astra'). The name 'computer science' is not a problem in practice.
Also, there were NS3200 versions, like the Balance 8000 with six CPUs I remember at UIUC around 1986. I was floored by how effortlessly it handled having just about everyone in the CS class compiling their assignments the night before they were due. Compared to the Pyramid 90x I'd used the year before, it was like night and day.
It took a while, but that eventually percolated down to everyday PCs. It's kind of stunning that I can get 64-core CPUs these days, and even my much more modest first-generation Ryzen is no slouch.
I never got anywhere near the physical machine. It has been interesting to find photos of the various models later in life.
Ahh, the original OSX.
“[In the future] a single processor will provide somewhere between a gigaflop and a teraflop of performance. Are there really problems which need such power?”
It goes on to list problems like quantum chemistry simulations and weather forecasting. Turns out the answer was...running a web browser.
So companies that had been building large multiprocessors using transputer switched to other architectures, eg Meiko who were in the building next door were making machines with SPARC CPUs and their own interconnect.
The T9 was cool, though. The transputer instruction set was a stack-based byte code, very dense but by the 1990s not that fast, because of the growing discrepancy between CPU speed and memory speed. So the T9 had an instruction decoder that would recover risc-style ops from the stack bytecode. It was helped a bit because the transputer had the notion of a “workspace”, a bit of memory (about 16 words) that a lightweight process could access with very short instructions - in the T9 this effectively became the register set. The T9 would have been a very early superscalar CPU.
And the T9’s new fast serial links used a relatively efficient layer 1 signalling scheme that was later reused for IEEE 1344 Firewire.
(I was an intern at Inmos between secondary school and university, 1993-1994, when this was happening.)
The 90s were brutal for alternative architectures like the Transputer because performance of Intel processors were significantly improving just about yearly. I recall a neural net chip startup company near where I live - they did some cool science Saturday presentations for the public where they explained how neural nets worked (this was the early 90s). But unfortunately, they only lasted a few years - they were only about 25 years ahead of their time. Now here we are in the 2020s and alternative architectures are sprouting like dandelions.
I also seem to remember seeing a demo of a mandlebrot set being rendered impressively quickly in parallel on a transputer based machine, which I think was a cube shaped machine. A quick look on the web doesn't throw up any obvious hits though.
might have been this one? or perhaps the following old demo:
http://people.cs.bris.ac.uk/~dave/transputer.html
'The B0042 board contains 42 transputers connected via their links into a 2-dimensional array. A number of them were built following a manufacturing error - all of these transputers were inserted into the packages in the wrong orientation so were fully functional but unsaleable. I had them all (around 2000) written off for engineering use and we built the B0042 'evaluation' boards! Many of these were given to Southampton University where they were assembled into a 1260 processor machine and used for experimental scientific computing. Inmos used them in a number of exhibitions (in a box of 10 boards - 420 processors) drawing Mandelbrot sets in real time!'
Sounds like the machine I remember, a 420 processor machine in a box in the late 80s was quite something.
http://www.geekdot.com/category/hardware/transputer/parsytec...
I did personally see a transputer card in a PC running a Mandelbrot demo in that era. EGA graphics! I don't think the person who had that in his office ever got it to do what he originally bought it for, btw.
Here's a video; from 1986! https://www.youtube.com/watch?v=cdK3PXKvYgs
Richard Miller designed the Blossom video card, was hired by Atari to design the Falcon (which contained a cut down blossom), and who in turn hired his ex-Sinclair friends to design the Jaguar.
https://atariage.com/forums/topic/212866-atari-sparrow-proto...
As well, there is the KROC compiler which allows a variant of the Occam programming language to be run on Linux, OS X and I think Windows. (Mentioning this in case anyone wants to play with the concepts without having a transputer).
"We announced a new computer!"
[collective response:] "WHAT?!"
Never got my hands on one. I regret that a little. The Transputer was a seriously interesting architecture. (I was never impressed with Occam, though).
I think you could also get Fortran, Modula2 and Ada compilers for Helios.
Many years later, I found a T-800 in its storage case abandoned in the drawer of my new (to me) desk at a new job - so I kept it.
Parallel computers of the late 80s were a mixed bag - they worked well for a few use cases but in general, they were troublesome and getting access was difficult and expensive.
Amusingly Perihelion was founded by many of the folk from compiler company Metacomco, who were mainly Cambridge University computer science folk perhaps best known for the Tripos research OS. Tripos, of course, was commercialised as AmigaOS, and was the basis of Helios. So Atari shipped a computer using the same core OS as the Amiga...
Helios ran on a bunch of different systems, 68000, Transputer, i960, and later ARM, I think.
It was a fun system to program: the server protocol is a bit like Plan9's 9P. It was pretty cool at the time to have all your CPUs, and all your services, linked into a distributed namespace along with your filesystems.
Actually I’ll shoot him an email and see if he answers!
While Helios did a lot of quite cool stuff, I don’t think it was as general as 9P. It felt like it was produced by a small number of smart people under a lot of time pressure, while Plan9 felt more like it had a more leisurely research background.
I recommend the blue book (vs the black one) for detailed documentation. That plus the book of papers from Perihelion was enough to get servers running.
So, I guess it was just an independently arrived at idea.
That’s probably not too surprising I guess.
I wonder if, rather than just a single LED for each CPU, you could use an old eg. 1280x1024 LCD panel instead, so you could set the display to show different configurations of the inter-CPU links for different algorithms?
It's sad modern supercomputers are built to be buried in a dark datacenter somewhere nobody can see them.
You mean like GPGPUs?
Also, don't recent CPUs have a lot of engineering to integrate many cores together efficiently? Most high-end CPUs now are 4-16 cores.
I suspect that maybe just about every computer today is kind of a transputer.
That you could string Transputers together via their links to create an arbitrary topology computing fabric.
Like the Lynn Rekursiv.
A common TRAM had a CPU and 4MB of RAM. You'd get a bunch of those, maybe a graphics TRAM, a SCSI TRAM, etc, and build a machine using a carrier board with maybe 8 or 10 slots.
There were 4 x 20Mbps links and you could use them to directly connect to other CPUs (so, a mesh or torus) or to a fabric. The link protocol was very simple.
Each CPU had local DRAM, but there usually wasn't much: 1-16MB was typical.
Unlike most CPUs, there weren't really registers as such: you had a high-speed stack instead (on die). So an add instruction would pop the top two stack locations, and push the sum.