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.
