cppyy: Automatic Python-C++ Bindings
cppyy.readthedocs.io
cppyy: Automatic Python-C++ Bindings
1–10 of 19 posts
Re: cppyy: Automatic Python-C++ Bindings
#2How very interesting. Only a few days ago I was reminiscing about scipy.weave, a horrendous hack and miracle of productivity in Python at the same time. It let users write inline C++, which would get compiled/cached into ephemeral extension modules. For certain jobs, and C++ users, beats numba, cython etc cleanly out of the water. It is sadly deprecated and long time not maintained. Is this a suitable replacement?
AFAICT this does not quite produce true binaries, but rather interprets C++ via Cling, is that right? And the docs only offer that C++-like speeds are achieved for PyPy. If there are any performance benchmarks for CPython3, I can't see find them. Thats the real question - few people combine Python and C++ just for the fun of it.
EDIT some benchmarks are available in this paper, linked from TFA: https://wlav.web.cern.ch/wlav/Cppyy_LavrijsenDutta_PyHPC16.p... But they don't really answer my question. The benchmarks seem to mostly look at the overhead of wrapping C++, rather than comparing to a Python implementation. There is some I/O involved in some of them, which is maybe not so interesting, and some of the benchmarks don't even have a pure CPython implementation. Where they do, speed is very close. But then the paper is from 2018, a lot may have changed.
Re: cppyy: Automatic Python-C++ Bindings
#3How very interesting. Only a few days ago I was reminiscing about scipy.weave, a horrendous hack and miracle of productivity in Python at the same time. It let users write inline C++, which would get compiled/cached into ephemeral extension modules. For certain jobs, and C++ users, beats numba, cython etc cleanly out of the water. It is sadly deprecated and long time not maintained. Is this a suitable replacement? AF…
the purpose of this tool isn't to "accelerate" python or whatever - it's to bind cpp.
> AFAICT this does not quite produce true binaries, but rather interprets C++ via Cling, is that right?
yes but to be very clear: it's not designed to interpret arbitrary cpp but calls and ctors and field accesses. the point is binding. also it can use cling or clang-repl.
Re: cppyy: Automatic Python-C++ Bindings
#4In case you are searching for fun use-cases, here's how one experiment with weird similarity metrics & kNN data-structures via Cppyy (for C++ kernel), Numba (for Python), or PeachPy (for x86 Asm), interacting with a precompiled engine: https://github.com/unum-cloud/usearch/blob/main/python/READM...
Re: cppyy: Automatic Python-C++ Bindings
#5How very interesting. Only a few days ago I was reminiscing about scipy.weave, a horrendous hack and miracle of productivity in Python at the same time. It let users write inline C++, which would get compiled/cached into ephemeral extension modules. For certain jobs, and C++ users, beats numba, cython etc cleanly out of the water. It is sadly deprecated and long time not maintained. Is this a suitable replacement? AF…
It is pretty easy and convenient to write extensions using pybind11, including passing numpy arrays. It takes 10 lines in setup.py and around 10 lines in a .cpp file, run setup.py build_ext to build it. Not quite the convenience of inline - but in practice pretty nice.
My only nit in that compile time is around 3 seconds on my machine.
Re: cppyy: Automatic Python-C++ Bindings
#6The project name reminds me of the BBBQ where the B is for BYOBB
Re: cppyy: Automatic Python-C++ Bindings
#7If I used cppyy in a project that I then made into a pip package, how would this affect distribution? It sounds like the end-user downloading the code would need a C++ compiler on their system, or does cppyy come with one?
Re: cppyy: Automatic Python-C++ Bindings
#8If I used cppyy in a project that I then made into a pip package, how would this affect distribution? It sounds like the end-user downloading the code would need a C++ compiler on their system, or does cppyy come with one?
Answering my own question, it seems they ship LLVM with it: https://cppyy.readthedocs.io/en/latest/philosophy.html#llvm-...
Re: cppyy: Automatic Python-C++ Bindings
#9How very interesting. Only a few days ago I was reminiscing about scipy.weave, a horrendous hack and miracle of productivity in Python at the same time. It let users write inline C++, which would get compiled/cached into ephemeral extension modules. For certain jobs, and C++ users, beats numba, cython etc cleanly out of the water. It is sadly deprecated and long time not maintained. Is this a suitable replacement? AF…
If not doing anything edge-casey, nanobind[0] is extremely pleasant to use. It’s a rewrite of pybind11 specifically designed for the 80/20 use-cases and solves the long compile times.
I have used it extensively over the last year in atopile[1] if someone is looking for a real-world production code example.
We are using nanobind paired with hatch & scikit-build.
I suggest having a look at the pyproject and src/faebryk/core/cpp.
[0] https://github.com/wjakob/nanobind [1] https://github.com/atopile/atopile
Re: cppyy: Automatic Python-C++ Bindings
#10How very interesting. Only a few days ago I was reminiscing about scipy.weave, a horrendous hack and miracle of productivity in Python at the same time. It let users write inline C++, which would get compiled/cached into ephemeral extension modules. For certain jobs, and C++ users, beats numba, cython etc cleanly out of the water. It is sadly deprecated and long time not maintained. Is this a suitable replacement? AF…
If not doing anything edge-casey, nanobind[0] is extremely pleasant to use. It’s a rewrite of pybind11 specifically designed for the 80/20 use-cases and solves the long compile times. I have used it extensively over the last year in atopile[1] if someone is looking for a real-world production code example. We are using nanobind paired with hatch & scikit-build. I suggest having a look at the pyproject and src/faebryk…
> solves the long compile times
this only goes so far - if you try to eg bind O(10k) methods using nanobind (or pybind ofc) you will be compiling for a very long time. for example, i have a threadripper and with a single large TU (translation unit) it took about 60 minutes (because single TU single thread). i had to "shard" my nanobind source to get down to a "reasonable" ~10 minutes.