[Python-Dev] Re: new bytecode results

[Terry Reedy]

"Dan Sugalski" <dan@sidhe.org> wrote in message
news:a05200f00ba84455b2bc8@[63.120.19.221]...
> We've still got to hash out the details,  but in december someone'll
> generate a bytecode file for the program(s) we're going to be
> running. We both get to run converters/optimizers over them if we
> choose.

I find this a bit surprising.  The problems of teaching to the test
and programming to the benchmark are well-known.  I presume the
extreme of 'optimizing' the bytecode down to a single byte (that calls
a custom compiled-to-machine-code function) will be disallowed.  But I
wonder how and where you plan to draw the line between that and
out-of-the-box behavior.

> Then at the 2004 OSCON we'll run the converted programs and

With enough 'conversion', the result could be seen as no longer being
a compilation of standard Python, but of a variant with type
declarations and pragmas added and certain dynamic features deleted.
In any case, this seems to makes the contest one more of special-case
optimization and less of general-case running time, and therefore of
less relevance to users who want *their* programs to run faster with
an out-of-the-box interpreter.

> whichever takes less time (we've not set whether it's wall or CPU
> time, though I'm tempted to go for CPU so neither gets penalized for
> the odd background task that might be running) wins.

>From my user viewpoint, I am more interested in total time from source
input to finish.

> The official details, limits, and pie flavors will likely be set at
> this summer's OSCON.

Will you allow runtime compilation (as with psyco)?
How about pre-contest dynamic compilation?  (I believe Armin plans to
add a save/restore feature).
What if psyco-like dynamic compilation is a 'stock' feature of one
system and not the other?

Your contest, my questions and comments.

Terry J. Reedy