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
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
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 ste...@karpinski.org:
From the original version of the code I see this timing after code gen:
julia @time Ke1(N);
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
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 ste...@karpinski.org:
Yikes, that's
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
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},
I wrote a comment in the gist.
2014-12-11 17:08 GMT-05:00 Robert Gates robert.ga...@gmail.com:
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
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 robert...@gmail.com javascript:
:
In
https://gist.github.com/anonymous/4ec426096c02faa4354d#comment-1354636
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
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
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, ())
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()
14 matches
Mail list logo
