Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

On Fri, May 28, 2010 at 15:02, Haowei Huang 
<huangh AT in.tum.de>
 wrote:
> 2010/5/28 Phil Miller 
> <mille121 AT illinois.edu>
>>
>> On Fri, May 28, 2010 at 14:11, Haowei Huang 
>> <huangh AT in.tum.de>
>>  wrote:
>> >     yes, you are right, it is a AOS and SOA problem. To solve this
>> > problem,
>> > we could use
>> > Compute object for Computation between Patches as showed in your
>> > publication. The
>> > message sent to Compute object is SOA, right? Is that a way you design
>> > to
>> > fix the locality
>> > problem?
>>
>> The problem is still there, though partially mitigated. When your
>> Patch objects sum the forces on the particles as they come back from
>> Computes, the force variables being written to will still be spread
>> out through memory. The same problem will also arise when integrating
>> the motion of the particles; for each Particle, you read its force
>> variables and write its velocity and position variables, thus ending
>> up with interspersed reads and writes of things that aren't operated
>> on in a nice vector fashion.
>
>    Ok. It is a problem in your Spatial and Force decomposition strategy,
> right?

This is not a problem of the parallel decomposition strategy. It's
purely a problem of data representation. If you send or store arrays
of structures (AOS, as you write it), then the data will be laid out
as AOS, and accessed as AOS, with the problems that implies. If you
send and stores a set of arrays, each holding a particular data
element for all of the represented entities (particles, here), then
you will get the locality benefits from SOA.