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

Dan Sugalski dan@sidhe.org
Fri, 28 Feb 2003 12:07:20 -0500


At 9:59 PM -0500 2/27/03, Terry Reedy wrote:

"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.

I find your trust in my personal integrity refreshing. Putting that aside, Guido isn't particularly interested in looking like a fool in public, and we've already agreed that the dirty tricks that are often used won't be, since that's not the point.

Make no mistake, I fully plan on winning, as resoundingly as I can manage. I'm not going to cheat, though, and I don't want there to be any doubt on either side as to the results. There'll be at least full disclosure on my part as to what the parrot bytecode I execute looks like. While I can't speak for Guido (and we've not talked about this bit) I expect he'll do the same.

> 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.

What it means is that I don't have to build a python bytecode loader into the stock parrot, or weld the Python parser into it. It also means that if Guido rolls out some sort of Miracle Technology or major bytecode revision between the time the challenge code is generated he can run a transition program on it. Works both ways.

I for one don't plan on doing much past writing a simple stack model to register model conversion program, though I might give a run with the code in pure stack mode just for chuckles. Don't overestimate how much effort I'm going to put into this, please.

> 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.

We'll measure both, I'm sure. The bigger question is whether it's fair to be penalized by other things running in the background, though I expect we'll do multiple runs and average or something to account for that. Still, it'd suck to lose because a cron job fired up and snagged 20% of the CPU and saturated the disk channel during the test run, so wall time may be collected but not count. We'll see.

> 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?

If it's in the stock python interpreter or parrot interpreter, it's fair game. (We've agreed that latest CVS checkout versions are acceptable) If by the time the contest rolls around you have some form of JIT technology, great. If Parrot's got JIT versions of the python ops, good for us. If one of us does and the other doesn't, well... the results may be somewhat lopsided. Or not, as JITs certainly aren't a panacea.

                                     Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk