FileBufferReader , оптимальный размер баффера

Язык не важно какой, важна суть, читаем большой файл (10-50МБ) а может и больше
пример для понятности на "проклятом" всеми чистом C,
просьба холиваров на темы C++ лучше, не разводить, тут это не важно.

  char buf[1024*512];
 
 while (fgets(buf, sizeof(buf), fp) != NULL)
  {
    buf[strlen(buf) - 1] = '\0'; // eat the newline fgets() stores
    printf("%s\n", buf);
  }

,

Как подбирать оптимальный размер баффера? почему .5мега а не 2 или 10?
Данные приходят по сети, обычным HTTP, В сети гуглил толком ничего по сути
не нашел, какие варианты

1. Размер должен быть кратен степени двойки, коли сейчас почти все машины считают в двоичной, да и аппаратная поддержка, скорее всего, этим пользуется.
2. Не надо размер в несколько мегабайт (не больше), т.к. старые машины могут не найти столько памяти, а делать желательно для бо́льшего количества применений.
3. Главное: размер должен быть таков, чтобы время на количество вызовов функций для чтения (с учётом времени на вызов каждой) было незначительно в сравнении с временем чтения данных. Так, для SSD, скажем, желательно делать вызовов поменьше, ибо они данные читают шибче. Впрочем, предел=идеал всё равну будет манить: только 1 вызов. В то же время, если вдруг делаете попытки чтения битых файлов, то запросто может оказаться, что лучше наделать кучу микровызовов (чтобы хоть что-то прочитать), нежели всего один, кой скажет, что неудача,... и адью.

На самом деле даже для относительно медленных жёстких дисков нет смысла слишком увеличивать размер буфера. Ведь пока буфер заполняется, программа ждёт, и ничего не делает. По крайней мере нет смысла делать его больше, чем дорожка диска (128 кБ). На само деле нет смысла делать его длиннее основной части непрерывных сегментов файла. Из-за этого для обычной последовательной обработки в современных операционных системах для современных же жёстких дисков обычно обходятся буфером размером в 4-64 КБ (Для винды покороче, для линукса подлиннее, обычно 16). Операционная система обнаружив, что программа читает файл последовательно с самого начала, сама считывает файл в кэш диска, и выдаёт порциями. При произвольном доступе имеет смысл делать буфер короче.
Увеличение размера буфера имеет смысл при копировании файлов в пределах одного физического носителя (с механическим доступом).
Но, для того, чтобы получить существенный выигрыш, недостаточно задавать буфер в вызовах функций fread/fwrite. Надо задать размер внутреннего буфера файла, используемого низкоуровневыми read/write.

Славян и amk, вы вроде челы продвинутые, на такие косяки порете!

1) Славян, возьми "среднестатистический" винт 10-й давности, там аппаратный кэш уже порядка 32 Mb! А это значит - "впилил и забыл", остальное дело микросхем. Вывод - "пилить" меньше, только электричество портить!

2) Amk, твое "ведь пока буфер заполняется, программа ждёт, и ничего не делает. По крайней мере нет смысла делать его больше, чем дорожка диска (128 кБ)." - шедевр безалаберности! Ты уж извини ... Про асинхронность помним, не? Отдали винту "порцию", не ждем ответа - работаем дальше. Давай вместе почитаем?

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

Цитата amk @ 24.11.18, 13:32

Но, для того, чтобы получить существенный выигрыш, недостаточно задавать буфер в вызовах функций fread/fwrite. Надо задать размер внутреннего буфера файла, используемого низкоуровневыми read/write.

А как знать какой размер внутреннего буфера файла?
У меня java, выглядит это

 InputStream inputStream = request.getInputStream();
              bufferedReader = new BufferedReader(new InputStreamReader(inputStream));

и потом

        char[] charBuffer = new char[8*1024]
  while ((bytesRead = bufferedReader.read(charBuffer)) > 0) {
}

Я его (файл ) парсю в HTTP handler, еще я знаю что это csv.
Пока писать на C не могу(слишком много народу, фирма 1500человек, убеждать надо).
дать 16 для Лины и 8 для окон, будет нормально?

sergioK, рекомендую тебе подход - системный!

В ближнем приближении - твоя "система" тупо состоит из двух блоков "ввод" и "вывод". Количество там и там - роли не играет. Важен трансфер на входе и выходе. Берем "вход", ты писал HTTP. Там существенным критерием есть MTU. Но он крошечный - единственный разумный, имхо, момент - делать буффер кратный ему. На счет блоков вывода - я бы смотрел в сторону аппаратных возможностей записи. Уже писал выше - как минимум размера аппаратного кэша. Но есть и третий момент, который забывают очень часто!!! А именно - свободная память для ОС! Если об этом не заботиться - ОС переходит в жесткий режим свопа - а это, в плане производительности, считай - "обнять и плакать"! Таким образом, любые манипуляции с памятью не должны урезать разумные границы работы ОС. Это самое главное!!! Оно - самое самое, и оно - самое главное! Остальное - лайт тюнинг. Таковое мое ИМХО.

Цитата JoeUser @ 24.11.18, 14:22

Про асинхронность помним, не? Отдали винту "порцию", не ждем ответа - работаем дальше.

Я комментировал пост с вызовом fgets. Там никакой асинхронности в принципе быть не может. Так что вызываем функцию… и ждём.
Впрочем для fgets выбор размера буфера определяется по-другому. Буфер должен быть больше, чем самая длинная строка в файле.
Буфер записи для fputs/fwrite может быть любым. Вообще любым, всё равно данные из него просто переписываются в буфер управления файлом.
Буфер записи для write тоже любой, лишь бы был кратен размеру блока системного файлового кэша. Система сама разберётся когда и что писать на диск.
Буфер чтения для read тоже должен быть кратен блоку системного кэша. И, повторю, нет смысла делать его больше, чем непрерывная цепочка блоков в файле, никакого выигрыша по быстродействию не будет. С другой стороны нежелательно делать его меньше читаемой за один раз порции данных. Если обработка идёт медленно по сравнению с чтением, то буфер можно вообще сделать примерно равным одной порции.

Цитата JoeUser @ 24.11.18, 14:22

Не поймите, плс, меня превратно - я не спец в этом вопросе, и код не "выплюну" на раз-два.

Вижу, поскольку "выплёвывание" кода тут вообще дело десятое. Всё зависит от того, какая система и куда идёт запись (откуда идет чтение). С некоторыми устройствами выгоднее вообще работать по-байтно.

Цитата JoeUser @ 24.11.18, 14:41

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

несколько гига хватит ? Асинхронность тоже ничего не даст, пока данные необработаны
делать нечего, ну поставишь waitSingleThread, все поймут что крутой пацан so what is next?


Всем спасибо но это была теория, что делать практически ? Ну я дам возможность
размер буфера брать из конфига, и ловить оптимальный вариант методом try && mistakes ?
Что конкретно в коде писать ?.

Сообщение отредактировано: sergioK - 26.11.18, 01:41

Цитата amk @ 24.11.18, 15:21

Буфер записи для fputs/fwrite может быть любым. Вообще любым, всё равно данные из него просто переписываются в буфер управления файлом.
Буфер записи для write тоже любой, лишь бы был кратен размеру блока системного файлового кэша. Система сама разберётся когда и что писать на диск.
Буфер чтения для read тоже должен быть кратен блоку системного кэша. И, повторю, нет смысла делать его больше, чем непрерывная цепочка блоков в файле, никакого выигрыша по быстродействию не будет.

я вот опять недавно разбирал старую программу для Виндус , и легко поднял
производительность её отрезка с файловыми операциями на порядок (в 10 раз).
Там чтение файла 200-300К происходило по-байтно.
А если читать блоками 16К-32К (актуальное значение буфера - размер кластера, 4К)
производительность выросла в 10 раз.
---
Как то раз я написал тест, для исследования зависимости скорости от размеров буфера
с блочной операцией fread/fwrite. Основной выигрыш был, когда буфер достигал 4К.
Дальше бонус растёт очень медленно, в том случае, если речь идёт о файлах огромных размеров.
Просто за счёт уменьшения количества циклов и обращений к fread/fwrite.

Добавлено 26.11.18, 12:48

Цитата sergioK @ 26.11.18, 01:32

Всем спасибо но это была теория, что делать практически ?

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

Цитата JoeUser @ 24.11.18, 14:22

2) Amk, твое "ведь пока буфер заполняется, программа ждёт, и ничего не делает. По крайней мере нет смысла делать его больше, чем дорожка диска (128 кБ)." - шедевр безалаберности! Ты уж извини ... Про асинхронность помним, не? Отдали винту "порцию", не ждем ответа - работаем дальше. Давай вместе почитаем?

Вообще-то он прав - не нужно делать больше, чем размер кластера. Да и асинхронность тут никаким боком - она не уменьшит время, проходящее с момента запуска начала чтения до его конца.

Цитата OpenGL @ 27.11.18, 06:16

Вообще-то он прав - не нужно делать больше, чем размер кластера. Да и асинхронность тут никаким боком - она не уменьшит время, проходящее с момента запуска начала чтения до его конца.

Она уменьшит количество операций с контроллером винта. А это существенно.

Цитата JoeUser @ 27.11.18, 06:34

Она уменьшит количество операций с контроллером винта.

Дай пруф на существенность что ли.

Цитата OpenGL @ 27.11.18, 06:50

Дай пруф на существенность что ли.

Ну выше же писали уже, мол блочное чтение/запись увеличивает на порядок скорость, нежели посимвольное чтение. Если доверия нет - напиши короткий тест. Я давно это проверял, и помню хорошо. Еще писамши на Virtual Pascal'е. Тут сравнивается заведомо худший вариант с "каким-то", путь удовлетворительным. И разница видна.

А вот дальше нужно определиться с понятием "существенно". Это от задачи к задаче, ИМХО. В два раза - это существенно? А на 5% быстрее, существенно?

По-моему так: коль ТС заговорил о быстродействии - значит любой лучший результат существенен. Ну как-то так.

Цитата JoeUser @ 27.11.18, 09:18

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

Давай ты не будешь додумывать то, что я не говорил. О том, что посимвольное чтение медленней буферизованного никто не спорит. Речь о том, что нет смысла делать буфер большой - 64 кб, например, за глаза и уши, а лучше и того меньше. Увеличение его размера не только не приведёт к ускорению, но даже замедлить чтение может.

Добавлено 27.11.18, 10:20

Цитата JoeUser @ 27.11.18, 09:18

По-моему так: коль ТС заговорил о быстродействии - значит любой лучший результат существенен.

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

Цитата OpenGL @ 27.11.18, 10:19

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

Возникает резонный вопрос - зачем тогда HDD обеспечивают аппаратным кэшем в 64/32/16/8 MB?

Цитата JoeUser @ 27.11.18, 11:26

зачем тогда HDD обеспечивают аппаратным кэшем в 64/32/16/8 MB?

Во-первых, при записи можно не ждать, когда установятся головки и под них подойдёт нужный блок, а записать данные в кэш и отчитаться, что операция выполнена. Реальную же запись выполнить, когда будет время.
Во-вторых, если после этого сразу начнётся чтение, можно придержать данные в кэше, прочитать нужные данные, а потом уже выбирать время для записи.
Можно накопить данные, и потом записать их в порядке, минимизирующем дёргание головок.
Специально для тех, кто не понимает разницу между высокоуровневым чтением из программного буфера и низкоуровневым с диска (встречал и такое), и пытающимся читать данные с диска по одному байту, можно не гонять головку к нужному блоку, а выдавать его прямо из памяти, уменьшив замедление работы с 1000 раз и более всего до 10.
Поскольку файлы хранятся на диске по-кластерно, а некоторые даже иногда подвергают диск дефрагментации, можно прочитать дорожку до конца в кэш, и заняться другими делами, по запросам выдавая уже прочитанные блоки.
Ну и последнее, многие не знают, но на современных дисках размер блока уже довольно давно не равен 512 байт (у меня в компе размер блока равен 4096 - 8 логических блоков, определяется при сбоях). Более того, реальные кластеры часто пересекают границы физических блоков на диске, и даже переходят с дорожки на дорожку. Чтобы сделать вид, что блок по-прежнему равен 512 байт. Приходится при чтении разбивать физические блоки на логические в кэше, а при записи собирать их обратно.

OpenGL, т.е. если диск может принять в свой кэш 64MБ, то все равно нужно забивать его мелкими порциями по 64КБ - и это будет по фэншую? А вот если установим свой программный кэш, к примеру в 16МБ, то получим (можем получить) просадку по скорости?

Цитата OpenGL @ 27.11.18, 10:19

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

Жалкие проценты никого не волнуют, но размер буфера конфигурируемым я сделал,
Дальше задача саппорта, буду делать stress test с файлами 20-25Мега на неделе,
выложу, благодарю за хинты, Я пока stand by.

JoeUser

Цитата JoeUser @ 27.11.18, 19:00

то все равно нужно забивать его мелкими порциями по 64КБ - и это будет по фэншую?

Когда я ставил эксперименты то оптимальным на чтение было 256КБ на запись 8МБ.

Цитата JoeUser @ 27.11.18, 19:00

А вот если установим свой программный кэш, к примеру в 16МБ, то получим (можем получить) просадку по скорости?

Да проседает на проценты.

Сообщение отредактировано: Pavia - 28.11.18, 03:08

Цитата JoeUser @ 27.11.18, 11:26

Цитата OpenGL @ 27.11.18, 10:19

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

Возникает резонный вопрос - зачем тогда HDD обеспечивают аппаратным кэшем в 64/32/16/8 MB?

А было время, когда этого не было.
В этом случае, ЦП должен был сам, программно, управлять
диском в реальном времени. Что не очень удобно, а в ситемах
типа Виндус крайне не выгодно.
(А я такие опыты производил в ситеме CPM/80. Писал процедуру
форматирования дискеток)
Поэтому в дивайсы стали устанавливать весьма интеллектуальные
контроллеры, а связь с внешним миром организовали через
общую память. Для того, чтобы максимальным образом
разгрузить центральный процессор.
-----
Похожая эволюция затрагивает практически любые дивайсы.
Например, сетевые карты. Видео-карты.

Сообщение отредактировано: ЫукпШ - 28.11.18, 09:59

Цитата JoeUser @ 27.11.18, 19:00

OpenGL, т.е. если диск может принять в свой кэш 64MБ, то все равно нужно забивать его мелкими порциями по 64КБ - и это будет по фэншую? А вот если установим свой программный кэш, к примеру в 16МБ, то получим (можем получить) просадку по скорости?

Я когда-то экспериментировал, то получал, что начиная с некоторого совсем небольшого размера размер буфера перестаёт ускорять чтение-запись.

Странно это все, очень странно!

Написал прогу на Си для тестирования различных вариантов буферизированной записи. Тестирование проводил на "живой ОС Win 10x64", т.е. не на виртуальной машине. Сама система крутится на материнском RAID-0 (fake RAID). Запись проводил на дополнительно подключенный HDD c SATA 6Gb/s на интерфейс компа SATA III, и потом другой HDD по USB 3.0. Комп на базе Intel Core i7-3770K, 3.5GHz, 8GB RAM. Для более реальных, как мне показалось, условий - писал в два конкурирующих за I/O (вернее за запись) потока.

Вот код:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <pthread.h>
#include <unistd.h>
 
#define BUFF_LEN_ONE 256*1024
#define BUFF_LEN_TWO 1*1024*1024
 
void* Write256KB(void* buff) {
  FILE *fd;
  struct timespec start, stop;
  clock_gettime (CLOCK_REALTIME, &start);
  if ((fd = fopen("F:/one.bin", "wb")) == NULL) {
    perror("Cannot open file one.bin");
    return NULL;
  };
  setvbuf(fd, (char *)buff, _IOFBF, BUFF_LEN_ONE);
  for (long int i=0; i<128*1024*1024; ++i) fputs("0123456789ABCDEF",fd);
  fflush(fd); /** в принципе не надо **/
  fclose(fd);
  clock_gettime (CLOCK_REALTIME, &stop);
  printf ("Delta One: %lu.%lu sec\n",stop.tv_sec - start.tv_sec,stop.tv_nsec - start.tv_nsec);
  return NULL;
}
 
void* Write32MB(void* buff) {
  FILE *fd;
  struct timespec start, stop;
  clock_gettime (CLOCK_REALTIME, &start);
  if ((fd = fopen("F:/two.bin", "wb")) == NULL) {
    perror("Cannot open file two.bin");
    return NULL;
  };
  setvbuf(fd, (char *)buff, _IOFBF, BUFF_LEN_TWO);
  for (long int i=0; i<128*1024*1024; ++i) fputs("0123456789ABCDEF",fd);
  fflush(fd); /** в принципе не надо **/
  fclose(fd);
  clock_gettime (CLOCK_REALTIME, &stop);
  printf ("Delta Two: %lu.%lu sec\n",stop.tv_sec - start.tv_sec,stop.tv_nsec - start.tv_nsec);
  return NULL;
}
 
 
int main() {
 
  pthread_t one, two;
  void *buff_one, *buff_two;
 
  buff_one = malloc(BUFF_LEN_ONE);
  buff_two = malloc(BUFF_LEN_TWO);
 
  if (pthread_create(&one, NULL, Write256KB, buff_one) != 0) perror("Pthread_create-1 fails");
  if (pthread_create(&two, NULL, Write32MB, buff_two) != 0) perror("Pthread_create-2 fails");
  if (pthread_join(one,NULL) != 0) perror("Pthread_join-1 fails");
  if (pthread_join(two,NULL) != 0) perror("Pthread_join-2 fails");
 
  return 0;
}

Может с кодом че не так? Но результаты получились странные.
Свел их в таблицы для наглядности:

Прикреплённая картинка

Прикреплённая картинка

Выводы:

1) Для программы с более одним потоком - операционная система рулит как хочет
2) Для потоков желательно не использовать буфера равных размеров - общее быстродействие программы ухудшается
3) Самый последний тест с равными размерами буферов для USB 3.0 удивляет

Критикуйте. Что не так написал или где неправильный вывод сделал.

Добавлено 28.11.18, 11:58
ЗЫ: Каждый из тестов запускал по несколько прогонов, тупо чтобы убедиться, что цифры "не пляшут". Как писал выше, с последним тестом с равными буферами для HDD USB - устойчивая разница. Везде разброс между запусками - доли секунды.

JoeUser
1)У вас процессор отрабатывает за 10 секунд пересылку в буфер ОС. Win7 и далее используют всю свободную память под дисковый кэш.
А далее виндоус медленно записывает на диск.
Так что с тем что винда, как хочет так и рулит согласен.
2)

Цитата JoeUser @ 28.11.18, 11:53

общее быстродействие программы ухудшается

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

В чём смысл двух потоков? Почему не 4 или 5?

3) Чем удивляет?
Судя повсему в обоих таблицам скорость 1 и 2 перепутаны с 1 и 2 буфером.
Кстати у вас вывод printf("Delta One: не синхротронный и там буквы да и цифры должны плясать чёрти как.

Сообщение отредактировано: Pavia - 28.11.18, 13:44

Цитата Pavia @ 28.11.18, 13:29

)У вас процессор отрабатывает за 10 секунд пересылку в буфер ОС. Win7 и далее используют всю свободную память под дисковый кэш. А далее виндоус медленно записывает на диск.

Нет. На на пару тестах, во время их работы, я открывал ProcessExplorer и смотрел загрузку проца нитями - была на протяжении всей записи, но от 1% до 5% максимум.

Цитата Pavia @ 28.11.18, 13:29

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

Да нет, все верно - пара столбцов под один вариант буфферов, следующая пара - под другой, и т.д. - лучший вариант меньший. Помимо того "серая" линия показывает "общее время программы" (иными словами максимально-бОльшее время работы одного из потоков). Аналогично - меньшее время = лучший результат.

Цитата Pavia @ 28.11.18, 13:29

Судя повсему в обоих таблицам скорость 1 и 2 перепутаны с 1 и 2 буфером.

Ничего не перепутано! Я времена снимал с "Delta ...:". Да, в некоторых случаях второй поток (второй, бОльший буфер) успевал отписываться первым, т.к. завершал раньше. Я все это учитывал.

Цитата Pavia @ 28.11.18, 13:29

В чём смысл двух потоков? Почему не 4 или 5?

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

Цитата Pavia @ 28.11.18, 13:29

Кстати у вас вывод printf("Delta One: не синхротронный и там буквы да и цифры должны плясать чёрти как.

В моем тесте такого в 99.9% быть не может - т.к. разница между выводами на много больше скорости вывода на консоль, более того - саму еще буферезированную. Кстати - код я привел, можно у себя проверить. Я собирал с помощью gcc version 5.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project).

JoeUser

Цитата JoeUser @ 28.11.18, 15:48

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

Жесткий запроектированы на временное разделение для 4 потоков. Поэтому 2-х недостаточно.
Во-вторых я не понимаю чего вы ожидаете увидеть?

Цитата JoeUser @ 28.11.18, 15:48

Нет. На на пару тестах, во время их работы, я открывал ProcessExplorer и смотрел загрузку проца нитями - была на протяжении всей записи, но от 1% до 5% максимум.

Дело в том, что ProcessExplorer считает данные блоки как Free. Просто запустите несколько процессов 32-битных или 64 битных которые съедят всю свободную память и данамика записи изменится у вас правда она не отображается. Но на скорость это тоже повлияет.

Цитата JoeUser @ 28.11.18, 15:48

Да нет, все верно

Так я не про то, что верно не верно. А про-то что вводит в заблуждение. Как на картинах intel vs amd.

Скрытый текст

Цитата Pavia @ 28.11.18, 17:00

Дело в том, что ProcessExplorer считает данные блоки как Free.

Я раскрывал свойство запущенной программы, открывал вкладку Threads и смотрел сколько CPU в % отъедает каждая работающая нить.
Какие такие блоки???

Цитата Pavia @ 28.11.18, 17:00

А про-то что вводит в заблуждение.

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

Цитата Pavia @ 28.11.18, 17:00

Жесткий запроектированы на временное разделение для 4 потоков. Поэтому 2-х недостаточно.

Кто и кем запроектирован для 4-х потоков и почему 2 недостаточно?

Цитата Pavia @ 28.11.18, 17:00

Во-вторых я не понимаю чего вы ожидаете увидеть?

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

Цитата JoeUser @ 28.11.18, 17:33

Цитата Pavia @ 28.11.18, 17:00

Жесткий запроектированы на временное разделение для 4 потоков. Поэтому 2-х недостаточно.

Кто и кем запроектирован для 4-х потоков и почему 2 недостаточно?

Потоков лучше всего столько, сколько ядер на машине.

Цитата sergioK @ 28.11.18, 19:22

Потоков лучше всего столько, сколько ядер на машине.

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

Чуток подправил для одновременного запуска на разных объёмах буферов. За неимением POSIX-а переиначил потоки и время на плюсовые std:: аналоги. Тестил на SATAшных терабайтниках.
Регулар:

Using 262144 and 1048576 len buffers:   delta two: 22.642 sec | delta one: 24.108 sec
Using 262144 and 16777216 len buffers:  delta one: 13.658 sec | delta two: 23.652 sec
Using 262144 and 536870912 len buffers: delta one: 10.679 sec | delta two: 33.190 sec
Using 262144 and 524288 len buffers:    delta one: 23.556 sec | delta two: 24.215 sec
Using 262144 and 262144 len buffers:    delta one: 24.640 sec | delta two: 24.889 sec
Using 16777216 and 16777216 len buffers:delta one: 24.022 sec | delta two: 24.270 sec

Энкриптед:

Using 262144 and 1048576 len buffers:   delta two: 24.068 sec | delta one: 24.511 sec
Using 262144 and 16777216 len buffers:  delta one: 13.193 sec | delta two: 22.704 sec
Using 262144 and 536870912 len buffers: delta one: 10.568 sec | delta two: 32.802 sec
Using 262144 and 524288 len buffers:    delta one: 24.850 sec | delta two: 25.351 sec
Using 262144 and 262144 len buffers:    delta one: 23.470 sec | delta two: 23.867 sec
Using 16777216 and 16777216 len buffers:delta one: 23.279 sec | delta two: 23.809 sec

Сомпрессед:

Using 262144 and 1048576 len buffers:   delta two: 30.661 sec | delta one: 34.824 sec
Using 262144 and 16777216 len buffers:  delta two: 20.858 sec | delta one: 46.974 sec
Using 262144 and 536870912 len buffers: delta one: 40.822 sec | delta two: 53.165 sec
Using 262144 and 524288 len buffers:    delta one: 45.717 sec | delta two: 59.511 sec
Using 262144 and 262144 len buffers:    delta two: 58.195 sec | delta one: 63.441 sec
Using 16777216 and 16777216 len buffers:delta two: 30.491 sec | delta one: 31.853 sec

Понятно, что время на упакованных файликах будет очень разниться в зависимости от их контента.
Не понимаю, об чём сыр-бор. Понятно же, что результат будет зависеть от конкретики, и синтетические тесты ровным счётом ничего не покажут. Для полноты экспериментов нужно ещё пробовать флажочки из WinAPI.
Для фана регулар на 4Г флэшке (NTFS):

Using 262144 and 1048576 len buffers:   delta two: 95.395 sec | delta one: 152.316 sec
Using 262144 and 16777216 len buffers:  delta two: 118.955 sec| delta one: 182.474 sec
Using 262144 and 536870912 len buffers: delta two: 155.706 sec| delta one: 157.165 sec
Using 262144 and 524288 len buffers:    delta two: 378.902 sec| delta one: 415.027 sec
Using 262144 and 262144 len buffers:    delta one: 258.895 sec| delta two: 259.765 sec
Using 16777216 and 16777216 len buffers:delta two: 87.787 sec | delta one: 152.773 sec

Пришлось уменьшить размер файлов вдвое, иначе не вмещались. Флешка оптимизирована на производительность, так что запись кешировалась. Полный алес по времени. Видимо, понимая медленность устройства, винда пыталась кешировать, пока был резон хавать память под кеш, но потом-таки сдалась.

Qraizer, сенкс, что не поленился Интересно, цифры конечно разные, но соотношения цифр на разных вариантах буферов - вполне похожи как в моем эксперименте.

1) Первый эксперимент - кэш в 1 мег выигрывает у кэша в 256к
2) Второй эксперимент с кэшем в 256к и 16 мегами - дает максимальную общую производительность проги
3) Последний эксперимент - что творит венда с записью на USB с обоими кэшами по 16 мег, только ей известно

Цитата Qraizer @ 28.11.18, 21:42

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

Согласен. Безапелляционные утверждения о конкретном значении программного кэша (пресловутые 256к) - наводят туман!

JoeUser
Про блоки я имел ввиду "кэшированные" тёмно синий цвет в мониторе ресурсов.
За одно обратите внимание, что запись идёт от имени процесса system.
https://yadi.sk/d/cjt20Bfu3B7voi

Цитата JoeUser @ 29.11.18, 01:06

Qraizer, сенкс, что не поленился Интересно, цифры конечно разные, но соотношения цифр на разных вариантах буферов - вполне похожи как в моем эксперименте.

1) Первый эксперимент - кэш в 1 мег выигрывает у кэша в 256к
2) Второй эксперимент с кэшем в 256к и 16 мегами - дает максимальную общую производительность проги
3) Последний эксперимент - что творит венда с записью на USB с обоими кэшами по 16 мег, только ей известно

Цитата Qraizer @ 28.11.18, 21:42

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

Согласен. Безапелляционные утверждения о конкретном значении программного кэша (пресловутые 256к) - наводят туман!

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