Оптимальный размер буфера для чтения/записи файла

← →
DevilDevil © (2013-01-27 14:51) [80]

> картман © (27.01.13 11:53) [76]
> это была критика твоего подхода, извини, если грубо получилось,
> впредь постараюсь избегать подобного... Но если ты задашь
> вопрос "как составить идеальный план выполнения запроса
> - раз и навсегда", то я не смогу удержаться

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

> Pavia © (27.01.13 12:47) [78]
> С одной стороны, результаты коррелируют с результатами других
> тестов с другой авторитетное мнение что это не кэш промахи, а ЦПУ слабый.

распиши поподробнее пожалуйста

> Запись я не тестировал. Но побочным результатом тестом на
> чтение было то, что 64 КБайта для записи не является эффективным.

не совсем понял
ты имеешь ввиду, "64кб на чтение" ?
сравнивал ли ты 64/256/1024 ?

← →
QAZ10 (2013-01-27 15:04) [81]

> распиши поподробнее пожалуйста

есть курсы от Intel по оптимизации ПО , там много чего расписано, правда есть одно но, компилятору дельфи до этого далековато, а автоинтеллект заложеный в процессоры сам может и несправляца со всеми поделками скомпилеными под I386

← →
Аббат Пиккола (2013-01-27 15:14) [82]

2 DevilDevil ©

А можно полюбопытствовать о цели самой программы?
Обычно откровенная информация на эту тему многое сразу проясняет.

← →
картман © (2013-01-27 15:24) [83]

> DevilDevil © (27.01.13 14:51) [80]

ты ж на будущее делаешь - через несколько лет поменяются железки, возможно, ОС будет по-другому работать с файлами - как можно обеспечить 100% эффективность на разных системах?

← →
DevilDevil © (2013-01-27 15:37) [84]

> QAZ10 (27.01.13 15:04) [81]

меня интересовал опыт человека относительно кэшмисс

> Аббат Пиккола (27.01.13 15:14) [82]
> А можно полюбопытствовать о цели самой программы? Обычно
> откровенная информация на эту тему многое сразу проясняет.

я пишу (уже написал) модуль, который смогу использовать для любых задач связанных с потоковым чтением и записью данных. Вопрос - каким должен быть оптимальный размер буфера для записи и чтения файлов. Остановил свой выбор на 256кб и 64кб. Возможно со временем изменю

> картман © (27.01.13 15:24) [83]
> ты ж на будущее делаешь - через несколько лет поменяются
> железки, возможно, ОС будет по-другому работать с файлами
> - как можно обеспечить 100% эффективность на разных системах?

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

← →
Аббат Пиккола (2013-01-27 15:45) [85]

для любых задач связанных с потоковым чтением и записью данных

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

← →
Аббат Пиккола (2013-01-27 15:47) [86]

Честно говоря я перестал понимать, чего именно Вы хотите. Что за такое "потоковое чтение"? А что, бывает какое-то другое чтение?

← →
картман © (2013-01-27 15:57) [87]

Если автор и книга: http://www.williamspublishing.com/Books/5-8459-0912-0.html - авторитет, то можно полистать 5-главу

← →
DevilDevil © (2013-01-27 16:09) [88]

> Аббат Пиккола (27.01.13 15:47) [86]
> Честно говоря я перестал понимать, чего именно Вы хотите.
> Что за такое "потоковое чтение"? А что, бывает какое-то
> другое чтение?

Например чтение XML из документов "Office Open XML"
тогда нужно потоком читать файлы в формате Zip
нужные XML-"записи" потоком декодировать из сжатого формата в расжатый
расжатые XML тоже нужно (можно) читать потоком, ибо XML по размеру вполне могут превышать гигабайты
ну и наконец если алгоритм рассчитан на кодировку например utf8, то в случае иной кодировки (utf16, windows-1251) нужно опять таки декодировать данные в нужную кодировку

получается такая цепочка:
файл --> UnZip --> XML --> нужный формат

Можно не париться и сразу всё разворачивать ОЗУ. Но на больших объёмах, ты рискуешь лишить пользователя памяти, производительности (файл подкачки) или вообще выдать EOutOfMemory.

С другой стороны можно организовать потоковое буферизированое чтение и эффективно обойтись минимальным потреблением ОЗУ хотя бы на этапе чтения данных

← →
Аббат Пиккола (2013-01-27 16:11) [89]

В спектре слов максимум на слове "авторитет" детектед.

Интересно, а как найти авторитет, который бы помог с выбором нужного авторитета? Или на этой стадии уже вполне рабочей следует считать методику "гадания на кофейной гуще"?

Хотя нет. Я, кажется, понял. Для того чтобы избежать дурной бесконечности авторитетов, неминуемо ведущей нас в индуктивную пропасть, можно их организовать в иерархию. Авторитеты более низкого уровня получат легитимность от авторитетов более высокого уровня. На самом верху будет сидеть главный авторитет, придающий легитимность всем нижестоящим по иерархии. А сам он будет получать легитимность от самого Господа. Ну как Папа Римский. Так задача вроде бы имеет решение. По крайней мере мне, как аббату, такое решение знакомо.

← →
Аббат Пиккола (2013-01-27 16:14) [90]

"нужные XML-записи" в зипе это что такое?

← →
Аббат Пиккола (2013-01-27 16:28) [91]

Извиняюсь за оффтоп [89]

Чем-то похожим джава постоянно занимается. Правда там куча мелких файлов засовывается в общий зип ради ускорения чтения, а не ради экономии места. А здесь как дело обстоит с размерами самих файлов? Они в основном мелкие или в основном крупные? Засовываются ли много мелких в "общий зип" или каждый лежит в файловой системе отдельно? Каков процент таких файлов в общей статистике обращений к файлам? Все это гораздо сильнее влияет на конечную производительность, нежели оптимизация конвертации отдельно взятого файла. И вообще, верна ли изначальная посылка о том, что поток чтения - "самое узкое место в этой системе"?

> Аббат Пиккола (27.01.13 16:28) [91]
> И вообще, верна ли изначальная посылка о том, что поток
> чтения - "самое узкое место в этой системе"?

я периодически сталкиваюсь с разными задачами (системами)
в любом случае потоковое чтение/запись - всегда одно из самых узких и рутинных мест при обработке большого объёма данных

> За последние 10 лет принципиально ничего не изменилось.
> Если поменяется - изменю константы или в целом подход по
> определению оптимального размера. Но в любом случае нужно
> основывать свои выводы на каких авторитетных умозаключениях

Очень сильно поменялось. Появился Win7, он стал кэшировать файлы. Теперь почти вся не используемая память отводиться под дисковый кэш.
Появились SSD. Они могут выполнять 10000-40000 операций ввода вывода в секунду против HDD диска который 60-150.

> ALL ©

В общем уговорили, сделал буфер в 256кб и на запись, и на чтение :)

> DVM ©

Готов к тестированию
Как раз можно будет поиграться с размером буфера на разном оборудовании, если здешним участникам будет интересно

Оптимальный размер буфера для чтения/записи файла Найти похожие ветки