[fpc-devel] AMD & Intel CPUCount
Marco van de Voort
marcov at stack.nl
Fri Dec 28 17:51:06 CET 2012
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.
More information about the fpc-devel
mailing list