This isn't exactly a bug since the answer is correct, it's an optimization that we don't yet do. (If all of those are bugs then every language implementation has an infinite number of bugs.) But yes, fixing this is on track. There's been a lot of recent work on Julia's IR which should make this problem resolvable soon.
On Tue, May 31, 2016 at 1:11 AM, 'Tobias Knopp' via julia-users < julia-users@googlegroups.com> wrote: > It would be great if this is resolvable. It took me quite some time to > determine that this is an issue in my own code. My mental model was that > type stability is about the return type being statically dependent on the > input parameter types. That a local binding has changed is quite a > different thing. > > Cheers, > > Tobias > > Am Dienstag, 31. Mai 2016 02:14:21 UTC+2 schrieb Yichao Yu: >> >> On Mon, May 30, 2016 at 7:54 PM, Erik Schnetter <schn...@gmail.com> >> wrote: >> > Yichao >> > >> > What is the known bug here: That Julia doesn't handle this more >> efficiently, >> >> The bug is that the type instability here is spurious. >> >> > 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 <yyc...@gmail.com> wrote: >> >> >> >> On Mon, May 30, 2016 at 7:23 PM, David P. Sanders <dpsa...@gmail.com> >> >> 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 <schn...@gmail.com> >> > http://www.perimeterinstitute.ca/personal/eschnetter/ >> >
