Re: [julia-users] Re: Aren't loops supposed to be faster?

[Petr Krysl]

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 
> ).
>  
> 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  
>> 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 :
>>>
>>> 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  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
>
>

>>>
>>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Petr Krysl]

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 
).
 
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  > 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 > >:
>>
>> 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 >> > 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


>>>
>>
>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Andreas Noack]

The problem in the updated version I linked to seems to be extracting the
type of the properties of nested composite types so wondered if you had any
general comment to that, i.e. using complicated types as inputs.

2014-12-12 10:25 GMT-05:00 Stefan Karpinski :
>
> 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 <
> andreasnoackjen...@gmail.com> 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 :
>>
>> 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  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


>>>
>>
>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Stefan Karpinski]

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 <
andreasnoackjen...@gmail.com> 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 :
>
> 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  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
>>>
>>>
>>
>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Andreas Noack]

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 :

> 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  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
>>
>>
>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Stefan Karpinski]

>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  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
>
>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Tim Holy]

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

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Petr Krysl]

Clever.   Thanks!

Petr


On Thursday, December 11, 2014 9:26:34 PM UTC-8, John Myles White wrote:
>
> Petr, 
>
> You should be able to do something like the following: 
>
> function foo(n::Integer) 
> if iseven(n) 
> return 1.0 
> else 
> return 1 
> end 
> end 
>
> function bar1() 
> x = foo(1) 
> return x 
> end 
>
> function bar2() 
> x = foo(1)::Int 
> return x 
> end 
>
> julia> code_typed(bar1, ()) 
> 1-element Array{Any,1}: 
>  :($(Expr(:lambda, Any[], 
> Any[Any[:x],Any[Any[:x,Union(Float64,Int64),18]],Any[]], :(begin  # none, 
> line 2: 
> x = foo(1)::Union(Float64,Int64) # line 3: 
> return x::Union(Float64,Int64) 
> end::Union(Float64,Int64) 
>
> julia> code_typed(bar2, ()) 
> 1-element Array{Any,1}: 
>  :($(Expr(:lambda, Any[], Any[Any[:x],Any[Any[:x,Int64,18]],Any[]], 
> :(begin  # none, line 2: 
> x = (top(typeassert))(foo(1)::Union(Float64,Int64),Int)::Int64 # 
> line 3: 
> return x::Int64 
> end::Int64 
>
> In the output of code_typed, note how the strategically placed type 
> declaration at the point at which a type-unstable function is called 
> resolves the type inference problem completely when you move downstream 
> from the point of ambiguity. 
>
>  -- John 
>
> On Dec 12, 2014, at 12:20 AM, Petr Krysl > 
> wrote: 
>
> > John, 
> > 
> > I hear you.   I agree with you  that type instability is not very 
> helpful,  and indicates  problems with program design. 
> > However, I believe that  provided the program cannot resolve  the types 
> properly  (as it couldn't in the original design of my program, because I 
> haven't provided  declarations  of  variables where they were getting used, 
>  only in their data structure  types that the compiler apparently couldn't 
> see), the optimization  for loop performance  cannot be successful. It 
> certainly wasn't successful in this case. 
> > 
> > How would you solve  the problem with  storing a function and at the 
> same time allowing the compiler to deduce what  values it returns?  In my 
> case I store a function that always returns a floating-point array.   
> However, it may return a constant value supplied as input to the 
> constructor,  or it may return the value provided by another function (that 
> the  user of the type supplied). 
> > 
> > So, the type  of the return value is  stable, but I haven't found a way 
> of informing the compiler that it is so. 
> > 
> > Petr 
> > 
> > 
> > 
> > 
> > On Thursday, December 11, 2014 8:20:20 PM UTC-8, John Myles White 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. 
> > 
> > I don't think this lesson will serve most people well. It doesn't 
> reflect my experiences using Julia at all. 
> > 
> > My experience is that code that requires variable type declarations 
> usually suffers from a deeper problem that the variable declarations 
> suppress without solving: either (a) there's some insoluble source of 
> ambiguity in the program (as occurs when calling a function that's passed 
> around as a value and therefore not amenable to static analysis) or (b) 
> there's some subtle source of type instability, as happens sometimes when 
> mixing integers and floating point numbers. 
> > 
> >  -- John 
> > 
>
>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[John Myles White]

Petr,

You should be able to do something like the following:

function foo(n::Integer)
if iseven(n)
return 1.0
else
return 1
end
end

function bar1()
x = foo(1)
return x
end

function bar2()
x = foo(1)::Int
return x
end

julia> code_typed(bar1, ())
1-element Array{Any,1}:
 :($(Expr(:lambda, Any[], 
Any[Any[:x],Any[Any[:x,Union(Float64,Int64),18]],Any[]], :(begin  # none, line 
2:
x = foo(1)::Union(Float64,Int64) # line 3:
return x::Union(Float64,Int64)
end::Union(Float64,Int64)

julia> code_typed(bar2, ())
1-element Array{Any,1}:
 :($(Expr(:lambda, Any[], Any[Any[:x],Any[Any[:x,Int64,18]],Any[]], :(begin  # 
none, line 2:
x = (top(typeassert))(foo(1)::Union(Float64,Int64),Int)::Int64 # line 3:
return x::Int64
end::Int64

In the output of code_typed, note how the strategically placed type declaration 
at the point at which a type-unstable function is called resolves the type 
inference problem completely when you move downstream from the point of 
ambiguity.

 -- John

On Dec 12, 2014, at 12:20 AM, Petr Krysl  wrote:

> John,
> 
> I hear you.   I agree with you  that type instability is not very helpful,  
> and indicates  problems with program design. 
> However, I believe that  provided the program cannot resolve  the types 
> properly  (as it couldn't in the original design of my program, because I 
> haven't provided  declarations  of  variables where they were getting used,  
> only in their data structure  types that the compiler apparently couldn't 
> see), the optimization  for loop performance  cannot be successful. It 
> certainly wasn't successful in this case.
> 
> How would you solve  the problem with  storing a function and at the same 
> time allowing the compiler to deduce what  values it returns?  In my case I 
> store a function that always returns a floating-point array.   However, it 
> may return a constant value supplied as input to the constructor,  or it may 
> return the value provided by another function (that the  user of the type 
> supplied).
> 
> So, the type  of the return value is  stable, but I haven't found a way of 
> informing the compiler that it is so.
> 
> Petr
> 
> 
> 
> 
> On Thursday, December 11, 2014 8:20:20 PM UTC-8, John Myles White 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. 
> 
> I don't think this lesson will serve most people well. It doesn't reflect my 
> experiences using Julia at all. 
> 
> My experience is that code that requires variable type declarations usually 
> suffers from a deeper problem that the variable declarations suppress without 
> solving: either (a) there's some insoluble source of ambiguity in the program 
> (as occurs when calling a function that's passed around as a value and 
> therefore not amenable to static analysis) or (b) there's some subtle source 
> of type instability, as happens sometimes when mixing integers and floating 
> point numbers. 
> 
>  -- John 
> 

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Petr Krysl]

John,

I hear you.   I agree with you  that type instability is not very helpful,  
and indicates  problems with program design. 
However, I believe that  provided the program cannot resolve  the types 
properly  (as it couldn't in the original design of my program, because I 
haven't provided  declarations  of  variables where they were getting 
used,  only in their data structure  types that the compiler apparently 
couldn't see), the optimization  for loop performance  cannot be 
successful. It certainly wasn't successful in this case.

How would you solve  the problem with  storing a function and at the same 
time allowing the compiler to deduce what  values it returns?  In my case I 
store a function that always returns a floating-point array.   However, it 
may return a constant value supplied as input to the constructor,  or it 
may return the value provided by another function (that the  user of the 
type supplied).

So, the type  of the return value is  stable, but I haven't found a way of 
informing the compiler that it is so.

Petr




On Thursday, December 11, 2014 8:20:20 PM UTC-8, John Myles White 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. 
>
> I don't think this lesson will serve most people well. It doesn't reflect 
> my experiences using Julia at all. 
>
> My experience is that code that requires variable type declarations 
> usually suffers from a deeper problem that the variable declarations 
> suppress without solving: either (a) there's some insoluble source of 
> ambiguity in the program (as occurs when calling a function that's passed 
> around as a value and therefore not amenable to static analysis) or (b) 
> there's some subtle source of type instability, as happens sometimes when 
> mixing integers and floating point numbers. 
>
>  -- John 
>
>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[John Myles White]

> 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.

I don't think this lesson will serve most people well. It doesn't reflect my 
experiences using Julia at all.

My experience is that code that requires variable type declarations usually 
suffers from a deeper problem that the variable declarations suppress without 
solving: either (a) there's some insoluble source of ambiguity in the program 
(as occurs when calling a function that's passed around as a value and 
therefore not amenable to static analysis) or (b) there's some subtle source of 
type instability, as happens sometimes when mixing integers and floating point 
numbers.

 -- John

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Robert Gates]

Hi Ivar,

yeah, I know, I thought Andreas was replying to my deleted post. I think 
Petr already solved the problem with the globals (his gist was apparently 
not the right context). However, he still reported:

On Thursday, December 11, 2014 6:47:33 PM UTC+1, Petr Krysl wrote:
>
> One more note: I conjectured that perhaps the compiler was not able to 
> infer correctly the type of the matrices,  so I hardwired (in the actual FE 
> code)
>
> Jac = 1.0; gradN = gradNparams[j]/(J); # get rid of Rm for the moment
>
> About 10% less memory used, runtime about the same.  So, no effect really. 
> Loops are still slower than the vectorized code by a factor of two.
>
> Petr
>
>
Best,

Robert

On Friday, December 12, 2014 12:01:44 AM UTC+1, Ivar Nesje wrote:
>
> https://gist.github.com/anonymous/4ec426096c02faa4354d#comment-1354636

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Ivar Nesje]

https://gist.github.com/anonymous/4ec426096c02faa4354d#comment-1354636

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Robert Gates]

Yeah, I think I figured it out on my own, hence the message deletion. 
Nonetheless, I don't see your comment.

On Thursday, December 11, 2014 11:29:15 PM UTC+1, Andreas Noack wrote:
>
> I wrote a comment in the gist.
>
> 2014-12-11 17:08 GMT-05:00 Robert Gates 
> >:
>
>> In any case, this does make me wonder what is going on under the hood... 
>> I would not call the vectorized code "vectorized". IMHO, this should just 
>> pass to BLAS without overhead. Something appears to be creating a bunch of 
>> temporaries.
>>
>> On Thursday, December 11, 2014 5:47:01 PM UTC+1, Petr Krysl wrote:
>>
>>> Acting upon the advice that replacing matrix-matrix multiplications in 
>>> vectorized form with loops would help with performance, I chopped out a 
>>> piece of code from my finite element solver (https://gist.github.com/
>>> anonymous/4ec426096c02faa4354d) and ran some tests with the following 
>>> results:
>>>
>>> Vectorized code:
>>> elapsed time: 0.326802682 seconds (134490340 bytes allocated, 17.06% gc 
>>> time)
>>>
>>> Loops code:
>>> elapsed time: 4.681451441 seconds (997454276 bytes allocated, 9.05% gc 
>>> time) 
>>>
>>> SLOWER and using MORE memory?!
>>>
>>> I must be doing something terribly wrong.
>>>
>>> Petr
>>>
>>>
>

Re: [julia-users] Re: Aren't loops supposed to be faster?

[Andreas Noack]

I wrote a comment in the gist.

2014-12-11 17:08 GMT-05:00 Robert Gates :

> In any case, this does make me wonder what is going on under the hood... I
> would not call the vectorized code "vectorized". IMHO, this should just
> pass to BLAS without overhead. Something appears to be creating a bunch of
> temporaries.
>
> On Thursday, December 11, 2014 5:47:01 PM UTC+1, Petr Krysl wrote:
>
>> Acting upon the advice that replacing matrix-matrix multiplications in
>> vectorized form with loops would help with performance, I chopped out a
>> piece of code from my finite element solver (https://gist.github.com/
>> anonymous/4ec426096c02faa4354d) and ran some tests with the following
>> results:
>>
>> Vectorized code:
>> elapsed time: 0.326802682 seconds (134490340 bytes allocated, 17.06% gc
>> time)
>>
>> Loops code:
>> elapsed time: 4.681451441 seconds (997454276 bytes allocated, 9.05% gc
>> time)
>>
>> SLOWER and using MORE memory?!
>>
>> I must be doing something terribly wrong.
>>
>> Petr
>>
>>