David Barbour wrote:
On Tue, Apr 3, 2012 at 10:47 AM, Miles Fidelman
<[email protected] <mailto:[email protected]>> wrote:
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.
I haven't used CGF. It does sound like a mess, the way you describe it.
No... the question was whether you've ever built one, not used one. I
haven't either, but engineers I've worked with have - and there are good
reasons for designing things they way they are. At least if you're
using a language where context switching is expensive.
But there are good architectures that won't become spaghetti code in
these circumstances. If you pipelined 2000 tank data objects through
four processes each instant, for example (i.e. so tanks 1-100 are in
the last process of four while 301-400 are in the first) there would
be some clear constraints on communication, and state could be updated
only at transition from one instant to another.
You're speaking theoretically, of course. The systems I'm familiar with
are fairly highly evolved and optimized. They just start from the
assumption that you can't spawn a process for every object.
You claim managing 2000 asynchronous processes is trivial. I think
you'll just find different things to complain about after you have,
say, 2000 actors processing 160000 asynchronous messages per second (4
messages per actor * 20 Hz, minimal for your example) plus managing
consistent views and safe updates of a shared map or environment, or
consistent snapshots for persistence.
What makes you assume that every actor is doing anything all the time.
A lot of them are simply sitting in one place, others are moving but not
interacting with anything. The major events are weapons fire events,
which are not happening at 20hz.
The difficult part of the job, and the one that causes a shared-nothing
approach problematic, is line-of-sight calculations - who can see whom.
Ultimately that has to be solved.
But this is far afield from the basic point: Someone suggested that
people thing sequentially, or that parallelism is more complicated than
sequential architectures. This is a very real case where that simply is
not the case - sequential approaches to this problem space are
inherently more complicated than parallel ones.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
