ZipPy status update

[Wei Zhang]

Hi Stefan,

> The second difference I see is that you have a `prepareBodyNode()` operation that rewrites local variable access nodes. Why is that necessary?

Inlined function in ZipPy has its own copy of the FrameDescriptor. I
did this to make sure that it doesn't share any frame state with the
original function.
'prepareBodyNode()' updates local variable accesses to use the new
FrameDescriptor.
It is just a correctness thing.

I'm actually curious about how easy/difficult was it for you to use RPython?
Compare to Truffle was it easier to get the performance that you are
happy with? or you also got some help from the PyPy guys?

Thanks,

/Wei


On Fri, Dec 20, 2013 at 11:55 PM, 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
>