4 ms·

1) "Ruby and Python are good general purpose languages, beloved by web developers because they make coding faster and easier. But they don’t run as quickly as l

by aldanor 13y ago

1) "Ruby and Python are good general purpose languages, beloved by web developers because they make coding faster and easier. But they don’t run as quickly as languages like C and Java." --- sorry to spoil the party but NumPy is quite a bit faster than Julia in real-world applications. Something as trivial as summing elements of an array runs much slower in Julia (unless they fixed it, last I checked was about 4 months ago). I'm not even gonna get started on pypy / llvmpy / numba / cython. R, albeit being a horrendous language, can be hardly beaten by anything at the moment due to its epic plotting tools like ggplot2 and the sheer amount of statistical packages created by scientists from all over the world; it's like github for many of the stats guys. Except unlike github, most of the packages are not open-source and hence can't be directly ported to python/julia/whatever.. 2) Lack of existing infrastructure for scientists and general purpose stuff like various SQL adapters and bindings. Take any data-oriented/scientific field, there's gonna be a python library or a c++ library with python bindings for it. Data munging? pandas. Plotting? matplotlib. Machine learning? scikit-learn. MC Monte-Carlo? PyMC or PySTAN. Optimization? scipy. That's just to name a few... those are all huge libraries with many thousands commits in their repos and many thousands human hours behind them -- it will be pretty hard for anyone to catch up fast. /* it's worth mentioning here though that many libraries in scientific Python stack were developed by aggravated R / Matlab users who loved the tools but hated the language => matplotlib/pyplot was initially a direct port of Matlab's plotting tools, pandas was initially a direct port of R's data.frame, etc / 3) 1-based indexing. Seriously, wtf? / insert an arbitrary Dijkstra joke here */ Not trying to bash Julia deliberately but I'd say by publishing a fluff piece like this Wired in fact discredits the Julia community who are nice and enthusiastic folks.

simonster 13y ago
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.
stefantalpalaru 13y ago
1) Most of NumPy is written in C. Pypy is slower in some scenarios than CPython (when the JIT doesn't kick in). Numba and Cython are supersets of subsets of Python. 2) Lack of libraries should never be a show stopper when it comes to adopting new languages. 3) Lua.
Fomite 13y ago
> 3) 1-based indexing. Seriously, wtf? / insert an arbitrary Dijkstra joke here */ There are arguments in favor of 1-based indexing, especially given one of Julia's target replacement languages is R.

by aldanor 13y ago

simonster 13y ago

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.

stefantalpalaru 13y ago

1) Most of NumPy is written in C. Pypy is slower in some scenarios than CPython (when the JIT doesn't kick in). Numba and Cython are supersets of subsets of Python. 2) Lack of libraries should never be a show stopper when it comes to adopting new languages. 3) Lua.

Fomite 13y ago

> 3) 1-based indexing. Seriously, wtf? / insert an arbitrary Dijkstra joke here */ There are arguments in favor of 1-based indexing, especially given one of Julia's target replacement languages is R.