Charm++ parallel programming system

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

> 2010/5/28 Phil Miller 
> <mille121 AT illinois.edu>
>>
>> On Fri, May 28, 2010 at 07:44, Haowei Huang 
>> <huangh AT in.tum.de>
>>  wrote:
>> > Hi Phil:
>> >
>> >         I encounter such a problem when I compile my program:
>> >
>> > Main.decl.h:325: error: ‘Particle’ was not declared in this scope
>> > Main.decl.h:325: error: template argument 1 is invalid
>> >
>> >
>> >         in Main.ci
>> >        array [3D] Patch {
>> >           .....
>> >           entry void receiveParticles(CkVec<Particle> updates);
>> >           .....
>> >       };
>> >
>> >        Particle is just a normal C++ class and included in Main.h. Patch
>> > object needs to call functions in Particle.
>> >
>> >       I don't know how to specify the Particle class in Main.ci or
>> > somewhere
>> > else. Should I define Particle as a chare also?
>>
>> No, you only need to define things with entry methods as chares in the
>> ci file. Though apparently undocumented, the ci file supports
>> inclusion directives that emit a #include in the decl.h file. Before
>> array [3D] Patch
>> add a line saying
>> include "Main.h";
>> or whatever more specific header defines the Particle objects.
>>
>> On a more general note, while each Patch having a collection of
>> Particle objects seems to be good object-oriented design, it tends to
>> result in poor performance. This is the classic issue of
>> array-of-structures vs structure-of-arrays layout giving
>> non-contiguous memory access patterns. There's a further issue with
>> array-of-structures, in that vector arithmetic on the elements using
>> modern SIMD hardware would require cycles to pack and unpack the
>> vector registers, while structure-of-arrays allows them to be loaded
>> and stored directly.
>>
>> Phil
>
>
>
> --
> Haowei Huang
> Ph.D. student
> Technische Universitaet Muenchen
> Institut fuer Informatik, I10
> Boltzmannstr. 3
> D-85748 Garching
> Room 01.06.061
> Phone: +49 (89) 289 18477
> mailto: 
> huangh AT in.tum.de
>