Switch to nanobind

[garth-wells]

This PR switches from pybind11 to nanobind for generating the Python wrappers. nanobind is smaller than pybind11, the wrappers build faster and it has significantly improved support for wrapping multi-dimensional arrays, which we use heavily.

The nanobind docs are easier to follow on the low-level details, which makes understanding the memory management in the wrapper layer easier.

PR depends on the nanobind development version, which includes fixes for complex-valued arrays. Fixed in nanobind 1.8.0.

[garth-wells]

There is an issue with docstrings, and __name__ which is not being set correctly. See: wjakob/nanobind#349

This is affecting documentation.

Fixed in nanobind (wjakob/nanobind@3c2b64a).

[wjakob]

Now that this process has concluded, I was wondering if you have statistics to share? Do you observe changes in compilation time/binary size/runtime overheads for the python binding component?

[chrisrichardson]

@wjakob - the binary size has decreased from 4052784 to 2157624 for the Python binding module, which is good. The compilation time also, subjectively feels faster - the LTO was always very slow for pybind.
I'm not sure we have timing statistics for the Python layer, as such - but we can perhaps have a look at it. We have recipes now for py-fenics-dolfinx@0.7.1 and py-fenics-dolfin@main in https://github.com/FEniCS/spack/tree/latest which makes it relatively easy to compare the two.

[wjakob]

That's pretty cool, thanks for sharing @chrisrichardson! Regarding runtime costs, I suppose that the main difference would apply to cases where you are solving small problems and bottlenecked by Python binding overheads.

[garth-wells]

@wjakob very appealing is ndarray support in nanobind.

[chrisrichardson]

I think we still have to think about the full potential of interoperation with other backends (not just numpy)