3 ms·

Ignoring the bad implementation of fib(n) and use of a Python interpreter without JIT... why does this matter? Python and JavaScript are scripting languages.

Ignoring the bad implementation of fib(n) and use of a Python interpreter without JIT... why does this matter? Python and JavaScript are scripting languages. Their advantages are being highly portable and relatively easy to develop and maintain. Performance has always been a weakness of both languages when compared to their pre-compiled siblings. That limitation is often mitigated by "gluing" together functionality implemented in a more performance-oriented language, but even then nobody chooses a scripting language because they expect it to be faster than the competition. Besides, this is hardly a fair comparison. Many tech giants have competed in the browser space for years by hyper-optimizing their JavaScript engines. Comparing the performance of Node/V8 to that of CPython is like me comparing my strength to that of a child.

brrrrrm 6y ago
I think it's notable that the gap between dominant scripting languages for simple function-call bound code has become quite large.
- CivBase 6y ago
  I do not consider the difference in performance for that particular implementation of that particular function on those particular interpreters to be notable. I don't think it's a fair match-up and I don't think there's much value in comparing the effectiveness of tools for a job they aren't made for. For additional comparison, I quickly I rewrote the function in C (output and code below). The code was comparable in length and complexity (at least the fib(n) implementation was), but the relative performance is enough to make JavaScript blush. If you really wanted to do something as trivial as this, why would you even use pure JavaScript or Python to begin with? And if performance was a concern, why would you choose a reference interpreter like CPython? Output: $ ./fib 35 14930352 68 ms Code: #include <stdio.h> #include <stdlib.h> #include <sys/time.h> int fib(int n) { if (n == 1 || n == 0) return 1; return fib(n - 1) + fib(n - 2); } int main(int argc, char *argv[]) { if (argc < 2) return 1; int x = atoi(argv[1]); struct timeval start, end; gettimeofday(&start, NULL); int n = fib(x); gettimeofday(&end, NULL); printf("%d\n", n); long unsigned int udiff = ( (end.tv_sec - start.tv_sec) * 1000000 + end.tv_usec - start.tv_usec); printf("%lu ms\n", udiff / 1000); return 0; }
GuB-42 6y ago
I think it matters because a lot of people are doing math in python. And if good optimizations can help run a small simulation in 1 minute instead of 2, multiplied by the number of python users, it is a lot of time gained. And I suspect, the fib(n) situation is actually quite common. I mean, not everyone who writes python is a "real" developer, there are a lot of scientists who just want the computer to run their formulas, and they write them it the most straightforward way possible. They won't bother with high performance libraries and optimizing their algorithms just to save a few minutes, but they would appreciate if the language could make things a little faster. And it doesn't matter in the way of "hey look, Python slow, use JS". But it is good information for Python developers and advanced users, the people who non-specialists rely on.
- CivBase 6y ago
  Yeah, but it's like comparing the effectiveness of a shovel vs a spade when it comes to hammering nails. You should obviously use a hammer. If it's not worthwhile to get a hammer, then does it really matter whether you use the shovel or the spade?
  - GuB-42 6y ago
    If a lot of people use a shovel as a hammer, the people making shovels should start considering that use case. The spade manufacturers already did so they could take inspiration. Real life tool manufacturers take "wrong" use into account. One of my preferred anecdote is the IMI Galil assault rifle, which has a built-in bottle opener. It was done because they noticed soldiers used magazines to open bottles, and it could cause damage. Of course, it is not about choosing between a shovel and a spade, people who have a choice will use a hammer. But it doesn't mean we shouldn't do a favor to shovel bearers.
    - CivBase 6y ago
      But what's the implication here if not that people should use JavaScript for better performance? That the Python Software Foundation should invest more in the performance of the reference interpreter, CPython? The Galil magazine example has an obvious, easy-to-implement, low-cost solution with an obvious ROI. If that weren't the case, don't you think IMI would have just cautioned soldiers about potential damage to the magazines and instructed them to use a bottle opener instead?

brrrrrm 6y ago

I think it's notable that the gap between dominant scripting languages for simple function-call bound code has become quite large.

CivBase 6y ago
I do not consider the difference in performance for that particular implementation of that particular function on those particular interpreters to be notable. I don't think it's a fair match-up and I don't think there's much value in comparing the effectiveness of tools for a job they aren't made for. For additional comparison, I quickly I rewrote the function in C (output and code below). The code was comparable in length and complexity (at least the fib(n) implementation was), but the relative performance is enough to make JavaScript blush. If you really wanted to do something as trivial as this, why would you even use pure JavaScript or Python to begin with? And if performance was a concern, why would you choose a reference interpreter like CPython? Output: $ ./fib 35 14930352 68 ms Code: #include <stdio.h> #include <stdlib.h> #include <sys/time.h> int fib(int n) { if (n == 1 || n == 0) return 1; return fib(n - 1) + fib(n - 2); } int main(int argc, char *argv[]) { if (argc < 2) return 1; int x = atoi(argv[1]); struct timeval start, end; gettimeofday(&start, NULL); int n = fib(x); gettimeofday(&end, NULL); printf("%d\n", n); long unsigned int udiff = ( (end.tv_sec - start.tv_sec) * 1000000 + end.tv_usec - start.tv_usec); printf("%lu ms\n", udiff / 1000); return 0; }

GuB-42 6y ago

I think it matters because a lot of people are doing math in python. And if good optimizations can help run a small simulation in 1 minute instead of 2, multiplied by the number of python users, it is a lot of time gained. And I suspect, the fib(n) situation is actually quite common. I mean, not everyone who writes python is a "real" developer, there are a lot of scientists who just want the computer to run their formulas, and they write them it the most straightforward way possible. They won't bother with high performance libraries and optimizing their algorithms just to save a few minutes, but they would appreciate if the language could make things a little faster. And it doesn't matter in the way of "hey look, Python slow, use JS". But it is good information for Python developers and advanced users, the people who non-specialists rely on.

CivBase 6y ago
Yeah, but it's like comparing the effectiveness of a shovel vs a spade when it comes to hammering nails. You should obviously use a hammer. If it's not worthwhile to get a hammer, then does it really matter whether you use the shovel or the spade?
- GuB-42 6y ago
  If a lot of people use a shovel as a hammer, the people making shovels should start considering that use case. The spade manufacturers already did so they could take inspiration. Real life tool manufacturers take "wrong" use into account. One of my preferred anecdote is the IMI Galil assault rifle, which has a built-in bottle opener. It was done because they noticed soldiers used magazines to open bottles, and it could cause damage. Of course, it is not about choosing between a shovel and a spade, people who have a choice will use a hammer. But it doesn't mean we shouldn't do a favor to shovel bearers.
  - CivBase 6y ago
    But what's the implication here if not that people should use JavaScript for better performance? That the Python Software Foundation should invest more in the performance of the reference interpreter, CPython? The Galil magazine example has an obvious, easy-to-implement, low-cost solution with an obvious ROI. If that weren't the case, don't you think IMI would have just cautioned soldiers about potential damage to the magazines and instructed them to use a bottle opener instead?