OK, so cpuid isn't the hardest thing in the world to use...
But has anyone got a pre-built c++ class (or even straight c code) which gets the number of CPUs, number of cores, and (in the case of intel) whether or not hyperthreading is enabled? CPU frequency would be usefull too, but not overly important, as would various SSE capabilities.
I know, I'm lazy! But this must have written a gazillion times already!
Thank you kindly!
Has anyone got a simple cpuid class to share?
I know, I'm lazy! But this must have written a gazillion times already!
I'm afraid I'll have to agree with that. The LMGTFY link is quite right.
On the top of the search results:
* how to use the __CPUID to do what you asked
* how to use WMI to do what you asked
* how to pull from the registry entry HKLM\Hardware\Description\System\CentralProcessor\ to do what you asked.
Three ways to do it in the top five search results, each with code examples.
Author
Thanks for the replies.
FWIW, I know how to use cpuid and the Windows functions, but I'm trying to get the most important information in a non OS specific manner.
The trouble with cpuid is that most libs actually report the wrong number of logical processors - my i7 920 is reported as having 16 logical processors, which according to intel docs is actually the maximum number of logical cores representable in a given core technology.
The correct way is the query all the cache information and find different levels of shared cache, although I think there may be another 'hack' using bits 14 to 31 in 0x4H. I was interested to see if there was a definitive way that's universally accepted.
FWIW, I know how to use cpuid and the Windows functions, but I'm trying to get the most important information in a non OS specific manner.
The trouble with cpuid is that most libs actually report the wrong number of logical processors - my i7 920 is reported as having 16 logical processors, which according to intel docs is actually the maximum number of logical cores representable in a given core technology.
The correct way is the query all the cache information and find different levels of shared cache, although I think there may be another 'hack' using bits 14 to 31 in 0x4H. I was interested to see if there was a definitive way that's universally accepted.
Author
Th correct answer is, don't use __cpuid.
__cpuid only gives the processor caps, not what is actuallu enabled. For that, you MUST use the OS services.
In the worst case scenario, Hypertherading may be disabled in the BIOS, and certain physical cores may be disbaled by the OS. Which means that __cpuid is not a valid way of checking cpu caps.
So to conlcude, use the OS service to understand the actual environment you're in.
__cpuid only gives the processor caps, not what is actuallu enabled. For that, you MUST use the OS services.
In the worst case scenario, Hypertherading may be disabled in the BIOS, and certain physical cores may be disbaled by the OS. Which means that __cpuid is not a valid way of checking cpu caps.
So to conlcude, use the OS service to understand the actual environment you're in.
Unfortunately I've even seen the OS (Windows, not sure which version) lie about this.
I believe any code that does not look at the APIC IDs (this apparently including libcpuid, after a quick browse) is completely broken in that respect. Intel has long said APIC IDs are not necessarily contiguous (0..#enabled-1). However, even the package/core/logical fields extracted with their recommended algorithm are not contiguous - you might see coreID = {0,1,6,7}.
Here's my best attempt at getting it right, successfully tested on some interesting hardware (up to 64 processors) -
http://trac.wildfire...64/topology.cpp
I believe any code that does not look at the APIC IDs (this apparently including libcpuid, after a quick browse) is completely broken in that respect. Intel has long said APIC IDs are not necessarily contiguous (0..#enabled-1). However, even the package/core/logical fields extracted with their recommended algorithm are not contiguous - you might see coreID = {0,1,6,7}.
Here's my best attempt at getting it right, successfully tested on some interesting hardware (up to 64 processors) -
http://trac.wildfire...64/topology.cpp
Author
[quote name]Jan Wassenberg [/quote]
Thank you very much! I'll enjoy going through the source. A quick question... does this take into account someone disabling HT in the BIOS, or someone disabling cores in the OS?
I'm now using GetLogicalProcessorInformation(), which (in theory) should give me the actual processor caps. Is your version a better way of determining this?
Thank you very much! I'll enjoy going through the source. A quick question... does this take into account someone disabling HT in the BIOS, or someone disabling cores in the OS?
I'm now using GetLogicalProcessorInformation(), which (in theory) should give me the actual processor caps. Is your version a better way of determining this?
Yes, those cases (as well as restricted process affinity) would be detected - if a core/logical processor isn't running/available, its APIC ID will not be counted.
Unfortunately I don't remember which of the Windows functions returned inaccurate information. I would advise against the use of GetLogicalProcessorInformation, though - its interface is just about as complex as digging through the APIC IDs and it cannot be relied upon to differentiate logical processors vs cores.
Unfortunately I don't remember which of the Windows functions returned inaccurate information. I would advise against the use of GetLogicalProcessorInformation, though - its interface is just about as complex as digging through the APIC IDs and it cannot be relied upon to differentiate logical processors vs cores.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
