download fast_io - download do código -fonte fast

fast_io

C/C++

1.0.0

Baixar

fast_io

Fast_IO é uma biblioteca de entrada/saída C ++ 20 que fornece velocidade excepcional e foi projetada para substituir as bibliotecas comumente usadas <iostream> e <cstdio> . É uma biblioteca somente para cabeçalho e é licenciada sob a licença do MIT, facilitando a inclusão de qualquer projeto. No entanto, requer um compilador C ++ 20 que suporta conceitos.

O repositório original para fast_io foi arquivado devido ao bloat Git ao longo do tempo, mas os compromissos mais antigos ainda podem ser encontrados lá. Os antigos compromissos estavam aqui.

Exemplos

Imprima para `stdout`

# include < fast_io.h >

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

Arquivo de mapa de memória

# include < fast_io.h >

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

Outros exemplos

Para outros exemplos atualizados, consulte os examples/ pasta.

Exemplos depreciados estão aqui, mas eles podem não funcionar mais.

Este I18N Repo armazena os arquivos de origem i18N.

https://bitbucket.org/ejsvifq_mabmip/fast_io_i18n

Perguntas frequentes

O que significa "rápido" em fast_io?

O termo fast em fast_io não implica necessariamente que é a biblioteca de entrada/saída mais rápida disponível (como teria sido nomeado como fastest_io ). Em vez disso, o termo refere -se ao fato de que fast_io é notavelmente mais rápido que <iostream> e <cstdio> em todos os casos.

Quais são as plataformas suportadas, compiladores ...?

Consulte o suporte.md para obter uma lista de coisas suportadas e notas de uso específicas da plataforma.

Outras perguntas?

Você pode fazer perguntas sobre o servidor Fast_io Discord ou QQ Group: 801441303 .

Documentação

Veja https://ewindy.gitee.io/fast_io_rst/index.html ou https://gitee.com/qabeowjbtkwb/fast_io/wikis.

Características

O mais próximo possível do sistema.
Suporte UNICODE (UTF-8, UTF-16, UTF-32) + Codecvt para GB18030 e UTF-EBCDIC (sem LIBC lida corretamente com isso)
Raii para FILE* , Posix fd e Win32/NT HANDLE
Interair com <cstdio> e <iostream>
Nenhuma coisa facilmente usada como std::endl
Manipuladores de E/S estáticos em vez de formatar cordas.
Local opcional.
Manipulação de E/S sem estado.
Manipulação consistente de erros; Quando disponível, exceções como o único mecanismo de relatório de erro (sem std::error_code , std::system_error ou verificação inútil)
Modo independente.
Aborde o código especial do Sinitizador para proteger os problemas de segurança da memória.
Suporte de instrumentação dinâmica
Suporta Posix Iconv. Você pode usar o fast_io para sua conversão de codificação.
Serialização binária para tipos triviais e contêineres padrão
Reproduz bem com contêineres C ++ (por exemplo std::vector<fast_io::obuf_file> é válido)
Formato básico/lua/python/etc (impressão, varredura). Não há suporte para C e C ++, pois são riscos de segurança.
Forneça APIs para expor a implementação interna dos fluxos FILE* e C ++.
Interface do identificador nativo
Extremamente fácil de suportar dispositivos personalizados
C ++ estilo de compilação de tempo de compilação de modo aberto análise.
Sem traits_type e EOF
Suporte ao tipo dinâmico
Multi Process
Mapeamento de memória
Debugando IO (opcionalmente com a GUI)
Algoritmo de ponto flutuante de ida e volta
Suporte de algoritmos de hash: sha-1 intrínseco, hmac-sha1 intrínseco, sha-256 intrínseco, hmac-sha256 intrínseco, sha-512, hmac-sha512, bem como algoritmos de hash não criptográficos, como jenkins hash.
Compressão/descompressão de Zlib
FileSystem
OpenSSL Bio, Qt Qfile, Suporte MFC CFILE

Post C ++ 20

Suporte ao módulo
Coroutine Suporte para async io
Melhorar e refactor Código depois que exceções determinísticas de cabeça zero são adicionadas ao padrão

Benchmarks

I/S 10m Inteiros

Objetivo: Imprima dez milhões de números inteiros de 0 a 10m para o arquivo. Em seguida, reabrir esse arquivo para repassar de volta.

Todos os benchmarks estão em benchmarks/0000.10m_size_t/unidade.

AVISO: Modifiquei o bufsiz 1048576 do LibSTDC ++ devido ao bufsiz é muito pequeno (512 bytes) para Mingw-W64, ou o desempenho horrivelmente.

Plataforma	Windows	Mingw-W64 GCC 11.0.0	Msvcrt+ libstdc ++

Método	Tempo de saída	Tempo de entrada	Comentário
stdio.h (fprintf/fscanf)	2.412987S	5.607791s
fStream	0,462012S	1.192s
Fream com rdbuf.sputc truque	0,33895s	1.170173s
fast_io :: i/obuf_file	0.04903s	0,080996S
fast_io :: i/obuf_file_mutex	0.146064s	0.113155s	Tópico seguro
c_locale_i/obuf_file ("c")	0,065988S	0,086012s	imbuído de localidade, localidade "C"
c_locale_i/obuf_file local	0,153995S		Imbued de Local, Locale ""
fmt :: format_int+obuf_file	0,122999S
fmt :: format_int+ofstream	0.209055s
FMT :: Formato+Ofstream	0,548s		FMT torna as coisas mais lentas
fmt :: print	0,663996S		FMT torna as coisas mais lentas
std :: to_chars+obuf_file	0,12s
std :: to_chars+ofstream	0,192s
fast_io :: c_file_unlocked	0,098999S	0.126003s	Eu invadi o arquivo do msvcrt* implementação
fast_io :: c_file	0,298988S	0,318001S	Tópico seguro. Eu invadi o arquivo do msvcrt* implementação
fast_io :: filebuf_file	0.048999S	0,081s	Eu invadi a implementação de streambuf/filebuf 'de libstdc ++
fast_io :: IOBUF_UTF8_FILE_CHAR16	0,124s	0.112001s	UTF-16 => UTF-8 com SSE
fast_io :: IOBUF_UTF8_FILE_CHAR32	0.110999S	0.111011s	UTF-32 => UTF-8 com SSE
std :: wofstream	2.64s	3.843735s	wofstream com std :: loce codecvt. TBH extremamente lento.
fast_io :: wfilebuf_io_observer	2.415692s	2.497704s	wofstream com std :: loce codecvt. Isso prova que o Fream nunca pode ser corrigido.
Linguagem de ferrugem	0,483s		A ferrugem é lenta. Também a ferrugem não lida com a localidade. Pense como é ruim.
Biblioteca Rust Itoa 0.4.6	> 0,165s		Eu ignorei a parte `n` para garantir não preconceito.

A linguagem de ferrugem é 10x mais lenta que o fast_io. + Bloat binária e biblioteca ITOA ainda são extremamente lentas e utilizáveis para mim. É pelo menos 3x mais lento que o fast_io.

Execute o mesmo teste no MSVC 19.26.28805.

Plataforma	Windows	MSVC 19.26.28805	Instale o tempo de desperdício de fmtlib da minha vida

Método	Tempo de saída	Tempo de entrada	Comentário
stdio.h (fprintf/fscanf)	1.5353597s	1.4157233s
fStream	3.6350262s	3.8420339S
Fream com rdbuf.sputc truque	3.3735902s	3.8145566s
fast_io :: i/obuf_file	0,0631433s	0.1030554S
fast_io :: i/obuf_file_mutex	0,2190659S	0,2485886S	Tópico seguro
std :: to_chars+obuf_file	0,1641641S
std :: to_chars+ofstream	0,5461922s
fast_io :: c_file_unlocked	0.1102575s	0,2399757S	Eu invadi o arquivo do Universal CRT* Implementação
fast_io :: c_file	0.2034755s	0,2621148S	Tópico seguro. Eu invadi o arquivo do UCRT* Implementação
fast_io :: filebuf_file	0,126661S	0,2378803s	Eu invadi a implementação do streambuf/filebuf do MSVC STL

Execute o mesmo teste no GCC 11. Glibc+ libstdc ++

Plataforma	Linux	GCC 11.0.0	glibc+ libstdc ++

Método	Tempo de saída	Tempo de entrada	Comentário
stdio.h (fprintf/fscanf)	0,532792935S	0,591907111S
Fream com rdbuf.sputc truque	0,318896068S	0,429406415S
fast_io :: i/obuf_file	0,050300857S	0,065372395S
fast_io :: i/obuf_file_mutex	0,05290654S	0,083040518S	Tópico seguro
c_locale_i/obuf_file ("c")	0,051939052s	0,065820056S	imbuído de localidade, localidade "C"
c_locale_i/obuf_file local	0,162406082S		Imbued de Local, Locale ""
std :: to_chars+obuf_file	0,115453587s
fmt :: format_int+obuf_file	0.1183587s
fmt :: format_int+ofstream	0,195914384S
FMT :: Formato+Ofstream	0,633590975S		FMT torna as coisas mais lentas
fmt :: print	0,495270371S		FMT torna as coisas mais lentas
Boost :: iostreams	0,400906063S	0,444717051S	Usar o Boost iOSTreams não torna seu código mais rápido
fast_io :: c_file_unlocked	0,060076723s	0,073299716S	Eu invadi o arquivo do GLIBC* Implementação
fast_io :: c_file	0,092490191S	0.104545535s	Tópico seguro. Eu invadi o arquivo do GLIBC* Implementação
fast_io :: filebuf_file	0,052251608S	0,06655806S	Eu invadi a implementação de streambuf/filebuf 'de libstdc ++

Você pode ver fast_io também pode aumentar o desempenho das instalações existentes para 10x! Sim, ele pode até melhorar o arquivo* e o desempenho da FStream por 10x, dependendo das plataformas, pois eu uso conceitos para abstrair todos eles. O FMTLIB realmente diminui o desempenho de E/S.

Saída 10m dupla no modo de ida e volta com o algoritmo RYU

Nós apenas realizamos esse teste para o MSVC, já que apenas o Charconv da MSVC o implementa. Sim. Fast_IO derrota o CharConv da MSVC por mais de 20% para executar o mesmo algoritmo.

Todos os benchmarks estão em benchmarks/0001.10m_double/charconv.

Execute o mesmo teste no MSVC 19.26.28805.

Plataforma	Windows	MSVC 19.26.28805

Método	Tempo de saída	Comentário
i/obuf_file	0,4653818S
charconv + obuf_file	0,6011s

Performance de E/S cru

Todos os benchmarks estão em benchmarks/0014.file_io/file_io.

Saída 100000000x "Hello World n"

AVISO: Modifiquei o std :: filebuf do LIBSTDC ++ para 1048576 devido ao bufsiz é muito pequeno (512 bytes) para Mingw-W64 ou tem um desempenho horrível.

Plataforma	Windows	Mingw-W64 GCC 11.0.0	Msvcrt+ libstdc ++

Método	Tempo de saída	Comentário
fWrite	2.524001s
fStream	1.013001S
fast_io :: obuf_file	0,437998S
fast_io :: obuf_file_mutex	1.371s	Tópico seguro
fast_io :: c_file_unlocked	1.164997S	Eu invadi o arquivo do msvcrt* implementação
fast_io :: c_file	3.337945s	Tópico seguro. Eu invadi a implementação do arquivo do MSVCRT*. Precisa de mais otimização
fast_io :: filebuf_file	0,467001S	Eu invadi a implementação do LIBSTDC ++ STD :: FileBuf

Plataforma	Linux	GCC 11.0.0	glibc+ libstdc ++

Método	Tempo de saída	Comentário
fWrite	1.457288317S
fStream	1.249783346S
fast_io :: obuf_file	0,494827134S
fast_io :: obuf_file_mutex	0,497138826S	Tópico seguro
fast_io :: c_file_unlocked	0,687976666S	Eu invadi o arquivo do GLIBC* Implementação
fast_io :: c_file	0.910792697S	Tópico seguro. Eu invadi o arquivo do GLIBC* Implementação
fast_io :: filebuf_file	0,526955039S	Eu invadi a implementação do LIBSTDC ++ STD :: FileBuf

Plataforma	Windows	MSVC 19.26.28805	Ucrt + msvc stl

Método	Tempo de saída	Comentário
fWrite	3.3139122s
fStream	1.7184119S
fast_io :: obuf_file	0,7996034S
fast_io :: obuf_file_mutex	2.2949221S	Tópico seguro. Parece que STD :: Mutex é terrivelmente lento para o MSVC STL.
fast_io :: c_file_unlocked	1.2103924S	Eu invadi o arquivo do UCRT* Implementação
fast_io :: c_file	2.3604295s	Tópico seguro. Eu invadi o arquivo do UCRT* Implementação
fast_io :: filebuf_file	1.2805368s	Eu invadi a implementação do MSVC STL STL :: FileBuf

Tamanho binário Basta usar o benchmark em benchmarks/0014.file_io/file_io. Cara, você deve evitar o fluxo como peste tbh. Não é saudável.

Plataforma	Windows	Mingw-W64 GCC 11.0.0	Msvcrt + libstdc ++ + compilação estática

Método	Tamanho binário	Comentário
fStream	925kb	Use o FStream não é bom para sua saúde, pois a STD :: Locale incha o seu binário.
fast_io :: obuf_file	155kb
fast_io :: c_file_unlocked	157kb	Eu invadi o arquivo do msvcrt* implementação
fast_io :: c_file	157kb	Tópico seguro. Eu invadi o arquivo do msvcrt* implementação
fast_io :: filebuf_file	933KB	Eu invadi a implementação do LIBSTDC ++ STD :: FileBuf. O fluxo C ++ é uma merda

Código Converter

Gerar 100000000? emojis usando o programa em benchmarks/0020.utf/file_nc.cc

Os benchmarks estão em exemplos/0043.iConv Universal Iconv. (UTF-8 a GB18030 como exemplo) Teste de iconv:

Plataforma	Windows	Mingw-W64 GCC 11.0.0	Msvcrt+ libstdc ++

Método	Tempo decorrido	Comentário
comando iconv	1.529s
universal.cc	1.293s	Use Posix libiconv

UTF8-> UTF16LE

Os benchmarks estão em exemplos/0022.utf

Teste de iconv:

Plataforma	Windows	Mingw-W64 GCC 11.0.0	Msvcrt+ libstdc ++

Método	Tempo decorrido	Comentário
comando iconv	0,967s	GNU iconv. Nenhum nascido que é péssimo
UTF8_FILE_TO_UTF16_FILE.CC	0,498s	Eu uso os algoritmos SSE fornecidos pelo projeto UTF-Utils.

UTF8-> UTF32LE

Os benchmarks estão em exemplos/0022.utf

Teste de iconv:

Plataforma	Windows	Mingw-W64 GCC 11.0.0	Msvcrt+ libstdc ++

Método	Tempo decorrido	Comentário
comando iconv	0,844s	GNU iconv. Nenhum nascido que é péssimo
UTF8_FILE_TO_UTF32_FILE.CC	0,442s	Eu uso os algoritmos SSE fornecidos pelo projeto UTF-Utils.

Créditos

A criação e o desenvolvimento deste projeto foram possíveis graças às valiosas contribuições de vários projetos de código aberto. Embora o código não tenha sido copiado diretamente desses projetos, eu os usei como referências e as reimplementi para atender aos propósitos específicos desta biblioteca. Em alguns casos, surgiram problemas de integração que exigiam modificações no código original. Sou grato a esses projetos e seus desenvolvedores por seu compromisso em tornar seu código aberto e acessível à comunidade em geral.

Projeto	Url
Grisu-Exacto	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
Reactos	https://github.com/reactos/reactos
DIRENT_H	https://github.com/win32ports/dirent_h
Biblioteca 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
Cripto ++	https://github.com/weidai11/cryptopp
Myitoa	https://gitee.com/xjkp2283572185/mystd