4 ms·

C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decid

C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.

msla 9y ago
> If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++. Better, perhaps, if John Walker's experiences with Javascript are anything to go by: https://www.fourmilab.ch/fbench/fbench.html https://www.fourmilab.ch/fbench/fbench.html John Walker has a program called fbench which is a floating-point benchmark built around raytracing. He's implemented it many times, in many languages, throughout the decades, beginning with implementations for the original IBM PC. Anyway, the results are posted on the site, in terms of multiples of the speed of the C implementation, which is defined to be 1.0. The Python implementation is 2.633 (PyPy 2.2.1 (Python 2.7.3), Linux), and the Javascript implementation is 0.372 (Mozilla Firefox 55.0.2, Linux). Yes, it completes in approximately a third the speed of a C implementation compiled on full optimization (-O3) by GCC 3.2.3. (The C++ implementation is at 0.939, GCC 5.4.0 -O3.) Anyway, Javascript has been the target of a lot of people for a fairly long time, and, despite the fact it's a very dynamic (hard-to-optimize) language... well, the numbers speak for themselves. I have no doubt Python could be improved to a similar degree. Downloads: https://www.fourmilab.ch/fbench/ https://www.fourmilab.ch/fbench/ The weblog post where he analyzes the modern Javascript numbers a bit: https://www.fourmilab.ch/fourmilog/archives/2017-10/001715.html https://www.fourmilab.ch/fourmilog/archives/2017-10/001715.h...
- tigershark 9y ago
  That is only a very specific benchmark and as that post said the result is so strange probably because of the changes in the C trigonometric functions lib that slowed down a lot to increase precision.
  - msla 9y ago
    The point, however, is that if the difference is down to library code, the language itself isn't imposing a penalty. That is what is counter-intuitive here.
    - igouy 9y ago
      What's "counter-intuitive" about that? As-fast-as C when it is C (or Fortran or assembler…)
- kevindqc 9y ago
  Well the link you posted is not very useful - Javascript is faster on a trigonometry benchmark and the author admits it's probably because GCC's trigonometry functions are probably slow and not optimized. If you switch them out to use better functions or use a different compiler, I imagine the time would go down. This is probably a better comparison: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/ Altough it seems to only have been run on node.js for Javascript.
bigcheesegs 9y ago
There's more to it than that. C++ is designed for implementations to produce fast code. "Leave no room between C++ and Assembly" has been a guiding principle of C++. This is not true of Python, and thus the engineering effort required for an implementation to reach the same level of performance is huge, if at all possible.
- sokoloff 9y ago
  I view C and C++ as "portable assembly language". (I happily and productively used C++ for many years; there's no hatred in the above sentiment.)
- jashmatthews 9y ago
  LuaJIT can do it and ZipPy + Graal + JVM should be able to get close enough to make a massive difference to Python performance in the near future.
tigershark 9y ago
No, It’s not possible to optimise Python like c++ because of the characteristics of the language. Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.
- duncan_bayne 9y ago
  Perhaps you should consider this a different way. Consider the end to end performance of a system - from inputs in (say, timesheets and HR data) to outputs out (bank payment APIs called, emails sent). Would you bet the end to end performance of a system built by mediocre C++ programmers would be better than that of a system built by mediocre Python programmers? I certainly wouldn't.
  - duncan_bayne 9y ago
    To elaborate a bit: what I mean is, it is easier to build an acceptably performant system in Python than in C++. Yes, an arbitrary algorithm will probably perform significantly faster in C++. But that probably won't matter in a real-world system built from multiple integrated components, when the performance is more likely to be determined by the abstractions chosen and the system architecture in use. And IMO Python and its surrounding ecosystem makes it easier to make good choices in those areas.
- jashmatthews 9y ago
  > Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be. Pypy etc never had the resources to build a truly amazing Python implementation. With Oracle throwing their weight behind Graal there's now ZipPy: http://thezhangwei.com/documents/oopsla113-zhang.pdf http://thezhangwei.com/documents/oopsla113-zhang.pdf Backwards compatibility with native extensions is the single biggest problem preventing optimising both Python and Ruby. If we could completely throw out C API compatibility like LuaJIT did, then we could make huge improvements to Python and Ruby performance and memory usage.
- collyw 9y ago
  I have been using Python for a while now, and its rarely that the language is too slow (I have encountered it on one problem). A lot of Python is for web programming where you optimize the database and set up caching to improve performance. If you want to do some heavy number crunching Numpy is apparently not far of C in terms of performance. Obviously its a case of the correct tool for the job and depends heavily on the type of software you are writing, but in most cases its a different type of optimization that is needed for Python code.

msla 9y ago

> If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++. Better, perhaps, if John Walker's experiences with Javascript are anything to go by: https://www.fourmilab.ch/fbench/fbench.html https://www.fourmilab.ch/fbench/fbench.html John Walker has a program called fbench which is a floating-point benchmark built around raytracing. He's implemented it many times, in many languages, throughout the decades, beginning with implementations for the original IBM PC. Anyway, the results are posted on the site, in terms of multiples of the speed of the C implementation, which is defined to be 1.0. The Python implementation is 2.633 (PyPy 2.2.1 (Python 2.7.3), Linux), and the Javascript implementation is 0.372 (Mozilla Firefox 55.0.2, Linux). Yes, it completes in approximately a third the speed of a C implementation compiled on full optimization (-O3) by GCC 3.2.3. (The C++ implementation is at 0.939, GCC 5.4.0 -O3.) Anyway, Javascript has been the target of a lot of people for a fairly long time, and, despite the fact it's a very dynamic (hard-to-optimize) language... well, the numbers speak for themselves. I have no doubt Python could be improved to a similar degree. Downloads: https://www.fourmilab.ch/fbench/ https://www.fourmilab.ch/fbench/ The weblog post where he analyzes the modern Javascript numbers a bit: https://www.fourmilab.ch/fourmilog/archives/2017-10/001715.html https://www.fourmilab.ch/fourmilog/archives/2017-10/001715.h...

tigershark 9y ago
That is only a very specific benchmark and as that post said the result is so strange probably because of the changes in the C trigonometric functions lib that slowed down a lot to increase precision.
- msla 9y ago
  The point, however, is that if the difference is down to library code, the language itself isn't imposing a penalty. That is what is counter-intuitive here.
  - igouy 9y ago
    What's "counter-intuitive" about that? As-fast-as C when it is C (or Fortran or assembler…)
kevindqc 9y ago
Well the link you posted is not very useful - Javascript is faster on a trigonometry benchmark and the author admits it's probably because GCC's trigonometry functions are probably slow and not optimized. If you switch them out to use better functions or use a different compiler, I imagine the time would go down. This is probably a better comparison: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/ Altough it seems to only have been run on node.js for Javascript.

bigcheesegs 9y ago

There's more to it than that. C++ is designed for implementations to produce fast code. "Leave no room between C++ and Assembly" has been a guiding principle of C++. This is not true of Python, and thus the engineering effort required for an implementation to reach the same level of performance is huge, if at all possible.

sokoloff 9y ago
I view C and C++ as "portable assembly language". (I happily and productively used C++ for many years; there's no hatred in the above sentiment.)
jashmatthews 9y ago
LuaJIT can do it and ZipPy + Graal + JVM should be able to get close enough to make a massive difference to Python performance in the near future.

tigershark 9y ago

No, It’s not possible to optimise Python like c++ because of the characteristics of the language. Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.

duncan_bayne 9y ago
Perhaps you should consider this a different way. Consider the end to end performance of a system - from inputs in (say, timesheets and HR data) to outputs out (bank payment APIs called, emails sent). Would you bet the end to end performance of a system built by mediocre C++ programmers would be better than that of a system built by mediocre Python programmers? I certainly wouldn't.
- duncan_bayne 9y ago
  To elaborate a bit: what I mean is, it is easier to build an acceptably performant system in Python than in C++. Yes, an arbitrary algorithm will probably perform significantly faster in C++. But that probably won't matter in a real-world system built from multiple integrated components, when the performance is more likely to be determined by the abstractions chosen and the system architecture in use. And IMO Python and its surrounding ecosystem makes it easier to make good choices in those areas.
jashmatthews 9y ago
> Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be. Pypy etc never had the resources to build a truly amazing Python implementation. With Oracle throwing their weight behind Graal there's now ZipPy: http://thezhangwei.com/documents/oopsla113-zhang.pdf http://thezhangwei.com/documents/oopsla113-zhang.pdf Backwards compatibility with native extensions is the single biggest problem preventing optimising both Python and Ruby. If we could completely throw out C API compatibility like LuaJIT did, then we could make huge improvements to Python and Ruby performance and memory usage.
collyw 9y ago
I have been using Python for a while now, and its rarely that the language is too slow (I have encountered it on one problem). A lot of Python is for web programming where you optimize the database and set up caching to improve performance. If you want to do some heavy number crunching Numpy is apparently not far of C in terms of performance. Obviously its a case of the correct tool for the job and depends heavily on the type of software you are writing, but in most cases its a different type of optimization that is needed for Python code.