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

← →
DevilDevil © (2013-01-25 12:38) [0]

Здравствуйте, уважаемые форумчане

Периодически сталкиваюсь с задачами потокового чтения/записи файлов. Выбираю разные подходы и размеры буферов. И в последнее время всё чаще возникала мысль написать что-то более-менее универсальное.

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

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

будут ли другие мнения ?
оптимальный размер буфера на запись ?

p.s. сегодня попробовал прочитать файл размером 200мб через CreateFileMapping - скорость в 2 раза медленнее, чем с предварительной буферизацией в куче. Readonly. Обращение к памяти стабильно по возрастанию

← →
DevilDevil © (2013-01-25 12:50) [1]

кто то говорит 16кб, кто то говорит 32кб
в TCustomZlibStream (ZLib, Delphi 7) используется буфер в 64кб

← →
Sha © (2013-01-25 12:58) [2]

Зависит от алгоритма обработки считанных данных.
Если будешь обрабатывать данные очень быстро, то и 64k будет достаточно.

Что касается FileMapping, то даже размер мапы в 64k способен обеспечить примерно ту же производительность, что и IOCompletionPort.

← →
DevilDevil © (2013-01-25 13:07) [3]

> Sha © (25.01.13 12:58) [2]

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

← →
QAZ10 (2013-01-25 13:08) [4]

> Rouse_ говорит, что для чтения оптимальный размер буфера 256кб

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

← →
QAZ10 (2013-01-25 13:09) [5]

> допустим работа с файлами - самое слабое место алгоритма

заодно можеш сделать в 2 потока - пока читается второй блок с диска обрабатываешь первый и тд

← →
Sha © (2013-01-25 13:36) [6]

> DevilDevil © (25.01.13 13:07) [3]

блок 64k, IOCompletionPort

← →
Дмитрий С © (2013-01-25 13:38) [7]

> DevilDevil © (25.01.13 13:07) [3]
> > Sha © (25.01.13 12:58) [2]
> допустим работа с файлами - самое слабое место алгоритма
> меня интересует самый оптимальный подход в плане производительности

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

← →
Sha © (2013-01-25 13:43) [8]

> QAZ10 (25.01.13 13:08) [4]

Я правильно понял, мы говорим о работе с файлом, которого нет в кеше?
HD хранит в своем железном буфере данные, над которыми прошла головка.
Важно успевать их забирать, пока их не затерли новые данные.

Причем тут размер файла?

← →
Sha © (2013-01-25 13:45) [9]

> Дмитрий С © (25.01.13 13:38) [7]
> Для некоторых задач я загружал 100-200 метровые файлы полностью в память для обработки.

Ну и что?
Я полностью обрабатываю файлы за то же время.

← →
Дмитрий С © (2013-01-25 13:47) [10]

> Я полностью обрабатываю файлы за то же время.

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

← →
Sha © (2013-01-25 13:50) [11]

> Дмитрий С © (25.01.13 13:47) [10]

значит, твоя задача отличается от задачи автора вопроса

← →
QAZ10 (2013-01-25 13:50) [12]

> Причем тут размер файла?

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

← →
Sha © (2013-01-25 13:56) [13]

Мы ведь не файлах меньше железного буфера?
Ясен пень винда будет влиять. Но не это не первая скрипка.

← →
brother © (2013-01-25 14:07) [14]

имхо нужно учитывать геометрию диска...

← →
DevilDevil © (2013-01-25 14:15) [15]

> Sha © (25.01.13 13:36) [6]

вот ты говоришь 64кб
а Rouse_ и QAZ10 говорят 256кб
и что лучше ?

← →
Slym © (2013-01-25 14:23) [16]

буфера должны быть третьего размера! ну и геометрия чтоб тоже была :) С пиатницой Всех

← →
Sha © (2013-01-25 14:25) [17]

считаешь, есть магический размер, пригодный для любого алгоритма?

← →
DevilDevil © (2013-01-25 14:35) [18]

> Sha © (25.01.13 14:25) [17]

дело не в алгоритме, а оптимальности для железа/драйверов/ОС

← →
QAZ10 (2013-01-25 14:36) [19]

> и что лучше ?

нублин затесть и так и так и по другому

> Sha © (25.01.13 13:56) [13]

я когда тестил свои диски по отдельности а потом в рейде с разным размером стрипа
то например при файлах 128мб и выше практически линейная скорость при буферах от 64кб до 8мб а на файлах 64мб и ниже уже ёлочно-ступенчатая с пиком в районе кокраз 256 кб буфера

← →
картман © (2013-01-25 14:43) [20]

> нублин затесть и так и так и по другому

и собирай статистику, да программно подстраивай размер под текущие систему и задачи

← →
DevilDevil © (2013-01-25 14:52) [21]

> нублин затесть и так и так и по другому

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

← →
Sha © (2013-01-25 15:21) [22]

> DevilDevil © (25.01.13 14:35) [18]
> > Sha © (25.01.13 14:25) [17]дело не в алгоритме, а оптимальности
> для железа/драйверов/ОС

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

> я хочу перенять опыт

развернутый ответ в пятницу? )

← →
DevilDevil © (2013-01-25 15:54) [23]

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

← →
QAZ10 (2013-01-25 16:23) [24]

> DevilDevil © (25.01.13 15:54) [23]

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

← →
DevilDevil © (2013-01-25 16:49) [25]

> QAZ10

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

← →
QAZ10 (2013-01-25 16:55) [26]

дык при записи такой же буфер оптимален как и на чтение только запись полюбому будет медленней раза в два

← →
DevilDevil © (2013-01-25 17:01) [27]

> QAZ10

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

← →
QAZ10 (2013-01-25 17:03) [28]

вот бери 256 и иди работай :)

← →
Павиа (2013-01-25 17:15) [29]

Бери 1 MByte на чтение и запись. И не парь мозги. На ближайшие лет 10 хватит.

← →
DevilDevil © (2013-01-25 18:10) [30]

> QAZ10 (25.01.13 17:03) [28]
> Павиа (25.01.13 17:15) [29]

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

← →
QAZ10 (2013-01-25 18:18) [31]

> DevilDevil © (25.01.13 18:10) [30]

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

← →
DevilDevil © (2013-01-25 18:26) [32]

> QAZ10 (25.01.13 18:18) [31]

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

← →
Pavia © (2013-01-25 18:40) [33]

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

Я же тебе не 10-100 МБайт советую. Во вторых я же не с потолка взял, а после тестирования.

← →
Дмитрий С © (2013-01-25 19:04) [34]

А разве сама ОС не закеширует какое-то количество файла при чтении или записи?

P.S. Может между делом кто-нибудь подскажет как во FreePascal сделать Flush записанному файлу (os linux)?

← →
Rouse_ © (2013-01-25 19:10) [35]

Я говорил про 256 Кб потому что делал тестирование на нескольких сотнях рабочих станций, выборка получилась достаточная ибо ОС, кол-во памяти на борту, сами хардешники и их комбинации с райдами сильно отличались. Данный размер буфера показал наибольшую производительность при чтении. Задача была проверить некий набор баз на их целостность через рассчет контрольной суммы файлов. Объем баз варьировался, но обычно был в районе 8-12 гигов. На запись не тестировал - не возникало такой задачи, поэтому тут ничего сказать не смогу.

← →
DevilDevil © (2013-01-25 19:30) [36]

> Rouse_ © (25.01.13 19:10) [35]
> На запись не тестировал - не возникало такой задачи, поэтому
> тут ничего сказать не смогу.

вот это жалко :)
но я попробую у себя в тестах и 64кб и 256кб

← →
Pavia © (2013-01-25 19:42) [37]

> Я говорил про 256 Кб потому что делал тестирование на нескольких
> сотнях рабочих станций,

Ключевое слово делал. Да было 256, сейчас чаще всего 512. А 1024 я посоветовал на будущее.

← →
Rouse_ © (2013-01-25 19:48) [38]

> Pavia © (25.01.13 19:42) [37]
>
> > Я говорил про 256 Кб потому что делал тестирование на
> нескольких
> > сотнях рабочих станций,
>
> Ключевое слово делал. Да было 256, сейчас чаще всего 512.
>

Ну если на последние два месяца что изменилось тогда ой :) Тестирование производилось от буфера в 2^12 (4 Кб) с изменением кратности до 2^25 (32 мегабайта). Пик производительности был на 2^18 (256 Кб), дальше производительность падала.

← →
Pavia © (2013-01-25 20:10) [39]

> дальше производительность падала.

Там падение не такое большое. А вот прирост может оказаться большим.

← →
Rouse_ © (2013-01-25 20:12) [40]

> Pavia © (25.01.13 20:10) [39]

Ну у меня это ничем не подтвердилось.

← →
DVM © (2013-01-25 20:37) [41]

> DevilDevil © (25.01.13 12:38)

>
> Периодически сталкиваюсь с задачами потокового чтения/записи
> файлов. Выбираю разные подходы и размеры буферов. И в последнее
> время всё чаще возникала мысль написать что-то более-менее
> универсальное.
>

Советую оформить буферизованный ввод-вывод в виде класса-наследника TStream (по-умному декоратора, обертки), тогда можно будет сделать буферизованный ввод-вывод для любого другого класса-потока, в. том числе и TFileStream. Размер буфера можно сделать свойством или передавать в конструктор. Максимальный размер буфера я бы выбрал 64к, минимальный 4к.

← →
QAZ10 (2013-01-25 20:52) [42]

> тебе говорит что нибудь такое понятие как "кэшмисс" ?

ну ты загоняешся бро, непотеме ;)
при чем тут кэш чтения файла и кэшь проца да еще и с компилятором дельфи

← →
brother © (2013-01-26 04:00) [43]

Розыч, прокомментируй [14] об этом размышления были?

← →
DevilDevil © (2013-01-26 09:29) [44]

> DVM © (25.01.13 20:37) [41]

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

к тому же логика работы буферезированого записывателя отличается от логики буферизированого читателя. а у TStream есть оба метода + определённый обвес типа Seek, Position, Size, всё в типах int64

вот например как можно будет записать TRect:
var R: TRect; begin ... if (DataWriter.Margin >= sizeof(TRect)) then begin // обычная запись в буфер данных PRect(DataWriter.Current)^ := R; inc(integer(DataWriter.Current), sizeof(TRect)); dec(DataWriter.Margin, sizeof(TRect)); end else begin // умная функция с распределённой записью DataWriter.Write(@R, sizeof(TRect)); end; end;

← →
DVM © (2013-01-26 10:16) [45]

> DevilDevil © (26.01.13 09:29) [44]

> я решил воспользоваться более тонкими материями, более низким
> уровнем
> ибо вызов Read/Write на каждый чих может негативно сказаться
> на производительности

Ты только представь разницу между скоростями на которых работает процессор и жесткий диск. Она огромна. Это имхо не то место где можно получить выигрыш. Зато получим выигрыш в удобстве использования. Плюс не привязываемся к файлам. Ну это если ты действительно хочешь сделать нечто универсальное.

> к тому же логика работы буферезированого записывателя отличается
> от логики буферизированого читателя. а у TStream есть оба
> метода + определённый обвес типа Seek, Position, Size, всё
> в типах int64

Без проблем можно реализовать обе логики в одном или двух классах, перекрыв соответствующие методы. На практике TStream оказывается много удобнее, чем что-то свое, т.к. поддерживается всеми и VCL и сторонним кодом.

← →
DVM © (2013-01-26 10:19) [46]

> DevilDevil © (26.01.13 09:29) [44]

> ибо вызов Read/Write на каждый чих может негативно сказаться
> на производительности

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

← →
DVM © (2013-01-26 10:34) [47]

> вот например как можно будет записать TRect:

На мой взгляд, запись всех необходимых типов удобнее оформить в виде class helper для TStream, тогда все стримы, в том числе и наш буферизованный получают возможность писать/читать нужные нам типы данных.

Если же у нас совсем древняя версия Delphi и class helper-ы не поддерживаются, тогда имеет смысл опять таки воспользоваться паттерном декоратор и в класс такого декоратора добавить все нужные нам методы. Опять таки все стримы получают возможность писать/читать наши типы данных.
Лучше чуть-чуть пожертвовать скоростью, зато потом получить чистый и наглядный код, удобный в поддержке и очень гибкий в использовании. Это к теме универсальности.

← →
DevilDevil © (2013-01-26 11:09) [48]

> DVM © (26.01.13 10:16) [45]

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

в целом - не вопрос, можно что-нибудь потестировать, мне интересно!
но давай денька через 4
потому что как раз сейчас я занят другим тестовым приложением, где надо выжать максимум скорости :)

← →
Rouse_ © (2013-01-26 13:20) [49]

> brother © (26.01.13 04:00) [43]
> Розыч, прокомментируй [14] об этом размышления были?

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

← →
DVM © (2013-01-26 13:42) [50]

> DevilDevil © (26.01.13 11:09) [48]

> ты рассуждаешь как типичный программист

ясное дело, я и есть программист, по крайней мере мне так кажется :)

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

Вряд ли слабым местом при работе именно с файлами окажется TStream, но дело твое конечно.

> но давай денька через 4

давай

← →
DevilDevil © (2013-01-26 14:00) [51]

> DVM © (26.01.13 13:42) [50]

придумай пока пожалуйста достойную задачу
варианты кстати сюда можно выкладывать )

← →
Аббат Пиккола (2013-01-26 14:23) [52]

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

← →
DevilDevil © (2013-01-26 14:39) [53]

> Аббат Пиккола (26.01.13 14:23) [52]

потому что у меня нет такого огромного количества разнообразного оборудования, чтобы после тестов на котором придти к однозначному мнению по вопросу

← →
brother © (2013-01-26 16:07) [54]

> размер буфера кратен размеру файлового кластера

я о том же, только вот вроде как предела нет)

← →
Rouse_ © (2013-01-26 17:29) [55]

> brother © (26.01.13 16:07) [54]
> я о том же, только вот вроде как предела нет)

Не понял, предела чему?

← →
QAZ10 (2013-01-26 18:11) [56]

Удалено модератором

← →
brother © (2013-01-26 18:47) [57]

> Не понял, предела чему?

> в технических блогах на MSDN нашел упоминания об этом, там
> утверждалось что наибольшая производительность будет если
> размер буфера кратен размеру файлового кластера.

а о конкретном рекомендуемом размере разговора нет, значит он может быть бооооольшой) (да шутю я)

← →
DVM © (2013-01-26 19:13) [58]

Удалено модератором
Примечание: не цитируем...

← →
Rouse_ © (2013-01-26 20:38) [59]

> QAZ10 (26.01.13 18:11) [56]
> это минимальная единица чтения\записи должна быть размером
> в кластер, а не буфер

Слово "кратность", стало быть ты пропустил?

> ну ты загоняешся бро, непотеме ;)

Так, устаю я от тебя. Прими к сведению, лурковский и молодежный сленг у нас не приветствуются.

> а о конкретном рекомендуемом размере разговора нет, значит
> он может быть бооооольшой)

По поводу кратности? Ну в принципе да. Вон Pavia тоже утверждает и мне нет смысла ему не верить, но просто у меня не прошли тесты на озвученных им объемах, поэтому я займу нейтральную позицию.

← →
Аббат Пиккола (2013-01-26 21:18) [60]

DevilDevil © (26.01.13 14:39) [53]
> Аббат Пиккола (26.01.13 14:23) [52]

потому что у меня нет такого огромного количества разнообразного оборудования, чтобы после тестов на котором придти к однозначному мнению по вопросу

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

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

← →
Аббат Пиккола (2013-01-26 21:20) [61]

А для пущей важности ввел бы в программу не только настройку, но и ТЕСТ, позволяющий на конкретном устройстве произвести автонастройку. Хотя, сдается мне, ради каких-то 10% выигрыша все это не имеет ровно никакого смысла. А задачи, где 10% важны (расчет полета баллистических ракет противника) незачем рассчитывать на какой попало устройство - для таких задач устройство с нужной производительностью можно просто потребовать.

← →
DevilDevil © (2013-01-26 21:26) [62]

> Аббат Пиккола

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

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

← →
Pavia © (2013-01-26 22:26) [63]

> Хотя, сдается мне, ради каких-то 10% выигрыша все это не
> имеет ровно никакого смысла.

Дело в том что выигрыш и проигрыш при чтении может доходить до 2 раз (±6 db).

И одно дело перекодировать файл 15-30 минут, а другое 3 минуты. (Правда это ещё нестрашно, а вот соседи ещё 2 часа на CD пишут)

> можно просто потребовать.

Не знаю как у Вас, а у нас и наших клиентов экономика плановая. И пока старое не сломается не заменят. Либо морально не устареет, а это 10 лет.

Как итог приходиться планировать скорость алгоритма, специфика работы.

← →
Аббат Пиккола (2013-01-26 23:18) [64]

Я предложил ввести настройку (автонастройку) в программу, если реально все так критично. Тогда вместо того чтобы ссылаться на чье-нибудь авторитетное заявление об идеальном размере буфера для любых устройств можно будет самому авторитетно заявлять, что программа имеет возможность (умеет сама автоматически) оптимизировать размер буфера под любые устройства.
Почему я это предлагаю?
Просто я не верю, что существует универсальный ответ на сабж, тем более "раз и навсегда".
Соответственно даже Господь Бог для меня в этом вопросе не авторитет (да помилует меня Всевышний за такую наглость.
Если для кого-то дело обстоит иначе - флаг в руки.

← →
DevilDevil © (2013-01-27 00:06) [65]

> Аббат Пиккола (26.01.13 23:18)

тем не менее для тебя естественно, что размер буфера должен быть кратен размеру страницы. более того кратен 64кб.

ты не тестируешь все возможные размеры буферов от 1 до 3мб с шагом в 1 байт. Всё потому, что какие то дядьки в своё время аргументировали размеры 4кб и 64кб. авторитетные дядьки

← →
Аббат Пиккола (2013-01-27 00:53) [66]

2 DevilDevil © (27.01.13 00:06) [65]

Возможно, Вас удивит, но я вовсе не считаю, что размер буфера должен быть кратен размеру страницы. Все об этом твердят, но когда мне понадобилось практически подобрать размер буфера, я ничего такого не обнаружил. Буфер, размером 30 кбайт работал ТОЧНО ТАК ЖЕ, как и буфер, размером 32. При этом НАМНОГО БЫСТРЕЕ, чем буфер размером 16. А дальше (свыше 30 кбайт) скорость ПРАКТИЧЕСКИ НЕ ИЗМЕНЯЛАСЬ. Задача была простой - менять четный и нечетный байт местами в огромных файлах.

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

За то время, которое Вы обсуждаете сабж, я бу уже написал и отладил модуль автонастройки размера буфера.
Как бы я рассуждал?
Сокрость либо не критична вообще либо я собираюсь обрабатывать много файлов. Следовательно, я собираюсь обрабатывать много файлов. А если так. то я могу себе позволить часть файлов обработать неоптимально, чтобы потом обрабатывать остальные оптимально. следовательно, я могу набирать статистику, поигрывая размером буфера. И анализировать результаты. Прямо в процессе использования программы. Сначала грубо, затем все тоньше и тоньше настраивая (это будет требовать все большую выборку) нужный размер под "оптимальный". Если окажется, что он равен сдуру 37.8 кбайт, я не буду удивляться или спорить на эти темы на форумах. Я просто узнаю нечто для себя новое в мире стереотипов, в котором мы живем. Мне это нравится. Разумеется, если я потом об этом факте сообщу, найдется 100500 "авторитетных мнений", объясняющих мне, недостойному, почему это так. Но я не буду уязвлен, ибо скромность аббатам приличествует. :)

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

Разумеется, я не настаиваю на подобном решении, если лень или неохота. Но в качестве идеи ведь можно рассмотреть и такой вариант. Чисто абстрактно. Чем больше вариантов Вы рассмотрите, тем лучшее решение Вы в конечном итоге примите.
А на авторитет я полагаюсь ...
Знаете когда?
Вот когда у меня соврешенно нет времени самому разбираться, и слишком высоки риски ошибиться, а цена ошибки - жизнь. Например, если болит что-то в районе аппендикса. Я, разумеется, доверюсь врачу. Причем, взможно даже - первому попавшемуся.

> В плане размера буфера для чтения - Rouse_ стал для меня
> таким человеком

Дим, ты слишком категорично рассуждаешь, я же выше ответил, что Павиа (к мнению которого я прислушиваюсь периодически) сказал что вероятно на других размерах будут другие данные. Я не знаю какое железо им тестировалось (я на пользователях обкатывал ну если точнее на наших диллерских отделах :) но если человек говорит такое, то как минимум имеет смысл к этому прислушаться. Вполне вероятно что на серверных системах его мнение стоит больше чем мое...

> Аббат Пиккола (27.01.13 00:53) [66]

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

> Rouse_ © (27.01.13 01:05) [68]

1мб это слишком большой буфер
и грозит он повышенным количеством кэшмисс
а мне оно не нужно )
мне нужен оптимальный размер

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

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

Всякая задача либо имеет единственное решение (a), либо имеет множество решений (b), либо вообще не имеет решения (c).

Давайте еще раз определимся с задачей.
1. Вы хотите "раз и навсегда" зафиксировать некотрую цифру в качестве оптимальной путем голосования участников Никейского Собора или решением авторитетнейшего из епископов?
2. Вы хотите дать ряд настроек юзеру, чтобы он выбрал и колеблетесь, какие цифры стоит включить в список?

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

на данный момент использую буферы 256кб и 64кб

И какой быстрее работает?

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

Вопрос снят - видно это чтение и запись.

> DevilDevil © (27.01.13 01:06) [69]
>
> > Аббат Пиккола (27.01.13 00:53) [66]
>
> я перфекционист, я хочу знать наверняка
> на данный момент использую буферы 256кб и 64кб
> если будут другие мнения авторитетных дядюшек - я прислушаюсь

а больше похож на идолопоклонника-политеиста

> Аббат Пиккола (27.01.13 01:18) [71]
> Всякая задача либо имеет единственное решение (a), либо
> имеет множество решений (b)

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

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

> картман © (27.01.13 01:32) [74]

я агностик. а на кого я там похож как вам кажется - лучше не выносить в тематическую ветку

> DevilDevil © (27.01.13 01:59) [75]

> > картман © (27.01.13 01:32) [74]
>
> я агностик. а на кого я там похож как вам кажется - лучше
> не выносить в тематическую ветку

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

← →
QAZ10 (2013-01-27 11:54) [77]

> Слово "кратность", стало быть ты пропустил?

есть такое, зато я уточнил важную деталь , а ты взял и затер пост :(

> 1мб это слишком большой буфери грозит он повышенным количеством
> кэшмисс

Про, кэшмисс я бы не заикался. Пробовал я тестировать на него. Система кэшев сложнее чем система работы с жёстким. В результате получил противоречивые данные. С одной стороны, результаты коррелируют с результатами других тестов с другой авторитетное мнение что это не кэш промахи, а ЦПУ слабый.

> на данный момент использую буферы 256кб и 64кб

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

Не могу удержаться. Надеюсь, юмор не слишком тонок :)
http://ic.pics.livejournal.com/kit58/2089172/510456/510456_original.jpg

> картман © (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 ©

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

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

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

> 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]

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

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

> Аббат Пиккола (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 ©

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

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