Hacker News Reader

Comment by Lxr | Hacker News Reader

Julia is a lot (lot) faster than Python, Matlab or R. This doesn't matter so much if you're gluing library calls together (if using well-known ML algorithms that use native BLAS/LAPACK etc) but for custom stuff Python et al are just too slow. Julia is comparable to C++ in speed (not as fast, but within an order of magnitude in my experience) and it's MUCH more fun to write.

There are definitely not more libraries though, it's still a young project.

View on HN

The problem is: plain Julia is faster than plain CPython. But Numba has solved this problem for me, by compiling my hot loop in-place. Other people report similar success with PyPy, Cython, or Pyston.

Furthermore, libraries like scikit-learn, pandas, matplotlib, or scipy are incredibly powerful, and usually implement in fast languages. Python is only there to glue them together.

For my applications, I just don't see any compelling reason why I should use Julia over Python. In practice, Julia is (for the above reasons) not faster in practice, and the libraries are a lot less mature. I try Julia every few months though, and there is progress. Maybe in a few years.

If you're really happy with your current tools, Julia's probably not for you right now, and that's totally fine. Julia's users tend to have the opposite of the "established libraries + glue" use case; something more like "custom data structures + unvectorisable numerics". It's better for the people who are writing the next scikit-learn than for those who are using it.

The main advantage of Julia's JIT is that the performance of a given piece of code is easy to predict and debug – this is a classic problem with tracing JITs.

Between ccall, PyCall and RCall you can access a huge range of existing code from inside Julia. So the libraries issue is moot.

Having used both, I much prefer Julia to python+cython. Three examples: multiprocessing is much less restrictive, there's no edit-compile loop so development is quicker, and no awkward pyx/pxd system. If you have to go deep with a cython project, you basically end up writing C, and that's slow - not cython's fault, it's a great tool, just a limitation of that platform.

I don't like Cython very much. I much prefer CFFI or Numba, which have none of your stated problems.

A quick look at the numba docs suggests that it doesn't parallelise any better than regular python - so there's one of my problems.

Numba also seems to be restricted in the functionality it offers, e.g. currently looks like no user defined types so good for hot loops but not your whole codebase. If you touch the python C API it suggests it can't do full JIT compilation, i.e. sounds like this would happen with any C-extension library code outside the range of supported numpy features. No strings?...

I'd love to be shown wrong about this.

Julia has a lot of room for improvements. For example with better type inference (programs get slooow when the type cannot be inferred, they are working on it) and stack-allocation of arrays.

Currently, all arrays require a malloc. Once the JIT-compiler is sufficiently smart, Julia could use stack-allocation of temporary arrays (that cannot escape the current context). Algorithms making use of temporary arrays will become faster by possibly an order of magnitude.

Julia might become competitive with C / Fortran for general purpose computing. And that is a level of speed all your other examples cannot hope to reach.

sort of: Julia is JITted, so there can be some overhead, and if you're not careful about how you program, the overhead can be high (and it's not hard to be careful), but the cost of this overhead diminishes as you run over increasing amounts of data. Also some things like Julia's text IO are super slow because of the architecture of how functions like print() work (I think this is a work in progress) so logging may incur a cost.

Don't get me wrong, I love Julia and actually get paid to code in Julia, and it's a real joy of a programming language to work in (I'd put it close to ruby in terms of programmer satisfaction)... Just think that overblowing speed claims is counterproductive.

> Don't get me wrong, I love Julia and actually get paid to code in Julia, and it's a real joy of a programming language to work in (I'd put it close to ruby in terms of programmer satisfaction)... Just think that overblowing speed claims is counterproductive.

Whoa! Who is using Julia in production? I'm a data scientist in a large corp that has successfully converted folks to Python, and would love to use Julia for my custom stuff!

I wouldn't call it 'production'. I'm prototyping experimental number systems for high-performance computing and my supervisor has been doing it in mathematica to date, which is so glacial it's unacceptable. Took hours to do a calculation that julia can do in seconds.

While many of Julia Computing's customers already use Julia in production, JuliaCon has had many talks as well. Here are a few:

A Big Data application: https://www.soasta.com/blog/soasta-brings-julia-big-data-rea... A finance application: https://www.youtube.com/watch?v=CShweOpWz6w&list=PLP8iPy9hna... An avionics application: https://www.youtube.com/watch?v=19zm1Fn0S9M

Reply on news.ycombinator.com