powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Тяпничная huge-сортировка
25 сообщений из 133, страница 5 из 6
Тяпничная huge-сортировка
    #39419325
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan)д0kХ,

я задачу не придумывал, такая была 20288078
учитывай что читать нужно весь объём Ln(S/MemBlockSize) раз

10 гб у меня сортировалось где то 4-5 минут, с учётом O(ln(n) * N) вроде как в твои параметры вписывается

Какой у тебя MemBlockSize ?
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419327
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dima Tд0kХ1. Не было ограничей по памяти,
20286712

д0kХ3 Как показывает практика однопоточная сортировка медленнее чем
современные шпиндельные
диски на мультиблочном ввводе выводе
ни один современный процессор не в силах сортировать поток
со скоростью с которой может читать SATA3 диск ( 60 - 90 мегабайт/сек)
Мне не интересна стандартная сортировка, которая O(N*log(N)) даже на сортированном файле. На сортированном хочу O(N), не надо мне *log 2 (N), log 2 (1Гб) = 30. Тут оно и есть, поэтому интересно.

Я не много о другом и
Я не понял причем тут вычислительная сложность к параметрам параллелизма ?

Я поступаю "тупо" , пытаюсь понять критерии при которых можно задействать
максимальное количество имеющихся ядер в системе в зависимости
от имеющейся производительности ввода вывода
не важно какой алгоритм они крутят O(N*log(N)) или O(N).

То есть адаптивно определить, что есть слабым местом конкретной вычислительной
системы процессор или ввод вывод.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419333
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Майтон ,

д0kХЯ поступаю "тупо" , пытаюсь понять критерии при которых можно задействать
максимальное количество имеющихся ядер в системе в зависимости
от имеющейся производительности ввода вывода
не важно какой алгоритм они крутят O(N*log(N)) или O(N).

То есть адаптивно определить, что есть слабым местом конкретной вычислительной
системы процессор или ввод вывод.

А дальше использовать наиболле оптимальный для имеющихся условий алгоритм
сортировки.



вот что нужно говорить майкрософту на собеседовании в ответ на постановку
задачи об абстрактной сортировке в вакуме )
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419339
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kХ
Какой у тебя MemBlockSize ? 1 Мб Ram больше использовать по условиям задачи нельзя
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419346
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan)д0kХ Какой у тебя MemBlockSize ? 1 Мб Ram больше использовать по условиям задачи нельзя

Если задаче не определен режим открытия файлов и используется кеш файловой системы ,
то это не чесный тест.

Я не помню что бы Майтон озвучивал однозначное
числовое ограничение на объем памяти.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419362
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kХ,

он много что не озвучил, я озвучил 20288078 , какая разница?
задача стала не такая абстрактная и сразу видно на что обратить внимание
обычно её варьируют кто как хочет

ну а кэш FS какой-бы волшебный не был, убьётся нужным входным объёмом
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419368
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 All
д0kХЕсли задаче не определен режим открытия файлов и используется кеш файловой системы ,
то это не чесный тест.

1 Мб - это очень странная цифра. Она растет ногами разве-что из MS-DOS или Windows-95/98.
Да и вообще, в современных ОС и фреймворках все меньше и меньше возможностей
контролировать или явно разграничивать использование памяти. Неявных способов
выделить ее - вагон и маленькая тележка.

Я не помню что бы Майтон озвучивал однозначное
числовое ограничение на объем памяти.

(потирая лоб)

Я не знаю что вы от меня хотите услышать. Любая цифра - будет подвергнута критицизму.
Буду профанации. Будут фейковые решения.

Тут важна не цифра. А само понимание стека технологий и подход. К примеру если имеем
1 ядро + 1Гиг памяти + 1Терабайт диска = можем отсортировать (грубо) 500 Гиговый
текстовый файл за N секунд времени.

Имеем ту-же конфигурацию но 2 диска по 500 Гигов. То-же самое. Но степень
параллелизма для merge - будет выше. Докинем перформанса (грубо) порядка +30%.
(Разумеется если мы сумеем эту степень параллелизма грамотно подать на вход
алгоритму).

Имеем на том-же стеке 3 диска по 330 Гигов. То-же самое. +60% перформанса
на слияниях.

И это все без конкретных цифр. А только на соотношениях. 1:1000 в моем примере.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419369
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TМожет кто идею подкинет как сливать во временные файлы?
А в чем сложность? Диском ты не ограничен. Бези себе /tmp или как
там в Windows... GetTempPath(..) и погнал.

P.S. Пока тары-бары да я всем отвечаю уже в 4х топиках - ни пса ни скомпилировал
твои акторы.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419371
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"640 Kb должно хватить всем" ( C )
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419409
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

что-то пятая страница уже, а сколько-нибудь вменяемой постановки задачи не видать.
Но, раз о "собеседовании" речь идет - вроде как и не надо.
А в плане собеседования - на собеседовании я бы в близком контексте рассказу про приделывание солитерной ( она же терпеливая - patience) сортировки как первой фазе для внешней сортировки по формированию набора сливаемых файлов, вероятно радовался,
в комбинации с последующим внешним слиянием.
Она (терпеливая), кстати, еще и модная стала в последнее время.

https://en.wikipedia.org/wiki/Patience_sorting

Там в ссылках занятная статья от Microsoft на солитерную тему.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419428
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kХЯ не много о другом и
Я не понял причем тут вычислительная сложность к параметрам параллелизма ?

Я поступаю "тупо" , пытаюсь понять критерии при которых можно задействать
максимальное количество имеющихся ядер в системе в зависимости
от имеющейся производительности ввода вывода
не важно какой алгоритм они крутят O(N*log(N)) или O(N).
Я тоже немного о другом, меня сам алгоритм с деревом триплетов заинтересовал, я его попутно исследую:
1. Это отличный способ для решения задач типа "получить N минимальных элементов из несортированного массива". По сути в один проход строится дерево триплетов, а потом извлекай из него N элементов. Вычислительных операций будет пропорционально N, а не размеру всего массива, т.к. вычисление происходит в момент извлечения минимального.
2. Потом хочу сюда 20170548 добавить дерево триплетов. Я там как-раз искал что подобное, порешал уже, но пусть будет про запас.

д0kХТо есть адаптивно определить, что есть слабым местом конкретной вычислительной
системы процессор или ввод вывод.
Чтобы что-то определить надо сначала дорешать запустить и посмотреть что получилось. Может проц и не загрузится на 100%.
А потом уже рефакторингом заниматься.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419431
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419631
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dima Tд0kХЯ не много о другом и
Я не понял причем тут вычислительная сложность к параметрам параллелизма ?

Я поступаю "тупо" , пытаюсь понять критерии при которых можно задействать
максимальное количество имеющихся ядер в системе в зависимости
от имеющейся производительности ввода вывода
не важно какой алгоритм они крутят O(N*log(N)) или O(N).
Я тоже немного о другом, меня сам алгоритм с деревом триплетов заинтересовал, я его попутно исследую:
1. Это отличный способ для решения задач типа "получить N минимальных элементов из несортированного массива". По сути в один проход строится дерево триплетов, а потом извлекай из него N элементов. Вычислительных операций будет пропорционально N, а не размеру всего массива, т.к. вычисление происходит в момент извлечения минимального.
2. Потом хочу сюда 20170548 добавить дерево триплетов. Я там как-раз искал что подобное, порешал уже, но пусть будет про запас.

д0kХТо есть адаптивно определить, что есть слабым местом конкретной вычислительной
системы процессор или ввод вывод.
Чтобы что-то определить надо сначала дорешать запустить и посмотреть что получилось. Может проц и не загрузится на 100%.
А потом уже рефакторингом заниматься.

Дима, я тебя не понимаю , ты говоришь о другом, а цитируешь размышления
об адаптивных параметрах параллелизма.

Если пишется ПО то подразумевается , что оно будет выполняться
тысячи раз на железе куда его проинсталили.
Я предполагаю что после первого запуска
ПО сортировки себя адаптирует под железо на котором выполняется.
что бы скорость и использование ресурсов в следующих запусках
было более оптимальным.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419757
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton2 All
д0kХЕсли задаче не определен режим открытия файлов и используется кеш файловой системы ,
то это не чесный тест.

1 Мб - это очень странная цифра. Она растет ногами разве-что из MS-DOS или Windows-95/98.
Да и вообще, в современных ОС и фреймворках все меньше и меньше возможностей
контролировать или явно разграничивать использование памяти. Неявных способов
выделить ее - вагон и маленькая тележка.

Я не помню что бы Майтон озвучивал однозначное
числовое ограничение на объем памяти.

(потирая лоб)

Я не знаю что вы от меня хотите услышать. Любая цифра - будет подвергнута критицизму.
Буду профанации. Будут фейковые решения.

Тут важна не цифра. А само понимание стека технологий и подход. К примеру если имеем
1 ядро + 1Гиг памяти + 1Терабайт диска = можем отсортировать (грубо) 500 Гиговый
текстовый файл за N секунд времени.

Имеем ту-же конфигурацию но 2 диска по 500 Гигов. То-же самое. Но степень
параллелизма для merge - будет выше. Докинем перформанса (грубо) порядка +30%.
(Разумеется если мы сумеем эту степень параллелизма грамотно подать на вход
алгоритму).

Имеем на том-же стеке 3 диска по 330 Гигов. То-же самое. +60% перформанса
на слияниях.

И это все без конкретных цифр. А только на соотношениях. 1:1000 в моем примере.

mayton , моя многолетняя практика работы с БД, постройки индексов,
сортировки в темппространстве БД и памяти,
просто сортировки в ОС любыми инструментами
однозначно говорит , что одно ядро не в состоянии сортировать
со скоростью потока с которой система может последовательно читать с диска.
Эта тенденция не меняется как минимум 15 лет

На один шпиндельный диск нужно в ~2 ядра , что бы система
была сбалансированной по производительности.
На SSD диск 3-4-5 ядер.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419774
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kХmayton , моя многолетняя практика работы с БД, постройки индексов,
сортировки в темппространстве БД и памяти,
просто сортировки в ОС любыми инструментами
однозначно говорит , что одно ядро не в состоянии сортировать
со скоростью потока с которой система может последовательно читать с диска.
в сортировке слияними фактически нет вычислений, так что процессор будет практически стоять
что я собственно и наблюдал, минимальна загрузка проца, 100% - диска
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419790
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan)д0kХmayton , моя многолетняя практика работы с БД, постройки индексов,
сортировки в темппространстве БД и памяти,
просто сортировки в ОС любыми инструментами
однозначно говорит , что одно ядро не в состоянии сортировать
со скоростью потока с которой система может последовательно читать с диска.
в сортировке слияними фактически нет вычислений, так что процессор будет практически стоять
что я собственно и наблюдал, минимальна загрузка проца, 100% - диска

100% нагрузки на диске вы видели потому что у вас вероятнее
всего чтение было не последовательным.
я выше говорил о балансе последовательного чтения и количест операций seek ( позиционирование головок).

Позиционирование головок очень дорогая операция , поэтому мне показалось странным
устанавливать ограничение на блок памяти 1 Мб.
Это не оптимально с точки зрения использования дисковгого ресурса,
я думаю нужно хотя бы 20 Мб , а лучше 50 ,
что бы уменьшить количество перемещений головок по поверхности шпинделей.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419837
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
офтопик

Вот пример тонкого тюнинга управления раскладки
по поврехростям шпинделей датафайлов оракла
в энтерпрайз системе

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
lspv -p hdisk32
hdisk32:
PP RANGE  STATE   REGION        LV NAME             TYPE       MOUNT POINT
  1-27    used    outer edge    df27           raw        N/A
 28-54    used    outer middle  df14           raw        N/A
 55-67    used    center        df01           raw        N/A
 68-80    used    center        df01           raw        N/A
 81-106   used    inner middle  df14           raw        N/A
107-107   used    inner edge    df14           raw        N/A
108-120   used    inner edge    df27           raw        N/A
121-133   free    inner edge  


Если надо , то любой датафайл можно подвинуть
по поврехностям шпинделей или вынести на отдельных шпиндель
незаметно для оракла на лету в зависимости от нагрузки на ввод вывод
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419844
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
д0kХ
офтопик

Вот пример тонкого тюнинга управления раскладки
по поврехростям шпинделей датафайлов оракла
в энтерпрайз системе

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
lspv -p hdisk32
hdisk32:
PP RANGE  STATE   REGION        LV NAME             TYPE       MOUNT POINT
  1-27    used    outer edge    df27           raw        N/A
 28-54    used    outer middle  df14           raw        N/A
 55-67    used    center        df01           raw        N/A
 68-80    used    center        df01           raw        N/A
 81-106   used    inner middle  df14           raw        N/A
107-107   used    inner edge    df14           raw        N/A
108-120   used    inner edge    df27           raw        N/A
121-133   free    inner edge  


Если надо , то любой датафайл можно подвинуть
по поврехностям шпинделей или вынести на отдельных шпиндель
незаметно для оракла на лету в зависимости от нагрузки на ввод вывод


Это я к тому что на скорость дискового ввода вывода и баланса нагрузок
может влиять даже место размещения файлов на поверхрости шпинделя
center - самое быстрое позиционирование
inner edge и outer edge более медленное позиционирование.
в center укладываются файлы с рандомным характером доступа ,
в edge с последовательным.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419862
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kХПозиционирование головок очень дорогая операция , поэтому мне показалось странным
устанавливать ограничение на блок памяти 1 Мб.
Это не оптимально с точки зрения использования дисковгого ресурса,
я думаю нужно хотя бы 20 Мб , а лучше 50 ,
что бы уменьшить количество перемещений головок по поверхности шпинделей.
усложнение жизни кандидату вопреки принятым практикам вполне согласуется с тем, что это тестовое задание, а не использование в продакшене
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419984
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Доделал, сортирует но очень медленно. Переливает туда-сюда во временных файлах.
Исходный файл не айс. Срока 12 байт, строки в разнобой. Средняя последовательность 5.5 строк.

Статистика 18 минут работы, обработано 82,8 Мб исходного файла:
Записано во временные: 15 252 Мб
Прочитано с диска всего: 15 335 Мб
Прочитано из исходного файла: 82,8 Мб
Сравнений: 12 158 млн.

Но сам алгоритм смотрится неплохо по количеству сравнений:
15 252 Мб это 1 271 млн. строк
Обычная сортировка будет 1271 млн. * log 2 (1271 млн.) = 38 438 млн.

Надо на сортировочных тестах его сравнивать с другими.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39419992
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima T,

очень дофига по времени для алгоритма, мне кажется в 20295980 именно та идея которую ты пытаешься реализовать
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39420019
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kealon(Ruslan)Dima T,

очень дофига по времени для алгоритма, мне кажется в 20295980 именно та идея которую ты пытаешься реализовать
Алгоритм слияния я неудачный выбрал.

Исходный файл 100 млн.строк, средняя последовательность 5.5 строк.

За раз берется 2048 последовательностей, т.е. 2048*5,5 = 11 тыс. строк. и сливается с предыдущим результатом. Т.е. надо ~9000 переливаний. При этом все накопленное участвует во всех переливаниях. Т.е. чем дальше тем тормознее.

Надо алгоритм слияния пересмотреть: если файл за один проход не разобрался, то лить все в другой, затем его на вход и т.д. пока за раз целиком не сольется. Тогда будет 2 переливания, т.е. исходный в промежуточный где станет 900 последовательностей по 11 тыс. строк, затем его в результат. Так всего 2.4 Гб записи. минуты за 3 отсортируется.

Еще тормоз из-за того что у меня указатель в файле постоянно скачет (fseek()) надо попробовать схитрить, открыть файл 2048 раз, правда тут далеко не 1 Мб будет, о чем д0kХ писал.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39420091
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kealon(Ruslan)д0kХmayton , моя многолетняя практика работы с БД, постройки индексов,
сортировки в темппространстве БД и памяти,
просто сортировки в ОС любыми инструментами
однозначно говорит , что одно ядро не в состоянии сортировать
со скоростью потока с которой система может последовательно читать с диска.
в сортировке слияними фактически нет вычислений, так что процессор будет практически стоять
что я собственно и наблюдал, минимальна загрузка проца, 100% - диска
Да. Все верно. Именно так я и предполагал.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39420097
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kХЭто я к тому что на скорость дискового ввода вывода и баланса нагрузок
может влиять даже место размещения файлов на поверхрости шпинделя
center - самое быстрое позиционирование
inner edge и outer edge более медленное позиционирование.
в center укладываются файлы с рандомным характером доступа ,
в edge с последовательным.
Я учту это замечание на будущее. Но давай пока стартанём просто
с разделов в /ext3, ext4 без привязки в расстоянию до шпинделя.

Допилим чуть позже когда будет более-менее работающий код.

В алгориме триплетов, каждый триплет будет создать неодинаковую
нагрузку. Потоки читатели будут делить по 50% трафика а поток-писатель
будет делать почти "горизонтальную полку" и оптимизировать это сейчас
сложно т.к. на следующем step фазы №2 их роли меняются и тот файл
который был создан писателем станет снова читаемым. И ситуация
перевернётся. Как быстро двигать файлы по поверхности шпинделя
так чтобы это не влияло на основной алгоитм - я пока не знаю.
...
Рейтинг: 0 / 0
Тяпничная huge-сортировка
    #39420098
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TДоделал, сортирует но очень медленно. Переливает туда-сюда во временных файлах.
Исходный файл не айс. Срока 12 байт, строки в разнобой. Средняя последовательность 5.5 строк.

Статистика 18 минут работы, обработано 82,8 Мб исходного файла:
Записано во временные: 15 252 Мб
Прочитано с диска всего: 15 335 Мб
Прочитано из исходного файла: 82,8 Мб
Сравнений: 12 158 млн.

Но сам алгоритм смотрится неплохо по количеству сравнений:
15 252 Мб это 1 271 млн. строк
Обычная сортировка будет 1271 млн. * log 2 (1271 млн.) = 38 438 млн.

Надо на сортировочных тестах его сравнивать с другими.
Дима. Как всегда респект. У тебя - легкая рука и ты очень быстро выдаешь бета-версии
пока мы только кумекаем чо и как сделать.
...
Рейтинг: 0 / 0
25 сообщений из 133, страница 5 из 6
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Тяпничная huge-сортировка
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]