Cada resolución de los ejercicios propuestos para este trabajo se localiza un una carpeta individual con el nombre correspondiente. Cada carpeta contiene:

• El o los códigos necesarios para cada prueba.
• Un script de compilación ``compile.sh''.
• Un script denominado ``run.sh'' para ejecutar todos los programas referidos al ejercicio en el cluster.
• Los resultados obtenidos en archivos .out y .err en un subdirectorio denominado ``results''.
• Un subdirectorio ``imgs'' con scripts para procesar los archivos de resultados y generar un CSV utilizable por el programa gnuplot. Los gráficos de barras y líneas producidos se encuentran en este mismo directorio.

Considerando que el cluster CDER posee dos placas gráficas diferentes, se propone como convención denominar a:

Grupo G

a las máquinas del cluster con placas GeForce GTX Titan (GeForce GTX 980) y

Grupo T

a las máquinas con placas Tesla V100.

En primera instancia, se analizarán las placas gráficas disponibles dentro del cluster CDER a utilizar. Para ello, se realizará una aplicación que solicite los datos necesarios al sistema por medio de los pasos que se explicarán a continuación.

Primero, es necesario obtener la cantidad de dispositivos que puedan realizar cómputos. Esto se realiza con la función cudaGetDeviceCount(&count). Luego, por cada dispositivo se solicitarán sus detalles por medio de la función cudaGetDeviceProperties(&prop, dev), dónde dev es el número de dispositivo.

Los datos obtenidos serán contenidos dentro dentro de la variable prop, la cual es de tipo cudaDeviceProp. Dicha estructura esta compuesta por varios campos que representan cada una de la información que corresponde al detalle del dispositivo: nombre, versión, cantidad de memoria global, etc. Una descripción completa se puede encontrar en su documentación Web de CUDA cuda_deviceprop.

A continuación se describen algunos campos de relevancia que fueron utilizados en el programa. Supóngase que prop es una variable de tipo cudaDeviceProp.

prop.name

Nombre que identifica al dispositivo.

prop.totalGlobalMem

Memoria global disponible (en bytes).

prop.totalConstMem

Memoria constante disponible (en bytes).

prop.maxThreadPerBlock

Máximo número de hilos por bloque.

prop.maxThreadsDim

Un arreglo de 3 elementos con el máximo tamaño de cada dimensión del bloque.

prop.maxGridSize

Un arreglo de 3 elementos con el tamaño máximo de cada dimensión de la grilla.

prop.multiProcessorCount

Número de multiprocesadores en el dispositivo.

Al ejecutar el script run.sh dentro del cluster se producirán una salida por cada grupo. Para el grupo T se genera el siguiente resultado.

--- General Information for device 0 ---
Compute name: Tesla V100-PCIE-16GB 
Compute capability: 7.0
Clock rate: 1380000
 --- Memory Information for device 0 ---
Total global mem: 16914055168
Total constant Mem: 65536
 --- MP Information for device 0 ---
Multiprocessor count: 80
Shared mem per mp: 49152
Registers per mp: 65536
Threads in warp: 32
Max threads per block: 1024
Max thread dimensions: (1024, 1024, 64)
Max grid dimensions: (2147483647, 65535, 65535)

Y para el grupo G, el siguiente.

--- General Information for device 0 ---
Compute name: GeForce GTX TITAN X 
Compute capability: 5.2
Clock rate: 1076000
 --- Memory Information for device 0 ---
Total global mem: 12806062080
Total constant Mem: 65536
 --- MP Information for device 0 ---
Multiprocessor count: 24
Shared mem per mp: 49152
Registers per mp: 65536
Threads in warp: 32
Max threads per block: 1024
Max thread dimensions: (1024, 1024, 64)
Max grid dimensions: (2147483647, 65535, 65535)

Utilizando estos datos obtenemos la Cuadro tab:detalles_placas.

Por consiguiente, se espera que el grupo T ofrezca un mejor rendimiento de un programa si se aprovecha completamente el dispositivo con respecto al grupo G. Con respecto a la cantidad de hilo para paralelizar, ambos ofrecen el mismo tamaño de grilla y de hilos por bloque. Más información acerca de las especificaciones técnicas de estas placas gráficas se encuentran disponibles en la página oficial de NVIDIA® y GeForce geforce:titanx,nvidia:titanx,nvidia:tesla.

En la suma de vectores se propone sumar de forma secuencial una serie de números en CPU y posteriormente realizarlas en paralelo.

El código se realizó para tomar tiempos de GPU y CPU aún si el programa nvprof no funcionase. Además, se modificó para que ciertos parámetros puedan ser ingresados como argumentos del programa, quedando la sinopsis de la siguiente forma:

./suma_vectores tam veces blockx blocky gridx gridy

De esta manera, se puede modificar los siguientes atributos por cada llamada:

tam

Tamaño del vector.

veces

Veces que se repite el experimento.

blockx, blocxy

Formato del bloque (cantidad de hilos en X e Y).

gridx, gridy

Formato de la grilla (cantidad de bloques en X e Y).

Utilizando varios valores para estos parámetros se realizan varias ejecuciones para medir sus tiempos de ejecución. En la Cuadro tab:params-suma-vec se presentan las distintas pruebas realizadas y sus parámetros. Las pruebas iniciales se enfocan en ver qué sucede con los tiempos de ejecución al incrementar la cantidad de datos. Las pruebas 7, 8 y 9 se incrementan las veces en que se repite la suma pero con pocos datos. Las tres siguientes tratan de usar una buena cantidad de datos y variando la repetición de la suma. Por último, se repiten las pruebas pero aumentando la cantidad de hilos dentro de la configuración de los bloques.

Además, se tuvo cuidado de reservar la cantidad de recursos necesaria para poder llevar a cabo la tarea. Por ejemplo: en el experimento número 6, se requiere 39063 bloques de 256 hilos para poder realizar el cálculo de 10000000 elementos del vector, a pesar de que hayan quedado 128 hilos libres de un bloque.

Para estudiar los resultados, se procederá, primeramente, a comparar los tiempos de CPU con respecto a los de GPU sin considerar la transmisión de datos. Luego, se considerarán todos los tiempos. En el gráfico de la Figura fig:suma_vectores se muestra los de GPU, CPU y GPU sumado la copia a memoria para cada experimento.

Obsérvese los experimentos del 1 al 6, en los cuales se nota una creciente en los tiempos de CPU debido al aumento de la cantidad del tamaño del vector. Sin embargo, el tiempo de GPU tiende a aumentar en un ritmo menor aparentando incluso a ser casi constante al principio. Si se observa el tiempo de ``GPU + memcpy'' se aprecia un aumento considerable en los tiempos, incluso superando el tiempo de CPU. Esto nos indica que la tranferencia de datos penaliza de forma significativa los tiempos de ejecución con respecto al tiempo de uso de la GPU.

Para el caso de los experimentos numerados entre el 7 y el 9, se testea baja cantidad de datos pero la cantidad de ejecución del algoritmo en aumento. Tanto en GPU como en CPU el crecimiento es estable aunque los tiempos de GPU son mayores. La copia de datos al dispositivo no afecta a los tiempos de forma considerable. Los resultados obtenidos en estas tres purebas nos muestra que el uso de la GPU no se justifica para pocos datos.

Los experimentos de 9 al 11, los tiempos para la GPU son muy favorables. La cantidad de datos es considerable y las operaciones a realizar se repiten de forma creciente logrando que el CPU las realice de forma secuencial y la GPU paralela. Aquí se aprecia un beneficio en el uso de las tarjetas gráficas puesto que las operaciones de copiado de datos se realizan al principio y al final del experimento una única vez y se aprovecha el paralelismo en la gran cantidad de operaciones.

En los experimentos del 13 al 15 se aumenta la cantidad de hilos por bloque y se preserva la cantidad de datos y de repeticiones de forma constante. Los resultados no varían mucho manteniendose constante.

Es importante ver el aprovechamiento del hardware al comparar el experimento 15 con el 12. Ambos poseen la misma cantidad de datos y se repite la misma cantidad, pero la cantidad de hilos por bloque es diferente. El experimento 15 resolvió el problema en menos tiempo de ejecución, haciendo uso del hardware de forma más eficiente. Del 16 al 21 se repiten los experimentos utilizando 1024 hilos por bloque. Aprovechando el máximo de paralelismo se obtiene una mejora en especial cuando se aumentan la cantidad de operaciones que la GPU debe hacer. Por ejemplo, al comparar la prueba 11 con la 21 se obtiene una mejora de ms.

La suma de matrices consiste en trasladar la suma de vectores a una dimensión más. En este caso, se debe considerar en distribuir el procesamiento a hilos usando grillas y bloques con dos dimensiones. Análogo al programa de suma de vectores, el tamaño de la matriz y la cantidad de bloques y grillas se puede configurar con los argumentos quedando la sinopsis del comando de la siguiente forma:

./suma_matrices filas cols grid_x grid_y block_x block_y

En el código del kernel, se realiza un chequeo para evitar la ejecución de hilos cuyos índices estén fuera del tamaño del vector. Esta situación puede producirse cuando el tamaño de la matriz no es múltiplo de la cantidad de hilos por bloque en la dimensión determinada.

Además, debido a la consideración de alineamiento de 32 hilos por warp, es posible que hayan hilos restantes al asignar un bloque para completar el tamaño de la matriz. Por ejemplo: si la matriz es de 100 filas y 100 columnas, se requieren 10000 hilos repartidos en 4 × 4 (16) bloques de 32 × 32 (1024) hilos, restando 6 bloques y 240 hilos asignados pero sin utilizar. Por consiguiente, el condicional que figura en el siguiente código del kernel fue incluido para cumplir con este propósito.

if (c < cols && f < filas){
  int i = c + (f * cols);
  MatC[i] = MatA[i] + MatB[i];
}

Se han ejecutado varias pruebas con diferentes objetivos. En el cuadro tab:suma_matrices se muestran los distintos tamaños de las matrices y la configuración de la grilla y sus bloques. Las pruebas del 1 al 6 se enfocan en ver qué sucede entre los tiempos de CPU y GPU a medida que la cantidad de datos crece. Para las 7 y 8 se busca ver qué sucede ante una grilla de configuración lineal contra una matricial. Y desde la prueba 9 hasta la 12 se desea probar configuracione de grillas desalineadas o con exceso de hilos para ver si esto afecta a la performance. Los resultados se muestran expresados en la Figura fig:res-suma_matrices. En este gráfico se puede apreciar que para una matriz de hasta 5000 × 5000 elementos es beneficioso utilizar la CPU. Esto es debido a que la gran penalización que conlleva el traslado de la información, desde y hacia el dispositivo de la GPU, no compensa con la cantidad de operaciones que la GPU debe realizar.

Los experimentos del 1 al 6 se enfocan en aumentar gradualmente la cantidad de datos manteniendo la grilla de forma uniforme y alineada. Se aprecia un aumento considerable en el trabajo de la CPU comparado con el de la GPU. Esta última realiza la suma dentro del milisegundo, casi diez veces más rápido que la velocidad del CPU. Sin embargo, el precio por trasladar los datos hace que se pierda este beneficio.

En el caso del 7 y el 8, se denota un leve aumento en los tiempos del GPU al intentar distribuir los datos en 32 × 32. La cantidad de threads que se ejecutaron son 157×5000×1024 = 804625000 y 157×157×32×32 = 25240576 respectivamente. Se requieren 25000000 threads para realizar la suma, sobrando 55462500 y 240576 threads respectivamente.

Analizando las métricas proveídas por el programa nvprof en el Cuadro tab-met-suma_matrices se puede deducir por qué aumentan los tiempos al estar desalineadas y mal configuradas las grillas.

El valor de ocupación alcanzada (achieved occupancy) nos muestra una proporción del promedio de los warps activos por ciclos activos al máximo número de warps soportado por un multiprocesador, la diferencia es de 0.28, indicando que hubo inactividad.

Además, se puede diferenciar que hubo una gran cantidad de instrucciones enteras, de control de flujo y otras para el test 7 en comparación con las que más nos interesan que son las de punto flotante. Esto se debe al condicional y al cálculo de la columna y fila de los threads sobrantes.

La cantidad de memoria utilizada, a primera vista, aparenta que es mayor para el test 8 que para el 7. Esto se debe a que la cantidad de threads del primer test es menor, pero a diferencia de la prueba 7, la mayoría de ellos realizan realmente la suma entre dos valores que están en memoria. El test 7 posee más threads pero una gran cantidad no realiza la suma y, como consecuencia, no necesita de los datos de memoria.

En definitiva, el Test 7, que posee los más threads desocupados y desalineados, realiza más trabajo y desaprovecha los recursos de la placa realizando instrucciones que no tienen relación con la suma de matrices. Incluso la utilización de la memoria se ve desaprovechada, puesto que muchos de los threads no acceden a ella resultando en una caída en la tasa de productividad (Global Load/Store Throughput) de la memoria.

Para el resto de las pruebas, se intentan con alineamientos fuera de los 32 hilos que contienen un warp. Esto lleva a un tiempo de GPU que supera a los previos debido a que la placa requiere de más tiempo por ciclo para realizar la misma tarea que podría hacer en uno. En especial cuando se solicita una grilla de 10000 × 10000 elementos y sólo se utilizan 5 × 5 hilos, se nota un incremento importante.

La suma de matrices requería una traslación de datos importante que hacía que la eficiencia del procesamiento paralelo no compensara los tiempos de copia de datos. En este caso, la convolución requiere de más trabajo de procesamiento y por consecuencia, un trabajo de paralelismo necesario que puede compensar los tiempos de transferencia.

Las pruebas a realizarse son las siguientes:

• Diferencias en tiempos a medida que el filtro crece.
• Diferencias en tiempos a medida que los datos crecen, pero el filtro se mantiene fijo.
• Diferencias en tiempos con pruebas similares, pero utilizando tipos de datos double.

En la Cuadro tab:pruebas_convolucion se pueden observar el número de experimento y sus respectivos parámetros. Las pruebas del 1 al 7 utilizan tamaños fijos del arreglo, pero varían el del filtro. Las del 8 al 13, fijan el tamaño del filtro para testear los tiempos a medida que crecen la cantidad de datos. Luego, se repiten las pruebas pero usando tipo de datos double. La finalidad de esta distribución de tests es determinar cuándo es más eficiente utilizar la GPU: si es más eficiente a medida que el filtro crece en tamaño o a medida que la cantidad de datos aumenta.

En la Figura fig:res_convolucion_float se observa una comparación entre los tiempos de CPU y GPU para resolver la convolución. Como se puede observar, los tiempos de CPU son muy elevados con respecto a los de GPU sumada la transferencia de los datos. Los experimentos del 1 al 7 notan un crecimiento a medida que aumenta el tamaño del filtro, aunque no superan los 10ms. Un crecimiento más estable se aprecia a medida que se aumentan los datos y el filtro se mantiene a partir del experimento 8, incluso, el tiempo de transferencia se encuentra en un crecimiento proporcional al tamaño de la entrada.

En la Figura fig:res_convolucion_double se aprecia el mismo comportamiento para cuando se utilizan tipos de datos double. Sin embargo, al comparar los tiempos en forma numérica (véase la Cuadro tab:ap_conv_float y tab:ap_conv_double en el Apéndice ``Resultados de la Convolución 1D'') se detecta mayormente una tendencia a superar los valores de los tiempos con respecto a los de punto flotante. Por ejemplo, el tiempo de uso de GPU para float en las experiencias 15 y 19 son las únicas que superan al de double.

Para una mejor comparación, se presenta la Figura fig:res_conv_double_float, la cual muestra la diferencia entre las ejecuciones de las mismas experiencias usando ambos tipos de datos. Aunque los tiempos de GPU son similares al principio, a partir de las pruebas 8 se nota un incremento estable en los tiempos. Se puede concluir, que el tiempo de ejecución de double supera al de float tanto en GPU como en GPU sumado el tiempo de transferencia, haciéndose más notorio a medida que la cantidad de datos crece.

Para el siguiente caso, se probará copiar el filtro desde el host a dos tipo de memorias disponibles en la placa gráfica. En la Figura fig:memories se muestra la ubicación de las diferentes memorias con respecto a los bloques y GPU.

La memoria constante es una memoria global de capacidad más reducida que posee una caché para agilizar su acceso. Puede ser accedida por todos los threads y su acceso es más rápido comparado con la memoria global. Obsérvese que el host puede acceder para inicializarla con información de forma directa. La memoria compartida reside dentro del bloque y puede ser utilizada por sus threads. La cercanía con el thread la hace muy ágil, pero es de tamaño muy reducido y sólo puede ser accedida por el thread lo que lo hace responsable de su inicialización.

Se propone implementar la convolución con el filtro residiendo en las tres memorias: global, compartida y constante. En nuestro caso, la Cuadro tab:detalles_placas indica que disponemos de más de 10GiB de memoria global, 64MiB de memoria constante y 48MiB de memoria compartida.

Para esta sección se plantea la aplicación de dos filtros diferentes a una imagen. El formato de ésta última es en escala de grises y de una magnitud de 750x499 píxeles, pudiéndose considerar como una matriz de números enteros. Los filtros son matrices de 3 × 3 mostrados a continuación. El primero corresponde al filtro promedio y el segundo al filtro enfocado.

1

La matriz del filtro es aplicada utilizando la técnica de la convolución 2D. El código para aplicar el filtro promedio para cada píxel de la salida se muestra a continuación. Considere lo siguiente:

• La imagen de entrada se encuentra en el arreglo de una dimensión d_imagen_in (la posición de columna y fila debe calcularse para convertirla a una dimensión).
• FILTRO_RCOLS y FILTRO_RFILAS son las cantidades de columnas y filas que posee el filtro.
• d_filtro es un arreglo unidimensional con los valores del filtro a aplicar.

int k, l;
float aux = 0.0;
for(k=-1; k <= 1; k++) { // fila filtro
  for (l = -1; l <= 1; l++) {// col filtro
    int fx = FILTRO_RCOLS + l;
    int fy = FILTRO_RFILAS + k;
    aux += d_filtro[fx + fy * FILTRO_COLS] *
      d_imagen_in[(myCol+l) + (myRow+k) * X];
  }
 }

d_imagen_out[myCol + myRow * cols] = aux;

Para el filtro promedio, la aplicación de la matriz con valores 1 debe ser dividida por la cantidad de elementos que posee el filtro. Por ello, su implementación es similar a la anterior modificando la última línea del código por:

d_imagen_out[myCol + myRow * cols] = aux / TAM_FILTRO;

El filtro Sobel requiere de la aplicación de dos kernels de 3 × 3 sobre la imagen original generando las matrices G_x y G_y. Si suponemos que ∗ es la aplicación de la convolución, entonces las siguientes son las expresiones que se deben implementar.

2

En el archivo imagen.cu se encuentran las funciones necesarias para aplicar el filtro Sobel de forma secuencial y en sobel.cu se implementan las paralelas. La función kernel_aplicar_filtro aplica uno de los filtros para obtener G_x o G_y dependiendo del valor booleano del parámetro de entrada hor. Los filtros están dentro de un espacio de memoria constante referenciados por d_filtro_hor y d_filtro_ver. El siguiente código corresponde con ésta función. Obsérvese la similitud con la convolución de las secciones anteriores. Para que sea utilizable por la GPU, se paraleliza teniendo en cuenta que se desea obtener el resultado de un píxel de la salida por cada thread.

  __constant__ float d_filtro_hor[9];
  __constant__ float d_filtro_ver[9];

  __global__ void kernel_aplicar_filtro(float* d_imagen_in, float* d_imagen_out,
                                        bool hor, int filas, int cols){

    int icol = threadIdx.x + blockIdx.x * blockDim.x;
    int irow = threadIdx.y + blockIdx.y * blockDim.y;


    if ((icol < cols-1) && (irow < filas-1)
        && (icol > 0) && (irow > 0)){
      float aux = 0.0;

      // Aplicar el filtro al pixel [icol, irow]
      for (int k = -1; k <= 1; k++){ // filas
        for (int l = -1; l <= 1; l++){ // cols
          int fx = l + 1;
          int fy = k + 1;

          if (hor){
            aux += d_filtro_hor[fx + fy * 3] *
              d_imagen_in[(icol + l) + (irow + k) * cols];
          }else{
            aux += d_filtro_ver[fx + fy * 3] *
              d_imagen_in[(icol + l) + (irow + k) * cols];
          }

        }
      }

      d_imagen_out[icol + irow * cols] = aux;
    }
  }

El condicional para determinar si aplicar un filtro u otro depende del parámetro hor. Es recomendado por CUDA evitar las diferentes ejecuciones (ramificaciones o branch) dentro de un warp. Esto se debe a que la arquitectura de los procesadores gráficos consiste mayormente en Single Instruction Multiple Data (SIMD) lo cual consiste en ejecutar una instrucción sobre múltiple datos por unidad de tiempo. En este caso, el valor de hor es verdadero o falso en toda la ejecución del warp, evitando que algunos threads vayan por un branch haciendo necesario varios ciclos para ejecutar cada una de las ramificaciones. Esto puede ser corroborado al ver las métricas resultantes del comando nvprof. En el Cuadro tab:sobel_metrics muestra dicha métrica indicando un 100% de eficiencia en el kernel kernel_aplicar_filtro y 0 eventos de ramificaciones divergentes. En cuanto al kernel kernel_calcular_g, se obtiene una pequeña divergencia debido a que hay threads que no realizan los cálculos dentro del condicional. Estos threads son los sobrantes generadon por la configuración de la grilla y bloques.

Luego de obtener G_x y G_y, se requiere calcular la matriz . Ésta se logra por medio de la función kernel_calcular_g. La paralelización se realiza de la misma manera que los filtros: se calcula la formula indicada por cada píxel de salida en cada thread.

__global__ void kernel_calcular_g(float *d_g_x, float *d_g_y,
                                  float *d_imagen_out,
                                  int filas, int cols){
  int icol = threadIdx.x + blockIdx.x * blockDim.x;
  int irow = threadIdx.y + blockIdx.y * blockDim.y;

  if ((icol < cols-1) && (irow < filas-1)
      && (icol > 0) && (irow > 0)){

    int idx = icol + irow * cols;
    d_imagen_out[idx] = (float) sqrt
      (
       (float) powf(d_g_x[idx], 2)
       + (float) powf (d_g_y[idx], 2)
       );
  }
}

Finalmente, la función aplicar_filtro_sobel_par ejecuta todos estos kernels de forma ordenada. En el siguiente retazo de código se muestra las secciones más importantes: la inicialización del filtro en memoria host, la copia de los filtro a la memoria constante de la GPU, la reserva de espacio para los resultados de G_x y G_y, la disposición de la grilla y sus bloques y los llamados a los kernels para obtener los resultados.

  inicializar_filtro_sobel_horizontal(h_filtro_hor, 9);
  inicializar_filtro_sobel_vertical(h_filtro_ver, 9);

  cudaMemcpyToSymbol(d_filtro_hor, h_filtro_hor, sizeof(float) * 9);
  cudaMemcpyToSymbol(d_filtro_ver, h_filtro_ver, sizeof(float) * 9);

  float *d_g_x, *d_g_y;
  cudaMalloc((void **) &d_g_x, size_img);
  cudaMalloc((void **) &d_g_y, size_img);

  dim3 blocklayout(16, 16);
  dim3 gridlayout(cols /blocklayout.x + (cols  % blocklayout.x ? 1 : 0),
                  filas/blocklayout.y + (filas % blocklayout.y ? 1 : 0));


  kernel_aplicar_filtro<<<gridlayout, blocklayout>>>(d_imagen_in, d_g_x,
                                                 true, filas, cols);
  kernel_aplicar_filtro<<<gridlayout, blocklayout>>>(d_imagen_in, d_g_y,
                                                 false, filas, cols);
  kernel_calcular_g<<<gridlayout, blocklayout>>>(d_g_x, d_g_y, d_imagen_out,
                                             filas, cols);

Este informe describe los resultados de los distintos ejercicios propuestos en el curso. Se aprecia que a medida que se avanza con los ejercicios la utilización del GPU cobra más relevancia.

En los primeros ejercicios, la cantidad de operaciones a realizar por dato es muy poca, de forma que no compensa el traslado de la información a la GPU con la utilización de la misma. Este balance entre transferencia de datos y uso de GPU, a veces, no logra ser suficiente como para considerar utilizar CUDA.

Sin embargo, a partir de la utilización de la convolución, el traslado de memoria comienza a ser menos considerable comparado con el tiempo de procesamiento. La paralelización en el procesamiento de imágenes hace que la utilización de muchos threads resulte beneficiosa y reduzca tiempos de ejecución logrando una gran ventaja ante el CPU. Es por ello, que en estos últimos ejercicios se observa que CUDA logra un gran avance en cuanto a tiempos de ejecución: realizar un procesamiento que es paralelizable e independiente entre sí sobre grandes cantidades de datos.

Las resoluciones planteadas aquí fueron intentos iniciales para comprender el comportamiento de la GPU, ante variadas tareas. Aunque se pudo apreciar una idea preliminar de lo que sucede sobre cada experiencia, es necesario más pruebas para abarcar con más detalles y certeza las deducciones realizadas. Entonces, como posibles trabajos a considerar es el de realizar varias ejecuciones de un mismo experimento para aumentar la certeza, y evitar errores de medición, y sumar pruebas con parámetros y configuraciones más variados y con tamaños de datos más grandes.

Bibliography

• [cuda_deviceprop] @Misccuda_deviceprop, author = NVIDIA Corporation. All rights reserved., title = cudaDeviceProp Struct Reference, year = 2019, note = \urlhttps://docs.nvidia.com/cuda/cuda-runtime-api/structcudaDeviceProp.html#structcudaDeviceProp visitado el día 25 de abril del 2019 (captura en \urlhttp://archive.today/LrYUE)
• [geforce:titanx] @Miscgeforce:titanx, author = NVIDIA Corporation. All rights reserved., title = Especificación de GeForce GTX Titan X en GeForce.com, year = 2019, note = \urlhttps://www.geforce.com/hardware/desktop-gpus/geforce-gtx-titan-x/specifications visitado el día 25 de abril del 2019 (captura en \urlhttp://archive.today/4nMP0)
• [nvidia:titanx] @Miscnvidia:titanx, author = NVIDIA Corporation. All rights reserved., title = Especificación Técnica de GeForce GTX Titan X en nvidia.com, year = 2019, note = \urlhttps://www.nvidia.com/en-us/geforce/products/10series/titan-x-pascal/#specs visitado el día 25 de Abril del 2019 (captura en \urlhttp://archive.today/fhnh1)
• [nvidia:tesla] @Miscnvidia:tesla, author = NVIDIA Corporation. All rights reserved., title = Especificación Técnica de Tesla V100 en nvidia.com, year = 2019, note = \urlhttps://www.nvidia.com/en-us/data-center/tesla-v100/ visitado el día 25 de abril del 2019 (captura en \urlhttp://archive.today/pUhkz).
• [nvidia_gtx980] @Miscnvidia_gtx980, author = NVIDIA Corporation. All rights reserved., title = NVIDIA GeForce GTX 980 Whitepaper, year = 2014, note = URL original: \urlhttps://international.download.nvidia.com/geforce-com/international/pdfs/GeForce_GTX_980_Whitepaper_FINAL.PDF disponible en archive.org: \urlhttps://web.archive.org/web/20180329030403/https://international.download.nvidia.com/geforce-com/international/pdfs/GeForce_GTX_980_Whitepaper_FINAL.PDF
• [nvidia_fermi] @Miscnvidia_fermi, author = NVIDIA Corporation. All rights reserved., title = NVIDIA's Next Generation Cuda Compute Architecture: Fermi - Whitepaper, year = 2009, note = \urlhttps://www.nvidia.com/content/pdf/fermi_white_papers/nvidia_fermi_compute_architecture_whitepaper.pdf visitado el día 25 de abril del 2019.