vibe.d benchmarks

[Sönke Ludwig via Digitalmars-d]

Am 31.12.2015 um 13:44 schrieb Daniel Kozak via Digitalmars-d:
>
> vibe.d has (probably) bug it use threadPerCPU instead of corePerCPU in
> setupWorkerThreads, here is a commit which make possible to setup it by
> hand.
>
> https://github.com/rejectedsoftware/vibe.d/commit/f946c3a840eab4ef5f7b98906a6eb143509e1447
>
> (I just modify vibe.d code to use all my 4 cores and it helps a lot)
>
> To use more threads it must be setup with distribute option:
>
> settings.options |= HTTPServerOption.distribute;
> //setupWorkerThreads(4); // works with master
> listenHTTP(settings, &hello);

For me, threadsPerCPU correctly yields the number of logical cores (i.e. 
coresPerCPU * 2 for hyper threading enabled CPUs), which is usually the 
optimal number of threads*. What numbers did you get/expect?

One actual issue could be that, judging by the name, these functions 
would yield the wrong numbers for multi-processor systems. I didn't try 
that so far. Do we have a function in Phobos/Druntime to get the number 
of processors?

* Granted, HT won't help for pure I/O payloads, but worker threads are 
primarily meant for computational tasks.