tree 48a4d91c394c6ad289588922e0dc2a915974e14f
parent 6eb7ce52c2674186e72432b4f4d3f10850a37802
author Stella Laurenzo <stellaraccident@gmail.com> 1687823850 -0700
committer GitHub <noreply@github.com> 1687823850 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJkmiXqCRBK7hj4Ov3rIwAAvp8IAK1Rhnee6cXaCTMMs4bZJmwX
 h8zJM3wrcYintm65PlLJXTh2o0PBWNbwmQKaWQDUi4uubp3VQCuDap3J7ppdBD/I
 xgjZKNcYp5GrgVO6V3J/mQOO5uAE4z7x8JAKGGGeBLiHsGDeQltmM/3H2WBN/2QZ
 dqxsrC7f56TKUXvfzzZ3ZQApK5reQI90HBho76oqjNUzDPNZCnByq2T0PwCLwCgT
 LGfnDHd3xLQFDJbmqogFXwLbM57x+PNBPM/qnKIKuCxjl52LQtgvqonRYiWXnwR+
 sHj8QMuuuD/8uGUogg6hw/gnVcZl77qzsMeuQKf48CSB3Wfqb+9Xftc+5BdZVzM=
 =trlv
 -----END PGP SIGNATURE-----
 

Port iree.runtime to nanobind. (#14214)

I believe that this should be a no-op for users. There is one minor API
change (the MappedMemory class no longer implements the buffer protocol,
but I've seen no evidence that this was actually used since it was a
less functional way to get a host ndarray).

More adventurous use of nanobind is possible in the future (i.e. using
`ndarray` and `dlpack` interop for sharing across frameworks), but using
that will most likely necessitate API changes, which I was working to
avoid.

Aside from relatively mechanical differences from pybind11, the main
issues were that the buffer protocol and array support was dropped in
nanobind. This required some direct coding against the C API to achieve
the same characteristics. I think this is actually an improvement as the
pybind11 implementations of these features was neither efficient nor
obvious what it was doing.

A build time dependency on `nanobind` is added. When building Python
wheels, this gets satisfied automatically. Otherwise, the docker images
have been updated to pre-install the necessary Python package. In
addition, there is now a build time dependency on NumPy headers, which
should already be installed (pybind11 vendored stripped down copies of
these headers in an effort to avoid this, but I opted to just do the
normal thing).

Nanobind's performance is [quite
compelling](https://nanobind.readthedocs.io/en/latest/benchmark.html)
and owes to a combination of favoring more efficient binding styles that
would basically be a rewrite in pybind11 and exclusive use of the new
Python 3.8+ vectorcall ABI. Since the runtime is performance critical
and the cost of Python calls is already quite visibly adding overhead on
traces, it makes sense to baseline on the most efficient implementation.
In addition, the compile-time savings seem to be real and the build is
noticeably faster (this was not a primary consideration, just a nice
bonus).