make faster Richards benchmark

Duncan Booth me at privacy.net
Thu May 13 05:15:53 EDT 2004


dlissett0 at yahoo.com (Duncan Lissett) wrote in 
news:6748553f.0405122211.5be5a150 at posting.google.com:

> I'd appreciate any suggestions on how to make faster Python
> implementations of Richards benchmark. Perhaps there are obvious
> problems that can be corrected?

That should say "the Richards benchmark", named for Martin Richards.

> 
> http://www.lissett.com/ben/bench1.htm

Well, if I was going to do a Python implementation of this I would want to 
look at what the benchmark is trying to achieve, and then program it fresh 
from the ground up instead of trying to ape some other language. In 
particular I expect that the classes with 'run' methods would probably 
become generators with most or all of their state held as local variables.

For example, imagining that all the 'run' methods have first been renamed 
'next', IdleTask becomes (untested):

def IdleTask(scheduler, v1, v2):
    for i in range(v2):
       if v1 & 1:
    	    	v1 = (v1 >> 1) ^ 0xD008
    	    	yield scheduler.release(DEVICEB)
       else:
    	    	v1 = v1 >> 1
    	    	yield scheduler.release(DEVICEA)
    yield scheduler.holdCurrent()

Next most obvious thing is to junk the linked lists and replace them with 
ordinary Python builtin lists. Pass the relevant list around instead of the 
id constants 'DEVICEA', 'DEVICEB' and you can get rid of all that lookup 
overhead. This involves quite a major restructuring of the scheduler 
though: hence my comment about understanding what the code is trying to 
achieve and starting from the ground up.

Packet.addTo should look more like:

    	def addTo(self, queue):
    	    queue.append(self)

and then vapourise entirely.


Minor points:

Remove the pointless use of the 'global' keyword in various places. Replace 
the traceOn variable with __debug__ so you get the same benefits as 
compiled languages by optimising out the test for the trace statements.

Remove the pointless set/get methods and just access the members directly. 
If you are writing a benchmark they will cripple performance.

Avoiding multiple accesses to the same instance variable, or assigning to 
instance variables until you are about to return from a method: use a local 
during the execution of the method.



More information about the Python-list mailing list