I have now been able to remove the need for all declarations except one,
Rm still needs to be declared as returning an array of floats.
Just before the loop I look at the type of the function that retrieves Rm
and I get
{:($(Expr(:lambda, {:XYZ,:tangents,:fe_label},
{{},{{:XYZ,Array{Float64,2},0},{:tangents,Array{Float64,2},0},{:fe_label,Int64,0}},{{:eR
m,Array{Float64,2},19}}}, :(begin #
C:\Users\pkrysl\Documents\Research\Software folder\FEA software
folder\jfineale\FEMMBaseModule.jl,
line 82:
return eRm::Array{Float64,2}
end::Array{Float64,2}))))}
This seems to be saying that the matrix returns the correct type. Am I
wrong?
Thanks,
Petr
On Friday, December 12, 2014 9:17:41 AM UTC-8, Petr Krysl wrote:
>
> Stefan,
>
> If you mean by the original code Ke1() and Ke2(), those were contrived
> examples that unfortunately did not even represent the problems in my
> actual code (conductivity(),
> https://gist.github.com/PetrKryslUCSD/ae4a0f218fe50abe370f
> <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2FPetrKryslUCSD%2Fae4a0f218fe50abe370f&sa=D&sntz=1&usg=AFQjCNHJQsa8ICKiXobesCkCSCKvhdW9dQ>).
>
> That code had no globals whatsoever.
>
>
> The solution (https://gist.github.com/PetrKryslUCSD/7bd14515e1a853275923)
> was to declare anything and everything. Now I've had more time to
> investigate,, and I've turned off the declarations selectively to see
> which ones were actually needed. The result: I actually need four
> declarations. Some of it may have to do with my inexperience with the
> language – I may not have made it possible for the compiler to discover
> the types. Some of it was addressed by John above (dynamically called
> function, with stable type, but not enough information for the compiler).
> The code (note the comments):
> https://gist.github.com/PetrKryslUCSD/4f57d4d62758ecc5bf20
>
> Petr
>
> PS: Concerning my attempt to formulate a moral for myself: I stand
> corrected, I'm beginning to get the idea that Julia does not need
> everything declared.
>
>
> On Friday, December 12, 2014 7:26:28 AM UTC-8, Stefan Karpinski wrote:
>>
>> Yikes, that's much harder to read than the original. Making the globals
>> const is a simple change and the fact that this improves the performance so
>> much shows that all those type annotations are not necessary. The only
>> issue with the original code was non-constant globals. We can also change
>> the globals to function arguments and the problem goes away:
>>
>> julia> @time Ke1(N);
>> elapsed time: 0.237183958 seconds (131200224 bytes allocated, 34.34% gc
>> time)
>>
>> julia> @time Ke2(N);
>> elapsed time: 0.021313495 seconds (400 bytes allocated)
>>
>> The gist has both the const and function-arg versions:
>>
>> https://gist.github.com/StefanKarpinski/e1d7d8804e373cc1de07
>>
>>
>> On Fri, Dec 12, 2014 at 10:12 AM, Andreas Noack <[email protected]>
>> wrote:
>>
>>> Stefan, please consider the updated version
>>>
>>> https://gist.github.com/PetrKryslUCSD/7bd14515e1a853275923
>>>
>>> which has no global variables.
>>>
>>> 2014-12-12 10:07 GMT-05:00 Stefan Karpinski <[email protected]>:
>>>
>>> From the original version of the code I see this timing after code gen:
>>>>
>>>> julia> @time Ke1(N);
>>>> elapsed time: 0.251365495 seconds (134400208 bytes allocated, 30.13% gc
>>>> time)
>>>>
>>>> julia> @time Ke2(N);
>>>> elapsed time: 3.923532621 seconds (996800384 bytes allocated, 13.97% gc
>>>> time)
>>>>
>>>> After making all the globals const, I see this:
>>>>
>>>> julia> @time Ke1(N);
>>>> elapsed time: 0.273683599 seconds (131200208 bytes allocated, 28.52% gc
>>>> time)
>>>>
>>>> julia> @time Ke2(N);
>>>> elapsed time: 0.026985097 seconds (384 bytes allocated)
>>>>
>>>> Type annotations everywhere are neither necessary nor recommended. It
>>>> is recommended not to use lots of non-constant globals.
>>>>
>>>>
>>>> On Fri, Dec 12, 2014 at 9:36 AM, Tim Holy <[email protected]> wrote:
>>>>
>>>>> On Thursday, December 11, 2014 08:10:38 PM Petr Krysl wrote:
>>>>> > The moral of this story is: If you can't or won't declare every
>>>>> single
>>>>> > variable, don't do loops. They are likely to be a losing proposition.
>>>>>
>>>>> Just to follow up further, this is not at all the right moral to
>>>>> absorb from
>>>>> this. A better set of morals is:
>>>>> - use code_typed or TypeCheck or Lint to diagnose problems
>>>>> - remember that julia optimizes functions as a unit. Therefore, in a
>>>>> loop with
>>>>> a type issue, one "brute force" solution is to create a separate
>>>>> function just
>>>>> for running that loop. The types will be known when that function gets
>>>>> compiled (even if you don't annotate anything with their types), and
>>>>> so your
>>>>> type problem should evaporate.
>>>>>
>>>>> --Tim
>>>>>
>>>>>
>>>>
>>>
>>