looking at ruby...

[Joao Pedrosa]

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.

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

Cheers,
Joao

 

[Paris Sinclair]

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

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?

 

[Eric Hodel]

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

What is happening in a few weeks?

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

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

--Apple-Mail-46--630192966
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)

iD8DBQFB9D9KMypVHHlsnwQRAlPeAKDFk3Jtngab8gAE5xCgSFYRDJoXLwCfeB4a
nIagKIYYUeMb6aEswsG8fuo=
=swc7
-----END PGP SIGNATURE-----

--Apple-Mail-46--630192966--

 

[Alexander Kellett]

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.

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

alex

 

[Premshree Pillai]

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.

 

[gabriele renzi]

Navindra Umanee ha scritto:

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.

 

[Paris Sinclair]

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.

 

[Csaba Henk]

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.

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]

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

 

[Premshree Pillai]

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.

 

[gabriele renzi]

Paris Sinclair ha scritto:

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

 

[Csaba Henk]

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

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?

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