Looking at ruby

ruby-talk
1

So I'm looking at ruby for both personal and work projects.

Trying to assess whether it would fit my needs.

I definitely like the language as a whole however, I have questions...

most of them in comparison to perl

Most are library related...

Anyway here goes

1. Can someone point me to benchmarks for ruby vs. other languages, perl
    in particular but others as well would be nice. I found a few using google
    but they all seemed to be from 2001-2002 which makes the numbers
    rather out of date as I expect ruby has improved speed wise since then...

2. mod_ruby vs mod_perl. mod_ruby looks from the surface to be pretty complete...
    are there features implemented in mod_perl that mod_ruby lacks?
    are there any problems or 'gotchas' with mod_ruby?

3. Are there ruby templating engines that are comparable feature-wise to
   perl's Template Toolkit? I looked through raa but didnt really find anything
   that would fit that basic description. In particular the built in caching for
   speed is one area... but the big features here for me are the Plugin
   and Filter interfaces for extending the template system.

4. perl has a Business::Online module that has various sub-module for
    using online payment transaction systems through a unified interface.
    Do similar libraries exist for ruby?

5. Ruby on rails - Active Records. It looks like a really nice system... comparable
    to Class::DBI in a lot of was... question I have is... what kind of performance
    hit does it incur above using DBI. In the perl universe, we decided not
    to use Class::DBI because of said considerations...

6. Marshalling speed... perl has the Storable module which alas is a tad slow...
    how does ruby do in this area?

7. Does ruby on rails work only with a cgi interface or does it work with mod_ruby?

That is my first initial round of questions... I can see a number of ways that
ruby would certainly make our code easier to deal with and understand as it
makes a lot of the design patterns we use a lot easier to implement, understand etc.
And we use a good number of objects in perl which are rather heavy to construct etc.
However, perl does have cpan the breadth and depth of which helps offset some
of these issues.

My big concern would be diving into ruby to save time and ease development in
one area only to have the gains lost in another.

Either way, I'm going to be playing around which ruby as like a lot about it...
I played around with Python a few years ago but at the time it had a number of
issues that kept it from being used ( no dbi type interface at the time, issues with
extending c based classes... ). I started all this by revisiting python but
found that ruby as a language is closer to what I am looking for...

Anyway... you help... thoughts, answers etc greatly appreciated...

2

1. Can someone point me to benchmarks for ruby vs. other languages, perl
   in particular but others as well would be nice. I found a few using google
   but they all seemed to be from 2001-2002 which makes the numbers
   rather out of date as I expect ruby has improved speed wise since then...

Premature optimization is the root of all evil. Ruby is fast enough for everybody here, and its fast enough for basecamphq.com and 43things.com.

If you really need something to be fast, use the 90/10 rule. Find the 10% of your code that does all the work, and use RubyInline to optimize it into C.

2. mod_ruby vs mod_perl. mod_ruby looks from the surface to be pretty complete...
   are there features implemented in mod_perl that mod_ruby lacks?
   are there any problems or 'gotchas' with mod_ruby?

FastCGI is recommended for Rails deployments, but also works on mod_ruby. There used to be a problem where you could not gracefully restart a mod_ruby enabled server due to memory leakage, but this may no longer exist.

3. Are there ruby templating engines that are comparable feature-wise to
  perl's Template Toolkit? I looked through raa but didnt really find anything
  that would fit that basic description. In particular the built in caching for
  speed is one area... but the big features here for me are the Plugin
  and Filter interfaces for extending the template system.

Everybody has written a template tool for Ruby, and ERB (which comes with Ruby) supports caching of 'compiled' templates. Not being familiar with the Template Toolkit, I don't know what to say about it.

4. perl has a Business::Online module that has various sub-module for
   using online payment transaction systems through a unified interface.
   Do similar libraries exist for ruby?

There's currently a bounty out for this.

5. Ruby on rails - Active Records. It looks like a really nice system... comparable
   to Class::DBI in a lot of was... question I have is... what kind of performance
   hit does it incur above using DBI. In the perl universe, we decided not
   to use Class::DBI because of said considerations...

AR is plenty fast, and it does not use Ruby's DBI. By plenty fast, I mean basecamphq.com and 43things.com both run off AR, and we don't plan on switching to anything else any time soon.

6. Marshalling speed... perl has the Storable module which alas is a tad slow...
   how does ruby do in this area?

Ruby's Marshal is plenty fast, some time ago there were YAML/ruby/perl/python/etc marshalling benchmarks, and I believe Ruby's Marshal did very well compared to all comers (maybe beating?). Add memcached as an excellent place to store this data and its plenty faster.

7. Does ruby on rails work only with a cgi interface or does it work with mod_ruby?

WEBrick, CGI, FastCGI and mod_ruby are built in.

That is my first initial round of questions... I can see a number of ways that
ruby would certainly make our code easier to deal with and understand as it
makes a lot of the design patterns we use a lot easier to implement, understand etc.
And we use a good number of objects in perl which are rather heavy to construct etc.

Ruby removes lots of 'code smell' (code that smells like code, where brute force coding is used rather than elegant language)

However, perl does have cpan the breadth and depth of which helps offset some
of these issues.

Most of the perl modules you would use already have Ruby equivalents.

My big concern would be diving into ruby to save time and ease development in
one area only to have the gains lost in another.

Most of your questions seem to be Rails-focused...

So I would recommend spending one week, no more, trying out Rails and seeing if it is a fit for your work. With Ruby and Rails, one week is more than sufficient to learn enough about Ruby and Rails to make a well-informed decision. I would wager that it will actually take less than a week, simply because Ruby and Rails are that easy, that fast, and that cool.

Either way, I'm going to be playing around which ruby as like a lot about it...

Excellent!

PGP.sig (186 Bytes)

···

On 22 Jan 2005, at 20:03, Sean T Allen wrote:

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

3

So I'm looking at ruby for both personal and work projects.

Trying to assess whether it would fit my needs.

I definitely like the language as a whole however, I have questions...

most of them in comparison to perl

Most are library related...

Anyway here goes

1. Can someone point me to benchmarks for ruby vs. other languages, perl
    in particular but others as well would be nice. I found a few using
google

You can find some standard benchmarks at http://shootout.alioth.debian.org/

···

On Sun, 23 Jan 2005 13:03:17 +0900, Sean T Allen <sean@ardismg.com> wrote:

    but they all seemed to be from 2001-2002 which makes the numbers
    rather out of date as I expect ruby has improved speed wise since
then...

2. mod_ruby vs mod_perl. mod_ruby looks from the surface to be pretty
complete...
    are there features implemented in mod_perl that mod_ruby lacks?
    are there any problems or 'gotchas' with mod_ruby?

3. Are there ruby templating engines that are comparable feature-wise to
   perl's Template Toolkit? I looked through raa but didnt really find
anything
   that would fit that basic description. In particular the built in
caching for
   speed is one area... but the big features here for me are the Plugin
   and Filter interfaces for extending the template system.

4. perl has a Business::Online module that has various sub-module for
    using online payment transaction systems through a unified interface.
    Do similar libraries exist for ruby?

5. Ruby on rails - Active Records. It looks like a really nice system...
comparable
    to Class::DBI in a lot of was... question I have is... what kind of
performance
    hit does it incur above using DBI. In the perl universe, we decided not
    to use Class::DBI because of said considerations...

6. Marshalling speed... perl has the Storable module which alas is a tad
slow...
    how does ruby do in this area?

7. Does ruby on rails work only with a cgi interface or does it work
with mod_ruby?

That is my first initial round of questions... I can see a number of
ways that
ruby would certainly make our code easier to deal with and understand as it
makes a lot of the design patterns we use a lot easier to implement,
understand etc.
And we use a good number of objects in perl which are rather heavy to
construct etc.
However, perl does have cpan the breadth and depth of which helps offset
some
of these issues.

My big concern would be diving into ruby to save time and ease
development in
one area only to have the gains lost in another.

Either way, I'm going to be playing around which ruby as like a lot
about it...
I played around with Python a few years ago but at the time it had a
number of
issues that kept it from being used ( no dbi type interface at the time,
issues with
extending c based classes... ). I started all this by revisiting python but
found that ruby as a language is closer to what I am looking for...

Anyway... you help... thoughts, answers etc greatly appreciated...

--
Premshree Pillai

4

Hello Eric,

Ruby is fast enough
for everybody here, and its fast enough for basecamphq.com and
43things.com.

But since the ruby community is still very very small this is maybe
not a very clever answer.

In the average ruby is a little bit slower then perl or python but
it might not be a problem for most usecases.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

5

I am new to Ruby, coming from the Perl (99% Perl for the last 5 years, until in October when I realized, oh Ruby has English docs these days :))))) so I don't know if I totally botched these benchmarks, because I know pretty much ZERO about Ruby internals and optimizations... and about half the attempts at benchmarks in Perl I've seen have been incorrect due to compiler optimization. But this is my quick little attempt to compare Perl's Storable to Ruby's Marshall.

Yes, I know it is a bad benchmark, please don't cite this anywhere. :slight_smile: it is just for, drinking a beer saturday night, and wondering also about the speed of this new love in my life, Ruby, compared to my dear but scatterbrained ex, Perl.

But do tell if anybody knows of optimizations defeating it. At first I did use the Perlish foreach instead of the C-ish for(;;), but I knew just waiting for the results (having run the Ruby version first) that the ruby iterations were better optimized. But even having uglified the Perl to speed it up, I haven't compared just the iteration speeds. Like I said, it is a "bad" benchmark. But it is maybe more like the real world that a formal benchmark?

perl -MStorable='freeze,thaw' -e '$start = time; for($i=0;$i<100;$i++) { for($j=0;$j<100;$j++) { $foo[$i][$j] = ${thaw(freeze(\(rand)))} } }; print time - $start'
14

ruby -e 'foo = ; start = Time.new ; (0...100).each { |i| foo[i] = ; (0...100).each { |j| foo[i][j] = Marshal.load(Marshal.dump(rand)) } } ; puts Time.new - start'
1.269654

It is such a difference, I can't imagine... that I didn't short circuit the Ruby loop? I love Ruby, I want it to be fast, but this is ridiculous, somebody tell me I am just drunk.

As far as aethetics go... before when I have looked at Perl, it has always looked beautiful, because of it's strength and freedom. C, Java, Python, LISP... all have been ugly in my eyes. But now that I have found Ruby, I understand, Perl is a bit homely, yes. Still though, she is the second hottest language I have spent the night with.

···

On 22 Jan 2005, at 20:03, Sean T Allen wrote:

6. Marshalling speed... perl has the Storable module which alas is a tad slow...
   how does ruby do in this area?

--
RubyPanther

6

the requirements are that each language implement the sollution exactly the same as some other language implementation that was already done.

So don't use these benchmarks to compare the languages IMO. They are not really even trying to do that, but rather to compare only certain implementations.

It is useful of course if you just want to compare an arbitrary implmentation, instead of comparing solutions to problems.

But usually people are trying to solve a problem with a program.

For example, the matrix one... in Perl there is PDL for dealing with this. I don't know about the general case, but when doing graphics using Gimp, it is orders of magnitude faster than doing it by hand like this benchmark does. But this site doesn't allow that.

···

On Mon, 24 Jan 2005, Premshree Pillai wrote:

1. Can someone point me to benchmarks for ruby vs. other languages, perl
    in particular but others as well would be nice. I found a few using
google

You can find some standard benchmarks at http://shootout.alioth.debian.org/

--
RubyPanther

7

While we all know that benchmark results are to be taken with a piece of
salt in general, I don't believe a word of this particular one.

Just look at the default comparison table:

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=cpu

that is, all languages and all tests are considered, and comparison is
simply by cpu time.

CMUCL, Free Pascal comes after Python? Chicken, Gwydion Dylan and SBCL
after Ruby (and SBCL has just a very thin edge over... PHP)?

Don't make me laugh.

The results of the original shootout were somewhat more realistic.

Csaba

···

On 2005-01-23, Premshree Pillai <premshree.pillai@gmail.com> wrote:

You can find some standard benchmarks at http://shootout.alioth.debian.org/

8

Okay, I see one thing already, Marshal is a lot smarter than Storable.
Storable requires a reference, which is why I did \(rand), and then it has to create this unreadable trash. Whereas, Marshal is able to recognize something is simple, a String or Float or whatever. And is smart enough not to do so much work!!

So it make it more fair, I switched JUST each
   rand
to
   [rand,rand,rand]

And then I got Storable 16, Marshal 30.

Since normally these are used for data structures not just strings, I would say, Storable is slow, and Marshal is twice as slow.

···

On Sun, 23 Jan 2005, Paris Sinclair wrote:

somebody tell me I am just drunk.

--
RubyPanther

9

Commonly, it is the truth. By omitting my full response though, you misrepresent my statement.

Writing C extensions in Ruby is hardly more difficult than writing plain Ruby code, and with a tool like RubyInline, it only gets easier. Beacuse of this, many people find no problem using Ruby despite it being slower than other languages.

PGP.sig (186 Bytes)

···

On 22 Jan 2005, at 23:57, Lothar Scholz wrote:

Hello Eric,

> Ruby is fast enough
> for everybody here, and its fast enough for basecamphq.com and
> 43things.com.

But since the ruby community is still very very small this is maybe
not a very clever answer.

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

10

i found that with threading, any difference in speed is more than
accounted for...

http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

···

On Sun, 23 Jan 2005 16:57:35 +0900, you wrote:

In the average ruby is a little bit slower then perl or python but
it might not be a problem for most usecases.

11

>> 1. Can someone point me to benchmarks for ruby vs. other languages, perl
>> in particular but others as well would be nice. I found a few using
>> google
>
> You can find some standard benchmarks at http://shootout.alioth.debian.org/

the requirements are that each language implement the sollution exactly the
same as some other language implementation that was already done.

Umm, what makes you think the implementations are done differently for
different languages? They use a standard algorithm -- for obvious
reasons -- across all the languages.

So don't use these benchmarks to compare the languages IMO. They are not really

When using benchmark data, the standard disclaimer -- "benchmarks are
debatable" -- is implicit. :slight_smile:

···

On Mon, 24 Jan 2005 07:03:04 +0900, Paris Sinclair <paris@perlpuma.net> wrote:

On Mon, 24 Jan 2005, Premshree Pillai wrote:

even trying to do that, but rather to compare only certain implementations.

It is useful of course if you just want to compare an arbitrary implmentation,
instead of comparing solutions to problems.

But usually people are trying to solve a problem with a program.

For example, the matrix one... in Perl there is PDL for dealing with this. I
don't know about the general case, but when doing graphics using Gimp, it is
orders of magnitude faster than doing it by hand like this benchmark does. But
this site doesn't allow that.

--
RubyPanther

--
Premshree Pillai

12

> You can find some standard benchmarks at http://shootout.alioth.debian.org/

While we all know that benchmark results are to be taken with a piece of
salt in general, I don't believe a word of this particular one.

Just look at the default comparison table:

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=cpu

that is, all languages and all tests are considered, and comparison is
simply by cpu time.

There's a win32 benchmark page at
http://dada.perl.it/shootout/craps_cpumemloc.html There's options
other than CPU use. (I think the original shootout had other options;
can't find it now.)

···

On Mon, 24 Jan 2005 16:50:52 +0900, Csaba Henk <csaba@phony_for_avoiding_spam.org> wrote:

On 2005-01-23, Premshree Pillai <premshree.pillai@gmail.com> wrote:

CMUCL, Free Pascal comes after Python? Chicken, Gwydion Dylan and SBCL
after Ruby (and SBCL has just a very thin edge over... PHP)?

Don't make me laugh.

The results of the original shootout were somewhat more realistic.

Csaba

--
Premshree Pillai

13

Hi,

Since normally these are used for data structures not just strings, I would
say, Storable is slow, and Marshal is twice as slow.

On your machine. I got

# time perl -MStorable='freeze,thaw' -e '$start = time; for($i=0;$i<100;$i++) { for($j=0;$j<100;$j++) { $foo[$i][$j] = ${thaw(freeze(\([rand,rand,rand])))} } }; print time - $start'
1
real 0m0.943s
user 0m0.900s
sys 0m0.005s

# time ruby -e 'foo = ; start = Time.new ; (0...100).each { |i| foo[i] = ; (0...100).each { |j| foo[i][j] = Marshal.load(Marshal.dump([rand,rand,rand])) } } ; puts Time.new - start'
0.371891

real 0m0.379s
user 0m0.334s
sys 0m0.004s

on my Linux box (Pentium M 1.6MHz).

              matz.

···

In message "Re: looking at ruby..." on Sun, 23 Jan 2005 18:43:10 +0900, Paris Sinclair <paris@perlpuma.net> writes:

14

So you're saying the common truth is that Ruby is fast enough, but only if you don't use Ruby but instead C?

I think it discourages the community from focusing on things like bytecode, which could solve the problem. Because you're speaking as if using C *is* using Ruby. When instead it's a different language that can be used to work around the slowness.

It is better than to go the road of tcl, IMO. Denying that slowness is bad, and so never fixing it.

···

On Mon, 24 Jan 2005, Eric Hodel wrote:

On 22 Jan 2005, at 23:57, Lothar Scholz wrote:

Hello Eric,

> Ruby is fast enough
> for everybody here, and its fast enough for basecamphq.com and
> 43things.com.

But since the ruby community is still very very small this is maybe
not a very clever answer.

Commonly, it is the truth. By omitting my full response though, you misrepresent my statement.

Writing C extensions in Ruby is hardly more difficult than writing plain Ruby code, and with a tool like RubyInline, it only gets easier. Beacuse of this, many people find no problem using Ruby despite it being slower than other languages.

--
RubyPanther

15

Yes, normally when you are benchmarking and comparing language, you start with a problem and what the end result of the solution should be. And then of course the exact implementation in each language will be appropriate to that language. For example, sorting in C often looks very different from sorting in Perl. THe lowest common denominator will be C-ish. And Ruby's ranges are another example. In these benchmarks, the format forces the Ruby code to look like C.
   for i in 0 .. (rows - 1)
instead of
   (0...rows).each { |i| ... }
I don't know in this case if there is a difference in performance. I a nuby. BUt I know that in Perl, the Perl-ish constructs are the ones best optimized. If you structure your code the same as a Java app, it will go sloooow. Even at tasks like sorting, where the opposite is usually true in real life. You wouldn't hand-code a quicksort, because the included one is lightning speed.

···

On Mon, 24 Jan 2005, Premshree Pillai wrote:

You can find some standard benchmarks at http://shootout.alioth.debian.org/

the requirements are that each language implement the sollution exactly the
same as some other language implementation that was already done.

Umm, what makes you think the implementations are done differently for
different languages? They use a standard algorithm -- for obvious
reasons -- across all the languages.

--
RubyPanther

16

that is, all languages and all tests are considered, and comparison is
simply by cpu time.

There's a win32 benchmark page at
Computer Language Shootout Scorecard There's options
other than CPU use. (I think the original shootout had other options;
can't find it now.)

I know of it. The alioth version also has options. My criticism wasn't
against the situation that a pure CPU comparison is the basic viewmode.
Eventually, that's what all freaks mainly care about, eh? :slight_smile:

CMUCL, Free Pascal comes after Python? Chicken, Gwydion Dylan and SBCL
after Ruby (and SBCL has just a very thin edge over... PHP)?

Don't make me laugh.

My criticism was against having these unbelieveable results on that
chart.

It's possible that the distortion comes from many test not working in
several languages. Whether this is the factor which produces such a huge
noise, or not, it's irrelevant, those results are unusuable by now,
anyway.

They could at least have some explanation why is it this way, and what
improvements are possible.

Csaba

···

On 2005-01-24, Premshree Pillai <premshree.pillai@gmail.com> wrote:

On Mon, 24 Jan 2005 16:50:52 +0900, Csaba Henk ><csaba@phony_for_avoiding_spam.org> wrote:

17

Ah! Yes. I ran mine on an AMD K6-2/400 running RedHat 7.2, perl 5.8.0 and ruby 1.8.1
When I run it through time like that, it also showed Ruby as much faster because of perl's compile time. I was trying to keep that out of the data, because when I am worried about performance it is usually web app so I would be running mod_perl. And for a non-web app, perlcc works really well now. But...

I notice yours the ruby is much faster than even just the perl runtime.

And on my server (P4/2G RedHat ES 3) I am getting
perl: user 0m1.160s
ruby: user 0m0.330s

Maybe I botched my ruby compile on my slow box. :slight_smile:

I am glad it was my fault...

YaY! Ruby!

···

On Sun, 23 Jan 2005, Yukihiro Matsumoto wrote:

Hi,

In message "Re: looking at ruby..." > on Sun, 23 Jan 2005 18:43:10 +0900, Paris Sinclair <paris@perlpuma.net> writes:

>Since normally these are used for data structures not just strings, I would
>say, Storable is slow, and Marshal is twice as slow.

On your machine. I got

# time perl -MStorable='freeze,thaw' -e '$start = time; for($i=0;$i<100;$i++) { for($j=0;$j<100;$j++) { $foo[$i][$j] = ${thaw(freeze(\([rand,rand,rand])))} } }; print time - $start'
1
real 0m0.943s
user 0m0.900s
sys 0m0.005s

# time ruby -e 'foo = ; start = Time.new ; (0...100).each { |i| foo[i] = ; (0...100).each { |j| foo[i][j] = Marshal.load(Marshal.dump([rand,rand,rand])) } } ; puts Time.new - start'
0.371891

real 0m0.379s
user 0m0.334s
sys 0m0.004s

on my Linux box (Pentium M 1.6MHz).

              matz.

--
RubyPanther

18

Hi --

Hello Eric,

> Ruby is fast enough
> for everybody here, and its fast enough for basecamphq.com and
> 43things.com.

But since the ruby community is still very very small this is maybe
not a very clever answer.

Commonly, it is the truth. By omitting my full response though, you misrepresent my statement.

Writing C extensions in Ruby is hardly more difficult than writing plain Ruby code, and with a tool like RubyInline, it only gets easier. Beacuse of this, many people find no problem using Ruby despite it being slower than other languages.

So you're saying the common truth is that Ruby is fast enough, but only if you don't use Ruby but instead C?

I think it discourages the community from focusing on things like bytecode,

Don't worry -- plenty of people are focusing on things like bytecode
:slight_smile:

which could solve the problem. Because you're speaking as if using C *is* using Ruby. When instead it's a different language that can be used to work around the slowness.

It is better than to go the road of tcl, IMO. Denying that slowness is bad, and so never fixing it.

The road of Ruby is even better: denying that slowness is bad, *AND*
fixing it. So everyone is happy.

David

···

On Mon, 24 Jan 2005, Paris Sinclair wrote:

On Mon, 24 Jan 2005, Eric Hodel wrote:

On 22 Jan 2005, at 23:57, Lothar Scholz wrote:

--
David A. Black
dblack@wobblini.net

19

Paris Sinclair ha scritto:

I think it discourages the community from focusing on things like bytecode, which could solve the problem. Because you're speaking as if using C *is* using Ruby. When instead it's a different language that can be used to work around the slowness.

It is better than to go the road of tcl, IMO. Denying that slowness is bad, and so never fixing it.

given the efforts to build alternate VM/interpreters (rubydium, vuby, YARV, metaruby..) I dont think we settled on denying slowness.
But it stays true the current ruby is usually fast enough and where it is'nt you can easily write C extensions, just like you would for many things that are too slow in other languages.

20

Hello Eric,
> Ruby is fast enough
> for everybody here, and its fast enough for basecamphq.com and
> 43things.com.
But since the ruby community is still very very small this is maybe
not a very clever answer.

Commonly, it is the truth. By omitting my full response though, you misrepresent my statement.

Writing C extensions in Ruby is hardly more difficult than writing plain Ruby code, and with a tool like RubyInline, it only gets easier. Beacuse of this, many people find no problem using Ruby despite it being slower than other languages.

So you're saying the common truth is that Ruby is fast enough, but only if you don't use Ruby but instead C?

No. I'm not saying that. I said this:

Premature optimization is the root of all evil. Ruby is fast enough for everybody here, and its fast enough for basecamphq.com and 43things.com.

If you really need something to be fast, use the 90/10 rule. Find the 10% of your code that does all the work, and use RubyInline to optimize it into C.

Most of the time, Ruby is fast enough. Sometimes its not, so find those parts that are most in need of being fast, and rewrite them.

I think it discourages the community from focusing on things like bytecode, which could solve the problem.

In a few weeks, you will be able to amazingly speed up some Ruby code without writing any C. No need for bytecode just yet.

Besides, there are plenty of people rewriting Ruby's interpreter, and the true goal of the above work will help out those people who want to make Ruby in Ruby faster.

Because you're speaking as if using C *is* using Ruby. When instead it's a different language that can be used to work around the slowness.

Have you done it? Ruby's C interface is very close to writing Ruby code, making it very easy to write a Ruby C extension. (I'm also working to fix the problem of context-switching between languages with Ryan Davis.)

It is better than to go the road of tcl, IMO. Denying that slowness is bad, and so never fixing it.

While I'm not working on making Ruby faster, I fear the project may actual do so.

PGP.sig (186 Bytes)

···

On 23 Jan 2005, at 13:45, Paris Sinclair wrote:

On Mon, 24 Jan 2005, Eric Hodel wrote:

On 22 Jan 2005, at 23:57, Lothar Scholz wrote:

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04