Re: [pooma-dev] [RFC] Specialize (internal) guard cell handling, more data-flow analysis

[Richard Guenther]

James Crotinger wrote:
> It's closing in on four years since the POOMA team left the lab, so 
> memory is rusting in this regard, but...
>
> Smarts did apply data-flow to filling the guards. However, it wasn't 
> perfectly efficient as there was only one Smarts DataObject associated 
> with each patch. More parallelism could have been achieved by having a 
> data object for each guard region, and this idea was thrown around, but 
> never seriously studied. (This would allow multiple parts of the brick 
> to be written into in parallel - obviously care would have to be taken 
> in implementing this.)

Yeah, I thought of this as well, but it's too complicated.  I merely 
guess treating the guard updates as regular iterates (and exposing this 
fact too early - before data-flow analysis) is the main problem ...

> We also discussed aggregating all of the guard updates for a single 
> brick into a single iterate - the current behavior creates lots of small 
> iterates and the overhead can kill you. This may be more along the lines 
> of what you're considering.

... which the above would support.  And these single iterates indeed 
prevent you from implementing efficient guard communication schemes.

> I personally don't like the idea of putting anything to do with guards, 
> dirty-ness, etc in BrickEngine. It is a clean abstraction. If you need 
> an enhanced abstraction for MultiPatchEngine to work with, then I'd 
> build it on top of BrickEngine. That's my 2 pfennigs anyway. :)

Ok, first I thought on tackling external guards at the same time - and 
obviously BrickEngine may have external guards, so it fitted naturally.
Also dirtying a patch-view of a MultiPatchEngine would work the right 
way then (I suppose it doesn't right now - but need to check).

But yes, it should be even possible to leave it in MultiPatchEngine.

Richard.

>         Jim