gmane.comp.lang.ruby.rubinius.devel

Re: Does &method(:foo) get inlined? Can it? Should it?

Evan Phoenix — 2011-08-08T21:09:24

I think that using this style is certainly possible, but fairly obtuse to most rubyists. If you never wrote blocks and instead only wrote these &method(:blah) isms, the other programmers on your team would get frustrated with you.

That being said, you asked a technical question rather than a stylistic one, so I'll answer it technically.

You're assumption that it could be the same as a block is, I'm sad to say, dead wrong. There reason you don't see Method#to_proc and such in profiling is 2 fold:

1) Most (all?) MRI profilers do not show a methods that MRI defines in C, so they'd never show up.

2) The mechanism for activating a method that has been turned into a Proc is all in C, so the overhead is invisible on the invocation side too.

You're point about the arty differences are right on. Additionally, you're thinking that a VM could easily optimize it into a block is quite wrong. Object#method is a not specially, not something that would be detected and optimized away. Additionally, even with runtime optimizations, something like escape analysis is still required since #method returns a Method object that you'd have to see inside and extract the information from. On the invocation side, the invoked method can only do something special with the block in the case of block inlining, an optimization that only Rubinius has.

So to get to your questions:

1. Does Rubinius optimize this code? No. Could it? Yes, but it's hardly easy.
2. In time it could, yes.
3. In time it should, yes.

- Evan

Re: Does &method(:foo) get inlined? Can it? Should it?

Rich Morin — 2011-08-08T17:06:31

Although I understand your rationale for point-free style,
I should note that it will seem _really peculiar_ to many
Rubyists.  It might also cause maintenance issues, if the
maintainer doesn't understand the idiom.

This may not be a show-stopper, particularly if your code
isn't read or modified by others.  However, you should keep
it in mind for any distributed or shared code .

-r

Does &method(:foo) get inlined? Can it? Should it?

Jörg W Mittag — 2011-08-08T02:21:42

Hi.

I am a big fan of programming in point-free style, although
unfortunately Ruby makes that unnecessarily ugly. I.e., I very much
prefer

ary.each(&method(:puts))

over

ary.each {|el| puts el }

The reason for this is the old saying by Phil Karlton:

| There are only two hard problems in computer science. Cache invalidation and naming things.

If naming things is hard (i.e. expensive), then names shouldn't be
wasted on irrelevant things. And conversely, if something has a name,
then it is important.

The whole *point* of higher-level iteration methods like
Enumerable#each and friends is to lift collection operations over the
individual elements, IOW to make the individual elements not
important; ergo, the individual elements shouldn't need to be named.

However, today there was a StackOverflow question about the efficiency
of such point-free code, especially with regards to reified Method and
Proc objects.

Personally, I don't care. I have yet to see Object#method or
Method#to_proc even show up in any profile.

My first reaction was basically that any halfway decent Ruby execution
engine should be able to inline and optimize the point-free version
all the way back till it generates basically the same machine code as
the explicit one. However, I am now having second thoughts about
whether there are some aspects of the semantics of Method and Proc
objects that make it impossible for them to be as efficient as a
method call (which after speculative inlining typically ends up as
just a conditional jump).

Since Rubinius seems to be the most advanced and most aggressively
optimizing Ruby execution engine, I thought I'd ask here:

1. Does Rubinius currently optimize such point-free code?
2. If it doesn't, could it?
3. If it could, should it?

Thanks in advance!

Greetings,
jwm

Re: Re: Rubinius vs JRE

Dave Newton — 2011-08-01T19:06:05

The same could be said for any Ruby VM. Since most Ruby folks aren't
using the JVM, I don't really see that as a strong need for Rubinius
in particular--non-JRuby users are already using Ruby-only libs
anyway.

Dave

Re: Rubinius vs JRE

Dave Newton — 2011-08-01T19:02:36

It's in now.

Dave

Re: Rubinius vs JRE

Smock Jonathan — 2011-08-01T01:21:43

I saw that this didn't get a reply, so I figured I'd take a shot.  I've just
started to seriously get interested in contributing, so I may not have all
my history/facts straight.

1. Rubinius started as an interest/labor of love by Evan Phoenix.  It's
gotten sponsorship from EngineYard in the form of two employed developers
(Evan and Brian, I believe) that work on Rubinius full-time.  Predicting the
future is hard, but those two factors make me think Rubinius will be around
for some time.  Obviously the hope is for even more people to run their
programs and apps on Rubinius and contribute back to keep it going.

There has been talk about Rubinius being some kind of replacement for MRI
but not by either core team (I could be wrong here).  At very least, my
impression is that neither side is really pushing for it, and each core team
is content working on their own "branch" as they have different goals, etc.
 I personally don't think it will happen, which is fine.  Rubinius offers
its own advantages, which are distinct from the advantages of MRI (and
JRuby).  That said, Brian Ford was on an EngineYard podcast recently and
noted that one of Rubinius' goals is to be a drop-in replacement for MRI in
terms of compatibility, C extensions, etc.

2.  It seems you're asking about the Rubinius VM vs. the JVM, and I can't
speak to that intelligently.  All I know is the Rubinius VM is small as VMs
go and is designed to support the dynamic nature of Ruby.  The JVM is a
larger codebase but has a large amount of support to refine and extend it.
 The JVM is starting to add things like invoke-dynamic which will better
support dynamic languages, but it's being added now not baked in.  Again,
this is my extremely coarse understanding of the differences.

On Thu, Jul 28, 2011 at 8:41 AM, Glenn Dix <glenn.dix< at >gmail.com> wrote:

Re: Rubinius vs JRE

flebber — 2011-07-29T07:22:18


1. Since the MRI is C and Rubinius in Ruby whats to assimilate? Will
it last long term, that ultimately will depend on user base and
contributor base, use and contribute the longer it will last.

2. Better than JRE. The JRE is has evolved and has a lot of mature
libraries written against it. So for Rubinius to be better it will
need to mature and have contributors write and develop libraires. It
would have the potential to be better as the libraries can be written
in Ruby not limiting the user who can contribute libraries ie not
limited to java or c extension writers, now those experienced in Ruby
can contribute to the language they love directly.

Sayth

Rubinius vs JRE

Glenn Dix — 2011-07-28T12:41:44

The architecture for Rubinius looks like an exciting enhancement over
MRI in the areas of concurrency and memory management, but I have two
general questions:

1. Will the Rubinius project exist long-term, or will it be
assimilated into MRI or something else
2. How will Rubinius be better than the JRE, other than for directly
supporting Ruby (e.g. java.lang.NullPointerException, system clock
skewing, incompatibility between minor revisions and patch releases,
weekly high severity vulnerability findings, etc.)

Re: Re: [jruby-user] benchmark server almost ready

Rob Heittman — 2011-06-19T15:31:07

I'm concerned that spawning an EC2 instance for each run may result in a lot
of noise in the emerged benchmarks. I've found that the hardware that
acquires each instance can differ noticeably in characteristics and shared
load from run to run, even within the same AZ. Every now and then "bad,"
underperforming, instance launches may raise spurious alarm bells. On a
large operation across multiple instances, we always expect something like a
20% difference between the first instances to report a result and the last
ones ... and are never surprised by a few failures.

The noise would be less for a single long-lived instance, or best with a
dedicated piece of hardware with no competing loads. Not that I have one I
could reliably volunteer ... but for this very specific mission, it seems
like run-to-run improvement or degradation only really has meaning if as
many other variables as we can manage are taken away. Maybe some Ruby
activist has a nice old server spinning away in their data center that feels
lonely because all the fun has gone to the cloud?

Of course, I could be fretting over nothing -- this could be in the "try it
and see" category.

On Sun, Jun 19, 2011 at 10:19 AM, Chuck Remes <cremes.devlist< at >mac.com>wrote:

Re: benchmark server almost ready

Karol Hosiawa — 2011-06-19T16:36:28


On Jun 19, 3:36 pm, Chuck Remes <cremes.devl...< at >mac.com> wrote:


Could we use the syntax tree of do end block in x.report("name")
do ... end  instead of its name ? Something along these lines:

Digest::MD5.hexdigest("proc {|i| i.to_i}".to_sexp.to_s)

will generate a usable key in the db. If the benchmark code changes
the id will change but that's good, because it's not the same
benchmark anymore, right (Renaming a variable will change the sexp
signature and the id but I guess this is less likely to happen
(renaming the variable for the sake of renaming it vs. renaming a
report) ? We'll be able to rename benchmarks (eg. if there are many
more benchmarks in the future, we get similar names and want to name
them slightly differently and won't be limited by the number of chars
etc.)



If the cost is going to be high for an EC2 instance and we're planning
things like post-commit hooks maybe it's worth to consider a dedicated
box ?
Prices in Europe start from 29 EUR/month.

Thanks
--
Karol Hosiawa

Newbie trying to make Module.freeze prevent singleton methods being added

Aviv Ben-Yosef — 2011-06-17T07:43:32

Hey,

I'm fascinated by the project and so decided to try and to some small
stuff. After getting a trivial fix committed, I tried to find
something a bit more challenging, but I may have taken a bite a bit
too big.
Would love some direction about whether my steps are in the right path
and if this is indeed feasible without knowing too much of rubinius's
guts.

I saw that this spec fails: "Module#freeze prevents further
modifications to self"
It basically checks that after freezing a module, trying to define
singleton method on it raises a TypeError.

After some digging and comparing to the MRI I understood that while
MRI freezes the singleton class after freezing an object, rubinius
doesn't.
"Aha!", I thought. After digging, I ended up adding a simple change to
Object#singleton_class, something along the lines of:
    if (this->frozen_p(state) == Qtrue) cl->freeze(state);

This seems to achieve the right result of freezing the singleton
classes just like MRI, but then I found out it doesn't seem like
there's any guard to stop you from adding methods to frozen classes.

What would be the right way to continue from this point? I've tried
adding a trivial guard in Rubinius#add_method that raises the proper
error in case it was called on a frozen object, but then found out
add_method is currently called for lots of frozen objects, which
breaks everything pretty much.

Any directions/suggestions would be really appreciated. Especially if
I'm just making a big mess :)

Cheers,
Aviv Ben-Yosef
< at >avivby http://codelord.net

Re: Interfacing with the Rubinius VM

Josep M. Bach — 2011-05-14T15:24:13

Thanks everyone! I'll take a deeper look :)

Re: Interfacing with the Rubinius VM

Chuck Remes — 2011-05-03T21:28:43


I recommend taking a look at some of the other languages that have been implemented on top of rubinius and following their lead.

You can find a list here:  http://rubini.us/projects/

The most active one is probably Fancy. Also, a brand new one (not on the list yet) is Poetics which is a start on implementing the CoffeeScript language.

Most, if not all, of the projects are on github.

cr

Re: Interfacing with the Rubinius VM

Kurt Stephens — 2011-05-03T20:31:10

Write a Brainfuck-to-Ruby compiler.

On 5/3/11 12:46 PM, Josep M. Bach wrote:

Interfacing with the Rubinius VM

Josep M. Bach — 2011-05-03T17:46:46

Hello there,

This might not be the right place to ask this (please tell me whether it 
should be better to post this in the IRC or wherever else), but here I go:

I'm going with my first try to interface a programming language with the 
Rubinius VM. For starters, my choice is Brainfuck, since it's a dead-simple 
language.

As far as I know, I only need a table of cells and a pointer, and almost map 
the BF tokens (>, <, +, -...) to the VM instructions. I am a bit lost, since 
I practically don't know where to start. I've seen in other projects there 
is a Generator class sublassing Rubinius::Generator, and each AST node 
implements a #bytecode method that calls the instructions on the generator. 
How does it work exactly? I don't know how to set an initial state (the 
table of cells and the pointer pointing to cell 0).

How would you implement this? Any feedback is appreciated :)

Thanks!

Re: Rubinius Contribute to Open Source Session at upcoming Red Dirt RubyConf

ThirtySixthSpan — 2011-04-05T20:18:37

Limited late registration for 2 days of Red Dirt RubyConf for just
$199

We are super excited to announce that we are now able to offer
a special last-minute late registration for Red Dirt RubyConf
to help anyone who might not otherwise have been able to afford
to attend.

Not already registered? You can still JOIN US for two days of
conference presentations and hands-on training for the much
reduced price of just $199 for a bare-bones access pass.

http://reddirtrubyconf.com/program

This is a limited offer that we expect will sell out.

Red Dirt has one of the best conference lineups that you will
see at any Ruby conference. Our speakers are world-class
contributors in the Ruby and Javascript communities working
for leaders in the industry including Obtiva, Intridea, AT&T
Interactive, Hewlett Packard, Heroku, ThoughtBot, and
Engine Yard.

Red Dirt is a content rich two-day conference to be held in
Oklahoma City on April 21st and 22nd, 2011.
http://reddirtrubyconf.com/schedule

Can't make it?
Join the live video stream or order the conference videos!
http://reddirtrubyconf.com/program


On Mar 28, 1:54 pm, ThirtySixthSpan <derrick.parkhu...< at >gmail.com>
wrote:

Re: Speed tests

Evan Phoenix — 2011-03-31T16:30:58

Hi Philip,

I can't say anything about these numbers because I don't know what was being run or how it was being run. For most tight code, rbx is faster so it makes me wonder what you're benchmarking.

Also, you've included no units on your numbers. Are those seconds? milliseconds? microseconds? rbx has to warmup to get good performance, so that matters.

So could you please tell us:
1) what the units are
2) how you got these numbers
3) what the code was that was run

 - Evan


On Mar 31, 2011, at 3:07 AM, Philip Rhoades wrote:

Speed tests

Philip Rhoades — 2011-03-31T10:07:18

People,

I have talked to people here before about speeding up my population 
genetics scripts and have made a bit of progress with optimising etc but 
I thought I would compare the three versions of Ruby I have been looking 
at - NB these results are on my real (not test) code, albeit on a 
reduced number of iterations.

I ran the normal number of the inner two loops and only one of the 
outermost loop (ie 1/50th of the total) and got the following with the 
different versions of Ruby:

ruby-1.8.7-p334 [ x86_64 ]=  31.41
ruby-1.9.2-p180 [ x86_64 ]=  19.53
rbx-head [ ]= 128.42

I realise that rbx started as an interesting exercise but the general 
goal would to be eventually faster than v1.9? - if so, it seems like 
there is way to go yet?

Regards,

Phil.

VM searches for method relying on < at >superclass ivar, not on Module#direct_superclass. Is it a bug?

Daniel Vartanov — 2011-03-26T12:19:09

Hi!

I tried to play with superclass chain and here is what I've
discovered:

The first example, < at >superclass is changed and method is being found
correctly:

https://gist.github.com/888224

# Step 1. Setting up environment

class Government
  def power
    "belongs to government"
  end
end

module People
  def power
    "belogs to people"
  end

  Government.__send__ :include, self
end

government = Government.new


# Step 2. Swapping ancestors by re-setting < at >superclass

included_module = Government.instance_eval { < at >superclass }

government.metaclass.instance_eval { < at >superclass = included_module }
included_module.instance_eval { < at >superclass = Government }
Government.instance_eval { < at >superclass = Object }


# Step 3. Testing

puts government.metaclass.superclass_chain.inspect
# => [#<IncludedModule People>, Government, Object, #<IncludedModule
Kernel>] <-------- cool, prepended module is before Class
puts government.power
# =>  belongs to people  <--------- this is definitely right


The second example. Module#direct_superclass is changed.
Module#superclass_chain gives correct result, but wrong method is
being called.

https://gist.github.com/888225

module Rubinius
  class PrependedModule < IncludedModule
    attr_reader :module

    def initialize(mod, superclass)
      < at >module = mod
      < at >superclass = superclass
      super(mod)
    end

    def inspect
      "#<PrependedModule #{< at >module.to_s}>"
    end
  end
end

class Module
  attr_reader :prepended_module # for the sake of simplicity let's
take just one for now

  def prepend(mod)
    < at >prepended_module = Rubinius::PrependedModule.new(mod, self)
  end

  def direct_superclass
    if < at >superclass && < at >superclass.prepended_module &&
< at >superclass.prepended_module != self
      < at >superclass.prepended_module
    else
      < at >superclass
    end
  end
end


# -----------------------------------------

class Government
  def power
    "belongs to government"
  end
end

module People
  def power
    "belogs to people"
  end

  Government.prepend self
end


puts Government.new.metaclass.superclass_chain.inspect
# => [#<PrependedModule People>, Government, Object, #<IncludedModule
Kernel>]      <----- looks good, but...
puts Government.new.power
# => belongs to government              <---- ...is this right? ;)



So, I actually have two questions:
1) Is it a bug?
2) If it has been done intentionally, then  is there better way
manipulate superclass chain?

Thanks,
Daniel Vartanov.

Re: Rubinius Contribute to Open Source Session at upcoming Red Dirt RubyConf

ThirtySixthSpan — 2011-03-28T18:54:33

RDRCRRE - Red Dirt RubyConf Regular Registration Ending

Regular registration deadline for Red Dirt RubyConf
is this Friday, April 1st.
http://reddirtrubyconf.com/program

Red Dirt has one of the best conference lineups that you will
see at any Ruby conference. Our speakers are world-class
contributors in the Ruby and Javascript communities working
for leaders in the industry including Obtiva, Intridea, AT&T
Interactive, Hewlett Packard, Heroku, ThoughtBot, and
Engine Yard.

Red Dirt is a content rich two-day conference to be held in
Oklahoma City on April 21st and 22nd, 2011.
http://reddirtrubyconf.com/schedule

Can't make it?
Join the live video stream or order the conference videos!
http://reddirtrubyconf.com/program


On Feb 18, 3:34 pm, ThirtySixthSpan <derrick.parkhu...< at >gmail.com>
wrote:

Kernel#gsub not working properly with a block

Josep M. Bach — 2011-03-20T18:22:21

Hi there!

The following spec does not pass on rbx (in 
spec/ruby/core/kernel/gsub_spec.rb#78):

  describe "Kernel#gsub with pattern and block" do
    it "acts similarly to using $_.gsub" do
      $_ = "olleh dlrow"
      gsub(/(\w+)/){ $1.reverse }
      $_.should == "hello world"
    end
  end

Trying to fix this one, I found that there is a comparison of replacement 
(in this case it is nil, because gsub is passed a block instead of a 
replacement string) with undefined, which always evaluates to false (even if 
it is nil). Since I don't know really well what `undefined` is, I've first 
tried comparing replacement to nil, which seems to work (in 
kernel/common/string.rb#902):

  def gsub(pattern, replacement=undefined)
    # ...
    if replacement.nil? # was if replacement == undefined 

Now the problem is that, when evaling the block { $1.reverse }, $1 is nil. 
Upon further inspection, This happens just before evaling the block, where 
Regexp's last match is (unsuccessfully) set to the intended match data (same 
file, #939):

      if use_yield
        # Although `match` contains actual match data,
        Regexp.last_match = match
        # Here Regexp.last_match is nil.
        
        # So this block evaluation will fail when trying to do nil.reverse
        val = yield(match.to_s)

I've tried it in the rbx console, so it seems Regexp.last_match=(matchdata) 
(although it returns the passed matchdata) does nothing to Regexp.last_match 
(it keeps previous matched data, or nil if it was nil).

I've checked the regexp.cpp file but I'm no expert there, so I can't tell 
what's wrong....

Any thoughts?