make faster Richards benchmark

[Duncan Lissett]

Duncan Booth <me at privacy.net> wrote in message news:<Xns94E8683D9EEF2duncanrcpcouk at 127.0.0.1>...
 
-snip-
> 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.

Thanks, these are all interesting suggestions. 


> 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.

The pointless set/get methods are pointless in the other language
implementations as well - that's the point. (And I'll cripple that
Oberon-2 implementation real soon by enforcing privacy with modules
and set/get procedures.)

OTOH there's definitely a place for a truly Pythonic implementation
here:
http://www.lissett.com/ben/bench3.htm 

best wishes, Duncan