Partial migration to nanobind

[PMeira]

Try to write a implementation based on ctypes and/or Cython to compare performance of the bindings on CPython and PyPy.

Investigate whether Numba's CFFI support can be useful to speed up anything.

Document pain points for each approach.

[PMeira]

A Cython implementation will be investigated, especially since it's better integrated with NumPy.

After studying the different usages of CFFI, it becomes apparent that a ctypes implementation wouldn't help much. One of CFFI's modes actually use ctypes directly, so we could just use that to test the speed if really necessary.

[PMeira]

An initial Cython implementation was added in the cython branch.

Initial observations from the somewhat naive implementation: Cython generates a huge C file (200k lines) compared to CFFI, and it takes a while to compile it (the CFFI file compiles instantly).

A quick set of microbenchmarks (reading most of the implemented properties) shows it is usually faster than CFFI. When both the benchmarks and this implementation are more complete, we can decide if it is worth to more to Cython. Ideally we should use a set of real-world scripts to benchmark the implementation as whole.

I also ran the benchmark with PyPy on Windows. Using lists instead of NumPy arrays (didn't want to spend time building NumPy on Windows) resulted in a 4-20x speedup compared to CPython.

[PMeira]

Added Pybind11 as another target of this comparison. Some libraries have moved from Cython and CFFI to it and usually people are happy. Since KLUSolve already needs a C++ compiler and we're trying to provide binary packages for most platforms, the C++ dependency wouldn't be an issue.

[PMeira]

It seems the call overhead of Pybind11 is higher than both Cython and CFFI.

[PMeira]

Almost 2 years later, the most likely future is to move to Cython after updating and benchmarking the current versions.
The main advantage of Cython is that it creates the NumPy arrays at the C side, removing some overhead.

Since this is not urgent, we can wait for the initial results of the HPy project to decide. CFFI is very convenient and I'd like to keep it if possible. If HPy develops enough by the end of the year, fully migrating performance-dependent code to PyPy would be the recommendation.