Hacker News Reader

Comment by knlje | Hacker News Reader

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

View on HN

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

Isn'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.

Why, is anybody restricted to using recursion in their solutions?

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

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

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

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

Reply on news.ycombinator.com