C'è quasi certamente una lacuna negli id APIC [x2] sul processore, il che significa che alcuni valori degli ID APIC non si associano a nessun processore logico. Dovresti usare la foglia 0xB di cpuid per scoprirlo. È possibile consultare il codice e l'algoritmo Intel di riferimento (https://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/) per i passaggi, ma ricopre fino a chiamare con EAX = 0xB, ECX = 0 e ottenere in EBX il numero di processori logici (thread) per core e quindi chiamare di nuovo cpuid con EAX = 0xB, ECX = 1 e ottenere in EBX il numero di processori logici per pacchetto processore.
Il vecchio metodo di utilizzo di foglia 0x1 non può giustificare gli spazi di identificazione APIC. Purtroppo questo è il codice di esempio ancora fornito nella pagina di riferimento MSDN Visual C++ 2013 (http://msdn.microsoft.com/en-us/library/hskdteyh.aspx) e non è corretto per i processori realizzati nel 2010 e successivamente, come è stato scoperto utilizzando il codice di MSDN o codice analogo non corretto da altrove . La pagina di Wikipedia su cpuid, che ho aggiornato di recente dopo aver cercato di capire il problema, ora ha un esempio nella sezione "Intel thread/core and cache topology" per enumerare la topologia su un processore con gap di id APIC, con ulteriori dettagli, incluso come determinare quali bit degli ID APIC sono effettivamente utilizzati e quali sono "morti".
Dato il codice di esempio attualmente offerto da Microsoft nella pagina __cpuid(), questa è fondamentalmente la stessa domanda di Logical CPU count return 16 instead of 4 perché è radicata nello stesso errore di interpretazione delle specifiche Intel. Come spiegazione per il cattivo spettacolo di MSDN, il codice che offrono funzionava bene prima del 2010 o giù di lì; Intel forniva un metodo simile prima che fosse introdotto l'x2APIC come puoi vedere in questo vecchio video/articolo: https://software.intel.com/en-us/articles/hyper-threading-technology-and-multi-core-processor-detection Se guardi le varie versioni della pagina MSDN su __cpuid, il loro codice di esempio è rimasto sostanzialmente lo stesso dal 2008 ..
Per quanto riguarda il singolo bit di rilevamento hyperthreaded, questa è una storia più lunga, già risposta da me allo Why does Hyper-threading get reported as supported on processors without it?. In poche parole, quel bit piuttosto legacy ti dice se il pacchetto del processore supporta più di un processore logico, sia tramite la tecnologia hypethreading o multi-core. Il nome del bit è quindi piuttosto fuorviante.
Inoltre, ti suggerisco di cambiare il titolo della tua domanda in "Utilizzo di CPUID per rilevare CPU topologia, soluzione affidabile?" perché ho trovato la tua domanda completamente per caso. Stavo cercando i dump cpuid di Sandy Bridge su google quando ho trovato la tua domanda.
Se non si è inclini a utilizzare __cpuid(). È possibile utilizzare OpenMPs omp_get_num_procs() che dovrebbe restituire la quantità di thread che la CPU può eseguire contemporaneamente. Non ho idea di quanto siano affidabili queste informazioni. Non ho mai avuto problemi in questo modo. – Compuholic
CPUID è generalmente abbastanza affidabile, ma a volte può essere fuorviante o errato. La tua CPU potrebbe supportare molto bene una funzione, ma la tua scheda madre non lo ha (o non ha disabilitato), quindi verrà segnalato come presente, ma non funzionerà. Ci sono librerie là fuori che prendono CPUID e cercano di renderlo un po 'più affidabile, con un database di correzioni e così via. – Kitsune
Ma se la CPU non supporta Hyperthreading e CPUID che ti dà l'informazione che è presente è davvero un problema con la scheda madre, potrei vedere che è l'altra strada, dove la CPU supporta HTT ma non la scheda madre e quindi ottieni un falso quando controlli HTT. – Alex