Footnote or stepping stone?
When Inmos was sold to Thorn EMI under the privatising Thatcher government in the mid-80s, and later to SGS Thomson, Transputer development continued, but was eventually abandoned.
The end of an era? It's not so easy to kill the Hydra-headed Transputer. The site of the original Inmos design centre in Bristol is now owned by STMicroelectronics. It is ablaze with engineering talent nurtured under Inmos.
Source: Ram Meenakshisundaram/Inmos.com
"They're developing products that are turning over more than a billion dollars a year," says May. "And have been for the last decade. It's the biggest Silicon Valley in Europe in terms of design capability. It's all there because of this huge expertise in processor technology."
Other companies like Infineon, Element 14 and Icera have mushroomed from the same Bristol talent base, as has May's own university spin-off, XMOS, that perpetuates the Transputer idea in low-cost microcontrollers.
So Inmos paid off in UK job creation. But in these days of ever faster Intel-style processors, who remembers the technology?
Source: PCPuter.com
Roger Shepherd was one of graduates who worked with May in the Inmos days. Now director of processor design at STmicroelectronics, he sees the ideas around the Transputer coming back into relevance. "Most PCs today have two or four cores," he says. "How to program for multicore systems is one of today's key challenges. People are now asking the same sorts of questions we were trying to answer at Inmos 30 years ago. They are trying to solve real problems that Occam overcame."
Iann Barron, now in his mid-seventies, looks back on Inmos as a venture deferred rather than defeated. He likens the Transputer to Babbage's mechanical computing engines, devised in the 19th Century, their significance not appreciated for more than 50 years after his death. "People will eventually see what we were talking about, and they'll say, 'yes, well, they did it'." ®
David May, parallel processing pioneer
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.
