Re: [boost] cache size runtime detection

Subject: Re: [boost] cache size runtime detection
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-08-18 05:12:16

On Tue, Aug 18, 2015 at 11:49 AM, Paul A. Bristow
<pbristow_at_[hidden]> wrote:
>
>
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrey Semashev
>> Sent: 17 August 2015 18:09
>> To: boost_at_[hidden]
>> Subject: Re: [boost] cache size runtime detection
>>
>> On 17.08.2015 19:56, Joel FALCOU wrote:
>> >>> It should definitely be a dedicated library. What I was thinking of
>> >>> for quite some time is a bit broader. My idea is a system
>> >>> capabilities library (Boost.SystemCaps) which would offer a generic
>> >>> interface for querying the current system properties such as:
>> >>>
>> >>> - Number of CPU cores/threads.
>
>> > Well, as far as creep goes, we can have a basic system put together
>> > adn expand it later.
>>
>> Yes, that's my thought as well. Such a library can never be complete. :)
>
> Not all systems will have all meaningful values for all features.
>
> Can we establish a good 'NotANumber' right at the start
>
> (preferably better than the -1 used in the C-ish
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/sysconf.html)?

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.

I'd really like to avoid dependency on a math library for NaNs or big
numbers. If we absolutely need to report an error or absence of the
actual data then I'd rather decide between boost::optional or an
exception. I'm leaning towards 'return optional when the data may be
legitimately absent, but throw exceptions when obtaining it results in
an error'. With this approach get_memory_size() would return uintmax_t
and throw in case of errors. On unsupported platforms (for which there
is no implementation) it would be absent, and a config macro would be
defined to indicate that.