Matthew Knepley <[email protected]> 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.
signature.asc
Description: PGP signature
