|
Totally agree with what you said, but there is a caveat no one tells you about when you start Elixir. Coming from CUDA the extra speed you might get with concurrency in Elixir seemed very enticing for me so naturally I began experimenting. In Erlang/Elixir processes are really lightweight, but they do still bring some overhead and, in most cases I experimented with brought no speed advantage whatsoever and were in fact slower. For example, lets say you want to compute the first million fibonacci numbers using the series' nth number formula.
The function below calculates the nth fib number in the sequence; Then, to keeps things simple, we look around in the Elixir documentation and find Task which accepts a closure, is async and spawns a new process. Great you think, with the extra speed from parallelising in blocks of lets say 1k fib numbers we'll surely be faster. def nthFib(n) do
round(:math.pow(@phi, n) / @sqrt5)
end 1..1000000
|> Task.async_stream(MyModule.nthFib)
|> Enum.map(fn({:ok, result}) -> result end) Nope. In fact, doing it naively with [0, 1, ... fib[i-1]+fib[i-2] ...] is faster. This was a bummer for me. If you're interested and want to test something on hackerrank yourself, take a look here for a post I made while first experimenting with Elxir's processes on overoptimizing the first Euler problem. Noob thread here: https://elixirforum.com/t/hackerrank-optimizing-euler-proble... Of course it might be just me, trying to apply the same principles I learned using CUDA. In my defence, those principles served me well over the years no matter if I was using CUDA or solving concurrency problems somewhere else. If anyone is interested in pitching in, I'm open to ideas, but for now I'm going to continue thinking that Elixir is fast enough for most use cases, just don't get your hopes up thinking its a silver bullet. |