LINUX.ORG.RU

Сортировка больших файлов


2

2

Предлагаю холивар: имеется текстовой файл размером в 10 метров, состоящий из неотсортированного массива чисел, в одной строке - одно число. Нужно прочитать исходный файл кусками по миллиону строк, отсортировать каждый кусок и записать его в отдельный временный файл. Потом нужно пробежаться по этим временным файлам и смержить все в итоговую сортировку в один результирующий файл. Смысл - в ограничении памяти, ее немного, поэтому используем дисковое пространство. Я наваял решение на питоне, которое выложу чуть попозже. На моей машинке 11-метровый файл (5 миллионов строк) перемалывается порядка минуты.

Финальная сортировка выглядит так:

f_output = open('output.txt', 'a')
for x in heapq.merge(*iters):
  f_output.write(str(x)+'\n')
f_output.close()

Кто быстрее ?

★★★★★

Последнее исправление: kto_tama (всего исправлений: 1)
Ответ на: комментарий от crowbar

Ты дурак? Я тебе говорю не про эту конкретную задачу, а про твое желание переделать задачу под себя.

Понимаешь в чем штука - мне абсалютно насрать что ты там говоришь и как ты пытаешься съехать с темы. Контекст разговора - данная задача, дак вот и кукарекай о ней.

Если говорить про эту, ты пока не обосновал даже чем плохо хранение данных в строках.

Датычё, я же тебе говорил - я тебе не сосед по парте, я помню всё, что я говорил. На что ты надеешься?

А 7метров памяти - это в 2раза больше, чем занимает 10метров текста в бинаре.

Пример после удаления.

Три - 10метров файл - это 3-4метра бинарь - это меньше, чем жрёт дефолтный говноитерпритатор говнопитона. Слив.

В удалённом.

Собственно - жрать говно.

Но давай я тебе расскажу, если тебе не ясно. Тектовый формат ТС"а тратит байт на разряд + разделитель. Т.е. превосходит 32битный инт только на дипазоне 0...99 на 2 и 1байт соответственно, т.е. это даже не являетя приемуществом.

После 3-х разрядов он начинает сливать инту по байту на разряд, а т.к. чисел в каждом разряде в 10раз больше, то слив происходит по кол-ву разрядов.

Т.е. инт - это 10разрядов - это 11байт на число, что в ~3раза больше 4-х. Т.е. тектовый формат обсирается на диапазоне инта в 3раза.

При равномерном распределение кол-во чисел с каждым разрядом увеличивается - т.е. картина так же, что на обычном диапазоне.

Первый файл - оверхед по памяти.

Второй фейл - оверхед на каст. Т.е. бесполезная операция, которая к тому же адски тормазная.

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

Т.е. только тотально больной на головку даун будет обрабатывать так относительно много данных создавая лишний оверхед форфан. И по процессорному времени и по памяти.

Во-первых кукарекаешь тут только ты

Датычё, и как же я кукарекаю?

во-вторых, чем тебя не устраивает mmap как альтернатива fopen'у

Ещё раз, в отличии от тебя, курочки, я помню свои посты и контекст разговора, поэтому писать мне ересь в надежде на то, что я чего-то забуду во имя беспалевного свича темы - не выйдет.

Ты кукарекал не про «юзать ммап вместо фопена», темболее какой даун будет юзать mmap() вместо fopen(), если это совершенно разные уровни - посикс и либси. Т.е. ты тотальная нулина.

Альтернативы? Можно перегнать его в бинарный формат, mmap'нуть и дальше сортировать слиянием кусками по M чисел предварительно копируя их в хип.

Т.е. ты тут кукарекал не про ммап, как альтернативу чтения файла, а как буфер.

Далее, ты обосрался с предворительным копированием в хип, ибо то, что заммаплено итак в хипе и не имеет смысла его копировать в хип.

Т.е. ты тотальная нулина и не знаешь даже как работает ммап, но кукарекаешь о нем, зачем?

Далее, слияние не требует изменения и перемещения - оно требует копирования, а запись происходит совершенно в другое место.

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

когда нужен random access?

Причем тут random access? Ты будешь мне пастить все термины, которые ты вчера выучил за партой?

Темболее ты о5 обосрался, ты предворительно копировал из ммапа в буфер в хипе, т.е. никакого random access у тебя к ммапу небыло.

А смысл с тобой соревноваться, если ты не собираешься решать задачу.

Отсутвие конкретных условий даёт тебе шанс сьюлить, а с конкретными условиями ты обосрёшься просто тотально.

Я то выложу свой вчерашний код, просто раньше возможности не было. Можешь заодно оценить

Именно в этом суть. Обезьяна будет постить говно, которое просто не запуститься на метре рамы, да и даже с метром хипа, но будет доказывать, что её говно типа жрёт меньше метра.

Ты реально настолько конченное? Иди запусти своё говно и выкати мне: pmap -x `pidof jabagovno`

Где ты увидел слово «код»?

Ещё раз, я напишу 3-й раз. Ты на что рассчитываешь?

Давай меньше балаболь и показывай свой код.
Ты замечаешь что у тебя весь пост — попытка выкрутиться и не писать код?
Зачем тебе мой код?
Выложи хоть какой-то свой код
А почему ты опять считаешь, что именно я должен выкладывать код первым?

Ты требуешь решения задачи, код или алгоритм — не суть

Эти жалкие попытки съюлить. Я не требовал от тебя решения задачи, даунёнок, требовал от меня её ты.

Вот тут(Сортировка больших файлов (комментарий)) ты, говно, вылезло и начало требовать от меня код.

Повторю 4-й раз, ты на что рассчитываешь?

Но повторю еще раз, «даже если принять твои слова за истину».

Какие слова? Ты, обезьяна, так и будешь делать вид, что ты не в говне?

У видишь ли не считаю что потребовать пруфов у зазнавшегося клоуна не имея своего кода — неправильно.

Мне насрать что ты там считаешь. Требовать что-то ты можешь только тогда, когда сама доказала, что ты не говно.

А какбэ говно требовать у кого-то пруфцов, что кто-то не говно не имеет право, ибо само говно.

Пусть даже не ссылки, хоть какое-то описание того что ты вообще разрабатывал серьезного.

Твои жалкие попытки съехать настолько убоги и шаблонны. У тебя не прокатить свичнуть тему.

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

carb_blog10
()
Ответ на: комментарий от carb_blog10

какой словесный понос. ты, балаболка, все еще не поняла, что всем тут уже давно насрать на тебя? ты просто сявка, нулёвая, ты ничего не можешь, ты ничтожество, ты ничего не знаешь, голова у тебя забита только говном, которое льется из твоей жопы, из которой растут руки.

anonymous
()
Ответ на: комментарий от carb_blog10

И по процессорному времени и по памяти.

По памяти константа. По процессорному времени может быть немного затратно на парсинг строки.

темболее какой даун будет юзать mmap() вместо fopen(), если это совершенно разные уровни - посикс и либси

И что с того что они разные? Ты не способен абстрагироваться от способа работы с временными файлами?

ибо то, что заммаплено итак в хипе и не имеет смысла его копировать в хип

А теперь вспомни, что сортировка — это тебе не проход по массиву. Если ты начнешь сортировать и сливать мапнутый массив напрямую при малом объеме памяти — угадай, во что ты упрешся. Не в пропускную ли способность ввода/вывода? Ты же не думаешь что mmap считывает весь входной файл в память?

Тектовый формат ТС"а тратит байт на разряд + разделитель

Я уже понял что ты не хочешь решать задачу т.к. условия тебе не нравятся. Не надо мне рассказывать про преимущества и недостатки бинарных форматов.

т.е. никакого random access у тебя к ммапу небыло

ты в самом деле тупой. для тупых поясню идею:

1) Читаем входной файл блоками по M чисел в буфер, буфер сортируем, сливаем в мапнутый файл (последовательно!)

2) Получаем мапнутый файл состоящий из K отсортированных блоков по M чисел.

3) Эти K блоков сливаем и результат пишем в выходной файл.

Обрати внимание, что мапнутый временный файл можно заменить на K файлов открытых через fopen (или open если ты считаешь его эффективнее). В моей java программе именно такой подход (хотя слияние можно было бы улучшить считывая не по одному числу, а небольшими блоками). Теперь ты понял?

Я сказал - задача говно

Ты сказал, но не показал. И даже если задача говно — ты не всегда сможешь отвертеться от её решения.

Если ты не можешь со мною спорить и доказать мне, что задача не говно, то какого хрена ты лезешь?

Вдумайся в свои слова. У тебя мания величия. Остальное твое поливание говнами разбирать лень, да и ничего осмысленного там нет. Научись сливать без ругани.

crowbar
()
Ответ на: комментарий от crowbar

А теперь вспомни, что сортировка — это тебе не проход по массиву.

Кому ты объясняешь? оно ничего кроме массивов ваще не знает.

anonymous
()
Ответ на: комментарий от anonymous

Ну хз, он иногда что-то выдает осмысленное, хотя возможно что он просто умеет гуглить и постить умные слова разбавляя их говном (чтобы типа шаристым пацаном выглядеть). Его слова про mmap в хипе наталкивают на мысль что все-таки второе.

crowbar
()
Ответ на: комментарий от anonymous

Ну давай, ты же мне покажешь чем проход по массиву отличается от сортировки?

carb_blog11
()
Ответ на: комментарий от crowbar

Как шизофреник может выдать что-то осмысленное? Он тут всегда вываливал только копипасты чужогого кода, свой родить умишка не хватает.

anonymous
()

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

Например: открыть 30 штук террабайтных файлов и попытаться их выборочно почитать...

anonymous
()

Непонятно. 11 миллионов байтов и 5 миллионов строк это числа от 0 до 10 что-ли? Сгенерил 11-мегабайтовый файлик, 4.8 миллионов чисел от 0 до 15. Джава с ограничением в 10 мегабайтов оперативной памяти перемолола такую задачку за 2 секунды. Поставил более реально - от 0 до 2^31-1 100-мегайбайтовый файл (10 миллионов чисел), перемолола (с теми же ограничениями памяти) за 7 секунд. Тормоз этот ваш питон. Хотя такое ощущение, что я мерил скорость жёсткого диска, а не джавы.

Собственно померил - так и вышло. 4 секунды идёт первый этап (чтение по 1 миллиону чисел, сортировка, запись), типичные значения - 94 ms, 84 ms, 201 ms соответственно. Ну и второй этап 3 секунды - там сложно что-то померить отдельно, но в целом, думаю, как раз одну секунду суммарно он сортирует (т.е. грузит процессор) он на первом этапе, 100 мегабайтов читает и 100 мегабайтов пишет. На втором этапе точно так же - 100 мегабайтов читает и 100 мегабайтов пишет, в сумме как раз 3 секунды выходит с практически нулевой загрузкой процессора. Итого полезной работы 1 секунда из 7, остальное на IO тратится.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)

Ох, как же царь тут всех сливает, прямо таки утро мне сделал. И дело даже не в коде, а в том, что оппонент банально за свои слова ответить не может. Такой-то юлеж, такие-то передергивания. Каждый царский пост мне лучше любого учебника.

kremator666
()
Ответ на: комментарий от kremator666

лучше любого учебника.

Спалилось школоло. Все равно тебе придется идти учить уроки.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.