Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет superhuman ([info]superhuman)
@ 2014-06-12 10:07:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
В высокоуровневых ЯП обычно есть функции, чтобы прочесть файл в байт-массив (байт-строку) и, наоборот, сбросить массив в файл. Идея в том, чтобы не париться со всякими буферами хуюферами, и в одну строчку такую задачу решать.

Понадобилось мне нонче iso-шки читать как блобы и переколбашивать их. Выясняется, что на больших файлах эти самые функции не работают! (в трёх ЯП, как минимум) В racket-е (с чего я начал), читается не более 380 мб, записывается не более 700 мб, - причём без всяких эксепшенов.

Потом позырил дотнет - там до .net-4.5 вообще никакие объекты не могли быть больше 2 гб в памяти. Нахуйя мне 32 гб рамы, спрашивается? Ну ладно, в 4.5 они типа поддерживают больше, но индексы в массивах всё равно 32-битного типа, т.е. байт-массив всё равно не может быть больше 2 гб. Ебанись.

Посмотрел байт-строки haskell-а, но там тоже индекс типа 32-битного integer-а. Хотел посмотреть ещё в J, но в онлайне не нашёл соответствующей документации. Хотя и пишут, что эта система "true 64 bit", но доверия уже никому нет. Надо будет попробовать всё же, J и сам по себе интересен.

Короче, вернулся к схеме и хуярю этими самыми чанками / буферами. Так-то работает, и не так много онанизма, в схеме всё-же индексы могут быть большие. Но всё равно, ощущение от этого кодостиля, блядь, что это 70-й год примерно.


(Читать комментарии) - (Добавить комментарий)


[info]ketmar
2014-06-15 00:32 (ссылка)
>Оно должно было получиться
хм. а что говорит об этом документация? а что она говорит о том, что получится, если в процессе чтения придёт сигнал? если ничего, то и либа, и документация — говно.

>Почему же одинаковые тормоза, если я читаю последовательно и сразу, а в mmap там
>получится фрагментированное (в памяти) кеширование и не сразу?

потому что:
а) на диске файл всё равно лежит фрагментами в большинстве случаев;
б) я уверен, что никаких хинтов ОС при открытии файла ты не давал, и ОС не в курсе, что ты собираешься его просто последовательно прочитать; при таких раскладах mmap() лучше, потому что таки сделает readahead (ну, так сделано, хоть это и не важно, потому что…)
в) …потому что при использовании mmap() ты избавляешься от лишнего буфера, которым является дисковый кэш ОС. надеюсь, не будем спорить о том, что чем меньше промежуточных буферов — тем лучше?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2014-06-15 01:45 (ссылка)
Документация не говорит ничего, но подразумевается, что будет эксепшен. И вообще, это ж не юниксовая библиотека, а кросс-платформенная. Поэтому такие специфичные вопросы и не нужно рассматривать.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2014-06-15 01:55 (ссылка)
такие специфичные вопросы всегда надо рассматривать, особенно в кроссплатформенных библиотеках. потому что если автор пишет под одну платформу, то я склонен считать, что он её более-менее знает. а вот если под несколько — то он запросто может забыть специфику одной из них. тем более, если некоторые специфические ситуации возникают настолько редко, что их за кучу лет можно ни разу не увидеть.

вот в таком случае я буду намного более спокоен, если автор сделает мне одолжение и покажет, что он не забыл о маловероятном событии, которое может произойти на одной из платформ. ибо преобразование сигнала в исключение — операция и сама по себе очень нетривиальная, мало кто может сделать это правильно (хотя тут больше виновата сама концепция сигналов, конечно; bwah, я сам делаю это неправильно почти везде). а если это вообще обработчик сигнала, который исключений не кидает, то всё становится ещё веселей.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2014-06-15 03:55 (ссылка)
Ну, да, вполне.

(Ответить) (Уровень выше)


(Читать комментарии) -