cppasm T7500 2.2ГГц 2 ядра Цифры пляшут. Причем были отрицательные. Видать потому что sleep не делаешь. В среднем 15-25% на обоих файлах на ST встречается серии 35-40% . На MT тоже встечается 35-40% но реже и по одиночке. P4 2.4 одноядерный 35% ровно. В том смысле что у разных процов по разному. Бывает и общий.
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:
А где про это написано? Я так понял из написанного на MSDN что поток после изменения affinity mask отдаётся планировщику на перепланирование. Ну ради интереса выкладываю ещё вариант с Sleep(0). У меня разницы нет практически никакой (что не удивительно - процессор одноядерный ). Немного изменён формат вывода. Code (Text): =============================== Performing ALGO speed test... =============================== Execution time (mmx) -> 66220968 clocks (+38%) Execution time (fix) -> 105935319 clocks ( +0%) В скобках процент прироста относительно максимального значения. Интересно будут ли прыгать цифры как прыгали (у тех у кого это наблюдалось, например у Pavia). Оставил только многопоточную версию в связи с тем что на процессорах без HyperThreading разницы нет, а с HyperThreading многопоточная лучше. Видимо потоки выполняющиеся во втором виртуальном ядре на кэш негативно влияют. Кэш то один для обоих виртуальных ядер.
cppasm C2D У меня всеравно скачит 20-30% в среднем 25% итого +5% нежели чем прошлая рализация. Скачит именно цифра с fix. А MMX реализация постоянна. Code (Text): C:\Downloads\speedcmp_mt>speedcmp_mt.exe =============================== Performing ALGO speed test... =============================== Execution time (mmx) -> 46304071 clocks (+25%) Execution time (fix) -> 61430930 clocks ( +0%) C:\Downloads\speedcmp_mt>speedcmp_mt.exe =============================== Performing ALGO speed test... =============================== Execution time (mmx) -> 46596803 clocks (+27%) Execution time (fix) -> 63467844 clocks ( +0%) C:\Downloads\speedcmp_mt>speedcmp_mt.exe =============================== Performing ALGO speed test... =============================== Execution time (mmx) -> 46509177 clocks (+30%) Execution time (fix) -> 65822328 clocks ( +0%) Я вот что, думаю. Тут в теме разные архитектуры. Сразу видно какая архитектура насколько превосходит и в чем.
Если кому интересно, добавление Sleep(0) после смены Affinity Mask во всех создаваемыех потоках решило проблему. Т.е. и на Р4 с HyperThreading я получил по замерам ~25%. Но почему-то это увеличило разгул значений на 1-2%... Думаю ещё попробовать с одним потоком и Sleep(0) после смены Affinity Mask. Похоже SetThreadAffinityMask() действительно поток сразу на перепланирование не отправляет, поток квант отрабатывает на том же процессоре/ядре на котором был.
Делал. Тут в теме даже выложенный бинарь ведь есть. Я тогда его просто на P4 с HT не проверил - не было возможности. А на одноядерном без разницы - что со Sleep(0), что без.