Yichao What is the known bug here: That Julia doesn't handle this more efficiently, or that the variable `x` can change its type from Int to Float64?
In this example, are there two variables `x` (the argument and the explicitly declared local variable), or should the declaration be an error? -erik On Mon, May 30, 2016 at 7:47 PM, Yichao Yu <[email protected]> wrote: > On Mon, May 30, 2016 at 7:23 PM, David P. Sanders <[email protected]> > wrote: > > > > > > El lunes, 30 de mayo de 2016, 19:11:47 (UTC-4), FANG Colin escribió: > >> > >> function t1(n::Int, x::Int, a::Float64) > >> x::Float64 = x > >> for i in 1:n > >> x += a > >> end > >> x > >> end > >> @time t1(10^6, 1, 1.0) > >> > >> 0.005445 seconds (1.00 M allocations: 15.259 MB) > > > > > > In t1, x changes type during the function, from Int to Float64, so the > > function is type *un*stable, as shown by @code_warntype, > > and as suggested by the huge number of allocations. > > > > In t2, x is always a Float64, and the function is type stable. > > > >> > >> > >> > >> > >> > >> function t2(n::Int, y::Int, a::Float64) > >> x::Float64 = y > >> for i in 1:n > >> x += a > >> end > >> x > >> end > >> @time t2(10^6, 1, 1.0) > >> > >> 0.001044 seconds (6 allocations: 192 bytes) > >> > >> > >> > >> > >> The @code_warntype of the 2 functions are very similar. However, the > llvm > >> code generated from t2 is a lot simpler. > > > > > > The @code_warntype of the two functions is very *different*. (This is > easier > > to see in the REPL than in the notebook, if > > that is the problem.) > > > >> > >> > >> Does it suggest that if we want to change the type of an argument, we'd > >> better create a new variable? > > This is a known bug. Fortunately it's easy to catch with code_warntype. > -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
