Una descripción general del panorama del cargador de datos: resultados numéricos

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

4. RESULTADOS NUMÉRICOS

Para el primer conjunto de experimentos, evaluamos el rendimiento de todas las bibliotecas al cambiar la cantidad de trabajadores (ver 2), así como el tamaño del lote. Estos experimentos se ejecutaron en un servidor local con las siguientes especificaciones: Intel(R) Core(TM) i9-10900K, 2 x NVIDIA GeForce RTX 3090 y un disco duro con 10 TB de almacenamiento (6 GB/s) [5].

Evaluamos los tres modos: predeterminado (GPU única), distribuido (dos GPU) y filtrado (GPU única) para todas las combinaciones posibles de 0, 1 y 2 trabajadores. Para CIFAR10 y RANDOM, el tamaño del lote fue 16, 64 o 128. Para CoCo, utilizamos valores más pequeños: 1, 2 y 4. Todos estos experimentos utilizaron un límite de 10 y la variante que ejecuta el modelo (adelante y pase hacia atrás).

4.1 Velocidad en función del tamaño del lote y de los trabajadores

Lo primero que notamos al examinar los experimentos es que la variación entre bibliotecas depende del problema y del conjunto de datos utilizado. La Figura 4 muestra una de esas comparaciones para CIFAR10 en una sola GPU, mientras que la Figura 5 muestra el mismo resultado para CoCo, también en una sola GPU.

Esto era de esperar dado que en este último, el tiempo necesario para calcular el paso hacia adelante y hacia atrás domina el tiempo de ejecución general, lo que no es el caso para la imagen.

clasificación. También puede notar la diferencia general en la velocidad: de 4000 muestras por segundo a solo 20.

En segundo lugar, señalamos que aumentar el tamaño del lote aumenta la velocidad de procesamiento en casi todos los casos. Sin embargo, este no es el caso del número de trabajadores. Podemos observar en la Figura 6 que el rendimiento de FFCV se degrada a medida que aumenta el número de trabajadores, mientras que Deep Lake se estabiliza en 1 trabajador y no en 2. Una explicación es que las bibliotecas tienen sus propios algoritmos internos que deciden cómo abarcar subprocesos y procesos según sea necesario. El punto anterior es relevante para los usuarios de estas bibliotecas, ya que la experiencia con una de ellas puede no traducirse bien en otra.

4.2 Ganancias de velocidad al usar DDP

Una característica deseable de un cargador de datos es su capacidad de escalar linealmente con la cantidad de GPU. Esto no siempre es posible y depende del mecanismo de carga interno de cada biblioteca. Exploramos el rendimiento de estas bibliotecas comparando el aumento de velocidad al usar una o dos GPU. La Figura 7 muestra los resultados del conjunto de datos RANDOM. Cada barra representa la velocidad máxima alcanzada en todos los tamaños de lote, número de trabajadores y repeticiones. En cierto modo, esto refleja la velocidad máxima que puede alcanzar la biblioteca. Observamos que las bibliotecas aceleran alrededor del 40%, menos de la mitad de un aumento lineal en promedio. Dos casos son particularmente sorprendentes. Por un lado, Torchdata funciona peor con dos GPU que con una sola. Por otro lado, FFCV logró un aumento de velocidad mayor de lo teóricamente posible. Hay varios artefactos que pueden estar en juego aquí, pero lo más probable es que se deba al número limitado de repeticiones que pudimos ejecutar (debido a recursos limitados). Además, esto podría

indican una mala configuración en Torchdata: la documentación sobre la ejecución de experimentos en entornos multi-GPU es limitada para la mayoría de las bibliotecas.

4.3 Comparación entre con y sin pase hacia adelante y hacia atrás

Como comentamos al presentar el Algoritmo 1, tuvimos que decidir si incorporaríamos los pases hacia adelante y hacia atrás en el cálculo de la velocidad. Hay argumentos para ambos. Por un lado, incluir los pases hacia adelante y hacia atrás refleja mejor el tiempo de entrenamiento real del algoritmo. Al mismo tiempo, algunas bibliotecas pueden optimizar de forma preventiva los pasos que normalmente se realizan durante el paso hacia adelante, por lo que

detenerse allí parecería como si tardaran más de lo que tardan.

Por otro lado, si el tiempo que toma el paso hacia adelante y hacia atrás es mucho mayor que el tiempo que toma solo cargar los datos, incluir ese tiempo en el cálculo ocultaría inevitablemente la diferencia entre bibliotecas.

Para comprender si el cambio de comportamiento fue notable, utilizamos el conjunto de datos RANDOM para comparar la diferencia en la velocidad promedio cuando se incluyen las dos operaciones del modelo en el cálculo y cuando no. Los resultados se presentan en la Figura 8. Podemos observar que la mayoría de las bibliotecas tienen una velocidad ligeramente mayor al excluir el modelo (excepto FFCV, cuyo rendimiento se reduce a la mitad) y, lo más importante, el rendimiento relativo entre las bibliotecas sigue siendo casi el mismo.

4.4 Compensaciones de velocidad al filtrar datos

Para nuestros experimentos de filtrado, seleccionamos dos clases para mantener en CIFAR10 y RANDOM: perro y camión, y 0 y 13, respectivamente. Para CoCO seleccionamos tres clases: pizza, sofá, gato.

Observamos que la mayoría de las bibliotecas no tienen un buen mecanismo de filtrado que evite la iteración sobre todo el conjunto de datos. Por ejemplo, nuestra implementación de filtrado de PyTorch requiere crear una muestra personalizada con los índices de las imágenes deseadas.

Esto es bastante rápido para un conjunto de datos pequeño, pero se vuelve inviable para conjuntos de datos grandes: filtrar CoCo usando PyTorch era prohibitivamente costoso. En general, el rendimiento fue bastante similar al filtrar y al no hacerlo[6]. De manera similar a la figura

7, en la Figura 9, podemos ver la desaceleración como resultado del filtrado: aunque fue considerable para Torchdata y Webdataset, vimos una reversión de los resultados cuando trabajamos con CoCo Dataset.

4.5 Entrenamiento mientras se transmite por la red

Idealmente, podríamos desacoplar el almacenamiento del conjunto de datos del proceso de capacitación de aprendizaje automático y simplemente conectar la base de datos que almacena nuestros datos al marco de aprendizaje automático de nuestra elección, independientemente de dónde se encuentren ambos. Eso implica enviar los datos de entrenamiento a través de una red y perder una velocidad considerable. Con los altos costos que implica alquilar hardware acelerado por GPU en la nube, podría parecer que la conveniencia no vale la pena. ¿Pero no es así?

Algunas de las bibliotecas consideradas en este artículo permiten especificar un conjunto de datos accesible a través de Internet: Webdataset, Hub y Deep Lake son particularmente buenas en esto[7]. La pregunta entonces es: ¿qué tan grande es la compensación entre facilidad de uso y tiempo de ejecución?

Organizamos el siguiente experimento para ofrecer una idea de esta cuestión. Ejecutamos dos épocas completas del conjunto de datos RANDOM para las tres bibliotecas: Hub, Deep Lake y Webdataset, mientras cambiamos el origen de los datos. Se consideraron tres ubicaciones: una copia local en la máquina que ejecuta el disco duro de los experimentos, una copia en un depósito S3 (en la región más cercana a nuestra máquina) y una copia almacenada en MinIO (un equivalente de código abierto de S3 que puede ser alojado localmente) ejecutándose en una máquina similar dentro de la misma red local (ambas máquinas estaban conectadas a través de WiFi). La computadora de los experimentos tenía una CPU Intel(R) Core(TM) i7-7700 a 3,60 GHz, 16 GB de RAM, NVIDIA GeForce RTX

2070 Rev y un disco duro Samsung SSD 850 con 256 GB de almacenamiento. En cuanto a la latencia, el tiempo de ida y vuelta desde la estación de trabajo que ejecuta los experimentos hasta el servidor MinIO (ubicado en la misma habitación y en el mismo WiFi local) tomó 59,2 ± 58,5 ms (mínimo 8,8 ms), mientras que hasta el depósito S3 en AWS los servidores tardaron 17,3 ± 1,3 ms (mínimo 14,8 ms).

La Figura 10 muestra los tiempos totales de ejecución de los nueve experimentos, y los porcentajes blancos denotan la desaceleración (aumento en el tiempo de ejecución) en comparación con el caso local. Podemos observar que si bien para Hub y Webdataset hay un aumento significativo al pasar a AWS, Deep Lake logró mantener casi la misma velocidad con un aumento de solo el 13%. Se podría extraer otra información útil del resultado: la configuración MinIO muestra una desaceleración casi dos veces mayor que la configuración AWS, como se ve en la Figura 10. Este resultado podría explicarse principalmente por la diferencia en los tiempos promedio de ida y vuelta que se muestran arriba, destacando que Las redes locales (por ejemplo, redes internas de la empresa[8]) pueden no ser la forma más eficiente de alojar conjuntos de datos debido a sus complejas configuraciones y restricciones. Además, este resultado también indica que el almacenamiento que sirve los conjuntos de datos a través de la red juega un papel crucial a la hora de permitir la capacitación remota y podría generar preguntas sobre las mejores prácticas para servir conjuntos de datos. Es decir, los datos de S3 se sirven en paralelo desde diferentes servidores con equilibrio de carga mientras teníamos acceso a una única instancia de MinIO.

Los gráficos de todos los experimentos adicionales se pueden encontrar en el Apéndice A.

[5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf

[6] en velocidad. La construcción del sampler para PyTorch se realiza por adelantado, lo que afecta considerablemente el tiempo total de ejecución.

[7] Squirrel tiene esta capacidad, pero no logramos especificar una dirección MinIO, por lo que la excluimos de la comparación. Tuvimos un problema similar con Torchdata.

[8] En este caso una red universitaria