<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 2, 2017 at 2:15 PM, Filippo Leonardi <span dir="ltr"><<a href="mailto:filippo.leon@gmail.com" target="_blank">filippo.leon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>Hello,</div><div><br></div><div>I have a project in mind and seek feedback.</div><div><br></div><div>Disclaimer: I hope I am not abusing of this mailing list with this idea. If so, please ignore.</div><div><br></div><div>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.</div><div><br></div><div><span style="line-height:15.6px">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).</span><br></div><div><br></div><div>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 <span style="line-height:1.5">really include in this wrapper, that I found nowhere):</span></div><div><span style="line-height:1.5">- I am currently only thinking about the Vector/Matrix/KSP/DM part of the Framework, there are many </span><span style="line-height:1.5">other cool things that PETSc does that I do not have the brainpower to consider those as well.</span></div><div>- 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);</div><div>- those expression templates should use SSE and AVX whenever available;</div><div>- expressions like x += alpha * y should fall back to BLAS axpy (tough sometimes this is not even faster than a simple loop);</div></div></blockquote><div><br></div><div>The idea for the above is not clear. Do you want templates generating calls to BLAS? Or scalar code that operates on raw arrays with SSE/AVX?</div><div>There is some advantage here of expanding the range of BLAS operations, which has been done to death by Liz Jessup and collaborators, but not</div><div>that much.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>- all calls to PETSc should be less verbose, more C++-like:</div><div>  * for instance a VecGlobalToLocalBegin could return an empty object that calls VecGlobalToLocalEnd <span style="line-height:1.5">when it is destroyed.</span></div><div>  * some cool idea to easily write GPU kernels.</div></div></blockquote><div><br></div><div>If you find a way to make this pay off it would be amazing, since currently nothing but BLAS3 has a hope of mattering in this context.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>- the idea would be to have safer routines<span class="m_-1883525242653817249m_-9209114810536857738inbox-inbox-Apple-converted-space" style="line-height:15.6px"> </span><span style="line-height:15.6px">(at compile time)</span><span style="line-height:1.5">, by means of RAII etc.</span></div><div><br></div><div>I aim for zero/near-zero/negligible overhead with full optimization, for that I include benchmarks and extensive test units.</div><div><br></div><div>So my question is:</div><div>- anyone that would be interested (in the product/in developing)?</div><div>- anyone that has suggestions (maybe that what I have in mind is nonsense)?</div></div></blockquote><div><br></div><div>I would suggest making a simple performance model that says what you will do will have at least</div><div>a 2x speed gain. Because anything less is not worth your time, and inevitably you will not get the</div><div>whole multiplier. I am really skeptical that is possible with the above sketch.</div><div><br></div><div>Second, I would try to convince myself that what you propose would be simpler, in terms of lines of code,</div><div>number of objects, number of concepts, etc. Right now, that is not clear to me either.</div><div><br></div><div>Baring that, maybe you can argue that new capabilities, such as the type flexibility described by Michael, are enabled. That</div><div>would be the most convincing I think.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If you have read up to here, thanks.</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-1883525242653817249gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>