> > You know, I *want* you to win, at least if you can win by a great > > big margin. Because then we could switch to Parrot to make Python > > faster. I just very much doubt that you'll be able to beat > > CPython. > > For this to be thinkable, and for the test to be > fair, Parrot must be at least as semantically > 'broad' as CPython (ie, handle every possible > meaning of every bytecode). So I would include at > least the syntax and standard lib test files (- > exec and eval tests) as part of the benchmark. > This also gets to the 'provably correct' aspect of > the rules. Right. I don't want to include the entire test suite, but I do want to make sure the benchmark visits most dark corners of the language: metaclasses, dynamically changing operator overloading, and the like. I trust that Dan can write a VM that executes integer operations faster than anyone, but that's not the point of Python. --Guido van Rossum (home page: http://www.python.org/~guido/)
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