5 ms·

Well written pure julia programs tend to be about as fast as C, or in other words about 100 times faster than Python or R. Before that gets you too excited or

Well written pure julia programs tend to be about as fast as C, or in other words about 100 times faster than Python or R. Before that gets you too excited or sceptical, let me say that end users will not really see many significant speed boosts. When I say end users, I mean people who are just loading packages and writing scripts where they plug variables into functions from the package. The reason these end users won't see much difference is that a well made Python or R package (including things like Numpy) are actually Python and R wrappers around C, C++, Fortran or Julia code. However, if you are trying to do something that your packages weren't directly designed to do and writing non-trivial code, then you're going to start seeing the speed advantages of Julia. With all that in mind, I'd say the main reason for end users to use Julia is not the speed, it's the expressiveness and the top notch libraries. Expressiveness is kinda a vague concept, but what I'm basically saying is that through things like multiple dispatch and macros, julia is able to provide ways of writing programs in almost any domain that feel incredibly natural and various programs will compose with eachother in ways you won't see in any language except Common Lisp. Finally, because of Julia's native speed and expressiveness, it doesn't get in package developers way like Python and R do and so we're seeing that even though julia has a much smaller community than Python or R, we have a package ecosystem that's quite comparable and in certain specific regions, flat out superior. As adoption grows, we're going to see the julia package ecosystem accelerate and Julia will make sense for more end users. For now, whether or not Julia makes sense for you really depends on what field you're working in (ie. if there are good packages already for the tasks you're interested in) and how advanced a programmer you are / want to be (ie. if you're going to be trying to do something that's not already covered by existing packages).

mehrdadn 7y ago
> However, if you are trying to do something that your packages weren't directly designed to do and writing non-trivial code, then you're going to start seeing the speed advantages of Julia. Or you use Numba. :-) But yeah, the speed can be pretty bad compare to native code if you can't compile everything to native with Numba. To put some concrete numbers here, the one time I had some complicated but heavily-optimized Python and C++ scicomp codebases computing exactly the same thing, I saw [1] running times like the following depending on the algorithm: 1. 10.6s with NumPy, 7.5s with NumPy + Numba, and 0.6s in direct C++ (1.4x and 12.5x respectively) 2. 68s with NumPy, 6.5s with NumPy + Numba, 0.5s in direct C++ (10x and 13x respectively) The first algorithm was simpler and more vectorizable, while the second algorithm was more complicated and less vectorizable but with a lower time complexity. In either case, the algorithm still had to do a fair bit of work in Python, so it wasn't running native code 100% of the time (which I think is fairly realistic). In either case, you can see the difference between C++ and Python was around 13x when using Numba... not quite as bad as 100x, but I imagine Julia probably does better. [1] Actually, originally I saw only a 5x improvement with Python 2.7 on my older laptop, but I re-ran these on my current laptop under Python 3.7 and the difference is 13x now.
- eigenspace 7y ago
  > Or you use Numba. :-) My gripe with Numba is that you're still giving up on a huge suite of Python's language features. One could say "oh well, eventually with enough work Numba will make all of Python as fast as Julia" but I don't think that's true. Python has specific semantics core to it's design that make all sorts of optimizations impossible. Julia made a lot of core design decisions to make sure that these optimizations were possible. You could invent a new language that's python-like but doesn't have the same limitations but then you might as well just use Julia. Now, if all you ever interact with is is floating point numbers then Numba may be enough for you unless you're in an application like differential equation solving where the context switch of going back and forth between interpreted Python code and compiled Numba code will kill your performance. But Julia's compiler will work on custom types just as well as builtin types (in fact, Julia's builtin number types are written in pure julia and could have been implemented in a package with the same performance). > In either case, you can see the difference between C++ and Python was around 13x when using Numba... not quite as bad as 100x, but I imagine Julia probably does better. When I said the 100x that's mostly a statement about Python's looping performance and discounting Numpy vectorization Ie. comparing a Python for loop to a C or Julia for loop (arguably a strawman, I know). Numpy is just calling C routines afterall, so for the most part it can be really fast other than the fact that individual Numpy calls don't know about each-other which precludes some optimizations. But yeah, claims about performance differences between languages is a really technical and highly context contingent debate which is why I wish people wouldn't lean so much on Julia's speed as it's main selling point. It will mostly just lead to disappointment or confusion when someone comes over to julia and finds out that matrix multiplication is the same speed in julia as their old language (or slower since we default to bundling OpenBLAS instead of MKL). Hell, for people just writing simple scripts and restarting julia often, especially plotting, Julia is probably significantly slower than Python since a non-trivial amount of time will be spent compiling functions before the first time they're run. Julia's incredibly expressive type system, macros and the crazy composability of julia code are much more impactful benefits than it's runtime performance, but these are much more vauge squishy, qualitative concepts than quantitative concepts like runtime performance.
  - laughfactory 7y ago

mehrdadn 7y ago

> However, if you are trying to do something that your packages weren't directly designed to do and writing non-trivial code, then you're going to start seeing the speed advantages of Julia. Or you use Numba. :-) But yeah, the speed can be pretty bad compare to native code if you can't compile everything to native with Numba. To put some concrete numbers here, the one time I had some complicated but heavily-optimized Python and C++ scicomp codebases computing exactly the same thing, I saw [1] running times like the following depending on the algorithm: 1. 10.6s with NumPy, 7.5s with NumPy + Numba, and 0.6s in direct C++ (1.4x and 12.5x respectively) 2. 68s with NumPy, 6.5s with NumPy + Numba, 0.5s in direct C++ (10x and 13x respectively) The first algorithm was simpler and more vectorizable, while the second algorithm was more complicated and less vectorizable but with a lower time complexity. In either case, the algorithm still had to do a fair bit of work in Python, so it wasn't running native code 100% of the time (which I think is fairly realistic). In either case, you can see the difference between C++ and Python was around 13x when using Numba... not quite as bad as 100x, but I imagine Julia probably does better. [1] Actually, originally I saw only a 5x improvement with Python 2.7 on my older laptop, but I re-ran these on my current laptop under Python 3.7 and the difference is 13x now.

eigenspace 7y ago
> Or you use Numba. :-) My gripe with Numba is that you're still giving up on a huge suite of Python's language features. One could say "oh well, eventually with enough work Numba will make all of Python as fast as Julia" but I don't think that's true. Python has specific semantics core to it's design that make all sorts of optimizations impossible. Julia made a lot of core design decisions to make sure that these optimizations were possible. You could invent a new language that's python-like but doesn't have the same limitations but then you might as well just use Julia. Now, if all you ever interact with is is floating point numbers then Numba may be enough for you unless you're in an application like differential equation solving where the context switch of going back and forth between interpreted Python code and compiled Numba code will kill your performance. But Julia's compiler will work on custom types just as well as builtin types (in fact, Julia's builtin number types are written in pure julia and could have been implemented in a package with the same performance). > In either case, you can see the difference between C++ and Python was around 13x when using Numba... not quite as bad as 100x, but I imagine Julia probably does better. When I said the 100x that's mostly a statement about Python's looping performance and discounting Numpy vectorization Ie. comparing a Python for loop to a C or Julia for loop (arguably a strawman, I know). Numpy is just calling C routines afterall, so for the most part it can be really fast other than the fact that individual Numpy calls don't know about each-other which precludes some optimizations. But yeah, claims about performance differences between languages is a really technical and highly context contingent debate which is why I wish people wouldn't lean so much on Julia's speed as it's main selling point. It will mostly just lead to disappointment or confusion when someone comes over to julia and finds out that matrix multiplication is the same speed in julia as their old language (or slower since we default to bundling OpenBLAS instead of MKL). Hell, for people just writing simple scripts and restarting julia often, especially plotting, Julia is probably significantly slower than Python since a non-trivial amount of time will be spent compiling functions before the first time they're run. Julia's incredibly expressive type system, macros and the crazy composability of julia code are much more impactful benefits than it's runtime performance, but these are much more vauge squishy, qualitative concepts than quantitative concepts like runtime performance.
- laughfactory 7y ago