힘들이지 않고 C/C++ 파일 I/O 가속화

머리말

세상에는 이렇게 간단하고 매우 유용한 유틸리티가 있습니다. B델타, 그리고 그것은 매우 오랫동안 우리 생산 과정에 뿌리 박혀 있었습니다(비록 해당 버전을 설치할 수는 없었지만 확실히 마지막으로 사용 가능한 버전은 아니었습니다). 우리는 이를 의도된 목적, 즉 바이너리 패치 구축에 사용합니다. 저장소에 있는 내용을 보면 조금 슬프게 됩니다. 사실 저장소는 오래 전에 버려졌고 대부분이 매우 구식입니다. (내 전 동료가 그곳에서 여러 번 편집한 적이 있지만 그건 오래 전 일입니다.) . 일반적으로 나는 이 문제를 부활시키기로 결정했습니다. 나는 포크하고, 사용할 계획이 없는 것을 버리고, 프로젝트를 다음으로 옮겼습니다. cmake, 인라인된 "핫" 마이크로 함수, 스택에서 큰 배열(및 솔직하게 "폭탄"으로 만드는 가변 길이 배열)을 제거하고 프로파일러를 다시 한 번 실행한 결과 약 40%의 시간이 작업에 소비된다는 사실을 알게 되었습니다. 쓰기...

그럼 fwrite는 어떻게 됐나요?

이 코드에서 fwrite(내 특정 테스트 사례: 가까운 300MB 파일 사이에 패치를 구축하고 입력 데이터가 전적으로 메모리에 있음)는 작은 버퍼 크기로 수백만 번 호출됩니다. 분명히 이 일이 느려질 것이므로 나는 어떻게든 이 불명예에 영향을 미치고 싶습니다. 아직은 다양한 유형의 데이터 소스, 비동기 입출력을 구현하려는 욕구가 없으며 더 간단한 솔루션을 찾고 싶었습니다. 가장 먼저 떠오른 것은 버퍼 크기를 늘리는 것이었습니다.

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

그러나 결과는 크게 향상되지 않았습니다(현재 fwrite가 전체 시간의 약 37%를 차지함). 이는 여전히 디스크에 데이터를 자주 쓰는 문제가 아니라는 의미입니다. fwrite의 "내부"를 보면 FILE 잠금/잠금 해제 구조가 다음과 같은 내부에서 발생하고 있음을 알 수 있습니다(의사 코드, 모든 분석은 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;
}

프로파일러에 따르면 _fwrite_nolock은 시간의 6%만 차지하며 나머지는 오버헤드입니다. 내 특별한 경우에는 스레드 안전성이 확실히 과잉이므로 fwrite 호출을 다음으로 대체하여 스레드 안전성을 희생하겠습니다. _fwrite_nolock - 논쟁에 능숙할 필요도 없습니다. 전체: 이 간단한 조작으로 인해 결과 기록 비용이 크게 줄어들었으며 원본 버전에서는 소요 시간의 거의 절반에 달했습니다. 그건 그렇고, POSIX 세계에도 비슷한 기능이 있습니다. fwrite_unlocked. 일반적으로 말하면 fread에도 동일하게 적용됩니다. 따라서 한 쌍의 #define을 사용하면 필요하지 않은 경우 불필요한 잠금 없이 완전히 크로스 플랫폼 솔루션을 얻을 수 있습니다(이런 일은 꽤 자주 발생합니다).

fwrite, _fwrite_nolock, setvbuf

원래 프로젝트에서 벗어나 특정 사례를 테스트해 보겠습니다. 바로 512MB 크기의 파일을 1바이트씩 아주 작은 덩어리로 나누어 쓰는 것입니다. 테스트 시스템 사양은 다음과 같습니다. AMD Ryzen 7 1700, 16GB RAM, 7200rpm HDD, 64MB 캐시. Windows 10 1809년 버전에서 바이너리는 32비트로 빌드되었고, 최적화가 활성화되었으며, 라이브러리는 정적으로 링크되었습니다.

실험 샘플:

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

변수는 TEST_BUFFER_SIZE가 되며, 몇 가지 경우에 fwrite_unlocked를 fwrite로 대체합니다. 버퍼 크기를 명시적으로 설정하지 않고 fwrite 사례부터 시작하겠습니다(setvbuf 및 관련 코드 주석 처리). 시간 27048906 µs, 쓰기 속도 - 18.93 MB/s. 이제 버퍼 크기를 64KB(시간 - 25037111μs, 속도 - 20.44Mb/s)로 설정해 보겠습니다. 이제 setvbuf를 호출하지 않고 _fwrite_nolock의 작동을 테스트해 보겠습니다: 7262221 µs, 속도 - 70.5 Mb/s!

다음으로 버퍼 크기(setvbuf)를 실험해 보겠습니다.

5번의 실험을 평균하여 데이터를 얻었는데 너무 게을러서 오차를 계산할 수가 없었습니다. 나로서는 일반 HDD에 93바이트를 쓸 때 1MB/s가 매우 좋은 결과입니다. 최적의 버퍼 크기를 선택하고(제 경우에는 256KB가 딱 맞습니다) fwrite를 _fwrite_nolock/fwrite_unlocked( 물론 스레드 안전성이 필요하지 않은 경우).
비슷한 조건에서 fread도 마찬가지입니다. Linux가 설치된 하드웨어 머신이 없기 때문에(단일 보드는 포함되지 않음) 가상 머신(Hyper-V, OpenSUSE 15, GCC 8.3.1)에서 제한된 실험을 수행하기로 결정했습니다. 패턴은 다음과 같습니다. 기본적으로 동일: "네이키드" fwrite 20 Mb/s, fwrite + 256 KB 버퍼는 23 Mb/s를 생성, fwrite_unlocked는 동일한 버퍼 - 35 Mb/s(64비트 바이너리, 어셈블된 g++ -o2 -s -static-libgcc -static-libstdc++ fwrite_test.cpp -o fwrite_test).

사후

이 글을 쓴 목적은 많은 경우에 간단하고 효과적인 기술을 설명하는 것이었습니다. (나는 이전에 _fwrite_nolock/fwrite_unlocked 함수를 접해본 적이 없으며 그다지 인기가 없지만 헛된 것입니다.) 나는 그 자료가 새로운 것이라고 주장하지 않지만, 그 기사가 커뮤니티에 도움이 되기를 바랍니다.

출처 : habr.com