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
[WIP] PEP 510: Specialize functions with guards #70286
Comments
Attached patch implements the PEP-510 "Specialize functions with guards". Changes on the C API are described in the PEP: Additions of the patch:
|
Patch version 2 fixes some bugs and add more tests. More notes about the patch:
TODO: keywords are currently not supported in PyGuard.__call__(). |
An unit test is needed on pickle serialization to ensure that the specialize code and guards are ignored. |
Patch version 3:
https://mail.python.org/pipermail/python-dev/2016-January/142792.html
|
Patch version 4:
|
Patch version 5: implement PyFunction_RemoveSpecialized() and PyFunction_RemoveAllSpecialized() functions (with unit tests!). I'm not sure that PyFunction_RemoveSpecialized() must return 0 (success) if the removed specialized code doesn't exist (invalid index). |
FIXME: sys.getsizecode(func) doesn't include specialized code and guards. |
Patch version 6: I inlined PyFunction_GetSpecializedCode() into fast_function() of Python/ceval.c. It reduces *a little bit* the overhead of the patch when specialization is not used, but it also avoids to expose this function. I don't think that it's worth to expose PyFunction_GetSpecializedCode(): it was only used in ceval.c. For example, I don't use it for unit tests. I prefer to write tests calling the function and checking the results (see test_pep510.py). *Raw* overhead of specialized-6.patch on calling "def f(): pass": 1.7 nanoseconds. I computed the overhead using timeit: ./python -m timeit -s 'def f(): pass' 'f()'
I will run perf.py to see the overhead on a macro benchmark. |
Results of the "The Grand Unified Python Benchmark Suite" on specialize-6.patch. I'm skeptical, I don't understand how my patch can make a benchmark faster :-) The result of regex_v8 is bad :-/ $ python3 -u perf.py --rigorous ../default/python.orig ../default/python
(...)
Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8 ### chameleon_v2 ### ### django_v3 ### ### regex_v8 ### The following not significant results are hidden, use -v to show them: |
Patch version 7:
|
Oh, I missed comments on the code review. Fixed on patch version 8. |
Recently, some people asked me for an update for my FAT Python project. So I rebased this change I wrote 1 year 1/2 and adapted it for the new code base:
The PEP-510 is not accepted, so the implementation is still a work-in-progress (WIP) and must not be merged. |
I rejected my own PEP-510, so I reject this issue as well. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: