Uma visão geral do cenário do Data-Loader: resultados numéricos

Tabela de Links

• Resumo e introdução
• Carregadores de dados
• Configuração Experimental
• Resultados numéricos
• Discussão
• Trabalho relatado
• Conclusão, agradecimentos e referências
• A. Resultados Numéricos Cont.

4. RESULTADOS NUMÉRICOS

Para o primeiro conjunto de experimentos, avaliamos o desempenho de todas as bibliotecas ao alterar o número de trabalhadores (ver 2), bem como o tamanho do lote. Esses experimentos foram executados em um servidor local com as seguintes especificações: Intel(R) Core(TM) i9-10900K, 2 x NVIDIA GeForce RTX 3090 e um HDD com 10TB de armazenamento (6GB/s) [5].

Avaliamos os três modos: padrão (GPU única), distribuído (duas GPUs) e filtragem (GPU única) para todas as combinações possíveis de 0, 1 e 2 trabalhadores. Para CIFAR10 e RANDOM, o tamanho do lote era 16, 64 ou 128. Para CoCo, usamos valores menores: 1, 2 e 4. Todos esses experimentos usaram um ponto de corte de 10 e a variante que executa o modelo (forward & passe para trás).

4.1 Velocidade em função do tamanho do lote e dos trabalhadores

A primeira coisa que notamos ao examinar os experimentos é que a variação entre as bibliotecas depende do problema e do conjunto de dados utilizado. A Figura 4 mostra uma comparação para CIFAR10 em uma única GPU, enquanto a Figura 5 mostra o mesmo resultado para CoCo, também em uma única GPU.

Isto era de se esperar dado que neste último caso, o tempo necessário para calcular o passe para frente e para trás domina o tempo total de execução, o que não é o caso para a imagem.

classificação. Você também pode notar a diferença geral na velocidade: de 4.000 amostras por segundo para apenas 20.

Em segundo lugar, salientamos que aumentar o tamanho do lote aumenta a velocidade de processamento em quase todos os casos. No entanto, este não é o caso do número de trabalhadores. Podemos observar na Figura 6 que o desempenho do FFCV diminui à medida que o número de trabalhadores aumenta, enquanto Deep Lake estabiliza em 1 trabalhador e não em 2. Uma explicação é que as bibliotecas têm seus próprios algoritmos internos que decidem como abranger threads e processos conforme necessário. O ponto acima é relevante para os usuários dessas bibliotecas, pois a experiência com uma delas pode não se traduzir bem em outra.

4.2 Ganhos de velocidade ao usar DDP

Um recurso desejável de um dataloader é sua capacidade de escalar linearmente com o número de GPUs. Isto nem sempre é possível e depende do mecanismo de carregamento interno de cada biblioteca. Exploramos o desempenho dessas bibliotecas comparando o aumento de velocidade ao usar uma ou duas GPUs. A Figura 7 mostra os resultados para o conjunto de dados RANDOM. Cada barra representa a velocidade máxima alcançada em todos os tamanhos de lote, número de trabalhadores e repetições. De certa forma, isso reflete a velocidade máxima alcançável pela biblioteca. Observamos que as bibliotecas aceleram cerca de 40%, menos da metade de um aumento linear em média. Dois casos são particularmente surpreendentes. Por um lado, o Torchdata tem desempenho pior com duas GPUs do que com uma única. Por outro lado, o FFCV conseguiu um aumento de velocidade superior ao teoricamente possível. Existem vários artefatos que podem estar em jogo aqui, mas muito provavelmente isso se deve ao número limitado de repetições que conseguimos executar (devido aos recursos limitados). Além disso, isso pode

indicam uma configuração incorreta no Torchdata: a documentação sobre a execução de experimentos em ambientes multi-GPU é limitada para a maioria das bibliotecas.

4.3 Comparação entre com e sem passe para frente e para trás

Conforme discutimos ao apresentar o Algoritmo 1, tivemos que decidir se incorporaríamos as passagens para frente e para trás no cálculo da velocidade. Existem argumentos para ambos. Por um lado, incluir as passagens para frente e para trás refletem melhor o tempo real de treinamento do algoritmo. Ao mesmo tempo, algumas bibliotecas podem otimizar preventivamente as etapas normalmente executadas durante o avanço, então

parar ali pareceria que demoravam mais do que demoram.

Por outro lado, se o tempo gasto na passagem para frente e para trás for muito maior do que o tempo necessário apenas para carregar os dados, incluir esse tempo no cálculo inevitavelmente ocultaria a diferença entre as bibliotecas.

Para entender se a mudança de comportamento foi perceptível, usamos o conjunto de dados RANDOM para comparar a diferença na velocidade média ao incluir as duas operações do modelo no cálculo e quando não. Os resultados são apresentados na Figura 8. Podemos observar que a maioria das bibliotecas apresenta uma velocidade ligeiramente aumentada ao excluir o modelo (exceto FFCV, cujo desempenho cai pela metade) e, o mais importante, o desempenho relativo entre as bibliotecas permanece quase o mesmo.

4.4 Compensações de velocidade ao filtrar dados

Para nossos experimentos de filtragem, selecionamos duas classes para manter para CIFAR10 e RANDOM: cachorro e caminhão, e 0 e 13, respectivamente. Para o CoCO selecionamos três classes: pizza, sofá, gato.

Observamos que a maioria das bibliotecas não possui um bom mecanismo de filtragem que evite a iteração em todo o conjunto de dados. Por exemplo, nossa implementação de filtragem PyTorch requer a construção de um amostrador personalizado com os índices das imagens desejadas.

Isso é bastante rápido para um pequeno conjunto de dados, mas se torna inviável para grandes conjuntos de dados: filtrar CoCo usando PyTorch era proibitivamente caro. Em geral, o desempenho foi bastante semelhante quando filtrava e quando não filtrava[6]. Da mesma forma que a Figura

7, na Figura 9, podemos ver a desaceleração como resultado da filtragem: embora tenha sido considerável para Torchdata e Webdataset, vimos uma reversão dos resultados ao trabalhar com o CoCo Dataset.

4.5 Treinamento durante streaming pela rede

Idealmente, poderíamos dissociar o armazenamento do conjunto de dados do processo de treinamento de aprendizado de máquina e simplesmente conectar o banco de dados que armazena nossos dados à estrutura de ML de nossa escolha, independentemente de onde os dois estejam localizados. Isso envolve enviar os dados de treinamento por uma rede e perder velocidade considerável. Com os altos custos envolvidos no aluguel de hardware acelerado por GPU na nuvem, pode parecer que a conveniência não vale a pena. Mas não é?

Algumas das bibliotecas consideradas neste artigo permitem especificar um conjunto de dados acessível através da Internet: Webdataset, Hub e Deep Lake são particularmente bons nisso[7]. A questão então é: quão grande é a compensação entre facilidade de uso e tempo de execução?

Montamos o seguinte experimento para oferecer alguns insights sobre essa questão. Executamos duas épocas completas do conjunto de dados RANDOM para as três bibliotecas: Hub, Deep Lake e Webdataset, enquanto alteramos a origem dos dados. Foram considerados três locais: uma cópia local na máquina que executa o disco rígido dos experimentos, uma cópia em um bucket S3 (na região mais próxima de nossa máquina) e uma cópia armazenada no MinIO (um equivalente de código aberto do S3 que pode ser hospedado localmente) rodando em uma máquina semelhante dentro da mesma rede local (ambas as máquinas estavam conectadas via WiFi). O computador dos experimentos tinha CPU Intel(R) Core(TM) i7-7700 a 3,60 GHz, 16 GB de RAM, NVIDIA GeForce RTX

2070 Rev e um disco rígido Samsung SSD 850 com 256 GB de armazenamento. Em relação à latência, o tempo de ida e volta da estação de trabalho que executa os experimentos até o servidor MinIO (localizado na mesma sala e no mesmo WiFi local) levou 59,2 ± 58,5 ms (mín. 8,8 ms), enquanto para o bucket S3 na AWS servidores levaram 17,3 ± 1,3 ms (mín. 14,8 ms).

A Figura 10 representa os tempos totais de execução para os nove experimentos, e as porcentagens brancas denotam a desaceleração (aumento no tempo de execução) em comparação com o caso local. Podemos observar que embora para Hub e Webdataset haja um aumento significativo ao migrar para AWS, Deep Lake conseguiu manter quase a mesma velocidade com um aumento de apenas 13%. Outro insight útil pode ser extraído do resultado: a configuração MinIO mostra uma desaceleração quase duas vezes pior que a configuração AWS, como visto na Figura 10. Esse resultado pode ser explicado principalmente pela diferença nos tempos médios de ida e volta mostrados acima, destacando que redes locais (por exemplo, redes internas da empresa[8]) podem não ser a forma mais eficiente de hospedar conjuntos de dados devido às suas configurações e restrições complexas. Além disso, este resultado também indica que o armazenamento que serve os conjuntos de dados através da rede desempenha um papel crucial ao permitir a formação remota e pode suscitar questões sobre as melhores práticas para servir conjuntos de dados. Ou seja, os dados do S3 são servidos em paralelo a partir de diferentes servidores com balanceamento de carga enquanto tínhamos acesso a uma única instância do MinIO.

Os gráficos para todos os experimentos adicionais podem ser encontrados no Apêndice A.

[5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf

[6] em velocidade. A construção do amostrador para PyTorch é feita antecipadamente, afetando consideravelmente o tempo total de execução.

[7] O Squirrel tem esse recurso, mas não conseguimos especificar um endereço MinIO, então o excluímos da comparação. Tivemos um problema semelhante com o Torchdata.

[8] Neste caso, uma rede universitária