[Top][All Lists]

[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 (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.²


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]