3 ms·

> Python is provably slower than C/C++ Eh. Is it though? For all possible operations? Are you sure? Which implementation are you using? CPython? PyPy? Are you

> Python is provably slower than C/C++ Eh. Is it though? For all possible operations? Are you sure? Which implementation are you using? CPython? PyPy? Are you comparing the exact same algorithms implemented in both languages? Modern CPUs are pretty good at executing bytecode-based languages, as there's usually a main loop that fits in cache. A C program can jump all over the place and easily blow caches. It's also easy to access memory in ways that are suboptimal. Because of the difficulty of managing memory, C code tends to free stuff way too quickly. GC languages have an advantage there, as they don't necessarily reclaim the memory immediately, saving malloc/free cycles (at the cost of RAM usage). That's even more of a problem for C++. Once you have profiled your Python program and found out that there isn't anything else you can do to run faster – including changing your algorithm (something that's easier to do in Python), then you can start thinking about rewriting the section in C on ASM.

kazinator 4y ago
> Which implementation are you using The only one in which all documented (and not) Python stuff works, and all Python packages can be used? There is only one Python for practical purposes. > Modern CPUs are pretty good at executing bytecode-based languages, as there's usually a main loop that fits in cache. When everything fits in the cache, bytecode loses most. The more you saddle code with uncached memory accesses, the less it matters whether it's bytecode or machine code. This is just Amdahl's Law. The best performing Python code will be that which spends very few cycles in any byte code loop, and just lets the C routines in Python do all the work. The interesting possiblity is that a bytecode program (and it's interpreter) together fit into the instruction and data cache. Whereas the equivalent machine code program blows the instruction cache. I'm not sure that this scenario is possible with Python in such a way that it actually makes it faster.
drunkenmagician 4y ago
Yes, there are numerous micro benchmarks that demonstrate this. Python has improved in speed, but outside specific uses cases where a C based library performs the bulk of the computational lift, it certainly lags behind. This despite some much duplicate effort to create JIT compilers and performance tuned runtimes.

kazinator 4y ago

> Which implementation are you using The only one in which all documented (and not) Python stuff works, and all Python packages can be used? There is only one Python for practical purposes. > Modern CPUs are pretty good at executing bytecode-based languages, as there's usually a main loop that fits in cache. When everything fits in the cache, bytecode loses most. The more you saddle code with uncached memory accesses, the less it matters whether it's bytecode or machine code. This is just Amdahl's Law. The best performing Python code will be that which spends very few cycles in any byte code loop, and just lets the C routines in Python do all the work. The interesting possiblity is that a bytecode program (and it's interpreter) together fit into the instruction and data cache. Whereas the equivalent machine code program blows the instruction cache. I'm not sure that this scenario is possible with Python in such a way that it actually makes it faster.

drunkenmagician 4y ago

Yes, there are numerous micro benchmarks that demonstrate this. Python has improved in speed, but outside specific uses cases where a C based library performs the bulk of the computational lift, it certainly lags behind. This despite some much duplicate effort to create JIT compilers and performance tuned runtimes.