Forum: Ruby Ruby 1.9.1-p0, llvm: all tests pass!

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
58a62321e4961bb65cc202bfd9cc963a?d=identicon&s=25 Ollivier Robert (keltia)
on 2009-03-30 00:11
One pet peeves of mine regarding 1.9 seems to have very recently been
squashed by progress on llvm/clang front.  Using r68016 of llvm/clang
(pre-2.6), I managed to configure, make and make test of 1.9.1-p0 on my
FreeBSD 7.1 box.

Before, miniruby was looping his heart out ad nauseam and has to be
killed by -KILL...

Now, to get an updated macports version of llvm to have the same on my
OS X machine...

PS: for the interested parties, miniruby was looping here:

-----
1238363465.749200 },0x0)           = 0 (0x0)
clock_gettime(0,{1238363465.749314966 })         = 0 (0x0)
_umtx_op(0x80f96ae0,0x8,0x1,0x80f96ac0,0x7fffffbfe6f0,0x7fffffbfe698) =
0 (0x0)
sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
2165309440 (0x81100000)
gettimeofday({1238363465.760127 },0x0)           = 0 (0x0)
clock_gettime(0,{1238363465.760237273 })         = 0 (0x0)
_umtx_op(0x80f96ae0,0x8,0x1,0x80f96ac0,0x7fffffbfe6f0,0x7fffffbfe698)
ERR#60 'Operation timed out'
gettimeofday({1238363465.771172 },0x0)           = 0 (0x0)
clock_gettime(0,{1238363465.771637002 })         = 0 (0x0)
_umtx_op(0x80f96ae0,0x8,0x1,0x80f96ac0,0x7fffffbfe6f0,0x7fffffbfe698)
ERR#60 'Operation timed out'
-----
58a62321e4961bb65cc202bfd9cc963a?d=identicon&s=25 Ollivier Robert (keltia)
on 2009-03-30 00:36
Ollivier Robert wrote:
> One pet peeves of mine regarding 1.9 seems to have very recently been
> squashed by progress on llvm/clang front.  Using r68016 of llvm/clang
> (pre-2.6), I managed to configure, make and make test of 1.9.1-p0 on my
> FreeBSD 7.1 box.

Apparently, it compiles, runs tests but "require" of gems is broken, so
much for tests...

1718 [0:33] roberto@keltia:Src/old-crypto> irb19
irb(main):001:0> require "hoe"
LoadError: no such file to load -- hoe
        from (irb):1:in `require'
        from (irb):1
        from /usr/local/bin/irb19:12:in `<main>'

/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0
/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0/History.txt
/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0/Manifest.txt
/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0/README.txt
/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0/Rakefile
/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0/bin
/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0/bin/sow
/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0/lib
/local/local/lib/ruby/gems/1.9/gems/hoe-1.11.0/lib/hoe.rb
...

1719 [0:35] roberto@keltia:Src/old-crypto> gem19 list

*** LOCAL GEMS ***

daemons (1.0.10)
eventmachine (0.12.6)
hoe (1.11.0)
nokogiri (1.2.3)
rack (0.9.1)
rake (0.8.4)
rmagick (2.9.1)
rubyforge (1.0.3)
thin (1.0.0)
8a85c693f13ef7cb542ef94d2a403d4d?d=identicon&s=25 Luc Heinrich (Guest)
on 2009-03-30 09:41
(Received via mailing list)
On 30 mars 09, at 00:11, Ollivier Robert wrote:

> One pet peeves of mine regarding 1.9 seems to have very recently been
> squashed by progress on llvm/clang front.  Using r68016 of llvm/clang
> (pre-2.6), I managed to configure, make and make test of 1.9.1-p0 on
> my
> FreeBSD 7.1 box.

Version 0.5 of MacRuby apparently uses LLVM already: "This future
version of MacRuby is freakishly fast and uses the LLVM to generate
code for the Objective-C runtime."

<http://antoniocangiano.com/2009/03/29/why-macruby-...

I tried the latest from Subversion and it has rubygems issues as well,
but only because the runtimes are different which seems to confuse
RubyGems.
Ba91caa4b1fd66471e4180151b379dd7?d=identicon&s=25 Jörg W Mittag (Guest)
on 2009-03-30 22:10
(Received via mailing list)
Luc Heinrich wrote:
> On 30 mars 09, at 00:11, Ollivier Robert wrote:
>> One pet peeves of mine regarding 1.9 seems to have very recently been
>> squashed by progress on llvm/clang front.  Using r68016 of llvm/clang
>> (pre-2.6), I managed to configure, make and make test of 1.9.1-p0 on
>> my FreeBSD 7.1 box.
> Version 0.5 of MacRuby apparently uses LLVM already:

That's not what this is about. Ollivier's post is about compiling the
C source code of YARV with the CLang/LLVM C compiler instead of the
GNU C compiler. MacRuby 0.5 is about compiling Ruby source code to
LLVM bitcode.

> "This future
> version of MacRuby is freakishly fast and uses the LLVM to generate
> code for the Objective-C runtime."
>
> <http://antoniocangiano.com/2009/03/29/why-macruby-...

This article is rather an example of why premature benchmarking
doesn't matter.

We have seen several times now, that Ruby implementations tend to get
orders of magnitude slower, as they become more and more Ruby
compliant. Early benchmarks of YARV showed speedups of 3x, 5x, 8x,
even up to 50x and more over MRI. According to a recent presentation
by matz, the actual speedup for real applications instead of
microbenchmarks and a real version of YARV instead of an early
prototype is more like 1.5x.

The same happened with MagLev: in the beginning there was much hype
about how they built a prototype that can run WEBRick in just 6 weeks,
that was up to 110x faster than MRI. In December of last year, they
were much closer to actually passing the RubySpec suite. They also
went from 100x faster to about the same speed as MRI.

We should well expect that something similar will happen to MacRuby.

I feel compelled to point out that both in the case of YARV and in the
case of MacRuby, those hyper-inflated benchmark numbers were *not*
actually posted by the project developers, but rather by over-excited
fanbois. In fact, if you read the announcement of MacRuby 0.5 by
project lead Laurent Sansonetti, you will find no mention of
performance numbers, and rather a focus on compatibility and RubySpec
compliance. And in the case of YARV, project lead Koichi Sasada has
always made it very clear that the microbenchmarks shipped in the
source distribution are by no means comprehensive or representative
and were specifically written to highlight only those few very
specific areas where YARV has dramatic performance improvements over
other Ruby implementations.

IronRuby project lead John Lam has similarly reported that IronRuby
gets slower, the more Ruby features are supported.

In the article, Antonio Cangiano declares MacRuby to be the fastest
Ruby implementation. But that's simply not true. Yes, MacRuby is
freakishly fast, but it's not a Ruby implementation. Not until it runs
RubySpec, Rails, Merb, RubyGems, RSpec and all the other Ruby code.
When Charles Oliver Nutter tried to benchmark MacRuby against JRuby,
it crashed on half of the benchmarks. That's not freakishly fast,
that's freakishly buggy.

It's pretty easy to make Fixnum#+ run fast, if Fixnum#+ is all you can
run.

Just dropping in LLVM is not magically going to fix all performance
problems. When the phc project (an LLVM-based compiler for PHP) first
fired up their compiler, they discovered that their code ran 10x
slower than the standard PHP interpreter. It took them a year and a
PhD thesis worth of bleeding-edge original research to become faster
than the interpreter. Granted, that was a static AOT compiler, not a
dynamic JIT, but still, it's a cautionary tale.

jwm
8a85c693f13ef7cb542ef94d2a403d4d?d=identicon&s=25 Luc Heinrich (Guest)
on 2009-03-31 08:46
(Received via mailing list)
On 30 mars 09, at 22:10, Jörg W Mittag wrote:

> That's not what this is about. Ollivier's post is about compiling the
> C source code of YARV with the CLang/LLVM C compiler instead of the
> GNU C compiler. MacRuby 0.5 is about compiling Ruby source code to
> LLVM bitcode.

Eh, good point, not the same thing indeed.

> We should well expect that something similar will happen to MacRuby.

Wanna bet ? :)
5a837592409354297424994e8d62f722?d=identicon&s=25 Ryan Davis (Guest)
on 2009-03-31 09:13
(Received via mailing list)
On Mar 30, 2009, at 23:45 , Luc Heinrich wrote:

>> We should well expect that something similar will happen to MacRuby.
>
> Wanna bet ? :)

yes.
This topic is locked and can not be replied to.