Re:The philosophies of software languages, from Go to Elixir
by matlin on Thursday April 18, 2019 @07:25PM
(#19695667)
Erlang VM is actually design around full CPU utilization. It will typically spin up a thread for each core and schedule processes (Erlang not system) across them. It's actually because it's designed to not share memory that it excels at parallelism!
Re:The philosophies of software languages, from Go to Elixir
by pcwalton on Thursday April 18, 2019 @11:05PM
(#19696794)
This design does not do well at CPU parallelism for many workloads. Consider texture sampling in rasterization, to name just one example, in which shared memory is extremely important to get good performance.
Re:The philosophies of software languages, from Go to Elixir
by felixgallo on Thursday April 18, 2019 @11:35PM
(#19696914)
thing is not optimized for another thing and tradeoffs exist, more news at 11.
> To take full advantage of multicore processors, a programming language needs to provide mechanisms for concurrency…All of the languages in this chapter—Go, Rust, Kotlin, and Elixir—were specifically designed to address this need for concurrency.
This confuses concurrency and parallelism. All of these languages have support for I/O concurrency. But the CPU parallelism support varies significantly. Go is fairly bad at such parallelism, because it doesn't have generics for concurrent data structures, parallel iterators, etc. Rust has pretty good support for it, with Rayon and Crossbeam. Kotlin does too, since it inherits the Java ecosystem, including the excellent java.util.concurrent package. I'm not sure about Elixir; my understanding is that the Erlang VM is not really designed around shared memory, which limits the potential for CPU parallelism.