On 08/17/2015 10:41 AM, Andrey Semashev wrote:
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.
I agree that the proposed Boost.SystemCaps would be a very useful library to have. At the risk of extending the scope creep even further, having the ability to discover the system's NUMA configuration would be another great capability. The Boost.Job library that was proposed the other day[1] already contains this functionality according to its README, but I haven't inspected it. Jason [1]: https://github.com/olk/boost-job