Каков наилучший способ реализации буфера фиксированного размера при использовании fread в C ++?

Question

Каков наилучший способ реализации буфера фиксированного размера при использовании fread в C ++?

0

Предположим, что у вас есть файл целых чисел, и вы хотите их прочитать по одному.

У вас есть два варианта буферизации.

Объявите buffer массива размера N и используйте setvbuf чтобы указать fread какой буфер использовать. Затем, вызывая функцию fread для чтения целого числа, вы пишете fread(&myInt, sizeof(myInt), 1, inputFile);
Объявите тот же buffer массива, но на этот раз не используйте функцию setvbuf. Вместо этого работайте над буферизацией самостоятельно. Таким образом, вызов fread(buffer, bufferSize*sizeof(int), 1, inputFile)

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

jsguy 14 окт. 2014, в 22:16

Источник

3

Мой вопрос: почему вы используете fread в C ++?
NetVipeC 14 окт. 2014, в 19:50
0

Лично я склонен просто писать свои собственные классы ввода / вывода поверх системных вызовов open , read и write , поскольку мне не нравится интерфейс stdio или iostream
o11c 14 окт. 2014, в 19:51
0

Смысл stdio (и iostream) в том, что вы позволяете системе делать за вас буферизацию. Просто прочитайте столько октетов, сколько вам нужно, используя fread или getc , и stdio обеспечит буферизацию чтений на уровне ОС. setvbuf предназначен только для тех редких случаев, когда вы хотите сами управлять размером / распределением буфера. setvbuf правило: если вам нужно спросить, нужен ли вам setvbuf , вам не нужно.
user4815162342 14 окт. 2014, в 19:54
0

NetVipeC, для целей тестирования, я бы не использовал его в C ++
jsguy 14 окт. 2014, в 19:59

Показать ещё 2 комментария

Теги:

c++

performance

fread

1 ответ

Ещё вопросы

Мой вопрос: почему вы используете fread в C ++?
Лично я склонен просто писать свои собственные классы ввода / вывода поверх системных вызовов open , read и write , поскольку мне не нравится интерфейс stdio или iostream
Смысл stdio (и iostream) в том, что вы позволяете системе делать за вас буферизацию. Просто прочитайте столько октетов, сколько вам нужно, используя fread или getc , и stdio обеспечит буферизацию чтений на уровне ОС. setvbuf предназначен только для тех редких случаев, когда вы хотите сами управлять размером / распределением буфера. setvbuf правило: если вам нужно спросить, нужен ли вам setvbuf , вам не нужно.
NetVipeC, для целей тестирования, я бы не использовал его в C ++

Thomas Matthews · Accepted Answer · 2014-10-14T17-52-00.000Z

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

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

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

Еще одним узким местом, связанным с вводом-выводом, является продолжительность между входными запросами. Устройства ввода/вывода предпочитают сохранять потоковые данные без остановок. Некоторые устройства ввода, такие как жесткие диски, имеют временное время между получением запроса и началом передачи данных. Для жестких дисков это будет время ускорения диска.

Лучшая производительность - это не тратить время на разработку приложений с библиотеками C или C++. Вам нужно использовать аппаратную помощь. На некоторых платформах есть устройство, называемое контроллером прямого доступа к памяти (DMA). Это устройство может принимать данные из источника ввода и доставлять их в память без использования процессора. ЦП может выполнять команды, в то время как DMA передает данные. Чтобы использовать аппаратную помощь, вам нужно написать код на уровне драйвера ОС или напрямую обратиться к драйверам ОС.

Библиотеки ввода-вывода C и C++ предназначены для независимой от платформы концепции, называемой потоками. Это могут быть связанные с этим накладные расходы (например, дополнительная буферизация). Если вам не нужны разные платформы, обратитесь к драйверам ОС напрямую.

Не тратьте время на общение с библиотеками C и C++. Не так много прироста производительности. Более высокая производительность заключается в непосредственном доступе к драйверам ОС (или использованию их собственных). Как и когда вы получаете доступ к вводу/выводу, вы получите больше прироста производительности, чем настройку библиотек C и C++.

Наконец, использование кэша данных процессоров эффективно также даст вам производительность.

"ускорить время"? Возможно, вы имели в виду «раскрутить»?
Кроме того, переключение с C ++ <fstream> на C (и C ++) <stdio.h> помогает ... настолько удивительно. Но да, прямое использование API-интерфейсов ОС, таких как mmap превосходит <stdio.h> .
Я не знаю, что дает вам идею, что DMA не будет происходить через обычные API пользовательского режима и оболочки.
Я не понимаю, зачем создавать fstream, когда у вас есть stdio. C также является частью C ++, верно? Тогда почему бы не использовать stdio и решить создать что-то, что действительно плохо работает с эквивалентной версией в C?
@BenVoigt: не все платформы имеют DMA. Некоторые платформы могут иметь DMA и не использовать его. Это не стандартно, и использование DMA зависит от ОС или драйверов устройств. Это также ресурс, который нуждается в обмене.
@jsguy: есть возможность переопределить operator<< для новых типов. Расширяемость - большое преимущество API C ++. Но производительность жалкая, как и отсутствие разделения интересов. Вокруг идет много дискуссий, чтобы сделать это лучше.
@ThomasMatthews: Но если в вашей платформе есть драйверы, использующие DMA, то на основе этих драйверов будут реализованы реализации API доступа к файлам POSIX, C и C ++. «Для того, чтобы получить DMA» не является веской причиной для приложений, чтобы перейти на API-интерфейсы ОС.