sorry but where has you readed that go doesnt outperform elixir???..almost any (except for a benchmark posted in github probably) shows that go has much better performance.
It’s not a criticism to elixir, elixir is much more robust and the ending app would be much more stable with less effort than golang…but in performance terms I think that go must be superior for several orders of magnitude
I should probably have worded it clearer.
As I wrote Go has both excellent raw speed and excellent concurrency. However I expect - just guessing - 1 or two order of magnitude, not “several” in tasks mainly requiring raw-speed.
But I got the idea that in real world massive concurrent web sites (note that I was asking about Elixir/Phoenix so a particular set of applications) the difference is not that big. In other words I don’t think WhatsApp would be orders of magnitude faster if written in Go instead of Erlang!
So my doubt (now cleared): what makes Elixir/Phoenix performing so much better than I expected?
The main advantage of Go in a situation like that is not necessarily speed (it’s almost entirely IO bound after all), but rather memory consumption of Go would be far less. However, Go is substantially less ‘safe’ than BEAM programs in terms of staying up in the cases of failure, so it’s a trade-off between maybe needing more servers and being able to fairly easily (comparatively) scale BEAM programs out or have a faster but with potentially more downtime Go program.
Came across this after having the same thoughts - I’ve just started learning Elixir and really like it but there is a small niggle that some simple tasks take an order of magnitude more time to run in Elixir/Erlang than in other languages. For example, just calculating the 20th Fibonacci number (recursive implementation) in Elixir takes around 300 microseconds on my laptop but in Golang it takes around 35 microseconds - anyone know how there can be such a difference in performance?
Elixir
defmodule Fib do
def of(0), do: 0
def of(1), do: 1
def of(n), do: Fib.of(n-1) + Fib.of(n-2)
end
before = :os.system_time(:microsecond)
res = Fib.of(20)
now = :os.system_time(:microsecond)
IO.puts "took: #{now-before} microseconds"
Golang
func main() {
now := time.Now()
res := fib(20)
took := time.Since(now)
log.Printf("res: %d took: %s", res, took)
}
func fib(x int) int {
if x == 0 {
return 0
}
if x == 1 {
return 1
}
return fib(x-1) + fib(x-2)
}
This has been addressed in more detail in other threads, but I think a fair TL;DR is:
The BEAM (and by extension, Elixir which runs on the BEAM) values the progress of the whole system over the optimal progress of some tiny part of that system.
This philosophy is at the core of all of the major Elixir trade offs I think. The things that make a single process slower when processing CPU bound tasks are exactly the same things that ensure that a CPU bound task can’t lock up the whole system. It’s the things that allow you to introspect and trace in realtime the execution of the system to figure out where the slow parts are on your running production server. Its the things that ensure that if part of the system fails, it won’t leave other parts with invalid memory states. These trade offs are great if you’re running an IO oriented server that coordinates many things or manages many data streams. These trade offs are bad if you want to write say a video codec or a 3d renderer. That’s OK, it’s one of the things I like about Elixir: It is up front and honest about what it’s good at and what it isn’t. It makes clear trade offs.
Addendum: A slightly more realistic CPU bound performance comparison might be JSON parsing, you can find an example here: Crude JSON parsing benchmarks for Elixir, Ruby, Golang. In this case at least, Elixir actually out performs Go.
for elixir you’ll want to use Tail recursion… Tail Call Optimization with Fibonacci in Elixir | Stride
for golang you’ll actually want to use the iterative one (afaik): https://medium.com/@felipedutratine/iterative-vs-recursive-vs-tail-recursive-in-golang-c196ca5fd489
and now you end up comparing different algos - due to different language features and performance characterics etc. etc.
also see this post/video (probably somewhat outdated by now) Performance - Best practices? - #4 by outlog on how Elixir/Erlang trades throughput for predictable latency - and Go does the opposite..
Taking this specific example:
int is a fixed size, 32 or 64 bit. Erlang/Elixir uses bignums, they can take huge values without overflow, but are slower.Fib.of(n) is what’s called an external or fully qualified call in Erlang, as opposed to a local call (of(n)). It will always use the latest version of the module that’s loaded. The code reload mechanism adds flexibility but makes every function call a bit slower. It also means the compiler can’t assume that Fib.of will always return an int, so the code has to check the type every single time before doing the + - whereas the Go compiler can skip those checks. (The compiler may be able to optimize a bit better if you use defp to define the recursive function and use a wrapper e.g. def fib to call it externally)You’ll find many similar tradeoffs in Erlang where it aims for reliability or observability rather than performance.
Sometimes it’s also just slow because it’s slow. It doesn’t get as much investment as other platforms (Java in particular), so potential improvements like the JIT compiler take a long time. The compiler is getting a lot of interesting improvements in the next release (23), in type analysis and optimization for instance.
Thanks for taking the time to respond - yeah I did a quick json comparison where I encoded/decoded an example map from the jason github page 100,000 times in Elixir and Go and Elixir was faster so interesting suggestion there. Weird how there was so much of a difference in performance with the Fibonacci calculation but not with some other tasks.
As you say its the use case that dictates the performance vs reliability trade off decision and it seems that Elixir is slow in some cases but not others so I’ll be interested to monitor this on various examples through my Elixir journey.
I’m surprised Elixir was faster. To me that suggests problems with Go’s JSON implementation. Because generally on CPU calculations the BEAM is substantially slower, but it is blazing fast on moving IO around, and superb at doing lots of that in parallel.
In my experience, most of such synthetic challenges are significantly skewed due to a suboptimal algorithm. In this example, we can significantly improve the running time by changiing the algorithm. Here’s a demo on 40th fibonacci:
defmodule NaiveFib do
def of(0), do: 0
def of(1), do: 1
def of(n), do: of(n - 1) + of(n - 2)
end
{time, res} = :timer.tc(fn -> NaiveFib.of(40) end)
IO.puts("Naive fib returned #{res} in #{time} microseconds")
defmodule BetterFib do
def of(0), do: 0
def of(1), do: 1
def of(n), do: of(0, 1, 2, n)
defp of(x, y, n, n), do: x + y
defp of(x, y, m, n), do: of(y, x + y, m + 1, n)
end
{time, res} = :timer.tc(fn -> BetterFib.of(40) end)
IO.puts("Better fib returned #{res} in #{time} microseconds")
Output:
Naive fib returned 102334155 in 2776981 microseconds
Better fib returned 102334155 in 0 microseconds
As we can see, the algorithmical optimization leads to an almost instantaneous computation. Of course, the equivalent go version would still be faster, but at this speed the difference doesn’t matter. So more generally, an algorithmical optimization can do wonders for performance. If that still doesn’t cut it, it’s perhaps time to consider a faster language. If that is the case, I’d probably go for C or Rust instead of go. But in my experience, more often than not, the challenge can be solved within a reasonable time using a proper algorithmical/technical combo 