V Mon, 4 Jan 2016 08:37:10 +0100 Sönke Ludwig via Digitalmars-d <[email protected]> napsáno:
> 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? > On my AMD FX4100 (4 cores) and my AMD AMD A10-7850K(4 core) it is return 1. > 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.
