LINUX.ORG.RU
Форум — Development  

[ФП] Примеры работы с БОЛЬШИМИ файлами


5

0

Всем привет, хочу продолжить тему работы с файлами в ФП. Тут недавно были примеры, но очень тривиальные, прочитать-записать. Вопрос такой, как в ФП-языке считать в память огромный файл как двумерный массив, и чтобы он а) занимал в памяти столько же места сколько на диске б) доступ к элементам был быстрый (О(1))?

Предистория такова, мы обрабатываем изображения с телескопов, там счёт идёт на сотни мегапикселей, и глубина пикселя 32 бита. Так что типичное изображение ~ два с половиной гигабайта, для этих целей специально собраны счётные узлы с 4 Гб RAM. Это чтобы изображение поместилось целиком в память, и оставалось на промежуточные буферы для накопления результатов. Естественно, все рассчёты написаны на Си и С++, работает быстро, памети хватает. Но код некрасивый, много повторяющихся конструкций и т.п. Народ в основном закостенелый из старшего поколения, ничего кроме Си и фортрана не знают, а я хочу попробывать более современные языки.

Так что буду благодарен за примеры чтения массивов для Haskell и особенно Scheme. И чтобы можно было посмотреть, сколько памяти реально израсходовано. Спасибо!

 ← 1 2 3 4 →
Ответ на: комментарий от LamerOk

Не имеют. page fault в слычае mmap — это ситуация, когда запрашивамой страницы не оказалось в памяти. Последовательно двигаясь по отображенному файлу, мы вынуждаем ОС генерировать эти самые page fault'ы, подгружая следующие части файлы и выгружая предыдущие. Приложение при таком раскладе вообще никак не контролирует объем потребляемой им памяти, Забивая дисковый кеш и ухудшая общую производительность и отзывчивость системы вцелом.

При использовании окна для чтения, ОС тоже может выделять страниц со сброшенным битом присутствия в памяти. Однако при повторном чтении эта страница уже будет иметь «прописку» в памяти и никаких исключений не возникнет. И это не говоря тем, что объем RSS уже будет явно ограничен размером окна.

И, да, read может быть «медленнее» mmap только если читать маленькими блоками.

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

Почти все перечисленные эффекты можно так или иначе обойти или свести к допустимому минимуму в зависимости от ОС и её расширений mmap(). Но если алгоритмы могут работать по окну за проход, то трогать mmap() смысла особого не имеет.

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

> Однако при повторном чтении эта страница уже будет иметь «прописку» в памяти

подгружая следующие части файлы и выгружая предыдущие.


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

Ты про page cache почитай для общего развития, прежде чем фигню на форуме пороть. )))

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

>Так я не понял, у тебя при чтении без ммапа память вырастет в десять раз и ничего не надо выгружать, или это линуксовый ммап по твоему мнению выгружает неиспользованные страницы при свободной памяти от нехер делать?

Ну да, я наивненько сказал. На самом деле, при нехватке памяти включится тот же самый механизм LRU для определения того, кто же сейчас покинет оперативку. Но в случае с mmap'нутым файлом, страницы будут попадать не в своп, а «в никуда» (это, кстати, предположение). То есть, они будут тупо помечаться как отсутствующие в памяти и писаться обратно в файл, если они dirty.

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

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

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

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

> А с программной - mmap будет удобнее.

К тому же, если внимательно почитать man на предмет флагов для mmap - ещё и параллельно с основным алгоритмом.

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