ZipPy status update

[Chris Seaton]

Ruby has very extensive use of closures (they call them blocks), and the
materialised frame is needed probably more often than not. This is used in
benchmarks and it's very much on the fast path.

I avoid materialising the frame where I know no local variables from the
declaring scope are used, but apart from that I haven't been worrying about
the performance impact yet. Your idea of making your own explicit up-values
sounds interesting, but I wonder if that's working around Truffle rather
than working with it. You will miss out on any performance improvements to
MaterializedFrame in the future, and you'll have more complex code.

In Ruby I also plan to inline all trivial methods immediately - but at the
moment I'm only doing it for getters, setters and all core methods. One
problem - if you inline straight away how do you stop the number of nodes
blowing up beyond the limit?

Christian Humer will be able to give a better explanation of @TypeCheck,
@TypeCast and @ImplicitCast, but as I understand it @ImplicitCast tells the
DSL that it can convert from one type to another via this method at any
point to satisfy specialisation signatures. So I think you could implement
the same thing using @TypeCheck and @TypeCast, but the @ImplicitCast is
often simpler and clearer.

In Ruby I use @ImplicitCast to convert between RubyFixnum and int. There is
no difference between these two types - the RubyFixnum version is just so I
can have a real object sometimes to simplify some other code. This tells
the DSL whenever you see a RubyFixnum, feel free to convert it to an int to
make things work.

    @ImplicitCast

    public int unboxFixnum(RubyFixnum value) {

        return value.getValue();

    }

I don't use @TypeCheck or @TypeCast anywhere in Ruby since I started using
@ImplicitCast instead.

Chris


On 21 December 2013 07:55, Stefan Marr <java at stefan-marr.de> wrote:

> Hi Wei:
>
> On 21 Dec 2013, at 01:45, Wei Zhang <ndrzmansn at gmail.com> wrote:
>
> > Only functions that close over its declaration frame (closures) use
> > PArguments#declarationFrame. This doesn't happen so often in my
> > benchmarks.
> > In most cases, zippy accesses local variable using VirtualFrames,
> > which is optimized by Truffle/Graal.
>
> Well, closures are much more common in Smalltalk, I think.
>
> >> I do wonder, what is the typical granularity of a Python method?
> >> At least in SOM, methods seem to be rather small. Perhaps a few AST
> nodes on average.
> >> Could that make a difference?
> >
> > Zippy inlines function calls when they become hot. Inlining helps
> > performance a lot.
> > I strongly recommend you to apply inlining in TruffleSOM if you haven’t
> yet.
>
> TruffleSOM does inlining. I only see two difference when browsing your
> code.
> The first should actually be a benefit for TruffleSOM: I also inline
> trivial methods immediately,  i.e., if a method just contains a literal or
> something similar, it is directly inlined without even a function call
> overhead, only protected by a polymorphic inline cache check node.
> The second difference I see is that you have a `prepareBodyNode()`
> operation that rewrites local variable access nodes. Why is that necessary?
>
> >
> >> Another detail I noticed is that you are using another strategy for
> type handling in the type system. You use a combination of @TypeCheck and
> @TypeCast, while I use @ImplicitCast.
> >> What is the difference of these two approaches?
> >
> > I use @TypeCheck and @TypeCast to customize type checks and
> > conversions in ZipPy. I just followed the SimpleLanguage examples in
> > Truffle API.
> > @ImplicitCast is new to me. I don't know how to use it, since there
> > isn’t any related document or example.
>
> There is a tiny example in SimpleLanguage… That’s where I took it from.
> But I have the feeling the generated code when using @TypeCheck and
> @TypeCast looks quite a bit simpler.
>
> Thanks for the comments
> Stefan
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>
>