4 ms·

What makes it work well on a distributed system? The value of such an approach lives and dies on how well-defined the problem space is. If the domain covered b

by gruseom 17y ago

What makes it work well on a distributed system? The value of such an approach lives and dies on how well-defined the problem space is. If the domain covered by those events is relatively walled-off and has a very clear protocol for interacting with the rest of the system, that's good. But if it turns out to require lots of special cases, you end up wanting (and probably hacking your way to get at) a general-purpose language and can end up with something more complicated. Event propagation in response to unpredictable signals from hardware is pretty much what GUI logic consists of. GUI event handling written the obvious way quickly generates into spaghetti under complexity. I've often wondered about a better way, since much of that complexity doesn't feel intrinsic. I don't know much about games but it seems like a lot of them might be in the sweet spot for this approach, with a lot of complexity that can be expressed using such rules and encapsulated in a way that works nicely with the rest of the program. The devil is in the details, though.

phugoid 17y ago
If you use the shared memory approach on a distributed system, each node has a copy of the shared memory, and there's infrastructure for keeping all that memory synchronized. At least that's one way of doing it. In the event-based approach they implemented, different nodes (PCs) subscribe just to the events they are interested in. It's light-weight, easy to understand, monitor and debug, and it fits the problem well in this case.
- sparky 17y ago
  In computer architecture terms, the pub/sub system opens the door to more efficient communication in a multiprocessor system, since the data sharing is explicitly known by virtue of the subscriptions; furthermore, a sufficiently intelligent runtime, compiler, or partitioner can optimally (or close) map calculations to processors. How much of a win you get in practice depends on the actual intelligence of the tools and the hardware you're running on. If you're running on a multicore or SMP (e.g., a quad-socket box) hardware cache coherence will do the heavy lifting for you; each processor won't have its own copy of the data, it will be shuttled around to just the processors that need it. On larger-scale systems, a more message-passing approach is indeed the way to go; in fact, it is often the only way to go, since most large-scale machines outside of integrated supercomputers (Cray et al.) don't support shared memory.

by gruseom 17y ago

phugoid 17y ago

If you use the shared memory approach on a distributed system, each node has a copy of the shared memory, and there's infrastructure for keeping all that memory synchronized. At least that's one way of doing it. In the event-based approach they implemented, different nodes (PCs) subscribe just to the events they are interested in. It's light-weight, easy to understand, monitor and debug, and it fits the problem well in this case.

sparky 17y ago
In computer architecture terms, the pub/sub system opens the door to more efficient communication in a multiprocessor system, since the data sharing is explicitly known by virtue of the subscriptions; furthermore, a sufficiently intelligent runtime, compiler, or partitioner can optimally (or close) map calculations to processors. How much of a win you get in practice depends on the actual intelligence of the tools and the hardware you're running on. If you're running on a multicore or SMP (e.g., a quad-socket box) hardware cache coherence will do the heavy lifting for you; each processor won't have its own copy of the data, it will be shuttled around to just the processors that need it. On larger-scale systems, a more message-passing approach is indeed the way to go; in fact, it is often the only way to go, since most large-scale machines outside of integrated supercomputers (Cray et al.) don't support shared memory.