Dear Armin, thank you for your reply! I was not aware of the distinction between virtuals and virtualizables. It's a good start to have that covered ;) I thought marking frame objects as virtualizables was a necessary input for the optimizer, because it cannot decide everything on its own. Since you are calling virtualizables a hack, it seems the optimizer SHOULD be able to handle frame objects without additional hints. Could you explain why it is not able to do so?
My original question was referring to virtuals, but I thought that frame objects were part of that. Now that I know of the distinction, I would like to understand both concepts in detail, and how they interact. I'm not sure how much of this I can ask you to describe to me - probably I should just read and debug the according code? Any suggestions? The motivation for this exercise is that the Spy VM is producing JIT traces that I (we) did not understand. For example, changes in the VM that seemed totally unrelated, were breaking the "virtualizablility" of frame objects (or parts of them), like by setting the program counter on each loop execution (inside the trace!). I'm not sure if this was unwanted behavior on behalf of the optimizer, but it seemed pretty non-deterministic, and I would like to understand the mechanism well enough to troubleshoot and optimize these traces. Best, Anton 2014-04-26 9:10 GMT+02:00 Armin Rigo <[email protected]>: > Hi Anton, > > On 24 April 2014 12:38, Anton Gulenko > <[email protected]> wrote: > > appreciate your input. I want to collect details about the underlying > > concept, and also about the specific implementation in the RPython JIT. > For > > example, was this concept first introduced in Pypy, or is it an older > idea? > > How exactly does the optimizer decide which objects can be virtualized, > and > > which can not? > > We first need to clarify some details. Are you talking about > "virtualizables", or "virtuals"? These are two very different > concepts. The latter is a very strong form of escape analysis, and > probably the single most efficient concept we have in the RPython JIT. > The former, on the other hand, is more of a hack that was added at > some point in time, and that we're trying to remove --- unsuccessfully > so far, because it gives slighty better results than virtuals only, > for the specific use case where it works. > > I'm unsure which one you're talking about: only the frame object is a > "virtualizable", and it's not the job of the optimizer to decide that; > it's explicitly marked in the jitdriver. See > https://pypy.readthedocs.org/en/latest/jit/virtualizable.html . On > the other hand, if you're talking about "virtuals", then indeed we > have code in the optimizer to handle them. It's some kind of escape > analysis leading to allocation removal. > > > A bientôt, > > Armin. >
_______________________________________________ pypy-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-dev
