Using CPUID to determine CPU specifications, a reliable solution?

Question

I am trying to collect information about my processor with __cpuid() . Despite the fact that this works correctly on my computer, when I run my program on my colleague's computer, it detects the Intel Core2 Quad Q6600 as hyper-only, although according to the specifications on Intel's own website, this is not so.

__cpuid() also detects the wrong number of “logical cores”, as shown here: Programmatically determine the number of physical processors / cores or if hyperthreading is active on Windows, Mac and Linux . Where he claims that the Intel Xeon E5520 has 16 logical cores and 8 physical ones.

I tried to run the code found in this thread on my own computer, Intel i7 2600K , giving me the same numbers as for Xeon.

So how reliable is __cpuid() really? In my own experience, this does not seem so reliable. Is there something very fundamental to me?

Answer 1

You can trust the CPUID, you just need to use it correctly. in this case, this means a correct enumeration of the topology. you get 16 logical processors because the field received from it represents the maximum that it can support, and not what it really is. the value obtained for the kernels is actually a logical number.

the code in the subject line is very simple and is meant as a starting point, on my system (i7 2720QM) I also write invalid data, but using my own code that checks the topology for CPU CPUID mappings, I get the correct results.

Answer 2

There is almost certainly a gap in the [x2] APIC ids on your processor, which means that some APIC value is not mapped to any logical processor. You must use the cxuid 0xB sheet to find out. You can look at the Intel reference code and algorithm ( https://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ ) for the steps, but it comes to a call with EAX = 0xB , ECX = 0 and get in EBX the number of logical processors (threads) per core, and then call cpuid again with EAX = 0xB, ECX = 1 and get in EBX the number of logical processors per processor packet.

The old method of using sheet 0x1 cannot take into account the spaces of the APIC identifier. Alas, the sample code is still set on the MSDN Visual C ++ 2013 help page ( http://msdn.microsoft.com/en-us/library/hskdteyh.aspx ), but it was wrong for processors in 2010 and after that because you found out if the code is using from MSDN or similarly the wrong code from other sources. On the cpuid Wikipedia page, which I recently updated after I tried to understand this problem, there is now a developed example in the section "Intel thread / core and cache topology" for listing the topology on the processor with spaces for the APIC identifier, with additional information, in including how to determine which bits of the APICs are actually used and which are “dead”.

Given the code sample currently offered by Microsoft on the __cpuid () page, this is basically the same question as Returning the logical CPU 16 instead of 4 , as it is rooted in the same interpretation of Intel errors. As an explanation of the poor show, the MSDN code that they offer is working fine until 2010 or so; Intel used a similar method before x2APIC, as you can see in this old video / article: https://software.intel.com/en-us/articles/hyper-threading-technology-and-multi-core-processor- detection If you look at the different versions of the MSDN page on __cpuid, their sample code has basically remained unchanged since 2008 ...

As for the single hyper-thread detection bit, this is a longer story that already answered me in Why is Hyper-threading information obtained as supported on processors without it? In short, this rather outdated bit tells you whether the processor supports a package of more than one logical processor, whether using hypetreading or multi-core technologies. Thus, the name of the bit is misleading.

In addition, I suggest changing the title of your question to "Using CPUID to determine processor topology, a reliable solution?" because I found your question completely by accident. I was looking for Sandy Bridge cpuid dumps on google when I found your question.