Rust NIFs can slow down Elixir

Chat / Discussions
, ,
1

I’m learning Elixir and I like its ecosystem but I really miss static typing (I’ve played a bit with F# and Ocaml before). I thought about moving as much application logic as possible to Rust NIFs but it seems it is not always a good idea.

Let’s take any Elixir process. Its receive function can be split into “pure” update function and “impure” execute function. The first one changes the state of a process (model) and prepares command (cmd) to be executed/sent by Elixir runtime. The second executes/sends prepared command:

def process(model) do
  receive do
    msg ->
      {model, cmd} = update(model, msg)
      execute(cmd)
      process(model)
  end
end

This separation allows us to implement update in statically typed Rust and treat Elixir as kind of postman that sends prepared commands.

I tested this idea with a toy Elixir/Rust implementation of card game of war. One has Game (arbiter) process and two Player processes. Game sends messages to Players to add or remove cards, receives back responses and updates its state.
Players processes receive messages from Game, update their states (i.e. lists of cards) and send responses (cards added, cards removed, unable to remove cards) to Game. I tested two versions of the game - with those update functions implemented as Rust NIFs and as Elixir only functions.

What about execution time? Elixir updates take on average a few microseconds and their Rust counterparts (with serialization/deserialization) are 100x slower so Elixir’s version of the whole game runs faster than Rust’s one. If speed is the only concern then one should consider substituting Elixir function with Rust NIF
only if its execution time is greater then 500 microseconds. I hope someone will check my claims - the code is available on github. By the way, NIFs are implemented with help of rustler library and data conversion between Elixir and Rust is flawlessly done by serde_rustler crate - both libraries are great.

Conclusions for static type oriented? I’m definitely not the right person but here are my thoughts.

Most functions by default should be written in Elixir :-). Medium sized Elixir functions can be written as Rust NIFs. Sophisticated applications can separated with the use of Erlang ports into Elixir “glue” and for example Ocaml part treated as a “domain model”.

The most radical option would be to abandon Elixir in favour of Rust but for web stuff Elixir ecosystem is probably much bigger.

1 Like
2

I haven’t looked into your project, but when you do NIFs, they need to return in less than a millisecond or they confuse the scheduler.

You can use CPU or IO bound dirty schedulers to circumvent this requirement.

3 Likes
3

I should be more explicit - NIFs execution time is of order 0.1 millisecond (i. e. 100 microseconds).

4

If you really want speed, then you don’t want to serialize/deserialize.

4 Likes
5

I will prepare a serde_rustler free version to check it.

1 Like
6

Small passing remark: when computing run time, you want the monotonic clock rather than utc_now:

https://hexdocs.pm/elixir/System.html#module-time

2 Likes
7

@sribe suggested that serialization/deserialization makes NIF slower. I prepared three version of the game to check it: elixir (no NIFs), nif_rustler (only rustler library) and nif_serde_rustler (with serde_rustler library) and took @dom advice to properly compute time of execution of update functions.

Conclusions? @scribe was right. Serde_rustler is a very nice library but rustler explicit decoding/encoding is always faster. On my machine on average rustler update takes 60 microseconds and serde update - 160 microseconds. By the way - pure Elixir update function runs in 6 microseconds. The code is available on github:

3 Likes