[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[ANN] Rubinius interview with Evan Phoenix

pat eyler

12/7/2006 8:07:00 PM

With all the recent buzz around rubinius, it was serendipitous that
Evan and I had nearly finished an interview. We wrapped it up over
lunch, and it's posted at:

http://on-ruby.bl.../2006/12/rubinius-inte...


Happy reading.

--
thanks,
-pate
-------------------------
http://on-ruby.bl...
8 Answers

Jörg W Mittag

12/8/2006 3:59:00 AM

0

pat eyler wrote:
> With all the recent buzz around rubinius, it was serendipitous that
> Evan and I had nearly finished an interview. We wrapped it up over
> lunch, and it's posted at:
>
> http://on-ruby.blogspot.com/2006/12/rubinius-inte...
>
> Happy reading.

From the interview:

| Q: What facets of the other alternative Ruby implementations do you
| envy?
|
| A: I envy the jruby developers for not having to debug segfaults,
| thats a biggy.

Then why use C? Why not translate to, say, Eiffel, OCaml, Oberon,
Java, C#? People have written operating system kernels in most of
those (Oberon, Java, C#; not sure about Eiffel, OCaml), surely one
could write a language kernel?

Just wondering ...

Probably the answer is "I can write C but not Eiffel" (-;

jwm

Wilson Bilkovich

12/8/2006 4:22:00 AM

0

On 12/7/06, Jörg W Mittag <Joerg.Mittag@web.de> wrote:
> pat eyler wrote:
> > With all the recent buzz around rubinius, it was serendipitous that
> > Evan and I had nearly finished an interview. We wrapped it up over
> > lunch, and it's posted at:
> >
> > http://on-ruby.blogspot.com/2006/12/rubinius-inte...
> >
> > Happy reading.
>
> From the interview:
>
> | Q: What facets of the other alternative Ruby implementations do you
> | envy?
> |
> | A: I envy the jruby developers for not having to debug segfaults,
> | thats a biggy.
>
> Then why use C? Why not translate to, say, Eiffel, OCaml, Oberon,
> Java, C#? People have written operating system kernels in most of
> those (Oberon, Java, C#; not sure about Eiffel, OCaml), surely one
> could write a language kernel?
>
> Just wondering ...
>
> Probably the answer is "I can write C but not Eiffel" (-;
>

At the risk of putting words in Evan's mouth, one of Rubinius's goals
is to make the core of Ruby's runtime accessible to a much, much wider
group of people what we've got currently.

Using something less common than C would work against that, even
though personally I'm a big OCaml fan. Rubinius wants to be
mainstream, and the wide availability of C knowledge and C compilers
will assist in that.

Sam Smoot

12/8/2006 2:47:00 PM

0

Since we're kinda on the topic of implementation I've got a question:

Avi Bryant's article in response to JoelOnSoftware said you could get
method calls down to a jump and compare.

My impression is that MRI basically uses hashtables for method lookup.

Is it in the cards for Rubinius to receive the sort of optimizations
Avi was talking about? Is it reasonable to expect that an optimized
version of Rubinius could get method calls into the same performance
realm as c# or Java?

This way I suppose C-Extensions would be used more as bridges to
leverage existing libraries, and not for performance reasons.

Any thoughts?

Wilson Bilkovich

12/8/2006 4:24:00 PM

0

On 12/8/06, Sam Smoot <ssmoot@gmail.com> wrote:
> Since we're kinda on the topic of implementation I've got a question:
>
> Avi Bryant's article in response to JoelOnSoftware said you could get
> method calls down to a jump and compare.
>
> My impression is that MRI basically uses hashtables for method lookup.
>
> Is it in the cards for Rubinius to receive the sort of optimizations
> Avi was talking about? Is it reasonable to expect that an optimized
> version of Rubinius could get method calls into the same performance
> realm as c# or Java?
>
> This way I suppose C-Extensions would be used more as bridges to
> leverage existing libraries, and not for performance reasons.
>

Yes. One way to do this is to make the common case as fast as
possible, even if that assumption 'breaks' some of the dynamic
features of Ruby. At runtime, you then detect when you've violated
that assumption, trap the error, and re-evaluate the code in a slower
mode.

If you pick targets for that that don't trap very often, you can
supposedly gain back quite a lot of speed. I believe the JVM has
something like this for dynamic invocations, but I haven't looked at
that code, so I might be making a fool out of myself by saying it.

Rob Sanheim

12/8/2006 5:28:00 PM

0

On 12/7/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:
> On 12/7/06, Jörg W Mittag <Joerg.Mittag@web.de> wrote:
> > pat eyler wrote:
> > > With all the recent buzz around rubinius, it was serendipitous that
> > > Evan and I had nearly finished an interview. We wrapped it up over
> > > lunch, and it's posted at:
> > >
> > > http://on-ruby.blogspot.com/2006/12/rubinius-inte...
> > >
> > > Happy reading.
> >
> > From the interview:
> >
> > | Q: What facets of the other alternative Ruby implementations do you
> > | envy?
> > |
> > | A: I envy the jruby developers for not having to debug segfaults,
> > | thats a biggy.
> >
> > Then why use C? Why not translate to, say, Eiffel, OCaml, Oberon,
> > Java, C#? People have written operating system kernels in most of
> > those (Oberon, Java, C#; not sure about Eiffel, OCaml), surely one
> > could write a language kernel?
> >
> > Just wondering ...
> >
> > Probably the answer is "I can write C but not Eiffel" (-;
> >
>
> At the risk of putting words in Evan's mouth, one of Rubinius's goals
> is to make the core of Ruby's runtime accessible to a much, much wider
> group of people what we've got currently.
>
> Using something less common than C would work against that, even
> though personally I'm a big OCaml fan. Rubinius wants to be
> mainstream, and the wide availability of C knowledge and C compilers
> will assist in that.

Arguably, I think Java is more accessible then c, especially as Ruby
gains a wider audience.

- Rob

Wilson Bilkovich

12/8/2006 6:44:00 PM

0

On 12/8/06, Rob Sanheim <rsanheim@gmail.com> wrote:
> On 12/7/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:
> > On 12/7/06, Jörg W Mittag <Joerg.Mittag@web.de> wrote:
> > > pat eyler wrote:
> > > > With all the recent buzz around rubinius, it was serendipitous that
> > > > Evan and I had nearly finished an interview. We wrapped it up over
> > > > lunch, and it's posted at:
> > > >
> > > > http://on-ruby.blogspot.com/2006/12/rubinius-inte...
> > > >
> > > > Happy reading.
> > >
> > > From the interview:
> > >
> > > | Q: What facets of the other alternative Ruby implementations do you
> > > | envy?
> > > |
> > > | A: I envy the jruby developers for not having to debug segfaults,
> > > | thats a biggy.
> > >
> > > Then why use C? Why not translate to, say, Eiffel, OCaml, Oberon,
> > > Java, C#? People have written operating system kernels in most of
> > > those (Oberon, Java, C#; not sure about Eiffel, OCaml), surely one
> > > could write a language kernel?
> > >
> > > Just wondering ...
> > >
> > > Probably the answer is "I can write C but not Eiffel" (-;
> > >
> >
> > At the risk of putting words in Evan's mouth, one of Rubinius's goals
> > is to make the core of Ruby's runtime accessible to a much, much wider
> > group of people what we've got currently.
> >
> > Using something less common than C would work against that, even
> > though personally I'm a big OCaml fan. Rubinius wants to be
> > mainstream, and the wide availability of C knowledge and C compilers
> > will assist in that.
>
> Arguably, I think Java is more accessible then c, especially as Ruby
> gains a wider audience.

Startup time for small scripts is a core requirement for Ruby, and
that's a problem for the JVM. JRuby is targeting long-running
processes for that reason.
Also, there's a pretty bad impedance mismatch between the Java opcodes
and what Ruby needs. The JRuby team is working around that by being
really smart and dedicated, but it's not easy.

If you combine the stats for C and C++, it is still the most
widely-used language on Earth. Also, I never want to program in Java
again, if I can avoid it. Heh.

We're doing Rubinius to make ourselves happier, along with all the other goals.

Rob Sanheim

12/8/2006 9:17:00 PM

0

On 12/8/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:
> Startup time for small scripts is a core requirement for Ruby, and
> that's a problem for the JVM. JRuby is targeting long-running
> processes for that reason.
> Also, there's a pretty bad impedance mismatch between the Java opcodes
> and what Ruby needs. The JRuby team is working around that by being
> really smart and dedicated, but it's not easy.

Agreed, I didn't say there weren't good implementation reasons that
you don't want to use java.

> If you combine the stats for C and C++, it is still the most
> widely-used language on Earth. Also, I never want to program in Java
> again, if I can avoid it. Heh.

Hm, well obviously I prefer Ruby over Java, but I think I'd take Java
over c or c++ any day if all else is equal. I'll take NPE's and
Intellij IDEA over dangling pointers and buffer overruns. :)

That said, I'm rooting for rubinius. I saw Evan's presentation at
rubyconf and I really hope he can rally other core hackers around the
"simpler is better" rallying cry.

- Rob

Aria Stewart

12/9/2006 12:14:00 AM

0

On Sat, 2006-12-09 at 06:17 +0900, Rob Sanheim wrote:
> On 12/8/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:
> > Startup time for small scripts is a core requirement for Ruby, and
> > that's a problem for the JVM. JRuby is targeting long-running
> > processes for that reason.
> > Also, there's a pretty bad impedance mismatch between the Java opcodes
> > and what Ruby needs. The JRuby team is working around that by being
> > really smart and dedicated, but it's not easy.
>
> Agreed, I didn't say there weren't good implementation reasons that
> you don't want to use java.
>
> > If you combine the stats for C and C++, it is still the most
> > widely-used language on Earth. Also, I never want to program in Java
> > again, if I can avoid it. Heh.
>
> Hm, well obviously I prefer Ruby over Java, but I think I'd take Java
> over c or c++ any day if all else is equal. I'll take NPE's and
> Intellij IDEA over dangling pointers and buffer overruns. :)

Until Java was opened, I'd definitely have chosen C above Java any day.
(and in general, still do.)

Definitely a bit more optimistic for Java than I used to be though.

> That said, I'm rooting for rubinius. I saw Evan's presentation at
> rubyconf and I really hope he can rally other core hackers around the
> "simpler is better" rallying cry.
>
> - Rob
>
>