Julia vs Python

Carson Chow Computer Science

I was about to start my trek up Python mountain until Bard Ermentrout tipped me to the Julia language and I saw this speed table from here (lower is faster):

Fortran Julia Python R Matlab Octave Mathe-matica JavaScript Go
gcc 4.8.1 0.2 2.7.3 3.0.2 R2012a 3.6.4 8.0 V8 3.7.12.22 go1
fib 0.26 0.91 30.37 411.36 1992.00 3211.81 64.46 2.18 1.03
parse_int 5.03 1.60 13.95 59.40 1463.16 7109.85 29.54 2.43 4.79
quicksort 1.11 1.14 31.98 524.29 101.84 1132.04 35.74 3.51 1.25
mandel 0.86 0.85 14.19 106.97 64.58 316.95 6.07 3.49 2.36
pi_sum 0.80 1.00 16.33 15.42 1.29 237.41 1.32 0.84 1.41
rand_mat_stat 0.64 1.66 13.52 10.84 6.61 14.98 4.52 3.28 8.12
rand_mat_mul 0.96 1.01 3.41 3.98 1.10 3.41 1.16 14.60 8.51

Julia is a dynamic high level language like MATLAB and Python that is open source and developed at MIT. The syntax looks fairly simple and it is about as fast as C (Fortran looks like it still is the Ferrari of scientific computing). Matlab is fast for vector and matrix operations but deadly slow for loops. I had no idea that Mathematica was so fast. Although Julia is still relatively new and not nearly as expansive as Python, should I drop Python for Julia?

14 thoughts on “Julia vs Python”

  1. Julia certainly has great-looking core performance and, yes, it benefits from being natively designed for scientific computing. You’ll have a lot more bother with library support and user experience in the wider context, for the near-mid future at least.

    I think the decision could come down to what fraction of your time you just want to do low level numeric computations quickly and with most ease (Julia) vs. setting up sophisticated high-level programs that involve lots of other workflow elements, which would benefit from the expanded capabilities of python. What kinds of modeling / computational tasks *are* you trying to execute with Matlab these days? For instance, no matter how fast the environment is, good luck trying to do bifurcation analysis with Julia until someone writes an interface to AUTO or creates an equivalent to PyCont or MatCont.

    Also, consider the Python + Cython combination, Cython being an easy-to-use built-in Python C-extension library (like MEX but simpler to use). This combo is a little bit more overhead to configure and use but can run raw computations at least as fast as Julia. The combo is essentially solving the problem under-the-hood the same way as Julia does automatically/natively.

    Liked by 1 person

  2. Python’s large number of excellent libraries and tutorials mean that for the moment it is probably a good choice, but Julia is certainly one to watch. It would probably be easier to transition from Matlab to Julia in terms of syntax, but not in terms of libraries.

    Like

  4. The legend for that table says “The Python implementations of rand_mat_stat and rand_mat_mul use NumPy (v1.6.1) functions; the rest are pure Python implementations.”

    But you would never use a pure Python implementation for any of these things, unless you were just messing around in the interpreter (in which case speed doesn’t really matter). If you’re actually writing a block of code to be re-used you would use a NumPy/SciPy/SciKits module that is using C-compiled code. For example, pretty much all of BLAS/ATLAS/LAPACK has already been implemented in Python at speeds within 2x of C.

    And is computation time really going to be a bottleneck relative to development time? Maybe if you’re looking for a quick answer, but if you are trying to produce a lasting research product that people can build on, I think that development time is definitely going to be the slow part, in which case you definitely want to use Python over all the alternatives. Moore’s law may be dead or dying, but I think the FLOPS/$ accessible to us is going to go up much faster over the rest of all of our careers than the speed with which we can write good code.

    Lastly, have you seen this?
    http://www.talyarkoni.org/blog/2013/11/18/the-homogenization-of-scientific-computing-or-why-python-is-steadily-eating-other-languages-lunch/

    Like

  5. I looked at the code, they certainly can’t write half decent matlab. On my trashy core i7 laptop (4 years old, while watching a stream of the USA v. Belgium and having about 1GB of 8GB memory taken in matlab by my dayjob, I could improve on their Fibonacci by almost 4 (!!!) orders of magnitude (114.81 with their code, 0.013 with mine) just by making it a for-loop (I wasn’t even trying hard!) instead of that recursive pig’s-ear of a coding job they did.

    Learn whatever language you like, just get your algorithms straight for the language you’re using.

    Like

  6. Thanks for cluing me in to Julia. For now, I’ll stick to Fortran (speed) and Python and R (for teaching newbies in their most native language). Keep us posted on your Julia progress.

    PS I help new researchers access and use data and will teach them in whatever language they are most comfortable with. Thus, I use what they use. Later, when they ask how to speed their work up, I can say, “Well, grasshopper…”

    Liked by 2 people

  7. My problem with Julia is that it does not go far enough. As you will see from the Julia homepage, Julia wishes to replace a bunch of existing (imperfect) languages with one, unified, fast language. That in itself is laudable, but in order to arrest the enormous momentum of R and/or Python, you need to provide a more ambitious programming paradigm, instead of simply being an incremental improvement. The posts above are telling, and can be summarised as follows “stick with Python, keep an eye on Julia”. Personally, having dabbled with Julia and hit a wall as soon as I needed to talk efficiently to Mongo (one of many potential examples of missing/incomplete libraries), I decided to stick with Python despite Julia’s general speed improvments. As another poster said, however, much of the numerical work one will do in Python is extremely fast already, and will not be improved upon signficantly with Julia (numpy/scipy/pandas). Also, while everybody waits for the Julia lang library catalogue to catch up, Python will be a moving target. It’s not a sitting duck.

    As such, while I can see Julia grabbing some share from (expensive and closed) Matlab – it is after all written by Matlab guys – I cannot see how Python’s gigantic and very high quality ecosystem will be overturned anytime soon, if not ever.

    Liked by 2 people

  8. I might add that if you want to get that “eureka” feeling, like the one you may have felt when first learning Python, do yourself a favour and but Wes McKInney’s book on Python for Data Analysis, and learn pandas. This single library will be enough to wrench you away from R, and transform your data-analysis workflows.

    Liked by 1 person

  10. Wouldn’t it be the trick Julia uses GPU instead of CPU like python does? So soon Python could have those libraries or integration?

    Like

  14. Instead of comparing a good implementation of an algorithm with bad implementations in other languages, why not make it an ongoing contest to see how fast people can get the code to run in their favorite language? No one would use pure Python for numerical computation, for instance.

    Like

Leave a comment