Beschleunigen Sie die E/A von C/C++-Dateien, ohne ins Schwitzen zu geraten

Vorwort

Es gibt so ein einfaches und sehr nützliches Dienstprogramm auf der Welt - BDelta, und so kam es, dass es schon sehr lange in unserem Produktionsprozess verankert war (obwohl es nicht möglich war, seine Version zu installieren, aber es war definitiv nicht die letzte verfügbare Version). Wir verwenden es für den vorgesehenen Zweck – die Erstellung von Binär-Patches. Wenn man sich ansieht, was sich im Repository befindet, wird es ein wenig traurig: Tatsächlich wurde es vor langer Zeit aufgegeben und vieles davon ist sehr veraltet (mein ehemaliger Kollege hat dort einmal mehrere Änderungen vorgenommen, aber das ist lange her). . Im Allgemeinen habe ich beschlossen, diese Angelegenheit wiederzubeleben: Ich habe gespalten, weggeworfen, was ich nicht verwenden wollte, und das Projekt dorthin verschoben cmake, integrierte „heiße“ Mikrofunktionen, entfernte große Arrays vom Stapel (und Arrays variabler Länge, die mich, ehrlich gesagt, „zu einer Bombe“ machen), ließ den Profiler noch einmal laufen – und stellte fest, dass etwa 40 % der Zeit dafür aufgewendet wird fschreiben...

Was ist also mit fwrite los?

In diesem Code wird fwrite (in meinem speziellen Testfall: Erstellen eines Patches zwischen knapp 300 MB großen Dateien, die Eingabedaten liegen vollständig im Speicher) millionenfach mit einer kleinen Puffergröße aufgerufen. Offensichtlich wird sich diese Sache verlangsamen, und deshalb möchte ich diese Schande irgendwie beeinflussen. Es besteht noch kein Wunsch, verschiedene Arten von Datenquellen und asynchrone Eingabe-Ausgabe zu implementieren. Ich wollte eine einfachere Lösung finden. Das erste, was mir in den Sinn kam, war, die Puffergröße zu erhöhen

setvbuf(file, nullptr, _IOFBF, 64* 1024)

Ich habe jedoch keine wesentliche Verbesserung des Ergebnisses erzielt (jetzt machte fwrite etwa 37 % der Zeit aus) – was bedeutet, dass es immer noch nicht darum geht, häufig Daten auf die Festplatte zu schreiben. Wenn Sie „unter die Haube“ von fwrite blicken, können Sie erkennen, dass in etwa dieser Dateistruktur eine Sperre/Entsperrung stattfindet (Pseudocode, alle Analysen wurden unter Visual Studio 2017 durchgeführt):

size_t fwrite (const void *buffer, size_t size, size_t count, FILE *stream)
{
   size_t retval = 0;
   _lock_str(stream);   /* lock stream */
   __try
   {
      retval = _fwrite_nolock(buffer, size, count, stream);
   }
   __finally 
   {
       _unlock_str(stream);   /* unlock stream */
   }
   return retval;
}

Laut Profiler macht _fwrite_nolock nur 6 % der Zeit aus, der Rest ist Overhead. In meinem speziellen Fall ist die Thread-Sicherheit eindeutig übertrieben, daher werde ich sie opfern, indem ich den fwrite-Aufruf durch ersetze _fwrite_nolock - Sie müssen nicht einmal geschickt mit Argumenten umgehen können. Insgesamt: Diese einfache Manipulation reduzierte den Aufwand für die Ergebnisaufzeichnung erheblich, der in der Originalversion fast die Hälfte des Zeitaufwands ausmachte. In der POSIX-Welt gibt es übrigens eine ähnliche Funktion - fwrite_unlocked. Im Allgemeinen gilt das Gleiche auch für Fread. Wenn Sie also ein Paar #defines verwenden, können Sie eine vollständig plattformübergreifende Lösung ohne unnötige Sperren erhalten, wenn diese nicht erforderlich sind (was häufig vorkommt).

fwrite, _fwrite_nolock, setvbuf

Wir wenden uns vom ursprünglichen Projekt ab und konzentrieren uns auf einen konkreten Anwendungsfall: das Schreiben einer großen Datei (512 MB) in extrem kleinen Teilen – jeweils ein Byte. Testsystem: AMD Ryzen 7 1700, 16 GB RAM, 7200-U/min-Festplatte, 64 MB Cache. Windows 10 1809 wurde die Binärdatei als 32-Bit erstellt, Optimierungen sind aktiviert, die Bibliothek ist statisch verlinkt.

Beispiel für das Experiment:

#include <chrono>
#include <cstdio>
#include <inttypes.h>
#include <memory>

#ifdef _MSC_VER
#define fwrite_unlocked _fwrite_nolock
#endif

using namespace std::chrono;

int main()
{
    std::unique_ptr<FILE, int(*)(FILE*)> file(fopen("test.bin", "wb"), fclose);
    if (!file)
        return 1;

    constexpr size_t TEST_BUFFER_SIZE = 256 * 1024;
    if (setvbuf(file.get(), nullptr, _IOFBF, TEST_BUFFER_SIZE) != 0)
        return 2;

    auto start = steady_clock::now();
    const uint8_t b = 77;
    constexpr size_t TEST_FILE_SIZE = 512 * 1024 * 1024;
    for (size_t i = 0; i < TEST_FILE_SIZE; ++i)
        fwrite_unlocked(&b, 1, sizeof(b), file.get());

    auto end = steady_clock::now();
    auto interval = duration_cast<microseconds>(end - start);
    printf("Time: %lldn", interval.count());

    return 0;
}

Die Variablen lauten TEST_BUFFER_SIZE und in einigen Fällen ersetzen wir fwrite_unlocked durch fwrite. Beginnen wir mit dem fwrite-Fall, ohne die Puffergröße explizit festzulegen (setvbuf und den zugehörigen Code auskommentieren): Zeit 27048906 µs, Schreibgeschwindigkeit – 18.93 MB/s. Stellen wir nun die Puffergröße auf 64 KB ein: Zeit – 25037111 μs, Geschwindigkeit – 20.44 Mbit/s. Testen wir nun die Funktionsweise von _fwrite_nolock, ohne setvbuf aufzurufen: 7262221 µs, Geschwindigkeit – 70.5 Mbit/s!

Als nächstes experimentieren wir mit der Puffergröße (setvbuf):

Die Daten wurden durch Mittelung von 5 Experimenten ermittelt; ich war zu faul, die Fehler zu berechnen. Für mich sind 93 MB/s beim Schreiben von 1 Byte auf eine normale Festplatte ein sehr gutes Ergebnis. Sie müssen nur die optimale Puffergröße auswählen (in meinem Fall sind 256 KB genau richtig) und fwrite durch _fwrite_nolock/fwrite_unlocked ersetzen ( für den Fall, dass Thread-Sicherheit nicht benötigt wird, natürlich).
Ebenso mit Fread unter ähnlichen Bedingungen. Da ich keine Hardware-Maschine mit Linux zur Hand habe (Einplatinencomputer zählen nicht), habe ich beschlossen, ein begrenztes Experiment auf einer virtuellen Maschine (Hyper-V, OpenSUSE 15, GCC 8.3.1) durchzuführen – der Das Muster ist im Prinzip dasselbe: „nacktes“ fwrite 20 Mbit/s, fwrite + 256 KB Puffer erzeugt 23 Mbit/s, fwrite_unlocked mit demselben Puffer – 35 Mbit/s (64-Bit-Binärdatei, assembliertes G++ -o2 - s -static-libgcc -static-libstdc++ fwrite_test.

Nachwort

Der Zweck dieses Artikels bestand darin, eine einfache und in vielen Fällen effektive Technik zu beschreiben (die Funktionen _fwrite_nolock/fwrite_unlocked sind mir noch nie begegnet, sie sind nicht sehr beliebt – aber vergebens). Ich behaupte nicht, dass das Material neu ist, aber ich hoffe, dass der Artikel für die Community nützlich sein wird.

Source: habr.com