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

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]666
2014-06-12 21:11 (ссылка)
операции вроде бы в основном с кешем будут, т.е. с памятью

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

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


[info]phantom
2014-06-12 22:04 (ссылка)
Не делают, но у меня выставлен лимит в половину рамы. Т.е. довольно большая уверенность, что всё будет в памяти.

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


[info]phantom
2014-06-13 00:19 (ссылка)
Собственно, функции-то я написал - my-write, my-read, грубо говоря, и теперь можно в одну строчку грузить/выгружать. Проблема не в том, что я не знаю, как их написать. Проблема в том, что мне их, вообще, пришлось писать.

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


[info]666
2014-06-13 03:00 (ссылка)
может дело в том что чтение-запись файла это нетривиальная хуйня, очень по-разному можно реализовать
с учётом одновременности доступа, контроля ошибок, лок-анлок, и тд

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


[info]phantom
2014-06-13 10:07 (ссылка)
Ой. Я тебя умоляю. Проще этого, наверное, хелловорд только.

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


[info]666
2014-06-13 15:09 (ссылка)
а ты посмотри как реализовано какое-нибудь стандартное копирование файлов, казалось бы - прочитал да записал, а оно от тыщи строк на си

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


[info]phantom
2014-06-13 22:22 (ссылка)
Ну, посмотрел - cp из coreutils. Ядро-то там десяток-другой строк. Всё остальное - отработка опций командной строки. Немного обработка ошибок и всяких исторических квирков. Плюс рекурсивное копирование директорий. И не тыщи, а три-четыре тысячи, со всем мутью за десятки лет накопленной.

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


[info]666
2014-06-13 22:54 (ссылка)
так а что из этих 4к строк должно быть в желаемых стандартных либах на скриптоязыке, а что не должно

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


[info]phantom
2014-06-14 02:46 (ссылка)
Для меня желательно, чтобы можно было файл загрузить в одну строку и выгрузить в одну строку.

В стандартной либе реализация этого должна быть в пару десятков строк.

Вот, я смотрю в стандартной либе рэкета, как раз чтение там - 20 строк, включая обработку ошибок.

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


[info]phantom
2014-06-13 22:29 (ссылка)
И вообще, "тыщи строк" - обычно показатель тривиальности. Вот в методе Рунге-Кутта всего-то < 10 строк, но в каждую вложены десятки, если не тысячи человеко-лет труда.

Или вот ещё проще нетривиальный пример в три строки. Обменяй значения двух (целочисленных) переменных, не прибегая к третьей переменной.

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


[info]666
2014-06-13 23:16 (ссылка)
ну так можно сказать, что в первую букву вложен миллиард лет, а copyfile написали всего за 10

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


[info]phantom
2014-06-14 02:47 (ссылка)
Это неверно, т.к. я приводил конкретно работу над алгоритмом Рунге-Кутта, а не "подготовку" и исторический процесс, приведший к появлению компьютеров, алгоритмов и Рунге-Кутта.

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


[info]666
2014-06-14 05:08 (ссылка)
не верно, потому что нет связи между человеко-годами и сложностью результата в строчках

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

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


[info]phantom
2014-06-14 12:04 (ссылка)
Ну да, это я загнул, нету такой связи.

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


[info]phantom
2014-06-14 13:16 (ссылка)
Однако, когда хвалятся, мол, "мы нахуярили 250 млн строк кода", это обычно означает, что там везде копипаста.

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


[info]ketmar
2014-06-14 16:10 (ссылка)
you are terribly wrong. ты, например, обрабатываешь EINTR после read()? а почему? а ты в курсе, что если у нас какая-нибудь сетевая fs через fuse, то… и так далее. а ошибки close() кто-нибудь вообще обрабатывает?

кстати, приветмир — тоже очень нетривиальная программа. обычный сишный пример с printf() — уже неправильный: опять забыли обработать ошибки i/o.

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


[info]ketmar
2014-06-14 16:13 (ссылка)
p.s. а вот этот приветмир, кстати, правильный:
import std.stdio;
void main () {
  writeln(`Hello, world`);
}

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


[info]phantom
2014-06-14 21:14 (ссылка)
С ума сойти, какая нетривиальная программа, хехе.

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


[info]ketmar
2014-06-14 22:08 (ссылка)
как ни странно. тем не менее, дишный вариант — единственный, который нормально обрабатывает ошибки без дополнительных телодвижений.

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


[info]phantom
2014-06-14 22:48 (ссылка)
А какие, вообще, ошибки имеются в виду? Можно поподробнее? Я ж не системный программист, по сути.

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


[info]ketmar
2014-06-14 22:58 (ссылка)
ошибки i/o: вообще-то tty может и отсутствовать. или сломаться посреди дороги. printf(), конечно, об этом просигнализирует как минимум несовпададающим количеством выведеных символов и того, сколько надо было вывести, но:
а) почти никто не проверяет результата printf();
б) если там что-то сложнее простой строки, то количество символов не угадаешь.

D в этом плане консервативен, и просто кинет исключение. непойманное исключение ведёт, натурально, к завершению программы с кодом ошибки. я считаю, что подход «для того, чтобы наплевать на ошибку, надо напрягаться больше, нежели для того, чтобы не наплевать» идеологически более правильным.

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


[info]phantom
2014-06-14 23:04 (ссылка)
В смысле надо писать main { return printf("hello world"); } вместо main { printf("hello world"); } ?

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


[info]ketmar
2014-06-14 23:23 (ссылка)
и это тоже фигня, на самом деле. да ещё и неправильная, потому что printf() возвращает или отрицательное число, или количество выведеных символов, а main() при успехе должен возвращать 0. поэтому для полной корректности надо делать return (printf("hello world\n") == 12 ? EXIT_SUCCESS : EXIT_FAILURE). не забывая о том, что волшебное число 12 следует держать в синхронизации с количеством символов, которые должны быть напечатаны.

да-да, EXIT_FAILURE — это единственный переносимый способ вернуть правильный код "пиздец" из main().

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


[info]phantom
2014-06-15 00:12 (ссылка)
Ну, такой ебанизм, наверное, только в языках без исключений.

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


[info]ketmar
2014-06-15 00:17 (ссылка)
тем не менее, оно есть. и, как оказывается, приветмир — программа вовсе не такая тривиальная. поэтому никогда не надо приводить её в качестве примера «простейшей программы», гыг.

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


[info]phantom
2014-06-15 01:18 (ссылка)
Ну, можно на ассемблере ещё написать её. Тогда ебаться ещё больше надо будет, и что? Я не получаю удовольствия от низкоуровневой ебли.

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


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

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

я, собственно, к тому, что привычка забивать на такие штуки однажды вылезет боком. а если ты думаешь о таком на уровне рефлексов, то, например, ставишь assert()'ы после вызова read(), хотя документация и обещает, что read() отработает нормально.

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


[info]phantom
2014-06-15 04:07 (ссылка)
Ну и хуй с ним. Вылезет - починим. И сколько б ты ни тужился, пытаясь написать bulletproof код с первого захода, всё равно уйдут годы, чтобы он стал зрелым.

Это и в жизни проявляется. Некоторые накупят страховок, например, на скалолазание не ходят или ещё чего. Жизнь в страхе, не жизнь даже, а так, существование. Годы унылой жизни, а потом всё равно в могилу.

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

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


[info]ketmar
2014-06-15 10:40 (ссылка)
ну, я тут где-то писал про настоящих сварщиков. у настоящих код, который забивает на ошибки, результатом считать не принято. профдеформация. забавно сказывается даже на throwaway utilities, где совершенно автоматически пишешь проверки даже на облажавшийся malloc(), хотя точно знаешь, что утилита одноразовая, и что больше пары килобайт она не выделяет.

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


[info]phantom
2014-06-15 15:24 (ссылка)
Если ты понимаешь, что это психическое отклонение, то ты можешь попытаться его подлечить.

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


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

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


[info]phantom
2014-06-15 15:37 (ссылка)
- Вы страдаете от мании величия?
- Что вы, доктор, я ею наслаждаюсь!

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


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