[fpc-devel] AMD & Intel CPUCount

Sven Barth pascaldragon at googlemail.com
Fri Dec 28 18:47:38 CET 2012

On 28.12.2012 17:51, Marco van de Voort wrote:
> In our previous episode, Mark Morgan Lloyd said:
>>> Note that in applications this should never be used for more than the
>>> default of a configurable option anyway.
>>> The way new processors deal with this, can change at any time, and not
>>> making this configurable would seriously limit the durability of the
>>> software.
>> If the number of CPUs changed during the lifetime of an app, it would
>> need to know the current situation rather than the original one.
> Or need to be restarted. But I think that is already several levels beyond
> something like a simple corecount, since that pretty much only signals a
> default for how many workerthreads can be started somewhat efficiently.
> (and then you would prefer something event based rather than continues
> polling to see if the #cores changes)
> HT cores shouldn't be included in that, since they mostly only improve
> thread latency.  For the workerthreads metric, physical cores +1 is probably
> closer to an optimal situation than virtual cores on most processor.

CPUCount on Delphi does return the number of HT cores. E.g. "8" on an 
Intel i7 QuadCore processor.


More information about the fpc-devel mailing list