avva: (Default)
[personal profile] avva
(эта запись будет интересна программистам и сочувствующим)

Владимир Ярославский из Сана придумал новый вариант Квиксорта, работающий быстрее обычного. Основная идея проста до безобразия: вместо одного опорного элемента (pivot) выбираем два, распихиваем элементы в три подмассива: меньше первого опорного, между первым и вторым, и больше второго, и спускаемся рекурсивно три раза вместо обычных двух.

Трудно представить, что эта идея до сих пор никому не приходила в голову. И тем не менее, может, это так и есть, и тогда это - прекрасный, особенно убедительный пример "очевидности задним умом". Но может быть и по-другому: многие об этом думали, но никто не доводил дело до серьезного анализа.

Автор алгоритма доказывает, путем довольно сложных и скучных выкладок, которые я не проверял, что его Dual-Pivot Quicksort теоретически должен быть быстрее обычного Quicksort в следующем смысле: он делает - на типичных входных данных - примерно столько же сравнений (comparisons), но на 20% меньше обменов элементами (swaps). Его практические измерения подверждают теорию. Интересно, что он специально упоминает, что не может предоставить простое объяснение, почему это так, т.е. почему два опорных элемента должны быть лучше одного. В чем-то лучше, в чем-то хуже, разные факторы балансируют друг против друга и в итоге - согласно Ярославскому - два опорных выигрывают, но простой картинки нет.

P.S. Обнаружилась заявка на патент 2005-го года, "Multiple Pivot Sorting Algorithm". Основная идея та же, но опорных точек там выбирают много (от 3 до 7), и их надо в свою очередь сортировать между собой. Раскладка элементов по подмассивам требует сравнения каждого элемента со всеми опорными меньше его. Мне это кажется довольно дорогим удовольствием: требует намного больше сравнений, чем в теоретически оптимальном двоичном поиске среди отсортированных опорных элементов, каковой реализовать в данном случае невозможно без дополнительного копирования подмассивов. Поэтому мне кажется маловероятным, что этот алгоритм с большим числом опорных точек лучше алгоритма Ярославского; а в частном случае двух опорных точек он точно хуже его. Но никаких проверок я не запускал.
Page 1 of 3 << [1] [2] [3] >>

Date: 2009-09-12 04:07 pm (UTC)
From: [identity profile] deadkittten.livejournal.com
Возможно тут дело аналогично многоленточной сортировке -- увеличение числа лент увеличивает один вид затрат, уменьшение -- другой. И основной вопрос, какое соотношение окажется оптимальным...

Date: 2009-09-12 04:24 pm (UTC)
From: (Anonymous)
Сравнивать теперь надо не с одним опорным элементом, а с двумя, то есть количество сравнений на один проход проход получается в среднем в полтора раза больше, чем в классическом алгоритме. Почему общее число сравнений в конечном итоге будет таким же, а не в 1.5 раза больше? Неочевидно ;)

Date: 2009-09-12 04:35 pm (UTC)
From: [identity profile] mudak.livejournal.com
Подозреваю, что оптимальным числом подмассивов должно быть e, но обосновать не могу.

Date: 2009-09-12 04:44 pm (UTC)
From: [identity profile] lykac.livejournal.com
Image
http://ru.wikipedia.org/wiki/Quicksort

Date: 2009-09-12 04:46 pm (UTC)
From: [identity profile] spamsink.livejournal.com
Брусенцов поныне здравствующий должен очень радоваться - это подтверждение его идеи о превосходстве троичного над двоичным.

Date: 2009-09-12 04:49 pm (UTC)
From: [identity profile] lykac.livejournal.com
а популярны ли алгоритмы, которые учитывают архитектуру процессора, в частности длину конвейера и количество ядер?

Date: 2009-09-12 05:14 pm (UTC)
From: [identity profile] avva.livejournal.com
Потому что уровней рекурсии меньше. На каждом уровне рекурсии мы сравниваем (игнорируя мелкие оптимизации) каждый элемент с опорным в классическом алгоритме, или, как вы верно заметили, в полтора раза больше в новом. Но в классическом число уровней рекурсии равно логарифму по основанию 2 от начального размера, а в новом логарифму по основанию 3. С трудом вспомнив формулы из старших классов школы ;), заметим, что log_2(x)/log_3(x) = log_2(3) = примерно 1.58, что довольно близко к 1.5...

Date: 2009-09-12 05:19 pm (UTC)
From: [identity profile] avva.livejournal.com
Распределение памяти по кэшам (L1/L2/L3) важнее, чем длина конвейера, и также играет роль, если используется параллельный алгоритм на нескольких ядрах. Но я не знаю никакого алгоритма, который бы стремился это специально учитывать; просто это может повлиять на то, насколько быстро работает данный последовательный или данный параллельный алгоритм. Под параллельным алгоритмом я имею в виду на практике какую-нибудь версию merge sort.

Date: 2009-09-12 05:29 pm (UTC)
From: [identity profile] ygam.livejournal.com
По-моему, у Сёджвика в Algorithms in C в главе о быстрой сортировке говорится про несколько опорных точек. Я свой экземпляр лет 10 назад подарил, и не могу посмотреть.

Date: 2009-09-12 05:34 pm (UTC)
From: [identity profile] http://users.livejournal.com/_rowan_tree_/
Идея настолько проста, что никому в голову не пришло посчитать и проверить. Забавно.

Date: 2009-09-12 05:37 pm (UTC)
From: [identity profile] ygam.livejournal.com
Есть много алгоритмов, принимающих во внимание кэш.

http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-fourteen/

Date: 2009-09-12 05:40 pm (UTC)
From: [identity profile] cmm.livejournal.com
есть ещё целый новомодный класс алгоритмов под общим названием cache-oblivious.

Date: 2009-09-12 05:52 pm (UTC)
From: [identity profile] avva.livejournal.com
Нет, в _Algorithms in C_ про это ничего нет, я сейчас проверил.

Date: 2009-09-12 05:52 pm (UTC)
From: [identity profile] avva.livejournal.com
Я имел в виду конкретно алгоритмов сортировки. Но по твоей ссылке вижу, что и это есть в каком-то виде.

Date: 2009-09-12 05:56 pm (UTC)
From: [identity profile] ygam.livejournal.com
Ага, я вспомнил, что я где-то (не уверен, где, но это было в 1991-1993 гг. - я тогда прочитал несколько книжек по алгоритмам) читал нечто другое: выбрать три случайные точки, и использовать в качестве опорной точки их медиану. Я это спутал с вышеприведенным алгоритмом.

Date: 2009-09-12 05:59 pm (UTC)
From: [identity profile] ygam.livejournal.com
Количество ядер - это простая параллелизация. Если мы исполняем алгоритм поиска на 8ядерном процессоре, то можно разбить дерево приблизительно на 8 поддеревьев, и поиск по каждому поддереву поручить одному ядру.

Date: 2009-09-12 05:59 pm (UTC)
From: [identity profile] avva.livejournal.com
Да, это есть и у Седжвика, и вообще часто упоминается, но это действительно совсем другое.

Date: 2009-09-12 06:00 pm (UTC)
From: [identity profile] ygam.livejournal.com
Ну, у Кнута в 3м томе целая глава посвящена алгоритмам внешней сортировки. Сейчас кэши больше, чем оперативная память во времена написания этого тома.

Date: 2009-09-12 06:16 pm (UTC)
From: [identity profile] getman.livejournal.com
Мне кажется что оптимальное число точек должно быть функцией от размера массива, чтобы рандомальное дерево рекурсии было более-менее сбалансированным.

Date: 2009-09-12 06:40 pm (UTC)
From: (Anonymous)
Кстати, чтобы получилось в 1.5 раза, нужно еще поработать. Если считать, что опорные элементы попадают в 1/3 и 2/3, то при простейшей реализации — сначала сравниваем с нижним опорным, а потом с верхним — 1/3 элементов окажутся меньше нижнего, а 2/3 придется сравнивать еще раз. То есть не в 1.5 раза уже, а в 1.67. Можно рандомизировать порядок сравнений, но у Ярославского этого нет...

Date: 2009-09-12 06:42 pm (UTC)
From: [identity profile] lykac.livejournal.com
а если на одном ядре расчёты завершились быстрее, чем на других, что ему делать?

Date: 2009-09-12 06:45 pm (UTC)
From: [identity profile] cousin-it.livejournal.com
Да, Ярославский молодец - не поленился проверить интуитивно очевидное утверждение и в результате опроверг его. В мои математические годы мы называли подобные ситуации "приз за научную добросовестность".

Date: 2009-09-12 06:52 pm (UTC)
From: [identity profile] old-radist.livejournal.com
Красивая мысль!
From: [identity profile] gianthare.livejournal.com
Сам алгоритм, как я у него глянул, слегка муторней, т.е. из головы не напишешь.
Интересно, сколько времени займет у этого нового варианта заменить везде квиксорт (אם בכלל).
Page 1 of 3 << [1] [2] [3] >>

December 2025

S M T W T F S
  123 4 56
78 9 10 11 1213
1415 1617181920
21 22 23 24 2526 27
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Dec. 29th, 2025 04:21 pm
Powered by Dreamwidth Studios