jeramyRR
Anyone know why Elixir's CPU usage is so high in this benchmark?
This is an interesting article to read. Elixir’s performance, like usual, is excellent. However, it seems like the high CPU usage is counter to what I would have expected.
Link to article: [Benchmarking Go vs Node vs Elixir](http://Benchmarking Go vs Node vs Elixir)
Most Liked
OvermindDL1
Elixir (well, the BEAM) does a LOT more than just opening, reading, and sending on sockets unlike Go, it also handles reliability between processes, supervision trees, etc.. etc… Where a single bit of bad code (which is dreadfully easy in Go due to its weak typing) will bring down the entire Go server, where that just won’t happen on the BEAM. In addition the BEAM is also managing distribution data, immutable message copying (to help with that reliability) between the actors, etc… etc..
In short, the BEAM is a lot more heavyweight yes, but it scales very well regardless and it has reliability characteristics that node and go could (at this point) only hope to dream of.
Overall, if I am going for absolute pure performance then I’d use Rust, its performance, like well crafted go and well crafted C/C++ is already as fast as you can get, except with Rust you also get many guarantees that you don’t get with go, C/C++, or even Elixir, however you lose a lot of the distribution capabilities that are just inherent to the BEAM itself.
If I’m going for something that I don’t want to go down, ever, the BEAM is unmatched with its combination of distribution abilities, supervision trees (OTP in general), and ability to hot-code reload a running a system.
In general: Node is both slower and it’s unsafe. Go is faster but it is still unsafe. Elixir is more heavyweight but still fast and safe both, while being able to scale in ways unmatched elsewhere. Rust is both crazy fast and still very safe, not necessarily like Elixir’s safety but in a different way, just not as easy to distribute as Elixir.
It’s what I expect in other words. ![]()
kt315
Benchmark author here. As I mentioned in the blog, BEAM was very responsive while saturating the CPU. After talking to people the theory is that significant fraction of CPU was used by busy waiting, in other words BEAM would “burn” some CPU cycles before resorting to kernel synchronization to achieve better performance. There is VM setting that controls that: +sbwt. Next time I will be running this benchmark with Elixir I will specifically look at microstate accounting to confirm this theory.
abtrapp
For those who don’t follow the blog: busy waiting test on The Curious Case of BEAM CPU Usage
Your article? That’s what I call a detailed analysis
- TNX!
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










