Inmos: the rise and fall
Barron already had a scheme, hatched in conjunction with IT entrepreneur Richard Petritz and chip designer Paul Schroeder, both from the US. Together they ended up with £50m funding for an almost insanely bold new venture Barron sold to the government as a job-creation programme, the seed for a modern UK electronics industry and a bridge to the US market.
Inmos was born in 1978 with a five-year plan: spend that time - and a lot of money - developing and bringing to market a dedicated parallel processing chip, the Transputer, guided by May. But the company would start making money almost immediately by selling memory from its SRAM and, soon, DRAM factory established in Colorado Springs.
Promoting the Transputer: an Inmos brochure from 1986
Source: Dean Allum/Inmos.com
"The theory was that the static and dynamic Ram chips would be a very quick entry into the market," says May. "We had top-class Ram designers stolen out of Mostek. The memory story was right. If you can make a cheaper, faster products with the same interface as the competition the customers will buy from you. But the microprocessor has all the opposite dynamics. It takes a long time to design, a long time to establish, but once it's established the customer's locked in."
The multilingual - human and computing - polymath B Lee Jones remembers working as a systems programmer for the Colorado Springs facility. Jones gave the first US presentation of the Occam parallel programming language - May's EPL successor - to a DEC Symposium in 1981.
"David, Tony Hoare and the gang changed the whole computing paradigm," he says. "But it was too early, because a lot of people didn't get it."
Occam source code
Source: Dr Daniel Hyde
His fellow workers at Colorado Springs certainly didn't understand what the Brits were up to. "There was this focus on getting from the 16K SRams to 64K DRams. Yeah, Occam and the transputer, OK, that's interesting... But we're in the Ram business."
And then the Colorado Springs memory cash cow created to feed the Transputer's long-term development, dried up when the Japanese started dumping 64K Drams on the US market in the early 1980s. Rival memory manufacturer and neighbour Mostek was the first to be hit. "I had a nice corner office overlooking the Mostek parking lot," says Jones. "I came in one Monday morning and there were no cars there. They'd shut down Mostek over the weekend."
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Next page: Footnote or stepping stone?
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)
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Cloud based data management
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
