With the Racket 8.7 release, Typed Racket includes two languages that weaken the run-time behavior of types: Shallow Typed Racket and Optional Typed Racket. Whereas normal Typed Racket types (Deep types) enforce guarantees that any module can depend on, Shallow types enforce only local invariants in typed code, and Optional types enforce nothing. In return, Shallow and Optional types add less overhead to gradual interactions. Code often runs faster and simpler than with Deep types.

Shallow Typed Racket and Optional Typed Racket use the same static types and typechecker as normal (Deep) Typed Racket.

1  Background: Typed–Untyped Interaction

A key feature of Typed Racket is that it allows typed code to interact with untyped code. An untyped module can import from a typed one with a normal require form, and a typed module can import from an untyped one by using a require/typed form:

For example, if an untyped module provides a struct and a function:

then a typed module can import the untyped bindings:

So far so good. One program combines untyped and typed code.

Now, what if the declared types are wrong?

The module below gives a wrong type to the distance function. This type expects an integer result instead of a real number:

Even with the wrong type, the program still typechecks (!) because Typed Racket does not analyze untyped code. It assumes the require/typed types are correct and moves on.

But this program does have a type error. At run-time, the call to distance returns a float instead of an integer, contradicting the static type.

If we want to catch the error, then Typed Racket needs to enforce types at run-time when typed and untyped code interact.

2  Enforcing Type Boundaries

By default, Typed Racket compiles types to higher-order contracts. The function type (-> pt pt Integer), for example, compiles to a function contract that will raise an exception if gets attached to a function that eventually returns a non-integer result.

Contracts enforce types with strong guarantees and offer useful debugging information if an error occurs. But they can also be expensive, especially when large, mutable, or higher-order values frequently cross boundaries. These high costs inspired a long search for cheaper ways to enforce types than the standard Deep strategy.

Two promising alternatives are Shallow and Optional types, neither of which use higher-order contracts.

Shallow types use lightweight assertions called shape checks to provide a basic soundness guarantee. Instead of putting heavy contracts at module boundaries, Shallow Typed Racket rewrites typed code to incrementally check the shape of values.

Optional types use no checks. They are completely unreliable for reasoning about typed-untyped interactions. But, they also have zero cost.

3  How to Select an Enforcement Strategy

The #lang of a Typed Racket module decides how its types behave at run-time. To change strategies, change the language.

• Deep types: typed/racket, typed/racket/base, typed/racket/deep, or typed/racket/base/deep.

• Shallow types: typed/racket/shallow or typed/racket/base/shallow.

• Optional types: typed/racket/optional or typed/racket/base/optional.

For a complete list of forms that change depending on the #lang, see Forms that Depend on the Behavior of Types in the Typed Racket Reference.

4  Example: Fewer Run-time Checks

Deep types can be significantly more expensive than Shallow and Optional. For example, the two functions below expect a data structure and access part of the data: list-first returns the first element of a list and vec-length counts the number of elements in a vector.

When these functions get called from untyped code, they have very different costs depending on the behavior of types:

• Deep types check all incoming data structures exhaustively. Lists undergo a full traversal that validates every list element, including unused ones. Vectors get wrapped in a chaperone to guard against future writes.

• Shallow types check the shape of the incoming data structures using list? and vector?. Elements of these structures get checked only when they are used by typed code.

• Optional types check nothing at all.

Further Reading has links to larger examples where the costs of Deep types are huge compared to Shallow and Optional.

5  Example: Weaker Types, Simpler Behavior

Shallow and Optional types raise fewer run-time errors than Deep. In many cases, the lack of an error means that a bug goes undetected. Deep finds the bug and the other two miss it because they skipped a run-time check.

But for some programs, the Deep types are too cautious. They reject a program that could run safely.

One restrictive type in the Deep world is Procedure, the type that describes any function. Because this type says nothing about argument and return types, Deep Typed Racket never allows calls to a procedure, even after a cast:

Shallow types do allow calls to a Procedure, after a cast:

Optional types also allow calls to a Procedure:

6  Four-Way Interactions

Typed–untyped interactions are much more exciting now that “typed code” can be Deep, Shallow, or Optional. These three styles of typed code can all interact with untyped code (of course), and they can also interact with one another.

Types in this four-way world need to be enforced at run-time depending on how they were defined:

• Deep types get enforced with contracts at all boundaries to non-Deep code. This means that Deep–Shallow and Deep–Optional interactions can be expensive.

• Shallow types guard the boundaries to Optional and untyped code with shape checks.

• Optional types never enforce themselves. But a Deep-typed or Shallow-typed client of Optional code will insert run-time checks as a consequence of their strategies.

These checks between Deep, Shallow, and Optional may come as a surprise, especially because all typed code gets validated by the same static type checker. But the checks are necessary because run-time interactions can mix untyped values into some of these typed modules. If an Optional module were to import an untyped function and send it to Deep-typed code without a contract wrapper, it could break the Deep type guarantees.

7  Reflections on Deep, Shallow, and Optional

Deep types, Shallow types, and Optional types have complementary strengths. When and where does each one work best? Here are a few suggestions, based on When to Use Deep, Shallow, or Optional? from the Typed Racket Guide:

• Deep types make the most of static checking and optimizations. Use them for self-sufficient groups of typed modules. Avoid them at high-traffic boundaries to untyped or to non-Deep code.

• Shallow types provide a weak but useful soundness guarantee at low cost. Use them in typed modules that frequently communicate with the untyped world. Avoid them, however, in large typed modules because every expression in typed code potentially needs a Shallow shape check.

• Optional types use types for static analysis and nothing more. Use them when you do not want types enforced at run-time.

We are very excited to have these languages in the Typed Racket family. Learning more about where they fit in practical applications and about how developers tend to use them will be part of the adventure.

8  Further Reading

• Typed-Untyped Interaction in the Typed Racket Guide

• Deep, Shallow, and Optional Semantics in the Typed Racket Reference

• For the theoretical and practical motivation:
  Ben Greenman. Deep and Shallow Types for Gradual Languages. PLDI 2022.
  Paper at https://www2.ccs.neu.edu/racket/pubs/g-pldi-2022.pdf
  Slides at https://cs.brown.edu/people/bgreenma/publications/apples-to-apples/g-pldi-2022-slides.pdf

• Shallow Typed Racket is based on the Transient semantics from Reticulated Python:
  Michael M. Vitousek, Cameron Swords, and Jeremy G. Siek. Big Types in Little Runtime: Open-World Soundness and Collaborative Blame for Gradual Type Systems. POPL 2017.
  Paper at https://dl.acm.org/doi/10.1145/3009837.3009849

• Vitousek’s dissertation has much more to say about Reticulated and Transient:
  Michael M. Vitousek. Gradual Typing for Python, Unguarded. PhD thesis, Indiana University, 2019. https://hdl.handle.net/2022/23172

• Greenman’s dissertation says more about combining Deep and Shallow in Typed Racket:
  Ben Greenman. Deep and Shallow Types. PhD thesis, Northeastern University, 2020. http://hdl.handle.net/2047/D20398329

Racket version 8.7 is now available from https://download.racket-lang.org/

As of this release:

• Typed Racket offers Shallow and Optional modes for its gradual types. These modes lower the cost of interacting with untyped code, but provide less protection against buggy interactions. (see https://docs.racket-lang.org/ts-reference/behavior-of-types.html )

• Racket uses Unicode 14.0 for character and string operations, and includes grapheme operations. DrRacket supports emojis. (see https://docs.racket-lang.org/gui/editor-overview.html#%28part._graphemes%29 )

• Racket supports RV64G (RISC-V).

• Programmers can disable definition shadowing using (#%declare #:require=define). (see https://docs.racket-lang.org/reference/module.html#%28form.%28%28quote.~23~25kernel%29._~23~25declare%29%29 )

• The module dependency graphs available using raco dependencies-graph and DrRacket’s Module browser are faster and have new package filtering support. (see https://docs.racket-lang.org/drracket/module-browser.html#%28idx._%28gentag.39.%28lib._scribblings%2Fdrracket%2Fdrracket..scrbl%29%29%29 )

• DrRacket is more responsive when killing programs that produce a lot of output.

• Plot 3D allows negative altitude values (e.g., looking at the plot from “below”). (see https://docs.racket-lang.org/plot/plotting.html#%28def._%28%28lib._plot%2Fmain..rkt%29._plot3d%29%29 )

• The scriblib/bibtex and scriblib/autobib libraries support DOIs. (see https://docs.racket-lang.org/scriblib/autobib.html#%28def._%28%28lib._scriblib%2Fautobib..rkt%29._make-bib%29%29 )

• There are many other repairs and improvements!

The following people contributed to this release:

Adit Cahya Ramadhan, Alex Harsányi, Bart van Strien, Ben Greenman, Bob Burger, Bogdan Popa, Cameron Moy, cheeze2000, D. Ben Knoble, Dan Anderson, Fred Fu, Geoffrey Knauth, Gustavo Massaccesi, J. Ryan Stinnett, Jack Firth, Jason Hemann, Jimmy McNutt, John Clements, Lîm Tsú-thuàn, M. Taimoor Zaeem, Mao Yifu, Matthew Flatt, Matthias Felleisen, Mike Sperber, Noah Ma, Oliver Flatt, Paulo Matos, Philip McGrath, Reuben Thomas, Robby Findler, Ryan Culpepper, Sam Phillips, Sam Tobin-Hochstadt, Samuel Bronson, Shu-Hung You, Sorawee Porncharoenwase, Sorin Muntean, Stephen Chang, William J. Bowman, and Winston Weinert

Official installers for Racket on many platforms are available from https://download.racket-lang.org/.

If you are new to Racket try our Getting started guide.

Questions and feedback about the release are welcome on Discourse.

Racket version 8.6 is now available from https://download.racket-lang.org/

As of this release:

• Racket has an “equal-always?” primitive that equates values that will stay the same even if mutated. See https://docs.racket-lang.org/reference/Equality.html#%28def.%28%28quote.~23~25kernel%29._equal-always~3f%29%29

• This release uses a new build system, Zuo, which is implemented as a little language, in accordance with the ideas of Language Oriented Programming (LOP). The implementation has a single C file (plus libraries implemented in Zuo), so it compiles easily. The zuo/build library is modeled on make and Shake for tracking dependencies and build steps. See https://docs.racket-lang.org/zuo/index.html and https://racket.discourse.group/t/new-build-system-pushed-to-git-repo/873

• Racket supports stencil vectors, which associate a virtual bitmask with a vector, enabling certain mask-equipped update operations. See https://docs.racket-lang.org/reference/stencil_vectors.html

• Racket supports Arm64 machines running Windows.

• Redex has support for simultaneous substitutions. See https://docs.racket-lang.org/redex/reference.html#%28form._%28%28lib._redex%2Freduction-semantics..rkt%29._substitute%29%29

• The Web Server provides control over the maximum number of concurrent connections via its “safety limits” construct. See https://docs.racket-lang.org/web-server-internal/dispatch-server-unit.html#%28part._safety-limits%29

• The Web Server has improved logging performance and improved request parsing performance, reducing tail latencies.

• The Web Server supports logging response status code via web-server/dispatchers/dispatch-logresp. See https://docs.racket-lang.org/web-server-internal/dispatch-logresp.html

• The db library supports custom types for PostgreSQL connections; see pg-custom-type for details. See https://docs.racket-lang.org/db/util.html#%28def._%28%28lib._db%2Futil%2Fpostgresql..rkt%29._pg-custom-type%29%29

• The release includes many other repairs and changes!

The following people contributed to this release:

Alex Knauth, Alexander Shopov, Alexis King, Amirouche Amazigh BOUBEKKI, Andy Keep, Ashish SHUKLA, Bob Burger, Bogdan Popa, Cameron Moy, Chung-chieh Shan, David K. Storrs, FrankHB, Fred Fu, Gustavo Massaccesi, helado de brownie, J. Ryan Stinnett, Jack Firth, Jamie Taylor, Jason Hemann, Jens Axel Søgaard, Jimmy McNutt, Joel Dueck, John Clements, José Manuel Calderón Trilla, Kevin Tew, Laurent Orseau, Matt Audesse, Matthew Flatt, Matthias Felleisen, Mike Sperber, naveen srinivasan, Niklas Larsson, Noah Ma, Oscar Waddell, Pavel Panchekha, Phil Nguyen, Philip McGrath, Philippe Meunier, rgkirch, Robby Findler, Robert Postill, Ryan Culpepper, Sam Tobin-Hochstadt, Sergiu Ivanov, Sorawee Porncharoenwase, Stephen De Gabrielle, Vincent Lee, wackbyte, and Zibing Zhang

Link to package regressions issue for the 8.6 release: https://github.com/racket/racket/issues/4366

Official installers for Racket on many platforms are available from https://download.racket-lang.org/.

If you are new to Racket try our Getting started guide.

Questions and feedback about the release are welcome on Discourse.

Racket version 8.5 is now available from https://download.racket-lang.org.

As of this release:

• Racket’s new -y flag automatically keeps compiled files up to date, reducing subsequent load times.

• Error-message realms allow Racket-hosted languages to adapt and rewrite error messages to make sense in a particular context.

• Nonprivileged users can control package installation scope using an “other-version” directory in the addon-dir.

• Racket CS runs on platforms where native-code generation is not currently supported (e.g., s390x or ppc64). See “README.txt” in the source distribution for more information on the —enable-pb flag to configure.

• DrRacket’s new ‘Reopen Closed Tab’ file menu item will open previously closed tabs.

• Typed Racket has support for the xml library; use typed/xml.

• Rackunit reports source locations for failed test cases in the Typed Racket language.

• Plot has violin plots and improved box-and-whisker plots.

• Boxes are supported alongside lists, vectors etc. in place-channel messages.

• Those who manually configure Racket CS to use Zlib compression for compiled code should be aware of CVE–2018–25032; the next release and the current snapshot builds use a newer, safer version of zlib.

• The release includes many other repairs and changes!

The following people contributed to this release:

Alex Harsányi, Alexander Shopov, Alexis King, Andrew Mauer-Oats, Ben Greenman, Benedek Szilvasy, Bert De Ketelaere, Bogdan Popa, Cameron Moy, Chung-chieh Shan, Fred Fu, Gustavo Massaccesi, J. Ryan Stinnett, Jamie Taylor, Joel Dueck, John Clements, Joseph Griego, Khadija Sidhpuri, Laurent Orseau, Maciej Barć, Matthew Flatt, Matthias Felleisen, Mike Sperber, Noah Ma, Philip McGrath, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Sorawee Porncharoenwase, Stephen De Gabrielle, Tim Jervis, and Trevor Paley

Link to package regressions issue for the 8.5 release: https://github.com/racket/racket/issues/4202

posted by John Clements

Racket version 8.4 is now available from https://download.racket-lang.org.

• Command-line Racket provides a new expression editor by default for its read-eval-print loop (REPL). The new REPL is based on the Chez Scheme expression editor, but extended to use the same language-sensitive syntax coloring and indentation tools as DrRacket.

• Typed Racket adds a kind system, preventing programmers from writing nonsensical type expressions. It checks whether type constructors are correctly applied to arguments, and separates type constructors from polymorphic types. The :kind form enables checking the kind of a type expression at the REPL. The new system also correctly rejects some ill-formed recursive types.

• Racket has a file-or-directory-stat for unified information about file-system objects.

• DrRacket shows the region affected by an #; S-expression comment by fading the commented-out region.

• Racket on Chez has faster multiplication and division for some numbers.

• Web server: The files dispatcher supports all standard caching-related HTTP response headers (e.g., Cache-Control).

• Web server: A new dispatcher captures the common pattern of processing HTTP requests and responses in a layered fashion.

• The Web Server supports use of the Cache-Control header, and includes a new wrapping dispatcher.

• Expander: add “portal” syntax to support new forms of syntax object binding.

• Documentation search is improved.

• Some hash operations support an optional try-order? argument.

• The plot-metrics interface has documentation.

• Fonts support OpenType feature settings.

• The Gui library has improved support for Wayland.

• The computation of quadratic roots is further improved.

• The set/c contract adds support for random generation.

• DrRacket’s interactions window supports #lang-specific coloring and indentation.

• DrRacket’s parenthesis-based keyboard shortcuts change based on the parentheses that each different #lang uses.

• The release includes many other bug repairs and other improvements!

Transition/Update notes:

• To turn off expeditor and make Racket’s REPL go back to the old editline/readline-based editor, use the command

  ,input readline

and then restart Racket. Get back to the new expression editor with

,input expeditor

To toggle color mode for the new expression editor, use one of the following, which does not require restarting Racket:

,color #false
,color #true

• Support for comment fading in DrRacket requires an increment to the “WXME” format version so files with non-text content written by DrRacket v8.4 will open only in v8.4 and later. This does not affect files that consist only of unicode text.

• The addition of the kind system to Typed Racket means that certain mild abuses of the type system no longer type check, most notably the ‘application’ of a polymorphic type.

The following people contributed to this release:

Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew Mauer-Oats, Andy Keep, Ayman Osman, Ben Greenman, Bob Burger, Bogdan Popa, Cameron Moy, D. Ben Knoble, Fred Fu, Greg Hendershott, Gustavo Massaccesi, Jamie Taylor, Jarhmander, Jesse Alama, Joel Dueck, John Clements, Jordan Johnson, Laurent Orseau, Leif Andersen, Marc Burns, Matthew Flatt, Matthias Felleisen, Mike Engelhart, Mike Sperber, Noah Ma, Oscar Waddell, Pavel Panchekha, Philip McGrath, rgkirch, Robby Findler, Sam Tobin-Hochstadt, Sergiu Ivanov, Sorawee Porncharoenwase, Stefan Schwarzer, Stephen De Gabrielle, Tony Garnock-Jones, Viko Riféo, and Zachary Mao

Link to package regressions issue for the 8.4 release: https://github.com/racket/racket/issues/4125

Feedback welcome.

posted by John Clements

Racket version 8.3 is now available from https://download.racket-lang.org.

• Racket removes syntax arming and disarming in favor of a simpler system of protected syntax operations, along with other updates to the syntax system.

• DrRacket has improved support for custom #lang languages.

• Typed Racket improves precision for type-checking of non-polymorphic structures, existential types, and certain binding forms.

• Scribble HTML output gains a button to show / hide the table of contents on mobile platforms.

• Redex’s stepper’s GUI shows IO-judgment form rule names.

• Many bug fixes!

The following people contributed to this release:

Adam Zaiter, Alex Knauth, Alexis King, Ayman Osman, Ben Greenman, Bob Burger, Bogdan Popa, Brian Adkins, Cameron Moy, Carl Eastlund, Dan Holtby, Dominik Pantůček, Eli Barzilay, Ethan Leba, Fred Fu, Greg Hendershott, Gustavo Massaccesi, J. Ryan Stinnett, Jason Hemann, Jay McCarthy, Jesse Alama, Joel Dueck, John Clements, Jonathan Simpson, Kartik Sabharwal, Laurent Orseau, Lehua Ding, Maciej Barć, Marc Burns, Matthew Flatt, Matthias Felleisen, Michael Ballantyne, Mike Sperber, Noah Ma, Paulo Matos, Pavel Panchekha, Philip McGrath, Robby Findler, Ryan Culpepper, Ryan Sundberg, Sage Gerard, Sam Tobin-Hochstadt, Shu-Hung You, Sorawee Porncharoenwase, Stefan Schwarzer, Stephen De Gabrielle, Vincent St-Amour, William J. Bowman, minor-change, and yjqww6

Feedback Welcome

posted by John Clements

Racket version 8.2 is now available from https://download.racket-lang.org.

• Racket CS improved the performance of large-integer arithmetic.

• Racket has improved support for layered and tethered installation.

• Racket CS supports nonatomic allocation via ffi/unsafe.

• Cross-compilation works fully with the raco cross tool, which is distributed separately as the “raco-cross” package.

• DrRacket has performance improvements when editing files with picts containing large bitmaps.

• Typed Racket more consistently refines field types of non-polymorphic structs.

• Printing of values is unified across the teaching language implementations and the stepper.

The following people contributed to this release:

Alex Harsányi, Alex Knauth, Amirouche, Andrew Mauer-Oats, Bob Burger, Bogdan Popa, Cameron Moy, Crystal Jacobs, Dale Vaillancourt, Diego A. Mundo, Fred Fu, Greg Hendershott, Gustavo Massaccesi, Jack Firth, Jamie Taylor, Jarhmander, Jason Hemann, Jay McCarthy, Jeffrey D. Swan, Jens Axel Søgaard, Jesse Alama, John Clements, Laurent Orseau, Lazerbeak12345, Matthew Flatt, Matthias Felleisen, Mike Sperber, Nada Amin, Noah Ma, Oscar Waddell, Paulo Matos, Pavel Panchekha, Philip McGrath, Ray Racine, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Shu-Hung You, Sorawee Porncharoenwase, Stephen Chang, Thorsten Blum, Tony Garnock-Jones, WarGrey Gyoudmon Ju, William J. Bowman, Yu Fang, and minor-change.

Feedback Welcome

posted by John Clements

Racket version 8.1 is now available from https://racket-lang.org/.

• DrRacket tabs can be dragged, and have new close buttons.

• Racket CS supports cross-compilation using raco exe.

• Racket CS supports Android on 32-bit and 64-bit ARM processors.

• The database library supports running queries in OS threads.

• Check-Syntax arrows correctly identify the definition site of identifiers with contracts.

• Racket CS performance has improved for structure predicates and accessors

• Racket CS is faster at multiplying extremely large numbers and dividing large integers.

• Racket CS allows callbacks to raise exceptions if they are annotated with #:callback-exns?.

• New ephemeron hash tables simplify the implementation of tables where keys can refer to values.

• Typed Racket supports for/foldr.

• The stepper works for #lang htdp/*sl.

• Struct signatures work for the ASL teaching language.

The following people contributed to this release:

Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew Mauer-Oats, Anish Athalye, Ben Greenman, Bert De Ketelaere, Bob Burger, Bogdan Popa, Brian Adkins, Cameron Moy, David Van Horn, Dexter Lagan, Dominik Pantůček, Fred Fu, Greg Hendershott, Gustavo Massaccesi, Hazel Levine, Ismael Luceno, Jack Firth, Jarhmander, John Clements, Jörgen Brandt, Laurent Orseau, Lazerbeak12345, Matthew Flatt, Matthias Felleisen, Micah Cantor, Mike Sperber, Noah Ma, Patrick McCarty, Paulo Matos, Pavel Panchekha, Philip McGrath, Philippe Meunier, R. Kent Dybvig, Robby Findler, Ryan Culpepper, Ryan Kramer, Sam Tobin-Hochstadt, Sergiu Ivanov, Shu-Hung You, Sorawee Porncharoenwase, Stephen De Gabrielle, William J. Bowman, bmitc, xxyzz, yjqww6, and ymdarake.

Feedback Welcome!

posted by John Clements

Racket version 8.0 is now available from https://racket-lang.org/.

* Racket 8.0 is here!*

Racket 8.0 marks the first release where Racket CS is the default implementation. Creating, polishing, and adopting Racket CS has been a 4-year effort involving the entire Racket community. At this point, Racket CS is faster, easier to maintain and develop, and compatible with existing Racket programs. Racket CS will continue to improve, but at this point it is ready to be the primary variant of Racket for all Racketeers. More details about the current state of Racket CS are available in the recent blog post.

Other notable changes:

• Racket CS has better parallel garbage collection, a 10%–30% reduction in the size of generated code, and various targeted optimizations.

• A rewrite of the test-engine package allows the #lang versions of teaching languages to produce linked test-failure messages.

• The release comes with a new mark-up DSL for composing text to appear in the REPL (simple-tree-text-markup).

• Redex has an added define-overriding-judgment form and improved error source location reporting.

• Windows scrolling speed reflects the system preference.

• The db package uses the utf8mb4 charset for MySQL connections.

The following people contributed to this release:

Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Bert De Ketelaere, Bogdan Popa, Cameron Moy, David Van Horn, Davis Silverman, Dominik Pantůček, Florian Weimer, Fred Fu, Gustavo Massaccesi, Jack Firth, James Wilcox, Joel Dueck, John Clements, Jonathan Chan, Lîm Tsú-thuàn, Mark, Matthew Flatt, Matthias Felleisen, Michael Ballantyne, Mike Sperber, Paulo Matos, Pavel Panchekha, Peter Zhong, Phil Nguyen, Philip McGrath, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Sergiu Ivanov, Shu-Hung You, Sorawee Porncharoenwase, Stefan Schwarzer, Stephen Chang, Stephen De Gabrielle, Walter H. Yang, WarGrey Gyoudmon Ju, kurinoku, xxyzz, and yjqww6

posted by Matthew Flatt

With the upcoming version 8.0 release, Racket on Chez Scheme (Racket CS) will become the default implementation of Racket. This report discusses the implications of that change, continuing a series that was originally about Racket CS; the most recent previous report was the February 2020 report. The original January 2018 report explains the motivation behind throwing out around 200k lines of C code to replace it with around 150k lines of Scheme and Racket code.

Switching to Racket CS

For most users, the differences between Racket CS and Racket BC (“before Chez”) may be too small to notice. The installer and executables will be larger, because they contain machine code instead of bytecode, and some programs may run a little faster. Otherwise, Racket programs are supposed to run the same.

To test this, we’ve built and tested every package available from the package server on Racket CS over the past several months and compared the results with those from Racket BC version 7.9. Out of more than 1800 packages, currently only 12 now fail to compile, and 5 others fail some of their tests. The new build failures, as well as 2 of the 5 new test failures, are the result of changes at the C API level. Several packages already have pull requests to fix them, and we hope others will be fixed soon, too. The remaining 3 test failures are differences in thread scheduling that provoked existing bugs in the packages.

Although Racket CS will be the default for v8.0, Racket BC will remain available through a “More Installers” link on the download page for the foreseeable future. So, Racket users will still have the option of falling back to the old runtime system and compiler if something goes wrong, or if they need a package that does not yet work on Racket CS.

Progress in the Past Year

During 2020, Racket CS became a little faster and a little smaller, and many corners of the implementation were repaired or made more compatible with the BC implementation. The planned changes that were on the previous report’s roadmap all happened! In addition, we introduced an AArch64 backend and ported to run natively on M1 Macs. Finally, we made the Chez Scheme garbage collector run in parallel, which brought the performance of places-based parallelism in Racket CS about on par with BC.

Building Racket CS no longer involves first building Racket BC as a way to bootstrap Chez Scheme. Instead, Chez Scheme bootstraps itself on any supported platform using a new portable bytecode (pb) backend. Bootfiles for pb mode are checked into a separate Git repository that is used in a submodule-like way, but bootfiles can always be built from source by using an existing Racket build; the bootstrap implementation is now detangled so that much older Racket versions in the v7 series can work for bootstrapping.

Benchmark Performance

For traditional Scheme benchmarks, not much has changed in the results. A plot is practically indistinguishable from the one in the previous report.

For the shootout benchmarks, which measure more Racket-specific functionality and libraries, there’s some improvement, especially toward the end of the table. (Shorter is better.) The light-blue line shows the results from the previous report (which corresponds to version 7.6), so a shorter “CS” bar means improvement there. The improvements mostly reflect unboxed floating-point arithmetic.

Below is another set of microbenchmarks from the racket-benchmarks package, comparing Racket CS to BC. Some points to note:

• CS is usually faster than BC. (Shorter is better.)

• The fastest relative CS runs are much faster than the fastest relative BC runs; that is, the shortest blue bars are much shorter than the shortest red bars. Although it’s difficult to extract from these plots, the difference is really that CS performs more consistently, so it’s slowest relative runs are not as slow as the slowest relative BC runs.

• These benchmarks mostly compare subsystems that are implemented in C for BC to subsystems implemented in Scheme and Racket for CS. That’s the key and motivating point — the maintenance advantage, more than the performance advantage.

For the rest of this report, the plots will show CS slower or bigger, but gradually approaching BC performance. You should not read that as “CS is slower than BC.” This report is about the parts of the implementation where we spent time last year, and we don’t dwell on parts where no improvement was needed.

About the measurements: Benchmarks are in the "racket-benchmark" package in the "shootout", "control", "hash", and "chaperone" directories. We dropped some of the "control" benchmarks because they take to long to run on BC, which means that the plots here understate how much more consistently CS performs compared to BC.

Startup and Memory Use

Load times improved for Racket CS:

That’s mostly due to reduced code size:

On a different scale and measuring peak memory use instead of final memory use for DrRacket start up and exit:

The large drop in peak memory use for DrRacket CS is due to garbage-collection improvements for old generations in large heaps, where old-generation objects tend to be marked in place instead of copied.

About the measurements: These results were gathered by running racket with the arguments -l racket or -l drracket. The command further included -W "debug@GC" -e ’(collect-garbage)’ -e ’(collect-garbage)’, and reported sizes are based on the logged memory use before the second collection. For the “BC” line, the reported memory use includes the first number that is printed by logging in square brackets, which is the memory occupied by code outside of the garbage collector’s directly managed space. Baseline memory use was measured by setting the PLT_GCS_ON_EXIT environment variable and running with -n, which is has the same effect as -e '(collect-garbage)' -e '(collect-garbage)'. DrRacket was initialized with racket/base as the default language; also, background expansion was disabled, because measuring memory use is tricky on Racket BC.

Build Times

Compile times improved for Racket CS:

This improvement, combined with others, makes the CS distribution now build a little faster from source than a BC build, and it uses about 20% less memory than the BC build. The following two plots use the same scale, where the foreground blue or red line shows memory use (vertical) plotted over time (horizontal) as recorded on each major collection (see this page for a detailed description):

Racket CS
Racket BC

A shorter build time in less space represents a big milestone for Racket CS. Even though most Racket users start with a pre-built distribution, build time measures end-to-end performance across many parts of the implementation, and build performance correlates well with end-to-end performance in many Racket applications.

The build plots above are for a sequential (i.e., single-threaded) build. More typically, Racket is built on machines with more CPUs, and build times easily benefit from process-like parallelism. Over the past year, garbage-collector improvements for parallel collection have made build times with place-based parallelism dramatically shorter on a machine with 4 hyperthreaded cores (although build dependencies ultimately limit parallelism). Since parallel collection debuted in Racket CS v7.9 but has improved since, we show v7.9 as an intermediate point:

As the plot shows, as of the previous report (before parallel garbage collection), trying to build with multiple places was counterproductive. The speedup from places-based parallelism in v8.0 is finally close to BC’s speedup, which is about the same as using process-based parallelism (but with the advantage of staying within a single Racket process). The parallelism available from BC remains a little higher, because its implementation of places uses completely separate allocation heaps, while parallelism in CS use a single heap.

About the measurements: The compile-time results were gathered by using time in a shell a few times and taking the median. The build plots were generated using the "plt-build-plot" package, which drives a build from source and plots the results. The parallelism results were generated by starting with an in-place installation, using raco setup –fast-clean and rm doc/docindex.sqlite to start from a clean state, and getting elapsed real time with time racro setup –jobs 8, and dividing by elapsed time from build plots (which is not exactly the same build job, but is close).

Reflection and Outlook

We tried to declare success and move on a year ago, but that didn’t work. This time really is different, because Racket CS is ready to be the default Racket implementation. Time will tell whether that difference is enough to allow a different focus in the coming year. Given how much the CS compilation strategy (ahead-of-time) differs from the BC strategy (bytecode compilation plus a JIT), it’s not clear that the compile time, load time, and memory footprint differences between BC and CS can be reduced further.

In terms of maintainability, one possible direction for improvement is to shift even more Racket support into the Chez Scheme layer. Gustavo’s decision to implement type reconstruction as a Chez Scheme pass was good call. Contributor yjqww6’s implementation of Racket-style lifting as a Chez Scheme pass was a clear improvement for Racket CS, because it eliminated a larger pass on the “schemify” side and implemented at a better layer of abstraction with less interference on local optimizations. Similarly, extending Chez Scheme’s support for weak hash tables, which was not difficult, allowed us to discard a complex and slower implementation in the “rumble” Racket-adapter layer. More direct support for left-to-right evaluation guarantees and cross-linklet inlining could further reduce the schemify layer, and maybe one day eliminate it.

We’ve mostly kept BC and CS in sync, so far, but moving forward, Racket BC will not necessarily get new functionality that is added to CS. After all, the point of CS is to eventually shed technical debt in BC. This divergence has already started: Racket CS fully supports M1 Macs, but Racket BC runs only in interpreted mode or as x86_64 (i.e., we did not add an AArch64 JIT to Racket BC).

Thanks to Sam, Ryan, Robby, Matthias, and John for improving this report. Special thanks to Sam, Paulo, and Robby for moving CS testing forward. Many contributors helped track down and repair CS bugs, and besides others mentioned, thanks to Shu-Hung, Sorawee, and Bogdan for tackling some substantial repairs.