Re: Non-overridable and non-redefinable methods

--- SASADA Koichi <[e-mail]> wrote:

> Hi,
> 
> Eric Mahurin wrote:
> > What I'm talking about above (inlining certain methods in
> > Object tagged as non-overridable) wouldn't require any
> static
> > analysis because these methods would be independent of
> class.

For this case, let's say Object#nil? is non-overridable. 
Whenever you have obj.nil?, it would be equivalent to:

obj.__id__==nil.__id__

well, that is if __id__ was also nonoverridable and Fixnum#==
wasn't redefined.  No method calls needed after this is
inlined.  This could be done independent of the class of obj.

> > It is unfortunate that you've abandoned static analysis.  I
> > think you could see huge performance improvements if you
> went
> > that route.  I believe you could approach C/C++ performance
> -
> > like Java is on every release.  To really go down this
> path,
> > you would have to recompile a method for each set of
> classes it
> > is called with (recursively).  So for one method in ruby,
> it
> > might be compiled into many methods statically typed and
> > possibly some partially or not static typed.  And you could
> > also in-line in the right places easily - because you know
> the
> > class.  Of course the big problem to all of this is
> redefinable
> > methods.
> 
> I can't understand what you proposing (because of my English
> skills and 
> Programming skills).  Can I get some example (pseudo code)
> for 
> translation?  I think inlining a Ruby method is quite
> difficult.

Here is an example:

module ComparableSequence
  def compare(seq)
    i=0
    loop {
      a = self[i]
      b = seq[i]
      a && a==b or return i,a,b
      i += 1
    }
  end
end

class String;include ComparableSequence;end

class Array;include ComparableSequence;end

"hi".compare("hi")
"hi".compare([?h,?i])
[?h,?i].compare("hi")
[?h,?i].compare([?h,?i])


I'm suggesting that in the above, the method compare would be
split by the compiler/VM into 4 optimized versions - one for
each set of classes for self and seq.  Every call could of a
method could end up referring to a different version.  For
example in the String#compare(aString) version, you could do
these things:

- determine that i is a Fixnum (or at least an Integer).  It
should stay in the Fixnum range because String#[aBignum] should
cause an exception.  I'm not going to say this is easy.

- determine that a and b are always Fixnum's because
String#[anInteger] always returns a Fixnum

- a==b can become Fixnum#==(aFixnum) which can be in-lined

- i + 1 can become Integer#+(aFixnum) or possibly
Fixnum#+(aFixnum).  Maybe even optimize the += completely to
become something like ++i in C.

When optimizing the Array#compare(anArray) method, you won't be
able to do all of these optimizations so easily since it isn't
know that a and b are Fixnum's.  It would be nice if you could
potentially statically track what could be in an Array also,
but that would quite difficult.

Again, the problem with all of the above is the redefinability
of the methods.  Where the programmer wants these
optimizations,  the klass.freeze method could be used as
suggested earlier.  You'd only inline instance methods from
classes that are frozen.



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