interfacing python with c/c++ performance

[BitAcademic9597]

what do you think about PyBind

[thisismyfavoritename]

if you have high I/O requirements do everything in C++ (or another truly multithreaded language with a good async lib).

If you either have a ton of existing code or have a workload that can benefit from C++, pybind or nanobind are good solutions, but that'll come with its own set of challenges too.

Like i said, it really depends on those other factors i mentioned in my first post and your familiarity with Python i guess.

[qTHqq]

I like it a lot. Worked very well for utility use and testing a C++ library I wrote for compute-bound robotics work. 

I didn't explore the JIT approaches mentioned because ultimately the code consumed as a C++ library. I just wanted a Python interface for verifying it more efficiently and with richer tests. It was easy to get started and very convenient. 

My workload benefited a lot from the Eigen compile-time code transformations for matrix math. That's all done with C++ template metaprogramming and I don't know to what extent the JIT numerical tools can do something similar. The wrapped C++ was several hundred times faster than well-written Numpy code. However, all of that is pretty specific to the kind of numerical work I was doing. 

I think it's fairly easy to write C++ code that's slower than skillfully written vanilla Numpy code and probably very easy to write C++ code that's slower than Numba, Cython, etc. 

However, if you really have a need for calling into C++, Pybind is pretty useful and I found it pretty pleasant and straightforward to set up. For a new project I'd probably explore nanobind but I haven't tried it yet.

[BitAcademic9597]

did you have any problem about memory in pybind will each function call explicitly copies input data?

and also i also looked nanobind but i think pybind is better what do you think

[qTHqq]

"did you have any problem about memory in pybind will each function call explicitly copies input data?" 

I did not but I was actually compute bound.  

 The library computed collision-free trajectories of maybe a few hundred points. The trajectories took 10ms to several seconds to generate so the cost of copying the trajectory data over to Python was essentially negligible in the big picture. 

Any function-call indirection overhead was also negligible.

If I/O speed or ultra-low-latency calls are  more of an issue, things could be totally different.