-
-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to nanobind #2820
Switch to nanobind #2820
Conversation
Fixed in nanobind (wjakob/nanobind@3c2b64a). |
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? |
@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. |
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. |
@wjakob very appealing is ndarray support in nanobind. |
I think we still have to think about the full potential of interoperation with other backends (not just numpy) |
This PR switches from
pybind11
tonanobind
for generating the Python wrappers.nanobind
is smaller thanpybind11
, 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 theFixed innanobind
development version, which includes fixes for complex-valued arrays.nanobind
1.8.0.