The future of concurrent programming

[Robert Fraser]

Those are just comparing a thread-for-each-request model with a single-threaded model, showing the single-threaded model doing quite a bit better at high loads. The interesting graphs are on page 126, where the SEDA-based server is compared against Apache and Flash, and to a lesser extent 133, which shows pings against a single-threaded model vs. a SEDA model.

Whatever the case, though, I was just thinking of this as a concurrent-programming architecture that may feel more familiar to coders used to single-threaded development.

I didn't know games were so highly event-driven... I guess I always think of game programming by reflecting on my own short experience with it: an interconnected mess. I still wouldn't suggest SEDA for game programming, since its main focus is adaptive overload control, which shouldn't be needed in a well-controlled system. Networked gaming or AI might benefit from it, though.

Pragma Wrote:

> Robert Fraser wrote:
> > Henrik Wrote:
> > 
> >> Todays rant on Slashdot is about parallel programming and why the
> > ... [snip]
> > 
> > At work, I'm using SEDA:
> > 
> > http://www.eecs.harvard.edu/~mdw/papers/mdw-phdthesis.pdf
> 
> Wow.
> 
> Anyone doubting if this makes a difference should compare the graphs on pages 18 and 25.
> 
> > 
> > Although it's designed primarily for internet services (and indeed, I'm crafting an internet service...), I'm using
> > it for a lot more than just the server portions of the program, and I plan to use it in future (non-internet-based)
> > solutions.
> > 
> > The general idea behind something like this is "fire and forget". There is a set of "stages", each with a queue of
> > events, and a thread pool varying in size depending on load (all managed behind the scenes). The creator of a stage
> > needs only to receive an event and process it, possibly (usually), pushing other events onto other stages, where they
> > will be executed when there's time. Stages are highly modular, and tend to serve only one, or a small group of,
> > functions, but each stage is managed behind the scenes with monitoring tools that increase and decrease thread count
> > respective to thread load.
> > 
> > The advantage of such a system is it allows the designer to think in a very "single-threaded" mindset. You deal with
> > a single event, and when you're done processing it, you let someone else (or a few other people) deal with the
> > results. It also encourages encapsulation and modularity.
> > 
> > The disadvantage? It's not suited for all types of software. It's ideal for server solutions, and I could see its use
> > in various GUI apps, but it might be hard to force an event-driven model onto something like a game.
> 
> Actually, just about everything in most modern 3d games is event driven, except for the renderer. FWIW, the renderer 
> simply redraws the screen on a zen timer, based on what's sitting in the render queue, so it can easily be run in 
> parallel with the event pump.  The event pump, in turn, modifies the render queue.
> 
> The only difference between a game and a typical GUI app is that even modest event latency can be a showstopper.  The 
> renderer *must* run on time (or else you drop frames), I/O events must be handled quickly (sluggish handling), 
> game/entity events must be fast, and render queue contention must be kept very low.
> 
> > 
> > Combined with something like the futures paradigm, though, I can see this being very helpful for allowing
> > multi-threaded code to be written like single-threaded code.
> > 
> > Now only to port it to D...
> 
> 
> -- 
> - EricAnderton at yahoo