¿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?

Hipotesis:

1. 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.
   
   
2. 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ú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)

Set de imágenes de prueba:

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

Código fuente: 

Secuencial

Procesa la imagen píxel por píxel con un ciclo tradicional. Mide el tiempo usando QueryPerformanceCounter(), aislando únicamente la función de brillo para no contar lo que tarda en leer o guardar el archivo.

Código de la configuración secuencial

SIMD Sin hilos

Corre en un solo hilo, pero aprovecha los registros vectoriales XMM del procesador. En lugar de ir uno por uno, inyecta el brillo a bloques de 16 bytes de un solo golpe, logrando una aceleración bestial sin tener que lidiar con la creación de hilos extra.

Código de la configuración SIMD sin hilos

Resultados: 

Para corroborar nuestras hipótesis con un alto rigor estadístico, el algoritmo de incremento de brillo se ejecutó exactamente 100 veces para cada tamaño de imagen (Mediana, Grande y Muy Grande) bajo las dos configuraciones principales: Secuencial y SIMD sin hilos.
Los tiempos fueron capturados utilizando la API de alta precisión QueryPerformanceCounter() en un entorno de Windows 11 nativo. A continuación, se presenta el resumen estadístico de dichas ejecuciones, eliminando el sesgo de procesos en segundo plano del sistema operativo mediante el análisis de cuartiles.

Tabla de datos completa

Resumen Estadístico (Cuartiles y Mediana)

Secuencial:

SIMD sin hilos:

Análisis visual y tendencias

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

• El tiempo se cuadruplica al duplicar las dimensiones: Existe una tendencia clarísima en ambas configuraciones. Al pasar de la imagen Mediana a la Grande, y de la Grande a la Muy Grande, el tiempo de ejecución se multiplica por un factor aproximado de 4x (ej. en Secuencial pasa de ~4.6 ms a ~18.8 ms, y luego a ~76.0 ms).

• Superioridad absoluta de SIMD: Las gráficas evidencian que la paralelización a nivel de datos (SIMD) obtiene tiempos radicalmente menores en todos los tamaños de imagen. Mientras el código secuencial tarda milisegundos completos, SIMD resuelve las mismas imágenes en fracciones de milisegundo al procesar bloques de 16 bytes simultáneamente.

Conclusiones:

Para dar respuesta a la interrogante sobre el comportamiento de los tiempos de ejecución al variar el tamaño de la imagen, el equipo planteó dos hipótesis. La primera sugería que a mayor tamaño, el tiempo de ejecución sería irremediablemente mayor debido al incremento en el conjunto de bytes a transformar. La segunda hipótesis profundizaba afirmando que la variación del tiempo no sería exactamente proporcional al tamaño en todas las configuraciones, debido a factores de hardware subyacentes como el acceso a memoria, el uso de caché y la sobrecarga del sistema.

Tras analizar las 100 ejecuciones bajo un entorno nativo, se determina que la segunda hipótesis es la acertada y la que más se apega a la contundencia de los datos. Si bien la primera hipótesis se cumple como una regla general, los datos demuestran que la proporcionalidad exacta depende estrictamente de la configuración arquitectónica (SISD vs SIMD) y los límites físicos del hardware:

1. En la configuración Secuencial: La carga de trabajo escala de forma casi perfectamente proporcional. Al duplicar las dimensiones de la imagen (lo que cuadruplica el área y el número de píxeles), el tiempo mediano pasó de 4.62 ms a 18.87 ms, y luego a 76.00 ms. Es un factor de crecimiento lineal de ~4x, ya que el procesador atiende un byte a la vez.
   
   
2. En la configuración SIMD sin hilos: Aquí es donde la segunda hipótesis brilla. Aunque la vectorización aplastó los tiempos generales reduciéndolos a fracciones de milisegundo, el crecimiento dejó de ser proporcional. Al pasar de la imagen Grande a la Muy Grande, el tiempo saltó de 0.092 ms a 0.449 ms (un crecimiento de casi 4.8x).

Esta discrepancia valida el argumento planteado por el equipo: al utilizar instrucciones XMM ultrarrápidas, el procesamiento aritmético deja de ser el problema principal. El incremento desproporcionado en el tiempo se explica por la saturación del bus de datos y el incremento en los fallos de caché al intentar transferir una imagen muy grande desde la RAM hacia los registros del CPU, comprobando que factores físicos y de memoria influyen drásticamente en configuraciones de alto rendimiento.