Comments

That's pretty much the exact model (well, in software at least) I'm using to develop a massively scalable and massively parallel industrial controller that I'm designing at work. I can tell you, it isn't all as simple as the guy makes out when you try to solve real problems with it.

The biggest issue with scaling this solution is that you need to process everything in one buffer before you process anything in the next, unless you fall back to complex syncronisation methods. But then, enforcing across multiple cores/cpus that one buffer must be finished before the next is started becomes a really complex syncronisation issue in itself. That is to say, it looks nice until you try to scale it really large, and then you realise that it hits the same performance problems as any MIMD parallel algorithm.

The main reason I'm using a similar model is to provide an easy graphical way for non-programmers to customise the system without having to worry about concurrency, and to provide some inherent modularity to help with the scalability. I don't think it's a good solution in general, but it's a good solution for what I need, and the paradigm is easy for non-programmers.

Maybe I'm missing something, but I'm still not sure what all the fuss about concurrency and threading is. Thinking about it some more, I reckon the people that complain about the complexity in managing muticies are also the same people who complain about the complexity in manual garbage collection. For concurrency we just need to develop similar models to those we have to help with garbage collection, ideas like reference counting and whatnot... as well as the tools to analyse programs for problems, much like valgrind and splint.

Actually, thinking about it some more, one really big problem with this model is one that is well known in the field of circuit design, and that is Hazards. I don't see any mention of how to deal with those on his site. They're basically the circuit equivalent of a race condition that you would see in multi-threaded software.