[#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: Thomas Enebo <Thomas.Enebo@...>
Date: 2006-11-13 15:02:49 UTC
List: ruby-core #9530
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.
>   
> 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?
>   

Actually, in JRuby I have changed all dvar and localvars (same for 
assigns) to be indexed on depth and index.   All the live local/dvar 
scopes are maintained in a single stack (with captured scopes as 
spaghetti stacks off each live scope).   localvars and dvars need not be 
distinguishable after parse storing things this way.  Also, it also 
gives the same relative cost of access between the two types.  So in a 
sense I did what you suggested (though I think because of the JVM GC 
this may be easier to implement for JRuby -- e.g. we do not have to 
manage whether this stuff is still referenced or not).

You still obviously need to differentiate between the two types of vars 
at parse-time so you can appropriately scope (calculate level and index).

I think this is a pretty good idea.  For one, it could simplify YARV 
instruction set by removing two extra instructions.

-Tom


In This Thread