Re: [Python-Dev] Pie-thon benchmark code ready
At 09:54 31.12.2003 -0800, Guido van Rossum wrote:
I'd be happy to answer any questions. Let the competition begin!
wondering whether the correctness checks are too much dependent on details of the representation of objects, especially the order of keys in a dict repr etc...
wondering whether the correctness checks are too much dependent on details of the representation of objects, especially the order of keys in a dict repr etc...
Probably. :-( I could probably fix that by subclassing dict with something whose repr() sorts the keys -- it doesn't print the few large dicts that it uses, so this should be fine. The same approach could be used for fixing all repr()-related issues. I'll leave it to Dan to decide if he wants this to be fixed ASAP or if he's okay with putting it off until later -- I imagine it will take a while before he's got it running on Parrot well enough to hit the first assert... (There's also an issue with the distinction between repr() of int and long, which will disappear in Python 3.0, and repr() of str vs. unicode, which already doesn't exist in Jython. So I predict that the benchmark currently doesn't have a chance of passing on Jython. (But it would be interesting to time it anyway -- simply disable the raises in b0.check() and in b5.check().) --Guido van Rossum (home page: http://www.python.org/~guido/)
At 4:50 PM -0800 12/31/03, Guido van Rossum wrote:
wondering whether the correctness checks are too much dependent on details of the representation of objects, especially the order of keys in a dict repr etc...
Probably. :-(
I could probably fix that by subclassing dict with something whose repr() sorts the keys -- it doesn't print the few large dicts that it uses, so this should be fine. The same approach could be used for fixing all repr()-related issues. I'll leave it to Dan to decide if he wants this to be fixed ASAP or if he's okay with putting it off until later -- I imagine it will take a while before he's got it running on Parrot well enough to hit the first assert...
Heh. I'm OK with either leaving it as-is if the current ordering is considered correct, or altering the benchmark to guarantee ordering. (Or having the output compared by an external program to guarantee correctness, which is fine as well) -- Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
wondering whether the correctness checks are too much dependent on details of the representation of objects, especially the order of keys in a dict repr etc...
Probably. :-(
I could probably fix that by subclassing dict with something whose repr() sorts the keys -- it doesn't print the few large dicts that it uses, so this should be fine. The same approach could be used for fixing all repr()-related issues. I'll leave it to Dan to decide if he wants this to be fixed ASAP or if he's okay with putting it off until later -- I imagine it will take a while before he's got it running on Parrot well enough to hit the first assert...
Heh. I'm OK with either leaving it as-is if the current ordering is considered correct, or altering the benchmark to guarantee ordering. (Or having the output compared by an external program to guarantee correctness, which is fine as well)
The ordering is supposed to be an unimportant detail. The external program solution won't work due to the nature of the benchmark. I'll fix the benchmark some time next week. The fix should be fairly simple and localized. --Guido van Rossum (home page: http://www.python.org/~guido/)
The ordering is supposed to be an unimportant detail. The external program solution won't work due to the nature of the benchmark. I'll fix the benchmark some time next week. The fix should be fairly simple and localized.
It was easier than I thought, so it's in place. Version 1.0.2 uses a subclass of dict whose __repr__ sorts the keys. The running time doesn't seem to be substantially affected. (Oh how I love subclassing builtin classes!) --Guido van Rossum (home page: http://www.python.org/~guido/)
The ordering is supposed to be an unimportant detail. The external program solution won't work due to the nature of the benchmark. I'll fix the benchmark some time next week. The fix should be fairly simple and localized.
It was easier than I thought, so it's in place. Version 1.0.2 uses a subclass of dict whose __repr__ sorts the keys. The running time doesn't seem to be substantially affected.
(Oh how I love subclassing builtin classes!)
Make that 1.0.3. There were two relevant dict usages -- one for globals and one for locals. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Dan Sugalski -
Guido van Rossum -
Samuele Pedroni