Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rubinius 1.0 (Fabius) Released

rubini.us

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Rubinius 1.0 (Fabius) Released

#41

Post by daveungerer »

evanphx wrote: post #32
daveungerer wrote: post #31

Earlier quoted context omitted.

Actually, his take on it isn't quite accurate. It's not "written in C++". From http://rubini.us : Wherever possible Rubinius is written in Ruby. Where not possible (yet), it's C++. And further down: The Rubinius bytecode virtual machine is written in C++, incorporating LLVM to compile bytecode to machine code at runtime. The bytecode compiler and vast majority of the core classes are written in pure Ruby. So, it's th…

Well, not exactly. The interpreter is in C++. By bytecode compiler he means the code that translates from a ruby AST into bytecode, which is in ruby.

Sure, but the point I'm trying to make is that Wayne Seguin was using the word "interpreter" colloquially to refer to the whole program, in effect saying that the whole code base is C++.

Re: Rubinius 1.0 (Fabius) Released

#42

Post by riffraff »

GrandMasterBirt wrote: post #37
jemfinch wrote: post #26

Earlier quoted context omitted.

You mean the same Google where Python beat Ruby years ago?

Can't blame them, even a year or two ago Ruby and RoR were much inferior to today. And wait till RoR3 hits the shelves full steam. Granted I hope ActiveRecord3 will include everything by default like DataMapper does but whatever... Ruby is still in infancy stages, Python is quite old. Hell Python was the inspiration for Ruby. I mean look at what is happening in the Javascript space. If Ruby and JRuby implementations…

appengine runs jruby, that is good enough :)

Re: Rubinius 1.0 (Fabius) Released

#43

Post by acangiano »

sandGorgon wrote: post #24
ezmobius wrote: post #20

This is my favorite project we have at Engine Yard. I've been rooting for it and fighting to keep it alive for years now because I know that this is the future of ruby. Evan and Brian and all the contributors have done great work on this ambitious project. I've had ruby aliased to rbx on my own personal laptop and run all of my development on rbx, I only have to bust out MRI every once in a while, like once a month.…

what is the performance as compared to Enterprise Edition ?

I'll publish my shootout soon, and it will include Rubinius 1.0.

Re: Rubinius 1.0 (Fabius) Released

#45

Post by crazydiamond »

jamesbritt wrote: post #39
steveklabnik wrote: post #38

Earlier quoted context omitted.

> Granted I hope ActiveRecord3 will include everything by default like DataMapper does but whatever... I'm not sure exactly what you mean by this, but Rails 3 will still be a full stack framework. Something will be chosen for everything by default. You'll be able to fully switch out ActiveRecord for DataMapper if you wish. > Hell Python was the inspiration for Ruby. I've never seen this before, usually I've heard Mat…

Matz has cited a number of inspirations, including Perl, Python, Lisp, Smalltalk, Self (I think), and CLU. He's also referred to Ruby as "Matz Lisp."

> He's also referred to Ruby as "Matz Lisp."

So when does the "enlightenment experience" Eric Raymond promised come ? Or did Matz take it all :-D

Re: Rubinius 1.0 (Fabius) Released

#46

Post by jshen »

sandGorgon wrote: post #24
ezmobius wrote: post #20

This is my favorite project we have at Engine Yard. I've been rooting for it and fighting to keep it alive for years now because I know that this is the future of ruby. Evan and Brian and all the contributors have done great work on this ambitious project. I've had ruby aliased to rbx on my own personal laptop and run all of my development on rbx, I only have to bust out MRI every once in a while, like once a month.…

what is the performance as compared to Enterprise Edition ?

I ran a benchmark on a library i'm working on (fuzzy auto complete), and rubinius was the fastest (I didn't test 1.9).

The code is pure ruby, it creates a decent sized trie then walks it once to set data in each node (a sequential forward index, etc).

I'll release the code once my library is ready for public consumption, but the numbers were (in seconds):

rubinius ~ 4.85

jruby 1.5 ~ 5.45

mri 1.8.7 ~ 9.35

ree 1.8.7 ~ 9.35

and Yes, I did a warm up.

Re: Rubinius 1.0 (Fabius) Released

#47

Post by Freaky »

anin_teger wrote: post #44

I'm just starting to get into Ruby but I'm pretty confused about this project. It sounds really cool, but doesn't Ruby 1.9 already have a GC and compiles into byte code? Maybe 1.9 doesn't have a JIT but couldn't they add it?

Ruby has had a GC since the start; it's a conservative stop-the-world all-or-nothing non-compacting mark-and-sweep garbage collector. Meaning:

1. It can't tell the difference between a number on the heap that happens to look like a reference to some active data, and an actual reference to some active data. Hence it has to be conservative, and assume anything that looks like a reference, is one. Rubinius has a precise GC, and so doesn't suffer from this problem, which can lead to dead objects never being collected.

2. The GC has to stop the VM while it's running. This is probably also the case with Rubinius, however:

3. It has to walk over every object in the VM in one go, so it gets progressively slower the more objects you have. Rubinius has a generational GC, where objects are split into pools based on how long they've been alive for, and these can be scanned individually and at different rates appropriate to their age (i.e. long-lived objects probably aren't worth checking very often).

4. It can't move objects around; when it frees something, it leaves a gap where the object used to be. If a new object doesn't fit there, it has to go somewhere else, wasting that space. In the long run this can lead to memory fragmentation. Rubinius has a compacting GC, allowing it to fill in these holes and make better use of memory, and also better use of CPU caches.

Yes, 1.9 compiles to bytecode, and yes in theory a JIT could be added to it, but that's a pretty big project.

Re: Rubinius 1.0 (Fabius) Released

#48

Post by jemfinch »

GrandMasterBirt wrote: post #37
jemfinch wrote: post #26

Earlier quoted context omitted.

You mean the same Google where Python beat Ruby years ago?

Can't blame them, even a year or two ago Ruby and RoR were much inferior to today. And wait till RoR3 hits the shelves full steam. Granted I hope ActiveRecord3 will include everything by default like DataMapper does but whatever... Ruby is still in infancy stages, Python is quite old. Hell Python was the inspiration for Ruby. I mean look at what is happening in the Javascript space. If Ruby and JRuby implementations…

Python was released in 1991; Ruby was released in 1995. If Ruby is significantly lagging behind Python at this point, it seems unlikely to make up the difference in the future.

Re: Rubinius 1.0 (Fabius) Released

#49

Post by headius »

jshen wrote: post #46
sandGorgon wrote: post #24

Earlier quoted context omitted.

what is the performance as compared to Enterprise Edition ?

I ran a benchmark on a library i'm working on (fuzzy auto complete), and rubinius was the fastest (I didn't test 1.9). The code is pure ruby, it creates a decent sized trie then walks it once to set data in each node (a sequential forward index, etc). I'll release the code once my library is ready for public consumption, but the numbers were (in seconds): rubinius ~ 4.85 jruby 1.5 ~ 5.45 mri 1.8.7 ~ 9.35 ree 1.8.7 ~…

I'd love to see your benchmark to understand why JRuby wasn't faster than that. I assume you ran with the --server flag to JRuby as well.

Re: Rubinius 1.0 (Fabius) Released

#50

Post by headius »

evanphx wrote: post #6
sreque wrote: post #5

Earlier quoted context omitted.

I just did a quick test of 1.9 vs rubinius on the alioth pidigits and btrees benchmarks, and rubinius was 1.5 times as slow on pidigits and twice as slow on btrees. In addition, the release notes state that they are aware that several string operations in Rubinius are currently slower than their MRI 1.8 equivalents. I'm excited that rubinius is out, but I'm not sure at the moment what it's advantages are versus MRI i…

This seems pretty accurate given the kind of performance we've seen thus far. One thing to understand about Rubinius is that we've optimized it to the hilt for running Ruby code. So when you see Rubinius performing, say, 1.5x slower than MRI on a particular String method, what you're seeing is Rubinius running ruby at 1.5x slower than C code. If you compare Rubinius to MRI both running pure ruby code, you'll see Rubi…

Aren't String and Array a mix of both C++ and Ruby, though? So it's a bit more like saying it's running that mix of C++ and Ruby 1.5x slower than MRI runs C, for varying percentages of Ruby and C++.

Still awesome though!

Post reply on HN