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

cppasm
T7500 2.2ГГц 2 ядра
Цифры пляшут. Причем были отрицательные.
Видать потому что sleep не делаешь.
В среднем 15-25% на обоих файлах на ST встречается серии 35-40% . На MT тоже встечается 35-40% но реже и по одиночке.

P4 2.4 одноядерный 35% ровно.

В том смысле что у разных процов по разному. Бывает и общий.

 

cppasm

P4 D925

 

AMD Turion(tm) 64 X2 Mobile Technology TL-58

speedcmp_mt
===============================
Performing ALGO speed test...
===============================
Execution time (fix) -> 71092569 clocks
Execution time (mmx) -> 64640253 clocks
9% speedup.

speedcmp_st
===============================
Performing ALGO speed test...
===============================
Execution time (fix) -> 71568571 clocks
Execution time (mmx) -> 64669347 clocks
9% speedup.

 

Мда, как я вижу у Р4 действительно с MMX не сложилось, скорее всего с умножением.

А зачем Sleep(0) делать?

MSDN:

 

на двух C2D (мобильном и десктопе) те же ~20% в обоих случаях.

 

перепланирование произойдет не сразу, а по истечении кванта времени.

 

А где про это написано?
Я так понял из написанного на MSDN что поток после изменения affinity mask отдаётся планировщику на перепланирование.
Ну ради интереса выкладываю ещё вариант с Sleep(0).
У меня разницы нет практически никакой (что не удивительно - процессор одноядерный ).

Немного изменён формат вывода.

Код (Text):

1. ===============================
2. Performing ALGO speed test...
3. ===============================
4. Execution time (mmx)  ->   66220968 clocks (+38%)
5. Execution time (fix)  ->  105935319 clocks ( +0%)

В скобках процент прироста относительно максимального значения.
Интересно будут ли прыгать цифры как прыгали (у тех у кого это наблюдалось, например у Pavia).
Оставил только многопоточную версию в связи с тем что на процессорах без HyperThreading разницы нет, а с HyperThreading многопоточная лучше.
Видимо потоки выполняющиеся во втором виртуальном ядре на кэш негативно влияют.
Кэш то один для обоих виртуальных ядер.

 

cppasm
C2D У меня всеравно скачит 20-30% в среднем 25% итого +5% нежели чем прошлая рализация.
Скачит именно цифра с fix. А MMX реализация постоянна.

Код (Text):

1. C:\Downloads\speedcmp_mt>speedcmp_mt.exe
2. ===============================
3. Performing ALGO speed test...
4. ===============================
5. Execution time (mmx)  ->   46304071 clocks (+25%)
6. Execution time (fix)  ->   61430930 clocks ( +0%)
7.  
8. C:\Downloads\speedcmp_mt>speedcmp_mt.exe
9. ===============================
10. Performing ALGO speed test...
11. ===============================
12. Execution time (mmx)  ->   46596803 clocks (+27%)
13. Execution time (fix)  ->   63467844 clocks ( +0%)
14.  
15. C:\Downloads\speedcmp_mt>speedcmp_mt.exe
16. ===============================
17. Performing ALGO speed test...
18. ===============================
19. Execution time (mmx)  ->   46509177 clocks (+30%)
20. Execution time (fix)  ->   65822328 clocks ( +0%)

Я вот что, думаю. Тут в теме разные архитектуры. Сразу видно какая архитектура насколько превосходит и в чем.

 

Если кому интересно, добавление Sleep(0) после смены Affinity Mask во всех создаваемыех потоках решило проблему.
Т.е. и на Р4 с HyperThreading я получил по замерам ~25%.
Но почему-то это увеличило разгул значений на 1-2%...
Думаю ещё попробовать с одним потоком и Sleep(0) после смены Affinity Mask.
Похоже SetThreadAffinityMask() действительно поток сразу на перепланирование не отправляет, поток квант отрабатывает на том же процессоре/ядре на котором был.

 

на P4D разброс значений 3-4% (причём в разные стороны)).

 

А можно так:

Код (Text):

1. .yield:
2.         call    [NtYieldExecution]
3.         test    al,al
4.         jnz     .yield

 

ты же писал что делал его? :\

так и есть.

 

Делал. Тут в теме даже выложенный бинарь ведь есть.
Я тогда его просто на P4 с HT не проверил - не было возможности.
А на одноядерном без разницы - что со Sleep(0), что без.