make faster Richards benchmark

Discussion in 'Ruby' started by Duncan Lissett, May 24, 2004.

  1. 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
     
    Duncan Lissett, May 24, 2004
    #1
    1. Advertising

  2. Duncan Lissett

    Phil Tomson Guest

    In article <>,
    Duncan Lissett <> 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
     
    Phil Tomson, May 24, 2004
    #2
    1. Advertising

  3. il 23 May 2004 22:21:12 -0700, (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.
     
    gabriele renzi, May 24, 2004
    #3
  4. Duncan Lissett

    Isaac Gouy Guest

    gabriele renzi <> wrote in message news:<>...

    > 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.
     
    Isaac Gouy, May 25, 2004
    #4
  5. Duncan Lissett

    denis Guest

    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
     
    denis, May 25, 2004
    #5
  6. il 25 May 2004 04:59:27 -0700, (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 :)
     
    gabriele renzi, May 25, 2004
    #6
  7. (Isaac Gouy) wrote in message news:<>...

    > 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.
     
    Duncan Lissett, May 25, 2004
    #7
  8. (denis) wrote in message news:<>...

    > 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.
     
    Duncan Lissett, May 26, 2004
    #8
  9. Duncan Lissett <> wrote:
    > (denis) wrote in message news:<>...
    >
    > > 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
     
    Martin DeMello, May 27, 2004
    #9
  10. Martin DeMello <> 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.)
     
    Duncan Lissett, May 27, 2004
    #10
  11. Duncan Lissett <> wrote:
    > Martin DeMello <> 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.


    Mostly that the more clever optimisation we use, the harder it's going
    to be to separate "ruby benchmarks better than python does" from "the
    ruby guys did a better job of implementing this than the python guys
    did". OTOH the fact that it's easier to do a better implementation in
    ruby may be more significant than the raw speed of the interpreter :)

    martin
     
    Martin DeMello, May 29, 2004
    #11
  12. Martin DeMello <> wrote in message news:<XFVtc.579069$Pk3.488631@pd7tw1no>...

    > Mostly that the more clever optimisation we use, the harder it's going
    > to be to separate "ruby benchmarks better than python does" from "the
    > ruby guys did a better job of implementing this than the python guys
    > did". OTOH the fact that it's easier to do a better implementation in
    > ruby may be more significant than the raw speed of the interpreter :)


    Broadly, I agree.

    The differences due to implementation 'style' (OO & Original) are also
    interesting to me. Does the language even allow a non-OO approach?
    Does the type system get in the way?

    All good, clean, fun ;-)
     
    Duncan Lissett, Jun 1, 2004
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Hansen

    Re: Richards bench benchmark

    Peter Hansen, Apr 2, 2004, in forum: Python
    Replies:
    10
    Views:
    465
    Duncan Lissett
    May 7, 2004
  2. Duncan Lissett

    make faster Richards benchmark

    Duncan Lissett, May 13, 2004, in forum: Python
    Replies:
    15
    Views:
    789
    Duncan Lissett
    May 14, 2004
  3. Simon Wittber

    RE: make faster Richards benchmark

    Simon Wittber, May 14, 2004, in forum: Python
    Replies:
    4
    Views:
    306
    Duncan Lissett
    May 17, 2004
  4. Farhad Farzaneh

    Does this benchmark make sense?

    Farhad Farzaneh, May 31, 2007, in forum: Ruby
    Replies:
    3
    Views:
    123
    Brian Candler
    May 31, 2007
  5. Melzzzzz
    Replies:
    2
    Views:
    330
    Melzzzzz
    Oct 4, 2012
Loading...

Share This Page