[petsc-users] PETSc with modern C++

[Barry Smith]

> On Apr 2, 2017, at 2:15 PM, Filippo Leonardi <filippo.leon at gmail.com> wrote:
> 
> 
> Hello,
> 
> I have a project in mind and seek feedback.
> 
> Disclaimer: I hope I am not abusing of this mailing list with this idea. If so, please ignore.
> 
> As a thought experiment, and to have a bit of fun, I am currently writing/thinking on writing, a small (modern) C++ wrapper around PETSc.
> 
> Premise: PETSc is awesome, I love it and use in many projects. Sometimes I am just not super comfortable writing C. (I know my idea goes against PETSc's design philosophy).
> 
> I know there are many around, and there is not really a need for this (especially since PETSc has his own object-oriented style), but there are a few things I would like to really include in this wrapper, that I found nowhere):
> - I am currently only thinking about the Vector/Matrix/KSP/DM part of the Framework, there are many other cool things that PETSc does that I do not have the brainpower to consider those as well.
> - expression templates (in my opinion this is where C++ shines): this would replace all code bloat that a user might need with cool/easy to read expressions (this could increase the number of axpy-like routines);
> - those expression templates should use SSE and AVX whenever available;
> - expressions like x += alpha * y should fall back to BLAS axpy (tough sometimes this is not even faster than a simple loop);

   People have been playing with this type of thing for well over 20 years, for example,

Rebecca Parsons and Dan Quinlan. A++/P++ array classes for architecture independent finite difference computations. In Proceedings of the Second Annual Object-Oriented Numerics Conference (OONSKI’94), April 1994.

and it seems never to have gotten to the level of maturity needed for common usage (i.e. no one that I know of uses it seriously). 

Has something changed in

1) the templating abilities of C++ (newer better standards?)

2) people's (your?) abilities to utilize the templating abilities that have always been their?

3) something else?

that would make this project a meaningful thing to do now? Frankly, not worrying about technical details, couldn't someone have done what you are suggesting 20 years? I actually considered trying to utilize these techniques when starting PETSc 2.0 but concluded that the benefits are minimal (slightly more readable/writable code) while the costs are an endless rat-hole of complexity and unmaintainable infrastructure; that only the single super-clever author can understand and update.

   Barry







> - all calls to PETSc should be less verbose, more C++-like:
>   * for instance a VecGlobalToLocalBegin could return an empty object that calls VecGlobalToLocalEnd when it is destroyed.
>   * some cool idea to easily write GPU kernels.
> - the idea would be to have safer routines (at compile time), by means of RAII etc.
> 
> I aim for zero/near-zero/negligible overhead with full optimization, for that I include benchmarks and extensive test units.
> 
> So my question is:
> - anyone that would be interested (in the product/in developing)?
> - anyone that has suggestions (maybe that what I have in mind is nonsense)?
> 
> If you have read up to here, thanks.