Hi Terry, On Wed, Jan 20, 2010 at 5:14 PM, Terry Reedy <tjre...@udel.edu> wrote: > Some comments from a non-developer: > > The proposal to add this to 3.x seems a bit premature until you have a > version that runs with 3.x. Not that I expect that to be a problem though. > If CPython development moves to distributed hg, the notion of 'blessed' > branches (other than the PSF release branch) will, as I understand it, > become somewhat obsolete. If you make a branch publicly available, anyone > can grab it and merge it with their branch, just as they can with anyone > elses.
Beyond inclusion in the mainline CPython source tree, we are also interested in gauging python-dev's level of interest in an LLVM-based JIT. While anyone can currently grab our source (as some companies already have), we don't want to waste our time fixing the remaining issues if python-dev is not interested in incorporating an LLVM-based JIT into the mainline roadmap. > 3.x add optional type annotations. It seems to me that a 3.x proposal should > make use of those. PEP 3107 explicitly rejected having Python-the-language decide on any semantics for function annotations, as the exact nature of those semantics were sure to be controversial. Reversing that decision is a separate issue requiring a separate PEP and input from the other implementations, I think, and in any case, would be an optimization within the wider JIT framework. > All the info being collected for every byte code execution *must* take extra > time, which will slow down certain types of programs. That is correct. For example, it slows down startup, but for most applications, you make up the difference (and more!) once the JIT-compiled functions kick in. We have ideas for addressing the degradation for short-lived programs, and one of our developers is actively working on this area. > Given the slight benefits compared to the costs, I think this, in its > current state, should be optional, such as is psyco. > > Psyco has a similar time-space tradeoff, except that the benefit is much > greater (10x+ has been reported by happy users) for certain types of code > (lots of integer arithmethic, which psyco unboxes). Why should your changes > be blessed and psyco not? While now 2.x only, like UnSw, there are > apparently people working on a 3.x version. Pysco makes its tradeoffs > voluntary, and easy to switch on and off where the benefits are worth the > cost to the particular user. I do not think that standard CPython should be > made incompatible with a module that greatly benefits certain users who have > been using it for years. We considered extending Psyco when we began the project, but found it to be an unsuitable baseline for a number of reasons: - Psyco is 32-bit x86 only (as the Psyco website now prominently notes), making it unsuitable for 64-bit environments like Google. The module's primary maintainer, Christian Tismer, has publicly indicated that he has no interest in porting Psyco to work on 64-bit systems. - Psyco is a tremendously complicated system with no test suite to verify that it is working correctly. The core development team is very small (I believe it is solely Christian Tismer), and other people who have tried to modify Psyco have found it not worth their time (myself, Jeffrey Yasskin, Raymond Hettinger). Jeffrey and I originally intended to make Psyco compatible with Unladen Swallow, but the overhead of doing so distracted from our main goal. - While Psyco provides large benefits to numerical workloads, the benefits to other systems we have at Google are much, much smaller, in the 15-30% range. Do you have pointers to the in-development Python 3 version of Psyco you mentioned? Google doesn't find any such a project, except for forum comments that it doesn't exist. > Your results suggest that speeding up garden-variety Python code is harder > than it sometimes seems. I wonder how your results from fancy codework > compare, for instance, with simply making built-in names reserved, so that, > for instance, len = <whatever> is illegal, and all such names get > dereferenced at compile time. Yes, if you change the language, certain optimizations become simpler or some code becomes faster. However, changing the language in subtle ways -- like changing when builtins are bound -- increases the barrier to adoption, which is why we chose to implement the language as specified. Auditing Google's entire Python codebase to correct for these subtle changes would be prohibitive, as would the need to retrain all our engineers who use Python to educate them on the differences between the two languages. > Increasing startup time on a hot new machine from .2 to .3 sec may not be a > big deal, but increases from 2 to 3 secs on an older machine will be for > short scripts that execute in 2 secs anyway. Agreed. We are actively working to improve the startup time penalty. We're interested in getting guidance from the CPython community as to what kind of a startup slow down would be sufficient in exchange for greater runtime performance. > I guess what I am mainly saying is that there are several possible ways to > speed up Python 3 execution (including others not mentioned here) and it is > not at all clear to me that this particular one is in any sense 'best of > breed'. If it disables other approaches, I think it should be optional for > the standard PSF distribution. We considered the three approaches you mentioned (Psyco, changing the language, using function annotations), but found them unworkable or inapplicable to Google's needs. Adding a just-in-time compiler to Python 2.6 while designing our changes for ease of portability to Python 3 made more sense for our environment, and we believe, is more applicable to the environments of other Python consumers and better-suited to the future roadmap of CPython. Thanks, Collin Winter _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
