[petsc-dev] Generality of VecScatter

[Matthew Knepley]

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

> On Thu, Nov 24, 2011 at 14:17, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>     Come on, stop being silly; it has nothing to do with the fact that it
>> is MPI+something.  It is because it is too complicated and hard to use and
>> both MPI and pthreads have bad limitations (for pthreads it is the fact
>> that pthreads does not have a good way of waking up many pthreads together
>> to do something, for MPI it is due to point to point and one sided do not
>> allow proper scheduling of communication at the low level).
>>
>
> This is why they added neighborhood collectives.
>
>
>>
>> > What about a library that was implemented in terms of MPI and pthreads,
>> but gave you a more consistent abstraction?
>>
>>    That would be fine, even great. I just don't believe that either of
>> them are the right base to build on.
>>
>
> I think of MPI as an abstraction for the network and pthreads as an
> abstraction for kernel management of threads. If you don't want to build on
> them, we need to justify why they are bad abstractions (and have different
> network or kernel-level implementations). The abstraction being good has
> nothing to do with whether it has a nice API for users, it's whether it
> provides a suitable model for the lower level (network hardware or kernel)
> upon which useful abstractions can be written.
>

We need abstractions for both execution and data access. MPI has
independent processes with barriers, and completely independent
memory augmented with messages. This is a pretty good model, however we
have the "halo problem" with high core counts (as well as
a simple lack of memory/core). Threads is one solution to this. In my
opinion, it is completely crap on all counts. An alternative model,
from the Cray, is vector processing. CUDA is basically a combination of MPI
and Vectors (everything else is incidental). I believe that this
can work since it is eminently programmable and debuggable.


>   You sound a bit like Jack telling me in 1994 that I should write PETSc
>> on top of Scalapack.
>>
>
> Or maybe like Bill suggesting that you use C and make it run on operating
> systems that exist? ;-)
>

So Seymour Cray is telling you guys not to fuck this up.

    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/cf15ede2/attachment.html>