[HN Gopher] Transputer.net
___________________________________________________________________
Transputer.net
Author : fidotron
Score : 67 points
Date : 2024-01-07 14:41 UTC (8 hours ago)
(HTM) web link (transputer.net)
(TXT) w3m dump (transputer.net)
| bradreaves2 wrote:
| Is this idea the progenitor of SoCs?
| fidotron wrote:
| More of a parallel universe that didn't work out caused by the
| same VLSI revolution.
|
| It is what you get if you think computers need to advance by
| going parallel, meaning making it far easier to build whole
| systems out of lots of CPUs arranged in application specific
| topologies, and taking advantage of VLSI to put all the
| hardware on one chip to do it. The inspired part was using CSP
| as the formalism to define how this should work, which is where
| things like the channels in golang ultimately come from. The
| transputer has microcoded instructions for interprocess and
| interprocessor channel i/o.
|
| It happened to walk straight into the RISC revolution, which it
| definitely is not part of, and so the only commercially
| successful spin off of it was their formally proven floating
| point unit which ended up licensed to Sun (and others iirc).
| bpye wrote:
| Xmos [0] still exists which, whilst not the same as the
| Transputer, does fabricate MCUs with hardware parallelism and
| a variant of C called xC with CSP primitives.
|
| [0] - https://www.xmos.com/
| JonChesterfield wrote:
| Graphcore is a direct descendent as well. That's message
| passing with different tooling - easy-ish to use from
| machine learning frameworks, deeply confusing to program
| directly.
| lukeh wrote:
| I'm using the XE216 (one of their chips) in an audio
| project and XC is a pleasure to program in.
| zozbot234 wrote:
| > More of a parallel universe that didn't work out
|
| Neuromorphic chips are built essentially the same way. The
| individual compute units are dog slow and only have tiny
| scratchpad memories (just like the elementary "SoC's" of a
| transputer), but you can etch many more of them on any given
| piece of silicon and they sip power compared to a standard
| CPU or even GPU, so the total amount of compute is
| significantly increased.
| fidotron wrote:
| Neuromorphic chips tend to be SIMD (or effectively so)
| which is not the case with transputers, which were also not
| intended to be slow CPUs when they were introduced! With
| transputers it was up to the PCB designer to choose the
| topology of the links between nodes, and they were very
| fast for the time.
|
| AFAIK no one ever put multiple transputers in an array in
| one package because it exposes one of the key flaws of the
| idea which is if you arrange them in a pipeline but only
| one of them has a flaw the whole thing is broken. That is a
| huge part of why the GPU style design has won for massive
| parallelism.
| dboreham wrote:
| > Is this idea the progenitor of SoCs
|
| No and yes. The idea of a SoC is pretty generic and existed in
| the industry at the time. But the Inmos team had an interesting
| mix of system and chip designers (some people who designed
| both) which led to an elevated interest in trying to get more
| functionality on-chip. E.g. the PLL clock generator, memory
| controller, on-board serial I/O. The idea that you could sell a
| custom chip with CPU and some application-specific peripherals
| onboard also existed. Inmos developed a disk controller
| transputer (M212) to showcase that concept.
| mk_stjames wrote:
| I have a few IMST400's and IMST425's sitting in a drawer waiting
| for inspiration to strike for a cool project to use them in, one
| day. Pulled from some mid 90's ISDN test equipment. These keep
| getting mentioned here on HN and every time I'm reminded I have
| these sitting here waiting for me to learn more about them.
|
| It's a very interesting architecture. Sifting thru the datasheets
| is daunting stuff.
| tromp wrote:
| Previously discussed as "Inmos and the Transputer (1998)" [1]
|
| [1] https://news.ycombinator.com/item?id=34948894
| lefixx wrote:
| ok but what is it?
| Tamer wrote:
| Obviously, it's a transputer, at least it looks like one.
| juancn wrote:
| This is probably a good explainer:
| https://transputer.net/fbooks/tarch/tarch.html
|
| TLDR: basically build a computer by connecting a bunch of small
| computers with memory and compute together (what we would call
| a SOC - System on a Chip - today )
|
| The instincts were correct IMHO, the implementation changed a
| lot over time and we do a similar strategy at different scales.
| klausnrooster wrote:
| Chuck Moore's https://www.greenarraychips.com/ for example?
| JonChesterfield wrote:
| The transputer tech is a rich trove of forgotten ideas. Occam and
| Hoare's CSP book are especially interesting. Highly recommended.
| As in read the primary sources, not blog posts about what people
| think CSP is.
| jgrahamc wrote:
| I studied at Oxford when Hoare was the lead of the Programming
| Research Group. We did a lot of CSP stuff and my entire DPhil
| is CSP and occam. I would recommend reading the CSP book [1] if
| you really want to know about CSP.
|
| [1] http://www.usingcsp.com/cspbook.pdf
| fidotron wrote:
| Hoare is so much more readable than Milner as well, which I
| think accounts for a large part of why the pi calculus gets
| ignored.
|
| I was at Loughborough and we had to do real time systems
| using occam . . . it was great! The problem with occam (and
| transputers generally) is they are a bit too static at build
| time, and so are very fault intolerant, which isn't great in
| many real world applications. Consequently I tend to think
| CSP works in the small and the Actor pattern is better in the
| large.
| JonChesterfield wrote:
| The differences between the original paper and the book are
| interesting too, I'm told that roughly reflects things he
| learned from the occam production effort.
|
| In particular I suspect there is a useful correlation between
| synchronous message passing and maintaining program
| invariants which is obfuscated if your primitive is
| asynchronous queues.
| jgrahamc wrote:
| What would you highlight? The big thing from my perspective
| was that there are no channels in the original CSP. There's
| just synchronization on shared events. Asynchronous queues
| are a good way of delaying deadlocks!
| karmakaze wrote:
| I wasn't aware that there was widespread misunderstanding about
| what CSP is. Mind listing a common misconception, so I can tell
| I'm among the misinformed. I haven't read up on it specifically
| so the links in these threads are now on my radar. As much as I
| know is through running into the ideas from Erlang/Elixir and
| Pony. The only other thing I recall reading is as soon as
| there's a buffer, CSP breaks down losing determinism or some-
| such.
|
| _I also ran into the Inmos Transputer while I was at UWaterloo
| but didn 't get a chance to use it myself, due to limited
| availability at the time._
| JonChesterfield wrote:
| Lots of people have the idea that message passing is good.
| Maybe slow, but easier than directly hammering on shared
| memory.
|
| Synchronous message passing, as in wait for the other guy
| then swap, is a different thing to pushing work into a queue
| to be dealt with later. Not just a buffer of size one; the
| current thread actually blocks until the exchange occurs.
|
| It's another step in the direction of decreased throughput
| for decreased entropy and I think it's an important one. I
| personally missed the distinction for a good decade or so,
| seems plausible others have likewise missed it.
| BoiledCabbage wrote:
| And between CSP and elixir, which promotes synchronous
| message passing and which promotes the asynchronous/queue
| approach?
| Jtsummers wrote:
| CSP communication blocks until both sides are ready for
| the communication. You can create a process which acts as
| a buffer so that an outputting process is able to
| communicate so long as the buffer has capacity (and if
| the buffer size is unbounded then it will never be
| blocked, at least as long as there is sufficient memory).
| dboreham wrote:
| Not exactly forgotten if you use golang.
| QuadrupleA wrote:
| Was dying for an explanation of what the hell it is, here's that:
| https://en.m.wikipedia.org/wiki/Transputer
| raldi wrote:
| Thanks.
|
| The first three words on the page should be, "A transputer
| is..."
| foobiekr wrote:
| It's an alternate timeline, basically. Had Inmos not fallen off
| a cliff after the T800 with a wicked case of second system
| syndrome (I know that the T9k wasn't their second system, but
| it has all the hallmarks) things might have gone differently,
| earlier.
|
| Unless I'm mistaken, the only thing that lasted was the //
| single line comment syntax from Occam.
| fanf2 wrote:
| // came from BCPL https://www.bell-
| labs.com/usr/dmr/www/bcpl.pdf
| noman-land wrote:
| 'The name, from "transistor" and "computer"), was selected to
| indicate the role the individual transputers would play:
| numbers of them would be used as basic building blocks in a
| larger integrated system, just as transistors had been used in
| earlier designs.'
| TickleSteve wrote:
| Since everyone is asking what a Transputer is, think of it as an
| 80's version of a "golang machine", It is natively programmed
| using Occam and has CSP
| (https://en.wikipedia.org/wiki/Communicating_sequential_proce...)
| in hardware as its concurrency model.
|
| It was typically used in military systems such as radar
| processing, but also found use in the Atari Transputer
| Workstation
| (ATW)(https://en.wikipedia.org/wiki/Atari_Transputer_Workstation)
| jasoneckert wrote:
| Back in 2007, I went to a surplus equipment sale at the
| University of Waterloo (they were a regular event where old
| systems were sold off cheaply). I bought a steel flight box that
| looked empty, but when I removed the bottom foam compartment,
| there were several transputer expansion boards
| (https://jasoneckert.github.io/myblog/the-
| transputer/transput...).
|
| While I consider myself very well versed in the computing and
| supercomputing space from the 1990s onwards, I never heard of the
| transputer before then and used that opportunity to learn as much
| as I could from the plethora of books and documentation that the
| university library had on them.
|
| I was shocked at the parallels between transputer design and
| modern supercomputer, SoC, and superscalar processor design
| principles that were in widespread use by 2007. The transputer
| was well ahead of its time. And while it never achieved fame and
| fortune, it seems to have certainly influenced many many other
| technologies that did.
| ChrisArchitect wrote:
| _Hello, Transputer?_
|
| https://en.wikipedia.org/wiki/Transputer
| notmysql_ wrote:
| Fun fact: my ATT router refuses to let me even access this site,
| saying that I need to use their app to add the domain to a
| whitelist to access it.
| kjellsbells wrote:
| Transputers are also interesting as a bit of economics/public
| policy history. In the late 1970s and early 80s, the UK
| government was seriously freaking out about the impact of
| computerization on society. For various reasons (insert debate
| here), the late 1970s UK was stuck with stodgy, outdated
| industries employing a lot of people, and computerization only
| threatened to make that much, much worse. Imagine 6 million
| unemployed instead of 3 (which was already extremely worrisome
| for the brits).
|
| The UK government launched a number of programs to try and get
| things moving. One, the BBC Computer Literacy project, gave us
| the BBC Micro, Acorn, amd eventually ARM...plus a generation of
| Gen X people here on HN who cut their teeth on the 6502 and Z80
| cpus inside the BBC micro andnits competitors.
|
| The other was to throw money at any UK firm that looked like it
| could be the basis for a modern tech industry. A parallel stream
| at that time was the fear that Japan would leapfrog the West with
| so called "4GL" systems and hardware just like they had done with
| cars and consumer electronics. I imagine that Inmos, with some
| flashy innovation, must have looked pretty sexy to the UK
| government at that time.
| klelatti wrote:
| It is an interesting piece of economics / public policy
| history. I think using the phrase 'throw money at any UK firm'
| though does a bit of a disservice to how credible Inmos's
| technology was. They were building at or close to leading edge
| RAM chips and the Transputer, although it looks like a
| curiosity now, had lots of interesting (not really flashy)
| innovation.
|
| There were lots of issues with the running of the company of
| course, but I think it was the sale to Thorn-EMI (a really
| unsuitable owner) that ultimately sealed the fate of the firm.
| manyturtles wrote:
| Doing a CS degree in UK in the mid nineties the parallel
| computing course was taught in Occam, on Transputer simulators
| (and a handful of Transputers). Seemed anachronistic at the time
| as the Transputer had been heavily hyped a decade or so before as
| a giant advance in computer architecture that would enable hugely
| powerful machines to be built. Toward the end of the 80s the
| Meiko Computing Surface was occasionally mentioned, and the
| September 1988 issue of Personal Computer World cover story --
| "The Desktop Mainframe arrives" -- was about the Microway
| Multiputer, which could scale to something like 100 Transputers
| in a single workstation chassis.
|
| It never did take the world by storm, though, and it seemed
| completely irrelevant as a practical architecture by the mid 90s.
| But I did like the elegance of parallelizing code in Occam. Code
| blocks were introduced with SEQ or PAR, with the behavior you'd
| intuitively expect: everything in a SEQ block was run
| sequentially, everything in a PAR block could be run in any
| order, and (if memory serves) was automatically and transparently
| distributed across whatever set of Transputers it was running on.
| Neat.
| lttlrck wrote:
| I did an Occam course in 92/93 at Portsmouth - I absolutely
| loved it. We also did Ada which I enjoyed immensely but Occam
| is the one that sticks in my mind due to the powerful
| primitives.
| klelatti wrote:
| If anyone is interested in the Transputer instruction set, I
| wrote a short post on the topic last year. In short few
| registers, stack based but with a tiny stack, heavily microcoded.
|
| https://thechipletter.substack.com/p/inmos-and-the-transpute...
___________________________________________________________________
(page generated 2024-01-07 23:00 UTC)