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 <[email protected]> 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 <[email protected]> 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 > >
