At 22:40 2003-01-18 -0600, Edward K. Ream wrote:
Hello Armin,
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 called?
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. [snip] Only when a new, not-already-seen type appears does it follow the "uncommon_case" branch. This triggers more compilation, i.e. emission of more 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 on 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 again. 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. Regards, Bengt Richter BTW[OT], sorry about the justification. Now I can't get it back without retyping or writing a re-spacing ragged wrapper.