RE: [pooma-dev] Further improving guard update

[Richard Guenther]

On Sun, 28 Dec 2003, James Crotinger wrote:

> Hi Richard,
>
> Wish you had been doing this a couple of years ago, when exponential decay
> hadn't set in so firmly. :)
>
> I had been looking at similar ideas back in '99. I had considered adding a
> Smarts DataObject for each face in order to allow independent face-to-face
> dependency tracking (one would need to be careful with the corners here).

I don't think having DataObjects for the faces would help (and it would
have a cost). You'd either have to introduce DataObjects for the corners,
too (that's 72 for the 4-dimensional case, already! don't even think about
higher dimensionalities), or have overlapping DataObjects which would
surely confuse the scheduler. Oh, but we have overlapping DataObjects
anyway with the guards (but I think we're just looking at the owned domain
here from the DataObject side of view, no?).

What I'll now try to do is introducing one extra flag to the dirty mask to
indicate, wether we have the corners updated.  For this to work
efficiently, we'd need to split the intersector expressionApply into two
phases, one collecting the data about the needed guards (including wether
we need any corners), and one doing the update. If we don't need the
corners, we can do completely independend updates, if we need them, we
have to be clever.

To teach the scheduler which iterates on the same DataObject are
independend, the way to go seems to be tracking of the affected domain for
each iterate/DataObject.  I haven't gone through the details, but it
should be possible to do this.  Of course, SMARTS would need to be updated
for this, but I'm not interested in SMARTS at all (just concentrating on
native OpenMP and MPI, and maybe hybrid operation).

But I for sure are happy for any input on this matter.

Richard.

> There were complications to the idea, though I'm afraid I can't recall what
> they were. I still think this is probably the way to go - SMARTs uses these
> objects to build a dependency graph and then evaluates that graph in some
> "smart" order, hoping to reuse cache, etc. The prioritization algorithm was
> something we had planned to play with some more. (There were also some ideas
> about ways to produce fewer small iterates as these really kill you, and
> guard filling makes a lot of these.)
>
> If I have time in the next week or so (I'm taking a bit of a break over the
> holidays), I'll see if I have my old email archive on one of my computers.
> There may be some ideas in old email. I don't think these ever reached the
> level of a white paper.
>
> There are some published papers on SMARTs. The only one I have on my shelf
> is the Proceedings from ICS '99, p. 302. I'm sure there were some
> SuperComputing 9x papers as well.
>
> Cheers,
>
>       Jim