3 ms·
Isn't adding things like memoization or writing the code in C (Cython) missing the whole point of the benchmark, which is to test the overhead of recursion / fu
by kristofferc 9y ago
Isn't adding things like memoization or writing the code in C (Cython) missing the whole point of the benchmark, which is to test the overhead of recursion / function calls in the language itself?
- knlje 9y agoUsers of programming languages interested in the end result (output of the program etc) do not care. They want the fastest performing language for the job. Julia website has been misleading people. Due to those claims, I spent a week porting some of my simulation code to Julia before I realized that it is actually slower in (optimized) Julia than in optimized Python.
- kristofferc 9y agoFor those who only care about the output of fib(20) there are more efficient methods than any of the Julia or Python implementations posted in the link, e.g. lookup tables. The assumption in benchmarks is of course that the results carry over to other use cases. Here, what is being tested is the overhead in recursion, nothing else. The fact that it happens to be Fibonacci-numbers that is being computed is irrelevant.
- coldtea 9y agoWhy, is anybody restricted to using recursion in their solutions?
- kristofferc 9y agoYou are not restricted to recursion, loops, functions etc, but these language constructs might be useful in situations, and therefore the performance (overhead) of these constructs is interesting.
- Beltiras 9y agoIsn't that basically what he does when he adds caching? I know it's not a static lookup table but you could prep it by invoking it with a sufficiently large n.
- keldaris 9y ago> actually slower in (optimized) Julia than in optimized Python That shouldn't be possible. If you have a code example, I (and probably other people as well) will be happy to look at it.
- jernfrost 9y agoI highly doubt that was optimized Julia code. Sure you might have used a really fast python library and a very slow Julia library, but there is no way optimized Julia code should be slower than Python. Julia simply offers far more ways to control performance than python.
- fmap 9y agoAnd thus we want benchmarks that measure language performance, not the fastest way to compute Fibonacci numbers. The solution to the latter problem is the same in Python and Julia and consists of calling the assembly function in gmp... Julia has a lot more potential for optimizations than python, but what python has going for it is the larger ecosystem. So if you want to write a one-off experiment that's similar to stuff that already exists in C bindings to python you should use that. If you plan to write a large application that you still want to optimize for current processors in 10 years then I'm not sure if python is a good choice.
- coldtea 9y agoIsn't the benchmark missing the whole point of what people actually want to do, which is to run their calculations fast (without caring whether they are written using the constructs the benchmark tests or not)?
- kristofferc 9y agoPeople might want to use recursion. They might want to split out their code into small functions without having to think about the overhead of function calls. They might want to just write a for loop instead of transforming it to vectorized notation. The benchmark investigated in the link answers the question "if I use recursion, and the function body is small, how much will I be penalized?". Changing the benchmark so that it no longer answers that question makes it pointless.
- shele 9y agoYes.
- stevesimmons 9y agoI agree... Judged against the title, the article adds little value: take one micro-benchmark; implement the naive Python algorithm using non-CPython approaches like Cython, Numpy and Numba; and stick on clickbait title that implies a speedup that applies in all cases. The article would be much better if it ditched the comparison to Julia and instead showcased "Some ways to make Python code faster."
- makapuf 9y agoI'm also wondering why the article is skipping pypy ? It's a python JIT which often be used as a drop in replacement of cpython.