Movatterモバイル変換
[0]ホーム
[Python-Dev] Psyco requests and patches
Armin Rigoarigo@ulb.ac.be
Wed, 02 Oct 2002 01:33:47 +0200
Hello everybody,As I have been putting more work into Psyco to make sure it will workwell with Python 2.3, I came up with a few support requests.Non-technical stuff first. People tend to think about Psyco as anobscure and complex piece of software for gurus -- should they knowabout it at all. Of course I would argue instead that it is exactly thepiece of software that Python users should not have to worry about,because it should be perfectly transparent. As you can guess I wouldeven say that the first widely-used dynamic programming language tonatively include this kind of techniques would see a huge widening ofits application domain. For Psyco to be a first step in that direction,here are a few goals that I would like you to comment.Publicity: well, I could do with a little more advertising, e.g. onwww.python.org or better yet in the docs and tutorials, at places whereperformance is discussed. Right now I am not sure that you can learnabout Psyco's existence unless you read python-dev or comp.lang.python.Ease of use: currently the psyco.bind() interface is easy to use, but itcould be trivial instead of just easy. It should actually be fullytransparent. (That's what psyco.jit() promised to do, but right now itbadly sucks; keeping it around may have been an error, as people isactually trying it and getting bad results.)Portability: the easy part! Indeed, an empty module named 'psyco'portably provides exactly the same functionality as Psyco everywhere... On non-supported platforms you just get nothing better than the currentinterpreter performance, but nothing worse either. (Besides, emittingportable pseudo-code could still be a future option. Of course,emitting a platform's machine code is not that easy at all, but thisfact doesn't compromise portability.)Ease of maintenance: the hard part. Psyco is not currently ready forthat. The implementation is way too obscure. You have no guarantee ifI tell -- and I do -- that I plan to upgrade Psyco to all newer Pythonversions for at least as long as the 2.x series is alive. We need morethan one person involved. (Note that upgrades are not as time-consumingas, say, in the case of Christian Tismer's first Stacklessimplementation that required a complete rewrite of the interpreter.)Let's defer this point to the bottom of this e-mail.Inclusion in the Standard Library or the interpreter core itself: notright now! This is a guideline for the goals discussed above. I mightbe inclined to think that completion of all the previous goals would beenough for consideration...?-=- Python patches -=-Psyco requires no change in the interpreter core -- however, there are acouple of things that needed obfuscated workarounds or just don'tcompletely work at all. A few minor changes would make it all muchcleaner. I submitted three patches to SF(http://www.python.org/sf/617309,http://www.python.org/sf/617311,http://www.python.org/sf/617312). The patches should be clear enough,not introducing obscure "features" or measurable performance loss. Thediffs are currently against the 2.2 branch -- it would greatly helpPsyco if the patches made their way into Python 2.2.2, which Iunderstood to be the candidate Python-in-a-tie. I will submit 2.3versions of the patches as well, of course.-=- Maintenance of Psyco -=-Psyco is currently highly obscure. I want to rewrite it in Python. Still, however, there will always be the problem that for any featuresupported by Psyco someone must track the changes in the correspondingfeature in the interpreter, and port them. (This doesn't concern thefeatures not supported by Psyco: for these it always calls theirup-to-date C implementation.) This process might be semi-automated witha tool that would be able to dig into C code and analyse it, but thiswould be sort of a hack.We might do some thinking about this synchronization problem when thediscussion about Python 3 is raised again: how hard would it be e.g. towrite some parts of the interpreter directly in Python -- or at least insome specific dialect that can be turned into C (a la Pyrex) for ease ofcompilation? It may actually help make the interpreter moreunderstandable. This looks a bit far-fetched, but I will never give upmy claims that high-level languages are just better than low-level onesfor most purposes, and writing an interpreter is no exception!For example, there was a December 2000 proposal to rewrite the "cmath"module in Python (http://www.python.org/sf/210838). It never actuallymade its way into the Standard library, which is too bad for Psyco,because Psyco-with-cmath-in-Python would be faster thanPsyco-with-cmath-in-C.Practically, the whole point of having a single high-level source codeis that you can do more than just one thing with it. With C code, it isa horrible hack to do anything else than compile and execute it. WithPython code it's a different matter. You can use this single source toproduce both the equivalent C code and to produce Psyco itself. In eachcase there is still an important part written directly in C, of course;I am not (yet;-) suggesting that Python should be written *only* inPython! Very roughly, the separation would be between the built-inobjects + abstract protocols in 'Objects/' (which could be written inPython) and the core in 'Python/' (which could not).The framework required to do such a thing looks complicated. I wouldargue that it probably isn't (and in any case it might be worth beingcarefully considered); this extra complexity might be favorably balancedif only just because writing Python in Python is easier than in C :-)A bientot,ArminPS: I just obtained my math Ph.D. -- it's now Psyco time again!
[8]ページ先頭