Форум: "Прочее";
Текущий архив: 2013.06.02;
Скачать: [xml.tar.bz2];
ВнизОптимальный размер буфера для чтения/записи файла Найти похожие ветки
← →
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_ © (2013-01-27 01:05) [68]
> В плане размера буфера для чтения - Rouse_ стал для меня
> таким человеком
Дим, ты слишком категорично рассуждаешь, я же выше ответил, что Павиа (к мнению которого я прислушиваюсь периодически) сказал что вероятно на других размерах будут другие данные. Я не знаю какое железо им тестировалось (я на пользователях обкатывал ну если точнее на наших диллерских отделах :) но если человек говорит такое, то как минимум имеет смысл к этому прислушаться. Вполне вероятно что на серверных системах его мнение стоит больше чем мое...
← →
DevilDevil © (2013-01-27 01:06) [69]> Аббат Пиккола (27.01.13 00:53) [66]
я перфекционист, я хочу знать наверняка
на данный момент использую буферы 256кб и 64кб
если будут другие мнения авторитетных дядюшек - я прислушаюсь
← →
DevilDevil © (2013-01-27 01:11) [70]> 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]Вопрос снят - видно это чтение и запись.
← →
картман © (2013-01-27 01:32) [74]
> DevilDevil © (27.01.13 01:06) [69]
>
> > Аббат Пиккола (27.01.13 00:53) [66]
>
> я перфекционист, я хочу знать наверняка
> на данный момент использую буферы 256кб и 64кб
> если будут другие мнения авторитетных дядюшек - я прислушаюсь
а больше похож на идолопоклонника-политеиста
← →
DevilDevil © (2013-01-27 01:59) [75]> Аббат Пиккола (27.01.13 01:18) [71]
> Всякая задача либо имеет единственное решение (a), либо
> имеет множество решений (b)
если решение одно - оно меня устроит
если решений несколько - я хотел бы со всеми ознакомиться и либо выбрать среднее оптимальное, либо динамически анализировать железо на котором запускается приложение
в любом случае мне нужно решение, основанное на архитектуре диска/ОС/памяти (или хотя бы большого опыта), а не на основе чьих-либо фантазий
> картман © (27.01.13 01:32) [74]
я агностик. а на кого я там похож как вам кажется - лучше не выносить в тематическую ветку
← →
картман © (2013-01-27 11:53) [76]
> DevilDevil © (27.01.13 01:59) [75]
> > картман © (27.01.13 01:32) [74]
>
> я агностик. а на кого я там похож как вам кажется - лучше
> не выносить в тематическую ветку
это была критика твоего подхода, извини, если грубо получилось, впредь постараюсь избегать подобного... Но если ты задашь вопрос "как составить идеальный план выполнения запроса - раз и навсегда", то я не смогу удержаться
← →
QAZ10 (2013-01-27 11:54) [77]
> Слово "кратность", стало быть ты пропустил?
есть такое, зато я уточнил важную деталь , а ты взял и затер пост :(
← →
Pavia © (2013-01-27 12:47) [78]
> 1мб это слишком большой буфери грозит он повышенным количеством
> кэшмисс
Про, кэшмисс я бы не заикался. Пробовал я тестировать на него. Система кэшев сложнее чем система работы с жёстким. В результате получил противоречивые данные. С одной стороны, результаты коррелируют с результатами других тестов с другой авторитетное мнение что это не кэш промахи, а ЦПУ слабый.
> на данный момент использую буферы 256кб и 64кб
Запись я не тестировал. Но побочным результатом тестом на чтение было то, что 64 КБайта для записи не является эффективным.
← →
Kerk © (2013-01-27 13:10) [79]Не могу удержаться. Надеюсь, юмор не слишком тонок :)
http://ic.pics.livejournal.com/kit58/2089172/510456/510456_original.jpg
← →
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 ?
Страницы: 1 2 3 вся ветка
Форум: "Прочее";
Текущий архив: 2013.06.02;
Скачать: [xml.tar.bz2];
Память: 0.65 MB
Время: 0.008 c