[Python-Dev] Re: new bytecode results (original) (raw)

Terry Reedy tjreedy@udel.edu
Thu, 27 Feb 2003 21:59:49 -0500

"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