8f. Type Stability with Tuples

Introduction

A function is considered type stable when, given the types of its arguments, the compiler can accurately predict single concrete types for its expressions. This definition, while universal, takes on different forms when applied to specific objects. So far, we've exclusively concentrated on scalars and vectors, whose conditions for type stability are relatively straightforward.

In this section, we begin the analysis of type stability for other data structures. In particular, we cover tuples, deferring functions and types themselves to subsequent sections. Guaranteeing type stability with tuples is more nuanced compared to vectors, as their type characterization demands more information. Its exploration will challenge our understanding of type stability, demanding a clear grasp of its definition and subtleties.

Warning! - Tuples Are Only Suitable For Small Collections

Remember that tuples should only be used for collections that comprise a few elements. Using them for large collections will result in significant performance degradation, or directly trigger fatal errors.

Dispatch By Value

A key takeaway from the previous example is that defining tuples from vectors invariably introduce type instability. A simple remedy for this is to create the corresponding tuple outside the function, and then pass it as an argument. This is demonstrated in the code snippet below.

x   = [1, 2, 3]
tup = Tuple(x)

foo(tup) = sum(tup[1:2])

@code_warntype foo(tup)         # type stable

This approach should be your first consideration when addressing the type instability. Nonetheless, there may be scenarios where defining the tuple inside the function is unavoidable. For these cases, there are a few alternatives we could consider.

Note first that simply passing the vector's number of elements as an argument doesn't solve the issue. The reason is that the compiler generates method instances based on information about types, not values. This means that a function argument like length(x) merely informs that the number of elements has type Int64, without providing any additional insight.

Instead, one effective solution is to define the tuple's length using a literal value, as demonstrated below.

x   = [1, 2, 3]

function foo(x)
    tup = NTuple{length(x), eltype(x)}(x)

    sum(tup)
end

@code_warntype foo(x)        # type UNSTABLE

x   = [1, 2, 3]

function foo(x)
    tup = NTuple{3, eltype(x)}(x)

    sum(tup)
end

@code_warntype foo(tup)       # type stable

The downside of this solution is that it defeats the purpose of having a generic function, as it restricts the function to tuples of a single predetermined size. In this context, to eliminate the type instability without constraining functionality, we need to introduce a more advanced solution. This is based on a technique known as dispatch by value. Since this approach is more complex to implement, textit{I recommend using it only when passing the tuple as a function argument is unfeasible}.

Next, we lay out the principles of dispatch by value, and then apply the technique to the specific case of tuples.

Definition

Dispatch by value enables users to pass information about values to the compiler. Implementing this feature, nonetheless, requires a workaround, since the compiler only gathers information about types. The hack consists of creating a type that stores values as type parameters. In the case of tuples, this type parameter is simply the vector's number of elements.

The functionality is achieved via the built-in type Val, whose syntax can be best explained with an example. Suppose a function foo and a value a that you wish the compiler to know. The technique requires defining foo with a type-annotated argument having no name, ::Val{a}. After this, you must call foo passing an argument Val(a), which instantiates a type with parameter a.

To illustrate the syntax, we revisit an example from previous sections. This considers a variable y that could be an Int64 or Float64, contingent upon a condition. The ambiguity of y's type is then transmitted to any subsequent operation, leading to type instability.

Dispatch by value is implemented by defining the condition as a type parameter of Val. In this way, the compiler will receive information about whether condition is true or false, and therefore know y's type. This makes it possible to specialize its operations.

function foo(condition)
    y = condition ? 1 : 0.5      # either `Int64` or `Float64`
    
    [y * i for i in 1:100]
end

@code_warntype foo(true)         # type UNSTABLE
@code_warntype foo(false)        # type UNSTABLE

function foo(::Val{condition}) where condition
    y = condition ? 1 : 0.5      # either `Int64` or `Float64`
    
    [y * i for i in 1:100]
end

@code_warntype foo(Val(true))    # type stable
@code_warntype foo(Val(false))   # type stable

Warning!

The function argument Val must be defined with {}, but called with (). This is because types define their parameters with {}, while instances of types require functions.

Dispatching by Value with Tuples

Let's now revisit the conversion of vectors to tuples. As we previously discussed, type instability arises because vectors don't store their size as part of their type information, leaving the compiler without sufficient information to determine the tuple's type.

Dispatch by value provides a solution to this issue: by passing the vector's length as a type parameter, the function call becomes type stable.

x = [1, 2, 3]

function foo(x, N)
    tuple_x = NTuple{N, eltype(x)}(x)   

    2 .+ tuple_x    
end

@code_warntype foo(x, length(x))        # type UNSTABLE

x = [1, 2, 3]

function foo(x, ::Val{N}) where N
    tuple_x = NTuple{N, eltype(x)}(x)   

    2 .+ tuple_x    
end

@code_warntype foo(x, Val(length(x)))   # type stable