[Python-Dev] FAT Python (lack of) performance
Sven R. Kunze
srkunze at mail.de
Wed Jan 27 13:11:27 EST 2016
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).
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160127/7b44e792/attachment.html>
More information about the Python-Dev
mailing list