Какой оптимальный размер буфера?

Question

[Никита]

Доброе время суток. Имеются ли какие-нибудь статьи по выбору оптимального размера буфера для считывания файла и запись в файл?
В интернете только натыкался на вот эту статью 2004 года, где рекомендуется применять 4 кб или 64 кб, но т.к. прошло уже 13 лет и мощности компов стали больше то уже доверия таким статьям мало. На стеке люди тоже пишут что мол 4 кб лучше использовать.
Просто у меня работа будет чаще всего с файлами более 10 гб и 4кб для них брать это как-то несерьезно (долгая работа с файлом)
P.S. необходимо это для диплома.

Comments

[4ainik]

Никита, а какова тема диплома? И что за данные хранятся у вас в 10ГБ файлах?

[Никита]

4ainik, Исследование способов резервирования зашифрованных данных в облачных хранилищах, делается это для хранение бэкапов sql баз и не только. Также будет применяться компрессия файлов.

Answer 1

[4ainik]

ну раз это нужно для диплома, то будет вполне уместно провести анализ: ряд тестов на чтений/запись больших файлов скажем размером в 10ГБ.
Читать/писать разными блоками начиная от 512 байт, далее степень двойки (1024,2048,4096,8192,...) замеряя при этом скорость... программа простецкая, за вечер думаю управитесь... построите график зависимости производительности от размера буфера... будет шикарный раздел диплома...

Comments

[Никита]

Наверно так и поступлю, спасибо.

Answer 2

[Дмитрий Threy]

На самом деле идеальный буфер от много зависит: от размера блоков вашей файловой системы, от кэша и т.д. Если обобщить, то главное не превышать область кэшей процессора, вот про регистры в таких крупных размерах речи и не идет, конечно. Так что можете смело брать ровно столько, сколько на L1 кэш влезет. Пока выше не залезете, то и не попадете в область оперативной памяти, а следовательно не уйдете вниз по кривой перформанса.

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

Comments

[Никита]

Интересно, про L1 кэш надо будет почитать

[d-stream]

А че, прогресс уже дошел до того, что с диска данные летят в L1? =))))

[4ainik]

d-stream, верное замечание, так то да, данные от HDD обычно пересылаются напрямую с ДИСКА в ОЗУ минуя процессор, занимается этим контроллер DMA это точно так для IDE интерфейса, насчет SATA точно не скажу, но тоже наверняка за это отвечает контроллер. По крайней мере это справедливо для больших блоков данных, но при малых объемах например 1 сектор процессор может и сам считать этот блок без DMA.

[d-stream]

4ainik, скажем в стиле деда Щукаря: кэш - внутри процессора, диск снаружи -))

[4ainik]

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

[d-stream]

4ainik, поясню попроще: нет прямого пути с диска в кэш процессора.

[Дмитрий Threy]

4ainik, эм, что значит минует кэш процессора? Да, контроллер считает данные и без процессора, но обработкой этих данных будет заниматься наш процессор, разве нет? Данные как ни крути попадут на кэш процессора, а потом в его регистры, это обычный процесс для работы с информацией. Как вы с данными работать иначе будете?

[Дмитрий Threy]

4ainik, вот, например, ответ на стак-оверфлоу, полностью солидарен с моим ответом.

стаковерфлоу

[4ainik]

Дмитрий Threy, так это уже другой вопрос.... ТС спросил

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

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

[Дмитрий Threy]

4ainik, перед записью в файл и считывания с него с этими данными работают, иначе какой смысл считывать/записывать, если мы не получили никакой информации и не изменили ее? Так что не согласен с вами, это все тот же вопрос и ответ был дан на наценку перфоманса.

[4ainik]

Дмитрий Threy, оптимальный размер буфера это сферический конь в вакууме, но в большинстве случаев лучше придерживаться диапазона 512 - 64к, кратного степени двойки. Не забывайте, что вы работаете с диском не напрямую, а через API ОС, а там куча посредников и своя логика работы...
В любом случае чем больше буфер тем меньше оверхед, ну чисто математически:
1) вызвать 1 раз fwrite(buf, 512, 1);
2) вызвать 512 раз fwrite(buf, 1, 1);

Очевидно второй вариант будет хуже в плане производительности, хотя и вполне уместен для например терминала :)

А конкретно для условий описанных ТС, я бы выбрал максимальный размер буфера равный 64к.

[Дмитрий Threy]

4ainik, Кто же с этим спорит? Вопрос в другом, что в погоне за идеальным буфером есть ориентиры, о чем я и сказал. То есть если вы будете укладываться в машинное слово и попадете в cash line, то перфоманс будет гораздо и гораздо лучше.

[4ainik]

Перформанс чего? Дисковых операций или всей программы в целом?
Давайте дождемся результатов тестов ТС и посмотрим на результирующий график?! ОК? Я думаю, что при размере буфера в 16к - 64к производительность будет примерно одинаковая.

[Дмитрий Threy]

4ainik, мой ответ выше и говорит использовать 64кб, тем самым не выходить за рамки кэша, какой смысл смотреть на результирующий график при таких буферах, если мы говорим использовать одно и тоже?

Я бы предложил ему выйти за размер кэша при батчинге файла на 10гб и вот тогда он почует разницу.

[Дмитрий Threy]

4ainik, что значит дисковых операций? Я вам уже говорил, что данные просто так не считывают, а с ними работают и именно поэтому важно знать про cashline процессора и попытаться туда влезть. Дисковые операции мы будем мерить вместе с использованием полученной информации и никак иначе.

[4ainik]

Дмитрий Threy, мы можем читать данные с диска в одном потоке, писать в другом, обрабатывать в третьем, а еще параллельно работает ОС и куча других программ, что будет в кеше процессора? - Никому не известно...

[Дмитрий Threy]

4ainik, какая разница, какой поток? Каждый поток делит время на определенном ядре процессора и часть одного потока в одном регистре и часть другого на том же самом регистре - просто невозможно, такого просто не бывает, вру, на самом деле бывает, если вы не делаете safe-threaded приложений с блоками, но мы же говорим о грамотном написании программ. Так, о чем я, одновременно там будет одно исполнение потока, т.е. если вы написали буфер в 64кб и работаете с ним, то он и попробует вместить туда ровно 64кб.

Или вы мне сейчас хотите сказать, что большинство практик для перформанса, типа inline методов/unroll циклов и выравнивания структур по полям полный бред, потому что мы не знаем, что там внутри? А зря, потому что они как раз нацелены на то, что мы догадываемся, что там внутри и пытаемся сделать лучше.

[4ainik]

Дмитрий Threy, разница очень даже большая, сколько будут эти данные там храниться и будут ли вообще они там храниться...
Копирование файла это "работа" с данными? - да.
А требуется ли в данном случае участие процессора? - не особо.
Требуется кеш L1, L2? - да тоже вроде не особо...
Вот у меня сейчас процессов 40+, потоков 700+, а ядро одно, что сейчас в кеше L1?
Я верю что процессор работает быстрее с L1 чем с ОЗУ.
Я так же верю, что данные обработаются быстрее если они попали в L1.
Но вопрос в другом. Ключевые слова "дисковые операции", "оптимальный размер буфера" и "размер файлов 10Гб".

[Дмитрий Threy]

4ainik, при чем тут, что у вас сейчас в кэше, если идет речь о том, когда будет конкретное приложение? Если в коде приложения написано выделить 64кб и работать с ними, то, повторяю, будет попытка вставить туда именно столько данных. Советую вам прочитать про cache misses.

[Дмитрий Threy]

4ainik,

Копирование файла это "работа" с данными? - да.
А требуется ли в данном случае участие процессора? - не особо.

при копировании файла путем перебора его через внутренний буфер? У вас буфер, это что такое? Правильно, переменная. А где она хранится? Правильно, в кэше процессора, а далее в регистрах.

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

Будут ли они вообще там храниться? А как вы себе это представляете? Данные, если мы с ними работаем, процессор вообще никак не обойдут, хоть ты лопни, но такого не будет.

[4ainik]

Дмитрий Threy, беспредметный разговор... буфер это переменная, но очень большая, такая ни в какой "регистр" процессора НЕ влезет, разрядность регистра всего 32-64бита к слову :)

char buf[512];
while(!feof(in)){
fread(in, buf, 512, 1);
fwrite(out, buf, 512, 1);
}

Зачем мне здесь кэш L1 процессора? buf это переменная, которая находится либо стеке (а это ОЗУ), либо выделена из "кучи", что так же является ОЗУ...
И в данном конкретном случае процессор даже не обращается к этой переменной, ну вообще ни как. Он лишь знает ее адрес (начальный адрес ОЗУ по которому расположен этот буфер) и только.

[Дмитрий Threy]

4ainik, в регистр лезут переменные из кэша, поделенные на размерность этого регистра, то есть по 64бита и 32бита.

Зачем мне здесь кэш L1 процессора? buf это переменная, которая находится либо стеке (а это ОЗУ), либо выделена из "кучи", что так же является ОЗУ

Да не знает процессор о вашей ОЗУ, у него есть память на регистрах. Все взаимодействие с данными происходит именно там, я это уже пытаюсь объяснить час.

но очень большая, такая ни в какой "регистр" процессора НЕ влезет

А куда она влезет тогда? Где процессор с ней будет общаться? Из оперативной памяти напрямую? Вы в своем уме? Она чанками раскидывается на регистры из кэша.

[4ainik]

Еще раз, ТС спросил о размере БУФЕРА при ДИСКОВЫХ операциях и судя по тегам писать программу он будет на C#, что он дальше будет делать с этими данными он не уточнил и его это видимо не волнует.
Переменные никуда не лезут :) И вообще не нужно путать понятия:
буфер != переменная != память != регистр != ОЗУ, это все очень узкие понятия, сильно зависящие от контекста.
есть случаи когда буфер != переменная, а есть буфер == переменная.
есть случаи когда переменная != память, переменная == память или переменная == регистр.
есть случаи когда регистр != ОЗУ и регистр == ОЗУ (процессора)

[Никита]

4ainik Дмитрий Threy Данные я буду шифровать и архивировать, наверное надо было мне это уточнить.
Провел я серию опытов (по 100 замеров на каждый блок) для файлов размером 1мб, 10мб, 100мб и 1гб. Размеры блоков я выбрал от 1 кб до 1 мб.
Итого по 1 мб:

• Размер блока 1кб, среднее время = 0:00:0.0226849
  
• Размер блока 2кб, среднее время = 0:00:0.021518
  
• Размер блока 4кб, среднее время = 0:00:0.0208970
  
• Размер блока 8кб, среднее время = 0:00:0.0200017
  
• Размер блока 16кб, среднее время = 0:00:0.0200935
  
• Размер блока 32кб, среднее время = 0:00:0.0196690
  
• Размер блока 64кб, среднее время = 0:00:0.0196175
  
• Размер блока 128кб, среднее время = 0:00:0.0202932
  
• Размер блока 256кб, среднее время = 0:00:0.0205030
  
• Размер блока 512кб, среднее время = 0:00:0.0200344
  
• Размер блока 1мб, среднее время = 0:00:0.0250169
  

Итого по 10 мб:

• Размер блока 1кб, среднее время = 00:00:00.6086737
  
• Размер блока 2кб, среднее время = 00:00:00.5704494
  
• Размер блока 4кб, среднее время = 00:00:00.5701250
  
• Размер блока 8кб, среднее время = 00:00:00.5489293
  
• Размер блока 16кб, среднее время = 00:00:00.5387132
  
• Размер блока 32кб, среднее время = 00:00:00.5380544
  
• Размер блока 64кб, среднее время = 00:00:00.5314811
  
• Размер блока 128кб, среднее время = 00:00:00.5325442
  
• Размер блока 256кб, среднее время = 00:00:00.5379496
  
• Размер блока 512кб, среднее время = 00:00:00.5288921
  
• Размер блока 1мб, среднее время = 00:00:00.5284209
  

Итого по 100 мб:

• Размер блока 1кб, среднее время = 00:00:04,0827317
  
• Размер блока 2кб, среднее время = 00:00:04,0602448
  
• Размер блока 4кб, среднее время = 00:00:03,9731101
  
• Размер блока 8кб, среднее время = 00:00:03,881938
  
• Размер блока 16кб, среднее время = 00:00:03,7614141
  
• Размер блока 32кб, среднее время = 00:00:03,8049724
  
• Размер блока 64кб, среднее время = 00:00:03,7621202
  
• Размер блока 128кб, среднее время = 00:00:03,7688710
  
• Размер блока 256кб, среднее время = 00:00:03,7608635
  
• Размер блока 512кб, среднее время = 00:00:03,8076113
  
• Размер блока 1мб, среднее время = 00:00:03,765408
  

Итого по 1 гб:

• Размер блока 1кб, среднее время = 00:00:48,9506655
  
• Размер блока 2кб, среднее время = 00:00:49,0770333
  
• Размер блока 4кб, среднее время = 00:00:48,6813174
  
• Размер блока 8кб, среднее время = 00:00:47,6786507
  
• Размер блока 16кб, среднее время = 00:00:45,6271946
  
• Размер блока 32кб, среднее время = 00:00:46,1870477
  
• Размер блока 64кб, среднее время = 00:00:45,9454532
  
• Размер блока 128кб, среднее время = 00:00:45,157257
  
• Размер блока 256кб, среднее время = 00:00:45,0101140
  
• Размер блока 512кб, среднее время = 00:00:44,722839
  
• Размер блока 1мб, среднее время = 00:00:44,4402667
  

Ну после таких результатов, могу сказать что до 1 гб стоит выбирать размер блока 64 кб, после наверно лучше брать уже 1 мб

[4ainik]

Никита, ээээ, тут есть несколько моментов.
1) современные жесткие диски обладают большой скоростью чтения/записи в зависимости от модели диска и интерфейса он может выдавать данные со скоростью 100МБайт/сек и более
2) современные ОС умеют очень хорошо кешировать данные в оперативной памяти, вполне себе могут закешировать весь файл целиком. Обычно это легко заметить при чтении файла, в первый раз он читается существенно дольше, последующих.

Не знаю как вы проводили тесты, но тесты на файлах размером меньше 1Гб практически не представляют полезной информации.

ЗЫ: График в данном случае показательнее цифр.
ЗЫ2: Какой у вас жесткий диск? уж не SSD?
ЗЫ3: Исходный код программы в студию :)

[Никита]

4ainik, Жесткий HDD
Вот 2 основных метода.

private static void Test(int bufSize)
		{
			var intput = @"D:\Для тестов\1гб\SW_DVD5_Office_2010w_SP1_W32_Russian_CORE_MLF_X17-82148.ISO";
			var output = @"D:\temp\1.gz";
			var watch = new Stopwatch();
			for (int i = 0; i < 100; i++)
			{
				watch.Start();
				WorkWithFile(intput, output, bufSize);
				watch.Stop();
				measurements.Add(watch.Elapsed);
				File.Delete(@"D:\temp\1.gz");
				watch.Reset();
			}
		}

public static void WorkWithFile(string sourceFile, string outputFile, int bufferSize)
		{
			using (var readStream = new FileStream(sourceFile, FileMode.Open, FileAccess.ReadWrite))
			{
				using (var writeStream = new FileStream(outputFile, FileMode.OpenOrCreate, FileAccess.Write, FileShare.ReadWrite))
				{
				
						int bytesRead = -1;
						byte[] bytes = new byte[bufferSize];

						while ((bytesRead = readStream.Read(bytes, 0, bufferSize)) > 0)
						{
						writeStream.Write(bytes, 0, bytesRead);
						}			
				}
			}
		}

[4ainik]

Никита, Понятно :)
Т.е. у вас получается измерение среднего времени выполнения операций чтения+записи.

Вот здесь как-то странно выглядит первый столбец (1кБ), по какой-то непонятной причине он показал лучше результат чем следующий (2кБ).
16кБ вполне себе ожидаемо показал результаты гораздо лучше чем все предыдущие, а вот почему 16кБ опередил 32кБ и даже 64кБ - не совсем понятно. Вполне возможно, что здесь работают какие-то особые механизмы кеширования, возможно упреждающего чтения, но могут влиять другие факторы, например фрагментация диска, тип файловой системы, размер кластера и размер сектора (обычно он 512байт, но в некоторых больших дисках бывает 4кБ). Вполне ожидаемо снижение оверхеда программы по мере увеличения размера буфера, вообще интересно посмотреть на картину происходящего по мере дальнейшего увеличения размера буфера до 10МБ :)

Answer 3

[Ivankon]

Смотрел исходники Майкрософта, и там применительно к C# для копирования файлов выбран буфер 81920, объясняется это так: "Выбираем значение, которое является самым большим кратным 4096, но которое по-прежнему меньше порога кучи больших объектов (85K)." Считаю что это самый оптимальный буфер для копирования.

Answer 4

[АртемЪ]

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