7 ms·

The Transputer Handbook (1990) [pdf]

48 points by twoodfin 4y ago

codetrotter 4y ago
I wanted Dall-E 2 to show me what a Transputer might look like, so I entered the following as prompt for Dall-E 2, based on the text from the preface and the intrpoduction of the linked PDF: > The software and hardware implementation of transputer parallel processing systems. Why do we need all this computing power, and how are we going to be provided with it? Modern developments have shown that good software should be intuitive. If the user has learned one program package then the next package, albeit from a different software house, should behave in a similar fashion. Results: * https://i.imgur.com/koOGgFI.png https://i.imgur.com/koOGgFI.png * https://i.imgur.com/BuU8YrX.png https://i.imgur.com/BuU8YrX.png * https://i.imgur.com/7fZplFV.png https://i.imgur.com/7fZplFV.png * https://i.imgur.com/mrMUHEp.png https://i.imgur.com/mrMUHEp.png The generated images are very stock photo looking. And unfortunately also not very informative..
- codetrotter 4y ago
  Another attempt. Prompt: > A photo in the style of a still from the 1995 science fiction movie Johnny Mnemonic, showing a man sitting in front of a Transputer. Results: * https://i.imgur.com/5ESVag2.png https://i.imgur.com/5ESVag2.png * https://i.imgur.com/8APGO8b.png https://i.imgur.com/8APGO8b.png * https://i.imgur.com/n38em4Q.png https://i.imgur.com/n38em4Q.png * https://i.imgur.com/rM4bDit.png https://i.imgur.com/rM4bDit.png I like these more. Still not sure the output is in any way influenced by the word "transputer" though, as these look like pretty regular computers. Guess I am left with no choice but to read the PDF itself. And hope that it's worth it :p
- kitd 4y ago
  Entertainingly, the second one has been flagged as potentially "erotic". That's parallel processing for you...
nickdothutton 4y ago
Brings back memories from university programming the T414.
- __d 4y ago
  The T414 was the first useful but affordable Transputer. It was 32 bit but lacked the floating point hardware of the more expensive T8xx series. Later on there were even cheaper T4xx chips, which were relatively easy to get on a PC expansion card with slightly crippled tool chains for occam. I still have a couple of T414 boards. I mostly run Helios on them: a parallel universe version of Plan9.
  - bear8642 4y ago
    Just to check - by Helios you mean <https://en.wikipedia.org/wiki/HeliOS https://en.wikipedia.org/wiki/HeliOS>? I've not heard of it before. > a parallel universe version of Plan9 I've enjoyed learning about Plan9, how would you say they compare as systems?
    - __d 4y ago
      Yes, that Wikipedia link is the one I mean. It was sold independently but was also the native OS of the Atari Transputer Workstation. Like Plan9, Helios has servers that export a namespace into a common tree. The Helios server protocol is very similar to 9p. They appear to have evolved independently though. Plan9 allows each user to manage their own namespace by mounting stuff into it. In Helios, there’s a shared global tree that spans all the Transputers in the system. Both are Unix-like, although Helios probably tried harder to maintain a POSIX-like API.
adrianmsmith 4y ago
I have this book, still sitting in my bookshelf, from back in the day. I never got to use a Transputer for real which is a shame as I would have loved to try them out, but the book was still excellent and worth the read.
- kingludite 4y ago
  It is a wonderful piece of writing.
mark_undoio 4y ago
The Transputer always sounded like a computer from an alternate future when I read about them before. I don't know how practical the tech would have been to scale but I wonder how different computing could have been. A conceptually somewhat related system (in the sense of a computer as a network of smart-ish components) was the (research prototype) Desk Area Network https://www.cl.cam.ac.uk/research/srg/netos/projects/archive/dan.html https://www.cl.cam.ac.uk/research/srg/netos/projects/archive... Mainframes had significantly powerful IO processors, meanwhile modern PCs contain many processors linked by effectively an internal network. With the right network hardware you can DMA to another system too. So I guess the lines have always been a little blurry between systems!
- deepspace 4y ago
  The company I worked for in the early 90s decided to use Transputers for their custom embedded systems, so I had the privilege of working with them in development and production environments for a few years. They were an absolute joy to work with. You would structure your code into tasks that could be performed in parallel, with a simple queue for inter-task communication. You could then debug the code on a single transputer (residing on an I/O card plugged into your computer). The production board typically contained several transputers, all connected through serial links, and with one off-board link connector. To upload your code to production, you connected a link from the transputer on your dev card to the production board, placed the board in "boot from link" mode and downloaded the code to the target. A "placement" file directed where the various tasks should run, so the tasks which ran on a single processor in dev, were loaded into the specified processors on the target. I.e. going from single processor to multiprocessor execution without even requiring a re-compile. The T800 was the fastest floating-point processor available at the time and blew our previous generation processors out of the water. Everyone was sad when INMOS /SGS Thompson faltered with the development of the T9000 and lost their performance edge, eventually resulting in the demise of the platform.
Rochus 4y ago
Occam-2 was definitely not my most favorite language, but an interesting experience. Thanks for the link; I only had the original manuals and Pio2 at the time. Using http://any2djvu.djvu.org/ http://any2djvu.djvu.org/ I was able to generate a fast, compact version of the referenced PDF. Btw. Pio2 can be accessed from here: http://www.cs.ox.ac.uk/people/geraint.jones/publications/book/Pio2/ http://www.cs.ox.ac.uk/people/geraint.jones/publications/boo...
- atrn 4y ago
  I did a lot of work with transputers and occam in the 1980s and wrote an OS for a machine that used them. The exposure to the CSP way of thinking was a blessing. occam-2 on the other hand was a little too primitive. I remember when Inmos marketing came up with "We wanted to make occam the FORTRAN of parallel processing". My response was "You have." (a reference to occam-2 having only static arrays and no concept of a record/struct)
  - Rochus 4y ago
    > occam-2 having only static arrays and no concept of a record/struct Which is remarkable since Tony Hoare is actually also the inventor of the records concept. In the corresponding publication in the Algol Bulletin 21 from 1965 there is even a quote by Occam ;-)
zackmorris 4y ago
This is great! I independently figured a lot of this stuff out around 1995 while writing shareware games in college (limited by absurdly slow 30 MHz memory busses and single-threaded execution before video cards) and 2005 at a job where I used MATLAB. Basically that computers ran many thousands of times slower than they should have, which today translates to many millions of times slower for the transistor counts. We perceive computers as fast today, but that's just the video card doing most of the work, at enormous programmer expense due to having to use separate languages and paradigms separate from the host OS. The article jumps the shark at chapter 5 Transputer Languages on page 63, so I'd recommend skipping that. It's fun to learn about stuff like Occam, but it's kind of the assembly language of Erlang or Go (if Go had full process isolation) so is probably too low-level for large programs to be understandable by humans. They didn't really understand process isolation like we do today, so got lost in the weeds with libraries/intrinsics/threads, rather than having a language self-parallelize all code like something like Julia (from what I understand, I haven't fully learned it yet). I'd largely skip Chapter 6 Software Environments on page 88 as well, which covers various environments for transputers, which are fun for their historical significance. But again, I wouldn't use any of them today, since we have much simpler approaches with stuff like containerization now. Chapter 7 Transputer Family Hardware on page 101 is quaint. The principles are good, but break down with the memory and network speeds available today and the fact that we work at higher levels of abstraction. I didn't know there was an Atari Transputer Workstation (ATW) in 1988, wow! I've written extensively about multicore processing in my comments here for over a decade, with no meaningful progress in industry from what I can tell. Personal hardware got abandoned for stuff like elastic compute on AWS. That said, it's pretty obvious what a transputer today would look like. I'd suggest a 1 GHz processor with at least 1 GB of onboard ram and at least 256 cores for under $100. It should have gigabit ethernet and use something like content-addressable memory to allow the chips to self-organize with LRU caching for data locality. It would use web metaphors so that the location of a core or memory doesn't matter, even running across a warehouse or over the internet. So 4 of these would look like a single desktop computer with a kilocore (kC, like IBM's from 2006) and easily scale to probably 64kC or even 1 MC without too much extra work. It would be the software equivalent of something like BitTorrent vs FTP. And largely buildable with FPGAs, had they continued to evolve instead of getting hamstrung by their GPU competition. It would be programmed with existing C-style languages and a self-parallelizing compiler that uses techniques from compiler optimization to detect for-loops on immutable data and spread the workload over any number of processes. Programs would be inverted to identify mutability and treat it as unsafe code that can't be statically analyzed or evaluated lazily. So synchronous blocking higher-order methods on immutable data would be highly encouraged. Stuff like shader memory layout optimizations would largely go away due to the use of content-addressable memory and the avoidance of hardware caching other than what's needed to make the distributed memory appear as a single address space. It's all so easy and obvious to me that I've all but given up on it ever happening. Writing this out for the umpteenth time makes me feel tired. To the point that I struggle to program in my daily life, because it feels like I'm having to do everything the hard way with async approaches (today's GOTO) and highly-specialized shaders that break constantly because I just can't see what I'm doing or debug them properly so it feels like all I ever get is a blank screen. I wish so badly that a startup would jump on this and bring us real computers with real power so that we could play around with stuff like genetic algorithms and running machine learning in simulation so that we could evolve our own AI digital assistants. Instead of having to rely on closed/proprietary/cookie-cutter solutions that are pay-to-play or have other artificial limitations to prevent terrorism or whatever. It's the same old story, I'm thrilled to see stuff like DALL-E 2 bring the predictions of sci-fi to life, but saddened that it happened decades later than it should have due to poor hardware architecture choices. It's like having to watch electric cars go mainstream 20-30 years after the lithium ion battery was invented, because the fossil fuel industry prevented that from happening every step of the way.
jschveibinz 4y ago
In the early 80’s, optical signal processing was the next big thing in array processing. Multiply-accumulates we’re done in optics and on the camera detector, and it was super fast, but the dynamic range was limited to less than 12 bits. By 1990, optical signal processing was dying and parallel array processing was the “next big thing” in array processing. Systolic arrays and transputers were going to be array processing engines of the future. The problem was to optimally fit the algorithm into the computing architecture—-compilers were complicated. By 1995-2000, general purpose processors, operating systems and MATLAB were fast enough to put most of that to bed except for graphics cards and special effects. GPU’s continue to be the latest in the history of array processing hardware solutions. But I believe their days are also numbered with the advent of quantum computing systems and other technologies.
01100011 4y ago
Wtf... I was just talking about transputers with a coworker yesterday. The ST20 was a popular core in early settop boxes(i.e DirecTV) and was based on a lot of transputer concepts.
- flopsamjetsam 4y ago
  Fascinating, I never thought of them as general purpose processors (though they obviously could do it). Any idea why they were chosen?
  - dboreham 4y ago
    There are a few reasons. I'll talk about two. One is technical in that Inmos had a signal processing business and was strongly staffed in that area. This offered the potential to eventually make a SoC solution that had CPU and MPEG in hardware. The other is that there were some smart people in marketing at Inmos who at some point decided that they would pick a small set of target applications that they expected to be growth areas, and where we had some existing experience, then devote serious dedicated resources to each of those areas. Two of the areas were STB and GPS. The serious resources devoted included engineers who would be pretty much full time available to the OEMs, and were dedicated to their target application. I think it was Richard Onyett who had the STB brief. He spent years working on those design in projects. Also fwiw, Inmos people always considered the CPUs to be general purpose.
  - jecel 4y ago
    Just a guess, but before everybody adopted ARM the ST20 that was inherited from Inmos was ST's high end microprocessor, though they had a bunch of other families with 8 bits and such.
  - 01100011 4y ago
    Not sure. It's been too long (20 years... Damn). I forget if they needed the horsepower for video decompression or if they had dedicated hw for that. It was definitely before ARM took over that space. ARM was still competing against MIPS, SuperH, Power, etc.
leashless 4y ago
Those were the days.
JonChesterfield 4y ago
Current day descendent of the transputer is the (AI themed) IPU from Graphcore. I think they're approximately publically accessible now in ssh to someone's server fashion with a proprietary toolchain. Some talks by the CTO online and some machine documentation on their GitHub.

48 points by twoodfin 4y ago

I wanted Dall-E 2 to show me what a Transputer might look like, so I entered the following as prompt for Dall-E 2, based on the text from the preface and the intrpoduction of the linked PDF: > The software and hardware implementation of transputer parallel processing systems. Why do we need all this computing power, and how are we going to be provided with it? Modern developments have shown that good software should be intuitive. If the user has learned one program package then the next package, albeit from a different software house, should behave in a similar fashion. Results: * https://i.imgur.com/koOGgFI.png https://i.imgur.com/koOGgFI.png * https://i.imgur.com/BuU8YrX.png https://i.imgur.com/BuU8YrX.png * https://i.imgur.com/7fZplFV.png https://i.imgur.com/7fZplFV.png * https://i.imgur.com/mrMUHEp.png https://i.imgur.com/mrMUHEp.png The generated images are very stock photo looking. And unfortunately also not very informative..

codetrotter 4y ago
Another attempt. Prompt: > A photo in the style of a still from the 1995 science fiction movie Johnny Mnemonic, showing a man sitting in front of a Transputer. Results: * https://i.imgur.com/5ESVag2.png https://i.imgur.com/5ESVag2.png * https://i.imgur.com/8APGO8b.png https://i.imgur.com/8APGO8b.png * https://i.imgur.com/n38em4Q.png https://i.imgur.com/n38em4Q.png * https://i.imgur.com/rM4bDit.png https://i.imgur.com/rM4bDit.png I like these more. Still not sure the output is in any way influenced by the word "transputer" though, as these look like pretty regular computers. Guess I am left with no choice but to read the PDF itself. And hope that it's worth it :p
kitd 4y ago
Entertainingly, the second one has been flagged as potentially "erotic". That's parallel processing for you...

nickdothutton 4y ago

Brings back memories from university programming the T414.

__d 4y ago
The T414 was the first useful but affordable Transputer. It was 32 bit but lacked the floating point hardware of the more expensive T8xx series. Later on there were even cheaper T4xx chips, which were relatively easy to get on a PC expansion card with slightly crippled tool chains for occam. I still have a couple of T414 boards. I mostly run Helios on them: a parallel universe version of Plan9.
- bear8642 4y ago
  Just to check - by Helios you mean <https://en.wikipedia.org/wiki/HeliOS https://en.wikipedia.org/wiki/HeliOS>? I've not heard of it before. > a parallel universe version of Plan9 I've enjoyed learning about Plan9, how would you say they compare as systems?
  - __d 4y ago
    Yes, that Wikipedia link is the one I mean. It was sold independently but was also the native OS of the Atari Transputer Workstation. Like Plan9, Helios has servers that export a namespace into a common tree. The Helios server protocol is very similar to 9p. They appear to have evolved independently though. Plan9 allows each user to manage their own namespace by mounting stuff into it. In Helios, there’s a shared global tree that spans all the Transputers in the system. Both are Unix-like, although Helios probably tried harder to maintain a POSIX-like API.

adrianmsmith 4y ago

I have this book, still sitting in my bookshelf, from back in the day. I never got to use a Transputer for real which is a shame as I would have loved to try them out, but the book was still excellent and worth the read.

kingludite 4y ago
It is a wonderful piece of writing.

mark_undoio 4y ago

The Transputer always sounded like a computer from an alternate future when I read about them before. I don't know how practical the tech would have been to scale but I wonder how different computing could have been. A conceptually somewhat related system (in the sense of a computer as a network of smart-ish components) was the (research prototype) Desk Area Network https://www.cl.cam.ac.uk/research/srg/netos/projects/archive/dan.html https://www.cl.cam.ac.uk/research/srg/netos/projects/archive... Mainframes had significantly powerful IO processors, meanwhile modern PCs contain many processors linked by effectively an internal network. With the right network hardware you can DMA to another system too. So I guess the lines have always been a little blurry between systems!

deepspace 4y ago
The company I worked for in the early 90s decided to use Transputers for their custom embedded systems, so I had the privilege of working with them in development and production environments for a few years. They were an absolute joy to work with. You would structure your code into tasks that could be performed in parallel, with a simple queue for inter-task communication. You could then debug the code on a single transputer (residing on an I/O card plugged into your computer). The production board typically contained several transputers, all connected through serial links, and with one off-board link connector. To upload your code to production, you connected a link from the transputer on your dev card to the production board, placed the board in "boot from link" mode and downloaded the code to the target. A "placement" file directed where the various tasks should run, so the tasks which ran on a single processor in dev, were loaded into the specified processors on the target. I.e. going from single processor to multiprocessor execution without even requiring a re-compile. The T800 was the fastest floating-point processor available at the time and blew our previous generation processors out of the water. Everyone was sad when INMOS /SGS Thompson faltered with the development of the T9000 and lost their performance edge, eventually resulting in the demise of the platform.

Rochus 4y ago

Occam-2 was definitely not my most favorite language, but an interesting experience. Thanks for the link; I only had the original manuals and Pio2 at the time. Using http://any2djvu.djvu.org/ http://any2djvu.djvu.org/ I was able to generate a fast, compact version of the referenced PDF. Btw. Pio2 can be accessed from here: http://www.cs.ox.ac.uk/people/geraint.jones/publications/book/Pio2/ http://www.cs.ox.ac.uk/people/geraint.jones/publications/boo...

atrn 4y ago
I did a lot of work with transputers and occam in the 1980s and wrote an OS for a machine that used them. The exposure to the CSP way of thinking was a blessing. occam-2 on the other hand was a little too primitive. I remember when Inmos marketing came up with "We wanted to make occam the FORTRAN of parallel processing". My response was "You have." (a reference to occam-2 having only static arrays and no concept of a record/struct)
- Rochus 4y ago
  > occam-2 having only static arrays and no concept of a record/struct Which is remarkable since Tony Hoare is actually also the inventor of the records concept. In the corresponding publication in the Algol Bulletin 21 from 1965 there is even a quote by Occam ;-)

zackmorris 4y ago

This is great! I independently figured a lot of this stuff out around 1995 while writing shareware games in college (limited by absurdly slow 30 MHz memory busses and single-threaded execution before video cards) and 2005 at a job where I used MATLAB. Basically that computers ran many thousands of times slower than they should have, which today translates to many millions of times slower for the transistor counts. We perceive computers as fast today, but that's just the video card doing most of the work, at enormous programmer expense due to having to use separate languages and paradigms separate from the host OS. The article jumps the shark at chapter 5 Transputer Languages on page 63, so I'd recommend skipping that. It's fun to learn about stuff like Occam, but it's kind of the assembly language of Erlang or Go (if Go had full process isolation) so is probably too low-level for large programs to be understandable by humans. They didn't really understand process isolation like we do today, so got lost in the weeds with libraries/intrinsics/threads, rather than having a language self-parallelize all code like something like Julia (from what I understand, I haven't fully learned it yet). I'd largely skip Chapter 6 Software Environments on page 88 as well, which covers various environments for transputers, which are fun for their historical significance. But again, I wouldn't use any of them today, since we have much simpler approaches with stuff like containerization now. Chapter 7 Transputer Family Hardware on page 101 is quaint. The principles are good, but break down with the memory and network speeds available today and the fact that we work at higher levels of abstraction. I didn't know there was an Atari Transputer Workstation (ATW) in 1988, wow! I've written extensively about multicore processing in my comments here for over a decade, with no meaningful progress in industry from what I can tell. Personal hardware got abandoned for stuff like elastic compute on AWS. That said, it's pretty obvious what a transputer today would look like. I'd suggest a 1 GHz processor with at least 1 GB of onboard ram and at least 256 cores for under $100. It should have gigabit ethernet and use something like content-addressable memory to allow the chips to self-organize with LRU caching for data locality. It would use web metaphors so that the location of a core or memory doesn't matter, even running across a warehouse or over the internet. So 4 of these would look like a single desktop computer with a kilocore (kC, like IBM's from 2006) and easily scale to probably 64kC or even 1 MC without too much extra work. It would be the software equivalent of something like BitTorrent vs FTP. And largely buildable with FPGAs, had they continued to evolve instead of getting hamstrung by their GPU competition. It would be programmed with existing C-style languages and a self-parallelizing compiler that uses techniques from compiler optimization to detect for-loops on immutable data and spread the workload over any number of processes. Programs would be inverted to identify mutability and treat it as unsafe code that can't be statically analyzed or evaluated lazily. So synchronous blocking higher-order methods on immutable data would be highly encouraged. Stuff like shader memory layout optimizations would largely go away due to the use of content-addressable memory and the avoidance of hardware caching other than what's needed to make the distributed memory appear as a single address space. It's all so easy and obvious to me that I've all but given up on it ever happening. Writing this out for the umpteenth time makes me feel tired. To the point that I struggle to program in my daily life, because it feels like I'm having to do everything the hard way with async approaches (today's GOTO) and highly-specialized shaders that break constantly because I just can't see what I'm doing or debug them properly so it feels like all I ever get is a blank screen. I wish so badly that a startup would jump on this and bring us real computers with real power so that we could play around with stuff like genetic algorithms and running machine learning in simulation so that we could evolve our own AI digital assistants. Instead of having to rely on closed/proprietary/cookie-cutter solutions that are pay-to-play or have other artificial limitations to prevent terrorism or whatever. It's the same old story, I'm thrilled to see stuff like DALL-E 2 bring the predictions of sci-fi to life, but saddened that it happened decades later than it should have due to poor hardware architecture choices. It's like having to watch electric cars go mainstream 20-30 years after the lithium ion battery was invented, because the fossil fuel industry prevented that from happening every step of the way.

jschveibinz 4y ago

In the early 80’s, optical signal processing was the next big thing in array processing. Multiply-accumulates we’re done in optics and on the camera detector, and it was super fast, but the dynamic range was limited to less than 12 bits. By 1990, optical signal processing was dying and parallel array processing was the “next big thing” in array processing. Systolic arrays and transputers were going to be array processing engines of the future. The problem was to optimally fit the algorithm into the computing architecture—-compilers were complicated. By 1995-2000, general purpose processors, operating systems and MATLAB were fast enough to put most of that to bed except for graphics cards and special effects. GPU’s continue to be the latest in the history of array processing hardware solutions. But I believe their days are also numbered with the advent of quantum computing systems and other technologies.

01100011 4y ago

Wtf... I was just talking about transputers with a coworker yesterday. The ST20 was a popular core in early settop boxes(i.e DirecTV) and was based on a lot of transputer concepts.

flopsamjetsam 4y ago
Fascinating, I never thought of them as general purpose processors (though they obviously could do it). Any idea why they were chosen?
- dboreham 4y ago
  There are a few reasons. I'll talk about two. One is technical in that Inmos had a signal processing business and was strongly staffed in that area. This offered the potential to eventually make a SoC solution that had CPU and MPEG in hardware. The other is that there were some smart people in marketing at Inmos who at some point decided that they would pick a small set of target applications that they expected to be growth areas, and where we had some existing experience, then devote serious dedicated resources to each of those areas. Two of the areas were STB and GPS. The serious resources devoted included engineers who would be pretty much full time available to the OEMs, and were dedicated to their target application. I think it was Richard Onyett who had the STB brief. He spent years working on those design in projects. Also fwiw, Inmos people always considered the CPUs to be general purpose.
- jecel 4y ago
  Just a guess, but before everybody adopted ARM the ST20 that was inherited from Inmos was ST's high end microprocessor, though they had a bunch of other families with 8 bits and such.
- 01100011 4y ago
  Not sure. It's been too long (20 years... Damn). I forget if they needed the horsepower for video decompression or if they had dedicated hw for that. It was definitely before ARM took over that space. ARM was still competing against MIPS, SuperH, Power, etc.

leashless 4y ago

Those were the days.

JonChesterfield 4y ago

Current day descendent of the transputer is the (AI themed) IPU from Graphcore. I think they're approximately publically accessible now in ssh to someone's server fashion with a proprietary toolchain. Some talks by the CTO online and some machine documentation on their GitHub.