Uma visão geral do cenário do Data-Loader: configuração experimental

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.

3. CONFIGURAÇÃO EXPERIMENTAL

Várias bibliotecas e conjuntos de dados foram selecionados para comparar seus recursos e desempenho. Embora tenha sido feito um esforço para ser o mais compreensível possível, o campo de carregamento de dados está em constante evolução e novas bibliotecas e lançamentos são adicionados todos os dias. Nesse sentido, esperamos que a lista a seguir forneça uma boa visão geral das capacidades atuais dos dataloaders, sem necessariamente reivindicar ou encontrar o melhor em geral (o que provavelmente mudaria desde o momento da escrita até o momento da publicação). Disponibilizamos ao público todo o código-fonte dos experimentos e esperamos que os resultados sejam totalmente reproduzíveis.

Selecionamos sete bibliotecas para realizar nossos experimentos: PyTorch (Paszke et al., 2019), Torchdata (TorchData, 2021), Hub (Team, 2022a), FFCV (Leclerc et al., 2022), Webdatasets (Webdataset, 2013), Esquilo (Team, 2022b) e Deep Lake (Hambardzumyan et al., 2022). Uma coisa interessante que descobrimos é que nem todas as bibliotecas suportam os mesmos recursos. Por exemplo, não poderíamos executar o FFCV com um conjunto de dados hospedado em um bucket S3 para realizar nossos experimentos remotos. Como mencionamos na Seção 1, executamos todos os nossos experimentos no PyTorch. Consideramos reproduzir os experimentos em outras estruturas populares de aprendizado de máquina, mas decidimos contra a ideia, pois o segundo candidato seria o Tensorflow, mas há rumores de que o Google está se afastando dela em favor do JAX. A Figura 1 mostra a popularidade de diferentes estruturas de ML nos últimos 12 meses.

3.1 Conjuntos de dados

Em relação aos conjuntos de dados, optamos inicialmente por dois conjuntos de dados clássicos para suportar duas tarefas de aprendizagem diferentes: CIFAR-10 (Krizhevsky et al., 2009) para classificação de imagens, e CoCo (Lin et al., 2014) para detecção de objetos. Ao realizar alguns experimentos, observamos um comportamento estranho (bibliotecas com desempenho melhor que o esperado) que poderia ser explicado por

CIFAR-10 encaixado na memória[2]. Por esse motivo, construímos um terceiro conjunto de dados denominado RANDOM, que consiste em imagens coloridas geradas aleatoriamente de tamanho 256 por 256 pixels e uma classe aleatória de 20. Este terceiro conjunto de dados contém 45.000 imagens para treinamento, 5.000 para validação e 500 para teste, e é consideravelmente maior que o CIFAR-10.

Usamos as mesmas transformações para todas as bibliotecas para tornar os benchmarks comparáveis. A única exceção foi o FFCV, que possui implementação própria das diferentes transformações. Para classificação de imagens, a pilha de transformação consistia no seguinte: Inversão Horizontal Aleatória, Normalização, Recorte, Transformação em Tensor.

Para detecção de objetos, contamos principalmente com a implementação de transformações de Albumentations (Buslaev et al., 2020). A pilha ficou assim: Corte de tamanho aleatório, Inversão horizontal aleatória, Normalização, Transformação em Tensor. Essas transformações se aplicam a imagens e caixas delimitadoras.

3.2 Variantes Experimentais

Quando possível, hospedamos o conjunto de dados localmente e em um bucket equivalente ao S3. Isso nos permitiu avaliar a desaceleração resultante do treinamento a partir de um fluxo de dados na rede. Forneceremos uma descrição detalhada do ambiente de treinamento na Seção 4.

Dado que os trabalhos de treinamento mais intensivos envolvem o uso de mais de uma GPU, sempre que possível também realizamos os mesmos experimentos em um ambiente com múltiplas unidades de GPU. Como no momento da execução dos experimentos nem todas as bibliotecas tinham suporte total do PyTorch Lightning, decidimos implementar o multi-GPU usando a biblioteca Distributed Data Parallel (DDP) (Li et al., 2020) da PyTorch.

Para alguns projetos de aprendizado de máquina, talvez precisemos de acesso apenas a um subconjunto de um conjunto de dados maior. Nesses casos, ter a capacidade de filtrar rapidamente os pontos de dados necessários sem precisar iterar todo o conjunto de dados pode reduzir drasticamente o tempo total de treinamento. Algumas bibliotecas permitem a filtragem com base em determinados recursos, como a classe (para tarefas de classificação de imagens). Exploramos o ganho (ou perda) de velocidade ao usar o método de filtragem fornecido pela biblioteca (caso ela oferecesse um) em vez de não filtrar. Sempre que a biblioteca não oferecia um método de filtragem, nós os implementávamos de forma ingênua, ou seja, verificando todo o conjunto de dados e mantendo apenas os elementos que correspondiam à condição especificada. A filtragem rápida não é necessariamente trivial de implementar, pois requer a manutenção de uma estrutura adicional semelhante a um índice para evitar a iteração em todas as amostras.

Finalmente, a Tabela 1 especifica a compatibilidade das diferentes bibliotecas com os diferentes experimentos e conjuntos de dados que exploramos neste artigo.

3.3 Métricas

Nossa principal prioridade ao construir os experimentos foi encontrar uma métrica objetiva que nos permitisse comparar todas as diferentes bibliotecas de uma forma sólida.

A métrica ideal seria o tempo total de execução do trabalho de treinamento, pois é por isso que temos que esperar e pagar. Infelizmente, isso teria limitado bastante o número de experimentos que poderíamos realizar. Após cuidadosa consideração, optamos pelo número de pontos de dados processados (imagens) por segundo, resultado respaldado por nossos experimentos numéricos. Consideramos duas variantes desta métrica: uma em que utilizamos o modelo ML para treinar e realizamos retropropagação e outra em que não utilizamos o modelo ML e apenas iteramos sobre as amostras, copiando-as para GPU. A diferença entre as duas métricas pode ser apreciada a partir do pseudocódigo do loop de treinamento no Algoritmo 1, onde m denota a variável de velocidade. Também coletamos o tempo total de execução[3] e o tempo que levou para os dataloaders serem inicializados. Este último foi motivado pelo fato de que algumas bibliotecas podem realizar cálculos caros antecipadamente para aumentar sua velocidade durante o treinamento. Acabamos também realizando um aquecimento para cálculo da velocidade. Isto é discutido mais detalhadamente na Subseção 3.5.

3.4 Correlação entre velocidade e tempo de corrida

3.5 Uma análise mais detalhada dos tempos de execução

Para aumentar nossa compreensão dos mecanismos internos de cada biblioteca, decidimos inspecionar, para uma única execução, quanto tempo levava para executar cada lote, bem como para inicializar o carregador de dados. A Figura 3 representa, para uma única combinação de parâmetros [4], o tempo gasto por cada biblioteca nas etapas descritas pelo Algoritmo 1. Todos esses experimentos envolveram um corte após 10 lotes.

Curiosamente, o primeiro lote leva um tempo consideravelmente maior que os outros. Isso pode ser explicado da seguinte forma: como a maioria dos dataloaders depende do carregamento lento de dados neste momento, as chamadas futuras se beneficiarão da pré-busca, dos dados já na memória e da paralelização (fazendo coisas enquanto a GPU está ocupada fazendo cálculos).

O tamanho das bandas de 1 a 9 fornece a melhor indicação de quão bem cada biblioteca é dimensionada desde o tempo gasto em uma

um grande conjunto de dados cresce linearmente com essa largura. Podemos observar que a maioria das bibliotecas possui largura uniforme, sendo Deep Lake a mais curta (a mais rápida). Por outro lado, a única biblioteca que apresenta larguras não homogêneas é a FFCV, onde as bandas 1 a 3 são tão finas que não podem ser vistas na imagem.

O período de encerramento leva aproximadamente o mesmo tempo para todas as bibliotecas, exceto para FFCV e Deep Lake, que demoram consideravelmente mais. O tempo gasto na finalização depende principalmente do modelo e não é necessariamente indicativo de quão bem cada biblioteca é dimensionada.

Com base nesta figura, decidimos realizar um aquecimento no cálculo da velocidade. Isso se traduz em ignorar o tempo gasto pelo primeiro lote em todos os cálculos de velocidade.

[2] Isto é frequentemente algo desejável e esperado em algumas revisões da literatura, mas descobrimos que não é o caso em diversas aplicações práticas envolvendo pequenas equipes e estações de trabalho internas.

[3] Este é o tempo desde o início da simulação até o corte, que na prática geralmente era de apenas 10 lotes.

[4] Conjunto de dados RANDOM, GPU única, 0 trabalhadores, tamanho de lote 64