Una descripción general del panorama del cargador de datos: configuración experimental

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.)

3. CONFIGURACIÓN EXPERIMENTAL

Se seleccionaron varias bibliotecas y conjuntos de datos para comparar sus características y rendimiento. Aunque se hizo un esfuerzo por ser lo más comprensible posible, el campo de la carga de datos está en constante evolución y cada día se agregan nuevas bibliotecas y versiones. En este sentido, esperamos que la siguiente lista proporcione una buena descripción general de las capacidades actuales de los cargadores de datos, sin necesariamente afirmar o encontrar lo mejor en general (lo que probablemente cambiaría desde el momento de escribir este artículo hasta el momento de la publicación). Ponemos a disposición del público todo el código fuente de los experimentos y esperamos que los resultados sean totalmente reproducibles.

Seleccionamos siete bibliotecas para realizar nuestros experimentos: PyTorch (Paszke et al., 2019), Torchdata (TorchData, 2021), Hub (Team, 2022a), FFCV (Leclerc et al., 2022), Webdatasets (Webdataset, 2013), Ardilla (Team, 2022b) y Deep Lake (Hambardzumyan et al., 2022). Una cosa interesante que descubrimos es que no todas las bibliotecas admiten las mismas funciones. Por ejemplo, no pudimos ejecutar FFCV con un conjunto de datos alojado en un depósito de S3 para realizar nuestros experimentos remotos. Como mencionamos en la Sección 1, ejecutamos todos nuestros experimentos en PyTorch. Consideramos reproducir los experimentos en otros marcos populares de aprendizaje automático, pero decidimos no hacerlo ya que el segundo candidato habría sido Tensorflow, pero hay rumores de que Google se está alejando de él en favor de JAX. La Figura 1 muestra la popularidad de diferentes marcos de ML en los últimos 12 meses.

3.1 Conjuntos de datos

Con respecto a los conjuntos de datos, inicialmente optamos por dos conjuntos de datos clásicos para respaldar dos tareas de aprendizaje diferentes: CIFAR-10 (Krizhevsky et al., 2009) para la clasificación de imágenes y CoCo (Lin et al., 2014) para la detección de objetos. Mientras realizábamos algunos experimentos, observamos un comportamiento extraño (las bibliotecas funcionan mejor de lo esperado) que podría explicarse por

CIFAR-10 encajando en la memoria[2]. Por esta razón, creamos un tercer conjunto de datos llamado RANDOM, que consta de imágenes en color generadas aleatoriamente de un tamaño de 256 por 256 píxeles y una clase aleatoria de 20. Este tercer conjunto de datos contiene 45000 imágenes para entrenamiento, 5000 para validación y 500 para prueba. y es considerablemente más grande que CIFAR-10.

Usamos las mismas transformaciones para todas las bibliotecas para que los puntos de referencia sean comparables. La única excepción fue la FFCV, que tiene su propia implementación de las diferentes transformaciones. Para la clasificación de imágenes, la pila de transformación constaba de lo siguiente: giro horizontal aleatorio, normalización, recorte, transformación en tensor.

Para la detección de objetos, nos basamos principalmente en la implementación de transformaciones de Albumentations (Buslaev et al., 2020). La pila tenía el siguiente aspecto: recorte de tamaño aleatorio, giro horizontal aleatorio, normalización, transformación en tensor. Estas transformaciones se aplican tanto a imágenes como a cuadros delimitadores.

3.2 Variantes del experimento

Cuando fue posible, alojamos el conjunto de datos localmente y en un depósito equivalente a S3. Esto nos permitió evaluar la desaceleración resultante del entrenamiento a partir de un flujo de datos a través de la red. Proporcionaremos una descripción detallada del entorno de capacitación en la Sección 4.

Dado que los trabajos de capacitación más intensivos implican el uso de más de una GPU, siempre que fue posible también realizamos los mismos experimentos en un entorno con múltiples unidades de GPU. Debido a que en el momento de ejecutar los experimentos no todas las bibliotecas tenían soporte completo de PyTorch Lightning, decidimos implementar la GPU múltiple utilizando la biblioteca Distributed Data Parallel (DDP) (Li et al., 2020) de PyTorch.

Para algunos proyectos de aprendizaje automático, es posible que necesitemos acceder solo a un subconjunto de un conjunto de datos más grande. En esos casos, tener la capacidad de filtrar rápidamente los puntos de datos requeridos sin tener que iterar sobre todo el conjunto de datos puede reducir drásticamente el tiempo total de entrenamiento. Algunas bibliotecas permiten filtrar en función de determinadas características, como la clase (para tareas de clasificación de imágenes). Exploramos la ganancia (o pérdida) de velocidad al usar el método de filtrado proporcionado por la biblioteca (en caso de que ofreciera uno) versus no filtrar en absoluto. Siempre que la biblioteca no ofrecía un método de filtrado, lo implementábamos de forma ingenua, es decir, escaneando todo el conjunto de datos y manteniendo sólo aquellos elementos que coincidían con la condición especificada. El filtrado rápido no es necesariamente trivial de implementar, ya que requiere mantener una estructura adicional similar a un índice para evitar la iteración sobre todas las muestras.

Finalmente, la Tabla 1 especifica la compatibilidad de las diferentes bibliotecas con los diferentes experimentos y conjuntos de datos que exploramos en este artículo.

3.3 Métricas

Nuestra principal prioridad al construir los experimentos fue encontrar una métrica objetiva que nos permitiera comparar todas las diferentes bibliotecas de una manera sólida.

La métrica ideal habría sido el tiempo total de ejecución del trabajo de capacitación, ya que esto es lo que tenemos que esperar y pagar. Desafortunadamente, eso habría limitado en gran medida la cantidad de experimentos que podríamos realizar. Después de una cuidadosa consideración, optamos por la cantidad de puntos de datos procesados (imágenes) por segundo, un resultado respaldado por nuestros experimentos numéricos. Consideramos dos variantes de esta métrica: una en la que usamos el modelo ML para entrenar y realizamos retropropagación y otra en la que no usamos el modelo ML y solo iteramos sobre las muestras, copiándolas en la GPU. La diferencia entre las dos métricas se puede apreciar en el pseudocódigo del bucle de entrenamiento en el Algoritmo 1, donde m denota la variable de velocidad. También recopilamos el tiempo total de ejecución[3] y el tiempo que tardaron en inicializarse los cargadores de datos. Esto último fue motivado por el hecho de que algunas de las bibliotecas podrían realizar cálculos costosos por adelantado para aumentar su velocidad durante el entrenamiento. También terminamos realizando un calentamiento para calcular la velocidad. Esto se analiza con más detalle en la Subsección 3.5.

3.4 Correlación entre velocidad y tiempo de carrera

3.5 Una mirada más cercana a los tiempos de ejecución

Para aumentar nuestra comprensión de los mecanismos internos de cada biblioteca, decidimos inspeccionar en una sola ejecución cuánto tiempo llevó ejecutar cada lote e inicializar el cargador de datos. La Figura 3 muestra, para una única combinación de parámetros [4], el tiempo que tarda cada biblioteca en los pasos descritos por el Algoritmo 1. Todos estos experimentos implicaron un límite después de 10 lotes.

Curiosamente, el primer lote lleva mucho más tiempo que los demás. Esto se puede explicar de la siguiente manera: dado que la mayoría de los cargadores de datos dependen de la carga diferida de datos en este punto, las llamadas futuras se beneficiarán de la recuperación previa, los datos que ya están en la memoria y la paralelización (hacer cosas mientras la GPU está ocupada haciendo cálculos).

El tamaño de las bandas 1 a 9 proporciona la mejor indicación de qué tan bien escala cada biblioteca desde el tiempo que lleva

un conjunto de datos grande crece linealmente con ese ancho. Podemos observar que la mayoría de bibliotecas tienen un ancho uniforme, siendo Deep Lake la más corta (la más rápida). Por otro lado, la única biblioteca que muestra anchos no homogéneos es FFCV, donde las bandas 1 a 3 son tan delgadas que no se pueden ver en la imagen.

El período de finalización dura aproximadamente el mismo tiempo para todas las bibliotecas, excepto FFCV y Deep Lake, que demoran considerablemente más. El tiempo dedicado a concluir depende principalmente del modelo y no es necesariamente indicativo de qué tan bien escala cada biblioteca.

Con base en esta cifra, decidimos realizar un calentamiento al calcular la velocidad. Esto se traduce en ignorar el tiempo que tarda el primer lote en todos los cálculos de velocidad.

[2] Esto suele ser algo deseable y esperado en algunas de las publicaciones de revisión, pero descubrimos que no es el caso en varias aplicaciones prácticas que involucran equipos pequeños y estaciones de trabajo internas.

[3] Este es el tiempo desde el inicio de la simulación hasta el corte, que en la práctica a menudo era de solo 10 lotes.

[4] Conjunto de datos ALEATORIO, GPU única, 0 trabajadores, tamaño de lote 64