

Modeling a zombie outbreak with CUDA - darkxanthos
http://dotslashed.com/gpu_project2.html

======
tmurray
As one of the guys responsible for CUDA, this made my day :-)

~~~
darkxanthos
I came across this trying to learn more about CUDA and OpenCL. Specifically I
was trying to find information on bending GPUs to be useful for actor model...
zombies were an awesome bonus!

~~~
tmurray
It's not really suited to CUDA/OpenCL; for the purposes of this discussion, we
can treat the two as the same because the execution model of actual kernels is
almost identical. The problems are

\- the size of the grid is fixed at kernel launch time, so you can't
arbitrarily spawn more work

\- the completion of one block cannot depend on the execution of another
block, which means inter-block communication within a kernel is forbidden

So you could do some sort of block-local actor operation then do an exchange
of the halo cells between blocks in another kernel (the only global
synchronization point allowed in CUDA/OpenCL), but that seems really painful,
especially if actors are sparse within your grid. A work queue approach would
probably work better; you'd certainly get better utilization and load
balancing than trying to spatially partition a large grid.

~~~
darkxanthos
While extremely limited, I thought shared memory enabled interblock
communications...? It's important to note I have no applications for this,
just researching.

~~~
tmurray
No, shared memory is only for intra-block communication. __syncthreads() only
ensures that every thread in a block is at a particular point rather than
every block in a grid.

Take Fermi, for example--you can potentially have 128 blocks running
concurrently (8 blocks per multiprocessor, 16 multiprocessors on GF110), but
you can launch a grid of 65535x65535 blocks in a single kernel. As a result,
if you try to do arbitrary global synchronization, you'd have a state
explosion (PDF: <http://www.gdiamos.net/papers/stateExplosion.pdf> ). The best
way to solve a problem with significant interaction between data elements is
to use a persistent work queue (as described in PDF:
[http://www.tml.tkk.fi/~timo/publications/aila2009hpg_paper.p...](http://www.tml.tkk.fi/~timo/publications/aila2009hpg_paper.pdf)
).

------
rue
"View Simulation" (<http://dotslashed.com/sim2.swf>) link is 404.

~~~
woodall
This may be a different simulation, but try:

<http://dotslashed.com/sim1.swf>

------
knowaveragejoe
Very cool, but the article itself is written very poorly.

------
Luyt
You can't go wrong with zombies: the public loves them.

 _It is necessary to initialize all variables. This will cause a run time
error._

This probably should read: 'accessing uninitialized variables causes a runtime
error'.

 _It is necessary to check your memory indexes for all data structures, if
they are wrong you will have run time errors._

What would be a 'memory index'? An index into an array? Yes indeed, an out-of-
bounds array index will cause an error sooner or later. If your language
doesn't check array bounds, like C, the bugs will be subtle and insidious.

------
flyhighplato
I was in this class. We all had to do this assignment and it was really fun.
Dr. Andy Johnson is a great professor.

------
flexd
I can't think of a better way of utilizing spare GPU power. It's important to
predict our zombie doom to give us time to prepare.

