[#9382] the sign of a number is omitted when squaring it. -2**2 vs (-2)**2 — <noreply@...>

Bugs item #6468, was opened at 2006-11-03 17:25

9 messages 2006/11/03

[#9385] merge YARV into Ruby — SASADA Koichi <ko1@...>

Hi,

42 messages 2006/11/04
[#9405] Re: merge YARV into Ruby — "Kirill Shutemov" <k.shutemov@...> 2006/11/06

On 11/4/06, SASADA Koichi <ko1@atdot.net> wrote:

[#9406] Re: merge YARV into Ruby — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2006/11/06

On Monday 06 November 2006 16:01, Kirill Shutemov wrote:

[#9417] Re: merge YARV into Ruby — Sean Russell <ser@...> 2006/11/06

On Monday 06 November 2006 10:15, Sylvain Joyeux wrote:

[#9428] Re: merge YARV into Ruby — "Kirill Shutemov" <k.shutemov@...> 2006/11/06

On 11/6/06, Sean Russell <ser@germane-software.com> wrote:

[#9402] fast mutexes for 1.8? — MenTaLguY <mental@...>

Many people have been using Thread.critical for locking because Ruby

24 messages 2006/11/06

[#9450] Bikeshed: No more Symbol < String? — Kornelius Kalnbach <murphy@...>

Hi ruby-core!

21 messages 2006/11/07
[#9452] Re: Bikeshed: No more Symbol < String? — Yukihiro Matsumoto <matz@...> 2006/11/07

Hi,

[#9493] Future Plans for Ruby 1.8 Series — URABE Shyouhei <shyouhei@...>

This week Japanese rubyists were talking about the future of ruby_1_8

13 messages 2006/11/09

[#9515] External entropy pool for random number generator — "Kirill Shutemov" <k.shutemov@...>

In the attachment patch which allow to use external entropy pool for

13 messages 2006/11/11
[#9522] Re: External entropy pool for random number generator — "Nobuyoshi Nakada" <nobu@...> 2006/11/13

Hi,

[#9554] Ruby 1.[89].\d+ and beyond. — Hugh Sasse <hgs@...>

I've been thinking about how version numbers are restricting what we can do.

30 messages 2006/11/16
[#9561] Re: Ruby 1.[89].\d+ and beyond. — Eric Hodel <drbrain@...7.net> 2006/11/16

[#9563] Re: Ruby 1.[89].\d+ and beyond. — Hugh Sasse <hgs@...> 2006/11/16

On Fri, 17 Nov 2006, Eric Hodel wrote:

[#9564] Re: Ruby 1.[89].\d+ and beyond. — Eric Hodel <drbrain@...7.net> 2006/11/16

On Nov 16, 2006, at 12:02 PM, Hugh Sasse wrote:

[#9571] Re: Ruby 1.[89].\d+ and beyond. — "Robert Dober" <robert.dober@...> 2006/11/19

On 11/16/06, Eric Hodel <drbrain@segment7.net> wrote:

[#9604] #ancestors never includes the singleton class (inconsistent) — <noreply@...>

Bugs item #6820, was opened at 2006-11-22 08:49

12 messages 2006/11/22
[#9618] Re: [ ruby-Bugs-6820 ] #ancestors never includes the singleton class (inconsistent) — Yukihiro Matsumoto <matz@...> 2006/11/25

Hi,

[#9629] Re: [ ruby-Bugs-6820 ] #ancestors never includes the singleton class (inconsistent) — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2006/11/27

> It is supposed to. Singleton classes (or eigenclasses, if you want to

Ruby performanmce improvements

From: "Michael Selig" <michael.selig@...>
Date: 2006-11-08 05:53:38 UTC
List: ruby-core #9470
I know you guys are in the middle of YARV stuff, but I thought you might be
interested in some performance improvements (around 20%) I made to Ruby in
my spare time recently.

One afternoon when I had a bit of spare time I decided to compile Ruby with
profiling (C profiling that is), to try to see where it was spending most of
its time. Also I needed some benchmarks to test with, so, for want of
anything better, I took some ruby scripts from the "Computer Language
Shootout" (http://shootout.alioth.debian.org/).

I found 3 main areas which I then focused on:
1) rb_call() especially rb_call0()
2) Loops & rb_yield(), especially rb_yield_0()
3) The large number of recursive calls to rb_eval()

So addressing these one at a time:
1) rb_call()
I found that many of these calls are to CFUNC (internal C) methods such as
Fixnum#+, most of which are simple, and don't access anything other than
their parameters. However, in order to execute these methods, ruby is still
doing quite a bit of work in rb_call0(), such as setting up a stack frame
etc, which is usually not used. So I made an optimisation that if a CFUNC
method is being called, and no block is being passed to it, then it bypasses
stack frame creation. (I also had to make a small hack to "backtrace()" to
handle errors in this case).

2) Loops & rb_yield()
Most of Ruby's loops end up calling rb_yield() for each iteration. However
much of the work that rb_yield_0 does each time can be often be done once at
the start of the loop:
    - Pushing frame, block, vars, class etc
    - Freeing/creation of dynamic variables (instead they can be initialized
to NIL each time, unless the context has been saved)
Also loops done by rb_iterate() (via an IFUNC stub) can be simplified
further to reduce the overhead of "double-yield".

3) rb_eval() calls
I simply inlined the code for common, simple nodes such as: NODE_LIT,
NODE_LVAR etc in certain places within rb_eval(), which resulted in a large
reduction in the number of calls to rb_eval().

After applying these mods, I was able to achieve a performance improvement
averaging 20% (ie: 20% less User CPU time) under Linux/386 in the "shootout"
benchmarks. I know these are not representative of Ruby programs in general,
but I had to use something that was simple to time.

My mods are based on Ruby 1.8.4.

I am not 100% sure that my mods haven't broken something - especially in the
Garbage Collector (which I haven't really tried to understand), but it seems
to work fine here. I did not touch the parser at all.

Please let me know if you'd like me to post a patch. If I get some more
spare time, I'd be happy to look at the Ruby 2.0 code to see if similar
optimizations can be made.

Mike


In This Thread

Prev Next