RetroSearch Browse

Tue Aug 30 09:58:42 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-August/113338.html

On Tue, Aug 30, 2011 at 4:22 PM, Eli Bendersky <eliben at gmail.com> wrote:
> On Tue, Aug 30, 2011 at 08:57, Greg Ewing <greg.ewing at canterbury.ac.nz>
> wrote:
> Following this argument to the extreme, the bytecode evaluation code of
> CPython can be simplified quite a bit. Lose 2x performance but gain a lot of
> readability. Does that sound like a good deal? I don't intend to sound
> sarcastic, just show that IMHO this argument isn't a good one. I think that
> even clever optimized code can be properly written and *documented* to make
> the task of understanding it feasible. Personally, I'd love CPython to be a
> bit faster and see no reason to give up optimization opportunities for the
> sake of code readability.

Yeah, it's definitely a trade-off - the point I was trying to make is
that there *is* a trade-off being made between complexity and speed.

I think the computed-gotos stuff struck a nice balance - the macro-fu
involved means that you can still understand what the main eval loop
is *doing*, even if you don't know exactly what's hidden behind the
target macros. Ditto for the older opcode prediction feature and the
peephole optimiser - separation of concerns means that you can
understand the overall flow of events without needing to understand
every little detail.

This is where the request to extract individual orthogonal changes and
submit separate patches comes from - it makes it clear that the
independent changes *can* be separated cleanly, and aren't a giant
ball of incomprehensible mud. It's the difference between complex
(lots of moving parts, that can each be understood on their own and
are then composed into a meaningful whole) and complicated (massive
patches that don't work at all if any one component is delayed)

Eugene Toder's AST optimiser work that I still hope to get into 3.3
will have to undergo a similar process - the current patch covers a
bit too much ground and needs to be broken up into smaller steps
before we can seriously consider pushing it into the core.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

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

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

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