[petsc-dev] Generality of VecScatter

[Dmitry Karpeev]

On Thu, Nov 24, 2011 at 11:45 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Thu, Nov 24, 2011 at 11:31, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>  You seem to have the tact assumption that the choice is between MPI+X or
>> some PGAS language, this I say is a major straw man! (And I totally agree
>> with you PGAS language are junk and will never take off).
>>
>>     What I am suggesting is there is a third alternative that is
>> compatible with MPI (allowing people to transition from MPI to it without
>> rewriting all current MPI based code) and is COMPLETELY library based (as
>> MPI is). This new thing would provide a modern API suitable for many core,
>> for GPUs and distributed computing and the API would focus on moving data
>> and scheduling tasks. The API will be suitable for C/C++/Fortran 90. Now
>> exact details of the API and the model are not clear to me of course. I
>> will be pushing the MCS CS folks in this direction because I don't see any
>> other reasonable alternative (MPI+X is fundamentally not powerful enough
>> for the new configurations and PGAS are a joke).
>>
>
> I just wrote the following in a private discussion with Barry and Matt.
> Copied here for the rest of you.
>
> Do you want to abandon MPI as a foundation for distributed memory, or do
> you just want a reliable way to manage multicore/SMT? I am far from
> convinced that we can't or shouldn't build our ultimate communication
> abstraction on top of MPI. In my opinion, the job of MPI is to abstract
> non-portable network-level details to provide a minimal set of primitives
> on which to write performant code and to implement libraries. Of course
> there is some unnecessary cruft, and there are occasional holes where
> networks can do cool things that are useful to libraries, but have not been
> exposed through MPI. But cleaning that stuff up is what I think new MPI
> standards should be targeting.
>
> I do not believe the goal of MPI is to provide abstractions that are
> directly usable by applications. That is the scope of domain-specific and
> general-purpose libraries. If an abstraction can be implemented with
> portable performance using primitives in MPI, then it should *not* be added
> to MPI.
>
> I know that you want these cool high-level persistent communication
> primitives.
>

What's the general flavor of these "high-level persistent communication
primitives"?
I think it's important to define them at least somewhat in order to
understand the rest of the discussion copied here.


> I want them too, but I don't want them *inside* of MPI, I want them in
> their own portable library. For the library to be portable, its network
> operations should be defined using some portable low-level communication
> interface. If only one of those existed...
>
> We can deal with distribution later so it's not a pain for users to get
> these things installed.
>
> As a general rule, I would much prefer that these high-level primitives be
> libraries that use MPI (and are created using communicators), otherwise
> they will not compose with other libraries and I think will suffer the fate
> of the PGAS languages, Smalltalk, Lisp, GA, etc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111124/35c5d395/attachment.html>