On Tue, Feb 15, 2011 at 09:10, Antonio Cuni <[email protected]> wrote: > On 15/02/11 03:41, Dima Tisnek wrote: >> On a related note, how hard is it to "freeze" the translator/compiler >> state of a given pypy version just before it begins to read extension >> modules and distribute that, it would speed up module development a >> lot. >> It would be a quick equivalent of distributing headers for a C library. > > this is hard, because the compilation of the modules is intermixed with the > compilation of the rest of the interpreter for each phase: we have (roughly) > something like: > > - annotation of the interpreter > - annotation of the modules > - rtyping of the interpreter > - rtyping of the modules > - etc. etc.
Thanks for explaining the problem. IIRC, rtyping is a global analysis because for performance you perform type inference globally, so that for instance if a module allows inferring that a field is a number, that information is propagated to the original definition. Depending on what Maciej meant, his proposal might be as hard: > [Separate loading] This would mean you still compile the whole interpreter, > but you can load the module from a compiled PyPy that didn't have this option > on. At least as far as I understand, if "interpreter" means just the interpreter "core", as in Antonio's mail, this seems just as hard. Otherwise, if "interpreter" includes modules, this extension would not accomodate the needs of authors of external modules: one would have download all external modules and compile them together, but at runtime one could save the RAM footprint of external modules. Is that the relevant problem? Cheers, -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
