Istnieje prawie na pewno luka w identyfikatorach APIC [x2] na procesorze, co oznacza, że niektóre wartości identyfikatorów APIC nie są odwzorowywane na żadne procesory logiczne. Powinieneś użyć liścia 0xB z cpuid, aby się dowiedzieć. Możesz przejrzeć referencyjny kod i algorytm Intela (https://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/) dla kroków, ale to sprowadza się do wywoływania z EAX = 0xB, ECX = 0 i uzyskiwania w EBX liczby logicznych procesorów (wątków) na rdzeń, a następnie wywoływania cpuid ponownie z EAX = 0xB, ECX = 1 i uzyskiwanie w EBX liczby logicznych procesorów na pakiet procesorów.
Stara metoda użycia liścia 0x1 nie może uwzględniać luk w identyfikatorach APIC. Niestety, jest to przykładowy kod nadal podany na stronie referencyjnej MSDN Visual C++ 2013 (http://msdn.microsoft.com/en-us/library/hskdteyh.aspx) i jest niepoprawny dla procesorów wykonanych w 2010 roku i później, ponieważ dowiedziałeś się, czy używając kodu z MSDN lub podobnie niepoprawnego kodu z innego miejsca . Strona Wikipedii na cpuid, którą niedawno zaktualizowałem, po tym, jak zmagałam się, aby zrozumieć problem, ma teraz opracowany przykład w dziale "Intel wątek/rdzeń i topologia pamięci podręcznej" do wyliczenia topologii na procesorze z lukami APIC, z dodatkowymi szczegółami, w tym jak ustalić, które bity identyfikatorów APIC są rzeczywiście używane i które są "martwe".
Biorąc pod uwagę przykładowy kod aktualnie oferowany przez Microsoft na ich stronie __cpuid(), jest to w zasadzie to samo pytanie, co Logical CPU count return 16 instead of 4, ponieważ jest on zakorzeniony w tym samym błędem interpretacji specyfikacji Intela. Jako wytłumaczenie słabego programu MSDN, kod, który oferują, działał dobrze przed rokiem 2010; Intel użył do przedstawienia podobnej metody przed wprowadzeniem x2APIC, jak widać w tym starym wideo/artykule: https://software.intel.com/en-us/articles/hyper-threading-technology-and-multi-core-processor-detection Jeśli spojrzysz na różne wersje strony MSDN na __cpuid, ich próbka kodu zasadniczo pozostała niezmieniona od 2008 roku.
Co do pojedynczego bitu wykrywania hiperwątkowego, to jest dłuższa historia, na którą już odpowiedziałem: Why does Hyper-threading get reported as supported on processors without it?. Krótko mówiąc, ten raczej starszy bit mówi ci, czy pakiet procesora obsługuje więcej niż jeden procesor logiczny, czy to za pośrednictwem wielowartościowej, czy wielordzeniowej technologii. Nazwa bitu jest więc raczej myląca.
Sugeruję również zmianę tytułu pytania na "Używanie CPUID do wykrywania procesora topologii, niezawodne rozwiązanie?" ponieważ znalazłem twoje pytanie całkowicie przez przypadek. Szukałem zrzutu cpuid Sandy Bridge na google, gdy znalazłem twoje pytanie.
Jeśli nie masz zamiaru używać __cpuid(). Możesz użyć OpenMPs omp_get_num_procs(), który powinien zwrócić ilość wątków, które twój CPU może uruchomić jednocześnie. Nie mam pojęcia, jak wiarygodne są te informacje. Nigdy nie miałem żadnych problemów w ten sposób. – Compuholic
CPUID jest zasadniczo dość wiarygodny, ale czasami może być mylący lub niepoprawny. Twój procesor może bardzo dobrze obsługiwać jedną funkcję, ale twoja płyta główna nie (lub ją wyłączyła), więc zostanie zgłoszona jako obecna, ale nie działa. Istnieją biblioteki, które pobierają CPUID i próbują uczynić go bardziej niezawodnym, z bazą danych poprawek i tym podobnych. – Kitsune
Ale jeśli procesor nie obsługuje funkcji HyperThreading i CPUID, informując o tym, że jest obecny, to jest to naprawdę problem z płytą główną, mogłem zobaczyć, że jest na odwrót, gdzie procesor obsługuje HTT, ale nie płytę główną i dlatego podczas sprawdzania HTT otrzymujesz fałsz. – Alex