On Tue, 9 Sep 2008, Kirk, Benjamin (JSC-EG) wrote:
(1) eliminate the var/elem loop - just loop on elem and extract the dof
indices for all vars at once.
Certainly a good idea. Hmm... why aren't we reversing the loops in
the main project_vector calculations? Just time and effort and fear
of regressing the code?
(2) I believe the dof indices were getting added twice when
(elem->refinement_flag() == Elem::JUST_REFINED)?
(added inside the if statement and then again afterward?
Whoops - yeah, I wrote this patch in a hurry (in fact the first
version had a silly bug or two).
(3) Thread-safe by converting to a parallel reduce. The other option
would be to mutex the send_list but I expect that would perform much
worse.
Thanks; I'd intended to mutex the send_list, but I don't use threading
so the whole problem completely slipped my mind.
(4) reuse the same elem range for both threaded operations.
Good idea, I guess. Is constructing that range an expensive
operation? Is it something we should be caching in UnstructuredMesh?
I'm gonna bang on it tomorrow with many processors & threads in various
combination.
Thanks! It's clearly not the big win I hoped it would be, but even if
it's not getting at our current bottleneck, the problem it fixes would
be a bottleneck eventually.
---
Roy
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
