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.
It seems time to pick up this discussion again. I think we were
cautiously in favor of trying this out in the limited proposed form.
Aside from ensuring we do not use C++ exceptions/run-time environment.
I.e. compile with `-fno-exception` and `-nostdlib`, the PR is probably
largely ready.
Are there any other bigger issues that need to be discussed?
The goal for now seems to allow this type of function templates (C++ as
a glorified templating language). We may be able to enforce this with
clang-tidy (not sure if that is necessary right away though).
There are parts of NumPy (mainly `fft`) where more C++ features could
be helpful but that should probably be discussed separately.
The current solution ends up using no X-Macro anymore, which means
listing the C symbols like:
NPY_NO_EXPORT int radixsort_byte(void* vec, npy_intp cnt, void
*NPY_UNUSED(null)) { return radixsort<npy_byte>(vec, cnt); }
NPY_NO_EXPORT int radixsort_ubyte(void* vec, npy_intp cnt, void
*NPY_UNUSED(null)) { return radixsort<npy_ubyte>(vec, cnt); }
NPY_NO_EXPORT int radixsort_short(void* vec, npy_intp cnt, void
*NPY_UNUSED(null)) { return radixsort<npy_short>(vec, cnt); }
NPY_NO_EXPORT int radixsort_ushort(void* vec, npy_intp cnt, void
*NPY_UNUSED(null)) { return radixsort<npy_ushort>(vec, cnt); }
NPY_NO_EXPORT int radixsort_int(void* vec, npy_intp cnt, void
*NPY_UNUSED(null)) { return radixsort<npy_int>(vec, cnt); }
NPY_NO_EXPORT int radixsort_uint(void* vec, npy_intp cnt, void
*NPY_UNUSED(null)) { return radixsort<npy_uint>(vec, cnt); }
NPY_NO_EXPORT int radixsort_long(void* vec, npy_intp cnt, void
*NPY_UNUSED(null)) { return radixsort<npy_long>(vec, cnt); }
NPY_NO_EXPORT int radixsort_ulong(void* vec, npy_intp cnt, void
*NPY_UNUSED(null)) { return radixsort<npy_ulong>(vec, cnt); }
I guess we could try to write some macro's to make this shorter,
although I am fine with delaying this, since the main point is probably
getting a brief example and the build changes in.
It also defines the following type tags:
https://github.com/numpy/numpy/pull/19713/files#diff-4de4beaecd7b0a1f4d887221191843a54b0c62f13eea18b8716c54bec9657f20
Any comments to the approach (especially from anyone more familiar with
C++) would be much appreciated!
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.
>
> Some changes in distutils were needed to cope with C++-specific
> flags, and
> extensions that consist in mixed C and C++ code.
>
> I've kept the change as minimal as possible to ease the (potential)
> transition
> and keep the C++ code close to the C code. This led to less idiomatic
> C++ code,
> but I value a "correct first" approach. There's an on-going effort by
> seiko2plus
> to remove that C layer, I acknowledge this would bring even more C++
> code, but
> that looks orthogonal to me (and a very good second step!)
>
> All lights are green for the PR, let's assume it's a solid ground for
> discussion :-)
> So, well, what do you think? Should we go forward?
>
> Potential follow-ups :
>
> - do we want to use -nostdlib, to be sure we don't bring any C++
> runtime dep?
> - what about -fno-exception, -fno-rtti?
> - 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
>
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
