Conclusiones - RaulDiazR/Image-Processing GitHub Wiki

Conclusiones

La implementación de nuestra granja de computadoras para el procesamiento distribuido de imágenes de gran formato demostró ser exitosa en la consecución del objetivo principal: el procesamiento de las 600 imágenes. Sin embargo, la observación de una marcada diferencia en la velocidad de procesamiento entre el nodo maestro y los esclavos resalta varios elementos cruciales para la obtención de los resultados y sugiere áreas claras de mejora.

Elementos Importantes para la Obtención de los Resultados

Arquitectura Maestro-Esclavo y Paralelización: La elección de una arquitectura maestro-esclavo combinada con MPI para la distribución de tareas y OpenMP para la paralelización interna fue fundamental. Esto permitió dividir una tarea computacionalmente intensiva (procesamiento de imágenes de gran formato) en subtareas más manejables que pudieron ejecutarse concurrentemente. El hecho de que el procesamiento total de las 600 imágenes se completara en aproximadamente 40 minutos es un indicativo del beneficio de esta aproximación distribuida.
Interfaz Gráfica (GUI): La interfaz gráfica desarrollada con PyQt Designer fue un elemento clave para la usabilidad del sistema. Permitió al usuario especificar fácilmente las rutas de entrada y salida, así como personalizar el filtro de blurring, lo que simplificó la interacción con la solución y la ejecución del experimento.
Filtrado Múltiple y Personalizable: La capacidad de aplicar múltiples filtros (escala de grises, espejos, blurring) y la flexibilidad de un kernel programable para el blurring demuestran la robustez y la versatilidad de la solución propuesta.

Modificaciones Futuras y Consideraciones Basadas en los Resultados del Experimento

La disparidad en el rendimiento entre el maestro y los esclavos, donde el maestro finalizaba sus tareas en segundos mientras los esclavos tardaban varios minutos, apunta a cuellos de botella específicos que deben abordarse:

Limitaciones de Ancho de Banda de Red: La creencia de que el uso de cables Ethernet y la red local (switch) actuaron como una limitante es muy plausible. El transporte de imágenes de gran formato hacia los esclavos para el procesamiento y su posterior retorno al maestro (que implica la recepción de datos, el procesamiento local y el envío de las 6 imágenes procesadas de vuelta) genera un tráfico de red considerable. Este intercambio de datos, especialmente de archivos grandes, puede saturar la red y convertirse en un cuello de botella significativo. Para modificar la respuesta y optimizar el rendimiento, se podría considerar:
- Actualizar la infraestructura de red: Implementar cables Ethernet de mayor categoría (Cat6 o superior) y switches Gigabit o 10 Gigabit Ethernet para aumentar drásticamente el ancho de banda disponible.
- Optimización de la transferencia de datos: Explorar técnicas de compresión de imágenes antes de la transferencia (si es viable sin comprometer la calidad para los filtros aplicados), o transferencias asíncronas que permitan que la computación y la comunicación se superpongan en lugar de bloquearse mutuamente.
- Procesamiento más cerca de los datos: En escenarios con datos extremadamente grandes, considerar si la arquitectura puede adaptarse para que el almacenamiento final no dependa exclusivamente del maestro, o si se puede distribuir el almacenamiento para reducir el tráfico de retorno.
Desbalance de Recursos de Hardware: Las diferencias significativas en las especificaciones de hardware entre el maestro y los esclavos son un factor determinante.
- Cores/Threads: El maestro contaba con 8 cores y 16 threads, mientras que los esclavos tenían configuraciones de 6, 6 y 4 cores, y 12, 12 y 8 threads, respectivamente. Una mayor cantidad de núcleos y threads en el maestro significa que puede procesar su carga de trabajo asignada (y posiblemente parte de la orquestación) mucho más rápido.
- RAM: La diferencia en la RAM (24GB en el maestro vs. 8GB, 8GB y 16GB en los esclavos) también impacta el rendimiento. El procesamiento de imágenes de gran formato es intensivo en memoria; los esclavos con menor RAM podrían estar experimentando un mayor uso de memoria virtual (swapping), lo que ralentiza drásticamente las operaciones de lectura y escritura de datos de imagen.
- Almacenamiento: La limitación de espacio en disco en los esclavos (apenas 40GB) en contraste con el maestro sugiere que los esclavos podrían tener que lidiar con limitaciones de almacenamiento temporal, lo que podría generar cuellos de botella si el procesamiento intermedio o la gestión de archivos requiere más espacio del disponible, o si la velocidad de acceso al disco es inferior.
Para mejorar la respuesta de acuerdo a estos datos, se debería:
- Homogeneizar los recursos: En futuras iteraciones, sería ideal equilibrar las especificaciones de hardware de los nodos esclavos para que sean comparables al maestro, o al menos entre sí. Esto incluye la cantidad de cores/threads, la RAM y el espacio de almacenamiento.
- Escalabilidad vertical en esclavos: Invertir en esclavos con procesadores más potentes, más RAM y espacio en unidades de estado sólido (SSD), mejoraría significativamente la velocidad de procesamiento local de las imágenes y la eficiencia en la gestión de archivos.

En resumen, si bien la práctica logró su objetivo funcional, la optimización del rendimiento requerirá una inversión estratégica en la infraestructura de red y en la homogeneización y mejora de los recursos de hardware de los nodos esclavos. Abordar estos puntos transformaría la solución de una prueba de concepto funcional a un sistema de procesamiento distribuido verdaderamente eficiente y escalable.