67 ms·

1) is probably still true at the moment as long as you really need that large array, but the performance gap is likely to disappear once we have better garbage

1) is probably still true at the moment as long as you really need that large array, but the performance gap is likely to disappear once we have better garbage collection and SIMD support, which are both open pull requests. On the other hand, if your algorithm can be expressed in a loop that touches less memory, in my experience, devectorized code in Julia beats vectorized code in NumPy or MATLAB, and absolutely destroys devectorized code in those languages. This is vitally important in my work, since the data sets I work with are so large that expressing the algorithm in terms of vector operations would require more memory than my computer actually has (and it has 64 GB of memory). Numba and especially cython are bolted on hacks to deal with the poor performance of the interpreter. They are not conducive to the kind of modularity you can get with Julia or plain Python, and they have their own set of rules for achieving high performance. Their main upside is that, as you say below, people already have a lot of Python code, but if you were starting from scratch you would probably not design them into the language. NumPyPy still doesn't implement all of NumPy, although I think it's been under development for roughly as long as Julia. 2) would be a problem for any new language, but it is partially mitigated by the PyCall package, which makes it easy to call almost any Python code from Julia. There are even Julia wrappers on top of pandas and matplotlib that allow you to use them while following standard Julia programming conventions. I've played around with calling PySTAN from Julia, and it's not substantially harder than calling PySTAN from Python.

sixbrx 13y ago
> once we have better garbage collection IMO the importance of the garbage collector needs to be underscored. My experience with Julia was that if I pre-allocated arrays and wrote in a low level like (C-like) way, then it would be fairly fast (also, need to avoid closures but that's another issue). If, however, I generated any new values inside loops (and using proper abstractions, this is hard to avoid), then garbage collection would often massively slow down computations and make performance hard to predict. Unfortunately, I think having a truly high performance garbage collector is a massive undertaking. I hope I'm wrong about that.
- simonster 13y ago
  See https://github.com/JuliaLang/julia/pull/5227 https://github.com/JuliaLang/julia/pull/5227 for the open PR. The benchmark there suggests 2-3x improvement. There is a decent amount of low-hanging fruit, although "truly high performance garbage collection" means different things for different applications and LLVM is apparently not a good platform for generational GC. There are further possible improvements that are not strictly related to GC. We could determine that an array of the same size is being created on every iteration of the loop and allocate that memory only once. Ideally we'd automatically devectorize code to remove temporaries, but that is quite hard.
sandGorgon 13y ago
Numba and especially cython are bolted on hacks to deal with the poor performance of the interpreter. Could you explain this a little - What is so fundamentally broken about pypy/numba ? From the little I have read [1], it looks like they are inferring types to enhance performance and does a jit (just like Julia). I am of course wondering if the magic of Julia cannot be ported on top of Numba or something. [1] http://continuum.io/blog/numba_performance http://continuum.io/blog/numba_performance
- aldanor 13y ago
  pypy is generally incompatible with CPython libraries -- most notable being plain vanilla numpy. There are ongoing attempts to port numpy to pypy (numpypy), but other than that you're just left with pure python and pure python libraries. Numba/Cython restrict what kind of code you can write so they can (jit-)compile it. Cython is less restrictive since it's more mature but it uses special syntax and is technically not python anymore.

sixbrx 13y ago

> once we have better garbage collection IMO the importance of the garbage collector needs to be underscored. My experience with Julia was that if I pre-allocated arrays and wrote in a low level like (C-like) way, then it would be fairly fast (also, need to avoid closures but that's another issue). If, however, I generated any new values inside loops (and using proper abstractions, this is hard to avoid), then garbage collection would often massively slow down computations and make performance hard to predict. Unfortunately, I think having a truly high performance garbage collector is a massive undertaking. I hope I'm wrong about that.

simonster 13y ago
See https://github.com/JuliaLang/julia/pull/5227 https://github.com/JuliaLang/julia/pull/5227 for the open PR. The benchmark there suggests 2-3x improvement. There is a decent amount of low-hanging fruit, although "truly high performance garbage collection" means different things for different applications and LLVM is apparently not a good platform for generational GC. There are further possible improvements that are not strictly related to GC. We could determine that an array of the same size is being created on every iteration of the loop and allocate that memory only once. Ideally we'd automatically devectorize code to remove temporaries, but that is quite hard.

sandGorgon 13y ago

Numba and especially cython are bolted on hacks to deal with the poor performance of the interpreter. Could you explain this a little - What is so fundamentally broken about pypy/numba ? From the little I have read [1], it looks like they are inferring types to enhance performance and does a jit (just like Julia). I am of course wondering if the magic of Julia cannot be ported on top of Numba or something. [1] http://continuum.io/blog/numba_performance http://continuum.io/blog/numba_performance

aldanor 13y ago
pypy is generally incompatible with CPython libraries -- most notable being plain vanilla numpy. There are ongoing attempts to port numpy to pypy (numpypy), but other than that you're just left with pure python and pure python libraries. Numba/Cython restrict what kind of code you can write so they can (jit-)compile it. Cython is less restrictive since it's more mature but it uses special syntax and is technically not python anymore.