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.
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
