Re: [Swarm-Modelling] ABMs on Graphical Processor Units

[Marcus G. Daniels]

Steven H. Rogers wrote:
> IIRC, each SPU has an MMU to coordinate DMA transfers between local 
> and shared memory, so data can be streamed in and out efficiently.  
> The SPUs shouldn't need to keep much data local for workloads that can 
> be structured to take advantage of this.
Good point, here's one idea..

When an agent was sent a message, that call would block until a SPU was 
free and then send the message to SPU.  The SPU then has a handle to 
that agent (and perhaps some user-supplied parameters and can send 
messages to itself to get more handles).  This would not be a virtual 
machine setup, but simply a multi-architecture compile of the same code 
with some efficient way to send messages over the Cell EIB.  In this 
sense of remote procedure calls for everything, it's not necessary to 
land whole objects on the local stores, just handles.  (It might be 
useful to do balance memory over the local stores, along the lines of 
the Kendall Square Research COMA machines, but that's a refinement.¹)

One way to use the fast 256K local store to good effect would be 
accumulate transactions in it.   That is, any object that would 
otherwise need locks for parallel access, like a 2d space or a shared 
list, would have a proxy that didn't directly modify the space, but 
instead prepared a block of information to send back to the PPU for 
validation.  Upon receipt, the PPU could see if others had changed the 
reference copy relative to what was expected by the transaction record, 
and if not, go ahead and commit it to RAM.²

Marcus

¹ http://en.wikipedia.org/wiki/Kendall_Square_Research
² http://en.wikipedia.org/wiki/Transactional_memory