Underscore

Ruby
21

On Wed, May 30, 2007 at 08:30:13PM +0900, Jon H. wrote:

making it comparable to OCaml’s bytecode, which is hardly surprising since
they are both stack machines with threaded code/computed gotos.

Yes. Is there a native-code compiler for Ruby in the works? Does the .NET
implementation give much better performance?

Nothing has been heard about a native code compiler (Ruby makes it
challenging
for a number of reasons).

AFAIK at this point in time the alternative implementations are all
slower or
a bit faster at best than the standard interpreter.

Microsoft’s IronRuby hasn’t been released yet, so nothing is known about
its
performance or the degree of compatibility with Ruby 1.8. The most
recent
IronPython vs. CPython benchmark I’ve found[1] reveals that the former
is not
faster than the latter. If IronRuby performs similarly, it might come
relatively close to Ruby 1.9 (formerly known as YARV), but it doesn’t
look
like it will improve significantly on it.

[1]
http://lists.ironpython.com/pipermail/users-ironpython.com/2007-April/004773.html

22

Mauricio F. wrote:

The most recent
IronPython vs. CPython benchmark I’ve found[1] reveals that the former is
not faster than the latter.

Wow. That’s absolutely fascinating.

I’ve put a lot of effort into learning the new F# programming language
from
Microsoft Research. It is derived from the Caml family of functional
programming languages and suffers from similar performance trade-offs
taken
by .NET:

  1. Allocation is much slower because the .NET allocator is designed to
    work
    with object lifetime distributions typical of C#.

  2. Exceptions are 600x slower on .NET and exceptions are ubiquitous in
    OCaml, used extensively by the stdlib for common cases (e.g. not finding
    an
    element in a dictionary).

  3. Tail calls are also ubiquitous in functional languages and they are
    many
    times slower on the .NET platform. You can ask the compiler to use
    non-tail
    calls but then you run the risk of blowing stack.

So the differences between OCaml and F# hit worst case in a wide variety
of
real situations. Very interesting to see that the performance
differences
are so huge that they even affect interpreted languages. I would not
have
expected that.