|
|
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Как наиболее быстро отсортировать массив типа int[N] при следующих значениях N 1..10; 20..100; 100...5000; Понятно, что тут Qsort не рулит вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2006, 16:55 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
быстрее Хора, вроде, ничего не придумано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2006, 16:56 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Зависит от природы самой предметной области ИМХО. Иногда дешевле поддерживать структуру данных в постоянно-отсортрованом виде (Б-дерево). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2006, 17:19 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Хоар хорош, когда данных для сортировки достаточно много, скажем порядка >1000. А иначе при сортировке 15 элементов времени тратится значительно больше, чем даже вставкой. Шелл тоже не оптимален, хотя и быстрее.А это надо как раз для оптимизации сотритовки большого количества небольших массивов. например после неполного Хоара можно отсортировать его подгруппы зночительно быстрее, если не до конца сортировать им, а после порога в 100 элементов перейти на что-то быстрее. Это же легко понять, если оценить поведение Qsort на данных Допустим, у нас кол-во элементов есть 2^10 и мы подразбиваем интервал на ранные группы. Итого имеем после 5 проходов 32 группы по 32 элемента. Ну и зачем нам далее вызывать Qsort(Хоар) 160 раз, если можно 32 раза ту же вставку. Притом на этом этапе(последнем) тратится примерно 50% производительности, что малоприемлимо(!). Вот и стоит вполне фундаментальная проблема именно сортировки большого количества небольших групп элементов за минимальное алгоритмическое время! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 10:34 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Правильно сказал zz118. Но, Хоар удобен, когда мы имеем random-access ко всем элементам массива и среднее время доступа=const. Если вносить дополнительные условия (блочное чтение данных с диска, влияние кеша второго уровня), то можно использовать различные оптимизации. Замечу, что Хоар хорош в чистой теории. На практике (для очень больших массивов) можно использовать комбинацию методов. Например - "Хоар" + "Ленточное Слияние". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 11:14 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Добавлю. Для массивов размером 2-3 элемента вполне подойтет метод "Пузыря". И нечего здесь стеснятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 11:21 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Ну а для 100 элементов как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 12:06 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Den_di! Судя по вашему второму посту вы неплохо разобрались в самой предментной области сортировок. Я думаю, что вы сами в состоянии ответить на ваш вопрос. Проведите ряд экспериметов. С различными исходными условиями. Сделайте табличку: Размер массива/группыМетодСреднее время (сек)1000Хоар?100/10Хоар+Шелл?1000/100Хоар+Шелл? Я думаю, что скрулистам будет интересно узнать реальные цифры оценок времени работы. P.S. Еще наблюдение: Хоар ведет себя по разному на различных исходных раскладах массива. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 12:42 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
mayton Спасибо за доверие. Если кто не знает, Хоар далеко не самый быстрый алгоритм. Есть несколько простых и намного более быстрых алгоритмов. Например поразрядная сортировка и сортировка слиянием (merge sort). Ассимптотика у них всегда N и дополнительная память им не нужна(ну не считать же 400Kb дополнительных). Если кому интересно, могу выложить исходник моей реализации. Но опять же они намного быстрее пузырька только при большом количестве элементов. Для Хоара порог оптимальности чде-то порядка 70-80 элементов а потом сортировка вставкой.(30% выигрыша). Но как гарантированно найти самый быстрый алгоритм при небольшом количестве элементов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 13:03 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Den_diЕсли кому интересно, могу выложить исходник моей реализации. Ну.. если не затруднит. Был-бы признателен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 13:12 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
насколько помню кроме бинарного дерева нет стабильных алгоритмов n*log(n) аффтопитезь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 15:28 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
maytonДобавлю. Для массивов размером 2-3 элемента вполне подойтет метод "Пузыря". И нечего здесь стеснятся. Тут нужна аккуратность. Помнится, на первом курсе параллельному потоку дали курсовую по методам сортировки, и я по этому поводу дал знакомой девчонке распечатку реализации qsort-а - ту, которая шла в демках к пятому паскалю. Вдруг она жалуется - мол, работает медленнее пузырька. Идем разбираться - вижу, что она как раз примерно так и оптимизировала :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 15:48 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Aklinнасколько помню кроме бинарного дерева нет стабильных алгоритмов n*log(n) а я тебе, помнится, рассказывал об одном таком. я же прошу отсортировать не абстрактное множество элементов а вполне ограниченное(!). Сначало сортируем по старнему разряду, потом по младшему.Тут и log не появляется даже. И придумал как под это дополнительную память не отхапывать. Сначало рассчитываем границы по старшим разрядам, потом расскидываем все элементы по группам а потом сортируем сами группы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 15:53 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
softwarer maytonДобавлю. Для массивов размером 2-3 элемента вполне подойтет метод "Пузыря". И нечего здесь стеснятся. Тут нужна аккуратность. Помнится, на первом курсе параллельному потоку дали курсовую по методам сортировки, и я по этому поводу дал знакомой девчонке распечатку реализации qsort-а - ту, которая шла в демках к пятому паскалю. Вдруг она жалуется - мол, работает медленнее пузырька. Идем разбираться - вижу, что она как раз примерно так и оптимизировала :) а вот простой вариант Qsorta своего сочинения: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 15:56 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Den_di Ну... это перевод фундаментального алгоритма. Я-то думал, что вы похвастаетесь гибридным. С подгруппами и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 16:04 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
mayton Den_di Ну... это перевод фундаментального алгоритма. Я-то думал, что вы похвастаетесь гибридным. С подгруппами и т.п. так это не о том Если гибридный, то что-то типа такого Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. Только это не всегда лучьше предыдущего. Так как насчёт сортировки набольших массивов! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 16:19 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
(смеясь) Экой вы коллега ... настойчивый! Ну.. для 100 элементов - теория умалчивает! И я вслед за ней скажу - не знаю! В вашем исходнике есть несколько настроечных параметров . 1) Размер массива (расстояние между поинтерами L и R) 2) Порог переключения алгоритма (20) 3) Статистические особенности иходных данных (массив может быть заранее отсортирован, перемешан, перемешан с монотонными подпоследовательностями). Подвигайте их. Понаблюдайте время отклика алгоритма. Табличку, что я нарисовал можете изменить как будет удобно. Дополнительно, могу предложить использовать параллелизм. Если у вас Hyper-Threading или несколько CPU , можете залочить mqsort на два потока. Только помните, что beginthread() или fork() инерционны и требуют некоторого время для разгона. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 16:36 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
mayton (смеясь) Да то что я там написал никокого отношения к эффективности не имеет! Заниматься глупостями вроде Хоара тем более. Я же говорил, что он далеко не лидер по скорости. Например даже мой кривой алгоритм(нормальный немного сложнее, и быстрее в 2-3 раза) и то быстрее Qsorta в 2 раза: maytonНу.. если не затруднит. Был-бы признателен. Я говорил о чём-то вроде этого Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. алгоритм элементарный и почти не требует дополнительной памяти!. Я же спрашиваю именно про самую быструю сортировку небольших массивов! Если кто знает алгоритм быстрее моего, прошу сказать, буду рад ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2006, 18:21 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Нерекурсивный QSort. Для Intel-я call и стек - дорогое удовольствие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 15:55 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Den_di ...Если кто знает алгоритм быстрее моего, прошу сказать, буду рад Я сравнивал ваш алгоритм с классическими (книжными) реализациями сортировок. Уже есть статистика. Но перед тем, как ее публиковать мне-бы хотелось бы задать вам несколько вопросов. 1) Вы действительно являетесь автором РЕАЛИЗАЦИИ этого алгоритма? Не является ли ваш алгоритм родственником метода Шелла? 2) Откуда произошла константа 0xffff ? На что влияет ее выбор ? 3) Этот алгоритм позиционируется как ДОПОЛНЕНИЕ к Хоару на малых размерах блока (менее 100 элементов ) ? Условия тестирования: Comp: Celeron 1700/256/2x512Mb OS: CentOS(Linux), GnuC++ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 22:58 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
mayton Den_di ...Если кто знает алгоритм быстрее моего, прошу сказать, буду рад Я сравнивал ваш алгоритм с классическими (книжными) реализациями сортировок. Уже есть статистика. Но перед тем, как ее публиковать мне-бы хотелось бы задать вам несколько вопросов. 1) Вы действительно являетесь автором РЕАЛИЗАЦИИ этого алгоритма? Не является ли ваш алгоритм родственником метода Шелла? 2) Откуда произошла константа 0xffff ? На что влияет ее выбор ? 3) Этот алгоритм позиционируется как ДОПОЛНЕНИЕ к Хоару на малых размерах блока (менее 100 элементов ) ? Условия тестирования: Comp: Celeron 1700/256/2x512Mb OS: CentOS(Linux), GnuC++ Ну, если вы не поняли, что он вообще не сортирует, то жаль. Он почти сортирует. Это просто алгоритм деления не на 2 группы, а на N. Выбор Oxffff произощёл от деления на 1<<16 групп. Алгоритм вполне самостоятельный, но после него нужен проход чнм-то вроде шелла. А вот это его полный вариант: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 16:43 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
да, вызывать как msort(mas,N,28); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 16:44 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
Den_di softwarerпропущено... Тут нужна аккуратность. Помнится, на первом курсе параллельному потоку дали курсовую по методам сортировки, и я по этому поводу дал знакомой девчонке распечатку реализации qsort-а - ту, которая шла в демках к пятому паскалю. Вдруг она жалуется - мол, работает медленнее пузырька. Идем разбираться - вижу, что она как раз примерно так и оптимизировала :) а вот простой вариант Qsorta своего сочинения: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. тут и ошибиться невозможно как то страшно выставлять int *r за правый край массива для нормальной работы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. mayton Den_di Ну... это перевод фундаментального алгоритма. Я-то думал, что вы похвастаетесь гибридным. С подгруппами и т.п. а перевод какого фундаментального? а почему во всех, гм, некоторых, мной просмотренных версиях Хоара (и в этой тоже) выполняется явно избыточный свап элемента массива с собой. в исходной версии Код: plaintext 1. 2. 3. 4. 5. 6. 7. i бывает равно j, явно лишняя работа. неужто никто не озадачился за 52 года после публикации алгоритма? или я шото не то вижу, в связи с полной деградацией? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2012, 15:10 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
tchingiz, я честно говоря не знаю что это за исходник. Очевидно что не мой. А откуда дровишки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2012, 16:16 |
|
||
|
сортировка небольших массивов
|
|||
|---|---|---|---|
|
#18+
0) на курсах в компьютерной академии крок. 1) я рылся у нас по другим темам, там была ссылка на сайт с различными методами, который рекомендовали к изучению. сайт забыл. было меньше равно 2) http://www.codelab.ru/source/32/ Код: plaintext 1. 2. 3. 4. 5. 3) в википедии на других языках тоже меньше равно. http://ru.wikipedia.org/wiki/%C1%FB%F1%F2%F0%E0%FF_%F1%EE%F0%F2%E8%F0%EE%E2%EA%E0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2012, 18:32 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=34038584&tid=1342090]: |
0ms |
get settings: |
4ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
135ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 393ms |

| 0 / 0 |
