[pypy-dev] Fw: [Python-3000] Premature optimization and all that

[Ben.Young at risk.sungard.com]

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 at python.org wrote on 
29/08/2006 22:51:17:

> Over lunch with Neal we came upon the topic of optimization and Python 
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 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.
> org/mailman/options/python-3000/python%40theyoungfamily.co.uk
>