News for hackers. Stuff that matters.
Re:Elixir and Phoenix after two years by onlyrealcuzzo on Monday April 05, 2021 @05:05PM (#26704727)
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_fa...

Re:Elixir and Phoenix after two years by gregors on Monday April 05, 2021 @10:30PM (#26707354)
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

Re:Elixir and Phoenix after two years by strmpnk on Monday April 05, 2021 @11:09PM (#26707585)
I was curious to see what my JIT build looked like for me so I ran the following: 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.)

Re:Elixir and Phoenix after two years by gregors on Monday April 05, 2021 @11:20PM (#26707633)
Neck in neck! That's amazing. Thanks for testing that out.
Re:Elixir and Phoenix after two years by strmpnk on Wednesday April 07, 2021 @08:48AM (#26724060)
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.