From: MikkelFJ <mikkelj-anti-spam@...1.dknet.dk>
Date: 2001-08-23T18:46:33+09:00
Subject: [ruby-talk:20171] Re: [patch] block memory allocation scheme - bmalloc


"Ryan Tarpine" <rtarpine@hotmail.com> wrote in message
news:m%Mg7.125639$EP6.34448084@news1.rdc2.pa.home.com...

> > Given that OCaml is one of the fastest interpreted language, I'm

As has been mentioned, OCaml is not interpreted - but it does have a small
runtime engine.

> I am new to both OCaml and Ruby, so correct me if I'm wrong, but as far
far


I'm no expert in these languages either.

> as I know one of the reasons OCaml is so fast is because of the strong
type
> checking.

That is certainly a part of it. But on larger systems, dynamic typechecking
is not necessarily slow. This is partially because in static typechecking
you move a lot of type conversion into userspace and where dynamically typed
systems can avoid much marshalling overhead.

> OCaml minimizes run-time type checking, which
> of course in Ruby is not possible because the object's methods must be
> queried and called.

But I reckon the real speed-advantage is not so much the avoidance of
typechecking by itself. Even OCaml has a lot of camouflaged typechecking
because a type can be one of several subtypes. But it usually only need to
check for a few different types.
A combination of strong knowledge of type combined with control over the
compiled code provides for some effective internal representation
optimizations.

The general consensus seems to that OCaml is slower than C but faster than
C++. That somehow makes sense. In C++ you often sacrifice speed to gain
convinience and code clarity.

Another reason for OCaml speed is its effective garbage collection (I
guess). You can do some operations more effeciently in garbaged collected
enviroments - especially in larger systems where you don't have to make
isoloated memory boundaries - i.e. this object controls all allocation /
deallocation.

You would probably never get Ruby close to OCaml in raw smallscale speed.
But you learn a lot from the compiler design anyway, as it does handle the
mix of bytecode and native code compilation as well as garbage collection.
And Ruby can be made to run significantly faster than it does today.

Mikkel