morfizm (morfizm) wrote,
morfizm
morfizm

Category:

Quicksort vs Mergesort

Quicksort и Mergesort - два интересных алгоритма сортировки. В первом выбирается "барьер", и данные раскидываются на два куска, в одном всё меньше барьера, в другом больше либо равно. Эти куски сортируются рекурсивно, после чего их можно просто "склеить", т.к. наибольший элемент из первого куска будет меньше либо равен наименьшему из второго. Если разделение происходит в внутри одного массива, то "склеивать" вообще ничего не надо - данные в большом массиве будут уже автоматически отсортированы. Идеальный барьер можно выбрать за линейное время, но на практике барьер выбирают за константное время - скажем, первый элемент или средний элемент, и это не идеальный выбор (массив может разделиться совсем не пополам), но в большинстве случаев (и в с реднем случае) это даёт ту же асимптотическую сложность.

Mergesort - это антипод Quicksort'а: во время разбиения на части мы не смотрим на ключи, делим совершенно произвольно на две примерно одинаковые части, сортируем их рекурсивно, а потом нужна процедура слияния - два отсортированных массива (множества элементов которых могут крепко пересекаться) нужно "слить" в один. Это линейная операция. Суммарно тот же O(n log n).

Раньше, сравнивая Quicksort и Mergesort, я считал, что они асимптотически одинаковы для среднего случая (O(n log n)), Mergesort лучше в худшем случае (всё ещё O(n log n) vs O(n^2)), а Quicksort лучше на практике из-за хорошей локальности на нижних уровнях рекурсии.

Но мне никогда не приходило в голову, что Quicksort может быть именно асимптотически, фундаментально лучше Mergesort. Оказывается, может. Если сортировать большие объёмы данных на hadoop кластере из K машин, то с K-way Quicksort'ом можно получить время O(n/K log n/K). Если выбирать барьеры для сегментов при помощи случайной выборки, то ни на одном этапе не нужен будет линейный проход массива. Mergesort approach, как ни крути, потребует в самом конце reducer, который всё "сольёт", т.е. на одном хосте прочешет весь массив. Получаем плохой O(n), вне зависимости от K.

Однако.
Tags: algorithms, software development
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 5 comments