Я знаю, что должен использовать: rdtsc. Измеренная функция детерминирована, но результат далек от воспроизводимого (я получаю 5% колебаний от цикла к запуску). Возможные причины:
Вы знаете какие-нибудь другие причины? Как их устранить?
TSC (то, что использует rdtsc) часто не синхронизируются в многопроцессорных системах. Это может помочь установить сродство ЦП, чтобы привязать процесс к одному ЦП.
Вы также можете получить временные метки из таймеров HPET, если они доступны, которые не подвержены той же проблеме. .
Что касается повторяемости, эти различия верны. Вы можете отключить кеширование, дать процессу приоритет в реальном времени и / или (если в Linux или что-то подобное) перекомпилировать ядро с более низкой фиксированной частотой прерывания таймера (той, которая выполняет квантование времени). Вы не можете полностью устранить дисперсию, по крайней мере, нелегко и не в обычных комбинациях CPU + OS.
В общем, из соображений удобства программирования, надежности и переносимости я предлагаю вам использовать то, что предлагает ОС. Если он предлагает таймеры с высокой точностью, используйте соответствующий помощник ОС.
(На всякий случай, если вы пытаетесь провести атаку времени на криптосистему, что ж, вам придется жить с 1. этой случайностью и 2. общей защитой, которые делают систему непредсказуемой по уважительным причинам, поэтому функция может не работать. быть детерминированным по времени.)
РЕДАКТИРОВАТЬ: добавлен параграф о таймерах, которые может предложить ОС.
РЕДАКТИРОВАТЬ: это относится к Linux. Для привязки процесса к одному процессору (для точного чтения из RDTSC) вы можете использовать sched_setaffinity (2). И вот код одного из моих проектов, использующий его для других целей (отображение потоков на процессоры). Это должна быть ваша первая попытка. Что касается HPET, вы можете использовать обычные вызовы POSIX, например эти , если ядро и машина поддерживают эти таймеры.
Зачем их устранять? Похоже, вы создали реалистичный тест. Этот код будет иметь такую же изменчивость при использовании в дикой природе. Вероятно, хуже, так как вы, вероятно, устранили задержки диска и кеш-памяти ЦП. Использование подхода Джона Скита, создание условий, которые дадут вам наилучший результат, оставит вас только с результатом, который заставит вас чувствовать себя хорошо, но никогда не будет достижим.
Если важно абсолютное число, рассчитывайте медиану, а не среднее значение.
См. Вопрос Приемлем ли эталонный анализ секундомера?, чтобы узнать о вариативности микробенчмаркинга на современная многоядерная многопоточная многопроцессорная машина.
Хотя речь идет о Java, соображения применимы к тестированию производительности на любом языке.
См. Также: Как написать правильный микротест на Java?
Также см. Какой совет вы можете мне дать написать значимый тест?
На самом деле в новых ядрах Linux есть новая подсистема perf. Пример:
$ ./perf stat du -s /tmp
94796 /tmp
Performance counter stats for 'du -s /tmp':
2.546403 task-clock-msecs # 0.060 CPUs
3 context-switches # 0.001 M/sec
0 CPU-migrations # 0.000 M/sec
166 page-faults # 0.065 M/sec
2434963 cycles # 956.236 M/sec
1798092 instructions # 0.738 IPC
302969 branches # 118.979 M/sec
26197 branch-misses # 8.647 %
23217 cache-references # 9.118 M/sec
4621 cache-misses # 1.815 M/sec
0.042406580 seconds time elapsed
Добавление к списку причин: предсказание ветвления / неверное предсказание (это может быть выполнено переключением контекста со сложными кешами предсказания на некоторых микросхемах. Также на предсказание могут влиять разные входные данные в вашу программу и, таким образом, прямое сравнение времени для двух разных данных наборы могут быть немного перекошены.
В общем, все это практически невозможно смягчить, но есть несколько вещей, которые вы можете сделать, чтобы помочь каждому из них:
Но, конечно же, лучший метод определения времени, подобного этому, - это выполнять их очень много раз на очень больших фрагментах данных, чтобы свести к минимуму изменчивость, вносимую вещами, которые вы не можете контролировать. (На самом деле это невозможно стереть.)
Большинство современных процессоров поддерживают замечательный набор низкоуровневых аппаратных счетчиков производительности. Если вы действительно хотите знать ответы, включая реальные измерения промахов в кэше и накладных расходов на переключение контекста, возьмите PAPI (Performance API) toolkit, то в некоторых (хотя и не во всех) ОС установите один патч ядра, и, приложив некоторые дополнительные усилия, вы готовы к работе.
