[Python-Dev] FAT Python (lack of) performance (original) (raw)
Chris Angelico rosuav at gmail.com
Mon Jan 25 22:59:36 EST 2016
- Previous message (by thread): [Python-Dev] FAT Python (lack of) performance
- Next message (by thread): [Python-Dev] FAT Python (lack of) performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 26, 2016 at 2:32 PM, INADA Naoki <songofacandy at gmail.com> wrote:
I know. But people compares language speed by simple microbench like fibbonacci. They doesn't use listcomp or libraries to compare language speed.
Well, that's a stupid way to decide on a language. Here, look: Python is faster than C. Proof!
rosuav at sikorsky:~$ time python3 fib.py 2880067194370816120
real 0m0.033s user 0m0.032s sys 0m0.000s rosuav at sikorsky:~$ cat fib.py import functools
@functools.lru_cache() def fib(n): if n < 2: return n return fib(n-2) + fib(n-1)
print(fib(90))
rosuav at sikorsky:~$ gcc fib.c && time ./a.out 1134903170
real 0m9.104s user 0m9.064s sys 0m0.000s rosuav at sikorsky:~$ cat fib.c #include <stdio.h>
unsigned long fib(unsigned long n) { if (n < 2) return n; return fib(n-2) + fib(n-1); }
int main() { printf("%lu\n",fib(45)); }
Algorithmic differences - even subtle ones - can easily outdo choice of language for run-time performance. And if you try to write a true C equivalent of that Python code, good luck - I'll have the Python one written and running while you're still trying to figure out how to write a cache, much less how to keep the syntax clean as you add a cache to an existing function.
Of course, rewriting the whole thing to work iteratively instead of double-recursively will make a dramatic difference to both programs. That's an unsubtle algorithmic difference, and if you're coding like that, you probably can't see the difference in performance between any two languages at anything up to a machine word (about the 90th or so Fibonacci number, on a 64-bit system) - all you'll see is the startup performance. As soon as you go beyond a machine word, Python massively trumps C, because its default integer type is a bignum. Going beyond a machine word in C is a hassle. Going beyond a machine word in Python 2 is almost insignificant - hey look, now your repr has an 'L' on the end, and performance is immeasurably worse. In Python 3, there's no machine word whatsoever.
So, yeah... Python beats C for Fibonacci calculation, too. You just have to not be stupid with your benchmarking.
ChrisA
- Previous message (by thread): [Python-Dev] FAT Python (lack of) performance
- Next message (by thread): [Python-Dev] FAT Python (lack of) performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]