|
From: | Richard Guenther |
Subject: | [RFC] Specialize (internal) guard cell handling, more data-flow analysis |
Date: | Wed, 07 Jul 2004 19:22:59 +0200 |
User-agent: | Mozilla Thunderbird 0.6 (X11/20040605) |
The problem is we "lower" the representation of guard cells and necessary updates of them too early (in the intersectors) and create usual iterates out of them. A better approach would be to compute necessary guards at intersection time only (as I introduced in the previous performance improvement patches), _not_ update them, but store this information in the iterates. We can then, before finally issuing the iterates, do data-flow analysis of the necessary guard cells and
insert optimal update iterates at optimal places (in principle).As iterates are per-patch, in the process of getting the above done, I'd suggest moving the dirty flag and its handling from the MultiPatchEngine down to the BrickEngine, together with more accurate information about the up-to-date-ness of the guards (use f.i. a GuardLayer<> to count the up-to-date cells).
Were there any previous plans on improving this situation within POOMA? Did you never experience performance problems with the communication? How did SMARTS improve situation with the guard updates (did it?)?
Thanks for any input (before I start hacking this up)! Richard.
[Prev in Thread] | Current Thread | [Next in Thread] |