[pypy-dev] Questions for Armin
bokr at oz.net
Sun Jan 19 08:25:52 CET 2003
At 22:40 2003-01-18 -0600, Edward K. Ream wrote:
>> On Fri, Jan 17, 2003 at 01:08:28PM -0600, Edward K. Ream wrote:
>> > 1. How often and under what circumstances does psyco_compatible get
>> > My _guess_ is that it gets called once per every invocation of every
>> > "psycotic" function (function optimized by psyco). Is this correct?
>> No: psyco_compatible() is only called at compile-time.
>> Only when a new, not-already-seen type appears does it follow the
>> "uncommon_case" branch. This triggers more compilation, i.e. emission of
>> machine code...
>Many thanks for this most interesting and informative reply. It clears up a
>lot of my questions. I feel much more free to focus on the big picture.
>> All your comments about Psyco are founded, but you are focusing too much
>> the "back-end" part...
>Yes. I have been focusing on an "accounting" question: how often does the
>compiler run? If the compiler starts from scratch every time a program is
>run, then I gather from your example that the compiler will be called once
>for every type of very argument for every executed function _every time the
>program runs_. Perhaps you are assuming that the gains from compiling will
>be so large that it doesn't matter how often the compiler runs.
Well, if most everything is written in python, with all the
libraries etc., I think there still is some accounting to
do. I.e., library modules won't change much after having
been exercised a bit. Will this keep updating cached info in
.pyc (or maybe new .pyp) files? (BTW, IWT that makes for
eventual permissions issues, if it's shared libraries. Do
you just get per-use caches, etc.?) IMO there has to be some
way of not rebuilding the world a lot, even if it's fast ;-)
I'm also picking this place to re-introduce the related
"checkpointing" idea, namely some call into a builtin that
can act like a yield and save all the state that the
compiler/psyco etc have worked up. Perhaps some kind of .pyk
for (python checkpoint) file that could resume from where
the checkpoint call was. I believe it can be done if the
interpreter stack(s) is/are able to be encapsulated and a
little restart info can be stored statically and the machine
stack can unwind totally out of main and the C runtime exit,
so that coming back into C main everyting can be picked up
I don't want to belabor it, but just mention it as something
to consider, in case it becomes easy when you are
redesigning the VM and its environment.
Obviously there has to be some restrictions on state, but I
think if we could wind up with fast-load application images
in the future because you kept this in mind in the
beginning, it could be a benefit.
BTW[OT], sorry about the justification. Now I can't get it back
without retyping or writing a re-spacing ragged wrapper.
More information about the Pypy-dev