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

Sun Jul 31 12:41:21 CDT 2022

> I don't think that "Python famously optimizes almost nothing" is important in our case.

The optimization itself isn’t important, the reason why there is none is. It boils down to the fact that the Python AST gives absolutely no information about what *type* a variable is. It is easier to translate from statically typed to duck typed than the other way around.

For example, suppose you have
```
x = [2]
y = user_func()
y += x
```
What type is y? Should x be a list? Or a static array? What is the signature of user_func()? That is to say, what should the C++ code for this look like? The AST will give you none of this information.

You can kind of get around this using type annotations but those are in no way binding, so need to be checked at runtime (by us) anyways.

Best regards,

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

> On Jul 31, 2022, at 13:04, Barry Smith <bsmith at petsc.dev> wrote:
> 
> 
>> Yes, Python exposes the “ast” module for direct introspection of Python code https://docs.python.org/3/library/ast.html.
> 
>  This looks good. We write the object hierarchy completely in Python with "sample" implementations in Python. From the resulting AST, we automatically generate the C++ class hierarchy, Fortran 2008 class monstrosities, some kind of reasonable mapping to Julia, a mapping to C, we can also have checkers on the AST to ensure we are following all our style rules. In addition, presumably, this would make semi-automatic refactoring of the Python code straightforward.  I don't think that "Python famously optimizes almost nothing" is important in our case. In other words the Python AST becomes our SIDL.
> 
>  I would say C++ is immediately out of the running as the base implementation language since there cannot be this clean automation because of the clang crappy AST, which I have heard from others also.
> 
>  Note: our basic building blocks must cleanly support derivative-enabled libraries everywhere, including the API mapping to other languages. So we need to keep this in mind.
> 
> 
>> On Jul 31, 2022, at 12:31 PM, Jacob Faibussowitsch <jacob.fai at gmail.com> wrote:
>> 
>> 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/
>>> 
>> 
> 