¿Qué va a ocurrir con el Speedup a medida que se incremente el tamaño de las imágenes en cada sistema operativo, pero con el mismo número de hilos por prueba?

Hipotesis

  1. El Speedup será mayor cuando aumente el tamaño de la imagen, porque habrá más píxeles para repartir entre los hilos. En imágenes pequeñas, el trabajo es tan poco que el tiempo usado en crear y coordinar los hilos puede pesar demasiado; en cambio, con imágenes más grandes, ese costo se compensa mejor porque cada hilo tiene más trabajo real que hacer.

  2. En imágenes muy grandes, el Speedup podría dejar de crecer aunque se mantenga el mismo número de hilos. Esto puede pasar porque el problema ya no estaría tanto en la cantidad de operaciones del procesador, sino en qué tan rápido el sistema puede leer y escribir datos en memoria. Es decir, llega un punto donde el límite lo pone el hardware, principalmente la memoria y la caché, no solamente el número de hilos (Al hardware le falta power).

Metodología y diseño de pruebas

Hardware utilizado:

CPU:

  • Ryzen 7 8700G - 4.2 GHz base / 5.1 GHz turbo
  • 8 Núcleos
  • 16 Hilos
  • Caché 24MB

Gráficos:

  • AMD Radeon 780M - 2.9 GHz

Memoría:

  • 2 x 16GB
  • DDR5
  • 6000 MHz

Sistema operativo:

  • Windows 11 Home (Nativo)

Hardware virtualizado:

  • 8 Núcleos

Memoría:

  • 16GB

Sistema operativo:

  • Ubuntu 26 (Virtualizado)

Set de imágenes de prueba:

  • (Normal) 620 x 465 Pixeles
  • (Grande) 1240 x 930
  • (Muy grande) 2480 x 1860

Código fuente: 

OpenMP (Windows / Linux)

Utiliza directivas de alto nivel (#pragma) para paralelizar el ciclo que recorre los píxeles de la imagen. El compilador se encarga de instanciar los hilos (8 en este caso) y repartir la carga matricial. Para Linux, la librería de Windows se cambia por <sys/time.h> para la captura del tiempo.

Resultados: 

Para evaluar el rendimiento del paralelismo, el cálculo de Speedup se ejecutó analizando 100 iteraciones exactas por cada tamaño de imagen (Normal, Grande y Muy Grande) manteniendo una configuración constante de 8 hilos con OpenMP. Los tiempos comparativos fueron capturados utilizando las APIs de alta precisión (QueryPerformanceCounter en Windows nativo y gettimeofday en Linux). A continuación, se presenta el resumen estadístico de la aceleración obtenida, eliminando valores atípicos del sistema operativo mediante el análisis de cuartiles.

Análisis visual y tendencias

Windows



Linux


Al observar las gráficas y compararlas con nuestra tabla de medianas, destacan dos comportamientos principales que responden directamente a nuestras interrogantes:

  • El peso del Overhead en imágenes pequeñas: En la configuración de la imagen Normal (Linux), existe una tendencia clarísima de baja eficiencia. El Speedup fluctúa apenas entre 1.0x y 1.6x, lo que se refleja en una caja sumamente comprimida en la parte baja de la gráfica.

  • Aceleración progresiva y sostenida: Al pasar de la imagen Normal a la Grande, y luego a la Muy Grande, el Speedup no se detiene. En Linux escala de ~2.5x a ~5.5x, mientras que en la ejecución nativa de Windows (imagen Muy Grande) se observa una aceleración monumental que promedia los ~15.6x.

Conclusiones:

Para dar respuesta a la interrogante sobre el comportamiento del Speedup a medida que se incrementa el tamaño de las imágenes manteniendo el mismo número de hilos por prueba, el equipo planteó dos hipótesis. La primera sugería que el Speedup sería mayor al aumentar el tamaño porque se compensaría el costo de coordinar hilos al haber más píxeles por procesar. La segunda hipótesis planteaba que en imágenes muy grandes el Speedup dejaría de crecer, estancándose al topar con el límite del ancho de banda de la memoria del hardware.

Tras analizar las 100 ejecuciones de OpenMP, se determina que la primera hipótesis es la acertada y la que más se apega a la contundencia de los datos. El rendimiento escaló positivamente al existir una mayor carga de trabajo:
  1. En imágenes pequeñas (Normal): El costo computacional de crear, coordinar y destruir los 8 hilos pesa demasiado frente al poco trabajo aritmético necesario para recorrer la imagen. La ganancia paralela es marginal.

  2. En imágenes de mayor tamaño (Grande y Muy Grande): El paralelismo se aprovecha a su máxima capacidad. El Speedup nunca dejó de crecer ni se topó con un cuello de botella en la RAM como sugería la segunda hipótesis. Al contrario, al fragmentar la inmensa cantidad de píxeles entre los hilos, cada uno manejó un bloque de datos que encajó eficientemente en la memoria caché del procesador, disparando el rendimiento y demostrando que la sobrecarga inicial del sistema operativo queda completamente amortizada.

Comentarios

Publicar un comentario

Entradas más populares de este blog

¿Cómo se van a comportar los tiempos de ejecución si se mantiene el código, pero se varía el tamaño de la imagen a procesar, en cada configuración? Y ¿existe una variación y si existe cómo se podría explicar tal variación observada?

Imagen
Hipotesis: A mayor tamaño de imagen es más probable que el tiempo de ejecución sea mayor, dependiendo incluso de la configuración, algunas podrían tener mejores resultados que otras, pero eso no quita el hecho de que el tamaño de imagen aumenta el tiempo de ejecución. La manera en que se podría explicar la variación, es que una imagen de mayor tamaño tiene un conjunto de bytes mayor, por lo que el proceso para transformar la imagen conlleva un mayor tiempo. La variación del tiempo no será exactamente proporcional al tamaño de la imagen en todas las configuraciones, porque también influyen factores como el acceso a memoria, el uso de caché, la sobrecarga de los hilos, el sistema operativo y la forma en que se reparte la carga de trabajo. En imágenes pequeñas, la sobrecarga puede pesar más que el procesamiento; en imágenes grandes, el paralelismo puede aprovecharse mejor.   Metodología y diseño de pruebas Hardware utilizado: CPU: Ryzen 7 8700G - 4.2 GHz base / 5.1 GHz turbo 8 Nú...
Leer más

¿Cómo se comportan los tiempos de ejecución al incrementar el número de hilos?

Imagen
¿Cómo se comportan los tiempos de ejecución al incrementar el número de hilos? Introducción En esta entrada se analiza el rendimiento de un programa de procesamiento de imágenes BMP de 24 bits. El objetivo del programa es incrementar el brillo de una imagen utilizando una rutina SIMD en ensamblador y dividiendo el trabajo entre varios hilos. La pregunta que se busca responder es la siguiente: ¿Cómo se van a comportar los tiempos de ejecución al incrementar el número de hilos con un mismo tamaño de imagen a procesar? Esta pregunta es importante porque permite observar si el uso de más hilos realmente mejora el rendimiento del procesamiento de imágenes, y también permite identificar si existe un punto donde agregar más hilos deja de ser útil. Hipótesis iniciales Hipótesis 1: Se debería reducir el tiempo de ejecución, ya que con un mayor número de hilos se puede dividir la tarea en más partes y así ejecutar el código al mismo tiempo, consiguiendo así un menor tiempo de ejecución. Hipótesi...
Leer más

¿Qué código reportará mejor Speedup, el generado por IA en un lenguaje de alto nivel como Python o el de la versión C/C++?

Imagen
Hipotesis La versión en C/C++ reportará un Speedup algo superior al de Python. C/C++ se compila a código nativo ya que permite el uso real de hilos en paralelo y la implementación de bajo nivel con instrucciones SIMD permite procesar múltiples canales de píxeles simultáneamente por ciclo de reloj, aprovechando verdaderamente el hardware sin intermediarios. El código de Python tendrá un Speedup cercano a 1 (nulo o sin mejora) en arquitecturas multihilo puro debido al mecanismo Global Interpreter Lock, que restringe la ejecución de bytecode a un solo hilo nativo a la vez. Incluso si la IA genera un código estructurado con hilos, estos se ejecutarán de forma secuencial en la CPU, a menos que se recurra explícitamente a multiprocesamiento, el cual tiene una sobrecarga de memoria muy alta en comparación con C++. Metodología y diseño de pruebas Hardware utilizado: CPU: Intel Core Ultra 7 255H (Frecuencia Base: 2.00 GHz / Turbo Máximo: 5.10 GHz) 16 Núcleos físicos  22 Hilos Caché 24MB...
Leer más