I haven't done any systematic benchmarking since Numba introduced the ability to JIT compile entire classes. In my experience, very well written Julia code is usually equivalent or better (in cases when @simd is helpful) compared to Numba JIT'd code. The Python code is sometimes easier to write, since Numba takes care of everything, but it's a double edged sword - if you run into a case where Numba doesn't work well or at all, you're just out of luck. In my personal view, the availability of Numba and other libraries just means Python vs Julia performance comparisons aren't particularly relevant, you should pick the language you prefer, not because you think it's faster, whereas if absolute performance is the only metric, you have to resort to Fortran/C++ anyway. I'm writing most of my code in Julia because I prefer the type system and multiple dispatch to Python's OOP, but I don't think it's meaningfully faster as long as you're willing to use appropriate libraries.
The one outlier is the fact that GPU programming is much easier in Python at the moment. Hopefully that will change soon, some of the progress in ArrayFire.jl and CUDA libraries is very promising. On Monday, July 25, 2016 at 7:34:04 PM UTC+3, dnm wrote: > > Interesting. Did you use the updated Julia code? > > Have you done any comparisons between reading and writing Numba JIT > classes and Julia types in tight loops? > > On Monday, July 25, 2016 at 10:41:48 AM UTC-4, [email protected] wrote: >> >> Just for the sake of comprehensiveness, I ran your Python benchmark >> through the Numba JIT library (which uses the same underlying LLVM >> infrastructure that Julia does) and on my computer the Python code is >> faster than Julia by 68%. Vanilla CPython is terrible for this kind of >> simple explicit loop code, but Numba and other JIT libraries largely solve >> that issue with minimal effort as long as the code is simple enough. That >> by no means solves all of Python's issues in the context of numerical >> programming and I'm sure the Julia benchmark could be improved as others >> have already mentioned, but benchmarking Python this way isn't necessarily >> representative of how a performance-conscious programmer would reasonably >> approach a problem of this kind. >> >
