paint-brush
Uma Visão Geral do Cenário do Data-Loader: Discussãopor@serialization
118 leituras

Uma Visão Geral do Cenário do Data-Loader: Discussão

Muito longo; Para ler

Neste artigo, os pesquisadores destacam os dataloaders como a chave para melhorar o treinamento de ML, comparando bibliotecas em termos de funcionalidade, usabilidade e desempenho.
featured image - Uma Visão Geral do Cenário do Data-Loader: Discussão
The Serialization Publication HackerNoon profile picture
0-item

Autores:

(1) Iason Ofeidis, Departamento de Engenharia Elétrica, e Instituto Yale para Ciência de Redes, Universidade de Yale, New Haven {Contribuição igual};

(2) Diego Kiedanski, Departamento de Engenharia Elétrica, e Instituto Yale para Ciência de Redes, Universidade de Yale, New Haven {Contribuição igual};

(3) Leandros TassiulasLevon Ghukasyan, Activeloop, Mountain View, CA, EUA, Departamento de Engenharia Elétrica, e Instituto Yale para Ciência de Redes, Universidade de Yale, New Haven.

Tabela de Links

5. DISCUSSÃO

Neste trabalho, utilizamos o tempo como principal ferramenta para comparar o desempenho entre diferentes bibliotecas. Há várias coisas a dizer sobre isso. Em primeiro lugar, notamos que os tempos de execução são bastante variáveis e dependem de processos em segundo plano que são difíceis de controlar. Ao mesmo tempo, o acesso a recursos multi-GPU é caro, o que limita o número de experimentos que podem ser executados. Idealmente, teríamos executado mais de três repetições de cada experimento com mais parâmetros (mais trabalhadores, mais tamanhos de lote), mas não tínhamos recursos para isso. Como estamos fazendo todo o nosso código-fonte aberto, convidamos os leitores a executar os benchmarks em seu próprio hardware e relatar os resultados. Ao mesmo tempo, as bibliotecas são atualizadas com bastante frequência e uma mudança na versão pode aumentar ou diminuir drasticamente o seu desempenho.


À luz dos pontos acima, encorajamos o leitor a internalizar os aspectos qualitativos deste artigo, mas esteja ciente de que os números aqui obtidos são propensos a mudanças.


Em segundo lugar, um aspecto mais difícil de comparar é a facilidade de utilização das bibliotecas consideradas neste projecto. A maioria das bibliotecas incluídas neste benchmark não possui documentação abrangente e depende principalmente de exemplos concretos. Consequentemente, a implementação nessas bibliotecas não é trivial e está sujeita a ineficiências. Uma das vantagens de tornar nosso código de código aberto é que permitimos que qualquer desenvolvedor identifique e melhore nosso código. Isto é particularmente relevante porque esperamos que os benchmarks criados neste projeto possam ser usados como código padrão para a comunidade.


Notamos que não parece haver uma biblioteca melhor que todas as outras. Em vez disso, cada um tem seus próprios pontos fortes. Vejamos o exemplo do FFCV: ele parece ser o mais rápido em nossos experimentos, mas a falta de suporte para transformações de rótulos impede que ele seja adotado em projetos que exijam tais características.


Esperamos analisar a interação entre filtragem e treinamento em múltiplas GPUs em trabalhos futuros. Ao mesmo tempo, seria interessante explorar as capacidades de escalabilidade destas bibliotecas à medida que o número de GPUs aumenta. Da mesma forma, seria de grande interesse avaliar as bibliotecas de carregamento de dados em termos de desempenho na etapa de embaralhamento no fluxo de trabalho de treinamento em EAD, pois isso pode ter um impacto significativo no tempo total de treinamento e sua implementação é um problema não trivial, onde existem vários tipos de abordagens.


A pesquisa sobre bibliotecas que fornecem carregamento de dados a partir de um armazenamento remoto e que apresentam resultados comparáveis aos experimentos de armazenamento local nos incentivou a explorar a ideia de formular e projetar uma política de cache para streaming de dados em uma rede. Nesse cenário, reduzir o tempo que um ponto de dados (por exemplo, imagem) precisa ser transferido pode reduzir significativamente o tempo geral de treinamento (e possivelmente os custos se o uso da rede for pago). A ideia de armazenar em cache um conjunto de dados de rede durante o treinamento não é nova (Mohan et al., 2020). Ainda assim, muitas vezes presume-se que todo o conjunto de dados pode ser armazenado em cache ao discutir treinamento e streaming de dados. Além disso, assume-se que todas as amostras serão utilizadas uma vez por época (Kumar & Sivathanu, 2020), como é tradicionalmente o caso. Estamos interessados em explorar o que acontece quando o tamanho do cache é pequeno e também em remover a necessidade de usar cada ponto de dados uma vez por época. Tal formulação deve basear-se na aprendizagem activa, na sumarização de dados e na aprendizagem curricular.


Este artigo está disponível no arxiv sob licença CC 4.0.