ZipPy status update

[Wei Zhang]

Hi Stefan,

> Hm, ok. I still don’t exactly see why that is necessary. Is the frame layout different? I thought the FrameDescriptor is more or less just a declaration of what goes where, and that should be identical for inlined functions as well, no?

It is the FrameSlots that need the separation. FrameDescriptor#copy()
initializes the new copy with a fresh set of FrameSlots, so it does
not share any state with the original one.
Since, you know, a function can be invoked with different argument types..

Thanks,

/Wei


On Sun, Dec 22, 2013 at 3:00 AM, Stefan Marr <java at stefan-marr.de> wrote:
> Hi Wei:
>
> On 22 Dec 2013, at 08:44, Wei Zhang <ndrzmansn at gmail.com> wrote:
>
>> 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.
>
> Hm, ok. I still don’t exactly see why that is necessary. Is the frame layout different? I thought the FrameDescriptor is more or less just a declaration of what goes where, and that should be identical for inlined functions as well, no?
>
>> 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?
>
> Well, there were a couple of phases, that are different from my work on TruffleSOM.
> RPython is different enough from Python so that it took some work to get the interpreter running. There are a couple of things the type inference requires help with for instance lambdas need to be put in a scope static enough to be analyzable, and a stricter language for instance tuples and lists are not exchangeable, and another set of libraries. So some minor functionality such as reading from the REPL had to be implemented differently.
>
> For that, the RPython error messages were useful ‘enough’, but I also got a hand from a colleague who has been using RPython for a while, and had been involved with SOM before.
>
> After that was done, I worked a bit on the object model of SOM. Especially in areas that were useful for TruffleSOM as well. So, actually, I changed the language a bit and hid more implementation details of the object layout behind methods (primitives) instead of representing them by fields in the objects.
>
> The third phase was then to add RPythons annotations throughout the code in order to communicate to the tracer what is constant, what is not going to change in the context of a trace, where to look for trace starts etc. And here, I actually got a hand from one of the core RPython guys, who had a look at the code and did the collect all the low hanging fruit.
> Looking at his changes, many of them I could have done based on good document, and guidelines, I think. But some of them are experience I would say.
>
> If you are curious for the details, have a look at:
>   https://github.com/SOM-st/RPySOM/commits/non-recursive-with-jumps
>
> The changes by Carl Friedrich Bolz (cfbolz) around October 21st are probably most interesting for the performance.
>
> As a current result, the last time I measured, DeltaBlue wasn’t to far off from the PyPy numbers anymore.
> And at the moment, we expect to still get a little more out of RPySOM.
> I made the interpreter recursive, similar to the basic execution model in Truffle, which should give the tracer some more context. But currently we are hitting some problems, because that approach requires at least two general points for trace starts. One in the interpreter loop, and one in the loop primitives. However, that’s something not commonly used in other RPython languages, and it seems to be broken. So, for very recursive programs it doesn’t work that well, while benchmarks with loops benefit from this change a lot.
>
> Best regards
> 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
>