On 04/01/2011 01:02, Guido van Rossum wrote:
On Mon, Jan 3, 2011 at 9:52 AM, David Malcolm<dmalc...@redhat.com> wrote:
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.gay...@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?
Not that I know of, otherwise I'd have mentioned it. :-)
It would be useful if someone wrote it up, since the idea comes back
in one form or another regularly.
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.
Yeah, that's what everybody proposes to keep the language semantics
unchanged. But I claim that an easier solution is to say to hell with
those semantics, let's change them to make the implementation simpler.
That's from the Zen of Python: "If the implementation is easy to
explain, it may be a good idea." I guess few people can seriously
propose to change Python's semantics, that's why *I* am proposing it.
:-) Note that the semantics of locals (e.g. UnboundLocalError) were
also changed specifically to allow a significant optimization -- again
by me.
I think someone else pointed this out, but replacing builtins externally
to a module is actually common for testing. In particular replacing the
open function, but also other builtins, is often done temporarily to
replace it with a mock. It seems like this optimisation would break
those tests.
Michael
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)
If you want to write up a PEP for the semantics change I am proposing,
everything you need is in this thread.
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
