Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > make faster Richards benchmark

Reply
Thread Tools

make faster Richards benchmark

 
 
Duncan Lissett
Guest
Posts: n/a
 
      05-13-2004
I'd appreciate any suggestions on how to make faster Python
implementations of Richards benchmark. Perhaps there are obvious
problems that can be corrected?

http://www.lissett.com/ben/bench1.htm
 
Reply With Quote
 
 
 
 
Peter Maas
Guest
Posts: n/a
 
      05-13-2004
Duncan Lissett wrote:
> I'd appreciate any suggestions on how to make faster Python
> implementations of Richards benchmark. Perhaps there are obvious
> problems that can be corrected?


The most obvious problem: how does the Richards benchmark work?
Care to post the source code?

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel +49-241-93878-0 Fax +49-241-93878-20 eMail http://www.velocityreviews.com/forums/(E-Mail Removed)
-------------------------------------------------------------------
 
Reply With Quote
 
 
 
 
Josef Meile
Guest
Posts: n/a
 
      05-13-2004
Duncan Lissett wrote:
> I'd appreciate any suggestions on how to make faster Python
> implementations of Richards benchmark. Perhaps there are obvious
> problems that can be corrected?
>
> http://www.lissett.com/ben/bench1.htm

What's about including a second python implementation of the Richards
benchmark using psyco? You don't have to modify your code, you only have
to add two lines. It would be also interesting to see the differences
between both source codes.

Regards,
Josef
 
Reply With Quote
 
Michel Claveau/Hamster
Guest
Posts: n/a
 
      05-13-2004
Hi !

On the site, click on the word "Python #92"




 
Reply With Quote
 
Wilk
Guest
Posts: n/a
 
      05-13-2004
(E-Mail Removed) (Duncan Lissett) writes:

> I'd appreciate any suggestions on how to make faster Python
> implementations of Richards benchmark. Perhaps there are obvious
> problems that can be corrected?
>
> http://www.lissett.com/ben/bench1.htm


import psyco
psyco.full()

2 times faster

--
Wilk - http://flibuste.net
 
Reply With Quote
 
Duncan Booth
Guest
Posts: n/a
 
      05-13-2004
(E-Mail Removed) (Duncan Lissett) wrote in
news:(E-Mail Removed) om:

> 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.
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      05-13-2004
Josef Meile wrote:

> Duncan Lissett wrote:
>
>> I'd appreciate any suggestions on how to make faster Python
>> implementations of Richards benchmark. Perhaps there are obvious
>> problems that can be corrected?
>>
>> http://www.lissett.com/ben/bench1.htm

>
> What's about including a second python implementation of the Richards
> benchmark using psyco? You don't have to modify your code, you only have
> to add two lines. It would be also interesting to see the differences
> between both source codes.


I get an immediate 38% speedup by doing "import psyco; psyco.full()"
at the start of the benchmark.

-Peter
 
Reply With Quote
 
Peter Maas
Guest
Posts: n/a
 
      05-13-2004
Michel Claveau/Hamster wrote:
> On the site, click on the word "Python #92"


Thanks. Oh, how silly of me. I didn't recognize these as links,
still tuned to underscore links.

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel +49-241-93878-0 Fax +49-241-93878-20 eMail (E-Mail Removed)
-------------------------------------------------------------------
 
Reply With Quote
 
Duncan Lissett
Guest
Posts: n/a
 
      05-13-2004
Duncan Booth <(E-Mail Removed)> wrote in message news:<Xns94E8683D9EEF2duncanrcpcouk@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
 
Reply With Quote
 
Michel Claveau/Hamster
Guest
Posts: n/a
 
      05-13-2004
>>> Mit freundlichen Gruessen,

Désolé, je ne comprend pas l'allemand. Et pourtant, en octobre, je vais
aller là :
http://www.babstsoft.com/Paradox/Con...n04/Info_1.htm

Je présenterai PONX (Python for Paradox) (cf http://ponx.org)


@-salutations
--
Michel Claveau
mél : http://cerbermail.com/?6J1TthIa8B
site : http://mclaveau.com






 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
gcc, spectral-norm benchmark faster without optimizations Melzzzzz C++ 2 10-04-2012 10:37 AM
Does this benchmark make sense? Farhad Farzaneh Ruby 3 05-31-2007 07:23 AM
make faster Richards benchmark Duncan Lissett Ruby 11 06-01-2004 08:03 PM
RE: make faster Richards benchmark Simon Wittber Python 4 05-17-2004 12:53 AM
Re: Richards bench benchmark Peter Hansen Python 10 05-06-2004 11:02 PM



Advertisments