Re: Ruby Inline over two times slower under 1.9 than under 1.8?
Ryan Davis
On Nov 3, 2009, at 04:46 , Shot (Piotr Szotkowski) wrote:
> I’m starting to dip my toes in non-Ruby coding (for performance
> reasons)
> and began with looking at the (simplest) choice of Ruby Inline.
>
> Interestingly, while my own number-crunching code seems to be
> generally
> three times faster in Ruby 1.9 than in Ruby 1.8, the attached script
> – a slightly altered Corey Hoffstein’s example¹ – seems to be actually
> running its Ruby part slightly slower under Ruby 1.9, and over two
> times
> slower when it comes to its C part:
I'm not seeing that in a simpler case (factorial in example.rb from
RubyInline). So maybe it is less method dispatch time and more ruby
internals manipulation time?
505 % multiruby example.rb
VERSION = 1.8.6-p368
CMD = ~/.multiruby/install/1.8.6-p368/bin/ruby example.rb
# of iterations = 1000000, n = 5
user system total real
null_time 0.110000 0.000000 0.110000 ( 0.111362)
c 0.780000 0.010000 0.790000 ( 0.798776)
c-raw 0.820000 0.000000 0.820000 ( 0.824597)
c-alias 0.810000 0.000000 0.810000 ( 0.826391)
pure ruby 3.120000 0.000000 3.120000 ( 3.121989)
RESULT = 0
VERSION = 1.8.7-p72
CMD = ~/.multiruby/install/1.8.7-p72/bin/ruby example.rb
# of iterations = 1000000, n = 5
user system total real
null_time 0.140000 0.000000 0.140000 ( 0.141250)
c 0.890000 0.000000 0.890000 ( 0.897377)
c-raw 0.950000 0.010000 0.960000 ( 0.975901)
c-alias 0.990000 0.000000 0.990000 ( 1.033289)
pure ruby 3.260000 0.020000 3.280000 ( 3.331565)
RESULT = 0
VERSION = 1.8.7-p160
CMD = ~/.multiruby/install/1.8.7-p160/bin/ruby example.rb
# of iterations = 1000000, n = 5
user system total real
null_time 0.120000 0.000000 0.120000 ( 0.119509)
c 0.870000 0.000000 0.870000 ( 0.881604)
c-raw 0.870000 0.000000 0.870000 ( 0.876080)
c-alias 0.900000 0.010000 0.910000 ( 0.921587)
pure ruby 3.330000 0.010000 3.340000 ( 3.357289)
RESULT = 0
VERSION = 1.8.7-p174
CMD = ~/.multiruby/install/1.8.7-p174/bin/ruby example.rb
# of iterations = 1000000, n = 5
user system total real
null_time 0.120000 0.000000 0.120000 ( 0.125070)
c 0.950000 0.000000 0.950000 ( 0.959735)
c-raw 0.860000 0.000000 0.860000 ( 0.868117)
c-alias 0.990000 0.010000 1.000000 ( 1.004241)
pure ruby 3.550000 0.010000 3.560000 ( 3.589039)
RESULT = 0
VERSION = 1.9.1-p129
CMD = ~/.multiruby/install/1.9.1-p129/bin/ruby example.rb
# of iterations = 1000000, n = 5
user system total real
null_time 0.150000 0.000000 0.150000 ( 0.148261)
c 0.350000 0.010000 0.360000 ( 0.365500)
c-raw 0.350000 0.000000 0.350000 ( 0.356689)
c-alias 0.350000 0.000000 0.350000 ( 0.352744)
pure ruby 1.090000 0.010000 1.100000 ( 1.133433)
RESULT = 0
TOTAL RESULT = 0 failures out of 5
Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368, 1.8.7-p174
Failed:
Roger Pack
Shameless plug: Also checkout http://github.com/rdp/crystalizer
:)
-r
--
Posted via http://www.ruby-forum.com/.
Roger Pack
> Roger Pack:
>
>>> — Shot, who’s off to play with RubyToC now. :)
>
> from http://zenspider.com/ZSS/Products/RubyInline/ to work.
here's a working example (well worked once upon a time).
http://betterlogic.com/roger/?p=1849
The disadvantage to ruby2c seems to be that it only works for methods
that "appear" to take floats and int [?]
> Checked it and it does seem to work under my hand-compiled
> 1.8.7-p202+r22308, but an attempt to install it under
> 1.9.1-p243+r22308 first ended in it trying to look for
Wow you're the first to ever even try it out besides myself. Yeah not
1.9 compat yet [sorry].
Caleb Clausen
> Wow you're the first to ever even try it out besides myself. Yeah not
> 1.9 compat yet [sorry].
Yet? Are you planning to release a 1.9-compatible version of
crystalizer? I had thought it was hopeless, since you're dependant on
2 libraries which won't ever be ported to 1.9...
Roger Pack
> crystalizer? I had thought it was hopeless, since you're dependant on
> 2 libraries which won't ever be ported to 1.9...
It's actually pretty high on the "to do" list, though who knows if I'll
ever get there.
I'll probably just use #source_location to extract the source and call
out to 1.8.6 to return me its ruby node (and cache the result, thus
fewer call outs necessary over time).
The hard part is actually getting the C code to compile in 1.9--that
could take awhile and is unfamiliar territory.
Roger Pack
> (checking gem RubyToC-1.0.0.5 for ruby_to_ruby_c)
> /home/shot/opt/ruby-1.8.7-svn/lib/ruby/gems/1.8/gems/RubyToC-1.0.0.5/lib/ruby_to_ruby_c.rb
>
> Fortunately, I noticed the 1.0.0.5 version not
> matching 1.0.0.7 in the example and cd-ed to
> /home/shot/opt/ruby-1.8.7-svn/lib/ruby/gems/1.8/gems/ruby2c-1.0.0.7
> instead. Still, with RubyToC being higher on the gem searchpath (?):
>
>>> RubyParser.new.parse(File.read 'hello.rb')
> NoMethodError: undefined method `clear' for nil:NilClass
Hmm. Maybe a bug in ruby parser?
> After uninstalling RubyToC (and, I assume, ruby_parser falling back
> to ruby2c) the above blog example works, both in 1.8.7-p202+r22308
> and 1.9.1-p243+r22308. Is there a ‘conflicts’ flag for gems, so that
> ruby_parser can specify that it (as far as I understand) works with
> ruby2c 1.0.0.7 but not with RubyToC 1.0.0.5?
So RubyToC 1.0.0.5 only works with an older version of ruby_parser, is
that right?
Charles Oliver Nutter
> I haven’t yet checked this, but I’ll check and report once/if I end
> up going down this road. After experimenting a bit with all these
> nice automagic approaches I think I’ll end up with either a good old
> D extension or hand-coded inline C, as I’d really prefer something that
> ‘just works’ in 1.9 MRI (and JRuby is not there yet with 1.9 support,
> unfortunately – although I’ll give it one more chance). :)
We've never said that 1.9 support is done, largely because it's hard
to say what "done" actually means with 1.9.2 adding and changing many
things. But if there's specific problems, please report them...we're
actively trying to improve it.
- Charlie