<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 10 July 2018 at 13:06, Mark Adams <span dir="ltr"><<a href="mailto:mfadams@lbl.gov" target="_blank">mfadams@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>If PETSc was an application, it could do whatever it wanted, but it's not.  If PETSc is a library that intends to meet the needs of HPC applications, it needs to support the programming models the applications are using.  </div></div></div></div></blockquote><div><br></div></span><div>To repeat, PETSc supports threads, currently with MKL kernels and third party solvers (hypre), and GPUs with native solvers and again through hypre. I'm sure we will add more mechanism in the future. (I really don't know how to say this any more clearly.)</div></div></div></blockquote><div><br></div><div>And let's not forgot the "E" for extensible within PETSc.</div><div><br></div><div>Despite the notion held by many in the committee that "PETSc does not support threads" there is absolutely nothing which prohibits a knowledgeable user from using threads (or any other form of "X") within their own custom implementation of KSP, PC, Mat, Vec etc which then naturally then plugs into the rest of the PETSc ecosystem. In fact, it's often far simpler to incorporate "X" via a custom implementation since the knowledgeable user is responsible for compiling their custom thing and does not have to make it natively work with PETSc's configure.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Or I suppose you will continue to disparage everyone who doesn't bow down and worship flat MPI on homogeneous big-core machines as a divine execution model until your users abandon you for otherwise inferior software that is willing to embrace user requirements.</div></div></div></div></blockquote><div><br></div></span><div>I agree, and I suspect we have a consensus that we should not disparage threads publicly as much (or at all) in the future as we have. </div></div></div></blockquote><div><br></div><div>This would be a great thing - and I'm happy to hear Barry will accept such branches. <br></div><div><br></div><div>I have been in the situation where a project in review proposing to do things with GPUs and OpenMP within PETSc was almost killed because the reviewers truly believed that "PETSc does not support threads". The consensus held was that the project would only be possible if we used Trilinos. I don't know how many times the reviewer wrote "PETSc does not support threads". The reviewer did not understand what, or how, the "E" in PETSc can be easily exploited to incorporate accelerators "within" the PETSc ecosystem. It was explained in the project proposal, but the strong (and loud) stance adopted regarding PETSc and threads prevented them from even thinking about the proposal content. A reviewer should not even have to understand how the extensibility works - but it would be great if in future, reviewers (I'm assuming they are representative of the larger community) simply didn't reject projects out of hand because they used the words "PETSc" and "threads" in the same sentence. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>It just does not do any good. Those that get it get it and those that don't don't.</div></div></div></blockquote><div> </div><div>Exactly. And sometimes those that don't get it are reviewing our projects.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div><br></div></div>