Home Original page

[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