[Python-Dev] Re: new bytecode results

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