Re: Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

David Barbour wrote:
>
>
> On Tue, Apr 3, 2012 at 9:46 AM, Miles Fidelman 
> <mfidelman@...
<mailto:mfidelman@...>> wrote:
>
>
>     And for that matter, driving a car, playing a sport, walking and
>     chewing gum at the same time 
>
>
> Would this be a Flintstones racecar?
>
>
>
>         I can think of a lot of single-threaded interfaces that put
>         people in a universe of pain. It isn't clear to me that
>         distribution is at fault there. ;)
>
>
>     Come to think of it, tracing flow-of-control through an
>     object-oriented system REALLY is a universe of pain (consider the
>     difference between a simulation - say a massively multiplayer game
>     - where each entity is modeled as an object, with one or two
>     threads winding their way through every object, 20 times a second;
>     vs. modeling each entity as a process/actor).
>
>
> Control flow is a source of much implicit state and accidental 
> complexity.
>
> A step processing approach at 20Hz isn't all bad, though, since at 
> least you can understand the behavior of each frame in terms of the 
> current graph of objects. The only problem with it is that this 
> technique doesn't scale. There are easily up to 15 orders of magnitude 
> in update frequency between slow-updating and fast-updating data 
> structures. Object graphs are similarly heterogeneous in many other 
> dimensions - trust and security policy, for example.

Hah.  You've obviously never been involved in building a CGF simulator 
(Computer Generated Forces) - absolute spaghetti code when you have to 
have 4 main loops, touch 2000 objects (say 2000 tanks) every simulation 
frame.  Comparatively trivial if each tank is modeled as a process or 
actor and you run asynchronously.

--

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra