Thanks a lot for all your answers! Now I need to take a break to learn all these cool stuff and get prepared to such a bright future :)
On Mon, Jul 21, 2014 at 11:03 PM, Stefan Karpinski <ste...@karpinski.org> wrote: > Automatic, general loop fusion is something that we want to make possible > and Jeff and I have been discussion quite a bit lately. There's a few ideas > that seem promising, but they won't happen immediately. The combination of > doing better escape analysis and loop fusion should help these problems > quite a bit and bring high-level vectorized Julia code closer to the > performance of manually devectorized, loop fused code. > > > On Mon, Jul 21, 2014 at 6:10 AM, Tim Holy <tim.h...@gmail.com> wrote: > >> codegen is a big one, as are inference.jl, gf.c, and cgutils.cpp. But >> there >> are optimization sprinkled throughout (e.g., ccall.cpp). >> >> You might be interested in this: >> https://github.com/JuliaLang/julia/issues/3440 >> >> Most of the optimizations so far are low level; most of the higher-level >> stuff >> tends to be macros in packages (@devec being a prime example, I'm working >> on >> another now). The fact that @devec didn't work for you is evidence that >> this >> is nontrivial (I bet that Dahua would be interested in contributions that >> improve it). In the longer run, it might be interesting to experiment with >> LLVM's Polly, but I'm not very clear on how far that project has gotten in >> practice. >> >> --Tim >> >> On Monday, July 21, 2014 03:51:11 PM Andrei wrote: >> > Could you please point me to where these optimizations take place? I see >> > some other transformations (like escape analysis, for example) >> happening in >> > codegen, are there any other places I should look at? >> > >> > On Mon, Jul 21, 2014 at 2:43 PM, Tim Holy <tim.h...@gmail.com> wrote: >> > > On Monday, July 21, 2014 02:33:26 PM Andrei wrote: >> > > > I see one disadvantage of using these tools, however - they are much >> > > >> > > harder >> > > >> > > > to read. Are there any plans for automatic code optimization on >> compiler >> > > > level? >> > > >> > > There are already many optimizations in place. But there's always >> more you >> > > could do. >> > > >> > > --Tim >> >> >
