首頁>編程相關>C/C++
下載

fast_io

Fast_io是C ++ 20輸入/輸出庫，可提供出色的速度，旨在替換常用的<iostream>和<cstdio>庫。它是一個僅限標題庫，已獲得MIT許可證的許可，使其易於在任何項目中納入。但是，它需要一個支持概念的C ++ 20編譯器。

隨著時間的推移，由於git的膨脹，Fast_io的原始存儲庫已被存檔，但是在那裡仍然可以找到較舊的提交。舊提交在這裡。

例子

打印到stdout 

# include < fast_io.h >

int main () {
	print ( " Hello, fast_io world! n " );
}

內存圖文件

# include < fast_io.h >

int main () {
	fast_io::native_file_loader file_data ( " text.txt " );
	// file_data satisfies std::ranges::contiguous_range
}

其他例子

有關其他最新示例，請查看examples/文件夾。

棄用的例子在這裡，但它們可能不再起作用。

此I18N存儲庫存儲I18N源文件。

https://bitbucket.org/ejsvifq_mabmip/fast_io_i18n

常問問題

fast_io中的“快速”是什麼意思？

fast_io中的fast不一定意味著它是可用的最快輸入/輸出庫（因為它將被稱為fastest_io ）。相反，該術語是指在所有情況下fast_io的速度明顯快於<iostream>和<cstdio>庫。

哪些受支持的平台，編譯器...？

有關支持的事物列表和平台特定的用法說明，請參見support.md。

其他問題？

您可以在Fast_io Discord Server或QQ組上詢問問題： 801441303 。

文件

請參閱https://ewindy.gitee.io/fast_io_rst/index.html或https://gitee.com/qabeowjbtkwb/fast_io/wikis。

特徵

  • 盡可能接近系統調用。

  • Unicode支持（UTF-8，UTF-16，UTF-32） + gb18030和utf-ebcdic（無LIBC正確處理）

  • raii用於c FILE* ，posix fd和win32/nt HANDLE

  • 與<cstdio>和<iostream>互動

  • 沒有像std::endl這樣的輕鬆濫用的東西

  • 靜態I/O操縱器而不是格式字符串。

  • 可選區域。

  • 無狀態的I/O操縱。

  • 一致的錯誤處理；如果有的話，例外是唯一的錯誤報告機制（無std::error_code ， std::system_error或無用的界限檢查）

  • 獨立模式。

  • 地址消毒劑特殊代碼，以保護記憶安全問題。

  • 動態儀器支持

  • 支持POSIX ICONV。您可以將FAST_IO用於編碼轉換。

  • 二進制序列化，用於微不足道的類型和標準容器

  • 使用C ++容器效果很好（例如std::vector<fast_io::obuf_file>有效）

  • basic/lua/python/etc格式（打印，掃描）。由於它們是安全危害，因此不支持C和C ++。

  • 提供API，以揭示FILE*和C ++流的內部實現。

  • 本機句柄接口

  • 非常易於支持自定義設備

  • C和C ++樣式編譯時間打開模式解析。

  • 沒有traits_type和EOF

  • 動態類型支持

  • 多過程

  • 內存映射

  • 調試io（可選為GUI）

  • 往返浮點算法

  • 哈希算法支持：內在的SHA-1，內在的HMAC-SHA1，內在的SHA-256，內在的HMAC-SHA256，SHA-512，HMAC-SHA512以及非加密攜帶算法，例如Jenkins Hash。

  • Zlib壓縮/減壓

  • 文件系統

  • OpenSSL BIO，QT QFILE，MFC CFILE支持

帖子C ++ 20

  1. 模塊支持
  2. Coroutine支持異步IO
  3. 改進和重構代碼一旦將零交叉確定性異常添加到標準

基準

  1. I/O 10m整數

目標：將一千萬個整數從0到1000萬打印到文件。然後重新打開該文件以掃描。

所有基準分配在基準/0000.10M_SIZE_T/單元中。

注意：我修改了由於Bufsiz而導致的libstdc ++的bufsiz 1048576，對於mingw-w64來說太小（512個字節），或者表現可怕。

平台視窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法輸出時間輸入時間評論
stdio.h（fprintf/fscanf） 2.412987 5.607791
Fstream 0.462012S 1.192S
fstream with rdbuf.sputc trick 0.33895 1.170173
fast_io :: i/obuf_file 0.04903 0.080996S
fast_io :: i/obuf_file_mutex 0.146064S 0.113155S線程安全
c_locale_i/obuf_file（“ c”） 0.065988 0.086012S充滿語言環境的“ C”
c_locale_i/obuf_file本地0.153995S充滿語言環境“”
fmt :: format_int+obuf_file 0.122999S
fmt :: format_int+ofstream 0.209055
fmt ::格式+ofstream 0.548 FMT使事情變慢
FMT ::打印0.663996S FMT使事情變慢
std :: to_chars+obuf_file 0.12s
std :: to_chars+ofstream 0.192S
fast_io :: c_file_unlocked 0.098999S 0.126003我砍了MSVCRT的文件*實現
fast_io :: c_file 0.298988 0.318001線程安全。我砍了MSVCRT的文件*實現
fast_io :: filebuf_file 0.048999S 0.081我砍了libstdc ++的streambuf/filebuf實現
fast_io :: iobuf_utf8_file_char16 0.124 0.112001帶有SSE的UTF-16 => UTF-8
fast_io :: iobuf_utf8_file_char32 0.110999 0.111011S帶有SSE的UTF-32 => UTF-8
std :: wofstream 2.64 3.843735S帶有std :: Locale codecvt的WOFStream。 TBH極慢。
fast_io :: wfilebuf_io_observer 2.415692 2.497704帶有std :: Locale codecvt的WOFStream。這證明Fstream永遠無法修復。
生鏽語言0.483生鏽很慢。 Rust也不涉及語言環境。想想這有多糟糕。
Rust Itoa庫0.4.6 > 0.165s我忽略了n部分，以確保沒有偏見。

Rust語言比Fast_io慢10倍。 +二進制膨脹和ITOA庫仍然非常慢，對我來說是可用的。它至少比Fast_io慢3倍。

在MSVC 19.26.28805上運行相同的測試。

平台視窗MSVC 19.26.28805安裝fmtlib浪費我一生的時間
方法輸出時間輸入時間評論
stdio.h（fprintf/fscanf） 1.5353597 1.4157233S
Fstream 3.6350262S 3.8420339
fstream with rdbuf.sputc trick 3.3735902 3.8145566
fast_io :: i/obuf_file 0.0631433S 0.1030554S
fast_io :: i/obuf_file_mutex 0.2190659 0.2485886線程安全
std :: to_chars+obuf_file 0.1641641S
std :: to_chars+ofstream 0.5461922S
fast_io :: c_file_unlocked 0.1102575S 0.2399757我黑客攻擊了環球CRT的文件*實現
fast_io :: c_file 0.2034755 0.2621148線程安全。我砍了ucrt的文件*實現
fast_io :: filebuf_file 0.126661S 0.2378803S我黑客入侵了MSVC STL的StreamBuf/filebuf實現

在GCC 11上進行相同的測試。GLIBC+ LIBSTDC ++

平台Linux GCC 11.0.0 glibc+ libstdc ++
方法輸出時間輸入時間評論
stdio.h（fprintf/fscanf） 0.532792935S 0.591907111S
fstream with rdbuf.sputc trick 0.318896068 0.429406415S
fast_io :: i/obuf_file 0.050300857S 0.065372395S
fast_io :: i/obuf_file_mutex 0.05290654 0.083040518線程安全
c_locale_i/obuf_file（“ c”） 0.051939052S 0.065820056充滿語言環境的“ C”
c_locale_i/obuf_file本地0.162406082S充滿語言環境“”
std :: to_chars+obuf_file 0.115453587
fmt :: format_int+obuf_file 0.1183587
fmt :: format_int+ofstream 0.195914384S
fmt ::格式+ofstream 0.633590975S FMT使事情變慢
FMT ::打印0.495270371 FMT使事情變慢
boost :: iostreams 0.400906063S 0.444717051使用Boost iostreams不會使您的代碼更快
fast_io :: c_file_unlocked 0.060076723S 0.073299716我砍了Glibc的文件*實現
fast_io :: c_file 0.092490191S 0.104545535S線程安全。我砍了Glibc的文件*實現
fast_io :: filebuf_file 0.052251608 0.06655806我砍了libstdc ++的streambuf/filebuf實現

您可以看到fast_io還可以提高現有設施的10倍性能！是的，它甚至可以根據平台改善文件*和FSTREAM的性能，因為我使用概念將它們全部抽象。 FMTLIB實際上會減慢I/O性能。

  1. 使用RYU算法在往返模式下輸出10m雙重

我們僅對MSVC執行此測試，因為僅MSVC的CharConv實現了它。是的。 Fast_IO以超過20％的運行而擊敗了MSVC的CharConv，以運行相同的算法。

所有基準分配在基準/0001.10M_DOUBL/CHARCONV中。

在MSVC 19.26.28805上運行相同的測試。

平台視窗MSVC 19.26.28805
方法輸出時間評論
i/obuf_file 0.4653818
charconv + obuf_file 0.6011
  1. 原始I/O性能

所有基準分配在基準/0014.File_io/file_io中。

輸出100000000X“ Hello World n”

注意：我修改了libstdc ++的std :: FileBuf的bufsiz至1048576，因為bufsiz對於mingw-w64而言太小（512個字節）或可怕的性能。

平台視窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法輸出時間評論
fwrite 2.524001
Fstream 1.013001
fast_io :: obuf_file 0.437998
fast_io :: obuf_file_mutex 1.371線程安全
fast_io :: c_file_unlocked 1.164997我砍了MSVCRT的文件*實現
fast_io :: c_file 3.337945線程安全。我黑客入侵了MSVCRT的文件*實現。需要進一步的優化
fast_io :: filebuf_file 0.467001我入侵了libstdc ++的std :: filebuf實現
平台Linux GCC 11.0.0 glibc+ libstdc ++
方法輸出時間評論
fwrite 1.457288317
Fstream 1.249783346
fast_io :: obuf_file 0.494827134
fast_io :: obuf_file_mutex 0.497138826線程安全
fast_io :: c_file_unlocked 0.687976666S我砍了Glibc的文件*實現
fast_io :: c_file 0.910792697S線程安全。我砍了Glibc的文件*實現
fast_io :: filebuf_file 0.526955039我入侵了libstdc ++的std :: filebuf實現
平台視窗MSVC 19.26.28805 UCRT + MSVC STL
方法輸出時間評論
fwrite 3.3139122
Fstream 1.7184119S
fast_io :: obuf_file 0.7996034
fast_io :: obuf_file_mutex 2.2949221線程安全。對於MSVC STL來說，STD :: Mutex的速度非常慢。
fast_io :: c_file_unlocked 1.2103924我砍了ucrt的文件*實現
fast_io :: c_file 2.3604295線程安全。我砍了ucrt的文件*實現
fast_io :: filebuf_file 1.2805368我入侵了MSVC STL的STD :: FileBuf實現
  1. 二進制大小只需在基準/0014.File_io/file_io中使用基準。伙計，您應該避免作為瘟疫TBH流。它不健康。
平台視窗MingW-W64 GCC 11.0.0 msvcrt + libstdc ++ +靜態編譯
方法二進制大小評論
Fstream 925kb使用fstream對您的健康不利，因為std :: locale both bo bot二進制二進制。
fast_io :: obuf_file 155kb
fast_io :: c_file_unlocked 157KB我砍了MSVCRT的文件*實現
fast_io :: c_file 157KB線程安全。我砍了MSVCRT的文件*實現
fast_io :: filebuf_file 933kb我入侵了libstdc ++的std :: filebuf實現。 C ++流很爛
  1. 代碼轉換

生成100000000？表情符號通過基準/0020.UTF/fill_nc.cc中使用該程序

基准在示例中/0043.ICONV通用ICONV中。 （以UTF-8至GB18030為例）ICONV測試：

平台視窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法經過時間評論
ICONV命令1.529
unidence.cc 1.293使用Posix libiconv

UTF8-> UTF16LE

基準為示例/0022.UTF

ICONV測試：

平台視窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法經過時間評論
ICONV命令0.967 GNU ICONV。沒有糟糕的bom
utf8_file_to_utf16_file.cc 0.498我使用UTF-UTILS項目提供的SSE算法。

UTF8-> UTF32LE

基準為示例/0022.UTF

ICONV測試：

平台視窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法經過時間評論
ICONV命令0.844 GNU ICONV。沒有糟糕的bom
utf8_file_to_utf32_file.cc 0.442S我使用UTF-UTILS項目提供的SSE算法。

學分

由於各種開源項目的寶貴貢獻，該項目的創建和開發成為可能。儘管該代碼未直接從這些項目中復制，但我將其用作參考，並重新實現它們以適合本庫的特定目的。在某些情況下，需要對原始代碼進行修改。我感謝這些項目及其開發人員的承諾，使他們的代碼開放並可以訪問更廣泛的社區。

專案URL
grisu-opact https://github.com/jk-jeon/grisu-exact
ryu https://github.com/ulfjack/ryu
SHA Intrinsics https://github.com/noloader/sha-intrinsics
SHA1 https://github.com/vog/sha1
UTF-UTILS https://github.com/bobsteagall/utf_utils
Jenkins-Hash-Java https://github.com/vkandy/jenkins-hash-java
MD5 https://github.com/jieweiwei/md5
反應https://github.com/reactos/reaectos
dirent_h https://github.com/win32ports/dirent_h
GNU C庫https://www.gnu.org/software/libc/
GNU Newlib https://sourceware.org/newlib/
Dragonbox https://github.com/jk-jeon/dragonbox
Jeaiii https://github.com/jeaiii/itoa
加密++ https://github.com/weidai11/cryptopp
myitoa https://gitee.com/xjkp2283572185/mystd
展開
附加信息
相關應用
爲您推薦
相關資訊 全部