[Python-Dev] Looking for master thesis ideas involving
Python
Phillip J. Eby
pje at telecommunity.com
Wed Oct 29 13:25:52 EST 2003
At 06:01 PM 10/28/03 -0800, Brett C. wrote:
>Today I got the wheels turning on my masters thesis by getting an
>adviser. Now I just need a topic. =) The big goal is to do something
>involving Python for a thesis to be finished by fall of next year (about
>October) so as to have it done, hopefully published (getting into LL4
>would be cool), and ready to be used for doctoral applications come
>January 2005.
>
>So, anyone have any ideas? The best one that I can think of is optional
>type-checking. I am fairly open to ideas, though, in almost any area
>involving language design.
Throwing another Python-specific implementation issue into the ring... how
about performance of Python function calls?
Specifically, the current Python interpreter has a high overhead for
argument passing and frame setup that dominates performance of simple
functions. One strategy I've been thinking about for a little while is
replacing the per-frame variable size stacks (e.g. argument and block
stacks) with per-thread stacks. In principle, this would allow a few
things to happen:
* Fixed-size "miniframe" workspace objects allocated on the C stack (with
lazy creation of heap-allocated "real" frame objects when needed for an
exception or a sys._getframe() call)
* Direct use of positional arguments on the stack as the "locals" of the
next function called, without creating (and then unpacking) an argument
tuple, in the case where there are no */** arguments provided by the caller.
This would be a pretty sizeable change to Python's internals (especially
the core interpreter's handling of "call" operations), but could possibly
produce double-digit percentage speedups for function calls in tight
loops. (I base this hypothesis on the speed difference between a function
call and resuming a generator, and the general observation that the runtime
of certain classes of Python programs is almost directly proportional to
the number of function calls occurring.)
More information about the Python-Dev
mailing list