[petsc-users] PETSc with modern C++

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

>> BLAS. (Here a interesting point opens: I assume an efficient BLAS
>>
>> implementation, but I am not so sure about how the different BLAS do
>> things
>>
>> internally. I work from the assumption that we have a very well tuned BLAS
>>
>> implementation at our disposal).
>>
>
> The speed improvement comes from pulling vectors through memory fewer
> times by merging operations (kernel fusion).

Typical examples are VecMAXPY and VecMDot, but note that these are not
xGEMV because the vectors are independent arrays rather than single
arrays with a constant leading dimension.

>> call VecGetArray. However I will inevitably foget to return the array to
>>
>> PETSc. I could have my new VecArray returning an object that restores the
>>
>> array
>>
>> when it goes out of scope. I can also flag the function with [[nodiscard]]
>> to
>>
>> prevent the user to destroy the returned object from the start.
>>
>
> Jed claims that this pattern is no longer preferred, but I have forgotten
> his argument.
> Jed?

Destruction order matters and needs to be collective.  If an error
condition causes destruction to occur in a different order on different
processes, you can get deadlock.  I would much rather have an error
leave some resources (for the OS to collect) than escalate into
deadlock.

> We have had this discussion for years on this list. Having separate names
> for each type
> is really ugly and does not achieve what we want. We want smooth
> interoperability between
> objects with different backing types, but it is still not clear how to do
> this.

Hide it internally and implicitly promote.  Only the *GetArray functions
need to be parametrized on numeric type.  But it's a lot of work on the
backend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170403/14b394dd/attachment.pgp>