4 ms·

I don't think Erlang's VM is that optimized. Currently (as far as I remember) the upper limit is to run 1024 schedulers (threads) but I imagine it certainly won

by loxs 10y ago

I don't think Erlang's VM is that optimized. Currently (as far as I remember) the upper limit is to run 1024 schedulers (threads) but I imagine it certainly wont be 10x more efficient than running 100 schedulers on 100 core machine

qaq 10y ago
Architecturally it's a perfect match for such CPUs. If you listen to Joe talks he was talking about designing for 1000 core cpus more then 10 years ago. It is his stated opinion that Erlang is perfect match for such situations.
- loxs 10y ago
  Of course it's (much) better than anything else... though my experience is that it's quite hard to scale your application that much... You always need some shared resource and it gets ugly. And I also suspect Erlang has some implementation quirks (for example the algorithm of deciding which scheduler gets which process) that will prevent it from scaling that much. Yeah, I do believe that some day we'll reach such scalability, probably just not today.
  - qaq 10y ago
    Each scheduler has it's own run queue there is higher level migration logic to balance run queues based on statistics collected.
- shoover 10y ago
  He's also mentioned FPGAs in similar terms, but I've not seen any news lately on that topic. Is it not practical? Not worth the effort? This is a different ballgame but interesting, a recent Raspberry Pi 2 experiment [1] demonstrated good scaling of an Erlang application on multicore ARM up until the concurrency limit inherent in the application (around 128 processes). [1] - https://medium.com/@pieterjan_m/erlang-pi2-arm-cluster-vs-xeon-vm-40871d35d356#.y68s4ha6n https://medium.com/@pieterjan_m/erlang-pi2-arm-cluster-vs-xe...