looking at ruby...

[Sean T Allen]

--------------070003000202050506020904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:BI 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:BI 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...



--------------070003000202050506020904
Content-Type: text/x-vcard; charset=utf-8;
name="sean.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="sean.vcf"

begin:vcard
fn:Sean T. Allen
n:Allen;Sean T.
org:Ardis Marketing Group
adr;dom:;;;New York;NY
email;internet:[email protected]
title:Tech Guru
x-mozilla-html:FALSE
url:http://ardismg.com/
version:2.1
end:vcard


--------------070003000202050506020904--

 

[Eric Hodel]

--Apple-Mail-38--690277565
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

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:BI 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:BI 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!

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-38--690277565
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB81SWMypVHHlsnwQRAmZVAJ9/dw6IUb0kznVag836xwRJG44U/gCffgWU
H9Vd12Qp4PCj9x1FKH2+omE=
=bUYL
-----END PGP SIGNATURE-----

--Apple-Mail-38--690277565--

 

[Lothar Scholz]

Hello Eric,

EH> Ruby is fast enough
EH> for everybody here, and its fast enough for basecamphq.com and
EH> 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.

 

[Paris Sinclair]

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

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. 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 = [] ; (0...100).each { |j| foo[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.

 

[Paris Sinclair]

somebody tell me I am just drunk.

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.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: looking at ruby..."

|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 = [] ; (0...100).each { |j| foo[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.

 

[Paris Sinclair]

Hi,

In message "Re: looking at ruby..."

|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 = [] ; (0...100).each { |j| foo[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.

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.

I am glad it was my fault...

YaY! Ruby!

 

[Premshree Pillai]

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/

 

[Eric Hodel]

--Apple-Mail-39--648502523
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hello Eric,

EH> Ruby is fast enough
EH> for everybody here, and its fast enough for basecamphq.com and
EH> 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.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-39--648502523
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB8/fEMypVHHlsnwQRAo7UAJ9sU6TugJoyhokQAQi/abC4biJ0KACgt/7q
6BpbRTaIQmdTGjgfvZa3xFU=
=1AXI
-----END PGP SIGNATURE-----

--Apple-Mail-39--648502523--

 

[Paris Sinclair]

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,
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.

 

[Paris Sinclair]

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.

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.

 

[David A. Black]

Hi --

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

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

 

[gabriele renzi]

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.

 

[Eric Hodel]

--Apple-Mail-40--636737314
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

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:

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.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-40--636737314
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB9CW/MypVHHlsnwQRAk80AJ9FoHBCPCAmTmXIurDuClYD5gEkSQCgh2YL
CyH3/OErLK34iehf9UOthG8=
=16IO
-----END PGP SIGNATURE-----

--Apple-Mail-40--636737314--

 

[Navindra Umanee]

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

Can you give more pointers on this? Any nice blogs of the ongoing
efforts to speed up Ruby and the success so far? The benchmark
shootout on debian.org is somewhat worrying.

Thanks,
Navin.

 

[tony summerfelt]

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

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

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

 

[Joao Pedrosa]

Hi,

Can you give more pointers on this? Any nice blogs of the ongoing
efforts to speed up Ruby and the success so far? The benchmark
shootout on debian.org is somewhat worrying.

This could be Ruby 2.0:
http://www.atdot.net/yarv/bench_20041206.txt

Cheers,
Joao

 

[Sean T Allen]

--------------040104030605000808050508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.



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.

What is happening in a few weeks?

--------------040104030605000808050508
Content-Type: text/x-vcard; charset=utf-8;
name="sean.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="sean.vcf"

begin:vcard
fn:Sean T. Allen
n:Allen;Sean T.
org:Ardis Marketing Group
adr;dom:;;;New York;NY
email;internet:[email protected]
title:Tech Guru
x-mozilla-html:FALSE
url:http://ardismg.com/
version:2.1
end:vcard


--------------040104030605000808050508--

 

[Paris Sinclair]

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

Happy yes! It pleases me to see such an enlightened attitude of
inclusiveness. Thank you for that.

For me a single instance of this philosophy is more reassuring about the future
of choosing Ruby, than all of the "it's plenty fast" propaganda, and the "C is
Ruby"... I don't have a word for that that is printable.

 

[Lothar Scholz]

Hello Paris,

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

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

There are some things that can never be done with anything else then a
static typed language. Computational algorithms like matrix
operations, parsing, decoding or compression will always be around 100-200
times slower. No bytecode will help you here. Even FORTH which is far better
then bytecode (direct threaded interpreter, together with a build in
stack that eliminates the function call overhead) is not very good in
doing these things.

Unfortunately many people still don't understand that many projects
should be written in multiple languages.