On Thu, 2021-10-07 at 15:41 -0700, Brock Mendel wrote: > Will this have any impact on the difficulty of finding "where is > np.foo or > ndarray.bar implemented"? >
I don't think so. It is always a bit annoying to step through the python and then C-layer before you reach the computation part (or know from where it is fetched). Just, now you end up in a C++ templated file rather than c.src templated one. Right now, it is probably even slightly better because it is easier to grep for the function names, although I guess that could change. The added complexity is that we have two ways to template C now... I hope that will pay off soon (as in C++ is proofs useful in some way), since it feels like replacing all `c.src` code is a pretty large (although probably doable) endeavor. Cheers, Sebastian > On Thu, Oct 7, 2021 at 3:02 PM Sebastian Berg > <sebast...@sipsolutions.net> > wrote: > > > 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 > > > > _______________________________________________ > > NumPy-Discussion mailing list -- numpy-discussion@python.org > > To unsubscribe send an email to numpy-discussion-le...@python.org > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > Member address: jbrockmen...@gmail.com > > > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: sebast...@sipsolutions.net
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
