On Wed, Jan 20, 2010 at 5:56 PM, Collin Winter <collinwin...@google.com> wrote: > On Wed, Jan 20, 2010 at 5:14 PM, Terry Reedy <tjre...@udel.edu> wrote: >> 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 think you're right that users should be able to turn off the JIT at runtime (not just configure time), and get pretty close to no slowdown or memory overhead compared to pre-Unladen CPython. We currently have a command-line switch to do just that, but I suspect it doesn't get as close to pre-Unladen performance/memory use as it could. I've filed http://code.google.com/p/unladen-swallow/issues/detail?id=123 to keep track of this. >> 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. Standard CPython is made incompatible with psyco at every release. ;) Someone had to update psyco to support CPython 2.5 and 2.6, and they'll have to update it to support each 3.x as well. I don't think there's anything we've done in Unladen that will make it impossible to update psyco to coexist with it; it's just that psyco turned out to be too complicated for us to keep it working through our bytecode changes. > - 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. I don't think it's just Google workloads that Psyco provides a smaller-than-advertised benefit to. >> 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. Again, this isn't just Google. Do you really want to audit your code and all the libraries you use to make sure they don't depend on late builtin binding? We have considered making language changes like this at some -O level to support people who want every ounce of speed (in the same way that gcc supports a -ffast-math option for people who don't care about floating point accuracy), and we think it'll be a good thing to investigate in the future, but it's not the kind of change I'd want to make to the default language. >> 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. As far as I can tell, it does not disable other approaches. Thanks for the comments! Jeffrey _______________________________________________ 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
