"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4