2 ms·

> 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 exp

by 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.

by msla 9y ago

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.