We remember when the transputer first appeared. Everyone “knew” that it was going to take over everything. Of course, it didn’t. But [Oscar Toledo G.] gives us a taste of what life could have been like with a JavaScript emulator for the transputer, you can try in your browser.
If you don’t recall, the transputer was a groundbreaking CPU architecture made for parallel processing. Instead of giant, powerful CPUs, the transputer had many simple CPUs and a way to chain them all together. Sounds great, but didn’t quite make it. However, you can see the transputer’s influence on CPUs even today.
Made to work with occam, the transputer was built from the ground up for concurrent programming. Context switching was cheap, along with simple message passing and hardware scheduling.
The ersatz computer has a lot of messages in Spanish, but you can probably muddle through if you don’t hablar español. We did get the ray tracing example to work, but it was fairly slow.
Want to know more about the CPU? We got you. Of course, these days, you can emulate a transputer with nearly anything and probably outperform the original. What we really want to see is a GPU emulation.
There is a modern equivalent to the Transputer plus Occam from one of the same team (David May): the XMOS xCORE plus xC; buy them at DigiKey.
Up to 32 processors on a chip (i.e. 4000MIPS) and expandable.
xC has all the Occam/CSP parallelism with a C type syntax and C interoperability. None of this “bolt on and oh dear we need a memory model” rubbish.
Guaranteed hard realtime performance: the IDE states how long it will take to get from here to there without executing the program. None of this “measure and hope you ran across the worst case” rubbish. Nothing else manages that.
Makes embedded programming fun again :)
Not sure if Larrabee and follow up Xeon Xe counts but I think a company called “Efficient Computer” is doing something similar today. They do it for power efficiency and not so much number crunching. They found out that making a GPU “general purpose” has a factor x2 cost penalty (silicon, throughput, power, …).
It’s important to realize that while all of these are VLIW:s., in the greater scheme today with many cores there are many threads (just like on a GPU), so it’s not much worse than AVX/Neon. But not much better either. If we can’t express many parts of a program in another way that serial code, well, any parallel architecture will fail. It’s not like we’re not having an abundance of parallel-capable HW available today (CPUs with vector extensions and DSPs/GPUs/TPUs).
I second the XMOS chips are awesome. What really makes them so cool is that execution time is deterministic. However, I’m not 100% sold on the xC language but it’s not bad to use.
Parallel hardware is trivial; the software is the problem. xC is one of the few languages that has tackled parallelism head on, rather than it being a tacked on wart.
I like the parallel constructs inherited from Hoare’s CSP. They are continually incorporated in new languages such as Go.
I like the constructs for doing IO and timimg, and the way they work with the underlying hardware and CSP.
I like the way they have removed problematic bits of C in multithreaded applicatioms, e.g. aliasing.
I like the way the language plus hardware is an RTOS. No need for a separate lump of software.
We need more languages that start with and presume parallelism. But xC is currently one of the best.
A fun period in computing. I had a stint designing a Mac II transputer coprocessor for medical research applications (NuBus FTW!).
One thing which set the transputer apart, in providing an implementation tool for parallel machines, was the singular elegance of its design, and the model of providing clear documentation for engineers using its ecosystem. Still relatively rare today. I’m guessing this stemmed from the influence of principal transputer architect David May.
The XMOS tutorial documentation is a joy to read; simple and explicit, even for complex subjects.
I didn’t come across any errata.
My first application’s first iteration was delivering results in less than a day. Remarkable! Everything worked as expected, without surprises. That’s rare, unfortunately.
I spent a while at Amstrad R&D making 4 Transputer ISA boards run in Amstrad PC1640 PCs back in the day. We looked at recreating a cheaper Transputer-compatible chip, but as you say, didn’t take off so that got canned.
I have a few Transputers and just missing the drive with Indigo OS and Volvox tools :-(
http://regnirps.com/VolvoxStuff/Volvox.html
“””Everyone “knew” that it was going to take over everything.”””
Who was “everyone” is in this context? It was well understood at the time that Transputers were a solution to niche computing problems that required massive amounts of parallel computing. Such as image processing, weather modeling, DSP and other HPC applications.
I don’t think anybody was saying or thinking Transputers were going to end up in everything. But it is kind of ironic, that the current state of HPC is built on videocards/GPUs, that are in (nearly) everything. Now for the low low price of $3+M you can have a box with 72 high end videocards in it to meet your HPC needs.
Although not very practical these days, Occam is still one of my favorite programming languages.
There were some really impressive demos of Transputers doing things like parsing source code in O(log n) time. I still suspect that if they hadn’t been too expensive compared to commodity hardware, they could have been at least a niche player in high-end computing.
But they were at least niche player in high-end computing. I am not sure what you are considering ‘commodity hardware’ in the high-end or High Performance Computing (HPC) realm, but to me in the early 90s that would be Cray, Convex, SGI, etc.. Compared to those Transputers were really cheap.
At least in the UK (and parts of Europe) much of the academic massively parallel computing needs were met with Transputers. But they were also used commercially for image processing (particularly as traditional print media switched to digital editing), virtual reality, real time data collection/processing, meteorological modeling, and a host of military related options.
One issue with HPC venders like Cray, Convex and SGI is that you would be hard pushed to install their (rather bulky) hardware in a tank or satellite. But it was relatively easy to configure a much smaller and lighter weight Transputer based solution which would do the job.