[Python-Dev] Python 3 optimizations continued...
stefan brunthaler
stefan at brunthaler.net
Tue Aug 30 02:25:21 CEST 2011
> Personally, I *like* CPython fitting into the "simple-and-portable"
> niche in the Python interpreter space. Armin Rigo made the judgment
> years ago that CPython was a poor platform for serious optimisation
> when he stopped working on Psyco and started PyPy instead, and I think
> the contrasting fates of PyPy and Unladen Swallow have borne out that
> opinion. Significantly increasing the complexity of CPython for
> speed-ups that are dwarfed by those available through PyPy seems like
> a poor trade-off to me.
>
I agree with the trade-off, but the nice thing is that CPython's
interpreter remains simple and portable using my optimizations. All of
these optimizations are purely interpretative and the complexity of
CPython is not affected much. (For example, I have an inline-cached
version of BINARY_ADD that is called INCA_FLOAT_ADD [INCA being my
abbreviation for INline CAching]; you don't actually have to look at
its source code, since it is generated by my code generator but can by
looking at instruction traces immediately tell what's going on.) So,
the interpreter remains fully portable and any compatibility issues
with C modules should not occur either.
> At a bare minimum, I don't think any significant changes should be
> made under the "it will be faster" justification until the bulk of the
> real-world benchmark suite used for speed.pypy.org is available for
> Python 3. (Wasn't there a GSoC project about that?)
>
Having more tests would surely be helpful, as already said, the most
real-world stuff I can do is Martin's django patch (some of the other
benchmarks though are from the shootout and I can [and did] run them,
too {binarytrees, fannkuch, fasta, mandelbrot, nbody and
spectralnorm}. I have also the AI benchmark from Unladden Swallow but
no current figures.)
Best,
--stefan
More information about the Python-Dev
mailing list