Le mer. 12 sept. 2018 à 18:12, Neil Schemenauer <nas-python@arctrix.com> a écrit :
On 2018-09-12, Victor Stinner wrote:
Amazing! Now I want your code in my http://github.com/pythoncapi/cpython/ fork! Please send me a PR!
I tried yesterday to port my changes to your branch. They don't work because of the hiding of Py_TYPE behind the limited API macro.
You may add a new #ifdef to enable tagged pointer, #ifdef which would enable Py_TYPE again.
So, porting to your branch is non-trival. It will take me some time. I would like to do more benchmarking as people are already making conclusions based on my bad benchmarks.
It's too early to measure the overhead, since we didn't agree yet on the API itself. I suggest to first focus on correctness and the design.
My dream now is to add a 'configure' option that would turn on tagged pointers for small ints. If you turn that on, extensions accessing PyObject struct members would break. However, it would be a nicely modular option: turn if off and there should be zero performance hit. Turn it on and, from an outside perspective, Python still works as normal. So, type(<fixedint>) would return 'int'. The fixedint stuff would be a hidden implementation detail.
In my plan, the "regular Python runtime" will continue to use borrowed references, Py_TYPE() and everything: https://pythoncapi.readthedocs.io/runtimes.html#regular-python-usr-bin-pytho...
But to use tagged pointers, you have to use the "New experimental runtime" where borrowed pointers, Py_TYPE(), etc. would be illegal: https://pythoncapi.readthedocs.io/runtimes.html#new-experimental-runtime-pyt...
Right now, I'm working on the implementation of this "new experimental runtime" to analyze which APIs are "bad" and how far we have to go to reach the perfect API.
Once I will know the full range of required changes and we will have proper benchmark results, we can *start* talking about which changes are worth it or not.
We can also imagine having multiple iterations to enhance the C API. For example, keep Py_TYPE() in the first iteration. But discuss removing it later.
About correctness, yesterday, we discussed adding a new first "ctx" parameter to all functions of the C API to support Eric Snow's Sub-Interpreters. The idea is to avoid any kind of global state, and pass an opaque pointer to pass the state of an interpreter. The state would contain for example memory allocators. At the point, I'm not fully excited by this change, since every C function using the C API would have to pass ctx everywhere.
Victor