On 30/10/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
On 10/30/07, Igor Stasenko siguctua@gmail.com wrote:
We are really don't need to have more than a fixed number of threads in VM (one for each core, and maybe 1 more for GC).
I'm totally on board the idea of native threads being internal to the VM, and client code not being aware. But my plan is to provide a way change how many threads that is, as 1 per CPU is not always optimal.
I agree on that. But such details can be discovered later.
When Erlang first did this, their approach was making a schedular 1-to-1 with a native thread. They seem to hit max performance at about 4 native threads per CPU core (if you want the reference I will try to dig it up, but I'm sure if your google-fu is strong, you should find it fairly quick).
Most of reasons why CPU not utilized at 100% is using a blocking I/O calls. Then a simplest solution to not use them and instead of blowing up the number of threads use asynchronous I/O . Most major platforms support asynchronous I/O and there are many libraries which support async data handling almost in each area we need for. We just need to build on top of them.