Viết một tệp nhị phân trong C ++ rất nhanh

Tôi đang cố gắng ghi một lượng lớn dữ liệu vào ổ SSD của mình (ổ đĩa trạng thái rắn). Và với số tiền rất lớn, ý tôi là 80GB.

Tôi duyệt web để tìm giải pháp, nhưng điều tốt nhất tôi nghĩ ra là:

#include <fstream>
const unsigned long long size = 64ULL*1024ULL*1024ULL;
unsigned long long a[size];
int main()
{
    std::fstream myfile;
    myfile = std::fstream("file.binary", std::ios::out | std::ios::binary);
    //Here would be some error handling
    for(int i = 0; i < 32; ++i){
        //Some calculations to fill a[]
        myfile.write((char*)&a,size*sizeof(unsigned long long));
    }
    myfile.close();
}

Được biên dịch với Visual Studio 2010 và tối ưu hóa đầy đủ và chạy trong Windows7, chương trình này đạt tối đa khoảng 20MB / s. Điều thực sự làm phiền tôi là Windows có thể sao chép các tệp từ một ổ SSD khác sang ổ SSD này ở khoảng từ 150MB / s đến 200MB / s. Vì vậy, nhanh hơn ít nhất 7 lần. Đó là lý do tại sao tôi nghĩ rằng tôi sẽ có thể đi nhanh hơn.

Bất kỳ ý tưởng làm thế nào tôi có thể tăng tốc độ viết của tôi?

Điều này đã làm công việc (trong năm 2012):

#include <stdio.h>
const unsigned long long size = 8ULL*1024ULL*1024ULL;
unsigned long long a[size];

int main()
{
    FILE* pFile;
    pFile = fopen("file.binary", "wb");
    for (unsigned long long j = 0; j < 1024; ++j){
        //Some calculations to fill a[]
        fwrite(a, 1, size*sizeof(unsigned long long), pFile);
    }
    fclose(pFile);
    return 0;
}

Tôi chỉ hẹn giờ 8GB trong 36 giây, tốc độ khoảng 220 MB / giây và tôi nghĩ rằng tối đa hóa SSD của mình. Cũng đáng lưu ý, mã trong câu hỏi đã sử dụng một lõi 100%, trong khi mã này chỉ sử dụng 2-5%.

Cảm ơn mọi người rất nhiều.

Cập nhật : 5 năm đã trôi qua 2017. Trình biên dịch, phần cứng, thư viện và yêu cầu của tôi đã thay đổi. Đó là lý do tại sao tôi thực hiện một số thay đổi đối với mã và thực hiện một số phép đo mới.

Đầu tiên lên mã:

#include <fstream>
#include <chrono>
#include <vector>
#include <cstdint>
#include <numeric>
#include <random>
#include <algorithm>
#include <iostream>
#include <cassert>

std::vector<uint64_t> GenerateData(std::size_t bytes)
{
    assert(bytes % sizeof(uint64_t) == 0);
    std::vector<uint64_t> data(bytes / sizeof(uint64_t));
    std::iota(data.begin(), data.end(), 0);
    std::shuffle(data.begin(), data.end(), std::mt19937{ std::random_device{}() });
    return data;
}

long long option_1(std::size_t bytes)
{
    std::vector<uint64_t> data = GenerateData(bytes);

    auto startTime = std::chrono::high_resolution_clock::now();
    auto myfile = std::fstream("file.binary", std::ios::out | std::ios::binary);
    myfile.write((char*)&data[0], bytes);
    myfile.close();
    auto endTime = std::chrono::high_resolution_clock::now();

    return std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime).count();
}

long long option_2(std::size_t bytes)
{
    std::vector<uint64_t> data = GenerateData(bytes);

    auto startTime = std::chrono::high_resolution_clock::now();
    FILE* file = fopen("file.binary", "wb");
    fwrite(&data[0], 1, bytes, file);
    fclose(file);
    auto endTime = std::chrono::high_resolution_clock::now();

    return std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime).count();
}

long long option_3(std::size_t bytes)
{
    std::vector<uint64_t> data = GenerateData(bytes);

    std::ios_base::sync_with_stdio(false);
    auto startTime = std::chrono::high_resolution_clock::now();
    auto myfile = std::fstream("file.binary", std::ios::out | std::ios::binary);
    myfile.write((char*)&data[0], bytes);
    myfile.close();
    auto endTime = std::chrono::high_resolution_clock::now();

    return std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime).count();
}

int main()
{
    const std::size_t kB = 1024;
    const std::size_t MB = 1024 * kB;
    const std::size_t GB = 1024 * MB;

    for (std::size_t size = 1 * MB; size <= 4 * GB; size *= 2) std::cout << "option1, " << size / MB << "MB: " << option_1(size) << "ms" << std::endl;
    for (std::size_t size = 1 * MB; size <= 4 * GB; size *= 2) std::cout << "option2, " << size / MB << "MB: " << option_2(size) << "ms" << std::endl;
    for (std::size_t size = 1 * MB; size <= 4 * GB; size *= 2) std::cout << "option3, " << size / MB << "MB: " << option_3(size) << "ms" << std::endl;

    return 0;
}

Mã này biên dịch với Visual Studio 2017 và g ++ 7.2.0 (một yêu cầu mới). Tôi đã chạy mã với hai thiết lập:

• Máy tính xách tay, Core i7, SSD, Ubuntu 16.04, g ++ Phiên bản 7.2.0 với -std = c ++ 11 -march = bản địa -O3
• Máy tính để bàn, Core i7, SSD, Windows 10, Visual Studio 2017 Phiên bản 15.3.1 với / Ox / Ob2 / Oi / Ot / GT / GL / Gy

Việc đưa ra các phép đo sau (sau khi bỏ các giá trị trong 1MB, vì chúng là các ngoại lệ rõ ràng): Cả hai lần tùy chọn1 và tùy chọn3 đều tối đa hóa SSD của tôi. Tôi không mong đợi điều này sẽ thấy, bởi vì tùy chọn 2 trước đây là mã nhanh nhất trên máy cũ của tôi.

TL; DR : Các phép đo của tôi cho thấy sử dụng std::fstreamhơn FILE.

Hãy thử các cách sau, theo thứ tự:

• Kích thước bộ đệm nhỏ hơn. Viết ~ 2 MiB tại một thời điểm có thể là một khởi đầu tốt. Trên máy tính xách tay cuối cùng của tôi, ~ 512 KiB là điểm hấp dẫn, nhưng tôi chưa thử nghiệm trên SSD của mình.

  Lưu ý: Tôi đã nhận thấy rằng bộ đệm rất lớn có xu hướng giảm hiệu suất. Tôi đã nhận thấy sự mất tốc độ khi sử dụng bộ đệm 16-MiB thay vì bộ đệm 512-KiB trước đây.

• Sử dụng _open(hoặc _topennếu bạn muốn chính xác Windows) để mở tệp, sau đó sử dụng _write. Điều này có thể sẽ tránh được rất nhiều bộ đệm, nhưng nó không chắc chắn.

• Sử dụng các chức năng dành riêng cho Windows như CreateFilevà WriteFile. Điều đó sẽ tránh bất kỳ bộ đệm trong thư viện tiêu chuẩn.

Tôi thấy không có sự khác biệt giữa std :: stream / FILE / thiết bị. Giữa đệm và không đệm.

Cũng lưu ý:

• Ổ SSD "có xu hướng" chậm lại (tốc độ truyền thấp hơn) khi chúng đầy.
• Ổ SSD "có xu hướng" chậm lại (tốc độ truyền thấp hơn) khi chúng cũ hơn (vì các bit không hoạt động).

Tôi đang thấy mã chạy trong 63 giây.
Do đó, tốc độ truyền tải là: 260M / s (SSD của tôi trông nhanh hơn một chút so với của bạn).

64 * 1024 * 1024 * 8 /*sizeof(unsigned long long) */ * 32 /*Chunks*/

= 16G
= 16G/63 = 260M/s

Tôi không tăng thêm bằng cách chuyển sang TẬP_TIN * từ std :: fux.

#include <stdio.h>

using namespace std;

int main()
{
    
    FILE* stream = fopen("binary", "w");

    for(int loop=0;loop < 32;++loop)
    {
         fwrite(a, sizeof(unsigned long long), size, stream);
    }
    fclose(stream);

}

Vì vậy, luồng C ++ đang hoạt động nhanh như thư viện cơ bản sẽ cho phép.

Nhưng tôi nghĩ thật không công bằng khi so sánh HĐH với một ứng dụng được xây dựng trên đỉnh của HĐH. Ứng dụng có thể không đưa ra giả định (không biết các ổ đĩa là SSD) và do đó sử dụng các cơ chế tệp của HĐH để chuyển.

Trong khi HĐH không cần đưa ra bất kỳ giả định nào. Nó có thể cho biết các loại ổ đĩa liên quan và sử dụng kỹ thuật tối ưu để truyền dữ liệu. Trong trường hợp này một bộ nhớ trực tiếp để chuyển bộ nhớ. Hãy thử viết một chương trình sao chép 80G từ 1 vị trí trong bộ nhớ sang vị trí khác và xem tốc độ đó nhanh như thế nào.

Biên tập

Tôi đã thay đổi mã của mình để sử dụng các cuộc gọi cấp thấp hơn:
tức là không có bộ đệm.

#include <fcntl.h>
#include <unistd.h>


const unsigned long long size = 64ULL*1024ULL*1024ULL;
unsigned long long a[size];
int main()
{
    int data = open("test", O_WRONLY | O_CREAT, 0777);
    for(int loop = 0; loop < 32; ++loop)
    {   
        write(data, a, size * sizeof(unsigned long long));
    }   
    close(data);
}

Điều này làm cho không có sự khác biệt.

LƯU Ý : Ổ đĩa của tôi là ổ SSD nếu bạn có ổ đĩa bình thường, bạn có thể thấy sự khác biệt giữa hai kỹ thuật trên. Nhưng như tôi mong đợi không đệm và đệm (khi viết các đoạn lớn lớn hơn kích thước bộ đệm) sẽ không có sự khác biệt.

Chỉnh sửa 2:

Bạn đã thử phương pháp sao chép tệp nhanh nhất trong C ++ chưa

int main()
{
    std::ifstream  input("input");
    std::ofstream  output("ouptut");

    output << input.rdbuf();
}

Giải pháp tốt nhất là thực hiện viết không đồng bộ với bộ đệm đôi.

Nhìn vào dòng thời gian:

------------------------------------------------>
FF|WWWWWWWW|FF|WWWWWWWW|FF|WWWWWWWW|FF|WWWWWWWW|

'F' biểu thị thời gian để điền vào bộ đệm và 'W' biểu thị thời gian ghi bộ đệm vào đĩa. Vì vậy, vấn đề lãng phí thời gian giữa việc viết bộ đệm vào tập tin. Tuy nhiên, bằng cách thực hiện viết trên một luồng riêng biệt, bạn có thể bắt đầu điền vào bộ đệm tiếp theo ngay sau đây:

------------------------------------------------> (main thread, fills buffers)
FF|ff______|FF______|ff______|________|
------------------------------------------------> (writer thread)
  |WWWWWWWW|wwwwwwww|WWWWWWWW|wwwwwwww|

F - điền vào bộ đệm thứ nhất
f - điền vào bộ đệm thứ 2
W - ghi bộ đệm thứ nhất vào tệp
w - ghi bộ đệm thứ 2 vào tệp
_ - chờ trong khi thao tác hoàn tất

Cách tiếp cận này với hoán đổi bộ đệm rất hữu ích khi điền vào bộ đệm đòi hỏi tính toán phức tạp hơn (do đó, mất nhiều thời gian hơn). Tôi luôn triển khai lớp CSequentialStreamWriter ẩn cách viết không đồng bộ bên trong, vì vậy đối với người dùng cuối, giao diện chỉ có (các) chức năng Viết.

Và kích thước bộ đệm phải là bội số của kích thước cụm đĩa. Nếu không, bạn sẽ kết thúc với hiệu suất kém bằng cách ghi một bộ đệm vào 2 cụm đĩa liền kề.

Viết bộ đệm cuối cùng.
Khi bạn gọi hàm Write lần cuối, bạn phải chắc chắn rằng bộ đệm hiện tại đang được điền cũng nên được ghi vào đĩa. Do đó, CSequentialStreamWriter nên có một phương thức riêng, giả sử Finalize (bộ đệm cuối cùng), ghi vào đĩa cuối cùng của dữ liệu.

Xử lý lỗi.
Trong khi mã bắt đầu điền vào bộ đệm thứ 2 và mã thứ nhất đang được viết trên một luồng riêng biệt, nhưng viết không thành công vì một số lý do, luồng chính phải nhận thức được sự thất bại đó.

------------------------------------------------> (main thread, fills buffers)
FF|fX|
------------------------------------------------> (writer thread)
__|X|

Giả sử giao diện của CSequentialStreamWriter có hàm Write trả về bool hoặc ném một ngoại lệ, do đó có lỗi trên một luồng riêng biệt, bạn phải nhớ trạng thái đó, vì vậy, lần tới khi bạn gọi Write hoặc Finilize trên luồng chính, phương thức sẽ trả về Sai hoặc sẽ ném một ngoại lệ. Và việc bạn dừng điền bộ đệm vào thời điểm nào không quan trọng, ngay cả khi bạn đã viết một số dữ liệu trước khi thất bại - rất có thể tệp sẽ bị hỏng và vô dụng.

Tôi khuyên bạn nên thử ánh xạ tệp . Tôi đã sử dụng mmaptrong quá khứ, trong môi trường UNIX và tôi rất ấn tượng bởi hiệu suất cao mà tôi có thể đạt được

Bạn có thể sử dụng FILE*thay thế, và đo lường hiệu suất bạn đã đạt được? Một vài lựa chọn là sử dụng fwrite/writethay vì fstream:

#include <stdio.h>

int main ()
{
  FILE * pFile;
  char buffer[] = { 'x' , 'y' , 'z' };
  pFile = fopen ( "myfile.bin" , "w+b" );
  fwrite (buffer , 1 , sizeof(buffer) , pFile );
  fclose (pFile);
  return 0;
}

Nếu bạn quyết định sử dụng write, hãy thử một cái gì đó tương tự:

#include <unistd.h>
#include <fcntl.h>

int main(void)
{
    int filedesc = open("testfile.txt", O_WRONLY | O_APPEND);

    if (filedesc < 0) {
        return -1;
    }

    if (write(filedesc, "This will be output to testfile.txt\n", 36) != 36) {
        write(2, "There was an error writing to testfile.txt\n", 43);
        return -1;
    }

    return 0;
}

Tôi cũng sẽ khuyên bạn nên xem xét memory map. Đó có thể là câu trả lời của bạn. Khi tôi phải xử lý một tệp 20 GB khác để lưu trữ nó trong cơ sở dữ liệu và tệp này thậm chí không mở. Vì vậy, các giải pháp như sử dụng bản đồ moemory. Tôi đã làm điều đó Pythonmặc dù.

Hãy thử sử dụng các lệnh gọi API open () / write () / close () và thử nghiệm với kích thước bộ đệm đầu ra. Ý tôi là không vượt qua toàn bộ bộ đệm "nhiều-byte" cùng một lúc, hãy thực hiện một vài lần ghi (ví dụ: TotalNumBytes / OutBufferSize). OutBufferSize có thể từ 4096 byte đến megabyte.

Một lần thử khác - sử dụng WinAPI OpenFile / CreateFile và sử dụng bài viết MSDN này để tắt bộ đệm (FILE_FLAG_NO_BUFFITH). Và bài viết MSDN này trên WriteFile () chỉ ra cách lấy kích thước khối cho ổ đĩa để biết kích thước bộ đệm tối ưu.

Dù sao, std :: ofstream là một trình bao bọc và có thể có các hoạt động I / O bị chặn. Hãy nhớ rằng việc duyệt qua toàn bộ mảng N-gigabyte cũng mất một thời gian. Trong khi bạn đang viết một bộ đệm nhỏ, nó sẽ vào bộ đệm và hoạt động nhanh hơn.

fstreams không chậm hơn các luồng C, mỗi se, nhưng chúng sử dụng nhiều CPU hơn (đặc biệt là nếu bộ đệm không được cấu hình đúng cách). Khi CPU bão hòa, nó giới hạn tốc độ I / O.

Ít nhất là triển khai MSVC 2015 sao chép 1 char tại một thời điểm vào bộ đệm đầu ra khi bộ đệm luồng không được đặt (xem streambuf::xsputn). Vì vậy, hãy đảm bảo đặt bộ đệm luồng (> 0) .

Tôi có thể nhận tốc độ ghi 1500MB / s (tốc độ tối đa của SSD M.2 của tôi) bằng fstreamcách sử dụng mã này:

#include <iostream>
#include <fstream>
#include <chrono>
#include <memory>
#include <stdio.h>
#ifdef __linux__
#include <unistd.h>
#endif
using namespace std;
using namespace std::chrono;
const size_t sz = 512 * 1024 * 1024;
const int numiter = 20;
const size_t bufsize = 1024 * 1024;
int main(int argc, char**argv)
{
  unique_ptr<char[]> data(new char[sz]);
  unique_ptr<char[]> buf(new char[bufsize]);
  for (size_t p = 0; p < sz; p += 16) {
    memcpy(&data[p], "BINARY.DATA.....", 16);
  }
  unlink("file.binary");
  int64_t total = 0;
  if (argc < 2 || strcmp(argv[1], "fopen") != 0) {
    cout << "fstream mode\n";
    ofstream myfile("file.binary", ios::out | ios::binary);
    if (!myfile) {
      cerr << "open failed\n"; return 1;
    }
    myfile.rdbuf()->pubsetbuf(buf.get(), bufsize); // IMPORTANT
    for (int i = 0; i < numiter; ++i) {
      auto tm1 = high_resolution_clock::now();
      myfile.write(data.get(), sz);
      if (!myfile)
        cerr << "write failed\n";
      auto tm = (duration_cast<milliseconds>(high_resolution_clock::now() - tm1).count());
      cout << tm << " ms\n";
      total += tm;
    }
    myfile.close();
  }
  else {
    cout << "fopen mode\n";
    FILE* pFile = fopen("file.binary", "wb");
    if (!pFile) {
      cerr << "open failed\n"; return 1;
    }
    setvbuf(pFile, buf.get(), _IOFBF, bufsize); // NOT important
    auto tm1 = high_resolution_clock::now();
    for (int i = 0; i < numiter; ++i) {
      auto tm1 = high_resolution_clock::now();
      if (fwrite(data.get(), sz, 1, pFile) != 1)
        cerr << "write failed\n";
      auto tm = (duration_cast<milliseconds>(high_resolution_clock::now() - tm1).count());
      cout << tm << " ms\n";
      total += tm;
    }
    fclose(pFile);
    auto tm2 = high_resolution_clock::now();
  }
  cout << "Total: " << total << " ms, " << (sz*numiter * 1000 / (1024.0 * 1024 * total)) << " MB/s\n";
}

Tôi đã thử mã này trên các nền tảng khác (Ubuntu, FreeBSD) và nhận thấy không có sự khác biệt về tốc độ I / O, nhưng chênh lệch sử dụng CPU khoảng 8: 1 ( fstreamsử dụng CPU nhiều hơn 8 lần ). Vì vậy, người ta có thể tưởng tượng, nếu tôi có một đĩa nhanh hơn, việc fstreamghi sẽ chậm lại sớm hơn stdiophiên bản.

Cố gắng sử dụng các tập tin ánh xạ bộ nhớ.

Nếu bạn sao chép thứ gì đó từ đĩa A sang đĩa B trong explorer, Windows sẽ sử dụng DMA. Điều đó có nghĩa là đối với hầu hết quá trình sao chép, CPU về cơ bản sẽ không làm gì khác ngoài việc nói cho bộ điều khiển đĩa biết nơi đặt và lấy dữ liệu từ đó, loại bỏ toàn bộ một bước trong chuỗi và một bước không được tối ưu hóa cho việc di chuyển số lượng lớn dữ liệu - và ý tôi là phần cứng.

Những gì bạn làm liên quan đến CPU rất nhiều. Tôi muốn chỉ cho bạn phần "Một số tính toán để điền vào phần []". Mà tôi nghĩ là cần thiết. Bạn tạo một [], sau đó bạn sao chép từ [] sang bộ đệm đầu ra (đó là những gì fux :: write thực hiện), sau đó bạn tạo lại, v.v.

Phải làm sao? Đa luồng! (Tôi hy vọng bạn có bộ xử lý đa lõi)

• cái nĩa.
• Sử dụng một luồng để tạo dữ liệu []
• Sử dụng cái khác để ghi dữ liệu từ [] vào đĩa
• Bạn sẽ cần hai mảng a1 [] và a2 [] và chuyển đổi giữa chúng
• Bạn sẽ cần một số loại đồng bộ hóa giữa các chủ đề của bạn (semaphores, hàng đợi tin nhắn, v.v.)
• Sử dụng các hàm cấp thấp hơn, không có bộ đệm, như hàm WriteFile được đề cập bởi Mehrdad

Nếu bạn muốn ghi nhanh vào các luồng tệp thì bạn có thể làm cho luồng bộ đệm đọc lớn hơn:

wfstream f;
const size_t nBufferSize = 16184;
wchar_t buffer[nBufferSize];
f.rdbuf()->pubsetbuf(buffer, nBufferSize);

Ngoài ra, khi ghi nhiều dữ liệu vào tệp, đôi khi nhanh hơn để mở rộng một cách hợp lý kích thước tệp thay vì vật lý, điều này là do khi mở rộng một cách hợp lý một tệp, hệ thống tệp không tạo khoảng trống mới trước khi ghi vào nó. Nó cũng là thông minh để mở rộng hợp lý tệp nhiều hơn bạn thực sự cần để ngăn chặn nhiều phạm vi tập tin. Mở rộng tệp logic được hỗ trợ trên Windows bằng cách gọi SetFileValidDatahoặc xfsctlvới XFS_IOC_RESVSP64các hệ thống XFS.

im biên soạn chương trình của tôi trong gcc trong GNU / Linux và mingw trong win 7 và win xp và tốt làm việc

bạn có thể sử dụng chương trình của tôi và để tạo tệp 80 GB, chỉ cần thay đổi dòng 33 thành

makeFile("Text.txt",1024,8192000);

Khi thoát khỏi chương trình, tập tin sẽ bị hủy, sau đó kiểm tra tập tin khi nó đang chạy

để có chương trình mà bạn muốn chỉ cần thay đổi chương trình

firt one là chương trình windows và cái thứ hai dành cho GNU / Linux

http://mustafajf.persiangig.com/Projects/File/WinFile.cpp

http://mustafajf.persiangig.com/Projects/File/File.cpp