Fw: [Python-3000] Premature optimization and all that
Over lunch with Neal we came upon the topic of optimization and Python
Hi PyPy'rs! I'm sure you will have already seen this email, but I thought it was quite interesting, as it may mean that Python 3000 is where PyPy can become faster than CPython! Given a years development time at the current rate of progress. I think PyPy is about 2.5 times slower than CPython at the moment isn't it? Cheers, Ben ----- Forwarded by Ben Young/Infinity on 30/08/2006 08:43 ----- python-3000-bounces+python=theyoungfamily.co.uk@python.org wrote on 29/08/2006 22:51:17: 3000.
It is our strong opinion that in this stage of the Py3k project we should focus on getting the new language spec and implementation feature-complete, without worrying much about optimizations.
We're doing major feature-level surgery, e.g. int/long unification, str/unicode unification, range/xrange unification, keys() views, and many others. Keeping everything working is hard work in and of itself; having to keep it as fast as it was through all the transformations just makes it that much harder.
if Python 3.0 alpha 1 is twice as slow as 2.5, that's okay with me; we will have another year to do performance measurements and add new optimizations in the ramp-up for 3.0 final. Even if 3.0 final is a bit slower than 2.5 it doesn't bother me too much; we can continue the tweaks during the 3.1 and 3.2 development cycle.
Note: I'm note advicating wholesale proactive *removal* of optimizations. However, I'm allowing new features to slow down performance temporarily while we get all the features in place. I expect that the optimization possibilities and needs will be different than for 2.x, since some of the fundamental data types will be so different.
In particular, I hope that Martin's int/long unification code can land ASAP; it's much better to have this feature landed in the p3yk branch, where everyone can bang on it easily, and learn how this affects user code, even if it makes everything twice as slow. This seems much preferable over having it languish in a separate branch until it's perfect.
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python. org/mailman/options/python-3000/python%40theyoungfamily.co.uk
participants (1)
-
Ben.Young@risk.sungard.com