There is also the GC improvement patch that is waiting for the 0.3 release, 
which should help improve the GC performance. With better escape analysis, 
it should be possible to reuse the garbage from vectorized expressions in a 
loop in the next iteration, and significantly reduce GC load. It should 
also give much better performance, and stuff like loop fusion should make 
it possible to avoid devectorization in many cases.

-viral

On Tuesday, July 22, 2014 1:34:10 AM UTC+5:30, Stefan Karpinski 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
>>
>>
>

Reply via email to