[New-bugs-announce] [issue29524] Move functions to call objects into a new Objects/call.c file
STINNER Victor
report at bugs.python.org
Fri Feb 10 07:42:39 EST 2017
New submission from STINNER Victor:
I propose to move functions to call objects into a new Objects/call.c file.
It should easy maintainance since all moved functions are inter-dependent: it becomes easier to keep them consistent since they are in the same fle.
I also have a small "hope" that moving "call" functions in the same file should help the compiler to produce more efficient code and that we will get a better "code placement". Closer functions should enhance the usage of the CPU instruction cache.
I don't know exactly how to measure the effect of code placement. My plan is to push the change, and then watch speed.python.org timeline.
Attached call.patch:
* Add Objects/call.c file
* Move all functions to call objects in a new Objects/call.c file.
* Rename fast_function() to _PyFunction_FastCallKeywords().
* Copy null_error() from Objects/abstract.c
* Inline type_error() in call.c to not have to copy it, it was only called once.
* Export _PyEval_EvalCodeWithName() since it is now called from call.c.
The change comes from the issue #29465. Copy of my msg287257 from this issue:
---
Serhiy Storchaka added the comment:
> Isn't the Python directory more appropriate place for call.c?
I moved code from other .c files in Objects/, so for me it seems more
natural to add the code in Objects/ as well. It seems like most of the
code in Python/ is not "aware" of types defined in Objects/. But I
don't have a strong opinion on the right directory.
Objects/call.c is 1500 lines long. IMHO the code became big enough to
justify to move it to a new file ;-)
---
Once we have a call.c file, we may try other changes to enhance the code placement:
* Add "#define PY_LOCAL_AGGRESSIVE" (only used by Visual Studio)
* Tag functions with _Py_HOT_FUNCTION: see the issue #28618 for discussion on __attribute__((hot)). The last time I checked, it wasn't enough to fix all "code placement issues".
* Reorder functions in call.c: I dislike this idea, IMHO it's too hard to guess ourself what is the best order, and it's likely to produce many commits for little benefit
See also the issue #29465: "Add _PyObject_FastCall() to reduce stack consumption.
----------
components: Interpreter Core
files: call.patch
keywords: patch
messages: 287527
nosy: haypo, inada.naoki, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Move functions to call objects into a new Objects/call.c file
versions: Python 3.7
Added file: http://bugs.python.org/file46624/call.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29524>
_______________________________________
More information about the New-bugs-announce
mailing list