Type instability with ntuple


#1

While experimenting with some performance bottlenecks, I found that

h1(n) = ntuple(i -> collect(0:1/n:1), 3)
@code_warntype h1(5)

show type instability (it cannot infer 3 as the length of the tuple), while

f(n) = ntuple(i -> n, 3)
g(n) = collect(0:1/n:1)
h2(n) = f(g(n))
@code_warntype h2(5)

seems to be fine.
I feel like this is non-expected behaviour and if possible I’d like h1 to be type stable without the need to split it up like that. Is this a known issue or am I just doing things the wrong way?


#2

On 0.6 both versions are type-unstable; presumably on 0.7 the second version is simple enough to benefit from the new constant-propagation optimization.

Anyway, you can pass Val{3}() if you want to force the length 3 to be a compile-time constant.

PS. Your h1 and h2 are inequivalent in another way: h1 has a different collected array in each tuple element, whereas h2 has a tuple of three references to the same array.


#3

Sorry for not mentioning, I’m on 0.7 master right now.
Thanks! I didn’t even know you could pass Val{n}() to ntuple, that is nice.
There might be other calls to Base-functions in my code, where I can pass Val{n}()s to enforce type stability.

Yes, h1 and h2 are indeed different in that sense, I didn’t notice when I put together the example.


#4

Note that you can write Val(3) instead. EDIT: On Julia 0.7