Futurism lib (futures in D)
Kevin Bealer
kevinbealer at gmail.com
Wed Jan 24 12:48:24 PST 2007
== Quote from Kristian Kilpi (kjkilpi at gmail.com)'s article
> On Mon, 22 Jan 2007 03:19:53 +0200, Kevin Bealer <kevinbealer at gmail.com>=
...
> Nice job! I'm looking forward to use futures in the future. :)
> BTW, is there a way to know the number of hardware threads (and maybe the
> number of CPUs)?
>
> IMHO it would be good to have something like this too:
> new ThreadPool(4); //pool of 4 threads
> new ThreadPool(); //pool of X threads, where X is the # of hardwa=
> re =
> threads
> new ThreadPool(1.5); //pool of 1.5 * X threads (>=3D 1, rounded up =
> perhaps)
> (I think one should, in general, always use thread counts relative to th=
> e =
> number of hardware threads.)
I added something like this to Futurism; it uses five criteria to pick the
number of threads to use, in this order:
1. Value passed to constructor (if any).
2. Number from envar FUTURISM_DEFAULT_THREADS (if any).
3. On linux, use #cores * overlap from /proc/cpuinfo.
4. On other x86, use std.cpuid.threadsPerCore * overlap.
5. If all else fails, assume 2 cpus * overlap.
Here, overlap is defined as 4, so typically you will see
4 threads on a single CPU machine or 8 on a dual core.
The envar is there so that people with several multithreaded
apps can balance their own system load if they like. All
numbers except for #1 will actually use N-1 worker threads,
because the library is designed so that the main thread pulls
some of the weight.
Kevin
More information about the Digitalmars-d-announce
mailing list