[#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

Re: Ruby performance improvements

From: Charles Oliver Nutter <charles.nutter@...>
Date: 2006-11-13 05:19:34 UTC
List: ruby-core #9523
Michael Selig wrote:
> ----- Original Message -----
> From: "Charles Oliver Nutter" <charles.nutter@sun.com>
> 
> 
>>> 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".
>> This one I haven't tried, but it's a great idea. I could modify the
>> yield logic in our ThreadContext to do loops natively, likely improving
>> the performance of such loops quite a bit. One concern would be making
>> sure the looped block doesn't capture additional scope...you'd
>> negatively effect the resulting capture
> The code I wrote checks for this, and if the scope has been captured, it
> allocates a new dynamic block. Luckily it was very simple to implement, as
> ruby sets a flag DVAR_DONT_RECYCLE when the scope is captured.

Interesting...we could probably do the same in JRuby to reduce the 
overhead of repeat block invocations.

> One other thing that I think is worth doing is to make variables created in
> a block into "local" variables rather than "dynamic" if possible, keeping
> dynamic variables for ones that the parser cannot pick up (eg: created by
> "eval"). Dynamic variables are accessed significantly slower than local
> ones, because a linear search is done (in 1.8 anyhow). This change would
> eliminate the unnecessary (and ugly) initialization of a variable before a
> loop simply to make it "local" and hence faster. Furthermore it would
> probably eliminate the use of dynamic variables completely in most loops,
> which would mean that a new block of dynamic variables could be created
> lazily for extra efficiency. Does YARV address this at all?

We've done this in JRuby already; all logic for "dynamic vars" is the 
same as for "local vars", rather than the linear search done before. I 
believe YARV also addresses this for dvars, since in the YARV bytecode 
dvars are specified by two numbers: var index and depth. We have the 
same logic in JRuby today.

-- 
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ www.headius.com/rubyspec
headius@headius.com -- charles.nutter@sun.com

In This Thread