[Python-Dev] FAT Python (lack of) performance

[Brett Cannon]

On Wed, 27 Jan 2016 at 10:12 Sven R. Kunze <srkunze at mail.de> wrote:

> On 27.01.2016 11:59, Terry Reedy wrote:
>
> On 1/26/2016 12:35 PM, Sven R. Kunze wrote:
>
> I completely agree with INADA.
>
>
> I an not sure you do.
>
>
> I am sure I am. He wants to solve a problem the way that is natural to him
> as a unique human being.
>
>
> It's like saying, because a specific crossroad features a higher
> accident rate, *people need to change their driving behavior*.
> *No!* People won't change and it's not necessary either. The crossroad
> needs to be changed to be safer.
>
>
> Safer crossroads tend to be slower unless one switched to alternate
> designs that eliminate crossing streams of traffic.
>
>
> So Python can be safer AND faster ( = different design) if we try hard
> enough.
>
>
> Languages that don't have integers but use residue classes (with
> wraparound) or finite integer classes (with overflow) as a (faster)
> substitute have, in practice, lots of accidents (bugs) when used by
> non-experts.  Guido noticed this, gave up on changing coder behavior, and
> put the expert behavior of checking for wraparound/overflow and switching
> to real integers (longs) into the language.  (I forget when this was
> added.)
>
>
> I am glad he did because it helps humans solve their problems in a natural
> way without artificial boundaries. :)
>
>
> The purpose of the artificially low input to fib() is to hide and avoid
> the bugginess of most languages.  The analogous trick with testing
> crossroads would be to artificially restrict the density of cars to mask
> the accident-proneness of a 'fast, consenting-adults' crossroads with no
> stop signs and no stop lights.
>
>
> I am completely with you here, however I disagree about suspected
> hiding/avoiding mentality. You say:
>
> Python -> *no problem with big integers but slow at small integers*
> Other Language -> *faster but breaks at big integers*
>
> Yes. That's it.
>
> We haven't solved the human side, however. A human AGAIN would need to
> compromise on either speed or safety.
>
>
> My point is: it would be insanely great if Python could be more like "*fast
> AND no problem with big integers*". No compromise here (at least no
> noticeable).
>

And this is why this entire email thread has devolved into a conversation
that isn't really going anywhere. This whole thread has completely lost
track of the point of Victor's earlier email saying "I'm still working on
my FAT work and don't take any notice of the performance numbers until more
stuff gets finished". And this discussion of what benchmarks to care about
is rather pointless since the core team has an implicit understanding that
any performance improvement is taken into consideration in terms of
balancing complexity in CPython with how much improvement it gets us. So if
someone wants to speed up Fibonacci then they are welcome to try, but the
solution must be maintainable in proportion to the speed increase it buys
Python as a whole.

-Brett




>
> So, people could entirely *concentrate on their problem domain* without
> every worrying about such tiny little, nitty-gritty computer science
> details. I love computer science but people of other domains don't have the
> time nor the knowledge to decide properly. That's the reason why they might
> decide by using some weird micro-benchmarks. Just humans.
>
>
> Same goes for Python. If it's slow using the very same piece of code
> (even superficially), you better make the language faster.
> Developers won't change and they won't change their code either. Just
> not necessary.
>
>
> Instead of making people rewrite fib to dramatically increase speed, we
> added the lru-cache decorator to get most of the benefit without a
> rewrite.  But Inada rejected this Python speedup.  An ast optimizer could
> potentially do the same speedup without the explicit decorator. (No
> side-effects?  Multiple recursive calls?  Add a cache!)
>
>
> Bingo! That's the spirit.
>
> Why that decorator in the first place? Hey, I mean, if I ever want to
> write some cryptic-looking source code with 3-letters abbreviations (LRU),
> I use Assembler again. But I discovered and love Python and I never want to
> go back when my problem domain does not require me to. So, when a machine
> can detect such an optimization, hell, do it, please. It's more likely that
> I apply it at the wrong function AND only in 10% of the correct cases:
> missing 90% and introducing some wild errors.
>
> Again human stuff.
>
>
> Btw. it would be a great feature for Python 3 to be faster than Python
> 2.
>
>
> We all agree on that.  One way for this to happen is to add optimizers
> that would make Python 'cheat' on micrebenchmarks
>
>
> Then, we are all set. :)
>
> Best,
> Sven
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160127/c6f09bb8/attachment.html>