PyOpenCL wants to move from cffi to pybind11
PyOpenCL allows one to write kernels for OpenCL in python and uses numpy arrays as the data to pass around. They now use cffi bindings, but are thinking of moving to PyBind11. https://lists.tiker.net/pipermail/pyopencl/2018-August/002395.html They claim 1500 less code lines and a 2x speedup (on cpython). It seems this is a step backwards for us, PyBind11 uses the python c-api to wrap C++ code and I do not see how we can make that JIT freindly. On the other hand, I do not know how easy it is to move form PyBind11 to cppyy. Any thoughts? I used to follow their codebase closely, now I just lurk on the mailing list, and do not use the package myself. Matti
Matti,
They claim 1500 less code lines and a 2x speedup (on cpython).
I certainly believe the former, but am surprised by the latter. From some simple benchmarking, I've found PyBind11 to be very slow (as in 3x and up). Perhaps the problem is in the C wrappers more so than in cffi?
On the other hand, I do not know how easy it is to move form PyBind11 to cppyy. Any thoughts?
The question is what they'd think of the LLVM dependency, since the e-mail explicitly states they're happy to be without a boost one. A move itself should be easy enough, but they'd have to be convinced by performance, so it might be good to get a benchmark out of them to measure and see what they consider more important: speed or few dependencies. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Matti,
They claim 1500 less code lines and a 2x speedup (on cpython).
I certainly believe the former, but am surprised by the latter. From some simple benchmarking, I've found PyBind11 to be very slow (as in 3x and up). Perhaps the problem is in the C wrappers more so than in cffi?
On the other hand, I do not know how easy it is to move form PyBind11 to cppyy. Any thoughts?
The question is what they'd think of the LLVM dependency, since the e-mail explicitly states they're happy to be without a boost one. A move itself should be easy enough, but they'd have to be convinced by performance, so it might be good to get a benchmark out of them to measure and see what they consider more important: speed or few dependencies. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
participants (2)
-
Matti Picus -
wlavrijsen＠lbl.gov