The Tera Computer System (1990) | Hacker News Reader

The Tera Computer System (1990)

citeseerx.ist.psu.edu

50 pointstwoodfin21 comments

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.

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) 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.

> 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 :).

Sorry, I should have added a link:

https://en.wikipedia.org/wiki/Dataflow_architecture

And the reason why it doesn't generalize: it is typically implemented in special purpose hardware.

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.

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.

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).

Hello Jecel, your work was just what I had in mind when writing about this. How are you doing? Any major progress? I'd really love to see you succeed, I think what you were working on is one of the most interesting developments in computing.

We are still moving forward and hope to have interesting things to show soon. For any other readers, my Morphle Engine (aka SiliconSqueak 5) processor design has many elements in common with EDGE (and so with Dataflow as well).

I found the reference to Windows running on Microsoft's E2 processor (which in turn has links to relevant papers):

https://www.theregister.com/2018/06/18/microsoft_e2_edge_win...

I should also have mentioned The Mill architecture as an example of dealing with code as blocks of instructions instead of each one separately. In this case they get a higher fetch rate for their VLIW machine by starting execution from the middle of the block and fetching both up and down at the same time. So they have two program counters which get set to the same value on every jump or call.

https://millcomputing.com/

The point is that inside every advanced processor instructions are handled in groups and if you expose that to the compiler you can save transistors and energy.

I think the other reality is that modern silicon increasingly adopts and blends aspects of many of these alternative architectures well enough that you can capture much of the potential value without designing silicon dedicated to it.

This is the same pattern with how most modern programming languages are credible approximations of procedural, object-oriented, functional, etc programming models if you choose to use them that way. The flexibility and optionality created by not being dedicated to a single paradigm has its own value.

Yes, that scenario has played out many times now. Every time there is a viable specialist CPU on the horizon the useful bits get incorporated and the effort fails. The GPUs have been a bit of an exception to that rule probably because they did not seem to be a threat to the main CPU vendors but were seen as complimentary and their broader processing power was revealed only after they were solidly established through the gaming world.

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.

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...)

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.

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.

there is an architecture document called 'Principles of Operation' which is the quintessential reference. I can't find it online, but apparently there is a copy at the Computer History Museum. Does anyone know if I can just go to Mountain view?

I'd contact them first.

I couldn’t figure out why this was here, but I guess it’s because there’s a new barrel processor design: https://news.ycombinator.com/item?id=37315802

Yes, agreed, that's probably why this was posted.

I mentioned the MTA in a comment on that thread. I assume somebody picked up on that, or independently knew about the architecture.

Somebody tried to get me to be a friendly user of MTA when it first came out. I took a look- they pitched it as useful for graph processing rather than simulations- and concluded that the architecture was not going to be competitive with intel in the long term, and ignored it.

Reply on news.ycombinator.com