Заблокирован
|
|
1 | |
Наиболее быстрый способ сортировки файла в 1 Тб при ограниченном объёме оперативной памяти29.07.2015, 16:30. Показов 25253. Ответов 85
Метки нет (Все метки)
Привет!
Какой есть наиболее быстрый способ сортировки файла, содержащего int-ы (по одному int-у на каждой строчке), размером в 1 террабайт, если на компе, к примеру, доступно всего 2 гб оперативки ... ? Ну файл с нитами типа: Добавлено через 1 час 11 минут Важная тема теряется... Up! Добавлено через 4 часа 45 минут Ну так что, никто не подскажет, как отсортировать 1 гиг в файле?
0
|
29.07.2015, 16:30 | |
Ответы с готовыми решениями:
85
Наиболее быстрый способ склеивания фрагментов файла Наиболее быстрый способ записи в консоль Наиболее быстрый способ забрать данные из html Наиболее быстрый способ работы с файлом Excel (около 20000 строк) |
7793 / 6560 / 2984
Регистрация: 14.04.2014
Сообщений: 28,672
|
|
29.07.2015, 18:01 | 2 |
Файл текстовый?
1
|
Заблокирован
|
|
29.07.2015, 21:14 [ТС] | 3 |
Хмм... а хз. Вот оригинальный текст вопроса:
You have a 1TB file containing integers (one number per line). You have 2GB of memory. How do you sort this file as fast as possible? Судя по фразе: one number per line могу предположить, что текстовой ... Добавлено через 3 часа 5 минут nmcf, так ты подкинешь идейку, как эту сортировку получше реализовать?
0
|
1375 / 519 / 72
Регистрация: 21.07.2015
Сообщений: 1,304
|
|
29.07.2015, 21:27 | 4 |
Butt-Head, ну я бы сделал как-то так:
1.В цикле до конца файла: 1.1 Считать инты, сколько гарантированно влезет в память. 2.2. Отсортировать их быстрой сортировкой. 2.3 записать фрагмент во временный файл (обязательно в двоичном виде) с уникальным именем для (для фрагмента). 2. Последовательно попарно объединят файлы сортировкой слиянием. Когда останется 2 фрагмента - сливаешь в один текстовый.
1
|
7793 / 6560 / 2984
Регистрация: 14.04.2014
Сообщений: 28,672
|
|
29.07.2015, 21:37 | 6 |
Сообщение было отмечено Butt-Head как решение
Решение
1
|
Заблокирован
|
|
29.07.2015, 21:51 [ТС] | 8 |
nmcf, я не очень въехал в чём там ваще фокус ...
Ну открыл ты кучу потоков, о одной строчке читаешь из каждого потока и пишешь в финальный поток... Бред какой - то. А что - то не помню, файловый поток в памяти занимает размер файлы или нет? Вот тут нашёл кое что, но не понял суть опять же http://stackoverflow.com/quest... -hard-disk Добавлено через 1 минуту Непонятно, как ты обойдёшь ограничение в 2 гб оперативки. Как вообще, пусть даже не быстро, отсортировать файл в 1 террабайт?
0
|
70 / 64 / 40
Регистрация: 17.02.2014
Сообщений: 265
|
|
29.07.2015, 22:09 | 11 |
Сообщение было отмечено Butt-Head как решение
Решение
Почему то хотел изначально отговорить от MergeSort, поскольку она требовательна к памяти, но видимо в данном случае без нее никак, кстати можно взять немного оптимизации из TimSort при склеивании двух фрагментов, в случае постоянного извлечения из одного подмассива брать следущий элемент галопом, так можно записывать в исходный массив целыми кусками.
0
|
29.07.2015, 22:43 | 13 | |||||
Как вариант, алгоритм исключительно для WinAPI и для двоичного файла:
0
|
Заблокирован
|
|
29.07.2015, 22:51 [ТС] | 14 |
Хмм... Я в принципе знал про это, но конечно же хотелось чего - то кроссового. Ну да ладно, для кроссового я так понял нужно External Merge Sort
Слушай, а по поводу Mapped файлов в WinApi, как то можно просчитать размер будущего проецируемого файла? Ну вот, допустим, какой объём потребуется для 1 Tb. .. И вообще, как эта проекция физический работает, что - то я не пойму ... Небойсь через кеш в файл подкачки самой винды и на террабайте просто упадёт
0
|
Заблокирован
|
|
29.07.2015, 22:57 [ТС] | 16 |
Смотри. Вот есть у тебя три куска:
Первый: 0,7,3 [допустим размер 1 гб] Второй: 4,2,8 [допустим размер 1 гб] Третий: 9,0,8 [допустим размер 1 гб] sort первых двух: Первый: 0,3,7 Второй: 2,4,8 смерджил их: merge1: 0,2,3,4,7,8 [2 гб] что ты дальше будешь делать? Подгружать весь merg1 в память и сливать его с третьим куском? Тогда у тебя этот мердж кусок будет расти как на дрожжах и привет пямять ...
0
|
1375 / 519 / 72
Регистрация: 21.07.2015
Сообщений: 1,304
|
|
29.07.2015, 23:01 | 19 |
Да работает она просто - при обращении к памяти #PF генерируется и ОС по этому адресу страницу из файла подгружает. Сам я никогда не использовал эту технологию. Но чудес-то не бывает, если памяти жрет мало, значит постоянно тасует страницы между диском и озу, что не особо благоприятно скажется на скорости.
0
|
Игогошка!
1801 / 708 / 44
Регистрация: 19.08.2012
Сообщений: 1,367
|
|
29.07.2015, 23:10 | 20 |
Разбиваем на куски. Сортируем каждый кусок. Сразу сливаем все куски в выходной файл.
Как так сразу сливаем? Просто открываем все файлы. У каждого файла есть итератор на текущее число в нем. Выбираем наименьшее число среди всех итераторов. Пишем его в результирующий файл. Сдвигаем этот итератор на следующее число в этом файле. Снова выбираем наименьшее число среди итераторов. И так далее, пока все итераторы не дойдут до конца своих файлов. Это самый простой и очевидный метод. Его можно оптимизировать. Например, читать из каждого файла не по одному числу, а пачками. Так как у нас там числа, то можем сортировать за O(n).
0
|
29.07.2015, 23:10 | |
29.07.2015, 23:10 | |
Помогаю со студенческими работами здесь
20
Наиболее быстрый способ сравнения двух экземпляров структур на предмет одинаковости их полей Какой способ сортировки одномерного массива самый быстрый? Memory shift или самый быстрый способ перемещения блока памяти Наиболее рациональный способ распределения памяти Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |