RDTSC, замеры производительности.

Привет.
Предистория.
Есть один и тот же алгоритм написанный на MMX и на обычных командах.
Захотелось померять прирост производительности, воспользовался RDTSC.
Вроди всё как положено, поставил процессу REAL_TIME_PROIRITY_CLASS, потоку поставил THREAD_PROIRITY_TIME_CRITICAL, поставил AffinityMask для потока только на один процессор и вперёд.
Делаем 1000000 замеров в цикле и потом вычисляем прирост.
И вот тут начинаются чудеса.
Сразу скажу что результаты повторяемые, т.е. это не случайные косяки с RDTSC.
На однопроцессорной машине всё даёт ожидаемые результаты - ~38% прирост.
А на многопроцессорной (либо двуядерной, либо просто с HyperThreading) получается ерунда.
По замерам прироста нет совсем.
Но! Если нагрузить остальные ядра, то результат получается примерно как на однопроцессорной машине.
Т.е. если для каждого ядра создать поток в котором делать просто jmp $, результаты такие же как и на однопроцессорной машине.
И это при том, что поток в котором выполняется измеряемый код жёстко привязан к одному ядру, это к примеру в диспетчере задач видно.
Вопрос в том что это за приколы такие?
Как нагрузка на одно ядро может влиять на производительность другого?
Причём влиять по разному - производительность MMX падает незначительно, а производительность обычных команд типа add/sub/imul - значительно?
Кто что думает по этому поводу?

 

cppasm
Может на компьюторе стоит энерго сберегающий режим?

 

Ну много факторов влияния возможно. Много различных состояний производительности процессора. ОС может шалить (видел такие KB в которых фиксились другие KB в которых были ошибки с состояниями производительности)
http://support.microsoft.com/kb/896256
http://support.microsoft.com/kb/330512

 

Нет, не стоит...
Да и какая разница?
Если на ядре выполняется поток с приоритетом реального времени, то оно просто не может в энергосберегающем режиме находиться.
Что интересно - если запускать программу из-под VTune то и замеры программы, и результаты VTune получаются такими же как при загрузке всех ядер.

 

AFAIK HyperThreading не отдлельное ядро, а так, хитро-жёппый out of order execution... На реальном dual core что происходит с выставленой affinity и без?

 

Ну это не out of order execution...
Там просто нету полноценного ядра, но некоторые исполнительные блоки дублируются.
На серваке с двумя Intel Xeon Dual Core (т.е. 2 процессора по два ядра) то же самое.
При нагрузке на все ядра результаты одни, при нагрузке только на ядро на котором выполняется замеряемый код - другие (я склонен считать что неправильные, на одноядерной машине результаты получаются как на многоядерной с полностью загруженными ядрами)...

 

cppasm, ну а без affinity и без дополнительных потоков ты попробовал?

 

Без дополнительных потоков пробовал - результат написан выше.
А без установки affinity mask (без привязки к ядру) пробовать смысла нету.
ОС тогда гипотетически может мой поток перекидывать между ядрами, а у каждого из них RDTSC считает независимо, т.е. что я в итоге намеряю непонятно.

 

cppasm
Помойму вы противоречите сами себе.

Еще раз проверьте все и выложите результаты.

По моим мыслям HyperThreading - должен работать так.
Если на одном ядре работает твой код на другом jmp $ то тут должны наблюдаться такиеже результаты как и на одно ядерном.
Без использования второго ядра HyperThreading будет тормазить и система будет работать медленее.
Если загрузить оба ядра то прирост несколько процентов. Причем я считаю если на одно ядро поместить код с MMX а надругую обычные команды то прирост будет больше.

А вот на настоящем двух ядерном такого недолжно наблюдаться.

 

cppasm

Вот именно, что "гипотетически". Если алгоритм позволяет, то лучше не накручивать офигенные циклы, а ноборот стремиться уложиться в микросекунды, тогда и вероятность переключения потока будет достаточно мала. А для отбраковки случайных "сбоев" достаточно делать серию из 8-10 проходов и брать только повторяемые результаты

Pavia

В принципе тоже может, если код интенсивно работает с памятью (видимо так оно и есть, раз речь об MMX). В этом случае пустой цикл на втором ядре гарантированно не лезет в память, не засоряет общий кэш L2, и не требует доп.проверок когерентности L1

 

Ээ, у двух ядер в одной упаковке общий TSC.

 

Откуда дровишки ?
У AMD точно разные и работают на частоте своего ядра, и соотв-но могут разбегаться при изменении частоты. У Intel скорее всего тоже разные, но работают синхронно на фикс.частоте и поэтому не разбегаются (или скажем так - не должны

 

leo
Во время старта ядра запускаются с опазданием. Поэтому значения TSC отличаются.

 

Нет, не противоречу.

На одноядерной машине прирост 38%.
На двуядерной мой код запускается только на одном ядре.
Если остальные ядра не трогать - то прироста нет совсем, т.е. время выполнения с MMX и без примерно одинаково.
Если же пригрузить остальные ядра, то скорость MMX кода практически не падает, а скорость обычного кода падает сильно - и получаем те же 38% прироста у MMX.
Я думал может с кешем ерунда какая-то.
Но у двуядерных процессоров ведь у каждого ядра свой кеш?
Если кому интересно могу выложить две тестовые программки, погоняете у кого есть двуядерные процессоры.

 

cppasm

конечно выкладывайте.

 

Зависит от системы.

 

а для четырехядерных подойдут?

 

В смысле? От какой системы?

Да, для любых подойдут, даже для однопроцессорных.

В архиве два файла - speedcmp_st.exe и speedcmp_mt.exe, соответственно однопоточная и многопоточная версия.
У меня результаты такие.
Однопоточная:

Многопоточная:

Ещё раз подчеркну, что в многопоточной версии замеряемый код всё равно работает в одном потоке, в остальных потоках просто пустой цикл while(loop_thread);

И всё равно на P4 MMX как-то туго работает.
Проверял ещё на Celeron D и на AMD Duron - прирост намного выше.

 

в обоих ~20%. Тестил раз 10.
Q6600
Не пробовал после установки аффинита делать Sleep(0) ?

Код (Text):

1. ===============================
2. Performing ALGO speed test...
3. ===============================
4. Execution time (fix)  ->   57217941 clocks
5. Execution time (mmx)  ->   45160083 clocks
6.  
7. 21% speedup.
8.  
9. ===============================
10. Performing ALGO speed test...
11. ===============================
12. Execution time (fix)  ->   58734189 clocks
13. Execution time (mmx)  ->   45895005 clocks
14.  
15. 21% speedup.

 

Пробовал, не помогает.

Погонял тут ещё - похоже HyperThreading такие чудеса творит.
На AMD Opteron Dual-Core (2 CPU по два ядра) результаты в обоих вариантах идентичны.
На Intel Xeon (2 CPU одноядерных с HyperThreading) - эффект наблюдается, разброс есть ~15%