Librerías Toma III

Ejemplo I: GPU-BLAST

BLAST (Alineación local de secuencias)

De acuerdo con la Web of Science, el trabajo que describe la primer versión de BLAST (Altschul et al. 1990) ha sido citado más de 28000 veces y el que describe la versión gapped del mismo ha sido citado

más de 25000 veces.

El nivel de uso de BLAST sugiere que cualquier mejora en su tiempo de ejecución, tendrá un significativo impacto en la bioinformática.

Smith-Waterman Muy lento (O(longitud²))

Se proponen soluciones heurísticas

No se garantiza hallar la mejor secuencia pero andan

bien!

BLAST (Basic LocalAlignment Search Tool)

BLAST : Pasos

SEEDING: busca coincidencias exactas de una pequeña longitud fija W (por defecto W=3) entre la secuencia de consulta y las secuencias de la base de datos (National Center for Biotechnology Information (NCBI) protein database ~ 38.500.000 secuencias).

EXTENSION: trata de extender la coincidencia en ambas direcciones, comenzando por la semilla. Si es encontrado un alineamiento sin huecos de alto puntaje, la base de datos de secuencias pasa a la tercera etapa.

EVALUATION: realiza un alineamiento con huecos entre la secuencia de consulta y la secuencia de la base de datos usando una variación del algoritmo de Smith-Waterman.

Los alineamientos relevantes estadísticamente son mostrados al usuario.

GPU-BLAST

Tiene la misma interfaz de usuario y produce los mismos resultados que NCBI-BLAST.

● 4 veces más rápido que NCBI-BLAST con 1 solo procesador● 2 veces más rápido que NCBI-BLAST con 6 procesadores

Independientemente del rendimiento alcanzado, lo interesante es cómo se realiza el cómputo en paralelo...

BLAST Profiling

Los pasos que mas tiempo levan son SEEDING y EXTENSION → altamente paralelizables

GPU!!!!

Implementación GPU-BLAST

Memoria Global: ● Comunica CPU y GPU.● La más grande y lenta (~5GB). ● Leída y escrita por CPU y por threads de GPU. ● El patrón de acceso a memoria por los threads

puede afectar el rendimiento (coalescencia, ancho de banda).

Memoria compartida: ● Pequeña (~50KB) y muy rápida (~GB/s).● Compartida por todos los threads de un bloque. ● Lectura/escritura por los threads. ● Comunica threads del mismo bloque. ● Afectada por el patrón de acceso de los threads (warps).

Registros: ● Cada thread utiliza su propio conjunto de registros.● El programador no tiene control.

Memoria local: ● Usada por el compilador alojar variables.

Memoria de textura: ● Controlada por el programador● Puede beneficiar aplicaciones con localidad espacial

donde el acceso a memoria global es un cuello de botella.

Las últimas dos no son usadas en el contexto de GPU-BLAST

● Memoria Constante:● Mucho mas chica (~64 KB).● CPU puede leer y escribir● Sólo de lectura para GPU threads.● Mayor ancho de banda.

Ordenado Inicial de secuencias (se hace una sola vez)

● Para evitar divergencia de threads se ordenan las secuencias por longitud (los threads del mismo warp realizan las tareas en aprox el mismo tiempo)

● El sorteo está embebido en el formato de FASTA requerido por NCBI-BLAST

Implementación GPU-BLAST (SEEDING)

La estructura de los datos → eficiencia y rendimiento de toda la aplicación

Base de datos (Subjets de distintostamaños) → mem global (~GB)(~4GB, 13 Multiproc/ 192 cores c/u,~2500 cores, placa K20)

Secuencia consulta (Query)→ mem global constante (~64KB)

Palabras semillas W (PLK,...) ~ 20 aminoácidos de interés

Cada Procesador (thread) toma un Subject y compara con W

Chequeo presencia/ausencia de Wen Query via vector en shared mem.

Matriz de sustitución BLOSUM (BLOcks SUbstitution Matrix) ~20x20

Shared memories son memorias rápidas (~GB/s) pero pequeñas (50KB) → acceso frecuente

Guardo posicion y ocurrencias enQuery index table (Memoria global)

Cada Multiproc toma una W

Implementación GPU-BLAST (EXTENSION)

Cada semilla se extiende hacia la derecha y hacia la izquierda según el “two-hit method”

Si el puntaje excede un “puntaje umbral” se guardan las coordenadas del par de Secuencias → memoria global (porque no se sabe cuantos pares tendremos)

CPU tiene una copia de la base de datos y va realizando parte de la tarea de alineación

La base de datos se divide entre GPU y CPU

Balance de carga y GPU y CPU ocupadas todo el tiempo

Uso GPU-BLAST:

Construida sobre NCBI-BLAST → comparten interfaz.

● Versión actual solo para alineamiento de proteínas.

● GPU-BLAST agrega las siguientes opciones:

-gpu <Boolean> Use GPU for blastp Default = ‘F’

-gpu_threads <Integer, 1...1024>

Number of GPU threads per block Default = ‘64’

-gpu_blocks <Integer, 1...65536>

Number of GPU block per grid Default = ‘512’

-method <Integer, 1...2>

1 = for GPU-based sequence alignment

2 = for GPU database creation Default = ‘1’

* Incompatible with: num_threads

-gpu F, all the previous options are ignored and

GPU- BLAST executes according to NCBI-BLAST

Uso NCBI- BLAST:

-num_threads <Integer>=1> number of CPU cores

in parallel with the GPU

Resultados:● Base de datos usada: env_nr con 6031291 secuencias (1.3GB). 51 queries de secuencias de ratones

con largos desde 2 a 4998 aminoácidos. Sacados de la base de datos UniProt

GPU-BLAS speedups relativos a CPU en funcion del largo de secuencia

● Speeup mayor que uno para todas las secuencias con longitud más de 2 para 1 CPU threads. ● Speedup mayor que uno para secuencias con longitud mayor de 500 para 6 CPU threads.● Speedup cercano a 4 para 1 CPU thread. ● GPU 1030 GFLOPS in single precision y 515 GFLOPS in double precision.● CPU 128 GFLOPS y 64 GFLOPS.● Speedups GPU-BLAST ~4 con respecto a NCBI-BLAST● Ya que usa CPU y GPU, GPU-BLAST se beneficiará en el futuro de los avances en ambas tecnologías.

Librerías

Ejemplo II: GPU-HMMER