Hello Christian and pypy team ;-) At 17:16 2005-09-15 +0200, you (Christian Tismer) wrote: >Martijn Faassen wrote: > >>Christian Tismer wrote: >>[snip] >> >>>That's the point. Not prioritizing speed is fine, but it >>>does not allow us to be remarkably slower. Being of competitive >>>speed and then more flexible is a must. If we are slower, the >>>market will not consider us at all. >> >>That's true, and that's a useful clarification. It's still different from the >>impression you're giving out, where you're strongly implying at least to me >>that speed will be significantly *faster* eventually with PyPy. Then again, >>it's forgivable that some hype is used to attract interest to the project. > >I thik I'm the worst speed junkie in the project, and I'm holding >my breath a little until I'm convinced that we can be fast. >ATM I'm quite vague about that, because of the complexity of >crucial parts of our system, and the fact that I don't understand >how we are going to translate that into speedy code without >very high level optimization techniques. I simply can't tell >whether we can reach this without major hand-rewriting or whether >we can gather the missing speed factor by applying JIT technology. >I always thought that the initial big step of creating an initial >binary of reasonable speed would be an easy, first step. > >But it turned out to be a huge step which is by far not in the shape >it should be. This amount of my misestimation makes me nervous and >stops me from praising PyPy's speed all too loudly. > >On the other hand, we have extremely efficient results on the low >level side. RPython programs have been shown to become possibly >very fast. This is an area where I have no doubt making promises, >and that's why I proposed to put some more effort there and at least >provide a tool to produce fast extension modules from RPython, soon. >This is also the reason why I want to make RPython more complete >and easier to use. > >For sure we never have put any hype onto PyPy just to make it more >attractive. We learned that flexibility and speed are not trivial >to marry, and we have proven our claims about flexibility, but >unfortunately not yet on speed. I would really hate to retract >this claim. ATM, there is simply no prognosis possible.
Well, keep the faith ;-) A couple of comments: 1) ISTM that "speed" needs to be split at least into speed of translation and speed of the resulting code/interpreter pair, though interactively one experiences the combined effect. (BTW, by that '/' I mean to highlight the fact that output code could be raw machine code packaged for OS linking/loading and where the "interpreter" is a CPU, vs. byte code for a VM such as found in cpython or jython etc. Also it could be pointed out that the target pair could eventually be on another platform entirely, such as a cell phone or game device, or I suppose a vending machine control system etc.) 1a) Re speed of translation: I note that translation has multiple phases/passes, so I wonder if this would be amenable to pipelining, so as to be able to take automatic advantage of multiple processors, either in the same box, or cooperating via fast network links if there were command line options for such delegation? Could one pickle state and pass it on to the next phase? Could you factor the passes as separate programs to connect in a unix-os-level pipeline? In which case I guess parallel make utilities could possibly come into play. Just thoughts... 1b) (1a) Brings the thought that the same interpreter will have a lot of unused baggage for any particular use, if it is a monolith. Which again brings up the translation-time/platform vs run-time/platform distinctions. I.e. space may be as important as speed in the target run-time environment, but I may be willing to crunch overnight translating on a cluster to make something that will fit and run acceptably on the target platform. BTW, is the issue of ROM-ability entirely low-level, or is it some kind of concern higher up? 1c) Will the different components of an interpreter be directable to dlls/sos and be able to load lazily/be-excluded-if-not-needed/whatever e.g. for good interactive startup, but also be configurable to load monolithically? IWT this is make-file stuff, but a makefile can't select pieces if they were welded together by the way they were developed, so I am wondering how that aspect is happening. 2) ISTM that you guys will be the first to notice what meta-info will be useful to pass into the translator(s) to achieve various results, so I wonder what analogies to e.g., C's "volatile" declaration you may want, and what vehicle you will want for representing and transmitting such information. Pragmas? more -*- cookies -*- ? If you come up with something really good, isn't it likely regular python will adopt it, as well as vice versa? The same goes for language syntax changes that don't hide behind a '#' -- IOW, will you guys wind up with some recommendations for language changes? I don't think you should be burdened with writing PEPs and haggling about syntactic sugar, but IWT you guys will discover optimization obstacles that no one else is in a position to see (or maybe even comprehend ;-), but that you could communicate by saying, "If we had a way to say this about such-and-so in python, we could optimize such-and-so much better" and that could help the language evolve in a win-win way. Is there a way to get a peek into your ongoing thoughts without asking you to hang all your unfinished paintings in the window when you go home from the studio each night? 2a) ISTM there will need to be module-specific meta-info, not just -O or -OO etc command line options. And since module translation occurs primarily at import time, there is the opportunity to pass dynamically determined meta-info to the import process as well, not just letting it see meta-info embedded in the source file or refer to interpreter startup command line parameter info. (I guess you could also package meta-info in various config files, or consolidate such info in one file for members of a package, etc. but I wonder if it's not dangerous to go further down the path of tangling abstract hierarchies with platform specific file system properties). So I'm wondering, if you see useful mods/variations to the semantics of import, or other python aspects, how would such ideas get back to python, so the appropriate language PEPs can get under way (though not prematurely) ? 3) I'm wondering how much of pypy translation technology could be factored out to apply to any language translation, and whether there could be a family of porting tool spinoffs eventually. I guess I rambled, as usual ;-) Anyhow, I am sure EU pypy funding is well spent. I hope they will renew their commitment when the time comes. Best wishes to you all. Regards, Bengt Richter _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
