mareknowak
Rust NIFs can slow down Elixir
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.
Most Liked
sribe
If you really want speed, then you don’t want to serialize/deserialize.
NobbZ
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.
mareknowak
@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:
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








