7e. Functions: Type Inference and Multiple Dispatch

Introduction

Functions play a central role in Julia to achieving high performance. This role of functions is by design: functions have been engineered from the outset to generate efficient machine code. In practice, it means that wrapping your code within functions isn't just good programming practice for facilitating logical structuring. It's actually necessary to attain fast execution.

However, to fully unlock the potential of functions, we must first understand the underlying process of function calls. Essentially, when a function is called, Julia attempts to identify concrete types for its variables, eventually selecting a corresponding computation method. At the heart of the process are three interconnected mechanisms: dispatch, compilation, and type inference. This section will provide a detailed explanation of each concept.

Functions and Methods

A function is simply a name that can be associated with different implementations. Each implementation is known as a method, which specifies the function body for a particular combination of argument types and number of arguments. You can inspect the methods associated with a function foo by executing methods(foo).

To see this in action, let's define several methods for the function foo1. Creating a method requires type-annotating the arguments of foo1 during its definition, which is implemented via the :: operator. In this way, we can set a distinct function body for each unique combination of argument types.

To keep matters simple, let's begin with a scenario where all the methods of foo1 take the same number of arguments, thus differing only in their types.

foo1(a,b)                  = a + b
foo1(a::String, b::String) = "This is $a and this is $b"

3

"This is some text and this is more text"

Since foo1(a,b) is equivalent to foo1(a::Any,b::Any), the first method sets the behavior of foo1 for every possible pair of argument types. After this, when we introduce the method foo1(a::String, b::String), we override that default for the specific case in which both arguments are strings. The existence of multiple methods explains why the two calls produce different outputs: the first method of foo1 is called with foo1(1, 2), whereas foo1("some text", "more text") triggers the second method.

The example also reveals that methods don't need to perform similar operations. Although it's usually unwise to group unrelated behaviors under a single function name, the ability to tailor implementations is central to performance-oriented programming. In practice, developers often exploit this flexibility to provide optimized algorithms for particular types, ensuring that a function can adapt its behavior while maintaining a coherent interface.

Also, methods don't need to have the same number of arguments. For instance, it's possible to define the following methods for a function foo2.

foo2(x)       = x
foo2(x, y)    = x + y
foo2(x, y, z) = x + y + z

1

3

6

Defining methods with different number of arguments is particularly useful for extending a function's behavior. A prime example is given by the function sum. So far, we've only used its simplest form sum(x), which adds all the elements of a collection x. However, sum also supports additional methods. One of them is sum(<function>, x), where the elements of x are transformed via <function> before being summed.

x = [2, 3, 4]

y = sum(x)          # 2 + 3 + 4
z = sum(log, x)     # log(2) + log(3) + log(4)

Type Inference

As we indicated, Julia produces the concrete machine code that will ultimately run the computation during compilation. This compilation in Julia happens on demand, right at the moment a function is first called with a new set of argument types. The strategy is known as Just-In-Time Compilation (JIT).

Most considerations for achieving high performance are tied to the compilation process. A key mechanism in it is type inference, whereby the compiler attempts to identify concrete types for all variables and expressions within the function body.

If the compiler succeeds in identifying concrete types, it can specialize instructions for each operation and yield fast code. For instance, type inference with the function foo defined above involves determining concrete types for 2, a = 1, and b = 2. Since all values have type Int64, the compiler can specialize the computation of 2 + a * b for variables with type Int64. This is the essence behind type stability, which we'll cover extensively in the next chapter.

On the contrary, if the compiler is unable to identify concrete types for some expressions, it must create generic code to accommodate multiple combinations of types. This forces Julia to perform type checks and conversions during runtime, significantly degrading performance.

Below, we provide various remarks about type inference that are worth keeping in mind for next sections.

Functions Do Not Guarantee The Identification of Concrete Types

Merely wrapping code in a function doesn't guarantee that the compiler will identify concrete types for all operations. The following example illustrates this.

x       = [1, 2, "hello"]    # Vector{Any}

foo3(x) = x[1] + x[2]        # type unstable

3

The issue in the example is that the compiler assigns the type Any to both x[1] and x[2], as they come from an object with type Vector{Any}. As a consequence, the compiler can't specialize the computation of the operation +. The example also highlights that compilation is exclusively based on types, not values. Thus, the generated code ignores the actual values x[1] = 1 and x[2] = 2, which would otherwise reveal the type Int64.

Global Variables Inherit Their Global Type

Type inference is restricted to local variable. Instead, any global variable inherits its type from the global scope. In the following examples, b and d are global variables. Consequently, the compiler defines b's type as Any and d as Number.

a         = 2
b         = 1

foo4(a)   = a * b

2

c         = 2
d::Number = 1

foo4(c)   = c * d

2

Type-Annotating Function Arguments Does Not Improve Performance

We pointed out that identifying concrete types is crucial for achieving high performance. This might wrongly suggest that explicitly annotating function arguments is necessary for performance, or at least beneficial. Such annotations are actually redundant, thanks to type inference. In fact, adding them can be counterproductive, as they unnecessarily restrict the types accepted by a function, thereby limiting its flexibility and potential applications.

To see how this loss of flexibility plays out, compare the following scripts.

foo5(a, b) = a * b

1.0

2

foo6(a::Float64, b::Float64) = a * b

1.0

The function on the first tab only accepts arguments of type Float64, implying that even integers are disallowed. By contrast, the function on the second tab also accepts the same behavior for Float64 inputs, but additionally allows for other types, due to implicit type annotation Any on the function arguments.

Packages Commonly Type-Annotate Function Arguments

When inspecting code of packages, you may notice that function arguments are often type-annotated. The reason for this isn't related to performance, but rather to ensure the function's intended usage, safeguarding against inadvertent type mismatches.

For instance, suppose a function that computes the revenue of a theater via nr_tickets * price. Importantly, the operator * in Julia not only implements product of numbers, but also concatenates words when applied to expressions with type String. Without type-annotations, the function could potentially be misused, as exemplified in the first tab below. The second tab precludes this possibility by asserting types.

Unannotated Function Type-Annotated Function

revenue1(nr_tickets, price) = nr_tickets * price

Output in REPL

julia>

revenue1(3, 2)

6

julia>

revenue1("this is ", "allowed")

"this is allowed"

revenue2(nr_tickets::Int64, price::Number) = nr_tickets * price

Output in REPL

julia>

revenue2(3, 2)

6

julia>

revenue2("this is ", "not allowed")

ERROR: MethodError: no method matching revenue2(::String, ::String)