Julia v1.10: Performance, a new parser, and more

The new year arrived bearing a new version of Julia, a general-purpose, open-source programming language with a focus on high-performance scientific computing. Some of Julia's unusual features are Lisp-inspired metaprogramming, the ability to examine compiled representations of code in the REPL or in a "reactive notebook", an advanced type and dispatch system, and a sophisticated, built-in package manager. Version 1.10 brings big increases in speed and developer convenience, especially improvements in code precompilation and loading times. It also features a new parser written in Julia.

Time to first x

The time needed to import packages has been a common annoyance since the first public release of Julia. This is sometimes called the "time to first plot", or, more generally, the "time to first x", where "x" is the output of some function when called for the first time from a freshly loaded package. Nearly every major release of Julia has improved compilation and loading times.

The latest release decreases these delays to the point where the strategy of creating custom system images with pre-loaded packages is largely no longer needed, as Chris Rackauckas pointed out. This strategy used the PackageCompiler module to make a custom Julia binary with one's commonly-used packages baked in, so it could start up instantly, ready to plot or perform other tasks without delays. The section "Creating binaries" below discusses this further.

I borrowed an example from that Hacker News discussion, and timed a simple "using Plots; plot(sin)" using Julia v1.10 on a low-powered laptop. It reported a wall-clock time of 2.16 seconds; in that time, it needed to load the Julia runtime, import the Plots package, and create a simple plot. Note that this experiment does not use a fresh Julia install. Plots has already been downloaded and precompiled (along with its dependencies), which can take some time, but that's a one-time cost. To get a sense of the improvements in v1.10, I repeated the same timed command with the two previous versions of Julia that I still have installed. Julia v1.9 takes 3.6 seconds, and v1.8 takes 18.1 seconds.

The Julia developers employed several strategies to achieve this latest improvement in code loading. The previous major release introduced native code caching and package extensions for weak dependencies, as well as the ability for package authors to ship precompiled, native binary code with their software. Some of the recent improvement in loading time is due to package developers taking greater advantage of these two mechanisms; as these practices spread through the community we'll see further decreases in latencies even without improvements to Julia itself.

The latest release corrects an oversight in the generation of code caches: previously, if a user was compiling code with more than one instance of Julia (a situation that can arise in parallel computing environments), a race condition might ensue, with different Julia processes writing to the same cache files simultaneously. Now this problem has been eliminated using lock files.

Part of the reduction in package load time is the result of parallelizing the initial stage of precompilation. The precompilation that happens upon installation of packages has been done in parallel for a long time, but the later stage, when the user imports functions into a program or environment, was a serial process until v1.10. It is this stage of precompilation that affects responsiveness in daily use, so speeding this up has a greater impact when working in the REPL or running programs.

Julia ships with a version of LLVM containing patches to fix bugs, mainly in numerical methods. The upgrade to LLVM 15 that came with v1.10 also had an impact on Julia's responsiveness, as the new compiler version has better performance.

For users who'd like to keep a closer eye on package precompilation times in the REPL, the command Pkg.precompile(timing=true) will precompile any packages in your environment that require it, and supply a per-package report of compilation times.

Language, libraries, and runtime

In addition to faster precompilation, v1.10 brings improved runtime performance and some developer conveniences.

The Julia parser has, since v1.0 until now, been implemented in Femtolisp. This Scheme dialect was, in the words of its creator, Jeff Bezanson (one of the inventors of Julia), in its README, "an attempt to write the fastest lisp interpreter I could in under 1000 lines of C".

With v1.10, the Femtolisp parser has been replaced with a parser written in Julia. The new parser brings three advantages: it is faster, it produces more useful syntax-error messages, and it provides better source-code mapping, which associates locations in compiled code to their corresponding lines in the source. That last improvement also leads to better error messages and makes it possible to write more sophisticated debuggers and linters.

The next figure illustrates the improved error reporting in v1.10:

As can be seen, the exact position of the error is indicated. The same error committed using v1.9 produces a somewhat less friendly message, mentioning the extra space but not pointing out its location visually.

Femtolisp still performs code lowering for the language. In the latest version, as in earlier iterations, starting an interactive session with the --lisp flag takes you to the Femtolisp REPL.

Stack traces have also been made more concise and useful by omitting unnecessary information, addressing a frequent complaint from Julia programmers.

Julia has always used a tracing garbage collector. Application programmers have never had to know anything about this, although, as an optimization, it is often possible to avoid garbage collection entirely by taking care not to allocate memory dynamically. Nevertheless, for some algorithms these strategies won't work.

Run-time performance in v1.10 was improved by parallelizing the mark phase of the garbage collector, achieving nearly linear speedup as a function of the number of threads allocated to garbage collection. Julia can be started with any number of worker threads, set with the -t flag. The number of threads used for garbage collection is half the number of worker threads, by default, but the user can set this with the new --gcthreads flag.

The use of Unicode characters has received some tweaks and refinements, as usual in any Julia release. There are two new fancy arrows (⥺ and ⥷) available to be used as names for binary operators. Physicists will be relieved to learn that two similar glyphs for hbar are now treated as identical. The glyph ∜ computes the fourth root, unsurprisingly, using a new function in Base.math called fourthroot(). Its implementer was motivated by the desire to not "let a perfectly good Unicode symbol go to waste", and also points out that fourthroot() is faster than what some programmers might turn to: x^(1/4).

Speaking of new functions, there is a generous handful in the new release. The tanpi(x) function calculates tan(xπ) more accurately for large arguments. For example, noting that tan(π/4) = 1 exactly, and the tangent has a period of π:

    julia> tanpi(1/4 + 2e10)
    0.9999999999999999

    julia> tan((1/4 + 2e10)*π)
    0.999995497014194

Some new memory-related functions, memmove(), memset(), and memcpy(), were added to Julia's C standard library, to aid in interacting with C library routines.

The function in Base for calculating binomial coefficients, binomial(x, n) (x choose n), now accepts non-integer x, applying the standard definition for extended binomial coefficients; n must still be an integer.

Julia has a printstyled() function that writes messages to the screen with optional effects including colors, underline, reverse video, and others; whether the user sees the effects depends on the capabilities of the terminal emulator in use. Julia v1.10 adds an italic option.

A View in Julia is a section of an array (called the parent), with which it shares memory. The function parent() returns the View's parent array. A SubString applies the same idea to strings: it's a piece of a parent string that doesn't create a new object. Previously parent() only worked with array Views. Now the function has been extended to work with SubString types:

    julia> s = "abcdefgh"
    "abcdefgh"

    julia> ss = SubString(s, 6:8)
    "fgh"

    julia> ss[1]
    'f': ASCII/Unicode U+0066 (category Ll: Letter, lowercase)

    julia> parent(ss)
    "abcdefgh"

The startswith() function determines whether a string starts with a given character or substring. This has now been extended to work with I/O streams (for example, files). It looks at the stream not from the beginning, but from the current read position, as shown in this example:

    julia> maybePNG = open("fig1.png")
    IOStream(<file fig1.png>)

    julia> seek(maybePNG, 1);

    julia> startswith(maybePNG, "PNG")
    true

    julia> position(maybePNG)
    1

This example checks for the magic number one byte into the file to determine if it might be a PNG image. The startswith() function peeks at the required extent of the stream without changing the read position, as shown in the last line of the example.

In Julia rational numbers are defined and displayed with a double slash, such as 3//4. In the latest release, when printing an array, rational numbers are displayed as integers if they have an integral value (if they can be reduced to having a denominator of one). Here's an example:

    julia> TM = Matrix{Rational}(undef, 5, 5);

    julia> for i ∈ 1:5, j ∈ 1:5
              if j<i
                  TM[i, j] = i//j
              else
                  TM[i, j] = 0//1
              end
           end

    julia> TM
    5×5 Matrix{Rational}:
    0   0     0     0    0
    2   0     0     0    0
    3  3//2   0     0    0
    4   2    4//3   0    0
    5  5//2  5//3  5//4  0

This constructs a lower triangular matrix whose structure is easy to see at a glance. Here is the way previous versions of Julia display the same array:

    0//1  0//1  0//1  0//1  0//1
    2//1  0//1  0//1  0//1  0//1
    3//1  3//2  0//1  0//1  0//1
    4//1  2//1  4//3  0//1  0//1
    5//1  5//2  5//3  5//4  0//1

This style of displaying rational numbers only applies to members of arrays; outside of that context, there is no change.

The new release comes with a few technical refinements to the linear algebra library, which is part of the standard library. One new addition is the hermitianpart() function, which efficiently calculates the Hermitian part of a square matrix.

Creating binaries

The normal way to use Julia is to download and install the runtime and to work either in an interactive environment, such as the REPL or a Pluto notebook, or to run program files from the command line, using the julia shell command. In both styles, the compiler is available to generate new native machine code whenever it encounters a function call with a combination of argument types that has not previously been compiled. This allows making full use of multiple dispatch and user-defined types without sacrificing performance, aside from the necessary compile times when code for a new method needs to be generated.

There are other usage scenarios, however, that are not satisfied by the standard mechanisms. We may want to eliminate as much compiler delay as possible, for example if a Julia program is called repeatedly in a shell script. Even the small compilation penalties still present in v1.10 could be undesirable. Or we may want to give our program to someone who, for some odd reason, does not have the Julia runtime installed. In this case, they would need a standalone binary version of our program.

There are two main packages that provide utilities for generating various types of compiled Julia programs. StaticCompiler is a package that can make small, statically compiled binaries from sources written in a severely limited subset of Julia. It's an experimental package intended for adventurous programmers. StaticCompiler is the basis of ongoing experiments in compiling Julia to WebAssembly for running in web browsers. The past year has seen significant progress in that area.

A more generally useful tool is the package PackageCompiler. It can compile programs written in unconstrained Julia into either sysimages or into distributable, standalone binaries. The former target is used in order to have a Julia environment with a set of packages baked in that starts up instantly. This was a great help in earlier versions of Julia, when precompilation times interfered with using Julia programs as routine utilities (a script that took half a minute to plot a small bit of data was inconvenient). Now that precompilation and load times are so much smaller, this use of PackageCompiler is almost obsolete.

But it is still the standard utility for creating binaries for distribution or for use in environments where the Julia runtime is not installed. While still under active development, it's a mature tool. Until recently, the main complaint has been the enormous size of the compiled programs: PackageCompiler would turn a "hello world" program into a 900MB monstrosity. This is because everything was included; not only the entire Julia runtime, but everything in the standard library. For example, the BLAS routines were included even if the program didn't do any linear algebra.

In the past year, the size of a compiled "hello world" program has come down to 50MB, making the PackageCompiler approach far more practical. This progress results from stripping out unneeded parts of the runtime and unused libraries. This work is ongoing, and is a strong focus of developer activity. Bezanson gave an informative talk about the history of this progress.

Learning resources

Julia's official manual is compendious and accurate, but its organization can make it difficult to find what you need, especially if you're a beginner. Fortunately Julia has been in use long enough now that a constellation of articles and books has grown around it, written by authors from a wide variety of backgrounds and aimed at readers from beginning programmers to working scientists experienced with computation. Several books have recently appeared by authors whose Julia articles over the past several years I've found illuminating; for example, Bogumił Kamiński, Erik Engheim, and Logan Kilpatrick. Their books, as well as my volume, are collected into a list maintained on the official Julia site.

Another good resource for learning more about Julia and the projects taking advantage of it are the talks from JuliaCon on YouTube.

Finally, once you're exploring the language and ecosystem in earnest, the Julia Discourse discussion platform will become a valuable resource. Julia developers, package authors, and experienced users participate actively; the community is welcoming, patient, and helpful.

Conclusion

Between the improvements in precompilation and loading times, and the progress in making small binaries, two major and perennial complaints, of beginners and seasoned Julia users alike, have been addressed. Work on both these areas continues and is likely to see more improvement in the near future, especially in the area of binary generation. StaticCompiler and related WebAssembly tools will make it easier to write web applications in Julia for direct execution in the browser; it is already possible, but may become more convenient over the next few years.