-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Evaluate the pros/cons of using ctypes to replace pybind11 #4830
Comments
One plus side is PyPy supports ctypes well, another is that combined with AOT API now we can also expose device API as well |
Two more pros:
That's true, but I don't really think this is a con for users, since Taichi should not throw FFI errors to users. Probably for developers only :-) One cent about switching to |
The author of pybind is working on a new python binding project, https://github.com/wjakob/nanobind, one of the motivations being reducing overhead. |
FYI I wrote a few toy demos of calling c extensions from python using pybind11/ctypes/cpython respectively and the code lives at https://github.com/ailzhang/c_ext_for_py/. It also prints time spent (maybe not apple-to-apple comparison tho).
As a result I'd view this issue more to identify hotspots in py->c interaction and migrate them to cpython/ctypes step by step in a measurable way. We can probably employ cpython/ctypes in the critical parts for perf gain and keep some components in pybind11 to enjoy the ready-to-use C++ features. |
We should move AOT first to CTypes, and then expose device API over ctypes. |
While pybind11 is quite easy to use, it comes with a few pitfalls:
Many large projects have switched to use ctypes. Writing this down to remind us that we should evaluate its feasibility.
The text was updated successfully, but these errors were encountered: