[Proposal] Adding CPUID Library in Boost
Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost. So any interest for it? I am currently evaluating the library http://libcpuid.sourceforge.net/ This has a permissive license that I think can go with the Boost license. I mailed the author also, although he does not use boost, he told he can give any fixes or support needed. ~Thanks smisra
On 07/12/12 16:48, Shakti Misra wrote:
Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost.
There is a SIMD library that will eventually be proposed to Boost. It contains among others means to detect whether a particular SIMD extension is supported, all of it header-only. You can re-use it or parts of it if you want, it's under the Boost Software license. <https://github.com/MetaScale/nt2/blob/master/modules/boost/simd/>
So any interest for it? I am currently evaluating the library http://libcpuid.sourceforge.net/
From a quick look, this library doesn't seem like it would work with MSVC x64. This actually fully parses the cpuid though.
Hi, I have been looking at nt2 for some time. It looks like a nice addition. But there is very less documentation, this led me to use AMD's SSEPlus. Apart from that any plans to add detection of below: number of cores or logical CPUs, cache sizes, CPU clock etc? ~Thanks Shakti On Sat, Dec 8, 2012 at 1:29 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 07/12/12 16:48, Shakti Misra wrote:
Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost.
There is a SIMD library that will eventually be proposed to Boost.
It contains among others means to detect whether a particular SIMD extension is supported, all of it header-only.
You can re-use it or parts of it if you want, it's under the Boost Software license. <https://github.com/MetaScale/**nt2/blob/master/modules/boost/**simd/<https://github.com/MetaScale/nt2/blob/master/modules/boost/simd/>
So any interest for it?
I am currently evaluating the library http://libcpuid.sourceforge.**net/ <http://libcpuid.sourceforge.net/>
From a quick look, this library doesn't seem like it would work with MSVC x64. This actually fully parses the cpuid though.
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
On 08/12/12 04:39, Shakti Misra wrote:
Hi, I have been looking at nt2 for some time. It looks like a nice addition. But there is very less documentation, this led me to use AMD's SSEPlus.
I personally don't find this library very compelling, but whatever helps you get stuff done. I noted your problems with nt2 and lack of documentation.
Apart from that any plans to add detection of below: number of cores or logical CPUs, cache sizes, CPU clock etc?
There is some of this in nt2, but not as part of the SIMD subcomponent.
2012/12/7 Shakti Misra <shakti.misra.study@gmail.com>:
Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost. So any interest for it?
I'm interested. Trunk version of GCC 4.8 have some compiler specific support for CPU detection, may be it'll help you: http://gcc.gnu.org/gcc-4.8/changes.html -- Best regards, Antony Polukhin
@Mathias: thanks for noting it down. I think it will be more usable with docs, because people may not always have time to search the source. I value your comments about libcpuid. @Antony: Thanks for link. My intention is about a library that can give details about a cpu features, and gpu features if possible. May be libcpuid is not the perfect yet, but can be a starting point to improve. May be I can start it as a separate project for my game engine and later merge if useful. On Sat, Dec 8, 2012 at 8:52 PM, Antony Polukhin <antoshkka@gmail.com> wrote:
2012/12/7 Shakti Misra <shakti.misra.study@gmail.com>:
Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost. So any interest for it?
I'm interested.
Trunk version of GCC 4.8 have some compiler specific support for CPU detection, may be it'll help you: http://gcc.gnu.org/gcc-4.8/changes.html
-- Best regards, Antony Polukhin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Here is one more helpful link https://github.com/facebook/folly/blob/master/folly/CpuId.h (but I`m not sure about compatibility of Boost and Apache2 licenses) -- Best regards, Antony Polukhin
From initial look, i think it does not check for all features.
On Fri, Dec 14, 2012 at 1:23 PM, Antony Polukhin <antoshkka@gmail.com>wrote:
Here is one more helpful link https://github.com/facebook/folly/blob/master/folly/CpuId.h (but I`m not sure about compatibility of Boost and Apache2 licenses)
-- Best regards, Antony Polukhin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Shakti Misra Sent: Friday, December 07, 2012 3:48 PM To: boost@lists.boost.org Subject: [boost] [Proposal] Adding CPUID Library in Boost
Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost. So any interest for it? I am currently evaluating the library http://libcpuid.sourceforge.net/ This has a permissive license that I think can go with the Boost license. I mailed the author also, although he does not use boost, he told he can give any fixes or support needed.
This will undoubtedly be useful to a few people. But I'm not sure if selection of instruction set should not be better done by the compiler at compile time, not at runtime. This should give the best possible performance (at the expense of different .exe versions). Or is this more useful for choosing the right version of .exe? Or is its usefulness as getting an ID of the computer - for which the serial numbers of other components like hard drives (perhaps in combination) or cookies might be a better bet? And of course it would need updating (from 2008) and full 'Boostification'. Header only very strongly preferred of course. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
But I'm not sure if selection of instruction set should not be better done by the compiler at compile time, not at runtime. This should give the best possible performance (at the expense of different .exe versions).
when dealing with `end users' you usually end up providing a binary that `runs everywhere' ... meaning you provide a binary that supports the most widely supported instruction set. for x86 this means no sseX, no cmpxchg8b, for x86_64 it means, no avx ... in these cases, a runtime dispatching is required to get most out of that CPU ... tim
On 11/12/12 16:18, Paul A. Bristow wrote:
But I'm not sure if selection of instruction set should not be better done by the compiler at compile time, not at runtime. This should give the best possible performance (at the expense of different .exe versions). Or is this more useful for choosing the right version of .exe?
That is indeed the only correct way to do it, though you may do so at the object level and not the executable level. You still need however to have a mechanism to choose which version of your function/exe to call...
I think if you look at the source of SSEPlus from AMD they are doing it at runtime. They have a CPUID functionality to get the correct SEE level, and dispatch to the correct intrinsic as per it. I do not have a perfect use case, but in gaming applications it can be beneficial to see if the GPU is present at run time, so as to use GPU or not. Mostly games would be compiled and supplied to the end user. Personally I use CPU ID when compiling it self, my script executes CPUID and sets my SSE_SUPPORT_LEVEL and GPU_SUPPORT macros to a certain value, which is then used. But it does not take into considerations the end user. As I use it for my experiments, and the binaries execute in my machine only. Ofcourse if it is needed by people Boostification needs to be done for it. On Tue, Dec 11, 2012 at 9:08 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 11/12/12 16:18, Paul A. Bristow wrote:
But I'm not sure if selection of instruction set should not be better
done by the compiler at compile time, not at runtime. This should give the best possible performance (at the expense of different .exe versions). Or is this more useful for choosing the right version of .exe?
That is indeed the only correct way to do it, though you may do so at the object level and not the executable level.
You still need however to have a mechanism to choose which version of your function/exe to call...
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
On 12/12/2012 06.05, Shakti Misra wrote:
I think if you look at the source of SSEPlus from AMD they are doing it at runtime. They have a CPUID functionality to get the correct SEE level, and dispatch to the correct intrinsic as per it. I do not have a perfect use case, but in gaming applications it can be beneficial to see if the GPU is present at run time, so as to use GPU or not. Mostly games would be compiled and supplied to the end user.
This fact of GPU check at runtime seems a poor argument to me. If the GPU is present then what? You need anyway to rely on DirectXXXX or on OpenGL anyway. If you want to instead use the GPU for GPGPU you can try to issue an OpenCL command and or CUDA one. So the fact you can via boost (!) detect if the GPU is present or not is like the 0.001% of the work. Regards Gaetano Mendola
On Fri, Dec 7, 2012 at 7:48 PM, Shakti Misra <shakti.misra.study@gmail.com> wrote:
Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost. So any interest for it? I am currently evaluating the library http://libcpuid.sourceforge.net/ This has a permissive license that I think can go with the Boost license. I mailed the author also, although he does not use boost, he told he can give any fixes or support needed.
I would find this library useful, although I have already implemented a similar library for my closed project. I remember considering a few open alternatives when I was deciding whether to write my own implementation or not and I didn't find a suitable one. Libcpuid looks promising but apparently lacks CPU cache parameters detection (LLC size, cache line size and prefetch size would be very useful). I'm not sure that Boost implementation should be based on an external library. Libcpuid seems to be x86-only while I would prefer Boost library to be easily extensible to other architectures. I know not every architecture provides a cpuid-like operation but there probably are other means. I'm not particularly geared towards a header-only or compiled implementation. My main requirement is that it should be lightweight to include.
On 12/12/2012 07.45, Andrey Semashev wrote:
On Fri, Dec 7, 2012 at 7:48 PM, Shakti Misra <shakti.misra.study@gmail.com> wrote:
Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost. So any interest for it? I am currently evaluating the library http://libcpuid.sourceforge.net/ This has a permissive license that I think can go with the Boost license. I mailed the author also, although he does not use boost, he told he can give any fixes or support needed.
I would find this library useful, although I have already implemented a similar library for my closed project. I remember considering a few open alternatives when I was deciding whether to write my own implementation or not and I didn't find a suitable one. Libcpuid looks promising but apparently lacks CPU cache parameters detection (LLC size, cache line size and prefetch size would be very useful).
I'm not sure that Boost implementation should be based on an external library. Libcpuid seems to be x86-only while I would prefer Boost library to be easily extensible to other architectures. I know not every architecture provides a cpuid-like operation but there probably are other means.
I'm not particularly geared towards a header-only or compiled implementation. My main requirement is that it should be lightweight to include.
Does it make sense to add to a not platform dependent library a very platform dependent feature? Basically what I'm reading is: I have several version of the same algorithm using different cpu features, after having spent a lot of time to write/test all of them then now I need a cpuid provided by boost. It's sound like eating an entire donkey and then leave the tail out. Regards Gaetano Mendola
On Wed, Dec 12, 2012 at 12:04 PM, Gaetano Mendola <mendola@gmail.com> wrote:
Does it make sense to add to a not platform dependent library a very platform dependent feature?
There are platform-specific components in Boost. Beside users, Boost.CPUID (or Boost.CpuCaps or whatever the name is) can also be viewed as a utility library that can be used by other libs.
Basically what I'm reading is: I have several version of the same algorithm using different cpu features, after having spent a lot of time to write/test all of them then now I need a cpuid provided by boost.
What's wrong with it? Boost is useful on its own. If I use it anyway in my project and I need cpuid, the proposed library will come handy. If you don't use Boost and don't want to add the dependency you are free to use any other implementation, including your own.
On 12/12/12 07:45, Andrey Semashev wrote:
I would find this library useful, although I have already implemented a similar library for my closed project. I remember considering a few open alternatives when I was deciding whether to write my own implementation or not and I didn't find a suitable one.
A rationale to have it as a library would be that people tend to do it wrong whenever they write inline asm. I have never seen so much bad inline asm than for the cpuid instruction.
I'm not sure that Boost implementation should be based on an external library. Libcpuid seems to be x86-only while I would prefer Boost library to be easily extensible to other architectures. I know not every architecture provides a cpuid-like operation but there probably are other means.
Which is why what I suggest is just part of Boost.SIMD. It is geared towards one thing and one thing only: detecting whether a particular SIMD extension is supported or not, and works across all architectures. There is also cache detection that we could optionally add, the code is already there. For reference, on other platforms you usually need to ask the operating system about the hardware capabilities, since detecting the capabilities can only be done by the kernel.
On Wed, Dec 12, 2012 at 12:53 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 12/12/12 07:45, Andrey Semashev wrote:
I'm not sure that Boost implementation should be based on an external library. Libcpuid seems to be x86-only while I would prefer Boost library to be easily extensible to other architectures. I know not every architecture provides a cpuid-like operation but there probably are other means.
Which is why what I suggest is just part of Boost.SIMD. It is geared towards one thing and one thing only: detecting whether a particular SIMD extension is supported or not, and works across all architectures. There is also cache detection that we could optionally add, the code is already there.
For reference, on other platforms you usually need to ask the operating system about the hardware capabilities, since detecting the capabilities can only be done by the kernel.
Vector programming is one of its applications, true. But hardly the only one. Consider also atomic ops and things like AES and RDRAND. Cache information can be useful for custom allocators. I'd rather have a separate library that is used by Boost.SIMD or at least a highly independent public component of Boost.SIMD (but then again, why is it not a first class library?).
Which is why what I suggest is just part of Boost.SIMD. It is geared towards one thing and one thing only: detecting whether a particular SIMD extension is supported or not, and works across all architectures. There is also cache detection that we could optionally add, the code is already there.
For reference, on other platforms you usually need to ask the operating system about the hardware capabilities, since detecting the capabilities can only be done by the kernel. Vector programming is one of its applications, true. But hardly the only one. Consider also atomic ops and things like AES and RDRAND. Cache information can be useful for custom allocators. I'd rather have a separate library that is used by Boost.SIMD or at least a highly independent public component of Boost.SIMD (but then again, why is it not a first class library?).
+1 run-time dispatching for cmpxchg8b on ia32 or cmpxchg16b on x86_64 all require access to CPUID and have absolutely nothing to do with SIMD programming. so i'd very much appreciate a separate lightweight library ... cheers, tim
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tim Blechmann Sent: Wednesday, December 12, 2012 9:09 AM To: boost@lists.boost.org Subject: Re: [boost] [Proposal] Adding CPUID Library in Boost
Which is why what I suggest is just part of Boost.SIMD. It is geared towards one thing and one thing only: detecting whether a particular SIMD extension is supported or not, and works across all architectures. There is also cache detection that we could optionally add, the code is already there.
For reference, on other platforms you usually need to ask the operating system about the hardware capabilities, since detecting the capabilities can only be done by the kernel. Vector programming is one of its applications, true. But hardly the only one. Consider also atomic ops and things like AES and RDRAND. Cache information can be useful for custom allocators. I'd rather have a separate library that is used by Boost.SIMD or at least a highly independent public component of Boost.SIMD (but then again, why is it not a first class library?).
+1
run-time dispatching for cmpxchg8b on ia32 or cmpxchg16b on x86_64 all require access to CPUID and have absolutely nothing to do with SIMD programming. so i'd very much appreciate a separate
lightweight
library ...
Sounds like a project that could be started neatly now using the shiny new GitHub system announced by Beman last week. Documentation for Git and Modular Boost conversion Needs to be Boost Licence throughout (can be dual licensed if really necessary) but all the files should carry the usual text, and the copyright of the author(s) (and include Shakti Misra if he is doing the Boostification). If it can be included by Boost.SIMD, so much the better, so some collaboration might be good? (But can be duplicated if necessary). Needs some Boost.Test style tests too of course. This may be tricky if the testers change hardware? And some docs too. Tell me if I can help. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
participants (7)
-
Andrey Semashev -
Antony Polukhin -
Gaetano Mendola -
Mathias Gaunard -
Paul A. Bristow -
Shakti Misra -
Tim Blechmann