<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>I expect PETSc will have some C++ (CUDA/HIP/SYCL) code for the foreseeable future, but that doesn't mean the primary implementation language needs to be C++, nor that it needs to bleed directly into a public interface. Much of the value in PETSc is higher level than GPU numerical kernels.<br></div><div><br></div><div>One issue is that 1:1 language bindings like we have now for C, Fortran, and mostly Python, don't lead to idiomatic code. Idiomatic language bindings require thought and documentation. </div><div><br></div><div>On Wed, Jul 27, 2022, at 10:55 AM, Barry Smith wrote:<br></div><blockquote type="cite" id="qt" style="overflow-wrap:break-word;"><div class="qt-"><br></div><div> Stan is less than 10 years old, has over 100,000 users and created their own language (that gets compiled to C++ code). Their community, like some optimization sub-communities) have a history of creating their own languages, unlike numerical linear algebra that didn't need to because Fortran was perfect for it :-)<br></div><div class="qt-"><br></div><div class="qt-"><div><br></div><div><div><br></div><blockquote type="cite" class="qt-"><div class="qt-">On Jul 27, 2022, at 12:29 PM, Justin Chang <<a href="mailto:jychang48@gmail.com" class="qt-">jychang48@gmail.com</a>> wrote:<br></div><div><br></div><div class="qt-"><div class="qt-"><div dir="ltr" class="qt-"><div>FWIW, vendors have poured a lot of effort into making C++ the industry standard for HPC, and it will remain that way for a very long time. Switching PETSc to a non-C/C++/Python/Fortran language today while still enabling GPU/accelerated computing could get ugly from a code implementation perspective. <br></div><div><br></div><div>Not saying you shouldn't consider other languages, but if we want the most seamless GPU experience then C++ is still the most pragmatic choice today and for the foreseeable future. And it could become even more important on tomorrow’s heterogeneous hardware architectures.<br></div></div></div><div class="qt-"><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Tue, Jul 26, 2022 at 11:09 AM Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank" class="qt-">bsmith@petsc.dev</a>> wrote:<br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204, 204, 204);"><div class="qt-"><div><br></div><div class="qt-"><div><br></div><blockquote type="cite" class="qt-"><div class="qt-">On Jul 26, 2022, at 11:30 AM, Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank" class="qt-">jed@jedbrown.org</a>> wrote:<br></div><div><br></div><div class="qt-"><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;" class="qt-">These ownership patterns need to be addressed for reliable interfaces in any language, the compiler just forces you to do it (or use the unsafe escape hatch) in Rust.<br></div><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;" class="qt-"><br></div><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;" class="qt-">I think it's necessary in any incremental porting effort for "old" code to call "new" code, due to the nature of our composition and callbacks.<br></div></div></blockquote><div class="qt-"><br></div><div> I would need to see some use cases of this to be convinced. <br></div><blockquote type="cite" class="qt-"><div class="qt-"><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;" class="qt-"><br></div><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;" class="qt-">On Tue, Jul 26, 2022, at 8:17 AM, Jeremy L Thompson wrote:<br></div><blockquote type="cite" id="qt-m_2446162622667342447gmail-m_787130091436462510qt" style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;" class="qt-"><p style="font-family:Helvetica;" class="qt-">I feel like someone has to mention the possibility of Rust.<br></p><p style="font-family:Helvetica;" class="qt-">In libCEED, we've found the FFI to C fairly painless. We made some improvements on the core C code of libCEED to facilitate Rust error handling and data ownership.<br></p><p style="font-family:Helvetica;" class="qt-">From various prototyping we've done in Jed's group, I think the more complex data ownership used in PETSc (as compared to libCEED) is one of the more complex issues that would need to be planned out for a Rust focused interface.<br></p><div style="font-family:Helvetica;" class="qt-">On 7/25/22 15:34, Barry Smith wrote:<br></div><blockquote type="cite" style="font-family:Helvetica;" class="qt-"><div style="font-family:Helvetica;" class="qt-"><br></div><div style="font-family:Helvetica;" class="qt-"> A major problem with writing a completely new version of a large code base is that one has to start with nothing and slowly build up to everything, which can take years. Years in which you need to continue to maintain the old version, people want to continue to add functionality to the old version, and people want to continue to use the old version because the new version doesn't have "the functionality the user needs" ready yet.<br></div><div style="font-family:Helvetica;" class="qt-"><br></div><div style="font-family:Helvetica;" class="qt-"> Is there an approach where we can have a new PETSc API/language/paradigm but start with a very thin layer on the current API so it just works from day one?<br></div><div style="font-family:Helvetica;" class="qt-"><ul style="font-family:Helvetica;" class="qt-"><li style="font-family:Helvetica;" class="qt-">to this would seem to require if PETSc future is not in C, there has to be a very, very easy way and low error-prone way to wrap PETSc current to be called from the new language. For example, how petsc4py wraps seems too manual and too error-prone. C++ can easily and low-error prone call C, any other viable candidates?<br></li></ul></div></blockquote></blockquote></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></blockquote><div><br></div></body></html>