[petsc-dev] programming model for PETSc

[Jed Brown]

On Sat, Nov 26, 2011 at 12:34, Matthew Knepley <knepley at gmail.com> wrote:

> I do not see DG a fundamentally different.
>

It's not, but there are two traversals in play: an element-based traversal
and a face-based traversal. That means that memory layout for efficient
traversal is a multi-objective problem. Of course you can do a few things
redundantly, but evaluating all the face fluxes redundantly would be
hard. Also, if you do a single traversal where cells evaluate fluxes on
some of their faces when they come to them, you lose lock-step between
threads. These are the reasons why I think it's a better test case to
understand.


> My first rule would be, never assume library intelligence. So we make it
> possible to give a schedule for kernels, but initially there is
> no scheduling code. It is user input, with a dumb default. The flat memory
> is the thread shared memory, and everything else is messages.
>

Fine, but now it looks like we have a two-level interface because we have
to know what distributed memory operations are needed before launching
kernels. The kernels don't see a global address space in any implementation
I'm aware of.


>
>
>> Can we have a way to specify the required memory access before launching
>> the kernels?
>>
>
> This is exactly what Victor's thing is about


Well sure, except that it doesn't say anything about how that would be
done. It's a model of distributed computation that currently lacks a
statement about what the interface would look like or even which things the
user specifies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111126/7b291b62/attachment.html>