[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Swarm-Modelling] ABMs on Graphical Processor Units
From: |
Marcus G. Daniels |
Subject: |
Re: [Swarm-Modelling] ABMs on Graphical Processor Units |
Date: |
Tue, 01 Jan 2008 12:33:58 -0700 |
User-agent: |
Thunderbird 2.0.0.9 (X11/20071115) |
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
- Re: [Swarm-Modelling] ABMs on Graphical Processor Units,
Marcus G. Daniels <=