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

[Jacob Faibussowitsch]

Responding to 2 things here:

> Jacob, would you consider VTK to be "Modern C++"? It was designed in the 90s and I think C++11 isn't widely used (architecturally) since it was first allowed a few years ago.


I don’t know, I have personally never interacted or read their codebase. Certainly any library that is pre-C++11 will have old C++ cruft. To give a counter-example, I would consider Kokkos or Thrust to be relatively modern C++ libraries.

> Does clang work with a high enough level of abstraction in its representation of C++ to map directly to Python classes, for example.

Sure, we can walk the Clang AST. But then we are in the business of writing a domain-specific language, and are firmly tied to a compiler. From my time writing the clang linter I am personally very comfortable with libclang but I can tell you that it:

A. Takes a while to get up to speed. AST closely align with the source but are not overly “friendly". As an example, try walking the AST backwards (to for example find wherever a variable is written to). You’ll find this is a monumental undertaking.
B. Many small idiosyncrasies to learn that are somewhat sparsely documented. There are also no real “examples” to copy/learn from.

> Does Python have any useful high-level representation that could be used so that we write in Python and generate from its representation?

Yes, Python exposes the “ast” module for direct introspection of Python code https://docs.python.org/3/library/ast.html. You can then use this to generate arbitrary code. Team green uses this in their WARP library (https://github.com/NVIDIA/warp) to generate CUDA kernels from python src. But doing so has enormous pitfalls, mostly to do with optimization. Python famously optimizes almost nothing because you can never be sure that an expression doesn’t have a side-effect.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

> On Jul 31, 2022, at 12:09, Barry Smith <bsmith at petsc.dev> wrote:
> 
> 
>> My issue with C++ is not the language itself, but the lack of discipline of C++ developers. There are disastrous stories we all know well. But there are successful ones, like VTK/ParaView.
> 
>   I fear that it would be difficult to learn and maintain discipline in PETSc C++ developments. We are largely self-taught, want functionality quickly, and the google approach to learning C++ and implementing PETSc will be a disaster. We would need to have a starting mechanism that prevents the monkeys with machine guns.
> 
>   To do multiple language mappings properly, I think we need to start with a language with a powerful, high-level useful AST (or some similar representation) that automated tools can scarf through to generate language bindings and verify the code is properly written from day one. Rather than picking the language based on its syntax, flexibility etc, we should pick it based on this property. Does clang work with a high enough level of abstraction in its representation of C++ to map directly to Python classes, for example. Does Python have any useful high-level representation that could be used so that we write in Python and generate from its representation? Rust? Zig? Carbon? Fortran 2035?
> 
> 
> 
>> On Jul 31, 2022, at 10:26 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> 
>> 
>> 
>> On Sun, 31 Jul 2022 at 17:07, Matthew Knepley <knepley at gmail.com> wrote:
>> On Sun, Jul 31, 2022 at 9:06 AM Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> On Sun, 31 Jul 2022 at 16:41, Jacob Faibussowitsch <jacob.fai at gmail.com> wrote:
>> 
>> > Please don't take my words as advocacy for C++
>> 
>> I’m going to pretend like I didn’t read this :)
>> 
>> Whatever the final decision is, PETSc should keep providing a plain C API. C is lingua franca, C++ is not. Many other programming languages have runtime FFIs mostly based on the C ABI guarantees (Java, Python, MATLAB, Rust, Julia, etc). C++ may be great for development, but I do not consider it great for crossing language boundaries. 
>> 
>> Maybe the right approach for petsc4py is to first get nice and modern  C++ bindings implemented by wrapping the C interface. And then map these C++ bindings to Python.
>> 
>> My crystal ball says that such a C++ binding would eventually be thrown away just as in the case of MPI.
>> 
>> MPI C++ failed because it provided little added value. But if a PETSc C++ API would become the base of bindings for other OO languages, then there is value in maintaining these C++ bindings.
>> Furthermore, these C++ bindings could serve as the foundation for a reimplementation of PETSc in C++, if that ever happens. And that can be done gradually.
>> 
>> PS: Modern C++ is a great language to implement stuff. People using C++ is another story, it is like giving a machine gun to monkeys. Well, at this point, I could say exactly the same about Python. 
>> My issue with C++ is not the language itself, but the lack of discipline of C++ developers. There are disastrous stories we all know well. But there are successful ones, like VTK/ParaView.
>> 
>> 
>> -- 
>> Lisandro Dalcin
>> ============
>> Senior Research Scientist
>> Extreme Computing Research Center (ECRC)
>> King Abdullah University of Science and Technology (KAUST)
>> http://ecrc.kaust.edu.sa/
>