[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:rguenth at tat.physik.uni-tuebingen.de] 
Sent: Friday, September 27, 2002 1:57 PM
To: James Crotinger
Cc: pooma-dev at pooma.codesourcery.com
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 <richard.guenther at uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20020927/f92a58af/attachment.html>