Як написати правильний мікро-орієнтир на Java?

Як написати (і запустити) правильний мікро-орієнтир на Java?

Я шукаю кілька зразків коду та коментарів, що ілюструють різні речі, про які варто задуматися.

Приклад: Чи повинен показник вимірювати час / ітерацію чи ітерацію / час, і чому?

Пов'язане: Чи прийнятний показник секундоміра?

Поради щодо написання мікро-тестів від творців Java HotSpot :

Правило 0: Прочитайте авторитетний документ про JVM та мікро-бенчмаркінг. Хороший - Брайан Гец, 2005 рік . Не чекайте занадто багато від мікро-показників; вони вимірюють лише обмежений діапазон експлуатаційних характеристик JVM.

Правило 1: Завжди включайте фазу розминки, яка запускає тестове ядро ​​до кінця, достатньо, щоб запустити всі ініціалізації та компіляції перед тимчасовими фазами. (На етапі розминки все менше в порядку. Правилом є кілька десятків тисяч ітерацій внутрішньої петлі.)

Правило 2: Завжди виконуйте з -XX:+PrintCompilation, -verbose:gcі т. Д., Щоб ви могли переконатися, що компілятор та інші частини JVM не виконують несподівану роботу під час фази хронометражу.

Правило 2.1: Роздрукувати повідомлення на початку та в кінці фаз синхронізації та розминки, щоб ви могли перевірити, чи немає результату з правила 2 під час фази хронометражу.

Правило 3: Будьте в курсі різниці між -clientі -serverта OSR та регулярними компіляціями. -XX:+PrintCompilationПрапор повідомляє ЛРН компіляцій з при-знаком для позначення без початкової точки входу, наприклад: Trouble$1::run @ 2 (41 bytes). Віддайте перевагу серверу клієнту і регулярному для OSR, якщо ви досягли найкращого результату.

Правило 4: Будьте в курсі ефектів ініціалізації. Не друкуйте вперше під час фази синхронізації, оскільки друк завантажує та ініціалізує класи. Не завантажуйте нові класи поза фазою розминки (або підсумкової фази звітування), якщо ви не тестуєте завантаження класів конкретно (і в цьому випадку завантажуйте лише тестові класи). Правило 2 - це ваша перша лінія захисту від таких наслідків.

Правило 5: Будьте в курсі ефектів деоптимізації та рекомпіляції. Не приймайте будь-який шлях коду вперше на етапі синхронізації, тому що компілятор може небажано перекомпілювати код, виходячи з попереднього оптимістичного припущення, що шлях зовсім не збирався використовувати. Правило 2 - це ваша перша лінія захисту від таких наслідків.

Правило 6: Використовуйте відповідні інструменти, щоб прочитати думку компілятора і очікуйте, що вас здивує код, який він створює. Перевірте код самостійно, перш ніж формувати теорії про те, що робить щось швидше чи повільніше.

Правило 7: Зменшіть рівень шуму в вимірах. Запустіть свій орієнтир на спокійній машині та запустіть його кілька разів, відкидаючи інші люди. Використовуйте -Xbatchдля серіалізації компілятора з програмою та розглянути можливість встановлення, -XX:CICompilerCount=1щоб запобігти роботі компілятора паралельно з самим собою. Спробуйте зробити все можливе, щоб зменшити накладні витрати GC, встановити Xmx(достатньо великі) рівні Xmsі використовувати, UseEpsilonGCякщо він є.

Правило 8: Використовуйте бібліотеку для орієнтиру, оскільки вона, ймовірно, є більш ефективною і вже була налагоджена для цієї єдиної мети. Такий , як JMH , супорт або Білл і Павла Відмінно UCSD орієнтири для Java .

Я знаю, що це питання було позначене як відповідь, але я хотів би згадати дві бібліотеки, які допомагають нам написати мікро-орієнтири

Суппорт від Google

Початок роботи з навчальними посібниками

1. http://codingjunkie.net/micro-benchmarking-with-caliper/
2. http://vertexlabs.co.uk/blog/caliper

JMH від OpenJDK

Початок роботи з навчальними посібниками

1. Уникнення контрольних підводних каменів у спільному проекті
2. http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking
3. http://java-performance.info/jmh/

Важливі речі для тестів Java:

• Спершу розминіть JIT, запустивши код кілька разів перед тим, як встановити його
• Переконайтеся, що ви запускаєте його досить довго, щоб можна було виміряти результати за секунди або (краще) десятки секунд
• Хоча ви не можете зателефонувати System.gc()між ітераціями, добре запустити їх між тестами, щоб кожен тест, сподіваємось, отримав «чистий» простір пам’яті для роботи. (Так, gc()це скоріше натяк, ніж гарантія, але дуже ймовірно, що він справді збиратиме сміття за моїм досвідом.)
• Мені подобається показувати ітерації та час, а кількість часу / ітерацію, яку можна масштабувати таким чином, що алгоритм "найкращого" отримує оцінку 1,0, а інші оцінюються відносно. Це означає, що ви можете довго запускати всі алгоритми, змінюючи і кількість ітерацій, і час, але все ж отримуючи порівнянні результати.

Я щойно веду обмін інформацією про дизайн структури бенчмаркінгу в .NET. У мене є кілька з попередніх постів , які можуть бути в змозі дати вам деякі ідеї - не все буде доречно, звичайно, але деякі з них можуть бути.

jmh - це недавнє доповнення до OpenJDK, його написали деякі інженери з продуктивності Oracle. Безумовно, варто подивитися.

Jmh - це джгут Java для побудови, запуску та аналізу нано / мікро / макро-тестів, написаних на Java та інших мовах, орієнтованих на JVM.

Дуже цікаві відомості, поховані в коментарях зразків тестів .

Дивись також:

• Уникнення контрольних підводних каменів у спільному проекті
• Обговорення основних сильних сторін jmh .

Чи повинен показник вимірювати час / ітерацію або ітерації / час, і чому?

Це залежить від того, що ви намагаєтеся протестувати.

Якщо вас цікавить затримка , використовуйте час / ітерацію, а якщо вас цікавить пропускна здатність , використовуйте ітерації / час.

Якщо ви намагаєтеся порівняти два алгоритми, зробіть принаймні два орієнтири для кожного, чергуючи порядок. тобто:

for(i=1..n)
  alg1();
for(i=1..n)
  alg2();
for(i=1..n)
  alg2();
for(i=1..n)
  alg1();

Я виявив деякі помітні відмінності (іноді 5-10%) під час виконання одного і того ж алгоритму в різні проходи.

Також переконайтеся, що n дуже великий, щоб час кожного циклу тривало не менше 10 секунд. Чим більше ітерацій, тим більш значущі цифри у вашому еталоні часу і тим надійніші дані.

Переконайтеся, що ви якось використовуєте результати, які обчислюються в орієнтованому коді. В іншому випадку ваш код може бути оптимізований далеко.

Існує багато можливих підводних каменів для написання мікро-орієнтирів на Java.

По-перше: вам доведеться обчислювати всілякі події, які займають час більш-менш випадкові: збір сміття, кешування ефектів (ОС для файлів і процесора для пам'яті), IO і т.д.

По-друге: Ви не можете довіряти точності вимірюваних разів протягом дуже коротких інтервалів.

По-третє: JVM оптимізує ваш код під час виконання. Так різні запуски в одному і тому ж JVM-екземплярі ставатимуть все швидше і швидше.

Мої рекомендації. Зробіть орієнтир запустити кілька секунд, це надійніше, ніж час виконання протягом мілісекунд. Прогрійте JVM (означає запустити показник хоча б один раз без вимірювання, щоб JVM міг запускати оптимізації). І запустіть свій орієнтир кілька разів (можливо, 5 разів) і візьміть середнє значення. Запустіть кожен мікро-орієнтир у новому екземплярі JVM (виклик для кожного базового тесту нового Java), інакше ефекти оптимізації JVM можуть вплинути на більш пізні запущені тести. Не виконуйте речі, які не виконуються у фазі розминки (оскільки це може викликати завантаження класів та перекомпіляцію).

Слід також зазначити, що може бути важливим також аналіз результатів мікро-орієнтиру при порівнянні різних реалізацій. Тому тест на значимість .

Це тому, що впровадження Aможе бути швидшим під час більшості етапів еталону, ніж впровадження B. Але Aтакож може бути більший розкид, тому вимірювана користь від продуктивності Aне матиме жодного значення в порівнянні з B.

Тому важливо також правильно написати та запустити мікро-орієнтир, а також правильно його проаналізувати.

Щоб додати до інших чудових порад, я також пам’ятаю про наступне:

Для деяких процесорів (наприклад, діапазон Intel Core i5 з TurboBoost) температура (і кількість ядер, що використовуються, а також їх відсоток використання) впливає на тактову частоту. Оскільки процесори динамічно синхронізовані, це може вплинути на ваші результати. Наприклад, якщо у вас є однопоточна програма, максимальна тактова частота (з TurboBoost) вище, ніж для програми, що використовує всі ядра. Тому це може заважати порівнянню одно- та багатопотокової продуктивності в деяких системах. Майте на увазі, що температура і волатації також впливають на те, як довго підтримується частота Turbo.

Можливо, більш принципово важливий аспект, над яким ви маєте безпосередній контроль: переконайтеся, що ви вимірюєте правильну річ! Наприклад, якщо ви використовуєте System.nanoTime()для орієнтування певного біта коду, розміщуйте дзвінки до призначення в місцях, які мають сенс уникати вимірювання речей, які вас не цікавлять. Наприклад, не робіть:

long startTime = System.nanoTime();
//code here...
System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");

Проблема полягає в тому, що ви не одразу отримуєте час завершення, коли закінчився код. Замість цього спробуйте наступне:

final long endTime, startTime = System.nanoTime();
//code here...
endTime = System.nanoTime();
System.out.println("Code took "+(endTime-startTime)+"nano seconds");

http://opt.sourceforge.net/ Java Micro Benchmark - завдання управління, необхідні для визначення порівняльних характеристик продуктивності комп'ютерної системи на різних платформах. Може використовуватися для керування рішеннями щодо оптимізації та порівняння різних реалізацій Java.