-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 17 August 2015 15:42 To: boost@lists.boost.org Subject: Re: [boost] cache size runtime detection

On 17.08.2015 17:28, Joel FALCOU wrote:

...

We have a bunch of cross-platform CPU cache size and cache line size detection that we want to offload into boost in preparation for the first reviewable version of Boost.SIMD.

It's rather smallish in term of API but the code is non-trivial. I think it's a bit broad to be in utility/core, doesn't really fit in align and IIRC there is no "general memory related" library in Boost.

Questions:

1/ would there be interest to have such utility in Boost ?

Yes. At least, that would be interesting for me.

...

2/ here should we put it ? Is Boost.Memory a viable solution or could it be hosted somewhere non-trivial ?

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. - Current CPU core capabilities (vendor string, instruction set extensions, cache properties, etc.). Probably, this would need to support heterogenous systems as well. - System RAM size. - OS version string.

There may be many more properties to query for in the future, but at least those would be a good start, IMHO.

Sounds very sensible to me too. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

...

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.

Doesn't Bosot.Thread has that already ?

...

- Current CPU core capabilities (vendor string, instruction set extensions, cache properties, etc.). Probably, this would need to support heterogenous systems as well.

We currently have a wrapper for CPUID(EX) like calls so it may just fit there.

...

- System RAM size. - OS version string.

Those I dunno except it's non-trivial. Well, as far as creep goes, we can have a basic system put together adn expand it later.

On 17 August 2015 at 18:08, Andrey Semashev wrote:

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.

Doesn't Bosot.Thread has that already ?

If you mean thread::hardware_concurrency() then it doesn't allow to differentiate HT threads from the real cores. Plus, as suggested, support for NUMA topology would be good as well.

hwloc is a library that already provides this information: http://www.open-mpi.org/projects/hwloc/, and goes further to provide locations of PCIe devices, and facilities to bind memory allocations to specific NUMA domains. There is then the netloc library built on top of this ( http://www.open-mpi.org/projects/netloc/) which provides topology information at the network level using infiniband and openflow as data sources.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 17 August 2015 18:09 To: boost@lists.boost.org 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)? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 18 August 2015 10:12 To: boost@lists.boost.org Subject: Re: [boost] cache size runtime detection

On Tue, Aug 18, 2015 at 11:49 AM, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 17 August 2015 18:09 To: boost@lists.boost.org 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

I wasn't implying THE FP math NaN - which is why 'NotANumber' is in quotes ;-) 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 +44 (0) 1539 561830

On 18.08.2015 22:16, Joel FALCOU wrote:

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.

I believe most of the API should be non-caching and when caching is reasonable we should probably think of a stateful approach. Let the user cache the state, if needed, and also deal with inherent thread safety issues. The CPU features are especially difficult because there are two usage patterns for this information that I have faced: 1. Collect all necessary CPU info at once and then use it to configure user's application (e.g. setup function tables and constants). This is typically done relatively rarely, like at application startup or some internal context initialization. 2. Query for one or few features, perhaps for using in a local condition to jump to a specialized code branch. The code that makes this query can be called often, so it must be fast. Satisfying both these patterns in an effective way is not easy, but I think it should be possible if we represent CPU features collection as an object that the user can create and cache, if needed. The features can be obtained lazily and cached within this object. Something along these lines (pseudo-code): namespace boost::sys_info::cpu { enum class feature_tag { // Arch-specific values sse, sse2... _count }; template< typename... Features > struct feature_list; // This struct can be specialized for different feature tags template< feature_tag Tag > struct feature { // In specializations, we can describe pre-requisites // for each feature, e.g. there must be OSXSAVE and // the OS must be saveing/restoring YMM registers // in order to be able to use AVX. typedef feature_list< ... > prerequisites; }; constexpr feature< feature_tag::sse > sse = {}; constexpr feature< feature_tag::sse2 > sse2 = {}; ... class features { // The flags indicate which features have been queried std::bitset< feature_tag::_count > m_cached; // The flags indicate which features are supported std::bitset< feature_tag::_count > m_values; public: // By default creates an empty object. // The only thing it may need to do // is to obtain the max cpuid function number. // If do_init == true, calls init() automatically. explicit features(bool do_init = false); // Obtains all features at once void init(); // If not cached already, tests for the feature and its // pre-requisites and returns the flag template< feature_tag Tag > bool operator[] (feature< Tag >); }; } // namespace boost::sys_info::cpu // Usage example void foo() { namespace cpu = boost::sys_info::cpu; cpu::features f; if (f[cpu::sse]) // SSE-optimized code foo_sse(); else // generic code foo_generic(); } I know there are complications and possible ways of optimization. In particular, we actually discover multiple features with one cpuid call, so we might want to fill multiple flags per feature query. And for /proc/cpuinfo backed solution we might want to always parse the whole file at once. But I like this interface and the design looks extensible.

On 20/08/2015 01:15, Andy Thomason wrote:

I would love to see a comprehensive SIMD library similar to those on game consoles.

That's what Boost.SIMD is about. HEre we're speakign of just detecting the configuration of the CPU.

On 20.08.2015 22:04, Rob Stewart wrote:

On August 18, 2015 4:23:24 PM EDT, Andrey Semashev wrote:

...

namespace boost::sys_info::cpu {

enum class feature_tag { // Arch-specific values sse, sse2... _count };

template< typename... Features > struct feature_list;

// This struct can be specialized for different feature tags template< feature_tag Tag > struct feature { // In specializations, we can describe pre-requisites // for each feature, e.g. there must be OSXSAVE and // the OS must be saveing/restoring YMM registers // in order to be able to use AVX. typedef feature_list< ... > prerequisites; };

constexpr feature< feature_tag::sse > sse = {}; constexpr feature< feature_tag::sse2 > sse2 = {}; ...

class features { // The flags indicate which features have been queried std::bitset< feature_tag::_count > m_cached; // The flags indicate which features are supported std::bitset< feature_tag::_count > m_values;

public: // By default creates an empty object. // The only thing it may need to do // is to obtain the max cpuid function number. // If do_init == true, calls init() automatically. explicit features(bool do_init = false);

This is the only thing which looks odd to me. It would be better to use an enumerated type, rather than bool here, or you could use the named constructor idiom (and make init() private).

That is, create a default constructed features for no caching, or use features::complete(), say, to get one pre-populated. Otherwise, pass something like pre_load rather than true.

I'd prefer to allow the ability to fill the (possibly partially filled) features object with an explicit function call. Also the static factory function makes an extra copy in the following pattern: void foo() { static cpu::features f = cpu::features::complete(); } I agree that using an enum or a special tag type instead of bool would be better. That way the code would be more descriptive.

On 17/08/2015 19:11, Andrey Semashev wrote:

On 17.08.2015 20:01, Glen Fernandes wrote:

...

Andrey wrote:

...

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. - Current CPU core capabilities (vendor string, instruction set extensions, cache properties, etc.). Probably, this would need to support heterogenous systems as well. - System RAM size. - OS version string.

This sounds like a good idea. It would almost be runtime-analogous to Boost.Config (Boost.RuntimeConfig or Boost.SystemConfig).

The name is not final, just something I refer the idea to. I'm in favor of shorter names though, like Boost.SysInfo, perhaps.

What about Boost.SysCtl to mimic the sysctl() function ?

Joel FALCOU wrote:

What about Boost.SysCtl to mimic the sysctl() function ?

I thought that the function was sysconf? http://pubs.opengroup.org/onlinepubs/009695399/functions/sysconf.html

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: 19 August 2015 20:25 To: boost@lists.boost.org Subject: Re: [boost] cache size runtime detection

On 17/08/15 21:03, Joel FALCOU wrote:

...

On 17/08/2015 19:11, Andrey Semashev wrote:

...

...

The name is not final, just something I refer the idea to. I'm in favor of shorter names though, like Boost.SysInfo, perhaps.

What about Boost.SysCtl to mimic the sysctl() function ?

I quite like SysInfo personally.

Works for me (and Boost.SysCtl doesn't - implies some method of *controlling* something). Yours bikeshedingly, Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830