3 ms·

Thank you for the explanation of BEAM + its objectives and internals. > It's incredibly good at multiprocessing, which is really useful in the websphere So on

Thank you for the explanation of BEAM + its objectives and internals. > It's incredibly good at multiprocessing, which is really useful in the websphere So on that benchmark I linked, if you switched to the latency tab Phoenix clocks in at 14.6ms average latency with a standard deviation of 23ms and a max of 460.7ms. The best looking ASP.NET Core result from a standard deviation and max point of view is 1.5ms average latency, 1.4ms standard deviation and 49ms max. So again it's hard for me to tell whether it's BEAM or Phoenix that's responsible for the relative performance hit.

derefr 7y ago
Very likely Phoenix (Phoenix is “more” software than ASP.Net is; a better comparison might be to Erlang’s cowboy library); but also very likely that the author of that benchmark didn’t really tune BEAM. By default, BEAM has runtime tracing hooks enabled; native code compilation (HiPE) disabled; no core pinning; low enough process-heap-size upon spawn that an immediate grow is usually necessary; and a slew of other things. There’s also the fact that Elixir and even Erlang don’t take full advantage of the possibilities of BEAM-bytecode whole-program optimization. For example, any list you walk using Erlang’s lists module or Elixir’s Enum module is going to generate a back-and-forth of remote (symbolic) calls, rather than resulting in the body of that function of lists/Enum being inlined and fused into the caller. Which in turn means, even if you use HiPE, you’ll be thunking in and out of native code so much that the overhead will eat any potential benefit; and each side will be opaque to the static analysis of the other, so even a wholesale native recompilation of the runtime won’t save you. (Same with gen_servers: remote callbacks through library code, rather than fused module-local receive statements; ergo, 10x optimization opportunity lost.) You’ll see real optimization in code generated by e.g. Erlang’s lexer-generator library leex; or in specific parts of each language’s stdlib, like Elixir’s Unicode-handling functions. But such optimized code emission is thin-on-the-ground compared to “naive” coding in Erlang/Elixir. (And I don’t blame the language devs: the languages are fast enough for almost everything people try to do; and for the rest, you can ignore the language-as-framework and write entirely self-contained modules that only rely on BEAM primitives.)
gregors 7y ago
looking at latencies for framework vs framework tells another story https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext&l=zg24n1-f&c=6 https://www.techempower.com/benchmarks/#section=data-r18&hw=... Where ASP.NET MVC clocks in with 39.3ms average latency, 154.1ms standard deviation

derefr 7y ago

Very likely Phoenix (Phoenix is “more” software than ASP.Net is; a better comparison might be to Erlang’s cowboy library); but also very likely that the author of that benchmark didn’t really tune BEAM. By default, BEAM has runtime tracing hooks enabled; native code compilation (HiPE) disabled; no core pinning; low enough process-heap-size upon spawn that an immediate grow is usually necessary; and a slew of other things. There’s also the fact that Elixir and even Erlang don’t take full advantage of the possibilities of BEAM-bytecode whole-program optimization. For example, any list you walk using Erlang’s lists module or Elixir’s Enum module is going to generate a back-and-forth of remote (symbolic) calls, rather than resulting in the body of that function of lists/Enum being inlined and fused into the caller. Which in turn means, even if you use HiPE, you’ll be thunking in and out of native code so much that the overhead will eat any potential benefit; and each side will be opaque to the static analysis of the other, so even a wholesale native recompilation of the runtime won’t save you. (Same with gen_servers: remote callbacks through library code, rather than fused module-local receive statements; ergo, 10x optimization opportunity lost.) You’ll see real optimization in code generated by e.g. Erlang’s lexer-generator library leex; or in specific parts of each language’s stdlib, like Elixir’s Unicode-handling functions. But such optimized code emission is thin-on-the-ground compared to “naive” coding in Erlang/Elixir. (And I don’t blame the language devs: the languages are fast enough for almost everything people try to do; and for the rest, you can ignore the language-as-framework and write entirely self-contained modules that only rely on BEAM primitives.)

gregors 7y ago

looking at latencies for framework vs framework tells another story https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext&l=zg24n1-f&c=6 https://www.techempower.com/benchmarks/#section=data-r18&hw=... Where ASP.NET MVC clocks in with 39.3ms average latency, 154.1ms standard deviation