[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