Em que ponto a leitura assíncrona da E / S de disco é mais eficiente que a síncrona?

22

Supondo que exista um pouco de código que leia arquivos para vários consumidores e os arquivos sejam de qualquer tamanho arbitrário: em que tamanho se torna mais eficiente ler o arquivo de forma assíncrona? Ou, em outras palavras, quão pequeno deve ser um arquivo para que seja mais rápido apenas para lê-lo de forma síncrona?

Percebi (e talvez esteja incorreto) que, ao ler arquivos muito pequenos, leva mais tempo para lê-los de forma assíncrona do que síncrona (em particular com o .NET). Suponho que isso esteja relacionado ao tempo de configuração de coisas como portas de conclusão de E / S, threads etc.

Existe alguma regra de ouro para ajudar aqui? Ou é dependente do sistema e do ambiente?

— blesh
fonte

Você pode fornecer o código que você usa para referência? Eu acho que isso poderia acontecer apenas no caso em que o tamanho do arquivo é menor que o tamanho do buffer interno do leitor de fluxo. Mas se você tem que ler que muitos pequenos arquivos que você provavelmente vai bater outros problemas com disco I / O

— Daniel Iankov

Não tenho o código à mão, receio. É algo que me ocorreu há algum tempo e que estava em minha mente desde então. O código era em NET e era essencialmente um File.ReadAllBytes rectas () vs FileStream.BeginRead () em um loop

— Blesh

Quando as curvas que representam sua eficiência cruzam e assíncrona IO sai da travessia com um valor maior que a curva de sincronização IO.

— Thomas Eding

14

Infelizmente, a resposta é "depende". Seria fácil para você escrever um pequeno programa para determinar empiricamente os tempos das leituras assíncrona e sincronizada.

Vai depender de muitos fatores. Eles são armazenados em discos giratórios, SSD ou em uma unidade de rede? Que tipo de CPU você está usando? Quantos soquetes / núcleos? Você está executando em uma VM ou bare metal? Você está executando um sistema operacional antigo ou moderno?

— Martin C. Martin
fonte

1

Sim, eu percebi isso. Acho que esperava que houvesse algum tipo de estudo para usar como guia ou regra de ouro.

— blesh 12/09/12

9

O Async tem 3 vantagens principais:

Reduz a utilização da CPU. Isso pode ser útil se você também estiver executando operações pesadas na CPU com os dados que acabou de ler.
O uso de algum tipo de infraestrutura assíncrona facilita o paralelismo do código. Especialmente se você estiver lendo muitos arquivos.
Ao enviar várias solicitações de leitura e gravação para o SO, o SO e o HW podem reordenar essas operações para serem concluídas mais rapidamente. SATA2 tem esse recurso.

Acredito que a principal vantagem da leitura assíncrona é quando você trabalha com muitos arquivos ou precisa de muita energia da CPU.

— Eufórico
fonte

Observe no ponto 2 que ele não otimizará nada se a operação de E / S for o gargalo. As coisas são diferentes se você estiver acessando em paralelo, através de RAID ou rede, arquivos localizados em discos diferentes.

— Arseni Mourzenko

5

Hmm, estou tendo problemas para entender o que você quer dizer com o número 1. Eu diria que é o contrário na prática. Porque com o caso assíncrono, agora você está alterando seu (s) encadeamento (s) de blocked waiting for I/O(0% CPU) para continue normal processing(> 0% CPU).

— Isak Savo

3

Depende

Uma coisa a ter em mente é o preço da troca de contexto entre os processos. O Node.JS foi projetado da maneira que é porque supõe que fazer uma alternância de contexto é muito caro e você terá muitos processos aguardando no IE, o que atrapalha o computador.

Por outro lado, Erlang faz com que um contexto de processo mude muito barato, para que tudo possa ser síncrono e o tempo de execução de Erlang possa acompanhar tudo.

Portanto, os fatores a serem considerados:

o custo de uma operação de troca de contexto
a velocidade do disco para operações de busca
a velocidade do disco para operações de leitura
são os arquivos no cache

E tenho certeza de que estou deixando de fora uma meia dúzia de fatores

— Zachary K
fonte

2

Não sei se há um "ponto" específico, mas faz mais sentido quando você tem muitos threads trabalhando, pois permite sobrepor sua E / S a outro trabalho. Se você tiver threads sobressalentes ociosos, a leitura assíncrona não dará nenhuma vantagem. Somente quando você tem filas de trabalho sendo preenchidas e seu encadeamento pode ser útil para realizar outro trabalho, em vez de esperar pela E / S, o acesso assíncrono aos arquivos oferece alguma vantagem.

— TMN
fonte

Sim, esse é o objetivo de multithreading!

— Vlad

1

Acho que o problema aqui não é tanto a velocidade de leitura, mas a latência.

Se você estiver lendo de uma unidade de rede ou de uma unidade de disco rígido mecânica lenta com longas filas, o desempenho será prejudicial para a leitura. E se o seu aplicativo também estiver fazendo a leitura no encadeamento da GUI, nesse caso, é um aplicativo muito ruim, será péssimo para o usuário.

— Codificador
fonte