Subject: Re: [boost] cache size runtime detection
From: Joel FALCOU (joel.falcou_at_[hidden])
Date: 2015-08-18 15:16:39
On 18/08/2015 11:12, Andrey Semashev wrote:
> For some data it is enough to return some meaningful pessimistic
> default in case if the actual value cannot be obtained. E.g. for ISA
> extensions we could return 'not supported', for cache size return 0,
> for OS version string return an empty string (or a fixed string based
> on the data available at compile time) and so on.
> For other data this doesn't quite work though. We can't return 0 as
> the system RAM size, for instance - except we can but then the user's
> application would have to check for this special value. I'm not sure
> what is best in this case.
One other stuff to consider, as we had reort of this issue by our users,
is that such facility should have cached and non-cached retrieval function.
Using CPUID to grab SIMD facility for example is slow enough to have a
noticable impact on computing in some cases, hence the need for caching.
I think some of those config are static anyway (you won't remove a CPU
feature midfight) and must be cached in static value at start-up.
Others, like for example amount of available free RAM must not.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk