Форум на Исходниках.RU

Форум на Исходниках.RU https://forum.sources.ru Форум на Исходниках.RU Форум на Исходниках.RU https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783998 Thu, 29 Nov 2018 05:00:21 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783998 Цитата JoeUser @ 29.11.18, 01:06

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

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

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

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

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

Все забыли что в нормальной системе есть куча других параметров, и затрат,
тем более в сервере с кастерами, и несколькими БД .]]> sergioK C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783995 Thu, 29 Nov 2018 03:13:39 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783995 JoeUser
Про блоки я имел ввиду "кэшированные" тёмно синий цвет в мониторе ресурсов.
За одно обратите внимание, что запись идёт от имени процесса system.
https://yadi.sk/d/cjt20Bfu3B7voi]]> Pavia C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783994 Thu, 29 Nov 2018 01:06:57 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783994 Qraizer, сенкс, что не поленился :) Интересно, цифры конечно разные, но соотношения цифр на разных вариантах буферов - вполне похожи как в моем эксперименте.

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

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

Согласен. Безапелляционные утверждения о конкретном значении программного кэша (пресловутые 256к) - наводят туман! :)]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783993 Wed, 28 Nov 2018 21:42:24 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783993 Регулар:

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 C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783991 Wed, 28 Nov 2018 19:51:37 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783991 Цитата sergioK @ 28.11.18, 19:22

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

Это когда ядра есть чем занять по вычислениям.]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783990 Wed, 28 Nov 2018 19:22:43 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783990 Цитата JoeUser @ 28.11.18, 17:33

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

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

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

Потоков лучше всего столько, сколько ядер на машине.]]> sergioK C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783985 Wed, 28 Nov 2018 17:33:47 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783985 Цитата Pavia @ 28.11.18, 17:00

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

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

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

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

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

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

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

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

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

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

Какой из потоков с соответствующим размером буфера умудриться свои данные записать быстрее. Потом подумалось об общем быстродействии - что также немаловажно.]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783982 Wed, 28 Nov 2018 17:00:41 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783982 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 C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783979 Wed, 28 Nov 2018 15:48:16 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783979 Цитата Pavia @ 28.11.18, 13:29

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

Цитата 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 C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783961 Wed, 28 Nov 2018 13:29:20 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783961 JoeUser
1)У вас процессор отрабатывает за 10 секунд пересылку в буфер ОС. Win7 и далее используют всю свободную память под дисковый кэш.
А далее виндоус медленно записывает на диск.
Так что с тем что винда, как хочет так и рулит согласен.
2)

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

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

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

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

3) Чем удивляет?
Судя повсему в обоих таблицам скорость 1 и 2 перепутаны с 1 и 2 буфером.
Кстати у вас вывод printf("Delta One: не синхротронный и там буквы да и цифры должны плясать чёрти как.]]> Pavia C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783951 Wed, 28 Nov 2018 11:53:42 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783951
Написал прогу на Си для тестирования различных вариантов буферизированной записи. Тестирование проводил на "живой ОС 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;

}

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

Screenshot_1.png (, : 429) Screenshot_2.png (, : 477)

Выводы:

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

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

Добавлено 28.11.18, 11:58
ЗЫ: Каждый из тестов запускал по несколько прогонов, тупо чтобы убедиться, что цифры "не пляшут". Как писал выше, с последним тестом с равными буферами для HDD USB - устойчивая разница. Везде разброс между запусками - доли секунды.]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783935 Wed, 28 Nov 2018 11:19:59 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783935 Цитата JoeUser @ 27.11.18, 19:00

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

Я когда-то экспериментировал, то получал, что начиная с некоторого совсем небольшого размера размер буфера перестаёт ускорять чтение-запись.]]> OpenGL C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783913 Wed, 28 Nov 2018 09:41:59 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783913 Цитата JoeUser @ 27.11.18, 11:26

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

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

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

А было время, когда этого не было.
В этом случае, ЦП должен был сам, программно, управлять
диском в реальном времени. Что не очень удобно, а в ситемах
типа Виндус крайне не выгодно.
(А я такие опыты производил в ситеме CPM/80. Писал процедуру
форматирования дискеток)
Поэтому в дивайсы стали устанавливать весьма интеллектуальные
контроллеры, а связь с внешним миром организовали через
общую память. Для того, чтобы максимальным образом
разгрузить центральный процессор.
-----
Похожая эволюция затрагивает практически любые дивайсы.
Например, сетевые карты. Видео-карты.]]> ЫукпШ C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783890 Wed, 28 Nov 2018 02:56:27 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783890 JoeUser

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

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

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

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

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

Да проседает на проценты.]]> Pavia C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783887 Tue, 27 Nov 2018 21:15:53 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783887 Цитата OpenGL @ 27.11.18, 10:19

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

Жалкие проценты никого не волнуют, но размер буфера конфигурируемым я сделал,
Дальше задача саппорта, буду делать stress test с файлами 20-25Мега на неделе,
выложу, благодарю за хинты, Я пока stand by.]]> sergioK C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783872 Tue, 27 Nov 2018 19:00:45 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783872 OpenGL, т.е. если диск может принять в свой кэш 64MБ, то все равно нужно забивать его мелкими порциями по 64КБ - и это будет по фэншую? А вот если установим свой программный кэш, к примеру в 16МБ, то получим (можем получить) просадку по скорости? :blink:]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783865 Tue, 27 Nov 2018 16:55:50 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783865 Цитата JoeUser @ 27.11.18, 11:26

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

Во-первых, при записи можно не ждать, когда установятся головки и под них подойдёт нужный блок, а записать данные в кэш и отчитаться, что операция выполнена. Реальную же запись выполнить, когда будет время.
Во-вторых, если после этого сразу начнётся чтение, можно придержать данные в кэше, прочитать нужные данные, а потом уже выбирать время для записи.
Можно накопить данные, и потом записать их в порядке, минимизирующем дёргание головок.
Специально для тех, кто не понимает разницу между высокоуровневым чтением из программного буфера и низкоуровневым с диска (встречал и такое), и пытающимся читать данные с диска по одному байту, можно не гонять головку к нужному блоку, а выдавать его прямо из памяти, уменьшив замедление работы с 1000 раз и более всего до 10.
Поскольку файлы хранятся на диске по-кластерно, а некоторые даже иногда подвергают диск дефрагментации, можно прочитать дорожку до конца в кэш, и заняться другими делами, по запросам выдавая уже прочитанные блоки.
Ну и последнее, многие не знают, но на современных дисках размер блока уже довольно давно не равен 512 байт (у меня в компе размер блока равен 4096 - 8 логических блоков, определяется при сбоях). Более того, реальные кластеры часто пересекают границы физических блоков на диске, и даже переходят с дорожки на дорожку. Чтобы сделать вид, что блок по-прежнему равен 512 байт. Приходится при чтении разбивать физические блоки на логические в кэше, а при записи собирать их обратно.]]> amk C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783849 Tue, 27 Nov 2018 11:26:10 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783849 Цитата OpenGL @ 27.11.18, 10:19

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

Возникает резонный вопрос - зачем тогда HDD обеспечивают аппаратным кэшем в 64/32/16/8 MB? :lol:]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783843 Tue, 27 Nov 2018 10:19:14 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783843 Цитата JoeUser @ 27.11.18, 09:18

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

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

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

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

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

Если жалкие проценты в быстродействии важны, то проще всего сделать размер буфера конфигурируемым, и на конкретной системе уже и выбирать наиболее подходящий размер.]]> OpenGL C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783840 Tue, 27 Nov 2018 09:18:01 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783840 Цитата OpenGL @ 27.11.18, 06:50

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

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

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

По-моему так: коль ТС заговорил о быстродействии - значит любой лучший результат существенен. Ну как-то так.]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783834 Tue, 27 Nov 2018 06:50:57 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783834 Цитата JoeUser @ 27.11.18, 06:34

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

Дай пруф на существенность что ли.]]> OpenGL C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783832 Tue, 27 Nov 2018 06:34:31 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783832 Цитата OpenGL @ 27.11.18, 06:16

Она уменьшит количество операций с контроллером винта. А это существенно.]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783830 Tue, 27 Nov 2018 06:16:44 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783830 Цитата JoeUser @ 24.11.18, 14:22

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

Вообще-то он прав - не нужно делать больше, чем размер кластера. Да и асинхронность тут никаким боком - она не уменьшит время, проходящее с момента запуска начала чтения до его конца.]]> OpenGL C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783792 Mon, 26 Nov 2018 12:45:10 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783792 Цитата 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

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

Проведи исследование.
Возьми какой-нибудь огромный файл.
И измеряй время его чтения, в зависимости от величины буфера.]]> ЫукпШ C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783765 Mon, 26 Nov 2018 01:32:20 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783765 Цитата JoeUser @ 24.11.18, 14:41

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

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

Всем спасибо но это была теория, что делать практически ? Ну я дам возможность
размер буфера брать из конфига, и ловить оптимальный вариант методом try && mistakes ?
Что конкретно в коде писать ?.]]> sergioK C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783700 Sat, 24 Nov 2018 15:21:31 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783700 Цитата JoeUser @ 24.11.18, 14:22

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

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

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

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

Вижу, поскольку "выплёвывание" кода тут вообще дело десятое. Всё зависит от того, какая система и куда идёт запись (откуда идет чтение). С некоторыми устройствами выгоднее вообще работать по-байтно.]]> amk C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783696 Sat, 24 Nov 2018 14:41:04 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783696 sergioK, рекомендую тебе подход - системный!

В ближнем приближении - твоя "система" тупо состоит из двух блоков "ввод" и "вывод". Количество там и там - роли не играет. Важен трансфер на входе и выходе. Берем "вход", ты писал HTTP. Там существенным критерием есть MTU. Но он крошечный - единственный разумный, имхо, момент - делать буффер кратный ему. На счет блоков вывода - я бы смотрел в сторону аппаратных возможностей записи. Уже писал выше - как минимум размера аппаратного кэша. Но есть и третий момент, который забывают очень часто!!! А именно - свободная память для ОС! Если об этом не заботиться - ОС переходит в жесткий режим свопа - а это, в плане производительности, считай - "обнять и плакать"! Таким образом, любые манипуляции с памятью не должны урезать разумные границы работы ОС. Это самое главное!!! Оно - самое самое, и оно - самое главное! Остальное - лайт тюнинг. Таковое мое ИМХО.]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783695 Sat, 24 Nov 2018 14:26:34 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783695 Цитата 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 C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783694 Sat, 24 Nov 2018 14:22:04 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783694 Славян и amk, вы вроде челы продвинутые, на такие косяки порете! :lol:

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

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

Не поймите, плс, меня превратно - я не спец в этом вопросе, и код не "выплюну" на раз-два. Но, концептуально, я - в теме. И чуйка подсказывает, что вы неправы. Очень глубоко, в своих глубинах :lol:]]> JoeUser C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783693 Sat, 24 Nov 2018 13:32:31 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783693 Увеличение размера буфера имеет смысл при копировании файлов в пределах одного физического носителя (с механическим доступом).
Но, для того, чтобы получить существенный выигрыш, недостаточно задавать буфер в вызовах функций fread/fwrite. Надо задать размер внутреннего буфера файла, используемого низкоуровневыми read/write.]]> amk C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783684 Sat, 24 Nov 2018 10:22:48 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783684 2. Не надо размер в несколько мегабайт (не больше), т.к. старые машины могут не найти столько памяти, а делать желательно для бо́льшего количества применений.
3. Главное: размер должен быть таков, чтобы время на количество вызовов функций для чтения (с учётом времени на вызов каждой) было незначительно в сравнении с временем чтения данных. Так, для SSD, скажем, желательно делать вызовов поменьше, ибо они данные читают шибче. Впрочем, предел=идеал всё равну будет манить: только 1 вызов. В то же время, если вдруг делаете попытки чтения битых файлов, то запросто может оказаться, что лучше наделать кучу микровызовов (чтобы хоть что-то прочитать), нежели всего один, кой скажет, что неудача,... и адью. :whistle:]]> Славян C/C++: Общие вопросы https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783679 Sat, 24 Nov 2018 09:14:01 +0000 FileBufferReader https://forum.sources.ru/index.php?showtopic=413817&view=findpost&p=3783679 пример для понятности на "проклятом" всеми чистом C,
просьба холиваров на темы C++ лучше, не разводить, ;) тут это не важно.

char buf[1024*512];

while (fgets(buf, sizeof(buf), fp) != NULL)

{

buf[strlen(buf) - 1] = '{text}'; // eat the newline fgets() stores

printf("%s\n", buf);

}

,

Как подбирать оптимальный размер баффера? почему .5мега а не 2 или 10?
Данные приходят по сети, обычным HTTP, В сети гуглил толком ничего по сути
не нашел, какие варианты ;)]]> sergioK C/C++: Общие вопросы