And the news posting: Erlang OTP 22.0 is released - Erlang/OTP

This is the biggest thing that jumped out at me:

           OTP-14894    Application(s): compiler
           Related Id(s): ERL-714

           The compiler has been rewritten to internally use an
           intermediate representation based on Static Single
           Assignment (SSA). The new intermediate representation
           makes more optimizations possible.

           Most noticeable is that the binary matching
           optimizations are now applicable in many more
           circumstances than before.

           Another noticeable change is that type optimizations
           are now applied across local function calls, and will
           remove a lot more redundant type tests than before.

I wrote a blog post describing some of the highlights in greater detail

Much appreciated, thank you!

I just watched https://www.youtube.com/watch?v=N_qaz5Dny9k and on the topic of “Fragmented distribution messages” I noticed it sound just like the erlang schedulers for network messaging

It’s interesting that you’re now omitting type checks through “whole module” analysis. Are there any performance improvements to be had from distinguishing from floats and integers?

I am also interested in more information about the in-module type check analysis:
Does this mean that when repeatedly pattern-matching on the type of a variable whose type is already known (like an Erlang record or an Elixir struct (AKA a map with a certain __struct__ key?)), that these will be completely elided?

This would be amazing, since it is very common to use e.g. public functions of a library (that pattern match on the data structure passed in to prevent incorrect usage by library users) inside the implementation of other functions in the library as well.

As an example, in the vectors/matrices/tensors library ‘tensor’, the function Tensor.Matrix.symmetric?/1 function internally calls the function Tensor.Matrix.transpose/1 on its parameter. Since both of these functions are public, both of these check if the data structure passed in is a matrix (i.e. a %Tensor{} struct where the ‘dimensions’ field is a list of length 2).
If these kinds of duplicate checks are optimized away, that would be really cool!

Amazing work, Erlang Core team!

Since Erlang allows integers of arbitrary size, it is difficult to optimize integer arithmetic. Even if we would introduce special operations for integer arithmetic, we would not gain much because those operations would have to check that the result of the operation would still fit in a smallnum.

It is easier to optimize floating point instructions, since the size of the result is fixed (a 64-bit floating point number). In fact, BEAM has special instructions for floating point arithmetic and has had them for a long time (since OTP R7 or R8, I think). The new whole module type analysis helps those floating point optimizations by finding more places where general arithmetic operations can be replaced with floating point instructions.

The type analysis currently keeps track of the types of all elements in tuples and will omit unnecessary type tests for known elements. (That also cover Erlang records, since they are tuples.)

Currently, the type analysis pass does not keep track of the keys or values for maps. It only keeps tracks of variables that are maps, so that the is_map test can be omitted, but there will be repeated tests for __struct__.

We plan to improve the type analysis pass in OTP 23 and it is very likely that it will be extended to keep track of keys and values in maps.

I was mainly thinking of the fact that a hypothetical strongly typed language on the BEAM could compile to “type-erased” code directly.