On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote:
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Hi folks,
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.
A brief update on this: The current plan would be to include this in the next release. Largely as a trial balloon, so we see if there are any issues, e.g. with deployment, and can revert the changes if there are. That would mean that some time within the next release cycle using C++ for more things could be on the table and less difficult to discuss. Not knowing the C++ much myself, I assume that the current approach is fine and the only remaining thing is a brief review of the new code to ensure correct translation from C. (Which does not preclude refining the C++ code later.) Cheers, Sebastian
Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.
I am not a C++ export, and really have to get to used to this code. So I would prefer if some C++ experts can look at it and give feedback.
This will be a bit harder to read for me than our `.c.src` code for a while. But on the up-side, I am frustrated by my IDE not being able to deal with the `c.src` templating.
One reaction reading the X-macro trick is that I would be more comfortable with a positive list rather than block-listing. It just felt a bit like too much magic and I am not sure how good it is to assume we usually want to export everything (for one, datetimes are pretty special).
Even if it is verbose, I would not mind if we just list everything, so long we have short-hands for all-integers, all-float, all-inexact, etc.
Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.
<snip>
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep?
What does this mean for compatibility? It sounds reasonable to me for now if it increases systems we can run on, but I really don't know.
- what about -fno-exception, -fno-rtti?
How do C++ exceptions work at run-time? What if I store a C++ function pointer that raises an exception and use it from a C program? Does it add run-time overhead, do we need that `no-exception` to define that our functions are actually C "calling convention" in this regard?!
Run-time calling convention changes worry me, because I am not sure C++ exception have a place in the current or even future ABI. All our current API use a `-1` return value for exceptions.
This is just like Python's type slots, so there must be "off the shelve" approaches for this?
Embracing C++ exceptions seems a bit steep to me right now, unless I am missing something awesome?
I will note that a lot of the functions that we want to template like this, are – and should be – accessible as public API (i.e. you can ask NumPy to give you the function pointer).
Cheers,
Sebastian
- coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion