Навіщо використовувати порівняння замість часу виконання для порівняння двох алгоритмів?

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

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

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

1. Загальна
   тривалість виконання, виміряна за допомогою однієї мови та одного компілятора на одній машині, мало значення, якщо ви змінюєте будь-який компонент. Навіть трохи різні реалізації одного і того ж алгоритму можуть працювати по-різному, оскільки ви запускаєте певну оптимізацію компілятора у випадку, а не в іншому.
2. Прогнозування
   Отже, у вас є декілька режимів виконання для деяких входів. Що це говорить про час виконання деякого іншого входу? Взагалі нічого.
3. Важливість
   Як правило, ви не будете орієнтувати всі входи (певного розміру), щоб це негайно обмежувало вашу здатність порівнювати алгоритми: можливо, ваш тестовий набір викликав найгірший випадок в одному і найкращий випадок в іншому алгоритмі? Або, можливо, ваші вклади були занадто малі, щоб проявити поведінку під час виконання .
4. Замір
   Вимірювальні автономної роботи також не є тривіальним. Чи є СІТ? Чи були суперечки, тобто ви рахуєте час, коли алгоритм навіть не запускався? Чи можете ви відтворити точно такий же стан машини для іншого запуску (іншого алгоритму), зокрема одночасних процесів і кешів? Як вирішується затримка пам’яті?

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

Про другу частину питання. Чому ми використовуємо порівняння або подібні елементарні операції?

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

2. Домінування
   Вибрана операція домінує під час виконання. Це не означає, що це сприяє найбільшому виконанню - порівнянь, очевидно, не відбувається, наприклад, у Quicksort при сортуванні цілих чисел у розмірі слова. Але вони виконуються найчастіше , тому, підраховуючи їх, ви підраховуєте, як часто виконуються найбільш виконані частини алгоритму. Отже, ваш асимптотичний час виконання пропорційний кількості домінуючих елементарних операцій. Ось чому нам зручно використовувати позначення Ландау і слово "час виконання", навіть якщо ми підраховуємо лише порівняння.

Зауважте, що може бути корисно порахувати більше однієї операції. Наприклад, деякі варіанти Quicksort проводять більше порівнянь, але менше замінів, ніж інші (в середньому).

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

Це пояснюється тим, що загальний час для виконання алгоритмів залежить від обладнання, на якому він працює, а також інших факторів. Не можна достовірно порівнювати два алгоритми, якщо один працює на Pentium 4, а другий працює на, скажімо, Core i7. Не тільки це, але скажімо, що ви обидва працювали на одному комп’ютері. Що говорити про те, що в обох процесор однаковий час? Що станеться, якщо якийсь інший процес має більш високий пріоритет, ніж процес одного з алгоритмів?

Щоб подолати це, ми відриваємося від цього загального часу для завершення, а замість цього порівнюючи на основі того, наскільки добре алгоритм масштабується. Можливо, ви помітили такі позначення, як O (1) або O (n ^ 2) у наукових роботах. Для цього може знадобитися трохи більше читати, якщо ви зацікавлені подивитися Big O нотації .

Оскільки інші відповіді пояснюють, чому ми аналізуємо час виконання за кількістю елементарних операцій, дозвольте запропонувати пару причин, чому порівняння є правильною метрикою багатьох (не всіх) алгоритмів сортування:

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