Accelerera C/C++ fil I/O utan att svettas

Förord

Det finns ett så enkelt och mycket användbart verktyg i världen - BDelta, och det råkade vara så att den hade varit en del av vår produktionsprocess under mycket lång tid (även om vi inte kunde fastställa dess version, var den verkligen inte den senaste tillgängliga). Vi använder det för sitt avsedda syfte – att bygga binära patchar. Om man tittar på vad som finns i arkivet blir det lite sorgligt: ​​faktum är att det övergavs för länge sedan och mycket av det är väldigt föråldrat (min tidigare kollega gjorde en gång flera redigeringar där, men det var länge sedan). I allmänhet bestämde jag mig för att återuppliva den här saken: Jag gafflade, slängde ut det jag inte planerar att använda och flyttade projektet till cmmake, inlineade "heta" mikrofunktioner, tog bort stora arrayer från stacken (och arrayer med variabel längd, vilket ärligt talat "pumpade" mig), körde profileraren igen - och upptäckte att ungefär 40 % av tiden ägnas åt fwrite.

Så vad är det med fwrite?

I den här koden anropas fwrite (i mitt specifika testfall: att bygga en patch mellan tätt placerade 300 MB-filer, indata helt i minnet) miljontals gånger med en liten buffert. Det är uppenbart att det här kommer att sakta ner, och därför skulle jag vilja påverka denna skam på något sätt. Det finns ingen önskan att implementera olika typer av datakällor eller asynkron input/output ännu; Jag skulle vilja hitta en enklare lösning. Det första jag tänkte på var att öka buffertstorleken.

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

men jag fick ingen signifikant förbättring av resultatet (nu stod fwrite för cirka 37 % av tiden) – så problemet ligger inte i frekvent skrivning av data till disk. Om man tittar "under huven" på fwrite kan man se att låsning/upplåsning av FILE-strukturer sker inuti något liknande detta (pseudokod, all analys utfördes under Visual Studio 2017):

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;
}

Enligt profileraren står _fwrite_nolock endast för 6 % av tiden, resten är omkostnader. I mitt specifika fall är trådsäkerhet helt klart redundant, så jag kommer att offra den genom att ersätta fwrite-anropet med _fwrite_nolock — det finns ingen anledning att ens vara smart med argument. Totalt sett minskade denna enkla manipulation kostnaderna för att registrera resultatet flera gånger, vilket i originalversionen stod för nästan hälften av den tidsåtgång som användes. Förresten, det finns en liknande funktion i POSIX-världen - fwrite_unlocked. Generellt sett gäller detsamma för fread. Således, med hjälp av ett par #define s, kan du få en helt plattformsoberoende lösning utan onödiga lås ifall de inte behövs (och detta händer ganska ofta).

fwrite, _fwrite_nolock, setvbuf

Låt oss gå ifrån det ursprungliga projektet och fokusera på att testa ett specifikt fall: att skriva en stor fil (512 MB) i extremt små bitar – en byte vardera. Testsystem: AMD Ryzen 7 1700, 16 GB RAM, 7200 rpm hårddisk, 64 MB cache. Windows 10 1809, binärfilen byggdes som 32-bitars, optimeringar är aktiverade och biblioteket är statiskt länkat.

Prov för experimentet:

#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;
}

Variablerna kommer att vara TEST_BUFFER_SIZE, och i ett par fall kommer vi att ersätta fwrite_unlocked med fwrite. Låt oss börja med fwrite-fallet utan att explicit ange buffertstorleken (kommentera ut setvbuf och tillhörande kod): tid 27048906 µs, skrivhastighet 18.93 MB/s. Nu ställer vi in ​​buffertstorleken till 64 KB: tid - 25037111 µs, hastighet - 20.44 Mbps. Nu ska vi testa funktionen hos _fwrite_nolock utan att anropa setvbuf: 7262221 µs, hastighet - 70.5 Mb/s!

Nu ska vi experimentera med buffertstorleken (setvbuf):

Data erhölls genom att medelvärdet beräknades för 5 experiment; Jag var för lat för att beräkna felen. Enligt min mening är 93 MB/s när man skriver 1 byte till en vanlig hårddisk ett mycket bra resultat, allt du behöver göra är att välja den optimala buffertstorleken (i mitt fall är 256 KB precis lagom) och ersätta fwrite med _fwrite_nolock/fwrite_unlocked (ifall du inte behöver trådsäkerhet förstås).
Det är samma sak med fread under liknande förhållanden. Eftersom jag inte har en maskin med Linux till hands (enkortsdatorer räknas inte), bestämde jag mig för att genomföra ett begränsat experiment på en virtuell maskin (Hyper-V, OpenSUSE 15, GCC 8.3.1) — mönstret är i princip detsamma: bara fwrite 20 Mb/s, fwrite + 256 KB buffert gav 23 Mb/s, fwrite_unlocked med samma buffert — 35 Mb/s (64-bitars binär, kompilerad med g++ -o2 -s -static-libgcc -static-libstdc++ fwrite_test.cpp -o fwrite_test).

efterordet

Syftet med att skriva den här artikeln var att beskriva en enkel och effektiv teknik i många fall (jag har aldrig stött på funktionerna _fwrite_nolock/fwrite_unlocked förut, de är inte särskilt populära - och förgäves). Jag påstår inte att materialet är nytt, men jag hoppas att artikeln kommer att vara användbar för samhället.

Källa: will.com