The spiritual successor to the transputer is a company called XMOS[1], which has some of the same original people behind the transputer there.
You now tend to have multiple cores (virtual and physical, each virtual core is handled by time-slicing in hardware, and physical cores are other instances of the same) on a single chip-carrier, more memory, and embedded hard-cores for ethernet/USB but the concepts are pretty similar. There are still 'links' (both serial and low-digit-parallel), there's still the idea that everything is time-synchronised and deterministic. You no longer have to use Occam to program it though :)
I've used them a couple of times, for some things (time-dependence on the order of microseconds, not nanoseconds) they're pretty awesome, and they get used in the audio industry a lot. They're sort of halfway between an FPGA and a microcontroller, where you "write" a UART in code, and then send messages to it over the links from other cores (virtual or physical) to perform the UARTs job. Same for SPI, I2C etc. There's even an SDRAM controller written in software...
The Tilera was also a spiritual successor in the 00's. Through an acquisition chain they ended up at Nvidia. The DPU compute cores are apparently derived from Tilera, which me kind of happy that it still survives in some form.
Modern multi-core computers all use an interconnect/network-on-a-chip to communicate across cores. Shared memory multiprocessing is built on top of that networked architecture, using cache coherence protocols. They also commonly use SMT which gives you the "virtual/logical cores", better known as hardware threads (harts).
Iann Barron was put in charge of our group for a while.
I thought he was incredibly old and wise, and the only person I knew with a Lamborghini, that he drove to work every day.
Now I'm six years older than he was then. Not wise, no Lamborghini...
In a way Inmos’s fate probably saved Arm. SGS Thomson was one of the companies Acorn spoke with when trying to find a home for the Acorn RISC Machine but having already bought Inmos there was no appetite. If they had bought it then the ISA might have survived but I’d be astonished if it were anywhere near as successful.
PS I used transputers in a financial modelling application in the late 1990s (PROPHET) where it was used to deliver cost effective floating point performance.
I had access to one of the development boards 1986/87. I was writing neural network code for my degree/dissertation and it was slow on the Sun 3 at the lab which was slower than the departmental Vax. I was writing in C (rather than the AI languages of the time) to get the most out of the machines we had and it was still overnight runs to train a network. The transputer was so seductive with its promise of parallel speed but I could not get my head around the Occam language and dev environment in time for my deadline. I still think of it fondly as a thing that I was happy to have bumped into however slightly since it went the way of so many ideas about how to build a computer with an eye on the pre-winter, mostly symbolic AI (Lisp machines, Connection Machine, Cray).
I joined Inmos in 1982 and worked on the transputer CAD system as part of a small team led by Miles Chesney. One of the things that seems remarkable, in retrospect, is the fact that we (the Microprocessor Design Group) designed not only the end product (processor, language and development system) but all of the tools used to design them: CAD system, graphics workstations, networking software, text editors and so on. I can't recall a single case of a software (or hardware) tool that was externally sourced. Whether this was an admirable trait is another question but it certainly made for an exciting life.
One other observation on the Inmos story that I don't believe has been made elsewhere in this thread is the degree to which the company seeded the development of a number of highly innovative and successful companies in the Bristol area: Meiko, Division, Pixelfusion, Xmos, MotionMedia, PicoChip to name but a handful.
Such a shame that the UK government cannot sustain an industrial strategy. For the relatively tiny amounts of money discussed in this article -- even £125m was not a huge amount of money in the 1980s -- today we wouldn't be having this conversation about how advanced chip manufacturing cannot be done in the UK. And we could say the same about nuclear power and telecoms where the UK had a lead and chucked it away.
Edit: Europe had a rather large Atari ST scene, since Macs were prohibitively expensive. So anything Atari got a lot of publicity. I remember reading a bunch of articles about the Transputer.
I have a drawer full of Inmos 32-bit chips that were pulled from a bunch of ISDN network diagnostic equipment. I've wanted for years to sit down and dig into their workings, come up with a little project or something, but... hasn't happened.
They are pretty though; gold pins and ceramic packages and all.
Worked with a transputer based piece of life sciences instrumentation for a few years. The way you could pass program code over the links to boot each transputer was neat. The people procuring parts (not just the transputers but also the parallel to serial transceivers) must have done some epic work to find parts once Inmos was defunct. We did a project to make a USB to Link protocol interface once the ISA bus became less available and this also saved a transputer that was on the ISA card that did nothing but route messages to the transputers on the instrument.
There was an Apple Mac (sub-) team visit to Inmos in the UK, hosted by Ian Barron, sometime circa 1982 - 1983. Bob Belleville, the Mac team's director of engineering, led the trip. I remember Ian had a Jaguar with twin fuel tanks, but told the story of how he forgot to refill the first one when it was empty, so sometime he totally ran out of fuel. JG (John Giannandrea), later of Netscape, was at Inmos around then. (He was at Apple last time I checked.)
There is a project called Parachute https://devzendo.github.io/parachute/ which has the goal of transputer emulation and running a forth dialect on top of it! Scratches many of my itches so I am watching patiently.
I remember Transputer enthusiasm when I was in college, we got some boards and even built our own, but it was really not practical and the toolchains were lacking.
Even back then it seemed like something more like the GPUs we have today with many cores per die would make more sense.
Yup the tool chain was a more than a wee bit painful. There was a lot of interest at that time in graphics applications of transputers - I remember seeing code for a parallel ray tracer (MAGG?) and there was Division Ltd - a spin off by folks from Inmos and Perehelion( makers of Helios OS used in the Atari transputer product), Ian Barron was chairman. Division built a very early VR system called ProVision[1] using transputers and later built general VR development software until their acquisition by PTC where they build digital mockup visualization tools. In many respects, at least for me, exposure to transputers and those companies gave a glimpse into what the GPU market would become.
I think Go's channels came largely from Tony Hoare's CSP, via a series of languages and experiences within the Bell Labs group that also produced Unix and Plan9.
See Limbo, Alef, Newsqueak, and Squeak.
Occam was also derived from CSP, but I don't think it's accurate to call it a direct ancestor to Go.
Hmm. Wasn't Alef done by Phil Winterbottom? I remember meeting him at a party in (iirc in Putney) and talking to him about Transputers. I can't remember if he was already familiar. It was a pretty good party. Anyway, based on that evidence I suspect there was a more direct derivation than from base CSP.
TL;DR -- I suspect you're right: the Alef, Limbo, Go evolutionary path was well aware of occam.
Alef was Phil Winterbottom, yes.
The Squeak paper (http://ordiecole.com/squeak/cardelli_squeak1985.pdf) was 1985, so let's assume the work was likely some time in 1984. That would follow the Blit terminal work (paper in 1982), which seems reasonable. Newsqueak, Alef, and Limbo followed in that order.
occam 1 was 1983, so it seems reasonable that Cardelli & Pike were aware of it, although it's not cited in the paper, so perhaps they weren't.
The Newsqueak TR is from 1994, although it seems likely the work was done earlier. The TR doesn't contain any formal citations, but the text describes the language: "syntax and basic semantics come from C, while the message-passing primitives come from CSP". I think it's a little odd that it doesn't mention occam, as I think it was widely known by the mid-80s as a successful use of the CSP concepts, and Newsqueak must have been somewhere in the range 1985-1994.
Alef is described as being derived from Newsqueak, but was released with Plan9 1st edition in 1992. Alef has "alt" and "par" constructs, which strongly suggest an occam influence.
That's what got me into Go! I'd been exposed to transputers around 1990s when I was a teenager, got really into CSP as a way of thinking about programming.
> The other product was the second test chip we had made for the transputer. We persuaded IBM to use this as their next generation graphic chip, and it became embedded in the PC as the SVGA standard. Some of the oddities in the present Windows operating system stem directly from the way this chip was designed to work with the transputer.
This sounds very much like the Colour Lookup Table (CLUT)- a classic skunkworks project initiated by Gerry Talbot and Miles Chesney that 'proved' the capability of the nascent Inmos CAD system.
Can someone who read this article post a sentence (like just a headline) of what the article is actually about, like what an inmo or transputer is, without starting with a background life story and life goals like the article?
Inmos was a British semiconductor company which made a series of CPUs it called Transputers in the late 1980s-early 1990s.
Transputers were novel in that they combined a CPU core with a set of high-speed network links: the CPU ran at, eg. 20MHz and the four network links at 20Mbps.
Paired with this hardware was the programming language Occam, which was derived from the ideas of Tony Hoare's CSP, and included concurrency and communications primitives that mapped directly onto the Transputer hardware.
The end result was a system in which it was easy to configure a parallel machine with a mesh, torus, or tree of CPUs that could then run CSP-style concurrent programs very effectively.
While it saw some success in various niches (image and signal processing, for instance), the Transputer CPUs did not support other popular languages of the time (C, Pascal, Fortran, etc) well, and for various reasons, Inmos was unable to evolve the design to match the performance of (in particular) the Intel x86 family. From an initial position of having competitive performance and superior concurrency and communication, the Transputer was quickly left behind, and its successor (the T9000-series) was obsolete before launch.
Quick note that there were compilers for other languages. Definitely C. Probably Pascal. Not sure about Fortran.
I think the failure to keep the single-CPU performance edge was probably mostly about lack of money vs the competitors. Obviously related to not selling enough of the first generation chips.
There were: Rowley did Modula2, there was a GCC port, there was an Ada port, and various others, commercial and open source. But the Transputer architecture, which was stack-based, didn't lend itself to easy ports of most existing compilers, and they were slow to arrive and slow when they did.
The article also discusses the reasons for the lack of follow-on investment.
Yes, I was taught Fortran* which featured built-in parallel calculations for matrix operations (which fed into Fortran 90 IIRC) as well as Occam, and was allowed to play with the university's Meiko Computing Surface (generating fractal landscapes in real time) but not actually allowed to program them.
> a series of pioneering microprocessors from the 1980s, intended for parallel computing. To support this, each transputer had its own integrated memory and serial communication links to exchange data with other transputers
Why not compose a 3, 6, 12 year business plan and approach Nvidia for a 20-49% stake in ownership? Show up at the HN Taipei meet-up and ask around? They had $40B plus to acquire ARM. What if the transputer concept can lower the W-budget for genuine-ai? Without leaving the UK you could ask around Man. U. there's an ARM lab there.
Right. For pipeline hardware, the per-CPU resources have to be well matched to the problem. You have to cut up the problem into bite-size pieces that are the right size for the compute and memory of the little processors. Audio, yes; sonar, yes; cellular problems such as weather prediction and finite element analysis, maybe. The PS3/Cell ran into that problem, which is why later Playstations are more conventional.
Exotic parallel architectures: you can build it, but will they come? Usually, no. You need some widely used case that partitions to match the hardware. GPUs and Bitcoin mining are the big successes so far. Machine learning has that property. Successes in this area tend to come from needing to solve a specific problem at scale.
You now tend to have multiple cores (virtual and physical, each virtual core is handled by time-slicing in hardware, and physical cores are other instances of the same) on a single chip-carrier, more memory, and embedded hard-cores for ethernet/USB but the concepts are pretty similar. There are still 'links' (both serial and low-digit-parallel), there's still the idea that everything is time-synchronised and deterministic. You no longer have to use Occam to program it though :)
I've used them a couple of times, for some things (time-dependence on the order of microseconds, not nanoseconds) they're pretty awesome, and they get used in the audio industry a lot. They're sort of halfway between an FPGA and a microcontroller, where you "write" a UART in code, and then send messages to it over the links from other cores (virtual or physical) to perform the UARTs job. Same for SPI, I2C etc. There's even an SDRAM controller written in software...
1: https://www.xmos.ai