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.
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. On Tue, Jul 26, 2022 at 11:09 AM Barry Smith <[email protected]> wrote: > > > On Jul 26, 2022, at 11:30 AM, Jed Brown <[email protected]> wrote: > > 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. > > 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. > > > I would need to see some use cases of this to be convinced. > > > On Tue, Jul 26, 2022, at 8:17 AM, Jeremy L Thompson wrote: > > I feel like someone has to mention the possibility of Rust. > > 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. > > 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. > On 7/25/22 15:34, Barry Smith wrote: > > > 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. > > 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? > > - 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? > > >
