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] > <javascript:>> 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 >>> >>> >>> >>> >
