Autores:  (1) Iason Ofeidis, Departamento de Ingeniería Eléctrica e Instituto de Ciencias de Redes de Yale, Universidad de Yale, New Haven {Contribución igual};  (2) Diego Kiedanski, Departamento de Ingeniería Eléctrica e Instituto de Ciencias de Redes de Yale, Universidad de Yale, New Haven {Contribución igual};  (3) Leandros Tassiulas Levon Ghukasyan, Activeloop, Mountain View, CA, EE. UU., Departamento de Ingeniería Eléctrica e Instituto de Ciencias de Redes de Yale, Universidad de Yale, New Haven.  Tabla de enlaces   Resumen e introducción   Cargadores de datos   Configuración experimental   Los resultados numéricos   Discusión   Trabajo relacionado   Conclusión, agradecimientos y referencias   A. Resultados numéricos (cont.)  5. DISCUSIÓN  En este trabajo, utilizamos el tiempo como herramienta principal para comparar el rendimiento entre diferentes bibliotecas. Hay varias cosas que decir al respecto. En primer lugar, notamos que los tiempos de ejecución son bastante variables y dependen de procesos en segundo plano que son difíciles de controlar. Al mismo tiempo, el acceso a recursos de múltiples GPU es costoso, lo que limita la cantidad de experimentos que se pueden ejecutar. Lo ideal sería haber realizado más de tres repeticiones de cada experimento con más parámetros (más trabajadores, más tamaños de lote), pero no teníamos los recursos para ello. Dado que estamos creando todo nuestro código de fuente abierta, invitamos a los lectores a ejecutar las pruebas comparativas en su propio hardware e informar los resultados. Al mismo tiempo, las bibliotecas se actualizan con bastante frecuencia y un cambio de versión puede aumentar o disminuir drásticamente su rendimiento.  A la luz de los puntos anteriores, animamos al lector a internalizar los aspectos cualitativos de este documento, pero tenga en cuenta que las cifras obtenidas aquí son propensas a cambiar.  En segundo lugar, un aspecto más difícil de comparar es la facilidad de uso de las bibliotecas consideradas en este proyecto. La mayoría de las bibliotecas incluidas en este punto de referencia no tienen documentación completa y se basan principalmente en ejemplos concretos. En consecuencia, la implementación en estas bibliotecas no es trivial y propensa a ineficiencias. Una de las ventajas de hacer que nuestro código sea de código abierto es que permitimos que cualquier desarrollador identifique y mejore nuestro código. Esto es particularmente relevante ya que esperamos que los puntos de referencia creados en este proyecto puedan usarse como código estándar para la comunidad.  Observamos que no parece haber una biblioteca mejor que todas las demás. Más bien, cada uno tiene sus propios puntos fuertes. Considere el ejemplo de FFCV: parece ser el más rápido en nuestros experimentos, pero la falta de soporte para transformaciones de etiquetas impide que se adopte en proyectos que requieren tales características.  Esperamos analizar la interacción entre el filtrado y el entrenamiento en múltiples GPU en trabajos futuros. Al mismo tiempo, sería interesante explorar las capacidades de escalamiento de estas bibliotecas a medida que aumenta la cantidad de GPU. De manera similar, sería de gran interés comparar las bibliotecas de carga de datos en términos de rendimiento en el paso de mezcla en el flujo de trabajo de capacitación de DL, ya que esto puede tener un impacto significativo en el tiempo total de capacitación y su implementación no es un problema trivial. donde existen varios tipos de enfoques.  La investigación sobre bibliotecas que proporcionan carga de datos desde un almacenamiento remoto y que muestran resultados comparables con los experimentos de almacenamiento local nos incentivó a explorar la idea de formular y diseñar una política de almacenamiento en caché para la transmisión de datos a través de una red. En ese entorno, reducir los tiempos en que se debe transferir un punto de datos (por ejemplo, una imagen) puede acortar significativamente el tiempo total de capacitación (y posiblemente los costos si se paga por el uso de la red). La idea de almacenar en caché un conjunto de datos de red durante el entrenamiento no es nueva (Mohan et al., 2020). Aún así, a menudo se supone que todo el conjunto de datos se puede almacenar en caché cuando se habla de datos de entrenamiento y transmisión. Además, se supone que todas las muestras se utilizarán una vez por época (Kumar & Sivathanu, 2020) como es el caso tradicionalmente. Estamos interesados en explorar qué sucede cuando el tamaño de la caché es pequeño y también en eliminar el requisito de utilizar cada punto de datos una vez por época. Esta formulación debería inspirarse en el aprendizaje activo, el resumen de datos y el aprendizaje curricular.  Este documento está   bajo licencia CC 4.0. disponible en 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 audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Boost your HackerNoon story @ $159.99! 🚀

Una descripción general del panorama del cargador de datos: debate

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps