adruab.net Deep internal/external searching… for… stuff

11Jan/092

Parallelismorama

First some comments. I've been reading some posts on the Sweng Gamedev mailing list. I'm a bit surprised that people are so hooked on super general lock free structures (e.g. a doubly linked list). They are complex to reason about and correspondingly hard to write. I've used big arrays with and simple atomic indices to great effect thus far and haven't needed such complicated mechanism. Perhaps it's console vs PC all over again, but I generally consider simplicity to be one of the most important aspects of parallel code I write.

One of the things that I've always disliked about CSP and Task based systems is how insanely broken readability gets. Adding task indirection wraps everything in goo. With lambdas/delegates in C# you've still got Task this Future that, but that's astronomically more readable than the C++ equivalent. I tried watching the PDC08 presentations and my eyes glazed over. Such simple concepts and ALL these crazy hoops to jump through. Now there's definitely an argument for explicitness when overhead is involved. And sure the C++ version is probably faster, but that much? Really?

I read Expert F# recently, a decent book on a cool language (functional with Haskell headaches). It has cool syntactic sugar called workflow builders, which are wrappers around continuations. They allow you to do write very straight simple code with asynchronous breaks in the middle. I haven't figured out yet if it's A) not explicit enough B) too slow because of compiler optimization deficiency or C) super awesome.

Additionally, I'm not sure I buy the each system runs asynchronous technique Intel's Smoke uses. Either I haven't read it close enough or there would be a direct competition between evil latency and the number of asynchronous stages. Lets assume everything uses deferred message passing you've got Input/player AI + physics + render + gpu + scan = a lot of latency at 30 or even 60 Hz. I imagine pipelining some part of drawing in immediate mode would have zero or net-good effect on latency. Breaking up the rest though would be hard. There are certainly obvious choices for deferred computation (e.g. effects, most AI). But player + physics is still a bigish serial bowling ball to chew on. Maybe staging physics so each stage only cares about objects that can influence that stage, and interleaving the rest with initial render submission? I'll keep that in the back of my brain, so I don't go berzerk trying to figure out how to limit the serializing effect script callbacks can have.

Comments (2) Trackbacks (0)
  1. I’m in Seattle every weekend lately. We should hang out!:-)

  2. Cool, though you’re probably not interested in me discussing parallelism :P.


Leave a comment

No trackbacks yet.