Hacker News Reader

Comment by thebooktocome | Hacker News Reader

The point of the Julia benchmarks was to show compiler performance.

You can do something clever in any language. There are plenty of really, really smart people that spend a lot of time writing incomprehensible (to me) Haskell that outperforms C.

The question is, do you have to do something clever to get performant code in the language of your choice?

In Julia -- not often. I've written around 50kloc of Julia; almost all of it is first-pass prototype code that manages to be performant despite itself. The most polished code I've written in Julia is about 100x faster than the MATLAB it replaced.

IMO, the main advantage of Python is its massive library of modules. As a prototyping language, on the other hand, it just seems to me that Julia is more flexible.

View on HN

I agree with your main idea, but if you think about it, the author isn't doing anything clever per se with Python. I mean, using numpy and associated libraries is fairly common when Python is used for numerical computing (remembering that Python is a _general purpose_ language, not particularly aimed at a particular domain).

I have tried Julia, and really like it, but am still using Python for most of my prototyping. Maybe I should force myself to use Julia for some time :)

I agree, but this is only true as long as you stick with numerical applications, which is kind of the point of Julia.

It is currently more of a domain specific language, kind of like Matlab, because it's not really optimized for other things and has no libraries in the other domains.

On the other hand, I implemented a prototype neural network in it, and it went very smoothly. Will have to eventually rewrite it in Python though.

Julia is a general purpose language, not a DSL. You can create web services, desktop apps, file tools with Julia. And it has access to a lot of external libraries using CCall.jl and PyCall.jl

Right now, numba is a better compiler than Julia has. You can write array expressions and loops in numba and it will do fusion/deforestation to eliminate temporaries giving you faster vectorized in loop code than Julia currently does.

Of course, this is currently being worked on in julia as well, but I don't see your point.

But to be fair, you need to compare the same exact program. A program that handles arbitrary precision isn't the same program as one that doesn't. The same goes for support for missing values and other stuff.

The OP was misleading. The benchmark is to calculate fib(20) = 6765, which does not overflow.

You can verify this for yourself at https://github.com/JuliaLang/julia/blob/master/test/perf/mic...

The issue is that the Python code uses arbitrary precision while Julia code uses 64 bits. Python may be slower because of that. One way to get rid of this discrepancy is to compile with typed Cython, or with Numba, which is what I did. The other way would be to benchmark Julia with BigInt. Either way would be fair IMHO.

I was unaware that Python 3 removed the distinction between int (which used to be C-style int) and long (which was arbitrary precision).

If it's really idiomatic Python 3 to always use arbitrary precision integers for everything, then it's not really Julia's fault that Python 3 makes it more difficult to use performant arithmetic.

Reply on news.ycombinator.com