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

[Roshan D'Souza]

Regarding the blocks that you need, I have uploaded the preprint of our journal paper. It describes stuff for agent motion (collision handling), replication, environment interaction etc in a data-parallel manner. You can use these to develop cell-based system. My group will be done shortly with statistics collection methods. We will then go ahead and develop several HCI routines. Our goal is develop functionality that is availabe on current systems. we can then perhaps focus on an agent language for ABM folks.

 

my website is http://www.me.mtu.edu/~rmdsouza/ABM_GPU.html, it is the second paper in the list of references.

 

-Roshan

 

On 12/28/07, Russell Standish <address@hidden> wrote:

On Thu, Dec 27, 2007 at 10:56:55PM -0700, Marcus G. Daniels wrote:
> Russell Standish wrote:
> >The blocks need to be implementable in SIMD hardware, which pretty
> >much rules out the sort of higher level functionality you're talking
> >about.
> Not really, the Cell SDK has a complete GCC target (e.g. working
> Objective C and C++) for both the front end (PPU) and back end (SPU)
> processors.  As far as RPC infrastructure goes, it happens that when a C
> routine is called on a SPU for a Unix system call, that system call is
> actually a RPC back to the PPU.   Unfortunately, OpenMP in GCC (gomp)
> doesn't work out of the box because there are two different instruction
> sets (one 64 bit for the PPU) and (32 bit for the SPU).  But there's a
> low level library for messaging (libspe) and even a IDL stubber for
> higher level stuff:
>
> http://moss.csc.ncsu.edu/~mueller/cluster/ps3/idl.pdf

You are probably right on the Cell. I haven't studied the
architecture, nor the software environment.  There is a possibility of
me getting involved in a Cell based project at CSU Bathurst - depends
on funds, that is one problem with the private sector, you often need
to do what your customers want :(

It sounds like one could do MPI on the Cell, however, which would allow
Graphcode-based applications written in EcoLab to work.

>
> Of course, additional runtime support would be needed to implement the
> idea I mentioned, but it's not like it is necessary to use only assembly
> or compiler intrinsics to get off the ground.  Even NVidia GPUs now have
> a C-like language (CUDA).
>

GPUs are a different kettle of fish, as they are definitely SIMD based
(apply the same instruction to an array of pixels).

> >Other possibilities include artificial neural networks,
> >or fuzzy logic inference engines that could be used to implement agent
> >behaviour.
> >
> I was thinking some kind of optimization package would make a lot of
> sense for GPUs or the Cell.  Any kind of procedure that had lots of
> candidates at once -- like a genetic program or a parallel tempering
> procedure.

That too. The problem is that optimisation usually involves callbacks
into the optimisation function, which may be a full blown ABM.

>
> Marcus
> _______________________________________________
> Modelling mailing list
> address@hidden
> http://www.swarm.org/mailman/listinfo/modelling

--

----------------------------------------------------------------------------
A/Prof Russell Standish                  Phone 0425 253119 (mobile)
Mathematics
UNSW SYDNEY 2052                         address@hidden
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------
_______________________________________________
Modelling mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/modelling