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