[#16116] RCRchive shutting down — "David A. Black" <dblack@...>

Hi everyone --

22 messages 2008/04/03
[#16119] Re: [ANN] RCRchive shutting down — "Robert Dober" <robert.dober@...> 2008/04/03

This is quite sad news, I feel that a mailing list does not offer all

[#16121] Re: [ANN] RCRchive shutting down — Yukihiro Matsumoto <matz@...> 2008/04/03

Hi,

[#16122] Re: [ANN] RCRchive shutting down — "Robert Dober" <robert.dober@...> 2008/04/03

On Thu, Apr 3, 2008 at 12:01 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#16123] issue tracking (Re: [ANN] RCRchive shutting down) — Yukihiro Matsumoto <matz@...> 2008/04/03

Hi,

[#16124] Re: issue tracking (Re: [ANN] RCRchive shutting down) — "Meinrad Recheis" <meinrad.recheis@...> 2008/04/03

On Thu, Apr 3, 2008 at 1:13 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#16128] RUBY_IMPLEMENTATION — Yukihiro Matsumoto <matz@...>

Hi,

60 messages 2008/04/03
[#16139] Re: RUBY_IMPLEMENTATION — Paul Brannan <pbrannan@...> 2008/04/03

On Thu, Apr 03, 2008 at 11:41:41PM +0900, Yukihiro Matsumoto wrote:

[#16143] Re: RUBY_IMPLEMENTATION — Eric Hodel <drbrain@...7.net> 2008/04/03

On Apr 3, 2008, at 10:59 AM, Paul Brannan wrote:

[#16146] Re: RUBY_IMPLEMENTATION — Yukihiro Matsumoto <matz@...> 2008/04/03

Hi,

[#16147] Re: RUBY_IMPLEMENTATION — Ezra Zygmuntowicz <ezmobius@...> 2008/04/03

[#16149] Re: RUBY_IMPLEMENTATION — Charles Oliver Nutter <charles.nutter@...> 2008/04/03

Ezra Zygmuntowicz wrote:

[#16155] Re: RUBY_IMPLEMENTATION — "Yemi I. D. Bedu" <yemi@...> 2008/04/03

Hello,

[#16158] Re: RUBY_IMPLEMENTATION — Charles Oliver Nutter <charles.nutter@...> 2008/04/03

Yemi I. D. Bedu wrote:

[#16175] Re: RUBY_IMPLEMENTATION — Eleanor McHugh <eleanor@...> 2008/04/04

On 4 Apr 2008, at 00:23, Charles Oliver Nutter wrote:

[#16194] Re: RUBY_IMPLEMENTATION — Chris Cummer <chris@...> 2008/04/04

On 4-Apr-08, at 3:05 AM, Eleanor McHugh wrote:

[#16195] Re: RUBY_IMPLEMENTATION — "Luis Lavena" <luislavena@...> 2008/04/04

On Fri, Apr 4, 2008 at 2:15 PM, Chris Cummer <chris@postal-code.com> wrote:

[#16240] syntax request — "ry dahl" <ry@...>

Often times when one has many long arguments and orders them like this

42 messages 2008/04/06
[#16263] Re: syntax request — "Bill Kelly" <billk@...> 2008/04/07

[#16266] Re: syntax request — "David A. Black" <dblack@...> 2008/04/08

On Tue, 8 Apr 2008, Bill Kelly wrote:

[#16282] Re: syntax request — Paul Brannan <pbrannan@...> 2008/04/08

On Tue, Apr 08, 2008 at 02:23:26PM +0900, David A. Black wrote:

[#16290] Could someone confirm signal handling is broken on OSX? — Dave Thomas <dave@...>

I've raised this before, but no one replied. I'd like to double check

12 messages 2008/04/08

[#16359] design meeting — Yukihiro Matsumoto <matz@...>

Hi,

18 messages 2008/04/12

[#16397] Ruby 1.8.7-preview1 has been released — "Akinori MUSHA" <knu@...>

Folks,

16 messages 2008/04/15

[#16482] Performance on method dispatch for methods defined via define_method — "Robert Dober" <robert.dober@...>

Hi

32 messages 2008/04/22
[#16483] Re: Performance on method dispatch for methods defined via define_method — Paul Brannan <pbrannan@...> 2008/04/22

On Wed, Apr 23, 2008 at 12:39:29AM +0900, Robert Dober wrote:

[#16484] Re: Performance on method dispatch for methods defined via define_method — "Robert Dober" <robert.dober@...> 2008/04/22

On Tue, Apr 22, 2008 at 8:46 PM, Paul Brannan <pbrannan@atdesk.com> wrote:

[#16487] Re: Performance on method dispatch for methods defined via define_method — "David A. Black" <dblack@...> 2008/04/22

Hi --

[#16488] Re: Performance on method dispatch for methods defined via define_method — "Robert Dober" <robert.dober@...> 2008/04/22

On Tue, Apr 22, 2008 at 10:44 PM, David A. Black <dblack@rubypal.com> wrote:

[#16490] Re: Performance on method dispatch for methods defined via define_method — "David A. Black" <dblack@...> 2008/04/22

Hi --

[#16501] Re: Performance on method dispatch for methods defined via define_method — ts <decoux@...> 2008/04/23

Robert Dober wrote:

[#16507] Drop :: as a . synonym — "David A. Black" <dblack@...>

Hi --

50 messages 2008/04/23
[#16511] Re: [RCR] Drop :: as a . synonym — Charles Oliver Nutter <charles.nutter@...> 2008/04/23

David A. Black wrote:

[#16512] Re: [RCR] Drop :: as a . synonym — "David A. Black" <dblack@...> 2008/04/23

Hi --

[#16525] Re: [RCR] Drop :: as a . synonym — Charles Oliver Nutter <charles.nutter@...> 2008/04/23

David A. Black wrote:

[#16527] Re: [RCR] Drop :: as a . synonym — "David A. Black" <dblack@...> 2008/04/23

Hi --

[#16534] Re: [RCR] Drop :: as a . synonym — Thomas Enebo <Thomas.Enebo@...> 2008/04/23

David A. Black wrote:

[#16546] Re: [RCR] Drop :: as a . synonym — "David A. Black" <dblack@...> 2008/04/24

Hi --

[#16552] Re: [RCR] Drop :: as a . synonym — "Jeremy McAnally" <jeremymcanally@...> 2008/04/24

Or changing #send to private...or (insert progressive but code

[#16564] Re: [RCR] Drop :: as a . synonym — Charles Oliver Nutter <charles.nutter@...> 2008/04/24

Jeremy McAnally wrote:

[#16567] Re: [RCR] Drop :: as a . synonym — "David A. Black" <dblack@...> 2008/04/24

Hi --

[#16570] Re: [RCR] Drop :: as a . synonym — Yukihiro Matsumoto <matz@...> 2008/04/24

Hi,

[#16531] Re: [RCR] Drop :: as a . synonym — "Eric Mahurin" <eric.mahurin@...> 2008/04/23

On Wed, Apr 23, 2008 at 9:21 AM, David A. Black <dblack@rubypal.com> wrote:

Re: Performance on method dispatch for methods defined via define_method

From: Charles Oliver Nutter <charles.nutter@...>
Date: 2008-04-23 06:19:44 UTC
List: ruby-core #16498
David A. Black wrote:
> Hi --
> 
> On Wed, 23 Apr 2008, Robert Dober wrote:
> 
>> On Tue, Apr 22, 2008 at 10:44 PM, David A. Black <dblack@rubypal.com> 
>> wrote:
>>
>>>
>>>  class C
>>>   x = 100
>>>   define_method(:a) { x }
>>>   define_method(:b){ puts eval(gets.chomp)}
>>>  end
>>>
>>>
>>>  David
>> David I am afraid I do not get the point,
>> you just gave another example of a method that cannot be "inlined"
>> because of the
>> eval, but that is easily detectable during compile time.
>> I would need an example where the closure is needed and this fact
>> cannot be detected during compilation!
> 
>   define_method(:c) { puts send([101, 118, 97, 108].pack("C*"),
>   gets.chomp) }
> 
> :-)
> 
> I don't know... it seems to me that determining statically whether or
> not a block will refer back to its context would be really, really
> difficult, at the very least.

And thereforce certain types of blocks should not be allowed access to 
the enclosing scope/frame. I think the above examples are pretty bad 
karma too, and it's hard to argue how their utility outweighs the gross 
performance cost they incur.

Check out normal method dispatch versus other types in JRuby. The 
difference here is largely whether we can perform certain optimizations 
that depend on knowing whether certain variables escape the scope:

                                              user     system      total 
        real
control: 100x x100 local var access       0.009000   0.000000   0.009000 
(  0.009000)
core class: 100x x100 Fixnum#to_i         0.322000   0.000000   0.322000 
(  0.322000)
ruby method: 100k x100 self.foo           0.888000   0.000000   0.888000 
(  0.888000)
ruby method: 100k x100 self.foos          1.474000   0.000000   1.474000 
(  1.474000)
ruby method: 100k x100 self.foos(1)       1.610000   0.000000   1.610000 
(  1.610000)
ruby method: 100k x100 self.foos(4)       5.874000   0.000000   5.874000 
(  5.874000)
ruby method: 100k x100 self.foo1          1.137000   0.000000   1.137000 
(  1.137000)
ruby method: 100k x100 self.foo2          0.972000   0.000000   0.972000 
(  0.972000)
ruby method: 100k x100 self.foo3          1.070000   0.000000   1.070000 
(  1.070000)
ruby method: 100k x100 self.foo4          5.355000   0.000000   5.355000 
(  5.355000)
__send__ method: 100k x100 self.foo       2.360000   0.000000   2.360000 
(  2.360000)
ruby method(opt): 100k x100 self.baz      2.042000   0.000000   2.042000 
(  2.042000)
ruby method(no opt): 100k x100 self.baz   1.166000   0.000000   1.166000 
(  1.166000)
ruby method(block): 100k x100 self.quux   0.853000   0.000000   0.853000 
(  0.853000)
ruby method(block{}): 10k x100 self.quux  0.497000   0.000000   0.497000 
(  0.497000)
define_method method: 100k x100 calls     2.538000   0.000000   2.538000 
(  2.538000)


And then the same run with some experimental "more optimistic" 
frame/scope optimizations:

                                               user     system 
total        real
control: 100x x100 local var access       0.006000   0.000000   0.006000 
(  0.007000)
core class: 100x x100 Fixnum#to_i         0.253000   0.000000   0.253000 
(  0.253000)
ruby method: 100k x100 self.foo           0.413000   0.000000   0.413000 
(  0.413000)
ruby method: 100k x100 self.foos          1.104000   0.000000   1.104000 
(  1.105000)
ruby method: 100k x100 self.foos(1)       0.884000   0.000000   0.884000 
(  0.884000)
ruby method: 100k x100 self.foos(4)       1.067000   0.000000   1.067000 
(  1.067000)
ruby method: 100k x100 self.foo1          0.435000   0.000000   0.435000 
(  0.434000)
ruby method: 100k x100 self.foo2          0.286000   0.000000   0.286000 
(  0.286000)
ruby method: 100k x100 self.foo3          0.352000   0.000000   0.352000 
(  0.352000)
ruby method: 100k x100 self.foo4          0.620000   0.000000   0.620000 
(  0.620000)
__send__ method: 100k x100 self.foo       1.687000   0.000000   1.687000 
(  1.687000)
ruby method(opt): 100k x100 self.baz      1.571000   0.000000   1.571000 
(  1.571000)
ruby method(no opt): 100k x100 self.baz   0.448000   0.000000   0.448000 
(  0.448000)
ruby method(block): 100k x100 self.quux   0.443000   0.000000   0.443000 
(  0.443000)
ruby method(block{}): 10k x100 self.quux  0.434000   0.000000   0.434000 
(  0.434000)
define_method method: 100k x100 calls     2.472000   0.000000   2.472000 
(  2.472000)


Finally Ruby 1.9 for comparison:

                                               user     system 
total        real
control: 100x x100 local var access       0.010000   0.000000   0.010000 
(  0.006355)
core class: 100x x100 Fixnum#to_i         0.880000   0.000000   0.880000 
(  0.892870)
ruby method: 100k x100 self.foo           0.890000   0.000000   0.890000 
(  0.895106)
ruby method: 100k x100 self.foos          5.310000   0.010000   5.320000 
(  5.307588)
ruby method: 100k x100 self.foos(1)       5.490000   0.010000   5.500000 
(  5.506018)
ruby method: 100k x100 self.foos(4)       5.710000   0.010000   5.720000 
(  5.709975)
ruby method: 100k x100 self.foo1          0.950000   0.000000   0.950000 
(  0.949075)
ruby method: 100k x100 self.foo2          1.000000   0.000000   1.000000 
(  0.997541)
ruby method: 100k x100 self.foo3          1.040000   0.000000   1.040000 
(  1.048048)
ruby method: 100k x100 self.foo4          1.130000   0.000000   1.130000 
(  1.129857)
__send__ method: 100k x100 self.foo       1.060000   0.010000   1.070000 
(  1.063126)
ruby method(opt): 100k x100 self.baz      2.430000   0.000000   2.430000 
(  2.433559)
ruby method(no opt): 100k x100 self.baz   1.050000   0.000000   1.050000 
(  1.046770)
ruby method(block): 100k x100 self.quux   0.970000   0.000000   0.970000 
(  0.974937)
ruby method(block{}): 10k x100 self.quux  0.610000   0.000000   0.610000 
(  0.606299)
define_method method: 100k x100 calls     2.170000   0.010000   2.180000 
(  2.172675)


The ability to make optimizations depending on the callee's access to 
your frame/scope makes a tremendous difference in performance. With the 
more optimistic optimizations, JRuby's method dispatch can be as much as 
  4-8x as fast as Ruby 1.9.

Benchmark source is here: 
http://svn.codehaus.org/jruby/trunk/jruby/test/bench/language/bench_method_dispatch.rb

- Charlie

In This Thread