On Tuesday, July 12, 2016 at 5:57:27 AM UTC-7, Andreas Lobinger wrote: > > just my two cents... > > On Tuesday, July 12, 2016 at 5:28:24 AM UTC+2, Chris Rackauckas wrote: >> >> >> MATLAB really improved their JIT in 2015b, but as you can see, it cannot >> come close to Julia. The main reason is that, although it can do quite a >> bit because it ensures type stability, it has type stability only because >> everything in MATLAB is by default a complex number. >> > > This is not correct, a variable is by default double. And extended to be > complex if needed. But that's not the point. >
It was originally all complex, but now everything is sort of double but can switch to complex at anytime. So all the standard numbers are not type-stable doubles in MATLAB which is one reason why you wouldn't ever expect it to be as efficient. It's a tradeoff between ease of use and performance where Julia took the performance choice. > > >> So even in the simplest example (where its JIT works correctly. You'll >> notice that in many cases it won't work, and since it doesn't cache well it >> may recompile all the time, and ... it works okay but there's a reason I >> switched to Julia) you'd expect Julia to be at least twice as fast. >> > > I think i have written this before: Julia enables you to write fast code, > however it's not automatically faster at a constant factor compared to > something. It's not like: matlab does it wrong, julia does it correct and > therefore is magically faster. Some people on this mailing list (including > myself) already had experiences with julia code running surprisingly slow > or with a heavy memory impact (row-first vs. column-first arrays and > temporary arrays and similar). > It's not magically faster. It's obvious why it's faster: type-stability plus the ability to turn off all the extra "dynamic language helpers" like bounds checking. If you restrict yourself to very basic examples you will always see this is the case like the one the OP chose you will always see a speedup over MATLAB for these two reasons. "Surprisingly slow" code usually comes from type-instability, a slow library/package function, or bad programming (which sometimes can be easy to do). Type-instability is the biggest one: it can easily lead to orders of magnitude slower code. Choosing to iterate along a row in a column-major language is just a bad idea (and thus will slow down the MATLAB code for the same reason). Temporary arrays usually come from vectorized calls which aren't fused, which usually happens in MATLAB as well and is going to be largely fixed very soon <https://github.com/JuliaLang/julia/pull/17300>, but is always fixable by re-writing the code as a loop. It's true that, as you say, if you ignore these facts and the other performance rules <http://docs.julialang.org/en/release-0.4/manual/performance-tips/>, your code will only be as fast as (or as slow as) other dynamic languages, and probably even be slower than something like MATLAB/Python. But I don't see how that applies to the case I mentioned: "the simplest example". In this case, you have type-stability, looped correctly through columns, etc., and your code will get close to C performance, or you read the manual wrong (or you found a bug and should open an issue). MATLAB's JIT can in some limited cases do almost as well. However, it's obvious why it's only a subset of cases: type-stability. f1(x) = sqrt(x) f2(x) = x^(-1) Those are 2 cases just off the top of my head where the equivalent MATLAB code using the JIT cannot be as fast as the Julia code simply because it cannot guarantee type stability in MATLAB. So if you have anything like this hanging around in a function, it will not do well. This isn't magic, it's a tradeoff between performance and ease of use (though you can make a new type in Julia called EasyFloat which just holds a float, and then make dispatches for each math function which are type-unstable in the same way as MATLAB. It wouldn't even be hard to do, and you'd no longer get InexactError() or DomainError() message, but it would be as slow as MATLAB). [Another case which MATLAB's JIT won't do well is the equivalent of f3(x) = sin.(cos.(log.(x))) due to temporary variables. Julia's will handle this well after @stevengj's PR (but you could always handle just by writing out the broadcast or the loop).]
