Re: [boost] cache size runtime detection

Subject: Re: [boost] cache size runtime detection
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-08-18 05:50:03

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrey Semashev
> Sent: 18 August 2015 10:12
> To: boost_at_[hidden]
> Subject: Re: [boost] cache size runtime detection
> 
> 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.

I wasn't implying THE FP math NaN - which is why 'NotANumber' is in quotes ;-)

> 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.

Sounds reasonable - I'm just suggesting to give it some thought - which you have.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]