Update of /cvsroot/python/python/nondist/sandbox/parrotbench In directory sc8-pr-cvs1:/tmp/cvs-serv29987 Added Files: README.txt Log Message: Beginning of an explanation. --- NEW FILE: README.txt --- Parrot benchmark ================ This is a benchmark to be run in front of a live audience at OSCON 2004 between Python and Parrot. The bytecode must be Python 2.3 bytecode frozen in December 2003 (which is almost over as I write this :-). For some more background, see the python-dev thread around http://mail.python.org/pipermail/python-dev/2003-December/040977.html The benchmark here is intended to make Dan Sugalski's life difficult: there are some standard benchmark thingies (simple random algorithms using basic data types) but also a lot of play with odd corners of the language definition, and Python's extremely dynamic object model: funky descriptors, mutable classes, that sort of thing. The benchmark is supposed to run with either Python 2.3 or Python 2.4. Brief description per file: Makefile -- Various ways of running the benchmark and sub-benchmarks. b.py -- The full benchmark output is defined as "python -O b.py". b0.py -- Lots of fun with a parser for a subset of Python (just because this is a classic OO-heavy application). b1.py -- Explore recursion. Unbounded recursion is expected to raise RuntimeError after about 1000 levels. (If Parrot supports much more, this part will be slower; the point is to be able to tweak the recursion limit.) b2.py -- Calculate PI using a generator. b3.py -- Sorting, and various ways of setting the comparison function for list.sort(). b4.py -- Another test for the code from b0.py, this time with code derived from Python 2.3's heapq.py. b5.py -- Test the standard library, including three standard Unicode codecs (ASCII, Latin-1 and UTF-8), various descriptors, and mutable classes. Note that per agreement I'm not allowed to use any built-in extension modules, not even __builtin__ or sys. This means there's no access to sys.args (so no command line arguments), sys.stdout (but we have "print >>file") or to sys.exc_info(). Dan could save some nanoseconds by not supporting tracebacks. But that would be cheating. Also cheating would be to do all the work at compile time (this is theoretically possible since the program has no input). Per agreement the following builtins are out: open(), file(), input(), raw_input(), compile(), eval(), execfile(), and the exec statement. But I assume the print statement is okay (the program must communicate its success or failure *somehow*). I'm being nice, and am voluntarily refraining from using __builtins__, basestring, callable(), __import__(), reload(), dir(), globals(), locals(), vars(), help(), apply(), buffer(), coerce(), or intern(). I'm also not digging around in the func_code attribute of function objects. --Guido van Rossum (home page: http://www.python.org/~guido/)