Средства и методы разработки

От большего числа повторений время, конечно, усредняется, но меньше от этого не станет. И если операционка отгрызает какой-то процент времени у потока, то этот процент может зависеть от типа операционной системы. По крайней мере, мои наблюдения таковы, что чем новее операционная система, тем больше времени она у моего потока отгрызает, что и выражается в том, что скорость выполнения расчетов снижается. Причем, показатели скорости на 64-разрядной Windows чуть меньше, чем на 32-разрядной, хотя и несущественно. Подчеркиваю, что речь сейчас идет только о тестах, основная нагрузка в которых ложится на float-операции! Причем, я сильно подозреваю, что причиной этого являются именно прерывания во время исполнения кода, т.к. более ни на что другое попенять не могу. В статьях, которые вы читали, речь шла о производительности компьютера на смешанных задачах, где удлинение регистров общего назначения до 64-х бит способно ускорять какие-то операции. Скажем, копирование из одного блока памяти в другой или обнуление массивов (последняя операция часто востребована при аллокации памяти). Однако в моем случае ситуация выглядит в корне иначе. Дело в том, что набор инструкций AVX/AVX2 имеет свои собственные команды загрузки и выгрузки данных между арифметическими регистрами ymm0-ymm7 и памятью. Поэтому новая арифметическая подсистема по-прежнему стоит особняком, являясь по сути сопроцессором, т.к. практически никакой связи с основным АЛУ не имеет. Даже конвейер команд обслуживает их так, как будто бы это были два разных процессора - раздает команды, руководствуясь исключительно префиксом перед ними. Поэтому, как раньше для FPU87 не было разницы, в каком режиме работает основной процессор, так и нынешнему до этого тоже дела мало. Короче говоря, при переходе из 32-битного режима в 64-битный, на стороне FPU почти ничего не меняется - его арифметические регистры не становятся от этого ни длиннее, ни короче. Как было в них 256 бит, так и остается. Как и остались прежними тайминги по всем операциям. Есть лишь одна минорная особенность - в 64-битном режиме ymm-регистров становится вдвое больше - уже не 8, а 16. Но если старшие не использовать, то разницы в скорости никакой быть не должно. Другое дело, что при большем числе ymm-регистров операционке потребно больше времени, чтобы спасать/восстанавливать их содержимое при переходах от одного потока к другому, поскольку другой потоки могут хранить в этих регистрах разное содержимое. А когда регистры такие длинные, то все 16 потянут на пол килобайта. А вы говорите, приоритет не нужен. При нормальном приоритете расчет будет прерываться каждые 55 мсек (это максимальное время цикла аппаратного таймера), после чего исполнение будет передано следующему в очереди потоку. Ну, а по дороге придется сохранять не только рабочие регистры процессора, но и двух сопроцессоров (старый FPU87 тоже в зачет идет). Причем, в 64-битном режиме, больше тех и других. А в том, что рабочие регистры основного процессора стали длиннее, то на скорость float-операций никак позитивно не сказывается. Раньше я свои алгоритмы для FPU87 вообще в DOS'е измеряла. Не том DOS'е, что виртуален, а в самом натуральном, 16-битном реальном режиме. Там всех этих внешних тормозов нет, а прерывание таймера занимает очень малое время (его запретить тоже возможно, но тогда время не замеришь). Но, к сожалению, SSE/AVX инструкции в реальном режиме не работают, т.к. для их разрешения требуется изменить бит в регистре статуса, находящийся выше 16-го этажа. При сравнении скорости алгоритма в разных операционных системах уровень приоритета остается тем же самым, а потому такое сравнение вполне валидно. Ведь какой-то приоритет все равно у потока есть, поэтому чистым эксперимент в любом случае не будет. Тем более что установленный мной приоритет дает преимущество лишь перед другими приложениями (например, чтобы Skype не мигал в трее глазом :)), но для самой операционной системы он не помеха.