3 ms·

Can someone break this down and explain what this means in practical runtime performance gains? I know it's probably "it depends", but in Elixir let's say you

by nickjj 6y ago

Can someone break this down and explain what this means in practical runtime performance gains? I know it's probably "it depends", but in Elixir let's say you were doing a lot of string parsing or mucking around with a bunch of Enum functions or doing a bit of math. Will this put Elixir's performance on par with at least Python and Ruby in those cases? I know this feature is meant for Erlang but I'm assuming it applies back to Elixir too?

strmpnk 6y ago
It does apply to Elixir. It will help all around performance but more so it does this on a per-instruction level by reducing dispatch cost in that the interpreter pays (as well as managing to specialize things a little better than what the fixed instruction tables can express). To get an idea of the instruction stream of the BEAM (not the same as .beam asm), you can use the erts_debug module: iex> :erts_debug.df(String) This will dump a BEAM machine instruction stream to a file named Elixir.String.dis in your current working directory. You'll see things like: 000000001B81AFB0: i_func_info_IaaI 0 `'Elixir.String'` `at` 2 000000001B81AFD8: is_integer_fx f(000000001B81AFB0) x(1) 000000001B81AFE8: is_ge_literal_fxc f(000000001B81B008) x(1) `0` 000000001B81B000: i_call_only_f loc(`'Elixir.String'`:`do_at`/2) 000000001B81B008: allocate_tt 2 2 000000001B81B010: move_window2_xxy x(1) x(0) y(0) 000000001B81B018: i_call_f loc(`'Elixir.String'`:`length`/1) 000000001B81B020: i_plus_xyjd x(0) y(0) j(0) x(0) 000000001B81B030: is_ge_literal_fxc f(000000001B81B060) x(0) `0` 000000001B81B048: move_shift_yxx y(1) x(0) x(1) 000000001B81B050: i_call_last_fQ loc(`'Elixir.String'`:`do_at`/2) 2 000000001B81B060: move_deallocate_return_cQ `nil` 2 Each of those instructions are what the .beam file loader currently generates. With the JIT, these will be replaced by machine code.

by nickjj 6y ago

strmpnk 6y ago

It does apply to Elixir. It will help all around performance but more so it does this on a per-instruction level by reducing dispatch cost in that the interpreter pays (as well as managing to specialize things a little better than what the fixed instruction tables can express). To get an idea of the instruction stream of the BEAM (not the same as .beam asm), you can use the erts_debug module: iex> :erts_debug.df(String) This will dump a BEAM machine instruction stream to a file named Elixir.String.dis in your current working directory. You'll see things like: 000000001B81AFB0: i_func_info_IaaI 0 `'Elixir.String'` `at` 2 000000001B81AFD8: is_integer_fx f(000000001B81AFB0) x(1) 000000001B81AFE8: is_ge_literal_fxc f(000000001B81B008) x(1) `0` 000000001B81B000: i_call_only_f loc(`'Elixir.String'`:`do_at`/2) 000000001B81B008: allocate_tt 2 2 000000001B81B010: move_window2_xxy x(1) x(0) y(0) 000000001B81B018: i_call_f loc(`'Elixir.String'`:`length`/1) 000000001B81B020: i_plus_xyjd x(0) y(0) j(0) x(0) 000000001B81B030: is_ge_literal_fxc f(000000001B81B060) x(0) `0` 000000001B81B048: move_shift_yxx y(1) x(0) x(1) 000000001B81B050: i_call_last_fQ loc(`'Elixir.String'`:`do_at`/2) 2 000000001B81B060: move_deallocate_return_cQ `nil` 2 Each of those instructions are what the .beam file loader currently generates. With the JIT, these will be replaced by machine code.