[petsc-dev] PETSc future starting as a new design layer that runs on top of PETSc 3?

[Justin Chang]

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 <bsmith at petsc.dev> wrote:

>
>
> On Jul 26, 2022, at 11:30 AM, Jed Brown <jed at jedbrown.org> 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?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220727/74d56340/attachment.html>