RetroSearch Browse

Tue Aug 30 10:15:22 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-August/113340.html

Nick Coghlan, 30.08.2011 02:00:
> On Tue, Aug 30, 2011 at 7:14 AM, Antoine Pitrou wrote:
>> On Mon, 29 Aug 2011 11:33:14 -0700 stefan brunthaler wrote:
>>> * The optimized dispatch routine has a changed instruction format
>>> (word-sized instead of bytecodes) that allows for regular instruction
>>> decoding (without the HAS_ARG-check) and inlinind of some objects in
>>> the instruction format on 64bit architectures.
>>
>> Having a word-sized "bytecode" format would probably be acceptable in
>> itself, so if you want to submit a patch for that, go ahead.
>
> Although any such patch should discuss how it compares with Cesare's
> work on wpython.
>
> 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.

If Stefan can cut down his changes into smaller feature chunks, thus making 
their benefit reproducible and verifiable by others, it's well worth 
reconsidering if even a visible increase of complexity isn't worth the 
improved performance, one patch at a time. Even if PyPy's performance tops 
the improvements, it's worth remembering that that's also a very different 
kind of system than CPython, with different resource requirements and a 
different level of maturity, compatibility, portability, etc. There are 
many reasons to continue using CPython, not only in corners, and there are 
many people who would be happy about a faster CPython. Raising the bar has 
its virtues.

That being said, I also second Nick's reference to wpython. If CPython 
grows its byte code size anyway (which, as I understand, is one part of the 
proposed changes), it's worth looking at wpython first, given that it has 
been around and working for a while. The other proposed changes sound like 
at least some of them are independent from this one.

Stefan

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-August/113340.html below:

[Python-Dev] Python 3 optimizations continued...