3 ms·
> this kind of composable parallelism are Go and Erlang, ... which therefore optimize for I/O throughput rather than CPU throughput Parallelism is always for C
by thekhatribharat 7y ago
> this kind of composable parallelism are Go and Erlang, ... which therefore optimize for I/O throughput rather than CPU throughput
Parallelism is always for CPU throughput, precisely why you don't run any more OS threads than the number of cores.
Concurrency primitives (whether in Go, Erlang or any other programming language) are meant for I/O-bound tasks. Let's not conflate concurrency primitives enabling I/O-bound tasks and parallelism primitives enabling CPU-bound tasks.
- elcritch 7y agoYou can still use Erlang style concurrency (or Go style as well) to truly parallelize CPU bound tasks. It’s a bit less efficient due to Erlangs design where you can’t readily share mutable data between processes but will still enable true parallel calculations on all cores. By default BEAM runs one execution thread per core. For example, it’d be trivial to write a true parallel merge sort in Erlang/Elixir. Now NodeJS or Python Asio style concurrency _are_ truly limited by their VMs and can’t do native parallel computations in a single process.
- chrisseaton 7y ago> precisely why you don't run any more OS threads than the number of cores It’s often worth running more than your number of cores, in order to keep execution units busy during memory fetches for example, or integer units busy while float units are a bottleneck otherwise. (Did a PhD partially on this kind of thing.)
- BubRoss 7y agoThat's what hyperthreading is for, which implies having the same number of threads as logical cores. Hyperthreading and out of order execution are meant to accomplish keeping the execution units busy.
- chrisseaton 7y agoNo it implies having the same number of OS threads as hardware threads, which is more than the number of hardware cores.