[Python-ideas] Python-ideas Digest, Vol 90, Issue 30

[dw+python-ideas at hmmz.org]

On Wed, May 21, 2014 at 07:04:58PM -0400, Ned Batchelder wrote:

> I can't think of something that has gone wrong because there was a
> switch to turn it off.

> I'm not sure what can of worms you are imagining.  Let's look to our
> experience with C compilers.  They have a switch to disable optimization.
> What trouble has that brought?

Are you serious? Somehow I'm reminded of the funroll-loops.info Gentoo
parody site. As others mention, there is a difficult to quantify, but
very real non-zero cost in introducing new major execution modes.


> When I think of problems with optimizers in C compilers, I think of
> incorrect or buggy optimizations.

Sure, it if were still the early 90s. Most optimization bugs come from
inexperienced developers relying on undefined behaviour of one form or
another, and Python doesn't suffer from UB quite the way C does.


> People in this thread have contrasted this proposal with an apparent desire
> to expand the set of optimizations performed.  It seems to me that the
> complexity and danger lie in expanded optimizations, not disabled ones.

Agreed, and so I'd suggest a better fix would be removing the peephole
optimizer, for the little benefit that it offers, if it could be shown
that it really truly does hinder peoples' comprehension of Python.

It seems the proposed feature is all about avoiding saying "oh, don't
worry about that for the moment" while teaching, assuming the question
comes up at all.

Adding another special case to disable a minor performance improvement
seems pointless when the implementation is slow regardless, kind of
along the same lines as adding another -O or -OO flag, and we all know
how useful they ended up being.

If there really was a problem here, it seems preferable to just remove
the optimizer entirely and find more general ways to fix performance
without creating a mess.


David