René's URL Explorer Experiment

Title: Use pybind11 for C/C++ extensions by ianthomas23 · Pull Request #23787 · matplotlib/matplotlib · GitHub

Open Graph Title: Use pybind11 for C/C++ extensions by ianthomas23 · Pull Request #23787 · matplotlib/matplotlib

X Title: Use pybind11 for C/C++ extensions by ianthomas23 · Pull Request #23787 · matplotlib/matplotlib

Description: This is a proof of concept of using pybind11 to wrap and compile MPL C/C++ extensions. It covers just the _qhull and _tri extensions as (1) they are relatively small and self-contained, and (2) I understand them well. The motivation is to provide information to other devs on what it would involve and then consider if this is a suitable approach for all of our C/C++ extensions or not. Advantages: Extensions no longer depend on the MPL bespoke array_view class in numpy_cpp.h as pybind11 includes its own NumPy array wrapper. Don't have to deal with parsing of input arguments via e.g. PyArg_ParseTuple as we get this for free. There are wrappers for python classes such as list and tuple, so no longer need to deal with Python C/API reference counting and error checking. Exceptions and error handling are much simplified. Just throw any C++ exception and pybind11 catches it and converts it to a Python equivalent exception. There is a net reduction in code, this PR has 357 additions and 775 deletions. Much of this is the much simpler module definition as the Python/C API boilerplate is no longer required. The extension shared libraries are smaller. On my Linux system the _qhull.so and _tri.so are 1.6 MB and 1.3 MB on main but only 1.0 MB and 0.7 MB on this branch. Disadvantages: It is a change, which inherently introduces risk, and to an area of code that we would probably prefer to leave alone. I appreciate that this may trump all of the advantages listed above. Change to build system including wheels and conda builds, which is also risky. I have tried to keep the changes as small as possible to make it clear what the minimal set of changes is. But if we were to go ahead with this approach we would probably want to make more, particularly to typedefs and numpy array accessors, to standardise and make the code clearer. Performance of a large qhull Delaunay triangulation is essentially unchanged by this PR. Performance of a large tricontour call is ~3% faster. There is a tradeoff here between performance and code clarity, in particular whether we access multi-dimensional numpy arrays via conventional-looking indexing (e.g. array(j, i)) which is slower than accessing via low-level C pointers where we do the index maths ourselves for speed. I know of one core dev (@anntzer) and one occasional contributor (me) who have pybind11 experience, via mplcairo and contourpy respectively. (Edited to add another disadvantage).

Open Graph Description: This is a proof of concept of using pybind11 to wrap and compile MPL C/C++ extensions. It covers just the _qhull and _tri extensions as (1) they are relatively small and self-contained, and (2) I u...

X Description: This is a proof of concept of using pybind11 to wrap and compile MPL C/C++ extensions. It covers just the _qhull and _tri extensions as (1) they are relatively small and self-contained, and (2) I u...

Opengraph URL: https://github.com/matplotlib/matplotlib/pull/23787

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width