--- Florian Gro<florgro / gmail.com> wrote:

> Eric Mahurin wrote:
> 
> > Lately, I've been thinking about the future of ruby
> > performance, ruby compilers, optimizations that a ruby
> compiler
> > or VM could make, etc.  I've come to the conclusion that
> one
> > big problem in ruby is that you can redefine (or remove) a
> > method (of an object or an instance method of a class) at
> any
> > point while running.  Here are the problem I see with being
> > able to do this:
> 
> Or to say it in another way: The language is hard to
> optimize, let's 
> change it to one that's easier to optimize at the cost of
> sacrificing 
> features.

Not exactly.  My proposal in this case was to add the "feature"
of being able to specify methods that can't be overridden
and/or redefined.

> Note that this quote also applies here:
> 
> "Researchers seeking to improve performance should improve
> their 
> compilers instead of compromising their languages."
> 
> -- An Efficient Implementation of SELF, a Dynamically-Typed 
> Object-Oriented Language Based on Prototypes, July 1989

I saw you mention that quote before.  I'd agree with it for the
most part, but are you going to take it as the word of God?

For example, I think someone mentioned at one time they'd like
the ability to be able to know the variable name(s) that are
assigned to a given object.  Although this might be a somewhat
useful feature in a language, it would result in some terrible
performance issues (memory and speed) in any implementation.


> > To solve these problems and preserve existing
> functionality,
> > I'd propose that there be a way to tag a method to not be
> > redefinable or removable.
> 
> I'd propose doing it similar to YARV. Optimize 1 + 2, but
> only if you 
> clearly see a Fixnum.freeze at the beginning of the file.

I was not aware that we are getting this type of optimization
in YARV already.  Excellent.

Yes, Fixum.freeze is an excellent solution.  But, it is a
little more restrictive than what I'm proposing.  You won't
even be able to add methods to the Fixnum class - which
shouldn't affect your 1+2 example.  Effectively what I'm
suggesting is the ability to freeze a method and then the
optimization could also pick up on that.  I didn't see a way to
freeze a method right now (tried instance_method(meth).freeze).

> > Or am I off base?  Is there another way to get this kind of
> > in-line performance without adding these
> > non-overridable/non-redefinable capabilities.
> 
> It isn't easy which is why nobody has done it yet, but you
> can inline 
> methods and heavily optimize them -- you just have to
> invalidate your 
> optimized versions when a method has been changed.

Yes, that could be quite difficult.  You'd have to have to
maintain a mapping from the instance method back to all of the
places that it is used.  Fortunately, this might be doable with
only a performance penalty to method (re)definition.  But, the
memory overhead could be quite significant.

> You can
> even compile 
> two branches of the code -- one depending on no core class
> methods being 
> overridden and the other not depending on it -- and execute
> the right 
> one with an if statement.

But, that if statement and check may have almost as much
performance overhead as the method call itself, so you might
not gain anything.  And the memory performance of this isn't so
good either - 2 branches of code.

It'd be a whole lot easier and at a minimum you'd get better
memory performance than other solutions if you had a way to say
that a method won't be redefined (not to be confused with
overridden in a derived class).

Maybe another solution is to use klass.freeze as YARV does, but
allow it to come a little later after you've possibly added a
few more methods (rather than right at the beginning of the
file).  This would solve the non-redefinable methods issue I
had with no language change and allow about the same
flexibility as the "freezing" a method solution I originally
proposed.

But, this doesn't solve the non-overridable attribute that I
think should be placed on at least a few of the methods in
Object.

I still think many of the methods in the core classes should be
marked by default as non-redefinable and in Object some also as
non-overridable.  A metric to use for a given method would be
to see if that method is ever effectively in-lined in the C
code.  For example, when the C code knows its dealing with a
Fixnum, it won't typically call the "+" method and instead
inline the additon.  Or if it wants to see if two arbitrary
objects are #equal? the C code will just compare the pointers
directly rather than calling #equal?.  I don't think it makes
any sense to redefine and/or override methods in those cases,
since the C code has already inlined them.

> The SELF guys have done a lot of interesting optimizations
> like this and 
> I'd think that at least some of them can also be applied to
> Ruby.

I haven't looked at self, but I hope for more optimizations
along these lines too.




		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs