vibe.d benchmarks

Daniel Kozak via Digitalmars-d digitalmars-d at puremagic.com
Mon Jan 4 02:31:11 PST 2016


V Mon, 4 Jan 2016 08:37:10 +0100
Sönke Ludwig via Digitalmars-d <digitalmars-d at puremagic.com> 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.




More information about the Digitalmars-d mailing list