81–90 of 119 posts
FYI: pypy3 is 10x faster than CPython on this benchmark. ~> python fib.py 4825.7598876953125 ms ~> pypy3 fib.py 514.7459506988525 ms
Numba version: @numba.jit def fib(n): if n == 1 or n == 0: return 1 return fib(n - 1) + fib(n - 2) first run: 498.46601486206055 ms. second run: 89.19310569763184 ms. For completeness, with njit: @numba.njit def fib(n): if n == 1 or n == 0: return 1 return fib(n - 1) + fib(n - 2) first run: 152.62889862060547 ms second run: 86.35592460632324 ms
from numba import jit
@jit
def fib(n: int) -> int: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 i…
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.
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 i…
I think it's notable that the gap between dominant scripting languages for simple function-call bound code has become quite large.
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
#include
#include
#include
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 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 i…
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 for…
Earlier quoted context omitted.
Numba version: @numba.jit def fib(n): if n == 1 or n == 0: return 1 return fib(n - 1) + fib(n - 2) first run: 498.46601486206055 ms. second run: 89.19310569763184 ms. For completeness, with njit: @numba.njit def fib(n): if n == 1 or n == 0: return 1 return fib(n - 1) + fib(n - 2) first run: 152.62889862060547 ms second run: 86.35592460632324 ms
Weird. On Mac I get 282 ms from pypy3, but 233 ms from numba. from numba import jit @jit def fib(n: int) -> int:
Earlier quoted context omitted.
Seems like an unduly harsh take. Is everyone just supposed to inherently know this fact about cpython or find it unsurprising when they run across it? "Obviously this isn't the most comprehensive benchmark, but the results are surprising to me." I fully agree with this and I learned something new about cpython's weakpoints today!
Oh, I think it is a quite reasonable comment. It isn't interesting work being done in the benchmark and the benchmark itself is short. If you want to get ultimate performance from Python then write a C function... If you want to inform me about runtime performance then show me how the language runtimes are spending cycles. If you wish to convince me about a language being great then tell me about the engineering effo…
Compare languages on performance is weird. Every language is made with another philosophy. Python isnt made for performance, but for good code readability. Write clear, logical code for small and large-scale projects. It is also made by Guido to build applications in less time. Guido knows his language isnt the fastest, but thas wasnt the goal with Python. Node.js is also made for other applications than Python. It's…
Knowing that the most prevalent implementation of one is significantly faster than the most prevalent implementation of the other is useful information for someone deciding between the two for a project where performance is important.
Comparing alternative implementations of the languages, which are geared toward performance, would also be valuable. But simply knowing that, if your choice to use CPython is more-or-less arbitrary, you're leaving performance on the table, is valuable.
(Of course, as discussed in the top-level thread by @SuchAnonMuchWow, this particular benchmark seems to be comparing apples to oranges, and thus may not be of much value.)