On Sun, 2011-01-02 at 19:18 -0800, Guido van Rossum wrote: > On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote: > > No, it's singularly impossible to prove that any global load will be any given > > value at compile time. Any optimization based on this premise is wrong. > > True. > > My proposed way out of this conundrum has been to change the language > semantics slightly so that global names which (a) coincide with a > builtin, and (b) have no explicit assignment to them in the current > module, would be fair game for such optimizations, with the > understanding that the presence of e.g. "len = len" anywhere in the > module (even in dead code!) would be sufficient to disable the > optimization. > > But barring someone interested in implementing something based on this > rule, the proposal has languished for many years. Is there a PEP for this? > > FWIW, this is reminiscent of Fortran's rules for "intrinsics" (its > name for builtins), which have a similar optimization behavior (except > there the potential overrides that the compiler doesn't need to take > into account are load-time definitions). I've been attempting another way in: http://bugs.python.org/issue10399 using a new "JUMP_IF_SPECIALIZABLE" opcode. This compares what a value is against a compile-time prediction, branching to an optimized implementation if the guess was correct. I use this to implement function-call inlining within the generated bytecode. Caveat-of-doom: That code's very much a work-in-progress at this stage, though: sometimes it doesn't segfault :) and the way that I track the predicted values is taking some other liberties with semantics (see that URL and the dmalcolm-ast-optimization-branch in SVN). (There's probably at least 2 PEPs in the above idea, though have yet to write my first PEP) Hope this is helpful Dave
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4