I checked, and my objective function is evaluated exactly as many times
under 0.4 as it is under 0.5. The number of iterations must be the same.
I also looked at the times more precisely. For one particular function call
in the code, I have:
0.4 with old code: 6.7s 18.5M allocations
0.4 with 0.5 style code(regular anonymous functions) 11.6s, 141M
allocations
0.5: 36.2s, 189M allocations
Surprisingly, 0.4 is still much faster even without the fast anonymous
functions trick. It doesn't look like 0.5 is generating many more
allocations than 0.4 on the same code, the time is just a lot slower.
On Thursday, September 29, 2016 at 3:36:46 PM UTC-4, Tim Holy wrote:
>
> No real clue about what's happening, but my immediate thought was that if
> your algorithm is iterative and uses some kind of threshold to decide
> convergence, then it seems possible that a change in the accuracy of some
> computation might lead to it getting "stuck" occasionally due to roundoff
> error. That's probably more likely to happen because of some kind of
> worsening rather than some improvement, but either is conceivable.
>
> If that's even a possible explanation, I'd check for unusually-large
> numbers of iterations and then print some kind of convergence info.
>
> Best,
> --Tim
>
> On Thu, Sep 29, 2016 at 1:21 PM, Andrew <owe...@gmail.com <javascript:>>
> wrote:
>
>> In the 0.4 version the above times are pretty consistent. I never observe
>> any several thousand allocation calls. I wonder if compilation is occurring
>> repeatedly.
>>
>> This isn't terribly pressing for me since I'm not currently working on
>> this project, but if there's an easy fix it would be useful for future work.
>>
>> (sorry I didn't mean to post twice. For some reason hitting spacebar was
>> interpreted as the post command?)
>>
>>
>> On Thursday, September 29, 2016 at 2:15:35 PM UTC-4, Andrew wrote:
>>>
>>> I've used @code_warntype everywhere I can think to and I've only found
>>> one Core.box. The @code_warntype looks like this
>>>
>>> Variables:
>>> #self#::#innerloop#3133{#bellman_obj}
>>> state::State{IdioState,AggState}
>>> EVspline::Dierckx.Spline1D
>>> model::Model{CRRA_Family,AggState}
>>> policy::PolicyFunctions{Array{Float64,6},Array{Int64,6}}
>>> OO::NW
>>>
>>> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>
>>> Body:
>>> begin
>>>
>>> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>
>>> = $(Expr(:new,
>>> ##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj},
>>>
>>> :(state), :(EVspline), :(model), :(policy), :(OO),
>>> :((Core.getfield)(#self#,:bellman_obj)::#bellman_obj)))
>>> SSAValue(0) =
>>> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>
>>> (Core.setfield!)((Core.getfield)(#self#::#innerloop#3133{#bellman_obj},:obj)::CORE.BOX,:contents,SSAValue(0))::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>> return SSAValue(0)
>>>
>>> end::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>
>>>
>>> I put the CORE.BOX in all caps near the bottom.
>>>
>>> I have no idea if this is actually a problem. The return type is stable.
>>> Also, this function appears in an outer loop.
>>>
>>> What I noticed putting a @time in places is that in 0.5, occasionally
>>> calls to my nonlinear equation solver take a really long time, like here:
>>>
>>> 0.069224 seconds (9.62 k allocations: 487.873 KB)
>>> 0.000007 seconds (39 allocations: 1.922 KB)
>>> 0.000006 seconds (29 allocations: 1.391 KB)
>>> 0.000011 seconds (74 allocations: 3.781 KB)
>>> 0.000009 seconds (54 allocations: 2.719 KB)
>>> 0.000008 seconds (54 allocations: 2.719 KB)
>>> 0.000008 seconds (49 allocations: 2.453 KB)
>>> 0.000007 seconds (44 allocations: 2.188 KB)
>>> 0.000007 seconds (44 allocations: 2.188 KB)
>>> 0.000006 seconds (39 allocations: 1.922 KB)
>>> 0.000007 seconds (39 allocations: 1.922 KB)
>>> 0.000006 seconds (39 allocations: 1.922 KB)
>>> 0.000005 seconds (34 allocations: 1.656 KB)
>>> 0.000005 seconds (34 allocations: 1.656 KB)
>>> 0.000004 seconds (29 allocations: 1.391 KB)
>>> 0.000004 seconds (24 allocations: 1.125 KB)
>>> 0.007399 seconds (248 allocations: 15.453 KB)
>>> 0.000009 seconds (30 allocations: 1.594 KB)
>>> 0.000004 seconds (25 allocations: 1.328 KB)
>>> 0.000004 seconds (25 allocations: 1.328 KB)
>>>
>>> 0.000010 seconds (70 allocations: 3.719 KB)
>>> 0.072703 seconds (41.74 k allocations: 1.615 MB)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thursday, September 29, 2016 at 1:37:18 AM UTC-4, Kristoffer Carlsson
>>> wrote:
>>>>
>>>> Look for Core.Box in @code_warntype. See
>>>> https://github.com/JuliaLang/julia/issues/15276
>>>
>>>
>
