Struggling with Rubinius
November 17th, 2010 6:09:03 pm pst by Sterling CamdenI decided to follow Chad’s advice and take Rubinius for a spin. Everything worked great until I tried running some of my more complicated scripts, each of which experienced failures on a ‘require’ statement.
After narrowing down which require statements were working and which were not, I realized I had two classes of failures: (1) my own modules that I had placed in the require path, and (2) gems. Built-in modules (like optparse) were OK. Sure enough, the command:
rbx -e 'puts $:'
revealed that the require path for rubinius is completely separate from that of MRI (Matz’s Reference Implementation). So, I copied my modules into the /usr/local/lib/ruby/site_ruby/rubinius directory, but that didn’t help. I also had to rbx -c each of them, to produce the corresponding .rbc file. UPDATE 2010-11-18: This was probably a red herring, caused by something else I fixed later (maybe the missing gems). See comment thread below.
That fixed my modules, but gems still wouldn’t load. The require for ‘rubygems’ itself was OK, however. So I figured there must be something different about installing gems for Rubinius. After a bit of googling, I found a comment posted by someone named “?”, who said in part:
In case you haven’t tried Rubinius yet, let me save you a bit of googling and tell you that to install gems you just write: “rbx gem install …”
Bingo. I proceeded to rbx gem install each of the gems that I use. But when I attempted sqlite3, I got:
ERROR: Error installing sqlite3:
sqlite3 requires Ruby version >= 1.9.1.
shell returned 1
Tartar sauce! Rubinius isn’t available for 1.9 yet, though they say it’s “coming soon”. Yeah, that’s what she said, too. I guess I’ll have to just keep plugging along with MRI for now. The one script for which I really hoped to get a performance boost from Rubinius is my spam filter, isspam, but I don’t feel like rewriting its database interface.
UPDATE 2010-11-18: Evan Phoenix provided the solution in the comments below: I was using the wrong gem! Should have been sqlite3-ruby instead of sqlite3 (odd that both exist). Thanks again, Evan!
Posted in Ruby | 15 Comments » RSS 2.0
Subscribe by Email
“Tartar sauce!”
Ah, someone’s been watching SpongeBob with their kids…
“Rubinius isn’t available for 1.9 yet, though they say it’s “coming soon”.”
I’ve talked to the Rubinius folks on a number of occasions, and I am *extremely* impressed with their commitment to the project and their dedication to quality. They too told me that 1.9 compat was on its way when I spoke to them a month or two ago, and based on their track history, I believe them.
J.Ja
Yes, my youngest is on a SpongeBob binge right now.
I’m glad to hear your hopeful opinion about Rubinius support for Ruby 1.9. I think the project hold a lot of promise for Ruby developers who need to get over the MRI performance hump.
Hi guys,
I have no clue what the sqlite3 gem is, but the one everyone uses is sqlite3-ruby. Try that instead, I know sqlite3-ruby works fine under Rubinius.
– Evan
Ah, that sorted it! When I installed the gem for MRI, I used the FreeBSD port. Since one requires “sqlite3″ I assumed that was the gem name. It’s weird that there is also a gem of that name that requires 1.9.
Thanks!
Also, when you copied stuff into /usr/local/lib/ruby/site_ruby/rubinius, you said it didn’t help. What happened exactly? Did you double check that /usr/local/lib/ruby/site_ruby/rubinius is in $LOAD_PATH?
It didn’t help, until I compiled the modules directly using rbx -c. Apparently, it needed the .rbc files to already exist.
BTW, I’m using rubinius 1.1.0 from the FreeBSD port.
But what exactly did it do? Did rubinius not see the files? Did it raise an exception? The .rbc files are automatically generated, and rbx -c doesn’t generate .rbc files, it just syntax checks them.
It threw a loader exception. There was no .rbc file until after I ran rbx -c, and then there was one. And then it worked.
Hm. Could you please show me the exception? This is important because I’d like to get this fixed ASAP!
OK, I’m going crazy. I tried to reproduce the issue, and now I can’t. Perhaps the only real problem was the missing gems. Thanks for giving me such prompt attention, and sorry for the noise.
In my initial benchmarks, I’m getting rubinius about twice as slow as MRI 1.8.7 on lengthy tasks (it’s probably not fair to compare short tasks because of rubinius’ startup time). I ran the same tests multiple times in order to avoid biasing one or the other with caching. What else could account for this?
Is the benchmarking code available for me to see? You can use ‘rbx -Xprofile ‘ to get profiling information about what is going on to help.
Sure, you can download the sources from http://bitbucket.org/sterlingcamden/isspam
Prime the database by supplying two large text files (like mbox mail files) to the following commands:
isspam -y large_file_1 # this is spam
isspam -n large_file_2 # this one isn’t
Then take a third large file (or one of the first two) and use the following command:
isspam -p large_file_3 # compute spam probabilities
Run that last command several times each with both ruby and rbx.
I did the -Xprofile, and the vast majority of time was spent in 2 calls to Array#qsort_block!
FYI: I just replaced the sort and slice code with an inject that speeds up Rubinius by about 25%, and helps MRI just a shade. But Rubinius is still about 50% slower than MRI.
[...] Struggling with Rubinius — Chip’s Tips for DevelopersGot me in a database headlock.Tags: chipstips ruby rubinius Tags: chipstips, consulting, del.icio.us, email, filtering, rubinius, ruby, spam, techrepublic [...]