Large Ruby Apps ?

[Isaac Gouy]

I believe this is incorrect. It should be possible to do a lot of
static analysis in Ruby, it's just that there is some type inference
etc that needs to be done first, and that is a significant amount of
work to implement.

An oldish reference that cover this fairly well is Ole Agesen's PhD
thesis "Concrete Type Inference: Delivering Object-Oriented
Applications" (available from
http://research.sun.com/techrep/1996/abstract-52.html)

That reference is based on work done in the language Self, which is
prototype based, and contains the same challenges as (pure) Ruby.
Things get much more complex if C is thrown into the mix, of course.

A newer reference based on work done in the language Smalltalk (and of
course many other approaches have been developed for Smalltalk over the
years)

Applications of Concrete-Type Inference
http://blogs.sun.com/roller/resources/ahe/peter-ahe-thesis.pdf

 

[Matt Pattison]

I believe this is incorrect. It should be possible to do a lot of
static analysis in Ruby, it's just that there is some type inference
etc that needs to be done first, and that is a significant amount of
work to implement.

An oldish reference that cover this fairly well is Ole Agesen's PhD
thesis "Concrete Type Inference: Delivering Object-Oriented
Applications" (available from
http://research.sun.com/techrep/1996/abstract-52.html)

That reference is based on work done in the language Self, which is
prototype based, and contains the same challenges as (pure) Ruby.
Things get much more complex if C is thrown into the mix, of course.

A much more recent example of this sort of type inference inference,
for a subset of Python, is Shed Skin:

http://shed-skin.blogspot.com
http://shedskin.sourceforge.net

It is a Master's Thesis and a Google Summer of Code project. It uses
Ole Agesen's Cartesian Product Algorithm, combined with what the
author calls "iterative object contour splitting", and converts
straightforward python code directly into C++ using type inference,
resulting in a ~ 10x speed up.

The guy seems to know what he's talking about, maybe some of these
ideas could be transferrable to an experimental, type inferring Ruby?

Matt Pattison

 

[Ben Myles]

It is a Master's Thesis and a Google Summer of Code project. It uses
Ole Agesen's Cartesian Product Algorithm, combined with what the
author calls "iterative object contour splitting", and converts
straightforward python code directly into C++ using type inference,
resulting in a ~ 10x speed up.

I wonder how hard it would be to create a ruby to objc converter? On a
feature by feature comparison, objc appears to come a lot closer than
c or c++ :

http://www.approximity.com/ruby/Comparison_rb_st_m_java.html

But then, I've no idea whether a ruby program converted to objc would
result in higher performance and/or less memory usage.

Ben

 

[Lothar Scholz]

Hello Matt,

MP> A much more recent example of this sort of type inference inference,
MP> for a subset of Python, is Shed Skin:

MP> The guy seems to know what he's talking about, maybe some of these
MP> ideas could be transferrable to an experimental, type inferring Ruby?

I'm still convinced that type inference with ruby and python without
added declarations is complete useless, so i was very surprised by
this stuff, but after reading the following:

<QUOTE>
At the moment the compiler correctly handles 124 unit tests,
six of which are serious programs of between 100 and 200 lines:
</QUOTE>

I now feel again on a save ground with my opinion. The guy had managed to
transform a program of 200 lines of code to C++, very cool. But this
does not say very much about real world usage.

 

[Eivind Eklund]

Hello Matt,

MP> A much more recent example of this sort of type inference inference,
MP> for a subset of Python, is Shed Skin:

MP> The guy seems to know what he's talking about, maybe some of these
MP> ideas could be transferrable to an experimental, type inferring Ruby?

I'm still convinced that type inference with ruby and python without
added declarations is complete useless, so i was very surprised by
this stuff, but after reading the following:

<QUOTE>
At the moment the compiler correctly handles 124 unit tests,
six of which are serious programs of between 100 and 200 lines:
</QUOTE>

I now feel again on a save ground with my opinion. The guy had managed to
transform a program of 200 lines of code to C++, very cool. But this
does not say very much about real world usage.

Have you read the references on type inference for Self *which has
been real world implemented and has worked*?

This is a prototype based object oriented language with, as far as I
can tell, the same set of challenges as Ruby. Smalltalk has many of
the same challenges; Self has full set of challenges as pure Ruby. (C
extensions is a separate issue, of course.) That implementation has
been tested against the use of type feedback, getting similar end
results.

Do you have any concrete challenges in Ruby that you think are beyond
the challenges in Self? As far as I've been able to tell, the Self
implementation contains all the challenges that a Ruby implementaiton
would.

If you don't, please stop scaring people - we want them to go
implement type inference for Ruby

Eivind.

 

[Tanner Burson]

------=_Part_11331_7704697.1128351191334
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Have you read the references on type inference for Self *which has
been real world implemented and has worked*?

This is a prototype based object oriented language with, as far as I
can tell, the same set of challenges as Ruby. Smalltalk has many of
the same challenges; Self has full set of challenges as pure Ruby. (C
extensions is a separate issue, of course.) That implementation has
been tested against the use of type feedback, getting similar end
results.

Do you have any concrete challenges in Ruby that you think are beyond
the challenges in Self? As far as I've been able to tell, the Self
implementation contains all the challenges that a Ruby implementaiton
would.

If you don't, please stop scaring people - we want them to go
implement type inference for Ruby

'We' do?

Eivind.

--
=3D=3D=3DTanner Burson=3D=3D=3D
(e-mail address removed)
http://tannerburson.com <---Might even work one day...

------=_Part_11331_7704697.1128351191334--

 

[Lothar Scholz]

Hello Eivind,


EE> Have you read the references on type inference for Self *which has
EE> been real world implemented and has worked*?

Yes i read. No it did not worked well - at least on the level people
expect it here. I'm tired about this and will not discuss this here
agein.

Did you read the paper and did you read what optimizations where made ?

EE> Do you have any concrete challenges in Ruby that you think are beyond
EE> the challenges in Self? As far as I've been able to tell, the Self
EE> implementation contains all the challenges that a Ruby implementaiton
EE> would.

Yes. With it's classless design its very hard, on the same level as
ruby. They didn't get it done for Self and i doubt that anybody will
get it done by ruby, because there are some facts that prevent it from
at least general purpose useage. And yes i know all this python stuff
too. It might work well on some problems (algorithms especially mathematical
ones) but not on others (data handling) and all solutions have the
problem that they don't work on larger code (as the memory
consumptions grow exponentially). And on smaller code examples there
is simply no reason to use an untyped script language.

EE> If you don't, please stop scaring people - we want them to go
EE> implement type inference for Ruby

They can try. But i want see some theoretical paper about this first
and then a paper that explains what they did with what precision,
what are the conclusions and whats there explainations.
The Self people didn't publish anything about this or if you know such
a paper please post an URL.

Smalltalk VM's gets most of its power from optimizing the control-flow
and the garbage collector and not the data type inference.
But even with this we can see an 30 times improvement of speed (as YARV shows).

 

[YANAGAWA Kazuhisa]

In Message-Id: <[email protected]>

They can try. But i want see some theoretical paper about this first
and then a paper that explains what they did with what precision,
what are the conclusions and whats there explainations.
The Self people didn't publish anything about this or if you know such
a paper please post an URL.

Papers on compiler:
<http://research.sun.com/self/compiler.html>

especially on optimization and type inference:
<http://research.sun.com/self/papers/customization.html>
<http://research.sun.com/self/papers/iterative-type-analysis.html>
<http://research.sun.com/self/papers/type-feedback.html>

....and others, if interested:
<http://research.sun.com/self/papers/papers.html>

Yes I've not read all the papers and I don't know you have, but they
did publish, didn't they?

 

[Ron M]

In Message-Id: <[email protected]>

They can try. But i want see some theoretical paper...
The Self people didn't publish anything about this or if you know such
a paper please post an URL.

Papers on compiler: [...]
<http://research.sun.com/self/papers/papers.html>

One more set of interesting papers from them is their work on
dynamic deoptimization that lets you inline Virtual Methods (and
any other dynamic classes) -- apparently by initially doing all the
cool optimization tricks like inline-ing stuff if no derived classes
exist; and then if needed "de-optimizing" the caller later if
any derived classes ended up overriding the virtual methods at
some later time.

http://research.sun.com/jtech/pubs/99-inlining.pdf
http://research.sun.com/kanban/
http://research.sun.com/self/papers/dynamic-deoptimization.html
http://research.sun.com/techrep/2000/smli_tr-2000-87.pdf

Yes I've not read all the papers and I don't know you have, but they
did publish, didn't they?

I admit I didn't read their type inferrance papers; but I did
read their dynamic de-optimization papers back when I worked
on a java virtual machine (that has to worry about things like
this because at JIT-compile time you don't know if a class
loader might extend a class you're optimizing some time in
the future). The 'self' guys published some very cool stuff.