On 24 September 2015 at 14:17, Marcio Sales <marciole...@hotmail.com> wrote:
> Wow. All this discussion to make Julia only *as fast as* the old > scripting languages? I gotta say that worried me a bit. What do you do when > there's no code to compare? How will you know that it was really a good > idea switching from Matlab/Python to Julia? > No. In my experience, Julia *IS* faster, and it is easy to make fast. What happened here is that the way you optimize Julia code is almost the opposite of how you optimize Matlab or Python code. If you take the fast code I wrote for Julia and port it to Matlab or Python it will be incredibly slow, I guarantee it (try it if you don't believe me). I think that the real lesson here is: Porting between Julia and Matlab/Python is not trivial. The way you write fast code is different in each language. Fast code in Julia means that you (1) use concrete types, and that you (2) write loops rather than "vectorized" code. > Considering what the develops proudly advertize about performance (what I > think is why most people would even consider changing to it), > In my case, while performance is important, I also really really like the design of the language. I really don't like Python/NumPy. I find Matlab tolerable (not great). Octave improves a bit on Matlab, but not enough, and Octave is slow. Before Julia, I used Octave despite the lower speed. > shouldn't the language be designed as to put the user in the best > performant direction most of the time? > That's what Julia does for me. > Matlab does a good job on that with fewer but simplified and efficient > data structures, supporting vectorized code etc. > This is backwards. It is not that Matlab "supports" vectorized code. Julia supports it too. Matlab *requires* vectorized code because Matlab loops are very slow by comparison. For Julia it's the other way. Vectorized Julia code performs similar to Matlab, but regular loops are much faster (in part because they avoid creating a lot of temporary variables in memory). > In my short experience with Julia, it seems that there are a lot of ways > to do the same thing, some of which very bad in terms of performance, like > the original code in this post. If Julia can't be easily faster and less > verbose than R for example, we could just forget about it... > Well, if Julia does not fit your needs, by all means use whatever language works best for you. Performance is a primary design goal for Julia, and I think that it delivers. I have seen Julia code get close to the performance of compiled Fortran code. I personally like Julia, and I don't like R, so I hope that the developers keep developing Julia. Cheers, Daniel.
