Порівняння методів ітерації: кількість ітерацій проти процесора

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

performance benchmarking

— srijan
джерело

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

— Годрік Провид

@GodricSeer Ваша редакція покращила моє запитання. Спасибі

— srijan

Відповіді:

Загалом обидва методи порівняння результатів мають своє місце.

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

Отже, так, має сенс наводити обидва числа [1], і я часто бачив це в публікаціях. Існує також третій варіант:

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

[1] Однозначно представлена статистика за декілька прогонів; якщо ви показуєте засоби, не забудьте також включити стандартні відхилення.

— Крістіан Класон
джерело

Не просто приймати засоби! Якщо у вас достатньо тестових балів зі випадковими введеннями, побудуйте розподіл.

— Білл Барт

@BillBarth - хороший момент, хоча це може бути не завжди можливим; але надання стандартних відхилень разом із середнім значенням має бути завжди можливим. Насправді, яка статистика для подання звітів про ефективність звучить як чудове подальше запитання.

— Крістіан Класон

@BillBarth Ви зробили хороший результат. Але я використовую кілька тестових матриць у порядку збільшення. У таких випадках неможливо побудувати розподіл, тому я повинен будувати розподіли для всіх інших тестових матриць. Ось чому я хотіла їх скласти таблицю. Дякуємо за ваші коментарі.

— srijan

@srijan: У вас будуть дані, ви повинні побудувати для себе гістограми, де тільки зможете. Вам не доведеться публікувати їх усіх, але я обіцяю вам, що графік розповсюдження розповість вам більше, ніж море чисел або просто середні показники.

— Білл Барт

Я включав би час виконання за ітерацію. Оскільки кожна матриця різна, ви можете мати різну кількість ітерацій з різним часом виконання. Разом з тим, що сказав @Cristian, час виконання за ітерацію було б корисним.

— jbcolmenares

Я вважаю, що кількість ітерацій є оманливою метрикою, оскільки вона пропонує "швидкість", коли її немає. Простий приклад порівняння кількох різних попередніх кондиціонерів, що показує цю різницю, дивіться тут: http://www.dealii.org/developer/doxygen/deal.II/step_6.html#Possibilityforextensions

— Вольфганг Бангерт
джерело

Дякую за відповідь. Я не в змозі зрозуміти цей рядок: «кількість повторень є помилковим показником, оскільки він пропонує« швидкість », коли її немає». Приклад, який ви запропонували, мені дещо важкий для розуміння.

— srijan

Що я кажу, що ми часто представляємо, що "кількість повторень" еквівалентно "використаному процесорному часу", маючи на увазі, що метод, який вимагає меншої кількості ітерацій, також швидший. Але це неправда, як показують цифри, до яких я посилався.

— Вольфганг Бангерт

Тепер я повністю зрозумів вашу думку. Те саме я спостерігав із методом Ньютона для наближення оберненої квадратної матриці. З часом порядок методу збільшується, спочатку час процесора, а також кількість ітерацій зменшуються, але, як порядок збільшується, початок запуску процесора збільшується, хоча кількість ітерацій зменшується. Дуже дякую за вашу відповідь.

— srijan

Якщо в інших відповідях незрозуміло, яка кількість повторень хороша для аргументів big-O.

Це не добре для абсолютної швидкості, тому що це залежить від середнього часу за ітерацію, яка може відрізнятися між методами великим фактором.

Наприклад, існує тенденція ігнорувати витрати на обчислення індексів масиву, і це, можливо, може становити значну частину часу процесора.

ДОБАВЛЕНО: Крім того, як я вже вказував в іншому місці, для кожного виклику методу зазвичай існує вартість налаштування. Тоді, якщо матриці, як правило, не дуже великі, ціна установки може сама по собі складати велику частку часу процесора (така, що для його видалення буде велика різниця у швидкості).

— Майк Данлаве
джерело