Улучшение/оптимизация скорости записи файлов в C++

Таким образом, основная проблема здесь заключается в том, что вы пытаетесь писать в том же потоке, что и получаете, а это означает, что ваш recv() может быть вызван снова только после завершения копирования. Несколько наблюдений:

• Перенесите запись в другую ветку. Речь идет об USRP, поэтому GNU Radio действительно может быть инструментом, который вы выберете — он по своей сути многопоточен.
• Ваш выходной итератор, вероятно, не самое эффективное решение. Просто «записать ()» в дескриптор файла может быть лучше, но это измерения производительности, которые зависят от вас.
• Если ваш жесткий диск/файловая система/ОС/ЦП не соответствуют скорости, поступающей от USRP, даже если отделить получение от записи по потоку, то вы ничего не можете сделать - получите более быструю систему.
• Вместо этого попробуйте записать на RAM-диск

На самом деле, я не знаю, как вы пришли к подходу std::copy. пример rx_samples_to_file, поставляемый с UHD, делает это с помощью простой записи, и вы определенно следует предпочесть это копированию; файловый ввод-вывод в хороших операционных системах часто может выполняться на одну копию меньше, а итерация по всем элементам, вероятно, очень медленная.

Давайте немного посчитаем.

Ваши образцы (очевидно) относятся к типу std::complex<std::float>. Учитывая (типичное) 32-битное число с плавающей запятой, это означает, что каждая выборка составляет 64 бита. При 10 MS/s это означает, что необработанные данные составляют около 80 мегабайт в секунду — это в пределах того, что вы можете ожидать при записи на жесткий диск настольного компьютера (7200 об/мин), но довольно близко к пределу (который обычно составляет около 100 мегабайт в секунду). -100 мегабайт в секунду или около того).

К сожалению, несмотря на std::ios::binary, вы на самом деле записываете данные в текстовом формате (поскольку std::ostream_iterator в основном выполняет stream << data;).

Это не только снижает точность, но и увеличивает размер данных, по крайней мере, как правило. Точная величина увеличения зависит от данных — небольшое целочисленное значение может фактически уменьшить количество данных, но для произвольного ввода увеличение размера, близкое к 2:1, является довольно распространенным явлением. С увеличением 2:1 ваши исходящие данные теперь составляют около 160 мегабайт в секунду, что быстрее, чем может обработать большинство жестких дисков.

Очевидной отправной точкой для улучшения было бы вместо этого записывать данные в двоичном формате:

uint32_t nItems = std::end(rxBuffer)-std::begin(rxBuffer);
outFile.write((char *)&nItems, sizeof(nItems));
outFile.write((char *)&rxBuffer[0], sizeof(rxBuffer));

На данный момент я использовал sizeof(rxBuffer) в предположении, что это реальный массив. Если на самом деле это указатель или вектор, вам нужно будет вычислить правильный размер (что вам нужно, так это общее количество записываемых байтов).

Я также хотел бы отметить, что на данный момент ваш код имеет еще более серьезную проблему: поскольку он не указал разделитель между элементами при записи данных, данные будут записываться без каких-либо элементов, отделяющих один элемент от следующий. Это означает, что если вы запишете два значения (например) 1 и 0.2, то, что вы прочитаете, будет не 1 и 0.2, а одно значение 10.2. Добавление разделителей к вашему текстовому выводу добавит еще больше накладных расходов (приблизительно на 15% больше данных) к процессу, который уже дает сбой, потому что генерирует слишком много данных.

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

Следующим шагом после этого будет переход к подпрограмме файлового ввода-вывода более низкого уровня. В зависимости от ситуации это может или не может иметь большого значения. В Windows вы можете указать FILE_FLAG_NO_BUFFERING при открытии файла с помощью CreateFile. Это означает, что операции чтения и записи в этот файл в основном будут выполняться в обход кеша и будут выполняться непосредственно на диск.

В вашем случае это, вероятно, выигрыш - при 10 MS/s вы, вероятно, довольно долго израсходуете пространство кеша, прежде чем перечитаете те же данные. В таком случае размещение данных в кеше практически ничего не даст, но вам придется потратить некоторые данные, чтобы скопировать данные в кеш, а затем несколько позже скопировать их на диск. Хуже того, он может загрязнить кэш всеми этими данными, поэтому он больше не хранит другие данные, которые, скорее всего, выиграют от кэширования.