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   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.  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á   sob licença CC 4.0. disponível no arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

We cover the most cutting edge academic research and expert blog posts on serialization. Also big fans of the Serial pod

Serialization's blog

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Boost your HackerNoon story @ $159.99! 🚀

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Telegram: a ponte da Crypto Island para o continente

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Telegram: a ponte da Crypto Island para o continente

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps