Temario

Sesiones	Tareas
1. Introducción al cómputo paralelo	Tarea_1 Fecha de entrega: 02/Feb
2. OpenMP
3. OpenMP-Ejemplos

Calificaciones:

Num. Ctrl.	T1_OMP	Comentarios	T2_CUDA	Comentarios	T3_CUDA	Comentarios	T4_CUDA	Comentarios	Prom. Tareas	Proyecto	Calif. Final 0.7T+0.3P

 

Comentarios:

• T1_OMP_1: En el ejercicio 1 hay que considerar que aunque la variable x tome el valor que tenia antes de entrar a la región paralela, esta puede cambiar su valor en cualquier parte de la región paralela. 
  
• T1_OMP_2: En el ejercicio 1 tu análisis del resultado de y[i] no está considerando que el código se está paralelizando y que estamos lanzando exactamente 5 hilos. Además el valor de x al finalizar la región paralela vuelve a ser 1.
• T1_OMP_3: En el ejercicio 1 es posible saber cual será el valor de cada elemento en el arreglo "y". Solo imagina que el número de iteraciones del ciclo se reparte entre los hilos ejecutados de forma estática.
  
• T1_OMP_4: En el ejercicio 1 tienes un detalle en el último valor del arreglo "y" resultante, este debe ser 17.
• T1_OMP_5: En el ejercicio 1 el objetivo es determinar cuales serían los valores del arreglo "y" y la varaible "x" después de completar todas las iteraciones del ciclo for. Nota que al poner printf dentro de la región paralela, la información podría aparecer en diferente orden, es decir el último valor que imprimes de "y[i]" podría no coincidir con el último valor del arreglo "y", es decir el y[9]. Si ejecutas varias veces el programa puedes ver que el ultimo valor que imprimes puede cambiar. 

• T2_CUDA_1: Faltó entregar el reporte.
• T2_CUDA_2: Está interesante el LeetGPU. Pero en el ejemplo del HolaMundo hay un detalle en tu código. Ya que estás lanzando 3 bloques y 4 hilos en cada bloque, entonces threadIdx.x debe ir con el módulo %4 y blockIdx.x con el módulo %3. Por otro lado, también puedes ejecutar tu código con la opción "Cycle Accurate", con esta opción ya te arroja los índices correctos.
• T2_CUDA_3: No entregó tarea.
  

• T3_CUDA_1: En el reporte solo describes la tabla de resultados, faltó describir lo que hiciste para paralelizar el programa usando OpenMP y CUDA.
• T3_CUDA_2: Los tiempos que reportas son usando el emulador, sería bueno probarlo en una computadora con GPU.
  
• T3_CUDA_3: Faltó describir la implementación del ejercicio c) y evaluar los tiempos de procesamiento con dicha implementación.
  
• T3_CUDA_4: No obtienes una ganancia en speedup al usar memoria compartida con respecto a la memoria global, por que la implementación que tienes no aprovecha de forma correcta la memoria compartida. Analiza los ejemplos que vimos al usar memoria compartida y te darás cuenta que al menos un hilo de cada bloque de hilos puede realizar una suma parcial, la cual se va acumulando con el uso del atomicAdd. Lo que estás haciendo es utilizar el atomicAdd para todos los hilos que estás ejecutando dentro de la función kernel.
  
• T3_CUDA_5: Tu implementación usando memoria compartida es correcta, sin embargo no hay una ganancia significativa en tiempos comparado con el uso de la memoria global ya que no cambiaste el número de hilos por bloque que estas usando, el cual es muy pequeño: BLOCK_SIZE=4, BLOCK_SIZE=8. Prueba con valores más grandes y notaras la diferencia.
  
• T3_CUDA_6: La forma de medir tiempos de procesamiento de tus funciones kernel es incorrecta, ya que las llamadas a las funciones kernel son asincronas, necesitas poner la instrucción cudaDeviceSynchronize() para poder usar el std::chrono.
  
• T3_CUDA_7: No obtienes buenos resultados en el speedup usando la GPU por que los tiempos que mides consideran la creación de memoria y las copias de memoria. Prueba mejor midiendo solamente el tiempo de procesamiento de la función kernel. Una forma es usando el profiler: nvprof.
  
• T3_CUDA_8: Puedes obtener mejores resultados con la implementación en GPU usando memoria compartida si utilizas más hilos para realizar las sumas parciales en cada bloque de hilos.
  
• T3_CUDA_9: En esta tarea se pedía considerar valores de punto flotante de 32 bits, es decir, utilizar el tipo de dato float. De esta forma no era necesario considerar estrategias para lidiar con el atomicAdd para tipos de datos double en tarjetas que no tienen capacidad >=6.0.
  
• T3_CUDA_10: De acuerdo con tu reporte, usaste una GPU P100, la cual debe tener capacidad 6.0, por lo tanto basta con indicarle al compilador la capacidad de la tarjeta con la bandera: -arch=compute_60 o -arch=sm_60.
  

• T4_CUDA_1: Faltó poner en el reporte cómo se desarrollaron cada uno de los ejercicios, mostrar algunos resultados y explicarlos.
  
• T4_CUDA_2: Hay un problema con el tipo de dato de tus arreglos en el ejercicio de la detección de bordes. Todos tus arreglos son de tipo uchar, entonces dentro de tu función "Filtro" realizas operciones que pueden tomar datos negativos o que pueden estar por encima del valor máximo de un uchar. Si cambias esto "MG_dev[idy * imageW + idx] = sqrt((float)(ix * ix + iy * iy));" por "MG_dev[idy * imageW + idx] = min(255,sqrt((float)(ix * ix + iy * iy)));" los bordes se ven más limpios.
  
• T4_CUDA_3: El código correspondiente al ejercicio de la combinación de dos imágenes no compila y tiene muchos errores, por ej.: Dentro de la función kernel faltó agregar [idx] a image2_dev.x; alpha_dev y composedImage_dev no se han declarado en el main(); olvidaste el atributo .data para pasar la memoria de mask_float a alpha_dev; etc...
  
• T4_CUDA_4: En lugar de dividir el contenido de la imagen máscara o alpha entre 255, es mejor comparar el valor con respecto a un umbral (128) de esta forma nos aseguramos que valores casi 255 sean exactamente 255.  
  
• T4_CUDA_5: Faltó aplicar el umbral a la magnitud del gradiente.
  
• T4_CUDA_6: Para mayor eficiencia en el código de la combinación de las imágenes, sería bueno considerar la máscara o el alpha como una imagen binaria de un solo canal, en lugar de tres canales.
  

Proyectos:

• 
  

Bibliografía:

• Rauber, T., & Rünger, G. (2013). Parallel Programming. Springer.
• Pacheco, P. (2011). An introduction to parallel programming. Elsevier.
• Chapman, B., Jost, G., & Van Der Pas, R. (2007). Using OpenMP. Portable Shared Memory Parallel Programming.
• Sanders, J., & Kandrot, E. (2010). CUDA by Example: An Introduction to General-Purpose GPU Programming, Portable Documents. Addison-Wesley Professional.
• Kirk, D. B., & Wen-Mei, W. H. (2009). Programming massively parallel processors: a hands-on approach. Morgan Kaufmann.
• Cook, S. (2012). CUDA programming: a developer's guide to parallel computing with GPUs. Newnes.
• Wilt, N. (2013). The cuda handbook: A comprehensive guide to gpu programming. Pearson Education.
• Zaccone, G. (2015). Python parallel programming cookbook. Packt Publishing Ltd.
• CuPy: https://docs.cupy.dev/en/stable/reference/index.html
  
• GPU Technology Conference, http://www.gputechconf.com/
• Webinars, https://developer.nvidia.com/gpu-computing-webinars