Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

make faster Richards benchmark

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

http://www.lissett.com/ben/bench1.htm
 
Reply With Quote
 
 
 
 
Phil Tomson
Guest
Posts: n/a
 
      05-24-2004
In article <(E-Mail Removed) >,
Duncan Lissett <(E-Mail Removed)> wrote:
>I'd appreciate any suggestions on how to make a faster Ruby
>implementation of Richards benchmark. Perhaps there are obvious
>problems that can be corrected?
>
>http://www.lissett.com/ben/bench1.htm



Have you tried the profiler on this code?

put 'require 'profile' at the top of the code.

This seems to be a fairly involved benchmark, so profiling it should help
to narrow down which parts of the code to concentrate your optimization
efforts on.

Check out the "When Trouble Strikes" chapter of the Programming Ruby book
(especially 'But it's too slow') online here:

http://phrogz.net/programmingruby/

Phil
 
Reply With Quote
 
 
 
 
gabriele renzi
Guest
Posts: n/a
 
      05-24-2004
il 23 May 2004 22:21:12 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) (Duncan Lissett) ha
scritto::

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




this:
class Scheduler
@table
@list
@currentTcb
@currentId
@v1
@v2
@queueCount
@holdCount

def initialize()
@table = Array.new(MAXTASKS,nil)
@list = nil
@queueCount = 0
@holdCount = 0
end

is not what you think, I believe
You can remove the @vars, at the top, leave thos in the method calls.
you don't need to show to ruby that they're instance variables the @
does this already

then remove the useless (). And the useless 'then's and 'return's

Next, I believe you could use attr_accessor for *many* variables.
And use a Task superclass will make the code much shorter I believe

Using Array.at(someIndex) is slightly faster than array[someIndex].

And I believe there is a linked list to handle a queue that probably
could be replaced from a normal Array.

Anyway, I believe that code should be rewritten from the specs, more
than just 'ported' from some other language.
hope this helps.
 
Reply With Quote
 
Isaac Gouy
Guest
Posts: n/a
 
      05-25-2004
gabriele renzi <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..

> You can remove the @vars, at the top, leave thos in the method calls.
> then remove the useless (). And the useless 'then's and 'return's


Thanks - the returns aren't useless

> Next, I believe you could use attr_accessor for *many* variables.

And interestingly that makes things somewhat faster.

> And use a Task superclass will make the code much shorter I believe

Yes, I just like to demonstrate the lack of superclass or interface.

> Using Array.at(someIndex) is slightly faster than array[someIndex].

Yes, it is.
Using integer literals instead of constants made things a little
faster too.

> And I believe there is a linked list to handle a queue that probably
> could be replaced from a normal Array.

It could, but it seems to be ~10% slower

> Anyway, I believe that code should be rewritten from the specs, more
> than just 'ported' from some other language.


I'd certainly be interested in seeing other implementations - there
are procedural implementations at
http://www.lissett.com/ben/bench3.htm

Seems like Ruby shows best with an OO style implementation
http://www.lissett.com/ben/bench1.htm

Phil, Gabriele, thanks for those suggestions.
 
Reply With Quote
 
denis
Guest
Posts: n/a
 
      05-25-2004
Nice that we are now faster than python, but there is still room for
small improvements.
You can find my version here:

http://flwrpwr.free.fr/Ruby/bench/bench27.rb

It is based on version #26 of the ruby OO bench, with the following
changes:

* precompile the isHeldOrSuspended? expression (this gives the
largest speed gain)
* use
@state |= x
instead of
@state = @state | x
(it is slightly faster)
* remove unneeded temporary variables and unused return values
* rewrite some conditionals in a more rubyish way (and more efficient)
* make better use of conditionals return value (eg like in Tcb.run)
* use symbols to represent packet kind. (this is more a style change,
speed is unchanged)
* in WorkerTask.run, use collect! to change the content of packet.a2

The speed gain between my version and #26 is approximatelly the same
as between #26 and #25.


Bye bye

Denis
 
Reply With Quote
 
gabriele renzi
Guest
Posts: n/a
 
      05-25-2004
il 25 May 2004 04:59:27 -0700, (E-Mail Removed) (denis) ha scritto::

>Nice that we are now faster than python, but there is still room for
>small improvements.
>You can find my version here:
>
>http://flwrpwr.free.fr/Ruby/bench/bench27.rb
>
>It is based on version #26 of the ruby OO bench, with the following
>changes:


another little thing:
maybe using the ugly c-ish ternary op instead of if..then..else in
tcp.initialize may bring something ? (I see it in other places).

Also, I know asyntotically it's irrelevant, but maybe using one single
print statement with sharp-braket interpolation in main() may bring
something, and You should be able to replace Proces.times.utime with
Time.now, dunno if it gains something.
Just to go ander 100
 
Reply With Quote
 
Duncan Lissett
Guest
Posts: n/a
 
      05-25-2004
(E-Mail Removed) (Isaac Gouy) wrote in message news:<(E-Mail Removed). com>...

> Seems like Ruby shows best with an OO style implementation
> http://www.lissett.com/ben/bench1.htm


Well I haven't tried a procedural implementation in Ruby.
Isaac thanks for the comments.
 
Reply With Quote
 
Duncan Lissett
Guest
Posts: n/a
 
      05-26-2004
(E-Mail Removed) (denis) wrote in message news:<(E-Mail Removed) om>...

> Nice that we are now faster than python, but there is still room for
> small improvements.
> You can find my version here:
> http://flwrpwr.free.fr/Ruby/bench/bench27.rb


Thanks for taking a careful look at what could be done.

> * precompile the isHeldOrSuspended? expression (this gives the
> largest speed gain)


If we convert those boolean conditions to a table lookup then we
should do the same in the other language implementations - so although
it's a nice optimization I haven't used it.

(You'll probably notice there are still a couple of "mistakes" where
code could be simplified - the same mistakes exist in the other
language implementations, so they'll have to wait until I feel like
changing all the implementations.)

> * use
> @state |= x
> instead of
> @state = @state | x

Good catch.

> * rewrite some conditionals in a more rubyish way (and more efficient)

zero? Good.

> * make better use of conditionals return value (eg like in Tcb.run)

I understand we could do that, it doesn't seem as readable to me so I
wouldn't.

> * use symbols to represent packet kind. (this is more a style change,
> speed is unchanged)


> * in WorkerTask.run, use collect! to change the content of packet.a2

Thanks, a newbie like me would never have found that.

> The speed gain between my version and #26 is approximatelly the same
> as between #26 and #25.


The more limited changes I've taken from your example make #28 ~0.7s
faster.
 
Reply With Quote
 
Martin DeMello
Guest
Posts: n/a
 
      05-27-2004
Duncan Lissett <(E-Mail Removed)> wrote:
> (E-Mail Removed) (denis) wrote in message news:<(E-Mail Removed) om>...
>
> > Nice that we are now faster than python, but there is still room for
> > small improvements.
> > You can find my version here:
> > http://flwrpwr.free.fr/Ruby/bench/bench27.rb

>
> Thanks for taking a careful look at what could be done.


Isn't the point of the benchmark to compare straightforward code that
can be reasonably be said to be equivalent in all the various languages?

martin
 
Reply With Quote
 
Duncan Lissett
Guest
Posts: n/a
 
      05-27-2004
Martin DeMello <(E-Mail Removed)> wrote in message news:<m4ftc.603356$Ig.361204@pd7tw2no>...

> > > Nice that we are now faster than python, but there is still room for
> > > small improvements.
> > > You can find my version here:
> > > http://flwrpwr.free.fr/Ruby/bench/bench27.rb

> >
> > Thanks for taking a careful look at what could be done.

>
> Isn't the point of the benchmark to compare straightforward code that
> can be reasonably be said to be equivalent in all the various languages?


Martin, I don't understand what point you're making - spell it out for
me.

There is one obvious difference between the language implementations -
the Smalltalks, Pythons, and Ruby use numeric literals in the Tcb
class. That's pretty questionable (Other differences are probably
unintended.)
 
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
RE: make faster Richards benchmark Simon Wittber Python 4 05-17-2004 12:53 AM
make faster Richards benchmark Duncan Lissett Python 15 05-14-2004 10:14 PM
Re: Richards bench benchmark Peter Hansen Python 10 05-06-2004 11:02 PM



Advertisments