|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
14.01.2012, 18:28 | #11 | |
Старожил
Регистрация: 28.01.2009
Сообщений: 21,000
|
Цитата:
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел. Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите. |
|
14.01.2012, 18:28 | #12 |
Старожил
Регистрация: 16.12.2011
Сообщений: 2,329
|
Не помню, где, но читал, что якобы 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 |