Biblioteka fstream i wielkość plików

RAID-1 składające się z dwóch HDD:
SSD:
tmpfs:

Wyniki nie mają sensu, bo podają czas procesora — clock używa clock_gettime z CLOCK_PROCESS_CPUTIME_ID! — nie czas zegara ściennego. Po zmianie kodu tak, by korzystał z CLOCK_MONOTONIC:
HDD:
SSD:
tmpfs:

Ha ha ha.

Teza: bottleneckiem jest std::fstream. Co się stanie, jeśli porównać też open + write + fdatasync (chcemy przecież zapisać coś na dysk, a nie tylko skopiować do page cache kernela) + close?
HDD: SSD: tmpfs:
Daje to kolejno 100, 450 i 6000 MB/s. To już ma sens i pokazuje, że problemy z wydajnością są spowodowane przez std::fstream, co mnie absolutnie nie dziwi.

To, że operator<< jest wolniejszy od funkcji składowej write również mnie nie dziwi, to pierwsze musi dokonać konwersji liczby na postać tekstową, co swoje kosztuje, zwłaszcza w standardowych strumieniach, gdzie trzeba przejść przez std::num_put.

Możesz jeszcze napisać czym kompilowałeś?

Clang z libc++ daje podobne wyniki, tylko operator<< jest prawie 5× wolniejszy:

Teza: bottleneckiem jest std::fstream. Co się stanie, jeśli porównać też open + write + fdatasync (chcemy przecież zapisać coś na dysk, a nie tylko skopiować do page cache kernela) + close?

Wprawdzie fwrite jest szybsza od fstream::write przy tak skonstruowanym teście, to przy usunięciu jednej pętli (128) na rzecz bufora int[128] różnice w czasach są nieznaczne (co ciekawe u mnie na korzyść fstream::write). Przy zapisie blokami 128 * 1024 i usunięciu jeszcze jednej pętli wychodzi mi, że kod z fstream::write jest około trzy razy szybszy od wersji z fwrite.


Wspomnę jeszcze, że operator<< jest szybszy od fprintf, ale to dziwić nikogo nie powinno.



p.s. testowałem na MinGW 5.1.0.

Troszkę te wasze dyskusje o prędkości przypominają udowadnianie że rower jest lepszy od samochodu. Strumienie w C++ to dość złożony podsystem który ma na celu kompleksowe obsłużenie zagadnień z którymi np. printf sobie nie radził lub nie miał nawet w planach radzić. Nie oznacza to że jest szybszy czy wolniejszy... to zależy... proponuję sprawdzić następujące fakty i ew. wyciągać wnioski:
1. Wyłączyć synchronizację z stdio znanego z C. Strumień respektuje mieszane wywołania. Czyli np. część tradycyjnego C (printf i pochodne) i część strumieni. Znaki się nie mieszają bo synchronizacja jest włączona. Wyłączenie:
2. Strumienie wejściowe mają wbudowaną kontynuację gdzie oczekują na synchronizację z innym. W metodzie strumienia (w tym przypadku otwartym pliku) w metodzie tie, warto podać wskaźnik nullptr. Dość mocno przyśpieszy.
3. Jeśli zapis jest wykonywany przy dużej ilości danych, warto zmienić wielkość bufora:
4. Czy zamiast konwersji które wykonuje printf() może być coś szybszego? W większości wypadków (podkreślam że w większość bo są wyjątki) tak. Dostępna jest biblioteka boost::lexical_cast .. odnośnik do wydajności http://www.boost.org/doc/libs/1_62_0/doc/html/boost_lexical_cast/performance.html
5. W trakcie close() na pliku (czyli także w takcie niszczenia obiektu pliku), następuje automatyczna synchronizacja.

Jak teraz będzie pritnf szybsze, super! Sprawdziłeś! Jeśli nie, również super! Wiesz że kilku "gałek i wajch" printf nie ma :-) Więc jeśli ich nie potrzebujesz, to printf będzie ok.

@mokrowski, bez przesady. Z takich dyskusji czasami można się czegoś ciekawego dowiedzieć, jak np. to, że strumienie z C++ nie są z definicji wolniejsze od tych z C (dość powszechny mit). Że na szybkość czytania/zapisywania dużej ilości danych większy wpływ ma buforowanie, a nie użyte strumienie czy funkcje systemowe.

strumienie z C++ nie są z definicji wolniejsze od tych z C (dość powszechny mit).

"Strumienie C++ definiuje się jako wolniejsze odpowiedniki rozwiązań z C.." :D Jednak mit jest, głównie przez to, że osoby nie mające pojęcia o programowaniu biorą się za zadania z limitem czasu, a I/O znają tylko z kursu i w podstawowym zakresie. "Mam problem, przekraczam limit czasu" i odpowiedź to zwykle "użyj printf", bo w takim przypadku tłumaczenie niuansów jest jak rzucanie grochem w ścianę, na której jest wyraźnie napisane "nawet śrut nic nie dał, ale próbuj szczęścia".

Strumienie w C++ to dość złożony podsystem który ma na celu kompleksowe obsłużenie zagadnień z którymi np. printf sobie nie radził lub nie miał nawet w planach radzić.

Kontrprzykładem jest tutaj i18n, z którym printf radzi sobie lepiej, bo nie rozbija wiadomości na kawałki.

1. Wyłączyć synchronizację z stdio znanego z C.

To ma wpływ tylko na std::{,w}c{in,out,err,log}, a temat jest o strumieniach plikowych.

2. Strumienie wejściowe mają wbudowaną kontynuację gdzie oczekują na synchronizację z innym. W metodzie strumienia (w tym przypadku otwartym pliku) w metodzie tie, warto podać wskaźnik nullptr. Dość mocno przyśpieszy.

Strumienie plikowe nie są domyślnie powiązane z niczym, więc to nic nie zmieni; patrz 27.5.5.2, do którego pośrednio odnosi się 27.9.5.1.

3. Jeśli zapis jest wykonywany przy dużej ilości danych, warto zmienić wielkość bufora

To nic nie da, gdy bottleneckiem jest samo kopiowanie danych do tegoż bufora — profilowałem, najwięcej czasu program malego7 spędza w std::basic_filebuf<char>::xsputn!

4. Czy zamiast konwersji które wykonuje printf() może być coś szybszego? W większości wypadków (podkreślam że w większość bo są wyjątki) tak. Dostępna jest biblioteka boost::lexical_cast

boost::lexical_cast też jest wolne, jeśli komuś zależy na wydajności, to używa Karmy^{karma best waifu} z Boost.Spirit, std::to_chars (które jeszcze nie istnieje) lub customowego kodu.

"Strumienie C++ definiuje się jako wolniejsze odpowiedniki rozwiązań z C.." :D

Najśmieszniejsze jest w tym wszystkim to, że tak definiuje je standard. Nie, nie żartuję, standardowe strumienie plikowe są zdefiniowane jako wrappery wokół FILE*, a konwersje liczb z/do ciągów znaków zdefiniowane są przy użyciu strto{l,ll,ul,ull,f,d,ld} i printf. Implementacje starają się jak mogą realizować to na sposoby szybsze niż wywoływanie funkcji z C, ale nie zawsze się da.