librerías toma iii
TRANSCRIPT
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