[petsc-dev] Generality of VecScatter

Matthew Knepley knepley at gmail.com
Thu Nov 24 16:26:13 CST 2011


On Thu, Nov 24, 2011 at 4:10 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Thu, Nov 24, 2011 at 16:01, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>   Yes, but they can only get access to that shared variable one at a
>> time: first get's it, then second get's it, then third gets, .... Ok for a
>> couple of cores but not for dozens.
>>
>>   Take a look at src/sys/objects/pthread.c for the various ways we have
>> coded for "waking" the threads. Maybe I am missing something but this is
>> the best Kerry and I could figure out.
>>
>
> What exactly should I be looking at? Can't you have all the threads spin
> on a normal shared variable (not a mutex) that is only written by the
> thread that needs to spark them? Or use a fetch-and-add atomic if you want
> to keep track of how many are running or limit the number? The latter could
> use a tree to get logarithmic cost, but if they are stored next to each
> other, you would still have O(P) cache invalidations.
>

This is one great reason that vectorization works and pthreads is crap. I
am not totally sold on the thread block system, but
it looks like genius compared to pthreads. I would start there.

  Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111124/0110b8ea/attachment.html>


More information about the petsc-dev mailing list