Elixir is a good choice for CPU bound tasks? I have seen this but I don’t fully understand the results https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/
Erlang and Elixir are good at a lot of things but raw number-crunching performance is not one of them.
1 Like
This sort of seems like a rephrasing of your video game question, but I’ll come at it from a different angle here. The BEAM (Elixir / Erlang’s VM) was built for a very specific purpose, and it achieves that purpose singularly well. https://www.youtube.com/watch?v=5SbWapbXhKo is probably the best articulation and demo of this I know of, so I’ll simply link to it here.
To achieve this purpose though there are trade offs. One of them is slower single threaded number crunching. This doesn’t make Elixir bad, it just isn’t what it’s meant for.
5 Likes
The BEAM is great at I/O and system supervision (to keep things running), especially with its abilities to call out to fast native code via NIF’s or Ports. Thus it is good for game servers, not clients.
2 Likes
Node.js is faster for single threads than Elixir/Erlang. However, Node.js is also single threaded. Last time I checked there was some multi-thread support arriving for Node but it was still experimental.
In Node, if your single thread crashes, that’s the end of you app. In Elixir, you have mechanisms to deal with that. This means Elixir apps will be more stable on the long run.
However, if it is raw power that you want, I must tell you that Node is horrible for heavy number crunching. Have you ever tried calculating PI on a Node.js app while trying to do anything else at all? You won’t be able to because Node.js will use it’s single thread to calculate PI blocking the entire app.
In Elixir, that won’t be a problem - ever. If you want to take out the best performance a CPU can give you, then IMO, Elixir is an easier choice because of all the juicy support it has for parallelism. In a Node.js app you only use 1 core, In Elixir you usually use as many as you can.
Granted there are solutions (to some extent) in the Node ecosystem for the issues I mentioned (PM2 comes to mind) but with Elixir you wont’ even have to consider 3rd party solutions.
I hope I have convinced you 
1 Like
Not so long ago I introduced an infinite loop/bug through Stream.cycle, in one part of an external synch and aggregate procedure, where I had assumed the calculation would always end up in <= 0 (halting at that point) so there was no worry about using Stream.cycle - some sets of data though didn’t conform to my assumptions nor calcs and they just went on forever. The remaining app went happily crunching millions of records while generating other couple million records, and next synch doing it all again and again, with no real difference in time spent. I only noticed something was wrong when the month changed and those sets were still showing info for the previous month while all others were getting updated regularly.
5 Likes
Am I wrong when I think that elixir should do better on number crunching when computer use more and more cores? It seems computers (and smartphones are computers, too) get more and more cores.
If you can parallelize your workload then sure, it’s what Joe Armstrong advocated for. But many algorithms cannot be easily parallelized, so single threaded performance still matters for those cases
4 Likes
Elixir is, IMHO, fine for number crunching. The reason it is not as efficient as other languages is the direct result of a tradeoff made long ago. Languages like Java (for example) will crash when dealing with numbers that are too big, for example. BEAM won’t. Ever. BEAM will not crash under circumstances other languages would but it comes at a cost.
Depending on your scenario, it may be a worth while trade. For me, personally, I think it is.
4 Likes
