У звичайному курсі алгоритмів нас вчать, що в середньому швидкості є а в гіршому - . Одночасно вивчаються інші алгоритми сортування, які є у гіршому випадку (наприклад, злиття та велика частина ), і навіть лінійний час у кращому випадку (як бульбашка ), але з деякими додатковими потребами пам'яті.O ( n 2 ) O ( n журнал n $O(n \log n)$$O(n^2)$$O(n \log n)$

Після швидкого огляду на ще певні часи , природно сказати, що хитрощі не повинні бути настільки ефективними, як інші.

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

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

Оновлення 1: канонічна відповідь говорить про те, що константи, що беруть участь у середнього випадку, менші, ніж константи, що беруть участь в інших алгоритмах . Однак я ще не бачив належного обґрунтування цього, точні розрахунки замість інтуїтивно зрозумілих ідей.O ( n журналу n $O(n\log n)$$O(n\log n)$

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

Оновлення 2: Існує декілька веб-сторінок, які пропонують порівняння алгоритмів сортування, деякі більш привабливі, ніж інші (особливо це сортування-algorithms.com ). Цей підхід, крім представлення приємної наочної допомоги, не відповідає на моє запитання.

Коротка відповідь

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

Довга відповідь

Поперше,

Середнє Справа не існує!

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

Чому -Запис?$O$

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

Є два шляхи виходу:

1. Зафіксуйте модель машини.

   Це зроблено в книжковій серії Дон Кнут « Мистецтво комп’ютерного програмування» для штучного «типового» комп'ютера, винайденого автором. У томі 3 ви знайдете точні середні результати для багатьох алгоритмів сортування, наприклад

   • :$11.667(n+1)\ln(n)-1.74n-18.74$
   • Mergesort:$12.5 n \ln(n)$
   • Гіпсорт: $16 n \ln(n) +0.01n$
   • Вставка: ^{[ джерело ]}$2.25n^2+7.75n-3ln(n)$
     

   Ці результати свідчать про те, що Quicksort є найшвидшим. Але це доведено лише на штучній машині Knuth, це не обов'язково означає нічого, скажімо, для вашого ПК x86. Зауважте також, що алгоритми по-різному відносяться до малих входів:
   
   ^{[ джерело ]}

2. Проаналізуйте абстрактні основні операції .

   Для порівняння на основі сортування це, як правило, свопи та ключові порівняння . У книгах Роберта Седжевіка, наприклад "Алгоритми" , такий підхід дотримується. Ви знайдете там

   • Quicksort: порівняння та в середньому$2n\ln(n)$$\frac13n\ln(n)$
   • Mergesort: порівнянь, але до доступу до масиву (об'єднання не засноване на свопі, тому ми не можемо порахувати це).8,66 n ln ( n $1.44n\ln(n)$$8.66n\ln(n)$
   • : порівняння та свопи в середньому.$\frac14n^2$$\frac14n^2$

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

Інші вхідні розподіли

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

Щодо цього питання можна зробити декілька пунктів.

Кіксорт зазвичай швидкий

$O(n^2)$

$n-1$$O(n \log n)$

Квіксорт зазвичай швидший, ніж більшість сортів

$O(n \log n)$$O(n^2)$$n$

$O(n \log n)$$O(\frac{n}{B} \log (\frac{n}{B}))$$B$

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

$O(\frac{n}{B} \log_{\frac{M}{B}} (\frac{n}{B}))$$M$$k$

Кіксорт зазвичай швидший, ніж Мергезорт

Це порівняння повністю стосується постійних факторів (якщо розглядати типовий випадок). Зокрема, вибір полягає в субоптимальному виборі стрижня для Quicksort порівняно з копією всього вводу для Mergesort (або складністю алгоритму, необхідного для уникнення цього копіювання). Виявляється, перший є більш ефективним: теорії за цим немає, це просто відбувається швидше.

$n$$O(\log n)$$O(n)$

Нарешті, зауважте, що Quicksort трохи чутливий до вводу, який трапляється в правильному порядку, і в цьому випадку він може пропустити кілька свопів. У Mergesort немає таких оптимізацій, що також робить Quicksort трохи швидшим порівняно з Mergesort.

Використовуйте сорт, який відповідає вашим потребам

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

В одному з навчальних посібників з програмування в моєму університеті ми попросили студентів порівняти ефективність кваксорту, злиття, сортування вставки та вбудованого list.sort Python (званий Timsort ). Експериментальні результати мене глибоко здивували, оскільки вбудований list.sort виконаний набагато краще, ніж інші алгоритми сортування, навіть із випадками, коли легко робиться крах, злиття злиття. Тому робити висновок про те, що звичайна реалізація кікспорту найкраща на практиці. Але я впевнений, що там набагато краща реалізація quicksort або її гібридна версія там.

Це приємна стаття в блозі Девіда Р. Маківера, що пояснює Тимсорт як форму адаптаційного злиття.

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

Отже, коли ви запускаєте, ви отримуєте доступ до першого елемента в масиві, і фрагмент пам'яті ("розташування") завантажується в кеш. І коли ви намагаєтеся отримати доступ до другого елемента, він (швидше за все) вже знаходиться в кеші, тому це дуже швидко.

Інші алгоритми, такі як гипсорт, не працюють так, вони багато стрибають у масиві, що робить їх повільнішими.

Інші вже говорили, що середній асимптотичний час виконання Quicksort кращий (в постійному), ніж у інших алгоритмів сортування (у певних налаштуваннях).

$\cal{O}(n \log n)$

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

$k \approx 10$

$O(n \lg n)$

ps: якщо бути точним, бути кращим, ніж інші алгоритми, залежить від завдання. Для деяких завдань може бути краще використовувати інші алгоритми сортування.

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

• Порівняння швидкого сортування з іншими алгоритмами сортування

• Порівняння купі-сортування з іншими алгоритмами сортування

$\Theta(n^2)$$\Theta(n\log n)$

Друга причина полягає в тому, що вона виконує in-placeсортування та дуже добре працює з середовищами віртуальної пам'яті.

ОНОВЛЕННЯ: (Після коментарів Яноми та Свічка)

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

Розглянемо наступну послідовність:

12,30,21,8,6,9,1,7. The merge sort algorithm works as follows:

(a) 12,30,21,8    6,9,1,7  //divide stage
(b) 12,30   21,8   6,9   1,7   //divide stage
(c) 12   30   21   8   6   9   1   7   //Final divide stage
(d) 12,30   8,21   6,9   1,7   //Merge Stage
(e) 8,12,21,30   .....     // Analyze this stage

Якщо ви всебічно бачите, як відбувається останній етап, перший 12 порівнюється з 8, а 8 - меншим, так що він проходить перший. Тепер 12 - ПРОТИ, порівняно з 21, а 12 - далі і так далі. Якщо взяти остаточне злиття, тобто 4 елементи з 4 іншими елементами, воно проводить безліч EXTRA порівнянь як констант, які НЕ проводяться в Швидкому Сортуванні. Це причина, чому віддається перевага швидкого сортування.

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

Ще в 2008 році я відстежив висячу помилку програмного забезпечення до використання quicksort. Через деякий час я написав прості програми введення сортування, quicksort, сортування купи та злиття та випробував їх. Мій сорт злиття випереджав усі інші під час роботи над великими наборами даних.

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

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

Редагувати: мови програмування, такі як Java, Python та Perl, також використовують сортування злиття, а точніше похідну, наприклад, Timsort або сортування злиття для великих наборів та сортування вставки для малих наборів. (Java також використовує подвійний шарнір, який швидше, ніж звичайний швидкодіючий.)

1 - Швидке сортування є місцем (не потрібно додаткової пам’яті, крім постійної кількості).

2 - Швидке сортування легше здійснити, ніж інші ефективні алгоритми сортування.

3 - Швидке сортування має менші постійні фактори за час його роботи, ніж інші ефективні алгоритми сортування.

Оновлення: для сортування злиття вам потрібно зробити «об’єднання», для якого потрібні додаткові масиви для зберігання даних перед об'єднанням; але в швидкому роді ви цього не зробите. Ось чому швидкий сорт на місці. Існує також кілька додаткових порівнянь, зроблених для злиття, які збільшують постійні фактори в роді злиття.

За яких умов конкретний алгоритм сортування насправді найшвидший?

$\Theta(\log(n)^2)$$\Theta(n \cdot \log(n)^2)$

$\Theta(n \cdot k)$$\Theta(n \cdot m)$$k=2^{\#number\_of\_Possible\_values}$$m = \#maximum\_length\_of\_keys$

3) Чи складається в основі структура даних з пов'язаних елементів? Так -> завжди використовувати на місці сортування об'єднань. Існують як прості в реалізації фіксованого розміру, так і адаптивні (так само природні) знизу вгору місця злиття різних типів для пов'язаних структур даних, і оскільки вони ніколи не вимагають копіювання всіх даних на кожному кроці, і вони ніколи не потребують рекурсій, вони є швидше, ніж будь-які інші загальні сортування на основі порівняння, навіть швидше, ніж швидке сортування.

$\Theta(n)$

5) Чи може розмір базових даних пов'язати малий до середній розмір? наприклад, n <10 000 ... 100 000 000 (залежно від базової архітектури та структури даних)? Так -> використання бітонічного сортування або нечетного злиття Batcher. Перейти 1)

$\Theta(n)$$\Theta(n^2)$$\Theta(n \cdot \log(n)^2)$найгірший час роботи відомий, або, можливо, спробуйте сортувати гребінець. Я не впевнений, що сортування оболонки або сортування гребінців на практиці матимуть досить хороші результати.

$\Theta(\log(n))$$\Theta(n)$$\Theta(n)$$\Theta(\log(n))$$\Theta(n^2)$$\Theta(n)$$\Theta(n)$$\Theta(\log(n))$$\Theta(n \cdot \log(n))$

$\Theta(n \cdot \log(n))$

Підказки щодо імплементації швидкості:

$\Theta(n)$$\Theta(\log(n))$$\Theta(n^{\log_k(k-1)})$

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

Підказки щодо реалізації об'єднань:

1) Злиття з низкою вгору завжди швидше, ніж злиття зверху вниз, оскільки воно не вимагає рекурсійних викликів.

2) дуже наївне злиття може бути пришвидшено за допомогою подвійного буфера і перемикання буфера замість копіювання даних назад з тимчасового масиву після кожного кроку.

3) Для багатьох даних у реальному світі адаптаційний злиття значно швидше, ніж об'єднання з фіксованим розміром.

$\Theta(k)$$\Theta(\log(k))$$\Theta(1)$$\Theta(n)$

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

1) існує більше, ніж "кілька" можливих значень

2) основна структура даних не пов'язана

3) нам не потрібен стабільний порядок

4) дані достатньо великі, що незначний неоптимальний асимптотичний час роботи бітонічного сортувального пристрою або непарного злиття об'єднаного об'єднання Батчера починає

5) дані майже не відсортовані і не складаються з великих вже відсортованих частин

6) ми можемо отримати доступ до послідовності даних одночасно з декількох місць

$\Theta(\log(n))$$\Theta(n)$

ps: Хтось повинен мені допомогти з форматуванням тексту.

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

$a \le b$