std.parallelism: Request for Review [Summary of discussion]
Daniel Gibson
metalcaedes at gmail.com
Tue Mar 1 11:29:01 PST 2011
Am 01.03.2011 20:19, schrieb dsimcha:
> == Quote from jasonw (user at webmails.org)'s article
>> dsimcha Wrote:
>>> Ok, so that's one issue to cross off the list. To summarize the discussion so
>>> far, most of it's revolved around the issue of automatically determining how many
>>> CPUs are available and therefore how many threads the default pool should have.
>>> Previously, std.parallelism had been using core.cpuid for this task. This module
>>> doesn't work yet on 64 bits and doesn't and isn't supposed to determine how many
>>> sockets/physical CPUs are available. This was a point of miscommunication.
>>>
>>> std.parallelism now uses OS-specific APIs to determine the total number of cores
>>> available across all physical CPUs. This appears to Just Work (TM) on 32-bit
>>> Windows, 32- and 64-bit Linux, and 32-bit Mac OS.
>> Does a Hyperthread machine have 2x as much cores & worker threads ? In Pentium 4
> HT might reduce throughput, in Core i7 increase it.
>
> Someone please check on this for me. I'd assume that these OS functions return
> the number of logical CPUs, but they don't really seem to document and I don't
> have the relevant hardware.
Who cares, the Pentium4 sucks anyway :P
Intel decided to implement Hyperthreading and to report 2 core when there really
is only one, so it should be treated like 2 cores. If this makes things slower..
bad luck (Why did Intel introduce Hyperthreading if it makes things slower,
anyway?). Pentium4 (and probably also Pentium D, it's a dual-core Pentium4)
users still can set the number of worker threads manually.
Furthermore people (hopefully!) don't use Pentium4 for serious heavy calculations.
Cheers,
- Daniel
More information about the Digitalmars-d
mailing list