4 ms·

In my case it was a team of 1 working on OTP 19 and 20. Since that is now 3+ years ago, it is quite possible things have improved in the single-thread performa

by blunte 6y ago

In my case it was a team of 1 working on OTP 19 and 20. Since that is now 3+ years ago, it is quite possible things have improved in the single-thread performance area.

astrowilson 6y ago
The 3+ years ago is a good reference, thanks for sharing. The issue could also be Ecto related. Ecto 3, which might not have been out at the time, had a bunch of improvements on this front.
onlyrealcuzzo 6y ago
Elixir single thread performance /is/ much faster than Ruby and Python [1]. Are you sure you weren't just doing something sub-optimal with Ecto? [1] https://amp.reddit.com/r/elixir/comments/46v1l1/is_elixir_faster_than_rubypython_when_were/ https://amp.reddit.com/r/elixir/comments/46v1l1/is_elixir_fa...
- gregors 6y ago
  I'm a huge elixir fan, but in micro made up benchmarks I consistently see Ruby win over Elixir. I haven't run it with the jit. One specific case that cripples Elixir - is as far as I know Elixir can't handle large multiplications efficiently. Ruby, Python use karatsuba or some derivative - from what I can tell multiplication in Erlang doesn't. Though I haven't actually asked anyone and was just poking around on my own. example: Multiplying the first 100_000 numbers together I get ruby multi.rb 3.47s user 1.91s system 99% cpu 5.396 total elixir multi.exs 14.32s user 0.62s system 103% cpu 14.441 total
  - strmpnk 6y ago
    I was curious to see what my JIT build looked like for me so I ran the following: https://gist.github.com/cararemixed/c232b888b9dbdaeb67967f357a3605df https://gist.github.com/cararemixed/c232b888b9dbdaeb67967f35... This shows a significantly different story between the two with at least similar code. Note I am not trying to optimize for the fastest factorial here as both can be made much quicker but roughly equivalent code seems to tell a different story for me. (NOTE: I put the code in a module as iex interpreted expressions on the top level are always slower than compiled modules, even when pasting them into iex. Doing the same for Ruby didn't show any difference for me.)
    - gregors 6y ago
      Neck in neck! That's amazing. Thanks for testing that out.
      - strmpnk 6y ago
        I wouldn’t call twice as fast neck and neck (others seem to show that the old interpreter is neck and neck) but the primitive JIT is clearly pulling ahead here.

by blunte 6y ago

In my case it was a team of 1 working on OTP 19 and 20. Since that is now 3+ years ago, it is quite possible things have improved in the single-thread performance area.

astrowilson 6y ago

The 3+ years ago is a good reference, thanks for sharing. The issue could also be Ecto related. Ecto 3, which might not have been out at the time, had a bunch of improvements on this front.

onlyrealcuzzo 6y ago

Elixir single thread performance /is/ much faster than Ruby and Python [1]. Are you sure you weren't just doing something sub-optimal with Ecto? [1] https://amp.reddit.com/r/elixir/comments/46v1l1/is_elixir_faster_than_rubypython_when_were/ https://amp.reddit.com/r/elixir/comments/46v1l1/is_elixir_fa...

gregors 6y ago
I'm a huge elixir fan, but in micro made up benchmarks I consistently see Ruby win over Elixir. I haven't run it with the jit. One specific case that cripples Elixir - is as far as I know Elixir can't handle large multiplications efficiently. Ruby, Python use karatsuba or some derivative - from what I can tell multiplication in Erlang doesn't. Though I haven't actually asked anyone and was just poking around on my own. example: Multiplying the first 100_000 numbers together I get ruby multi.rb 3.47s user 1.91s system 99% cpu 5.396 total elixir multi.exs 14.32s user 0.62s system 103% cpu 14.441 total
- strmpnk 6y ago
  I was curious to see what my JIT build looked like for me so I ran the following: https://gist.github.com/cararemixed/c232b888b9dbdaeb67967f357a3605df https://gist.github.com/cararemixed/c232b888b9dbdaeb67967f35... This shows a significantly different story between the two with at least similar code. Note I am not trying to optimize for the fastest factorial here as both can be made much quicker but roughly equivalent code seems to tell a different story for me. (NOTE: I put the code in a module as iex interpreted expressions on the top level are always slower than compiled modules, even when pasting them into iex. Doing the same for Ruby didn't show any difference for me.)
  - gregors 6y ago
    Neck in neck! That's amazing. Thanks for testing that out.
    - strmpnk 6y ago
      I wouldn’t call twice as fast neck and neck (others seem to show that the old interpreter is neck and neck) but the primitive JIT is clearly pulling ahead here.