how can we make a ruby compiler

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

What's "awesome" is that not a soul on this thread has asked you a single
clarifying question...

WHY do you want one and WHAT do you want to do with it?

Perhaps the most straightforward answer for wanting a Hiphop or
Starkiller-like compiler is 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 don't think that applies to anyone who uses Ruby, though. Maybe Twitter...

 

[Ryan Davis]

=20

What's "awesome" is that not a soul on this thread has asked you a = single
clarifying question...
=20
WHY do you want one and WHAT do you want to do with it?

=20
Perhaps [... lots of speculation ...]

My point was that none of your speculation matters in the absence of =
clarifying questions to the OP.

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

My point was that none of your speculation matters in the absence of
clarifying questions to the OP.

Given the OP hasn't responded to any of the discussion, the world may never
know...

 

[Clifford Heath]

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

And in all the world, there are how many companies that have a
web site that large (in traffic)? Maybe not even one other.
And they could afford to rewrite the site in whatever language
they chose, instead of relying on a dodgey translator to give
them an unreadable result.

I can't believe how many people use the old "but what if we
become as large as Facebook?" argument to drive their technology
choices. Like the number of places using NoSQLs to produce sites
that are even less reliable than they used to...

 

[Michal Suchanek]

And in all the world, there are how many companies that have a
web site that large (in traffic)? Maybe not even one other.
And they could afford to rewrite the site in whatever language
they chose, instead of relying on a dodgey translator to give
them an unreadable result.

I can't believe how many people use the old "but what if we
become as large as Facebook?" argument to drive their technology
choices. Like the number of places using NoSQLs to produce sites
that are even less reliable than they used to...

The lack of reliability is not caused by using a less traditional
database but by programming errors either in the site itself or the
tools it uses.

Some databases not associated with NoSQL such as MySQL tend to be very
unreliable.

Using new and experimental technology is not always a good idea but
using old and known broken technology is never so and many people do
that anyway.

Thanks

Michal

 

[Samuel Williams]

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

=46rom 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).

=46rom 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

 

[Ryan Davis]

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

Well this just isn't true (or is overly vague and my tired brain is =
reading more into it than it should). Look at anything written by David =
Ungar, or the research done on self, smalltalk, the latest javascript =
engines, etc...

 

[Samuel Williams]

Dear Ryan,

Thanks for your comments. In this discussion there are many opinions, so =
please keep in mind this is simply my perspective based on my =
experience.

On Oct 5, 2010, at 02:49 , Samuel Williams wrote:
=20

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

=20
Well this just isn't true (or is overly vague and my tired brain is =

reading more into it than it should). Look at anything written by David =
Ungar, or the research done on self, smalltalk, the latest javascript =
engines, etc...


I'm aware of most of this work, however I don't consider many of these =
languages to be completely dynamic. By dynamic, I mean that it is not =
possible to make an assumption about the result of an expression unless =
it is executed. If you can make an assumption about an expression, I =
don't consider it to be dynamic.

For example, in most of those languages, the name of a function is =
specified explicitly and can't change due to the environment or scope of =
execution. We also know that all arguments to a function will be =
evaluated in the current scope. We can do some analysis and determine =
that an expression won't change in a loop, and then optimise for this =
case. Many of these languages provide some semantic models which allow =
the interpreter to make assumptions.

A good indication of a non-dynamic programming language is the presence =
of semantically meaningful keywords, especially those that have fixed =
behaviour. Examples include "def", "if", "while", "switch" and "try". =
These expressions can all be analysed with the knowledge of a given =
semantic model. A truly dynamic language has no such luxury...

In the case of a dynamic language we are reduced to statistical analysis =
at run time. Compilation becomes a method of speeding up the interpreter =
execution rather than optimising based on assumptions in the code =
itself. Few, if any, programming languages are completely dynamic. =
Scheme would be one language that I would consider very dynamic, as an =
example.

An interpreter is simply a high level processor (i.e. CPU). However, =
there are intrinsic semantic structures which cannot be lowered. =
"Sufficiently smart compilers", and all that. Programming languages =
range from completely dynamic to completely static, depending on the =
semantic and execution model.

Kind regards,
Samuel

 

[Samuel Williams]

Scheme would be one language that I would consider very dynamic, as an =

example.

Sorry, I meant to say "Scheme would be one language that I would =
consider very close to being completely dynamic".

 

[Urabe Shyouhei]

For example, in most of those languages, the name of a function is specified explicitly and can't change due to the environment or scope of execution.

Oh yes they can. For instance:

rhino

Rhino 1.7 release 2 2010 01 20
js> foo = {
foo: function() {
this.foo = function () {
return "bar"
};
return "foo";
}
};
[object Object]
js> foo.foo();
foo
js> foo.foo();
bar

 

[Rick DeNatale]

Dear Ryan,

Thanks for your comments. In this discussion there are many opinions, so =

please keep in mind this is simply my perspective based on my experience.le to compile it adequately. This is because compilation is all about makin=
g assumptions. A dynamic language makes it very hard to make assumptions (t=
here is quite a bit of research in this area, it is worth reading about it)=

 

[namekuseijin]

my 3 cents:

1) static type-inferencing analyzers/compilers wouldn't help much in a
language where you can do something like monkey patching and modify
behaviour of classes at runtime: there's not many things remaining
static (for too long) in a ruby program
2) static type-inferencing analyzers/compilers could work if they were
whole-program compilers, but for a typical ruby program this could
mean a few hours or days of compilation time and memory swapping
3) static type-inferencing analyzers/compilers could work best for
ruby if they were JITs, but still wouldn't get you anywhere near the
performance of a static language by nature.

 

[William Rutiser]

And Gerald Sussman went on to write, with Julie Sussman and Harold
Abelson, "The Structure and Interpretation of Computer Programs" which
should be an eye-opener to anyone who has thought of C as the
prototypical programming language.

Thanks to MIT's open course ware program, 21 hours of video of Sussman
and Abelson teaching a course of the same name are available here:

http://www.youtube.com/view_play_list?p=E18841CABEA24090

Links to the book itself and other information are here:
http://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs

-- Bill

 

[Philip Rhoades]

Bill,

Thanks to MIT's open course ware program, 21 hours of video of Sussman
and Abelson teaching a course of the same name are available here:

http://www.youtube.com/view_play_list?p=E18841CABEA24090

Links to the book itself and other information are here:
http://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs

What level of programmer is this stuff aimed at? I want a Ruby compiler
(see previous message) but am interested generally and would like to
know more but I am a biologist and not really a serious low-level coder . .

Thanks,

Phil.
--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: (e-mail address removed)

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

What level of programmer is this stuff aimed at?

SICP is actually aimed at freshmen at MIT. So I might be inclined to say
"beginners"...

 

[namekuseijin]

[Note:  parts of this message were removed to make it a legal post.]

What level of programmer is this stuff aimed at?

SICP is actually aimed at freshmen at MIT. So I might be inclined to say
"beginners"...

freshmen at MIT are higher level than your average joe. Plus, they
may be freshman, but after going through SICP they come out
wizards...

Have you ever taken the time or curiosity to read some of it?

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

Have you ever taken the time or curiosity to read some of it?

I've never read the wizard book but I've watched the Ableson/Sussman
lectures which are very interesting.

 

[William Rutiser]

Bill,





What level of programmer is this stuff aimed at? I want a Ruby
compiler (see previous message) but am interested generally and would
like to know more but I am a biologist and not really a serious
low-level coder . .

Thanks,

Phil.

The book was the text for the introductory programming course at MIT.
The preface, describing the teaching of the material over several years
to 600-700 students, says:

Most of these students have had little or no prior formal training in
computation, although many have played with computers a bit and a few
have had extensive programming or hardware-design experience.

MIT, of course, is not a trade-school and this book is not really about
the Scheme language. Its about computation and programming itself.
Perhaps it will help to think of it as being like an introduction to
cell biology as opposed to a cook book for a sushi chef. (Ignore the
metaphor if it doesn't resonate.)

You can download the book at the cost of a little bandwidth. I suggest
you do so and read the forward, preface, table of contents, then skim
the first chapter and flip thru the rest of the book. Note that it ends
with a compiler and garbage collector. Then you can make an informed
decision about how much time to devote to it.

As for a Ruby compiler, a useful one is very unlikely for many reasons.
Now a compiler for a different language that has a distant family
resemblance to Ruby may be possible but likely of not much practical use.

-- Bill

 

[Eleanor McHugh]

As for a Ruby compiler, a useful one is very unlikely for many =

reasons. Now a compiler for a different language that has a distant =
family resemblance to Ruby may be possible but likely of not much =
practical use.

Lisp, Scheme, Forth and Smalltalk are all compilable so in principle =
Ruby should be as well. It's just not clear that there's any real gain =
by doing so outside of very particular applications (i.e. dominated by =
maths or interpretation performance bottlenecks). Moreover multicore is =
teasing us towards a world where all processing will be a negligible =
cost compared to I/O latencies and throughput, much as was the case =
fifty years ago.


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel

 

[Mohit Sindhwani]

Perhaps the most straightforward answer for wanting a Hiphop or
Starkiller-like compiler is 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 don't think that applies to anyone who uses Ruby, though. Maybe Twitter...

If you get to that scale (and are hopefully making money by then or have
very large investments that match your scale of users/ traffic), there
is a high chance that you will need to re-architect or rewrite a bunch
of stuff - I don't think source translation will solve the problem.

On the other hand, Speed is an objective is something I am very keen
on... I think there's a bunch of stuff that we do which is acceptable in
Ruby but I would prefer it to run faster in some cases. However, I have
often found that Ruby lets me do the first prototype fast and once the
system is mature, if the speed is needed (not desired), a rewrite in C++
is not that difficult - it should be noted that I'm not a super-advanced
Ruby programmer... what that means is that I tend to write Ruby code
that avoids the advanced constructs of Ruby, making translation to C++
easier.

Cheers,
Mohit.
5/10/2010 | 5:10 PM.