Comment by jacquesm | Hacker News Reader

Comment by jacquesm | Hacker News Reader

Parent Full thread

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.

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.

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

Reply on news.ycombinator.com