Необходимо определить число физических и логических процессоров, т.е. отличать HT процессор от нормального, чтобы можно было устанавливать affinitymask по этой инфе. Для этого использую GetLogicalProcessorInformation. Все вроде работает кроме Win2003 SP2 (на XP SP3 все работает). Почитав более внимательно нашел вот это:

Windows Server 2003 and Windows XP Professional x64 Edition: This member is also 1 for cores that share a physical package. Therefore, to determine whether the processor supports multiple cores or hyperthreading on systems prior to Windows Vista, use the CPUID instruction

Попытался использовать __cpuid и тут-то меня ждала неожиданность. Оказывается мой проц типа поддерживает Hyper-Threading 8-() хотя все определиловки говорят что его нету. Проц у меня i5 2500K (не разогнан). Может я не правильно определяю HT? Сейчас проверяю 28 бит EDX (это 3-й элемент/последний элемент возвращаемый __cpuid функцией).
Почитал интелловскую доку по поводу 28-ого бита:

Max APIC IDs reserved field is Valid. A value of 0 for HTT indicates there is only a single logical processor in
the package and software should assume only a single APIC ID is reserved. A value of 1 for HTT indicates the
value in CPUID.1.EBX[23:16] (the Maximum number of addressable IDs for logical processors in this package) is
valid for the package

и совсем запутался. В CPUID.1.EBX[23:16] лежит число 0x10.

Подскажите что делаю неправильно?

Здравствуйте, gwg-605.

Поддержка Hyper-Threading действительно определяется с помощью cpuid, но по-другому.
Способ в общих чертах такой — инструкция cpuid вызывается на каждом логическом процессоре и
для каждого определяется PACKAGE_ID, CORE_ID и SMT_ID (ID процессора, ID ядра, ID потока).
Если два логических процессора имеют одинаковые PACKAGE_ID и CORE_ID, а SMT_ID у них,
соответственно, разные, то это значит что они — потоки внутри одного ядра, то есть,
Hyper-Threading включен.

Более подробно можно узнать в документе "Intel® 64 Architecture Processor Topology Enumeration":
http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration

Здравствуйте, gwg-605, Вы писали:

G6>отличать HT процессор от нормального, чтобы можно было устанавливать affinitymask по этой инфе.

Если Вы это делаете в целях оптимизации использования ядер, прикрепляя вычислительные потоки к физическим ядрам, имейте в виду, что это имеет смысл только для ранних процессоров с HT. Уже в Core2 это довольно неплохо оптимизировано, не говоря об i7. Большинство вычислительных задач, в которых не вылизаны до такта все возможные виды спаривания, работает быстрее, будучи свободно (без affinity masks) раскидано по всем логическим процессорам.

а так не пойдет?

bool GetCPUInfo( size_t& nCores, size_t& nLogicCores )
{
    unsigned __int32 regs[4] ={0x00};

      // Get vendor
    char vendor[12] ={0x00};
    cpuID(0, regs);
      ((unsigned *)vendor)[0] = regs[1]; // EBX
      ((unsigned *)vendor)[1] = regs[3]; // EDX
      ((unsigned *)vendor)[2] = regs[2]; // ECX

    std::string cpuVendor = std::string(vendor, 12);

      // Get CPU features
    cpuID(1, regs);
    unsigned __int32 cpuFeatures = regs[3]; // EDX

      // Logical core count per CPU
    cpuID(1, regs);
    unsigned __int32 logical = (regs[1] >> 16) & 0xff; // EBX[23:16]
    nLogicCores = static_cast<size_t>( logical );
    unsigned __int32 cores = logical;

    if( cpuVendor == "GenuineIntel" ) 
    {
        // Get DCP cache info
        cpuID(4, regs);
        cores = ((regs[0] >> 26) & 0x3f) + 1; // EAX[31:26] + 1

    }
    else 
        if (cpuVendor == "AuthenticAMD") 
    {
        // Get NC: Number of CPU cores - 1
        cpuID(0x80000008, regs);
        cores = ((unsigned __int32)(regs[2] & 0xff)) + 1; // ECX[7:0] + 1
    }
    nCores = static_cast<size_t>( cores );
      // Detect hyper-threads  
    return ( cpuFeatures & (1 << 28) && cores < logical );
}

inline void cpuID( unsigned __int32 i, unsigned __int32 regs[4] ) 
{
#ifdef _WIN32
  __cpuid((int *)regs, (int)i);

#else
  asm volatile
    ("cpuid" : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3])
     : "a" (i), "c" (0));
  // ECX is set to zero for CPUID function 4
#endif
}

Здравствуйте, Lepsik, Вы писали:

L>а так не пойдет?

L>[code]
L>...
L>[/ccode]

Core i5 2500 (4 ядра), показывает nCores = 8, nLogicCores = 16.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если Вы это делаете в целях оптимизации использования ядер, прикрепляя вычислительные потоки к физическим ядрам, имейте в виду, что это имеет смысл только для ранних процессоров с HT. Уже в Core2 это довольно неплохо оптимизировано, не говоря об i7. Большинство вычислительных задач, в которых не вылизаны до такта все возможные виды спаривания, работает быстрее, будучи свободно (без affinity masks) раскидано по всем логическим процессорам.

В общем есть у нас проблема с HT. Пишется кодек. Очень сильно используется оптимизация на симдах. При обычных ядрах все полученные результаты по производительности ожидаемы и стабильны. Но при включении HT, получаем очень нестабильную работу. т.е. производительность может прыгать в пару раз.

Тесты показали:
на одном коре — производительность Х
на двух независиых корах — 1.9*Х
на одном коре с HT — 1.1*Х, т.е. всего 10% прироста, дальше 5%, 2%, 0%, а потом начинает тормозить. Это среднее за весь тест.

Если брать среднее за секунду то произодительность прыгает +25%...-60%.

С одной стороны 10% HT не так уже и много, но очень хочется их заюзать. и не получается.

Понимание работы HT дает объяснение данных результатов, но пока не дает идеи как заюзать HT. Может есть какие-то опробированные решения?

Здравствуйте, gwg-605, Вы писали:

G6>При обычных ядрах все полученные результаты по производительности ожидаемы и стабильны. Но при включении HT, получаем очень нестабильную работу. т.е. производительность может прыгать в пару раз.

Тесты гоняли на Realtime Priority, чтобы максимально исключить вытеснение? Каждый поток за время тестирования отрабатывает примерно одинаковое количество времени, или наблюдается заметный разбаланс? Конфликты по кэшам/памяти вроде нет оснований смотреть, если с привязкой к ядрам все работает нормально.