Looking at ruby

ruby-talk
21

Hello Paris,

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.

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.

···

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

22

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

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

Ah, there you have a point. That's a serious flaw then. Methinks the
program should just follow the high-level algorithms, and then be
implemented in the particular language using whatever data
structure/controls are optimized for that language.

···

On Mon, 24 Jan 2005 16:16:47 +0900, Paris Sinclair <paris@perlpuma.net> wrote:

On Mon, 24 Jan 2005, Premshree Pillai wrote:

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.

--
RubyPanther

--
Premshree Pillai

23

Paris Sinclair ha scritto:

···

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.

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.

well, this example is not correct (since, for example, there are some scripts that use Integer#times instead of for).
But in general, we'd never write a dumb generate_random() method instead of using the builtin #rand, just to say :slight_smile:

24

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.

···

David A. Black <dblack@wobblini.net> wrote:

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

25

Eric Hodel wrote:

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.

What is happening in a few weeks?

26

Happy yes! :slight_smile: 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.

···

On Mon, 24 Jan 2005, David A. Black wrote:

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.

--
RubyPanther

27

Hi,

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

It's like searching for happiness. Lots of languages and vendors are
less fun to deal with. People and companies have their own agendas,
even you and me. I like to be part of this Ruby community. The people
here are less commercial oriented, contrary to other languages and
tools, where people are always asking how to solve their daily
problems, because they are too lazy or smart to do them themselves.

If we could solve more problems using a fun language like Ruby it
would be great in our search for happiness. :slight_smile:

But you are definitely right. But if I fully believed that you are
100% right I would be laying my body on a nice beach and forget about
programming all together. :slight_smile: heheheh

Cheers,
Joao

28

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.

On the Perl side, the usual attitude is identify those particular things, and write extensions in C that do those things. Then the users of the language are only using the Perl interface to those things, not having to each write a bunch of C. I see enough brilliant programmers using Ruby that, regardless of individual opinions on this, that is the direction it will go. It goes that direction faster, the more people who realize this. Not because Ruby should be like Perl, but because it has real world success to do this. Most users of a high level language WILL choose to keep their app just in one language.

Certainly it would be a misunderstanding to think I meant, Ruby is self hosting, or should be, or anything in that direction. I only meant, that is for internals type people, and it is too bad to claim that that should be required of everybody, just to get good performance out of typical programs.

Because that leaves out a lot of people. Who won't, in the end, be left out. The non-inclusive ideology has no chance to succeed, because Ruby is free software.

Of course people who find joy in writing C, will still do so instead of using libraries :slight_smile:

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

Meep! Well, perhaps instead of being ignorant dummies who don't understand, we simply disagree. It is worth a little thought perhaps?

···

On Mon, 24 Jan 2005, Lothar Scholz wrote:

--
RubyPanther

29

luckily there *are* other people (me) working on
solutions not involving bytecode.

alex

···

On Jan 24, 2005, at 12:05 AM, Lothar Scholz wrote:

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.

30

Hi,

···

On Mon, 24 Jan 2005 07:33:57 +0900, Navindra Umanee <navindra@cs.mcgill.ca> wrote:

David A. Black <dblack@wobblini.net> wrote:
> > 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:

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

31

You've probably seen posts from my partner-in-crime, Ryan Davis, on this topic before, but should you want more details, go check out the PDF in the topic of irc://irc.freenode.net/#ruby2c

PGP.sig (186 Bytes)

···

On 23 Jan 2005, at 14:48, Sean T Allen wrote:

Eric Hodel wrote:

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?

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

32

Navindra Umanee ha scritto:

···

David A. Black <dblack@wobblini.net> wrote:

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:

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.

the benchmark shooutout from debian.org is even mostly useless :).
  You won't use a hand written mergesort since you have it built in. You won't do numerical stuff in pure ruby since you have NArray/gsl/R/IDL libraries for that. And obviously you won' usually use long recursive calculations.