Shrinking the minicomputer
Tiny computers were already available to May. Intel, founded in the late 1960s by Robert Noyce and Gordon Moore as a memory manufacturer, had already introduced the 8-bit 8008, the chip credited as the seed for the PC revolution.
But the processor May eventually chose came from Texas Instruments. "The TM9900 was a PDP-11-like machine on a chip," he says. "It had fast serial interfaces, so I was sticking these things on boards, each with their own memory, and then networking them together for message-passing."
The system needed a programming language, so May wrote something he called EPL - Experimental Programming Language. At Cambridge he'd been taught compiler writing by Martin Richards, whose own BCPL programming language laid down the foundations for what eventually became C. BCPL was the language that drove the Warwick departmental minicomputer, the Modular One, built by a company founded by British engineer and entrepreneur Iann Barron.
"The BCPL compiler was faulty," says May, "because the port to the Modular One was never finished." Fixing BCPL was May's nursery slope to developing EPL.
One board - the B000 - 42 Transputers
From Parallel Theory to Practice
But EPL was very different. BCPL instructed a single processor to do one thing, and then the next thing, and then the next. EPL sent out its instructions to a hive of processors, each with its own memory. This made them effectively autonomous computers, and EPL's job was to distribute tasks among them and co-ordinate the results.
The far-from-trivial logic behind this kind of parallel computing had been formulated in the mid-1970s in a paper by Tony, now Sir Charles Antony Richard, Hoare. Already famous for Quicksort, the widely used sorting algorithm, Hoare had devised a theoretical language, CSP (Communicating Sequential Processes) that might enable parallel computing. It was this logic that May was now trying to implement in the real world.
May wasn't alone in his quest for workable parallelism. "In 1975, 76 there were three groups in the UK," says May. "Myself and a colleague, a couple of guys in Edinburgh, and George Coulouris and his group at Queen Mary College. We'd all, in one way or another, made proposals to the then Science Research Council (SRC) to do research on distributed computing when nobody knew what it was."
Dramatis Personnae: Iann Barron (left) and Tony Hoare
Source: Mark Jones/Inmos.com (IB) and Wikipedia (TH)
Nobody in the Labour government knew either. There was no Minister for Information Technology, although there had been a vociferous advocate for one for several years: Modular One maker Iann Barron. And it was to Barron that the SRC turned for advice.
Next page: Inmos: the rise and fall
COMMENTS
Amen. Message passing is where it's at.
As someone who has to constantly deal with multithreading hell, I fully agree. Debugging other people's synchronization errors, mutex and semaphore issues, performance cratering due to shared access issues, ararararargh. Replace it all with message queues and it's so much more deterministic, and faster as well. The queues have to be synced and high performance, but that's a single point to optimize. You can still share huge areas of memory (if you do have shared memory) by passing pointers but using the messages as permission to access and doing that infrequently.
Something with super-fast efficient message passing like Barrelfish just makes me weak in the knees - not worrying about cache coherency is a great thing. So c'mon, don't say 'The Americans' when you just mean Intel. Even Microsoft realizes Intel is dogging the wrong bone again, like they did with the P4 before the Israelis showed them the right way.
We thought it was a vision of the future
In the early '80s I ran a series of symposia for IBM UK "thought leaders" at Cambridge University. The theme of the first one was "Change" and we invited Inmos along to demonstrate the transputer technology, which some of us thought IBM should invest in.
At around that time IBM was proud to have produced a complex ray-traced image of a Newton's Cradle sitting on a chess board. This was done in under 24 hours on a high end general purpose mainframe.
Inmos demonstrated the same image before our eyes in minutes using a couple of shoebox-sized pieces of hardware. They also demonstrated how the performance could be increased by simply adding more transputers without powering off the machine.
Following the demonstration the group discussion decided that it was obviously done with smoke and mirrors and had no commercial value!
I learned a lot from that presentation, mainly to make sure that change was introduced in small increments. This was proof of Clark's 3rd Law - "Any sufficiently advanced technology is indistinguishable from magic."
Occam lives!
I ought to point out that the Occam language is thriving beyond Bristol. A group at Allegheny College in the USA (see http://transterpreter.org/) have ported an Occam dialect to the Atmel's Atmega328 microcontroller chip and appear to have generated a lot of interest among users of this tiny low-cost device - who include robot makers, animatronic artists and hobbyists. And I keep nudging its name as often as I can get away with it in PC Pro (see for example http://www.pcpro.co.uk/features/357853/how-to-build-a-computer-smarter-than-a-us-president)
Parallel processing is like Christianity
It has not been tried and found wanting, it has been found difficult and left untried (as Chesterton put it). Now we're looking at dozens of cores on a chip, but can we make effective use of them? On a server supporting multiple independent sessions (and probably with some VM going on as well) we can - but in a desktop or a supercomputer dedicated to one task?
Get real Inmos was a disaster zone
Why do we remeber britains technical and commercial failures through rose tinted glasses?
I was a system design engineer when the transputer was launched. It was nowehere near competive. It was targeted at number crunching tasks but teh performanc eof the individual pressors was so poor we calculated we would need more than 200 to replace the single bit slice procesor we had at the time. DSP devices were starting to appear at the time and they made a lot more sense. Developing a distributed message passing algorithm is much harder than on more conventional platforms so we estimated a 5 times increase in development effort.
Selling a product in which the power consumptio, space and cost are two orders of magnitude greater than competing technologies and the development costs are one order of magnitude greater is not smart.
We did use large quantities of Inmos DRAM becaus ethe nibble mod eparts were at the time the fastest available however we quickly discovered a design flaw that resulte din patern sensitive corruption of the memory. Inmos denied thsi for more than 1 year despite us being one of their largest customers and the fact we could reliably produce a problem right from the start on approximately 1% of all devices.
To summarise:
Technically naive
Commercially inept
Poor customer service
Poor quality.
No mystery about why the company no longer exists.
Lets produce commercially viable technologically innovative products with high qualty not fantasise about products thatwere badly conceived and poorl;y executed.
