5 ms·
That first link is from 2009. A lot's changed since then, so I didn't read it. And maybe I missed something in the second link, but Go showed very similar I/O
by Scramblejams 6y ago
That first link is from 2009. A lot's changed since then, so I didn't read it.
And maybe I missed something in the second link, but Go showed very similar I/O performance to Elixir, while consuming a boatload less CPU doing it. That's what I'm after. Open to being told I missed something, though.
- adelarsq 6y ago> Open to being told I missed something, though. The Bean keep using CPU even with no work to be done, so avoid context changes. We can't compare about CPU values.
- Scramblejams 6y agoWe can't compare about CPU values Can you explain more why we can't compare? Looking at this chart... https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/10K-cpu.png https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi... ...shows pretty clearly how the CPU utilization grows linearly (ignoring some sawtooth) as the load increases, plateaus once the load remains constant, and then comes down linearly as the load decreases on the other end. Looks like a very clear mapping between work done and CPU load to me.
- Zingler 6y agoIt is explained in the blog post after that benchmark - https://stressgrid.com/blog/beam_cpu_usage/ https://stressgrid.com/blog/beam_cpu_usage/ . Essentially in order to optimise responsiveness the BEAM uses busy waiting, which in reality is not actually utilising the CPU as much as is reported by the OS, which results in misleading CPU usage being reported by the operating system.