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