[petsc-users] PETSc with modern C++

[Michael Povolotskyi]

Hello Filippo,
we had to write a wrapper around Petsc to use both double and double 
complex functions in the same code.
We achieved  it by creating two shared object libraries and hiding Petsc 
symbols.
Once we had to achieve it for a statically linked executable, this was 
really painful, we had to change symbols in the object files.

If your wrapper can make this process easier, it would be great.
I'm not interested in developing as such, but I'm interested in the 
product and in a good performance.
Michael.

On 4/2/2017 3:15 PM, Filippo Leonardi 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);
> - 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170402/534afe52/attachment-0001.html>