RE: [pooma-dev] Assigning to internal guards

[James Crotinger]

A good starting point would be Engine/Intersector.h. You might want to step through the MultiPatch evaluation to see how this all flows. I think it currently just bails out of the process of accumulating intersected patches if its already seem the same layout ID (not the same layout - we want this bail-out even if different layouts have differing numbers of internal guards). I think you'll have to change this by building a new PETE functor that just gets you the layout reference (this may already exist) and then you'll have to do a ForEach that checks if all layouts have the same address. Hmmm. Layouts have shallow copy semantics, so what you'd really like is an operator== on layouts that just compared object identity. I'm not sure if that is there. Anyway, if all the layouts are the same, then you'd want to generate a list of patches that was the total-domain of each underlying patch. If any layout was different, then you'd have to branch to the existing intersector code. Doesn't really sound all that hard. You probably want to protect the new code with a configuration flag and maybe even a runtime flag to allow comparisons.

In your example:

 temp(I) = a(I) + b(I);
 c(I) = temp(I-1) + temp(I+1);

you should also compare with doing a and b with no guards, which they don't need in this _expression_. If your stuff is 1D, the memory is probably not an issue, but in multiple dimensions it can be a big problem - when the difference is "runs, but communicates a lot" and "doesn't run because it won't fit into memory", people tend to choose the first. :)

        Jim

-----Original Message-----
From: Richard Guenther [mailto:address@hidden]
Sent: Friday, September 27, 2002 1:57 PM
To: James Crotinger
Cc: address@hidden
Subject: RE: [pooma-dev] Assigning to internal guards

On Wed, 25 Sep 2002, James Crotinger wrote:

> We considered this and it was on the list of things to work on someday. If I
> remember correctly, we were going to try to figure out if the layouts all
> matched, including the numbers of internal guards, and if so, generate patch
> iterates that performed the operations on the entire domains, not just the
> physical domains. We already figure out if the layouts match at the
> physical-domain basis, I believe, so this didn't sound like a big extension.
> Indeed, the simplest form of this would be to check that everyone has
> exactly the same layout.
>
> Of course, in multiple dimensions you generally don't want internal guards
> on anything that you're not going to stencil, so in practice it isn't clear
> how often this practice will really pay off. (Internal guards can consume a
> lot of memory in 3D.)

We encounter this mainly with using temporaries (to do CSE). So f.i.

 temp(I) = a(I) + b(I);
 c(I) = temp(I-1) + temp(I+1);

or when using in-place stencils which need a temporary, too, like

 temp(I) = a(I) + b(I);
 a(I) = temp(I-1) + temp(I+1);

Oh - and this happens quite often so that for our local testing cluster 3d
simulations are unusable without this optimization (maybe a SCore bug with
extreme load, too, though).

Do you have any starting hints where to look at to implement what you
suggested? I.e. where is the layout matching done (f.e. for a multipatch
engine)?

Thanks, Richard.

--
Richard Guenther <address@hidden>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/