But if you are using a class hierarchy for everything, not just random code
with naked variables and functions, then doesn't it know the types? Is the
problem that it knows the type of the self argument of methods but not any of
the other arguments? So we would need to implement our own pret
> 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 tr
> 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++
> On Jul 31, 2022, at 12:49 PM, Jacob Faibussowitsch
> wrote:
>
> Sorry, hit send too early :)
>
>> It may be worth it if there are significant benefits in safety and static
>> analysis or if the tooling means contributors really have fewer moving parts.
>
> Well for one, C ships with quit
Sorry, hit send too early :)
> It may be worth it if there are significant benefits in safety and static
> analysis or if the tooling means contributors really have fewer moving parts.
Well for one, C ships with quite possibly the leanest standard library out
there. A good chunk of the contents
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
> 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
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 feel like changing languages (or adopting a second essential implementation
language) is a significant complexity step
It could be the "base" language of PETSc would be used by almost no one
except the core PETSc developers. For example, a base in Rust but no rust
users. One could push this a bit more to easily support "extensions" written in
a variety of languages that are easily usable from any language;
On Sun, 31 Jul 2022 at 17:07, Matthew Knepley wrote:
> On Sun, Jul 31, 2022 at 9:06 AM Lisandro Dalcin wrote:
>
>> On Sun, 31 Jul 2022 at 16:41, Jacob Faibussowitsch
>> wrote:
>>
>>>
>>> > Please don't take my words as advocacy for C++
>>>
>>> I’m going to pretend like I didn’t read this :)
>>>
On Sun, Jul 31, 2022 at 9:06 AM Lisandro Dalcin wrote:
> On Sun, 31 Jul 2022 at 16:41, Jacob Faibussowitsch
> 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
On Sun, 31 Jul 2022 at 16:41, Jacob Faibussowitsch
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 l
IMO there are 2 stakeholders to consider here:
1. “Individual” users
Lisandro raises excellent points here IMO. A huge chunk of scientific computing
users primarily use Python, and the amount of HPC libraries that are being
built as a Python-frontend-to-Clike-backend is also rapidly growing. An
On Tue, 26 Jul 2022 at 17:35, Barry Smith wrote:
>
> Bindings for Fortran 20xx, Python 3, Julia? If the bindings are not,
> more or less, automatically generated, that would be problematic.
>
>
So far, PETSc exposes a C API. Of course it is object oriented in spirit,
but it is not object-orient
22 at 07:57
> *To: *Jed Brown
> *Cc: *Satish Balay via petsc-dev
> *Subject: *Re: [petsc-dev] PETSc future starting as a new design layer
> that runs on top of PETSc 3?
>
>
>
>
>
> On Jul 27, 2022, at 5:47 PM, Jed Brown wrote:
>
>
>
> PETSc has never u
timescale.
Cheers,
David
From: petsc-dev on behalf of Barry Smith
Date: Thursday, 28 July 2022 at 07:57
To: Jed Brown
Cc: Satish Balay via petsc-dev
Subject: Re: [petsc-dev] PETSc future starting as a new design layer that runs
on top of PETSc 3?
On Jul 27, 2022, at 5:47 PM, Jed Brown
> On Jul 27, 2022, at 5:47 PM, Jed Brown wrote:
>
> PETSc has never used fine grain OO, like per row of a matrix or per element
> in a mesh (compare DMPlex with libMesh).
Yes, because even in 1994, we knew that was a dead-end for performance and
unnecessary as well :-)
> But languages hav
PETSc has never used fine grain OO, like per row of a matrix or per element in
a mesh (compare DMPlex with libMesh). But languages have idioms related to
features like iterators, high-order functions/closures, traits, error
handling/nullability, and multimethods. You can usually make a naive int
The API for PETSc is (by design) highly object-oriented; the data
encapsulation is helpful and rarely gets in the way of performance. The object
oriented nature makes it easier to be supported by multiple languages even when
one does not utilize the idiomatic features for object-oriented code
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.
One i
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
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 perspectiv
> On Jul 26, 2022, at 11:30 AM, Jed Brown 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 "ol
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
Hi,
here we are developing in C++ and using PETSc encapsulated into C++
classes since 1997 I am curious about a kind of survey on "How do
you use PETSc in your code?"
I would say that bad code in feasible in almost all languages (yes, we
did that to! :) ): peer code review is there to he
> On Jul 26, 2022, at 10:51 AM, Barry Smith wrote:
>
>
>
>> On Jul 26, 2022, at 10:49 AM, Boyce Griffith wrote:
>>
>>
>> clang-tidy can help with setting/enforcing C++ coding standards and avoiding
>> some “old” C++ conventions / suggesting “modern” replacements.
>
>
> Could we just
I have to put in a good work for Fortran. There are many parallels in
capability with modern C++, and it only requires disregarding every
implementation method you previously know and mapping them onto keywords
that have different meanings in every other language. The tooling is
comparable to
> On Jul 26, 2022, at 10:49 AM, Boyce Griffith wrote:
>
>
> clang-tidy can help with setting/enforcing C++ coding standards and avoiding
> some “old” C++ conventions / suggesting “modern” replacements.
Could we just run clang-tidy on PETSc 3 1000 times and end with PETSc future
:-)
>
> On Jul 26, 2022, at 9:55 AM, Barry Smith wrote:
>
>
>
>> On Jul 26, 2022, at 9:43 AM, Jacob Faibussowitsch
>> wrote:
>>
>>> even more importantly we would need a huge amount of education as to what
>>> to use and what not to use otherwise our hacking habits will fill the
>>> source co
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
Bindings for Fortran 20xx, Python 3, Julia? If the bindings are not, more or
less, automatically generated, that would be problematic.
> On Jul 26, 2022, at 10:20 AM, Jed Brown wrote:
>
> I have to put in a good word for Rust. There are many parallels in capability
> with modern C++, but th
Given our diverse programming team, I don't see how we will each spend a year
learning modern C++ and, most importantly, learning everything not to do and
then writing PETSc future. On the other hand, this may be true of any other
language, Rust, Zig, Carbon, D, Julia. The advantage of the o
I have to put in a good word for Rust. There are many parallels in capability
with modern C++, but the compiler enforces many good practices (and guarantees
safety), compiler error and warning messages are really useful, and the tooling
is phenomenal on multiple fronts, from packaging to refacto
> And for programmers today who program by googling, googling does not
> distinguish between good modern C++ solutions and crappy 15 year old
> solutions that still work but should not be used today.
Sure, all jokes aside the difference between old and modern C++ is broadly
speaking:
1. If yo
I think it would be reasonable to say PETSc future uses PETSc old (including
new features that may be added to PETSc old for a couple of years) but that
PETSc old cannot use PETSc future. As Jacob says. Going both ways seems like an
unneeded burden.
Barry
> On Jul 26, 2022, at 9:55 AM
> engage in incremental development.
Incremental development that goes the other way though (unless I have
misunderstood) i.e. you have base C-code that is called from C++. If you need
C++ from C, then you need macros to generate the stubs for each instantiated
template, but if you need C from
> On Jul 26, 2022, at 9:43 AM, Jacob Faibussowitsch wrote:
>
>> even more importantly we would need a huge amount of education as to what to
>> use and what not to use otherwise our hacking habits will fill the source
>> code with bad code.
>
> As long as you never type “new” and “delete” t
On Tue, Jul 26, 2022 at 8:44 AM Jacob Faibussowitsch
wrote:
> > even more importantly we would need a huge amount of education as to
> what to use and what not to use otherwise our hacking habits will fill the
> source code with bad code.
>
> As long as you never type “new” and “delete” then you
> even more importantly we would need a huge amount of education as to what to
> use and what not to use otherwise our hacking habits will fill the source
> code with bad code.
As long as you never type “new” and “delete” then you are using modern C++ :)
> Based on Jacob's contributions even "m
With C++ we would need good security guards on the MR who prevent use of the
"bad old C++" paradigms and only allow use of proper modern techniques; even
more importantly we would need a huge amount of education as to what to use and
what not to use otherwise our hacking habits will fill th
IMO C++ is the pragmatic choice here.
- Anyone with a C compiler is virtually guaranteed to have a C++ compiler these
days, so no extra toolchain burden on users.
- Our configure and build system already has all the infrastructure in place
for C++ builds.
- We already do half-C-half-C++ in the
On Mon, Jul 25, 2022 at 4:34 PM 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 versio
Julia?
If you’re interested, you can follow the online minisymposium on Julia for HPC
later today (register for free):
https://live.juliacon.org/talk/LUWYRJ
Perhaps also relevant is the one of yesterday, on differentiable Earth system
models:
https://youtu.be/K2VtJe9baO4
Boris
On 25. Jul 2022
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
44 matches
Mail list logo
