More of a parallel universe that didn’t work out caused by the same VLSI revolution.
It is what you get if you think computers need to advance by going parallel, meaning making it far easier to build whole systems out of lots of CPUs arranged in application specific topologies, and taking advantage of VLSI to put all the hardware on one chip to do it. The inspired part was using CSP as the formalism to define how this should work, which is where things like the channels in golang ultimately come from. The transputer has microcoded instructions for interprocess and interprocessor channel i/o.
It happened to walk straight into the RISC revolution, which it definitely is not part of, and so the only commercially successful spin off of it was their formally proven floating point unit which ended up licensed to Sun (and others iirc).
Xmos [0] still exists which, whilst not the same as the Transputer, does fabricate MCUs with hardware parallelism and a variant of C called xC with CSP primitives.
Graphcore is a direct descendent as well. That's message passing with different tooling - easy-ish to use from machine learning frameworks, deeply confusing to program directly.
> More of a parallel universe that didn’t work out
Neuromorphic chips are built essentially the same way. The individual compute units are dog slow and only have tiny scratchpad memories (just like the elementary "SoC's" of a transputer), but you can etch many more of them on any given piece of silicon and they sip power compared to a standard CPU or even GPU, so the total amount of compute is significantly increased.
Neuromorphic chips tend to be SIMD (or effectively so) which is not the case with transputers, which were also not intended to be slow CPUs when they were introduced! With transputers it was up to the PCB designer to choose the topology of the links between nodes, and they were very fast for the time.
AFAIK no one ever put multiple transputers in an array in one package because it exposes one of the key flaws of the idea which is if you arrange them in a pipeline but only one of them has a flaw the whole thing is broken. That is a huge part of why the GPU style design has won for massive parallelism.
No and yes. The idea of a SoC is pretty generic and existed in the industry at the time. But the Inmos team had an interesting mix of system and chip designers (some people who designed both) which led to an elevated interest in trying to get more functionality on-chip. E.g. the PLL clock generator, memory controller, on-board serial I/O. The idea that you could sell a custom chip with CPU and some application-specific peripherals onboard also existed. Inmos developed a disk controller transputer (M212) to showcase that concept.
I have a few IMST400's and IMST425's sitting in a drawer waiting for inspiration to strike for a cool project to use them in, one day. Pulled from some mid 90's ISDN test equipment. These keep getting mentioned here on HN and every time I'm reminded I have these sitting here waiting for me to learn more about them.
It's a very interesting architecture. Sifting thru the datasheets is daunting stuff.
TLDR: basically build a computer by connecting a bunch of small computers with memory and compute together (what we would call a SOC - System on a Chip - today )
The instincts were correct IMHO, the implementation changed a lot over time and we do a similar strategy at different scales.
The transputer tech is a rich trove of forgotten ideas. Occam and Hoare's CSP book are especially interesting. Highly recommended. As in read the primary sources, not blog posts about what people think CSP is.
I studied at Oxford when Hoare was the lead of the Programming Research Group. We did a lot of CSP stuff and my entire DPhil is CSP and occam. I would recommend reading the CSP book [1] if you really want to know about CSP.
Hoare is so much more readable than Milner as well, which I think accounts for a large part of why the pi calculus gets ignored.
I was at Loughborough and we had to do real time systems using occam . . . it was great! The problem with occam (and transputers generally) is they are a bit too static at build time, and so are very fault intolerant, which isn’t great in many real world applications. Consequently I tend to think CSP works in the small and the Actor pattern is better in the large.
The differences between the original paper and the book are interesting too, I'm told that roughly reflects things he learned from the occam production effort.
In particular I suspect there is a useful correlation between synchronous message passing and maintaining program invariants which is obfuscated if your primitive is asynchronous queues.
What would you highlight? The big thing from my perspective was that there are no channels in the original CSP. There's just synchronization on shared events. Asynchronous queues are a good way of delaying deadlocks!
The 1978 paper proposes a reasonable set of primitives and then walks through prose examples with them. The book proposes roughly the same primitives (channels are the big change, but stop is barely in the paper) and describes them in a formal notation for state machines. It's the difference between a sketch of a plausible idea and writing down the mathematics.
Related though much later, ocaml https://github.com/ocaml-multicore/reagents observed that the send/recv primitives make less sense than a swap primitive. Between occam and the current ocaml effort, concurrent ML is the same sort of model with the details really well thought through (e.g. a thread executing stop gets garbage collected).
I wasn't aware that there was widespread misunderstanding about what CSP is. Mind listing a common misconception, so I can tell I'm among the misinformed. I haven't read up on it specifically so the links in these threads are now on my radar. As much as I know is through running into the ideas from Erlang/Elixir and Pony. The only other thing I recall reading is as soon as there's a buffer, CSP breaks down losing determinism or some-such.
I also ran into the Inmos Transputer while I was at UWaterloo but didn't get a chance to use it myself, due to limited availability at the time.
Lots of people have the idea that message passing is good. Maybe slow, but easier than directly hammering on shared memory.
Synchronous message passing, as in wait for the other guy then swap, is a different thing to pushing work into a queue to be dealt with later. Not just a buffer of size one; the current thread actually blocks until the exchange occurs.
It's another step in the direction of decreased throughput for decreased entropy and I think it's an important one. I personally missed the distinction for a good decade or so, seems plausible others have likewise missed it.
CSP communication blocks until both sides are ready for the communication. You can create a process which acts as a buffer so that an outputting process is able to communicate so long as the buffer has capacity (and if the buffer size is unbounded then it will never be blocked, at least as long as there is sufficient memory).
It's an alternate timeline, basically. Had Inmos not fallen off a cliff after the T800 with a wicked case of second system syndrome (I know that the T9k wasn't their second system, but it has all the hallmarks) things might have gone differently, earlier.
Unless I'm mistaken, the only thing that lasted was the // single line comment syntax from Occam.
Wow you are right. That's crazy, I actually had to learn BCPL because early AmigaDos still had a lot of BCPL content and I seem to have forgotten. Thanks for the correction.
'The name, from "transistor" and "computer"), was selected to indicate the role the individual transputers would play: numbers of them would be used as basic building blocks in a larger integrated system, just as transistors had been used in earlier designs.'
Since everyone is asking what a Transputer is, think of it as an 80's version of a "golang machine", It is natively programmed using Occam and has CSP (https://en.wikipedia.org/wiki/Communicating_sequential_proce...) in hardware as its concurrency model.
Back in 2007, I went to a surplus equipment sale at the University of Waterloo (they were a regular event where old systems were sold off cheaply). I bought a steel flight box that looked empty, but when I removed the bottom foam compartment, there were several transputer expansion boards (https://jasoneckert.github.io/myblog/the-transputer/transput...).
While I consider myself very well versed in the computing and supercomputing space from the 1990s onwards, I never heard of the transputer before then and used that opportunity to learn as much as I could from the plethora of books and documentation that the university library had on them.
I was shocked at the parallels between transputer design and modern supercomputer, SoC, and superscalar processor design principles that were in widespread use by 2007. The transputer was well ahead of its time. And while it never achieved fame and fortune, it seems to have certainly influenced many many other technologies that did.
Transputers are also interesting as a bit of economics/public policy history. In the late 1970s and early 80s, the UK government was seriously freaking out about the impact of computerization on society. For various reasons (insert debate here), the late 1970s UK was stuck with stodgy, outdated industries employing a lot of people, and computerization only threatened to make that much, much worse. Imagine 6 million unemployed instead of 3 (which was already extremely worrisome for the brits).
The UK government launched a number of programs to try and get things moving. One, the BBC Computer Literacy project, gave us the BBC Micro, Acorn, amd eventually ARM...plus a generation of Gen X people here on HN who cut their teeth on the 6502 and Z80 cpus inside the BBC micro andnits competitors.
The other was to throw money at any UK firm that looked like it could be the basis for a modern tech industry. A parallel stream at that time was the fear that Japan would leapfrog the West with so called "4GL" systems and hardware just like they had done with cars and consumer electronics. I imagine that Inmos, with some flashy innovation, must have looked pretty sexy to the UK government at that time.
It is an interesting piece of economics / public policy history. I think using the phrase 'throw money at any UK firm' though does a bit of a disservice to how credible Inmos's technology was. They were building at or close to leading edge RAM chips and the Transputer, although it looks like a curiosity now, had lots of interesting (not really flashy) innovation.
There were lots of issues with the running of the company of course, but I think it was the sale to Thorn-EMI (a really unsuitable owner) that ultimately sealed the fate of the firm.
Amen. (I didnt mean to imply that Inmos technology was smoke and mirrors.) Looking back at that period, there was no inherent technological reason why 8086 had to win out. It could just have easily been something from Motorola, Texas Instruments, or Inmos. I think that one of the difficulties for government investments made by small(er) countries is that there simply arent that many native horses to back, in contrast to places like the US (then and now) or maybe China (now).
Unfortunately Prolog-like logical programming was especially hard to parallelize and too high-level, in that it was hard to implement efficient search/computation strategies as part of a "declarative" Prolog program. Thus Prolog itself isn't used all that much today, even though e.g. database query and other types of "non-deterministic" programming (based on trial-and-error 'choice' and backtracking) work with similar principles.
Doing a CS degree in UK in the mid nineties the parallel computing course was taught in Occam, on Transputer simulators (and a handful of Transputers). Seemed anachronistic at the time as the Transputer had been heavily hyped a decade or so before as a giant advance in computer architecture that would enable hugely powerful machines to be built. Toward the end of the 80s the Meiko Computing Surface was occasionally mentioned, and the September 1988 issue of Personal Computer World cover story -- "The Desktop Mainframe arrives" -- was about the Microway Multiputer, which could scale to something like 100 Transputers in a single workstation chassis.
It never did take the world by storm, though, and it seemed completely irrelevant as a practical architecture by the mid 90s. But I did like the elegance of parallelizing code in Occam. Code blocks were introduced with SEQ or PAR, with the behavior you'd intuitively expect: everything in a SEQ block was run sequentially, everything in a PAR block could be run in any order, and (if memory serves) was automatically and transparently distributed across whatever set of Transputers it was running on. Neat.
I did an Occam course in 92/93 at Portsmouth - I absolutely loved it. We also did Ada which I enjoyed immensely but Occam is the one that sticks in my mind due to the powerful primitives.
If anyone is interested in the Transputer instruction set, I wrote a short post on the topic last year. In short few registers, stack based but with a tiny stack, heavily microcoded.
I was part of the Inmos Microcomputer Design Group (working on the transputer) from 1982 till 1987.
When Inmos was recruiting, number of people in the UK with solid experience in the semiconductor industry was very limited. I had some mathematics and programming experience but my degree was in Architecture.
One interesting fact is that, at Inmos, we designed ALL the hardware and software tools used to design the device: workstations, network, text editors, compilers etc. I worked on an innovative CAD system (Fat Freddy) that took inspiration from Mead and Conway's book on VLSI design. In 1987 I joined Meiko - an Inmos spin-off - which was founded to manufacture a family of message-passing 'supercomputers'.
I am not a computer architect but my understanding is that the message-passing model embodied in the transputer lost out to shared-memory, multiprocessors with respect both to performance (latency) and ease of programming. All the same, it is good to see that there are people who continue to be interested in the transputer story.
These days, my own interest is mainly focused on the transputer (and other semiconductor devices) as physical artefacts and I have a collection of unpackaged devices and wafers dating from those early years. I think of the 25-year period starting with the first Intel 4004 in 1971 as the 'heroic' period of semiconductor design when the layout of functional elements and interconnect was a 'handcraft'.
Nowadays, with the automatic layout of microelectronic circuitry and the planarisation adopted in the fabrication process, the physical circuitry has disappeared 'into the woodwork'.
You wouldn’t happen to have any docs on the T805 microcode, would you? There are relatively few Open Source Transputer emulators; the microcode has been dumped, a couple of people have figured it out and written closed-source emulators with it, but nobody’s sharing information.
1. each transputer CPU is fast, with on chip memory and links
2. you can easily wire them up in parallel to get (10,100,1000x) speed up
3. with the Occam language, you can write code in a parallel way
What people heard was:
1. a 10MIPS T414 transputer is a heavily microcoded CISC architecture and thus slower than a comparable RISC CPU. Clocked at 20MHz a MIPS, SPARC CPU will deliver 20MIPS ... but of much more powerful instructions. [various other limitations such as stack of only 3 registers v.s eg MIPS has 32 registers; flat memory model vs. data/instruction caching; log shifter vs. barrel shifter in ALU; microcoded FPU] --- so you already need 1.5-2x transputers to match the competition is speed is your aim
... I think that this was pretty fair - rather an apples vs oranges comparison
2. this device is for teams that building a computing platform (e.g. workstation, graphics machine, supercomputer, etc.) and you have software that is amenable to parallelization
... I think that this was pretty fair too
3. you can't use any existing software since there is no C/Pascal/FORTRAN compiler and Inmos will not support this (so forget UNIX, libraries, drivers, benchmarks, apps) - there was never a path such as a C compiler with Occam-style Channels in a library
... you and your customers will have to rewrite all your code in Occam
In hindsight, it was probably unlucky that the transputer and parallel architectures were launched into the teeth of the CISC vs RISC revolution since it was harder to keep the focus on point (2). Even more telling was that there was no substantive market demand for this (any) parallel microprocessor (a couple of niche systems players like nCube who didn't fancy being hostage to Inmos IP). So we ended up trying to create a market from scratch.
My model for the ultimate failure is that there was an internal battle between the pragmatists who said "we need to have a C compiler and port in a standard OS" (Pete) and the purists who said "any dilution of Occam will make it too hard for users to successfully parallelize their code" (David & Colin). The purists had the CEO's (Iain's) ear - they won the battle and lost the war.
Disclosure: I was US junior product manager for the Transputer launch in 1985
48 comments
[ 3.5 ms ] story [ 115 ms ] threadIt is what you get if you think computers need to advance by going parallel, meaning making it far easier to build whole systems out of lots of CPUs arranged in application specific topologies, and taking advantage of VLSI to put all the hardware on one chip to do it. The inspired part was using CSP as the formalism to define how this should work, which is where things like the channels in golang ultimately come from. The transputer has microcoded instructions for interprocess and interprocessor channel i/o.
It happened to walk straight into the RISC revolution, which it definitely is not part of, and so the only commercially successful spin off of it was their formally proven floating point unit which ended up licensed to Sun (and others iirc).
[0] - https://www.xmos.com/
Neuromorphic chips are built essentially the same way. The individual compute units are dog slow and only have tiny scratchpad memories (just like the elementary "SoC's" of a transputer), but you can etch many more of them on any given piece of silicon and they sip power compared to a standard CPU or even GPU, so the total amount of compute is significantly increased.
AFAIK no one ever put multiple transputers in an array in one package because it exposes one of the key flaws of the idea which is if you arrange them in a pipeline but only one of them has a flaw the whole thing is broken. That is a huge part of why the GPU style design has won for massive parallelism.
No and yes. The idea of a SoC is pretty generic and existed in the industry at the time. But the Inmos team had an interesting mix of system and chip designers (some people who designed both) which led to an elevated interest in trying to get more functionality on-chip. E.g. the PLL clock generator, memory controller, on-board serial I/O. The idea that you could sell a custom chip with CPU and some application-specific peripherals onboard also existed. Inmos developed a disk controller transputer (M212) to showcase that concept.
It's a very interesting architecture. Sifting thru the datasheets is daunting stuff.
[1] https://news.ycombinator.com/item?id=34948894
TLDR: basically build a computer by connecting a bunch of small computers with memory and compute together (what we would call a SOC - System on a Chip - today )
The instincts were correct IMHO, the implementation changed a lot over time and we do a similar strategy at different scales.
[1] http://www.usingcsp.com/cspbook.pdf
I was at Loughborough and we had to do real time systems using occam . . . it was great! The problem with occam (and transputers generally) is they are a bit too static at build time, and so are very fault intolerant, which isn’t great in many real world applications. Consequently I tend to think CSP works in the small and the Actor pattern is better in the large.
In particular I suspect there is a useful correlation between synchronous message passing and maintaining program invariants which is obfuscated if your primitive is asynchronous queues.
Related though much later, ocaml https://github.com/ocaml-multicore/reagents observed that the send/recv primitives make less sense than a swap primitive. Between occam and the current ocaml effort, concurrent ML is the same sort of model with the details really well thought through (e.g. a thread executing stop gets garbage collected).
I also ran into the Inmos Transputer while I was at UWaterloo but didn't get a chance to use it myself, due to limited availability at the time.
Synchronous message passing, as in wait for the other guy then swap, is a different thing to pushing work into a queue to be dealt with later. Not just a buffer of size one; the current thread actually blocks until the exchange occurs.
It's another step in the direction of decreased throughput for decreased entropy and I think it's an important one. I personally missed the distinction for a good decade or so, seems plausible others have likewise missed it.
The first three words on the page should be, "A transputer is..."
Unless I'm mistaken, the only thing that lasted was the // single line comment syntax from Occam.
It was typically used in military systems such as radar processing, but also found use in the Atari Transputer Workstation (ATW)(https://en.wikipedia.org/wiki/Atari_Transputer_Workstation)
While I consider myself very well versed in the computing and supercomputing space from the 1990s onwards, I never heard of the transputer before then and used that opportunity to learn as much as I could from the plethora of books and documentation that the university library had on them.
I was shocked at the parallels between transputer design and modern supercomputer, SoC, and superscalar processor design principles that were in widespread use by 2007. The transputer was well ahead of its time. And while it never achieved fame and fortune, it seems to have certainly influenced many many other technologies that did.
https://en.wikipedia.org/wiki/Transputer
The UK government launched a number of programs to try and get things moving. One, the BBC Computer Literacy project, gave us the BBC Micro, Acorn, amd eventually ARM...plus a generation of Gen X people here on HN who cut their teeth on the 6502 and Z80 cpus inside the BBC micro andnits competitors.
The other was to throw money at any UK firm that looked like it could be the basis for a modern tech industry. A parallel stream at that time was the fear that Japan would leapfrog the West with so called "4GL" systems and hardware just like they had done with cars and consumer electronics. I imagine that Inmos, with some flashy innovation, must have looked pretty sexy to the UK government at that time.
There were lots of issues with the running of the company of course, but I think it was the sale to Thorn-EMI (a really unsuitable owner) that ultimately sealed the fate of the firm.
https://en.wikipedia.org/wiki/Fifth_Generation_Computer_Syst...
It never did take the world by storm, though, and it seemed completely irrelevant as a practical architecture by the mid 90s. But I did like the elegance of parallelizing code in Occam. Code blocks were introduced with SEQ or PAR, with the behavior you'd intuitively expect: everything in a SEQ block was run sequentially, everything in a PAR block could be run in any order, and (if memory serves) was automatically and transparently distributed across whatever set of Transputers it was running on. Neat.
https://thechipletter.substack.com/p/inmos-and-the-transpute...
1. each transputer CPU is fast, with on chip memory and links
2. you can easily wire them up in parallel to get (10,100,1000x) speed up
3. with the Occam language, you can write code in a parallel way
What people heard was:
1. a 10MIPS T414 transputer is a heavily microcoded CISC architecture and thus slower than a comparable RISC CPU. Clocked at 20MHz a MIPS, SPARC CPU will deliver 20MIPS ... but of much more powerful instructions. [various other limitations such as stack of only 3 registers v.s eg MIPS has 32 registers; flat memory model vs. data/instruction caching; log shifter vs. barrel shifter in ALU; microcoded FPU] --- so you already need 1.5-2x transputers to match the competition is speed is your aim ... I think that this was pretty fair - rather an apples vs oranges comparison
2. this device is for teams that building a computing platform (e.g. workstation, graphics machine, supercomputer, etc.) and you have software that is amenable to parallelization ... I think that this was pretty fair too
3. you can't use any existing software since there is no C/Pascal/FORTRAN compiler and Inmos will not support this (so forget UNIX, libraries, drivers, benchmarks, apps) - there was never a path such as a C compiler with Occam-style Channels in a library ... you and your customers will have to rewrite all your code in Occam
In hindsight, it was probably unlucky that the transputer and parallel architectures were launched into the teeth of the CISC vs RISC revolution since it was harder to keep the focus on point (2). Even more telling was that there was no substantive market demand for this (any) parallel microprocessor (a couple of niche systems players like nCube who didn't fancy being hostage to Inmos IP). So we ended up trying to create a market from scratch.
My model for the ultimate failure is that there was an internal battle between the pragmatists who said "we need to have a C compiler and port in a standard OS" (Pete) and the purists who said "any dilution of Occam will make it too hard for users to successfully parallelize their code" (David & Colin). The purists had the CEO's (Iain's) ear - they won the battle and lost the war.
Disclosure: I was US junior product manager for the Transputer launch in 1985