From: Samuel Williams <space.ship.traveller@...>
Date: 2010-10-05T18:49:14+09:00
Subject: Re: how can we make a ruby compiler


On 5/10/2010, at 9:42 PM, Michal Suchanek wrote:

> On 5 October 2010 07:10, Clifford Heath <no@spam.please.net> wrote:
>> Tony Arcieri wrote:
>>> 
>>> ... FOR SPEED! For example, you're a company on the
>>> scale of Facebook who has written a large web site in a dynamic language
>>> and
>>> suddenly realize you could be saving a lot of money on servers if your app
>>> ran a lot faster. Source translation to C++ is a potential way to go

I thought I'd throw in my 2cents since I've actually done a little bit of profiling.

There are two main reasons for "compilation":
	- Faster execution for code that is repeated many times
	- Better foreign function interface

Other parts of modern compilers which are separate from compilation include:
	- Syntax correctness
	- Type checking / program validity

From my experience, a fast interpreter is better than a compiler in many cases, unless you are optimising an inner loop for code which is pushing the CPU. I found this out from writing an interpreter and compiler and doing the tests for myself. I was surprised by the result.

Many problems are algorithmic in nature, and a compiler will only provide a marginal improvement in speed.

If you have a truly dynamic language (like Ruby), it is almost impossible to compile it adequately. This is because compilation is all about making assumptions. A dynamic language makes it very hard to make assumptions (there is quite a bit of research in this area, it is worth reading about it).

From testing code that is either interpreted or compiled, I found that you had to run the code at least 10 times before you saw any kind of parity. For an inner loop on some complex function, this could be beneficial.

Every specific situation is different, and this is my experience.

Kind regards,
Samuel