If the only thing that keeps you on Julia is the JIT for loops where
everything has straightforward types like Array{Float64}, there are already
tons of choices: PyPy, Numba, Cython, Luajit, and V8 will all JIT that kind
of code decently.
But Julia has that kind of speed while also having a rich type system for
generic programming, macros, and other well-thought-out semantics due to
being designed by scratch. I doubt Matlab is very likely to add those
features going for, both for backwards-compatibility reasons and since it
doesn't like a priority for Mathworks (which isn't to impinge on the
technical ability of Mathworks engineers at all - of course they *could *if
they wanted to*).*
On Friday, October 23, 2015 at 7:18:43 AM UTC-4, Kris De Meyer wrote:
>
> Thanks for the tips. There are no depreciation warnings in my own code,
> but the Sundials package which I rely on has quite a few. Although the
> tests which are really slow don't print out depreciation warnings (the
> printed warnings occur earlier), I suppose depreciation checking can still
> be slowing things down, even if no warnings are printed anymore? I guess
> I'll just have to wait to see if Sundials can catch up (I see it's failing
> to pass tests under 0.4.0). This is very annoying as I wanted to move up
> from 0.3.11 because of problems in the PyCall/PyPlot/Conda packages that I
> don't seem to find a solution for in 0.3.11 but have been told are resolved
> in 0.4.0.
>
> Please accept the following not as unbridled criticism but as a way to
> improve working procedures. I've been developing Julia code since release
> v0.3.7. Unfortunately this isn't the first time that I lose many hours
> having to figure out why something that works in one release stops working
> in a subsequent one. To be honest, it's putting me off Julia and it must
> have similar effects on other potential users too. To me this points to the
> need for better procedures and guidelines in the way the language
> progresses and how the "official" packages catch up. I worked a couple of
> years for the MathWorks. Breaking backwards compatibility was generally not
> allowed, and the coordinated testing and release procedures made that
> nearly impossible. For Julia to be taken seriously by people outside the
> academic community, it would do well to start looking at how similar
> procedures can be adopted into an open-source development model. It's one
> thing to write good code and develop the "ideal" language, it's another
> thing altogether to release workable software to an outside community.
>
> On a slightly different note, in 2 or 3 release cycles, Matlab will have
> caught up on any performance gains Julia may have introduced (by using the
> same LLVM compiler procedures Julia uses) and then the only thing Julia
> will have going for it is that it's free. But my cost to my employers is
> such that if I lose as little as 3 days a year on compatibility issues,
> they would be better off paying for a Matlab license...
>
> Best.
>
> Kris
>
>
>
>
>
>
>
> On Thursday, October 22, 2015 at 10:58:30 PM UTC+1, Stefan Karpinski wrote:
>>
>> You can try using @code_warntype to see if there are type instabilities.
>>
>> On Thu, Oct 22, 2015 at 5:50 PM, Gunnar Farnebäck <[email protected]>
>> wrote:
>>
>>> If you don't have deprecation warnings I would suspect some change in
>>> 0.4 has introduced type instabilities. If you are using typed
>>> concatenations you could be hit by
>>> https://github.com/JuliaLang/julia/issues/13254.
>>>
>>>
>>> Den torsdag 22 oktober 2015 kl. 23:03:00 UTC+2 skrev Kris De Meyer:
>>>>
>>>> Are there any general style guidelines for moving code from 0.3.11 to
>>>> 0.4.0? Running the unit and functionality tests for a module that I
>>>> developed under 0.3.11 in 0.4, I experience a 500 times slowdown of blocks
>>>> of code that I time with @time.
>>>>
>>>> Can't even imagine where I have to start looking, and find it
>>>> flabbergasting that perfectly valid julia code under 0.3.11 (not
>>>> generating
>>>> a single warning) can show such a performance degradation under 0.4.0.
>>>>
>>>> Anyone seen anything similar? Is there some fundamental difference in
>>>> how code is JIT-compiled under 0.4.0?
>>>>
>>>> Thanks,
>>>>
>>>> Kris
>>>>
>>>>
>>>>
>>>>
>>
