Percentage of time spent in method dispatch?

Discussion in 'Ruby' started by John Lam, Aug 17, 2006.

  1. John Lam

    John Lam Guest

    I was wondering if anyone had taken a look at what % of time that ruby
    spends doing method dispatch?

    I'll eventually do the experiments myself, but I wanted to check with
    y'all to see if someone had already done some investigations. It would
    be an interesting experiment to see how much you can improve method
    dispatch performance by caching the reference to the method call
    target, and invalidating it when the call context changes.

    Thanks,
    -John
    http://www.iunknown.com
     
    John Lam, Aug 17, 2006
    #1
    1. Advertising

  2. John Lam

    Guest

    On Aug 17, 2006, at 5:05 PM, John Lam wrote:
    > I'll eventually do the experiments myself, but I wanted to check with
    > y'all to see if someone had already done some investigations. It would
    > be an interesting experiment to see how much you can improve method
    > dispatch performance by caching the reference to the method call
    > target, and invalidating it when the call context changes.


    I'm not an internals expert, but I think the difficulty in optimizing
    Ruby
    method dispatch is that the result of a dispatch is not determined
    by the local context but instead is determined by the state of all
    the module objects searched during method dispatch:
    singleton class
    class and super classes
    included modules in all of the above



    Gary Wright
     
    , Aug 17, 2006
    #2
    1. Advertising

  3. On Fri, Aug 18, 2006 at 06:05:12AM +0900, John Lam wrote:
    > I was wondering if anyone had taken a look at what % of time that ruby
    > spends doing method dispatch?
    >
    > I'll eventually do the experiments myself, but I wanted to check with
    > y'all to see if someone had already done some investigations. It would
    > be an interesting experiment to see how much you can improve method
    > dispatch performance by caching the reference to the method call
    > target, and invalidating it when the call context changes.


    The current implementation has a method cache whose hit rate is above 95% or
    so (don't remember the exact figure; it's not hard to reproduce anyway) ---
    full method lookups are relatively rare.

    Method dispatching is still fairly slow, though; I once measured that it took
    some ~200 instructions to run a CFUNC, and about half as much with YARV.
    Last time I read YARV's sources, it didn't have inline method caches (but it
    was caching constants, IIRC), but it's been a while and they might have been
    implemented meanwhile.

    --
    Mauricio Fernandez - http://eigenclass.org - singular Ruby
     
    Mauricio Fernandez, Aug 17, 2006
    #3
  4. John Lam

    John Lam Guest

    I'd be interested in doing some experiments with DynamicMethods in the
    CLR to see what kind of performance gains can happen with method
    dispatch. And direct method dispatch in the CLR is *very* fast, if we
    consider that each parameter is a boxed object reference (4 bytes) and
    the actuall call is a call indirect instruction. Dealing with closures
    is a bit more problematic though, and making that go fast could be
    difficult.

    It's also fairly straightforward to substitute one dynamic method for
    another one when a cache invalidation event occurs. It would be very
    interesting to study the existing implementation's method cache to see
    what the triggers for cache invalidation look like ...

    Thanks for the input!
    -John
    http://www.iunknown.com




    On 8/17/06, Mauricio Fernandez <> wrote:
    > On Fri, Aug 18, 2006 at 06:05:12AM +0900, John Lam wrote:
    > > I was wondering if anyone had taken a look at what % of time that ruby
    > > spends doing method dispatch?
    > >
    > > I'll eventually do the experiments myself, but I wanted to check with
    > > y'all to see if someone had already done some investigations. It would
    > > be an interesting experiment to see how much you can improve method
    > > dispatch performance by caching the reference to the method call
    > > target, and invalidating it when the call context changes.

    >
    > The current implementation has a method cache whose hit rate is above 95% or
    > so (don't remember the exact figure; it's not hard to reproduce anyway) ---
    > full method lookups are relatively rare.
    >
    > Method dispatching is still fairly slow, though; I once measured that it took
    > some ~200 instructions to run a CFUNC, and about half as much with YARV.
    > Last time I read YARV's sources, it didn't have inline method caches (but it
    > was caching constants, IIRC), but it's been a while and they might have been
    > implemented meanwhile.
    >
    > --
    > Mauricio Fernandez - http://eigenclass.org - singular Ruby
    >
    >
     
    John Lam, Aug 18, 2006
    #4
  5. Mauricio Fernandez wrote:
    > On Fri, Aug 18, 2006 at 06:05:12AM +0900, John Lam wrote:
    >> I was wondering if anyone had taken a look at what % of time that ruby
    >> spends doing method dispatch?
    >>
    >> I'll eventually do the experiments myself, but I wanted to check with
    >> y'all to see if someone had already done some investigations. It would
    >> be an interesting experiment to see how much you can improve method
    >> dispatch performance by caching the reference to the method call
    >> target, and invalidating it when the call context changes.

    >
    > The current implementation has a method cache whose hit rate is above 95% or
    > so (don't remember the exact figure; it's not hard to reproduce anyway) ---
    > full method lookups are relatively rare.
    >
    > Method dispatching is still fairly slow, though; I once measured that it took
    > some ~200 instructions to run a CFUNC, and about half as much with YARV.
    > Last time I read YARV's sources, it didn't have inline method caches (but it
    > was caching constants, IIRC), but it's been a while and they might have been
    > implemented meanwhile.
    >

    I'm about to re-post my profiling of Ruby on a moderate-sized "Matrix"
    benchmark. I'll post the link as soon as I get it re-run.
     
    M. Edward (Ed) Borasky, Aug 18, 2006
    #5
  6. Hi,

    On Thu, 17 Aug 2006 23:05:12 +0200, John Lam <> wrote:

    > I was wondering if anyone had taken a look at what % of time that ruby=


    > spends doing method dispatch?


    Here are some numbers. Running this code:

    max =3D 2000
    z =3D x =3D 0
    while (x+=3D1) <=3D max
    y =3D 0
    while (y+=3D1) <=3D max
    z =3D (x+y-z) % 32000
    end
    end

    takes about 5.5s in plain Ruby 1.8.4 (on my machine).

    Compiling it with Ruby2CExtension (latest version, all optimizations =

    turned on) and then running it takes about 0.9s.

    One of the optimizations is to bypass rb_call and calling the C function=
    s =

    of those methods (almost) directly (when possible).

    If this optimization is turned off then running the compiled code takes =
    =

    about 3.1s. These additional 2.2s are all spent for method dispatch.

    Plain Ruby spends at least the same time for method dispatch, so Ruby =

    spends at least 40% of the time doing method dispatch (in this case).


    I hope that helps,
    Dominik
     
    Dominik Bathon, Aug 18, 2006
    #6
  7. M. Edward (Ed) Borasky wrote:
    > Mauricio Fernandez wrote:
    >> On Fri, Aug 18, 2006 at 06:05:12AM +0900, John Lam wrote:
    >>> I was wondering if anyone had taken a look at what % of time that ruby
    >>> spends doing method dispatch?
    >>>
    >>> I'll eventually do the experiments myself, but I wanted to check with
    >>> y'all to see if someone had already done some investigations. It would
    >>> be an interesting experiment to see how much you can improve method
    >>> dispatch performance by caching the reference to the method call
    >>> target, and invalidating it when the call context changes.

    >> The current implementation has a method cache whose hit rate is above 95% or
    >> so (don't remember the exact figure; it's not hard to reproduce anyway) ---
    >> full method lookups are relatively rare.
    >>
    >> Method dispatching is still fairly slow, though; I once measured that it took
    >> some ~200 instructions to run a CFUNC, and about half as much with YARV.
    >> Last time I read YARV's sources, it didn't have inline method caches (but it
    >> was caching constants, IIRC), but it's been a while and they might have been
    >> implemented meanwhile.
    >>

    > I'm about to re-post my profiling of Ruby on a moderate-sized "Matrix"
    > benchmark. I'll post the link as soon as I get it re-run.
    >
    >

    All done and uploaded ... the link is

    http://rubyforge.org/cgi-bin/viewvc.cgi/MatrixBenchmark/?root=cougar

    I re-ran this in single-user mode, so there is little interference from
    X, etc.
     
    M. Edward (Ed) Borasky, Aug 18, 2006
    #7
  8. Hi,

    Mauricio Fernandez wrote:
    > Method dispatching is still fairly slow, though; I once measured that it took
    > some ~200 instructions to run a CFUNC, and about half as much with YARV.
    > Last time I read YARV's sources, it didn't have inline method caches (but it
    > was caching constants, IIRC), but it's been a while and they might have been
    > implemented meanwhile.


    YARV already has inline method cache (see vm.c).

    --
    // SASADA Koichi at atdot dot net
     
    SASADA Koichi, Aug 21, 2006
    #8
  9. M. Edward (Ed) Borasky wrote:
    >
    >>

    > All done and uploaded ... the link is
    >
    > http://rubyforge.org/cgi-bin/viewvc.cgi/MatrixBenchmark/?root=cougar
    >
    > I re-ran this in single-user mode, so there is little interference from
    > X, etc.
    >

    Updated over the weekend. YARV is about four times as fast as Ruby
    1.8.5! I'll probably rerun the profiling using "oprofile", though.
    "gprof" seems to have too low a sampling frequency to determine what's
    really going on with "reasonable" run times -- 1 to 10 minutes.
    >
     
    M. Edward (Ed) Borasky, Aug 21, 2006
    #9
    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. Dan
    Replies:
    0
    Views:
    379
  2. Replies:
    5
    Views:
    604
    Laurent Bugnion
    Apr 26, 2006
  3. Replies:
    3
    Views:
    457
    Nick Craig-Wood
    Feb 6, 2007
  4. xianwei
    Replies:
    20
    Views:
    719
    Guy Macon
    Sep 29, 2007
  5. lyallex
    Replies:
    8
    Views:
    383
    lyallex
    Oct 27, 2007
Loading...

Share This Page