> On Apr 2, 2017, at 2:15 PM, Filippo Leonardi <filippo.l...@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.