7 ms·

Modeling a zombie outbreak with CUDA

25 points by darkxanthos 16y ago

rue 16y ago
"View Simulation" (http://dotslashed.com/sim2.swf http://dotslashed.com/sim2.swf) link is 404.
- woodall 16y ago
  This may be a different simulation, but try: http://dotslashed.com/sim1.swf http://dotslashed.com/sim1.swf
Luyt 16y ago
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.
tmurray 16y ago
As one of the guys responsible for CUDA, this made my day :-)
- darkxanthos 16y ago
  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 16y ago
    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 16y ago
      While extremely limited, I thought shared memory enabled interblock communications...? It's important to note I have no applications for this, just researching.
      - tmurray 16y ago
        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 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.pdf http://www.tml.tkk.fi/~timo/publications/aila2009hpg_paper.p... ).
flexd 16y ago
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.
knowaveragejoe 16y ago
Very cool, but the article itself is written very poorly.
flyhighplato 16y ago
I was in this class. We all had to do this assignment and it was really fun. Dr. Andy Johnson is a great professor.

25 points by darkxanthos 16y ago

rue 16y ago

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

woodall 16y ago
This may be a different simulation, but try: http://dotslashed.com/sim1.swf http://dotslashed.com/sim1.swf

Luyt 16y ago

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.

tmurray 16y ago

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

darkxanthos 16y ago
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 16y ago
  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 16y ago
    While extremely limited, I thought shared memory enabled interblock communications...? It's important to note I have no applications for this, just researching.
    - tmurray 16y ago
      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 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.pdf http://www.tml.tkk.fi/~timo/publications/aila2009hpg_paper.p... ).

flexd 16y ago

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.

knowaveragejoe 16y ago

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

flyhighplato 16y ago

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