4 ms·

I remember reading about this in a magazine as a kid when it first came out. I wrote software for the late-generation versions of this architecture (Cray XMT).

I remember reading about this in a magazine as a kid when it first came out. I wrote software for the late-generation versions of this architecture (Cray XMT). It really changed the way I thought about software design, and was probably the most fun piece of weird silicon I ever worked on. With a little imagination you could approximate the latency hiding it was doing in silicon in software heuristically, albeit with somewhat different mechanics. For certain kinds of codes it could be exceptionally efficient, graph analysis being a major target. Its fatal flaw was that it was pretty severely memory-bandwidth limited when code was highly optimized, an architectural resource mismatch. There were similar architectures produced by other small companies with ultra-high memory bandwidth but those were designed for a handful of specific customers and not widely marketed. Fun times.

jacquesm 3y ago
Any von Neumann inspired architecture is going to resemble looking at your data through a keyhole and trying to cram as much data through that keyhole as you can. There is an obvious solution to that but unfortunately it does not generalize well and it would likely be very hard to program for. This bottle-neck is what we spend a very large fraction of our time dealing with. Crack that one and you will be more famous than Bill Gates. I've seen some really nice attempts at computing fabrics but none that were able to grab any kind of market share, there was a post the other day about another Barrel Processor (https://news.ycombinator.com/item?id=37315802 https://news.ycombinator.com/item?id=37315802) which is probably why this one is posted now. But Barrel processors are still limited by the die size and need regular processors to deal with the non parallelizable parts of the code, they're a different point on the general cpu <-> specialized hardware continuum that works well for certain problems. Chances are that as we get closer to the limits of Moore's law that we will see a revival of such exotic architectures because they will be the only way forward to get more computing power. Especially workloads like AI and graph analysis could well benefit from this because the hardware and the data model overlap quite nicely.
- navaati 3y ago
  > There is an obvious solution to that but I'm feeling a bit dense today and it's not obvious to me. Please do tell what that solution is and why it doesn't generalize :).
  - jacquesm 3y ago
    Sorry, I should have added a link: https://en.wikipedia.org/wiki/Dataflow_architecture https://en.wikipedia.org/wiki/Dataflow_architecture And the reason why it doesn't generalize: it is typically implemented in special purpose hardware.
    - JonChesterfield 3y ago
      GPUs are pretty close to an instantiation of a dataflow architecture. I have a soft spot for vliw on deterministic memory latency but the runtime scheduler + variable memory latency is probably better. The insight is that GPUs are memory driven - warps basically wait for memory operations to complete while other warps do stuff - so execution proceeds driven by memory access patterns.
      - jacquesm 3y ago
        Not quite, but yes, they are converging. But GPUs are not universal enough to be called dataflow computers. But there are some similarities. But unless I'm mistaken SIMD is fundamentally different compared to dataflow in that it executes all of the instructions in lockstep across a bunch of units rather than that each execution unit can have its own stream of opcodes. So GPUs have great performance but require that tasks be more inherently parallel than what you could (theoretically, mostly) do with a true dataflow computer.
    - jecel 3y ago
      I have twice had the experience of meeting a professor who had done their PhD in the late 1980s/early 1990s on Dataflow and were lamenting having wasted their time since it turned out to be a dead end. I pointed out to them that the computer they are currently using has a hidden Dataflow machine inside of it - it just has a front end converting the x86 code stored in memory into the dataflow graph (reorder buffers, reservation stations and so on) before actually executing it. Perhaps one day the "all advanced processors are really RISC inside" meme will get replaced with "all advanced processors are really dataflow inside". Of course, there is the option to make the dataflow visible to the outside with the EDGE (explicit data graph execution) architecture (Microsoft even showed Windows running on one).
convolvatron 3y ago
I worked a very little bit on the systems code for the MTA, and while I really enjoyed the sync bits, the limited single thread performance really made a lot of things very difficult. Later versions of the processor were integrated in the XT systems - so you could use commodity for the rest of the stuff outside the application.
- linksnapzz 3y ago
  Was that the FreeBSD 3.x that the original MTA was running? My recollection was that it wasn't really a product; and that the MTA-2 (after the Cray buyout) was actually sold to a couple of users (Peugeot-Citroen, I think was one...)
  - convolvatron 3y ago
    its wasn't actually freebsd..it was bsd. that os continued past the cray buyout, and as far as I know continued being used even in the XMT era for local management. UCSD was the flagship customer for the MTA2 edit - it was bsd wrapped around a custom microkernel, kind of more like OSX. the original intent was that the MTA be a general purpose machine that would scale down to the desktop. so that provided the user space. there was also a very funny division of labor between the OS, the hardware, and the runtime that caused alot of anguish over the years. one the primary goals for that was extremely lightweight thread management.
    - linksnapzz 3y ago
      The system at SDSC had a string that said "FreeBSD 3.3" in its boot messages; that's what I recall seeing when working on it. It may have been referencing some code imported from FreeBSD/dragged in elsewhere. This was the original MTA, the one with the "Tera" illuminated logo, atop the "wave" case that resembled a toolshed designed for the Mighty Morphin' Power Rangers. According to Wikipedia, the MTA-2 was delivered to the Naval Research Labs, probably at Anacostia, not to a French car company as I had thought.

jacquesm 3y ago

Any von Neumann inspired architecture is going to resemble looking at your data through a keyhole and trying to cram as much data through that keyhole as you can. There is an obvious solution to that but unfortunately it does not generalize well and it would likely be very hard to program for. This bottle-neck is what we spend a very large fraction of our time dealing with. Crack that one and you will be more famous than Bill Gates. I've seen some really nice attempts at computing fabrics but none that were able to grab any kind of market share, there was a post the other day about another Barrel Processor (https://news.ycombinator.com/item?id=37315802 https://news.ycombinator.com/item?id=37315802) which is probably why this one is posted now. But Barrel processors are still limited by the die size and need regular processors to deal with the non parallelizable parts of the code, they're a different point on the general cpu <-> specialized hardware continuum that works well for certain problems. Chances are that as we get closer to the limits of Moore's law that we will see a revival of such exotic architectures because they will be the only way forward to get more computing power. Especially workloads like AI and graph analysis could well benefit from this because the hardware and the data model overlap quite nicely.

navaati 3y ago
> There is an obvious solution to that but I'm feeling a bit dense today and it's not obvious to me. Please do tell what that solution is and why it doesn't generalize :).
- jacquesm 3y ago
  Sorry, I should have added a link: https://en.wikipedia.org/wiki/Dataflow_architecture https://en.wikipedia.org/wiki/Dataflow_architecture And the reason why it doesn't generalize: it is typically implemented in special purpose hardware.
  - JonChesterfield 3y ago
    GPUs are pretty close to an instantiation of a dataflow architecture. I have a soft spot for vliw on deterministic memory latency but the runtime scheduler + variable memory latency is probably better. The insight is that GPUs are memory driven - warps basically wait for memory operations to complete while other warps do stuff - so execution proceeds driven by memory access patterns.
    - jacquesm 3y ago
      Not quite, but yes, they are converging. But GPUs are not universal enough to be called dataflow computers. But there are some similarities. But unless I'm mistaken SIMD is fundamentally different compared to dataflow in that it executes all of the instructions in lockstep across a bunch of units rather than that each execution unit can have its own stream of opcodes. So GPUs have great performance but require that tasks be more inherently parallel than what you could (theoretically, mostly) do with a true dataflow computer.
  - jecel 3y ago
    I have twice had the experience of meeting a professor who had done their PhD in the late 1980s/early 1990s on Dataflow and were lamenting having wasted their time since it turned out to be a dead end. I pointed out to them that the computer they are currently using has a hidden Dataflow machine inside of it - it just has a front end converting the x86 code stored in memory into the dataflow graph (reorder buffers, reservation stations and so on) before actually executing it. Perhaps one day the "all advanced processors are really RISC inside" meme will get replaced with "all advanced processors are really dataflow inside". Of course, there is the option to make the dataflow visible to the outside with the EDGE (explicit data graph execution) architecture (Microsoft even showed Windows running on one).

convolvatron 3y ago

I worked a very little bit on the systems code for the MTA, and while I really enjoyed the sync bits, the limited single thread performance really made a lot of things very difficult. Later versions of the processor were integrated in the XT systems - so you could use commodity for the rest of the stuff outside the application.

linksnapzz 3y ago
Was that the FreeBSD 3.x that the original MTA was running? My recollection was that it wasn't really a product; and that the MTA-2 (after the Cray buyout) was actually sold to a couple of users (Peugeot-Citroen, I think was one...)
- convolvatron 3y ago
  its wasn't actually freebsd..it was bsd. that os continued past the cray buyout, and as far as I know continued being used even in the XMT era for local management. UCSD was the flagship customer for the MTA2 edit - it was bsd wrapped around a custom microkernel, kind of more like OSX. the original intent was that the MTA be a general purpose machine that would scale down to the desktop. so that provided the user space. there was also a very funny division of labor between the OS, the hardware, and the runtime that caused alot of anguish over the years. one the primary goals for that was extremely lightweight thread management.
  - linksnapzz 3y ago
    The system at SDSC had a string that said "FreeBSD 3.3" in its boot messages; that's what I recall seeing when working on it. It may have been referencing some code imported from FreeBSD/dragged in elsewhere. This was the original MTA, the one with the "Tera" illuminated logo, atop the "wave" case that resembled a toolshed designed for the Mighty Morphin' Power Rangers. According to Wikipedia, the MTA-2 was delivered to the Naval Research Labs, probably at Anacostia, not to a French car company as I had thought.