Время вычисления функции. - Общие вопросы C/C++ - Страница 2

Пепел Феникса · 14.01.2012, 18:28

Цитата:

Правда можно вставить асмовские вставки и на время замера времени работы функции отключит прерывания.

нельзя.(только с ядра если уж)

_Bers · 14.01.2012, 18:28

Не помню, где, но читал, что якобы QueryPerformanceCounter работает через ассемблеровскую инструкцию rdtsc, которая, в числе прочих недостатков, тупит на много-ядерных процессорах.

"псевдо всплески в системах с многопоточным ядром(ах), HyperThreading: для случаев очень точных замеров блока команд, за счёт неучёта загруженности общих процессорных блоков. Также кэша и памяти, что верно и для просто MP систем. Простейшее и правильнейшее решение - отключить на время тестов HyperThreading в БИОС, при наличии более одного ядра - в БИОС или программно в ОС ограничив число ядер до одного[12]."

Поэтому, вопрос не только в том, чем замерять, но и в том, как замерять.

Допустим серия замеров показывает результаты: 445, 467, 533, 480, 112345, 433
Предпоследний результат - явно косяк "мульти-задачности" ОС, ну или, косяк rdtsc, либо ещё какой то косячок.

Вопрос: для установления среднестатистического времени работы функции, нужно ли учитывать те результаты замеров, которые явно и резко выделяются из общей серии результатов?

Ведь один такой всплеск уже весь среднестатистический результат попортит.

Или может быть их нужно проигнорировать?

Но если нужно часть результатов браковать, как "косяки измерения", возникает вопрос, а как узнать какой из результатов слишком выделяется?

Например, серия:

10000, 400, 420, 425, 433.

Самый первый замер - уже отпадает. Как его вычислить?

Первое, что в голову приходит - по ходу пьессы подсчитывать среднестатистический результат не получится. Нужно сначала записать все результаты (получится большой массив с результатами замеров).
А потом, анализировать его на предмет выявления средней нормы, и крайних точек.

Но эт только одна серия.

А запустить нужно несколько серий, и аналогичным образом отфильтровать все серии, которые отклоняются от нормы.

Потом запустить несколько серий серий, и аналогично...

и так до тех пор, пока не будет зафиксированно ни одного отклонения превышающего неккий коэффициэнт.

Получается жутко тормозной топорный алгоритм. Который в много-задачной системе будет возвращать каждый раз одно и тоже значение.

Но правда в том, что эта же самая функция в боевом коде может начать работать совсем с другой скоростью только потому, что в боевом коде кэш уже непойми чем засрали, или потому, что в боевом коде в релиз версии её код был оптимизирован, или...

По-моему, засекать время выполнения функции в таких системах, как Windows - затея фейловая изначально.

Похожие темы
Тема	Автор	Раздел	Ответов	Последнее сообщение
программа вычисления функции	arshavin	Паскаль, Turbo Pascal, PascalABC.NET	2	16.04.2011 18:47
Вычисления в функции	Ислам	Помощь студентам	2	28.02.2011 02:43
Составить прогу вычисления функции	Lion8990	Помощь студентам	6	17.12.2010 00:18
Алгоритм вычисления значения функции	vzr	Свободное общение	9	30.03.2010 20:14

14.01.2012, 18:28	#12
_Bers Старожил Регистрация: 16.12.2011 Сообщений: 2,329	Не помню, где, но читал, что якобы QueryPerformanceCounter работает через ассемблеровскую инструкцию rdtsc, которая, в числе прочих недостатков, тупит на много-ядерных процессорах. "псевдо всплески в системах с многопоточным ядром(ах), HyperThreading: для случаев очень точных замеров блока команд, за счёт неучёта загруженности общих процессорных блоков. Также кэша и памяти, что верно и для просто MP систем. Простейшее и правильнейшее решение - отключить на время тестов HyperThreading в БИОС, при наличии более одного ядра - в БИОС или программно в ОС ограничив число ядер до одного[12]." Поэтому, вопрос не только в том, чем замерять, но и в том, как замерять. Допустим серия замеров показывает результаты: 445, 467, 533, 480, 112345, 433 Предпоследний результат - явно косяк "мульти-задачности" ОС, ну или, косяк rdtsc, либо ещё какой то косячок. Вопрос: для установления среднестатистического времени работы функции, нужно ли учитывать те результаты замеров, которые явно и резко выделяются из общей серии результатов? Ведь один такой всплеск уже весь среднестатистический результат попортит. Или может быть их нужно проигнорировать? Но если нужно часть результатов браковать, как "косяки измерения", возникает вопрос, а как узнать какой из результатов слишком выделяется? Например, серия: 10000, 400, 420, 425, 433. Самый первый замер - уже отпадает. Как его вычислить? Первое, что в голову приходит - по ходу пьессы подсчитывать среднестатистический результат не получится. Нужно сначала записать все результаты (получится большой массив с результатами замеров). А потом, анализировать его на предмет выявления средней нормы, и крайних точек. Но эт только одна серия. А запустить нужно несколько серий, и аналогичным образом отфильтровать все серии, которые отклоняются от нормы. Потом запустить несколько серий серий, и аналогично... и так до тех пор, пока не будет зафиксированно ни одного отклонения превышающего неккий коэффициэнт. Получается жутко тормозной топорный алгоритм. Который в много-задачной системе будет возвращать каждый раз одно и тоже значение. Но правда в том, что эта же самая функция в боевом коде может начать работать совсем с другой скоростью только потому, что в боевом коде кэш уже непойми чем засрали, или потому, что в боевом коде в релиз версии её код был оптимизирован, или... По-моему, засекать время выполнения функции в таких системах, как Windows - затея фейловая изначально.