Inferência de redes de regulação gênica usando algoritmo de busca ...

Universidade Federal do ABC

Curso de Pós-Graduação em Ciência da Computação

Dissertação de Mestrado

Fabrizio Ferreira Borelli

Inferência de redes de regulação gênica usando algoritmo

de busca exaustiva em clusters de GPUs

Durante o desenvolvimento deste trabalho o autor recebeu auxílio financeiro da UFABC eCAPES

Santo André

2014

Universidade Federal do ABC

Curso de Pós-Graduação em Ciência da Computação

Dissertação de Mestrado

Fabrizio Ferreira Borelli

Inferência de redes de regulação gênica usando algoritmo

de busca exaustiva em clusters de GPUs

Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Ciência da

Computação da Universidade Federal do ABC

para a obtenção do Título de Mestre em

Ciência da Computação, sob orientação do

Professor Doutor Luiz Carlos da Silva Rozante.

Durante o desenvolvimento deste trabalho o autor recebeu auxílio financeiro da UFABC eCAPES

Santo André

2014

iv

Este exemplar foi revisado e alterado em relação à versãooriginal, de acordo com as observações levantadas pelabanca no dia da defesa, sob responsabilidade única doautor e com a anuência de seu orientador.

Santo André, 17 de Abril de 2014.

Assinatura do autor:

Assinatura do orientador:

Dedicatória

Dedico este trabalho a Rosa Demitrov Borelli.

i

ii

You can’t connect the dots looking foward.You can only connect them looking backwards.

So you have to trust that the dots will somehow connect in your future.You have to trust in something: your gut, destiny, life, karma, whatever.

Because, believing that the dots will connect down the roadwill give you the confidence to follow your heart;

even when it leads you off the well-worn path.Steve Jobs

Resumo

Borelli, F. F. Inferência de redes de regulação gênica usando algoritmo de buscaexaustiva em clusters de GPUs.. 2013. 96 f. Dissertação (Mestrado) - Centro de Mate-mática, Computação e Cognição, Universidade Federal do ABC, 2013.

Introdução: Inferência de Redes de Regulação Gênica (do Inglês,Gene Regulatory Networks– GRNs) é um importante problema da bioinformática, com várias aplicações em biologiade sistemas, no qual tenta-se deduzir as interações entre genes a partir de dados de ex-pressão gênica, como por exemplo dados de microarray ou RNA-Seq. Métodos de seleçãode características podem ser aplicados neste problema. Um método de seleção de carac-terísticas é composto por duas partes: um algoritmo de busca e uma função critério. Nocontexto desse trabalho, tratamos de uma técnica já bem estabelecida na literatura parainferência de GRNs, baseada em seleção de características, e que usa busca exaustiva comoalgoritmo de busca e entropia condicional média como função critério. Busca exaustiva tema vantagem de sempre retornar o melhor subconjunto de características, mas é computaci-onalmente inviável na maioria das situações, o que torna soluções baseadas em computaçãode alto-desempenho atraentes; entretanto, plataformas de alto-desempenho tradicionais sãoainda caras e de difícil manutenção. O objetivo deste trabalho foi desenvolver uma soluçãoparalela de custo relativamente baixo — baseada na arquitetura GPU/CUDA — para buscaexaustiva aplicada ao problema de inferência de GRNs.

Resultados: Desenvolvemos alguns algoritmos paralelos para inferência de GRNs que fun-cionam em uma ou mais máquinas com múltiplas GPUs, as quais podem ser homogênease/ou heterogêneas. Realizamos dezenas de experimentos com tamanhos de rede variando de64 a 16384 genes e obtivemos speedups encorajadores, que situam-se na ordem dos milharespara os casos mais importantes. Resultados de experimentos usando um número crescentede GPUs mostram que o speedup cresce de forma quase linear à medida que cresce o númerode GPUs.

Conclusão: Neste trabalho apresentamos uma prova de princípio, mostrando que é possí-vel paralelizar o algoritmo busca exaustiva em GPUs com resultados encorajadores. Emborao foco deste trabalho tenha sido o problema da inferência de GRNs, a técnica de busca

iii

iv

exaustiva baseada em arquiteturas GPUs pode ser aplicada, com pequenas alterações, emoutros problemas combinatoriais.Keywords: Computação de Alto-Desempenho, GPU/CUDA, Inferência de Redes de Regu-lação Gênica, Entropia Condicional Média.

Abstract

Borelli, F. F. Gene regulatory networks inference using a GPU cluster exhaustivesearch algorithm . 2013. 96 f. Dissertação (Mestrado) - Centro de Matemática, Compu-tação e Cognição, Universidade Federal do ABC, São Paulo, 2013.

Background: Gene regulatory networks (GRN) inference is an important bioinformaticsproblem- with many applications in system biology - in which the gene interactions needto be deduced from gene expression data, such as microarray data or RNA-Seq. Featureselection methods can be applied to this problem. A feature selection technique is composedby two parts: a search algorithm and a criterion function. In the context of this project,we will address a technique already well established in the literature for inferring of GRNsbased on feature selection, and that uses exhaustive search as search algorithm and meanconditional entropy as criterion function. Exhaustive search has the advantage of alwaysreturn the best subset of features, but is computationally infeasible in most situations, whichmakes solutions based on high-performance computing attractive; however traditional high-performance platforms are still expensive and difficult to maintenance. The goal of this workis develop a parallel solution with relatively low cost - based on GPU/CUDA architecture- for exhaustive search. CUDATM is a general purpose parallel programming platform thatallows the usage of NVIDIAR© GPUs to solve complex problems in an efficient way andrelatively low cost.

Results: We developed some parallel algorithms for inferring GRNs running on one ormore machines with multiple GPUs, which can be homogeneous and / or heterogeneous. Weconducted dozens of experiments with network sizes ranging 64-16384 genes and obtainedencouraging speedups which are in the order of thousands of the most important cases.Results of experiments using an increasing number of GPUs show that the speedup growsalmost linearly as it grows the number of GPUs.

Conclusion: In this work, we present a proof of principle, showing that it is possible toparallelize the exhaustive search algorithm in GPUs with encouraging results. Although ourfocus in this paper is on the GRN inference problem, the exhaustive search technique based

v

vi

on GPU developed here can be applied (with minor adaptations) to other combinatorialproblems.Keywords: High-performance Computing, GPU, Inference of Gene Regulatory Networks,Mean Conditional Entropy.

Sumário

Lista de Abreviaturas xi

Lista de Símbolos xiii

Lista de Figuras xv

Lista de Tabelas xix

1 Introdução 11.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Limitações das Soluções Existentes . . . . . . . . . . . . . . . . . . . . . . . 21.3 Desenvolvimento de Solução Paralela de Baixo Custo . . . . . . . . . . . . . 31.4 Relevância dos Resultados e Impactos Esperados . . . . . . . . . . . . . . . . 31.5 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Inferência de Redes de Regulação Gênica (GRNs) 72.1 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Modelos de GRNs e Métodos de Inferência . . . . . . . . . . . . . . . . . . . 82.3 Inferência de GRNs por Cálculo Entropia Condicional Média . . . . . . . . . 8

2.3.1 Busca Exaustiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Arquitetura GPU/CUDA 15

4 Materiais e Métodos: Usando GPU/CUDA para Inferência de GRNs 234.1 Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Pré-Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Busca Exaustiva Local com Dois Preditores . . . . . . . . . . . . . . . . . . 244.4 Busca Exaustiva Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5 Algoritmo Multi-Amostra-Variável (MAV) . . . . . . . . . . . . . . . . . . . 274.6 Busca Exaustiva com Três Preditores . . . . . . . . . . . . . . . . . . . . . . 304.7 Algoritmo Multi-GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.8 Algoritmo Multi-GPUs-Máquinas (MGM) . . . . . . . . . . . . . . . . . . . 33

vii

viii SUMÁRIO

4.9 Algumas Considerações sobre Complexidade . . . . . . . . . . . . . . . . . . 384.10 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.10.1 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.10.2 GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Experimentos e Resultados 435.1 Supondo Dois Preditores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.1 Experimento em CPU Multi-Thread . . . . . . . . . . . . . . . . . . 445.1.2 Experimentos com Algoritmo Multi-Amostra-Constante (MAC) . . . 455.1.3 Experimentos com Algoritmo Multi-Amostra-Variável (MAV) . . . . 475.1.4 Experimentos com Algoritmo Multi-GPUs-Máquinas (MGM) . . . . . 485.1.5 Speedups obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.1.6 Comparação entre os Algoritmos MAC, MAV e MGM . . . . . . . . . 56

5.2 Supondo Três Preditores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2.1 Experimentos com Multi-Amostra-Variável (MAV) . . . . . . . . . . 575.2.2 Experimentos com Multi-GPUs-Máquinas (MGM) . . . . . . . . . . . 59

5.3 Detalhes de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.4 Desafios de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Conclusões 636.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 Sugestões para Pesquisas Futuras . . . . . . . . . . . . . . . . . . . . . . . . 64

Referências Bibliográficas 65

Índice Remissivo 70

Lista de Abreviaturas

API Application Program InterfaceCPT Tabela de Probabilidades Condicionais (Conditional Probability Table)GPU Unidade de Processamento Gráfico (Graphics Processing Unit)GRN Redes de Regulação Gênicas (Gene Regulatory Network)ICMP Internet Control Message ProtocolMAC Algoritmo Multi-Amostras ConstanteMAV Algoritmo Multi-Amostras VariávelMCE Entropia Condicional Média (Mean Conditional Entropy)MGM Algoritmo Multi-GPU MáquinasMPI Message Passing InterfaceSM Stream MultiProcessor

ix

x LISTA DE ABREVIATURAS

Lista de Símbolos

E Matriz de Expressão GênicaT Matriz de Expressão Gênica dos Genes AlvosP Matriz de Expressão Gênica dos Genes PreditoresG Conjunto de GenesA Conjunto de Amostrasth Número de threads por blocotg Número de Genes Alvos por Blocol Número de amostrassh Número de genes preditores na memória compartilhadaM Modelo que representa as interações de G

xi

xii LISTA DE SÍMBOLOS

Lista de Figuras

3.1 Comparação entre a largura de banda de memória e o número de operações deponto flutuante por segundo em GPUs e CPUs. Em ambos os gráficos, a linhaverde representa a GPU e a linha azul, a CPU. Figura obtida de Nvidia1 (2013). 16

3.2 A plataforma CUDA. a) Arquitetura de uma GPU moderna, possuindo umagrande quantidade de memória global e um conjunto de multiprocessadores,cada um com um conjunto de processadores de ponto flutuante, uma pequenamemória compartilhada e um grande número de registradores. b) Organiza-ção hierárquica das threads nos blocos de execução e em grids, na qual cadabloco de execução é associado a um único multiprocessador. Figura obtida dede Camargo et al. (2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Comparativo entre as arquiteturas CPU e GPU. Figura obtida de Nvidia1(2013). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Opções de estrutura de dados para modelar problemas em GPU. Da esquerdapara a direita, a primeira opção é um vetor de estruturas e a segunda, umaestrutura de vetores. A segundo opção é mais adequada a GPU, pois pode-seaproveitar a coalescência. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 a) Exemplo de uma matriz de expressão gênica com 7 amostras e 4 genes.T e P são cópias desta matriz. b) Avaliação da entropia condicional médiabaseada nas probabilidades condicionais de um gene alvo dado dois preditores. 24

4.2 Particionando as matrizes T e P em k segmentos e regra de acesso dos blocosaos segmentos T : uma flecha Ti → Bli indica que o blocoBli acessa o segmentoTi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Regra de acesso dos blocos de execução aos segmentos. Uma flecha Pi → Blj

indica que o bloco Blj acessa o segmento Pi. Flechas com a mesma cor indicaque os acessos são executados de forma simultânea. . . . . . . . . . . . . . . 26

4.4 Figura ilustrando a estrutura bidimensional tablete. Esta estrutura consisteem uma submatriz: para a matriz P , tablete é um segmento de genes detamanho n/2k e um agrupamento de amostras de tamanho sh; para a matrizT , tablete é um segmento de genes de tamanho n/k e um agrupamento deamostras de tamanho sh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

xiii

xiv LISTA DE FIGURAS

4.5 Regra de acesso dos blocos de execução aos tablete. Uma flecha Pj → Bli

indica que o bloco Bli acessa o tablete Pj. Uma flecha Ti → Bli indica que obloco Bli acessa o tablete Ti. Flechas com a mesma cor indicam que os acessossão executados de forma simultânea. Enquanto Pj é copiado para todos osblocos, Ti é copiado apenas para o bloco Bli. O primeiro passo é copiar ostabletes Pj1,0, Pj2,0, Ti,0 (cor preta) da memória global da GPU para a memóriacompartilhada. Num segundo passo, os tabletes Pj1,1, Pj2,1, Ti,1 (cor verde)são copiados para a memória compartilhada e assim sucessivamente até queos tabletes Pj1,l/sh−1, Pj2,l/sh−1, Ti,l/sh−1 (cor vermelha) sejam copiados para amemória compartilhada. Após a cópia de todos os tabletes é que podemoscalcular a entropia para os genes alvos de Ti. . . . . . . . . . . . . . . . . . . 30

4.6 Algoritmo Multi-GPU: uma flecha T i → Ci indica que o supersegmento T i écopiado para a memória global da GPU Ci; T i

j denota o segmento j perten-cente ao supersegmento i; Blij denota o bloco de execução Blj que começouCi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.7 Exemplos de configuração de cluster : em a), à esquerda, um exemplo da con-figuração típica, onde a máquina M0 executa o processo mestre e um processoescravo; em b), à direita, um exemplo da configuração onde a máquina M0

executa apenas o processo mestre (nessa configuração supomos que M0 nãopossui GPUs disponíveis). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1 Explicação do cálculo do valor de u. Em a), os SMs podem processar apenasum bloco no mesmo espaço de tempo. Em b), os SMs primeiramente pro-cessam os blocos em vermelho para somente depois executar os blocos emazul. Lembrando que a ordem de execução é determinada pelo escalonadorda GPU. A ordem de execução dos blocos desta figura é apenas um exemplodidático. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 (a), (b) e (c): gráfico mostrando speedup versus tamanho da GRN para 32,64 e 128 genes alvos por bloco. Os termos “BIN” e “TER” indicam amostrasbinárias e ternárias, respectivamente. O termo Tg/Bl indica o número degenes alvos por bloco. Figura obtida de Borelli et al. (2013). . . . . . . . . . 52

5.3 Curvas representando os tempos de execução em função do número de amos-tras, na qual cada curva corresponde ao número de alvos por bloco (32, 64 e128). Neste caso, 4 GPUs são empregadas para inferir a rede de 4096 genes.Os termos “BIN” e “TER” indicam amostras binárias e ternárias, respecti-vamente. O termo Tg/Bl indica o número de genes alvos por bloco. Figuraobtida de Borelli et al. (2013). . . . . . . . . . . . . . . . . . . . . . . . . . 53

LISTA DE FIGURAS xv

5.4 Gráfico mostrando speedup versus quantidade de amostras para GRNs com2048, 4096, 8192 e 16384 genes com experimentos utilizando amostras bináriase ternárias ao aplicar o Algoritmo MAV. O termo “BIN” indica amostrasbinárias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.5 Gráfico mostrando speedup versus quantidade de amostras para GRNs com2048, 4096, 8192 e 16384 genes com experimentos utilizando amostras bináriase ternárias ao aplicar o Algoritmo MAV. O termo “TER” indica amostrasternárias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.6 Gráfico mostrando speedup versus quantidade de amostras para GRNs com2048, 4096, 8192 e 16384 genes com experimentos utilizando amostras bináriasusando o Algoritmo MGM. Utilizamos 2 placas gráficas GTX 680 e 4 placasgráficas GTX 295. Os termos “BIN” e “TER” indicam amostras binárias eternárias, respectivamente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.7 Gráfico mostrando speedup versus quantidade de amostras para GRNs com2048, 4096, 8192 e 16384 genes com experimentos utilizando amostras bináriasusando o Algoritmo MGM. Utilizamos 4 placas gráficas GTX 680, distribuídasem 2 computadores. Os termos “BIN” e “TER” indicam amostras binárias eternárias, respectivamente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

xvi LISTA DE FIGURAS

Lista de Tabelas

2.1 Um exemplo de entrada para o método contendo dados temporais (quantiza-dos para valores binários) de expressão gênica de 4 genes e 7 amostras. . . . 10

2.2 Dados parciais obtidos da tabela de entrada (Tabela 2.1), para facilitar oentendimento do exemplo, focando na avaliação da capacidade do par (Gene0, Gene 1) predizer o Gene 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Tabela de Probabilidades Condicionais para o caso do par (Gene 0,Gene 1) opredizer Gene 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Tabela de Probabilidades Condicionais junto com a entropia para cada casopossível que o Gene 0 e o Gene 1 pode assumir. . . . . . . . . . . . . . . . . 12

5.1 Tempo de execução para amostras binárias utilizando o Algoritmo SerialMulti-Thread. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). As linhas e colu-nas em negrito indicam os tempos de execução feitos em CPU com 4 coresutilizando amostras binárias. O restante dos dados foram estimados usandoregressão linear para as amostras e uma linha de tendência com polinômio degrau 3 para o tamanho das GRNs. A primeira linha de cima para baixo indicaa quantidade de amostras nos experimentos. . . . . . . . . . . . . . . . . . . 45

5.2 Experimento 1. Tempo de execução para amostras binárias usando 1 GPUGTX 295 com a cardinalidade do subconjunto X igual a 2 e utilizando oAlgoritmo MAC. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). A segunda colunada esquerda para a direita apresenta os tempos de execução do algoritmo paraa CPU com 6 cores. As outras colunas apresentam os tempos de execução comtrês experimentos: 32, 64 e 128 genes alvos por bloco. . . . . . . . . . . . . . 46

xvii

xviii LISTA DE TABELAS

5.3 Experimento 2. Tempo de execução para amostras binárias usando 2 GPUsGTX 295 com a cardinalidade do subconjunto X igual a 2 e utilizando oAlgoritmo MAC. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). A segunda colunada esquerda para a direita apresenta os tempos de execução do algoritmo paraa CPU com 6 cores. As outras colunas apresentam os tempos de execução comtrês experimentos: 32, 64 e 128 genes alvos por bloco. . . . . . . . . . . . . . 46

5.4 Experimento 3. Tempo de execução para amostras binárias usando 4 GPUsGTX 295 com a cardinalidade do subconjunto X igual a 2 e utilizando oAlgoritmo MAC. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). A segunda colunada esquerda para a direita apresenta os tempos de execução do algoritmo paraa CPU com 6 cores. As outras colunas apresentam os tempos de execução comtrês experimentos: 32, 64 e 128 genes alvos por bloco. . . . . . . . . . . . . . 46

5.5 Experimento 4. Tempo de execução para amostras ternárias usando 1 GPUGTX 295 com a cardinalidade do subconjunto X igual a 2 e utilizando oAlgoritmo MAC. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). A segunda colunada esquerda para a direita apresenta os tempos de execução do algoritmo paraa CPU com 6 cores. As outras colunas apresentam os tempos de execução comtrês experimentos: 32, 64 e 128 genes alvos por bloco. . . . . . . . . . . . . . 47

5.6 Experimento 5. Tempo de execução para amostras ternárias usando 2 GPUsGTX 295 com a cardinalidade do subconjunto X igual a 2 e utilizando oAlgoritmo MAC. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). A segunda colunada esquerda para a direita apresenta os tempos de execução do algoritmo paraa CPU com 6 cores. As outras colunas apresentam os tempos de execução comtrês experimentos: 32, 64 e 128 genes alvos por bloco. . . . . . . . . . . . . . 47

5.7 Experimento 6.Tempo de execução para amostras ternárias usando 4 GPUsGTX 295 com a cardinalidade do subconjunto X igual a 2 e utilizando oAlgoritmo MAC. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). A segunda colunada esquerda para a direita apresenta os tempos de execução do algoritmo paraa CPU com 6 cores. As outras colunas apresentam os tempos de execução comtrês experimentos: 32, 64 e 128 genes alvos por bloco. . . . . . . . . . . . . . 47

LISTA DE TABELAS xix

5.8 Experimento 7. Tempo de execução para amostras binárias usando 2 GPUsGTX 680 com a cardinalidade do subconjunto X igual a 2 e utilizando oAlgoritmo MAV. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). As outras colunasapresentam os tempos de execução com apenas um experimento: 32, 64, 128,256, 512 e 1024 amostras e 2048, 4096, 8192 e 16384 genes. A quantidade degenes alvos por bloco é igual a 8. . . . . . . . . . . . . . . . . . . . . . . . . 48

5.9 Experimento 8. Tempo de execução para amostras ternárias usando 2 GPUsGTX 680 com a cardinalidade do subconjunto X igual a 2 e utilizando oAlgoritmo MAV. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). As outras colunasapresentam os tempos de execução com apenas um experimento: 32, 64, 128,256, 512 e 1024 amostras e 2048, 4096, 8192 e 16384 genes. A quantidade degenes alvos por bloco é igual a 8. . . . . . . . . . . . . . . . . . . . . . . . . 48

5.10 Experimento 9. Tempo de execução para amostras binárias usando 2 GPUsGTX 680 e 4 GPUs GTX 295 com a cardinalidade do subconjunto X igual a2 e utilizando o Algoritmo MGM. A coluna mais a esquerda indica os diferen-tes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).As outras colunas apresentam os tempos de execução com apenas um expe-rimento: 32, 64, 128, 256, 512 e 1024 amostras e 2048, 4096, 8192 e 16384genes. A quantidade de genes alvos por bloco é igual a 8. . . . . . . . . . . . 49

5.11 Experimento 10. Tempo de execução para amostras ternárias usando 2 GPUsGTX 680 e 4 GPUs GTX 295 com a cardinalidade do subconjunto X igual a2 e utilizando o Algoritmo MGM. A coluna mais a esquerda indica os diferen-tes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).As outras colunas apresentam os tempos de execução com apenas um expe-rimento: 32, 64, 128, 256, 512 e 1024 amostras e 2048, 4096, 8192 e 16384genes. A quantidade de genes alvos por bloco é igual a 4. . . . . . . . . . . . 49

5.12 Experimento 11. Tempo de execução para amostras binárias usando 4 GPUsGTX 680 distribuídas igualmente entre 2 computadores com a cardinalidadedo subconjunto X igual a 2 e utilizando o Algoritmo MGM. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-sea quantidade de genes). As outras colunas apresentam os tempos de execuçãocom apenas um experimento: 32, 64, 128, 256, 512 e 1024 amostras e 2048,4096, 8192 e 16384 genes. A quantidade de genes alvos por bloco é igual a 8. 50

xx LISTA DE TABELAS

5.13 Experimento 12. Tempo de execução para amostras ternárias usando 4 GPUsGTX 680 distribuídas igualmente entre 2 computadores com a cardinalidadedo subconjunto X igual a 2 e utilizando o Algoritmo MGM. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-sea quantidade de genes). As outras colunas apresentam os tempos de execuçãocom apenas um experimento: 32, 64, 128, 256, 512 e 1024 amostras e 2048,4096, 8192 e 16384 genes. A quantidade de genes alvos por bloco é igual a 8. 50

5.14 Número ideal de blocos executados no mesmo espaço de tempo para o algo-ritmo MGM ao terminar o experimento independente do tamanho da GRN eda quantidade de amostras para a cardinalidade do subconjunto X igual a 2. 50

5.15 Experimento 13. Tempo de execução para amostras binárias usando 2 GPUsGTX 680 com a cardinalidade do subconjunto X igual a 3 e utilizando oAlgoritmo MAV. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). As outras colunasapresentam os tempos de execução com apenas um experimento: 36, 72, 108,360, 720 amostras e 360, 720, 2160. A quantidade de genes alvos por bloco éigual a 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.16 Experimento 14. Tempo de execução para amostras ternárias usando 2 GPUsGTX 680 com a cardinalidade do subconjunto X igual a 3 e utilizando oAlgoritmo MAV. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). As outras colunasapresentam os tempos de execução com apenas um experimento: 36, 72, 108,360, 720 amostras e 360, 720, 2160. A quantidade de genes alvos por bloco éigual a 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.17 Experimento 15. Tempo de execução para amostras binárias usando 2 GPUsGTX 680 e 4 GPUs GTX 295 com a cardinalidade do subconjunto X igual a3 e utilizando o Algoritmo MGM. A coluna mais a esquerda indica os diferen-tes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).As outras colunas apresentam os tempos de execução com apenas um experi-mento: 36, 72, 108, 360, 720 amostras e 360, 720, 2160. A quantidade de genesalvos por bloco é igual a 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.18 Experimento 16. Tempo de execução para amostras ternárias usando 4 GPUsGTX 680 distribuídas igualmente entre 2 computadores com a cardinalidadedo subconjunto X igual a 3 e utilizando o Algoritmo MGM. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-sea quantidade de genes). As outras colunas apresentam os tempos de execuçãocom apenas um experimento: 36, 72, 108, 360, 720 amostras e 360, 720, 2160.A quantidade de genes alvos por bloco é igual a 6. . . . . . . . . . . . . . . . 60

LISTA DE TABELAS xxi

5.19 Experimento 17. Tempo de execução para amostras binárias usando 4 GPUsGTX 680 distribuídas igualmente entre 2 computadores com a cardinalidadedo subconjunto X igual a 3 e utilizando o Algoritmo MGM. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-sea quantidade de genes). As outras colunas apresentam os tempos de execuçãocom apenas um experimento: 36, 72, 108, 360, 720 amostras e 360, 720, 2160.A quantidade de genes alvos por bloco é igual a 9. . . . . . . . . . . . . . . . 60

5.20 Número ideal de blocos executados no mesmo espaço de tempo para o algo-ritmo MGM ao terminar o experimento independente do tamanho da GRN eda quantidade de amostras para a cardinalidade do subconjunto X igual a 3. 60

xxii LISTA DE TABELAS

Capítulo 1

Introdução

Os mecanismos de regulação gênica são sistemas complexos formados por sinais queatuam em momentos específicos e controlam as atividades celulares, principalmente pormeio de sua ação moduladora dos padrões de expressão gênica (Maniatis e Reed, 2002). Onível de expressão de todos os genes são indiretamente refletidos nas concentrações corres-pondentes de mRNA. Tais concentrações podem indicar o estado biológico da célula, uma vezque elas representam, em princípio, todas as proteínas que são sintetizadas por ribossomos(Alberts et al., 2002).

Assim, é possível estudar os processos biológicos em um organismo através da medi-ção e análise das concentrações de mRNA (níveis de expressão) dos genes existente nascélulas. Existem várias técnicas experimentais que permitem medir o nível de expressãode milhares de genes simultaneamente, tais como SAGE (Serial Analysis of Gene Expres-sion)(Velculescu et al., 1995), DNAmicroarrays (Derisi et al., 1996) e RNA-Seq (Wang et al., 2009).

Estas técnicas, chamadas de grande escala, estão fornecendo uma enorme quantidadede dados de transcriptoma, o que implica na necessidade de desenvolver rápidas e precisasferramentas computacionais para processamento e análise desses dados. Neste contexto, in-ferência de redes de regulação gênicas (do inglês, Gene Regulatory Networks - GRNs) éum importante problema no qual o objetivo é inferir as interações/relações entre genes apartir de dados de expressão gênica. Vários métodos de inferência de GRNs têm sido pro-postos, alguns baseados em Redes Bayesianas (Chen et al., 2006; Friedman et al., 2000), oREVEAL (REVerse Engineering ALgorithm) (Liang et al., 1998), ARACNE (Algorithm forthe Reconstruction of Accurate Cellular NEtworks) (Margolin et al., 2006), CLR (ContextLikelihood of Relatedness) (Faith et al., 2007) e SFFF-MCE (Sequential Floating ForwardSelection - Mean Conditional Entropy) (Barrera et al., 2007; Lopes et al., 2008, 2009). A li-teratura relacionada à modelagem e inferência de GRNs é enorme e cresce rapidamente, o quereflete a importância deste campo de pesquisa. O leitor pode ser encaminhado para textosde revisões (de Jong, 2002; D’haeseleer et al., 2000; Hecker et al., 2009; Karlebach e Shamir,2008; Schlitt e Brazma, 2007; Styczynski e Stephanopoulos, 2005) sobre este tópico.

1

2 INTRODUÇÃO 1.2

Embora haja uma grande quantidade de dados disponíveis e vários métodos de inferênciade GRNs já desenvolvidos, desafios ainda permanecem, tais como a maldição da dimensi-onalidade (número de genes/variáveis para é muito maior do que o número de amostrasdisponíveis), o ruído presente nos dados reais e o custo computacional. Como na prática édesejável inferir GRNs com milhares de genes, a utilização de soluções baseadas em compu-tação de alto desempenho torna-se uma alternativa interessante. Infelizmente, plataformastradicionais de alto desempenho são geralmente caras e difíceis de manter.

O uso de GPUs (Graphics Processing Units) para computação de uso geral (GPGPU) éuma tecnologia emergente que permite realizar computação de alto desempenho com custorelativamente baixo (Che et al., 2008; Owens et al., 2008). CUDA (Compute Unified DeviceArchitecture) é um ambiente de programação que fornece um modelo paralelo de programa-ção que permite que a arquitetura de GPUs da NVIDIAR© execute eficientemente computaçãode propósito geral e a custo relativamente barato. A aplicação de GPUs para resolver o pro-blema de inferência de GRNs ainda é uma técnica muito recente. Shi et al. (2011) propuse-ram um esquema de paralelização para inferência de GRNs com base em um framework dateoria da informação que envolve multiplicação de matrizes, o que otimiza alguns benefíciosobtidos através da aplicação de GPUs. Entretanto, este método resulta em uma aproximaçãoque considera apenas as relações entre pares de genes, sem levar em consideração a naturezamultivariada de um certo preditor relacionados a seus genes alvo.

Este trabalho mostra vários algoritmos eficientes de busca exaustiva baseado em GPUe que utiliza entropia condicional média como função critério para a inferência de GRNscom predição multivariada com dois ou três genes preditores por gene alvo, e que pode serexecutado em múltiplas GPUs e em várias máquinas. A abordagem das redes gênicas doalgoritmo proposto é baseado em redes gênicas probabilísticas (Barrera et al., 2007), quemostrou resultados interessantes para obter o melhor subconjunto de genes preditores paracada gene alvo considerado.

1.1 Objetivos

1.2 Limitações das Soluções Existentes

Técnicas experimentais que permitem medir o nível de expressão de milhares de genesestão fornecendo uma enorme quantidade de dados de transcriptoma, o que implica na ne-cessidade de desenvolver rápidas e precisas ferramentas computacionais para processamentoe análise desses dados.

Os métodos de inferência em geral são aplicações que normalmente requerem um grandepoder computacional, o que dificulta a disseminação e o uso intensivo desses modelos poragentes públicos (universidades por exemplo) com limitações orçamentárias, visto o signifi-cativo custo de aquisição e manutenção de parques computacionais de alto-desempenho.

1.4 DESENVOLVIMENTO DE SOLUÇÃO PARALELA DE BAIXO CUSTO 3

Em um país com recursos limitados como o Brasil, é imprescindível o uso de técnicas quepermitam aos cientistas desenvolverem suas pesquisas utilizando menos recursos. O uso dasarquitetura GPU adotado neste projeto para realizar processamento paralelo segue nestadireção, pois o seu custo relativo é significativamente menor do que arquiteturas tradicionaisde alto-desempenho.

1.3 Desenvolvimento de Solução Paralela de Baixo Custo

O objetivo deste trabalho foi desenvolver um solução paralela para a inferência de GRNsvoltada para a arquitetura GPU/CUDA. Essa solução baseou-se em técnicas de seleção decaracterísticas, sendo que para isso usamos como algoritmo de busca o Busca Exaustiva ecomo função critério a entropia condicional média.

Em Borelli et al. (2012) desenvolvemos uma solução com essas características, masrelativamente restritiva: permitindo apenas dois genes preditores por gene alvo, operandoapenas com quantização binária de dados e tratando com um número limitado (trinta) deamostras.

Aqui o objetivo foi estender essa solução de modo a eliminar essas restrições, isto é, demodo a permitir mais do que dois genes preditores por gene alvo, operar com diferentesníveis (multi-nível) de quantização dos dados e com um número não limitado de amostras.Além disso, avançamos de modo a permitir que o algoritmo possa executar em múltiplasGPUs e em múltiplas máquinas (homogêneas e/ou heterogêneas).

1.4 Relevância dos Resultados e Impactos Esperados

A literatura relacionada à modelagem e inferência de GRNs é enorme e cresce muito rá-pida e vigorosamente há vários anos, o que reflete a importância deste campo de pesquisa. Hámuitas aplicações de interesse médico, que vão desde o diagnóstico e tratamento de psicopa-tias (Bearden et al., 2001; Lisman et al., 2009; Rolls et al., 2008), até o melhor entendimentoda biologia do câncer (DeBerardinis et al., 2008). Pesquisadores necessitam de ferramentascomputacionais para modelar e simular comportamentos capturados de experimentos reais.Um exemplo é inferir a relação entre os genes de diferentes tipos de doenças a partir dedados de microarray. Eventuais semelhanças e/ou diferenças estruturais identificadas nasredes de interação gênica de tipos patológicos podem ser de fundamental importância parauma melhor caracterização dessas patologias, enriquecendo o conhecimento de suas origensbiológicas em níveis moleculares e melhorando as suas classificações, bem como ajudandono desenvolvimento de diagnósticos. Outros tipos de dados estão se tornando cada vez maisdisponíveis, como por exemplo, dados de interação proteína-proteína (proteomics) e de pro-cessos químicos envolvendo metabólitos (metabolomics).

Como na prática é desejável inferir GRNs com milhares de genes, a utilização de soluções

4 INTRODUÇÃO 1.6

baseadas em computação de alto desempenho torna-se uma alternativa interessante. Infe-lizmente, plataformas tradicionais de alto desempenho são geralmente caras e difíceis de semanter, daí a importância do desenvolvimento e aplicação de plataformas alternativas comoGPU/CUDA.

Além disso, o desenvolvimento de um algoritmo de Busca Exaustiva, que seja capaz deexecutar num contexto de múltiplas máquinas com múltiplas GPUs, exigirá o desenvolvi-mento de técnicas – em especial no que diz respeito a estratégias para gerência do tráfegoentre as memórias local e global dos dispositivos – que poderão ser utilizadas em outrosproblemas combinatórios, com uma vasta gama de aplicações.

1.5 Contribuições

As principais contribuições deste trabalho são:

• Item 1. Elaboração, implementação e documentação de um conjunto de algoritmospara o problema da busca exaustiva aplicado ao problema da Inferência de GRNsbaseado em clusters de GPU, junto com sua análise de complexidade.

• Item 2. A elaboração de uma estratégia de distribuição de tarefas entre um conjuntode processos escravos para a busca exaustiva em GPU.

• Item 3. Execução de diversos experimentos da estratégia de distribuição de cargas emGPUs homogêneas/heterogêneas para a busca exaustiva com o propósito de avaliar emostrar a escalabilidade dos algoritmos propostos.

• Item 4. Publicação científica em congresso internacional: F. F. Borelli, R. Y. Camargo,D. C. Martins-Jr, B. Stransky e L. C. S. Rozante. Accelerating gene regulatory networksinference through gpu/cuda programming. In 2nd IEEE International Conference onComputational Advances in Bio and Medical Sciences (ICCABS), Las Vegas, NV, 2012.

• Item 5. Publicação científica em revista internacional: F. F. Borelli, R. Y. Camargo,D. C. Martins-Jr e L. C. S. Rozante. Gene regulatory networks inference using a multi-GPU exhaustive search algorithm. BMC Bioinformatics, 2013. DOI 10.1186/1471-2105-14-S18-S5.

1.6 Organização do Trabalho

O restante deste trabalho está organizado da seguinte forma:

• Capítulo 2. Neste capítulo fazemos uma caracterização do problema. Há uma pequenafundamentação teórica para o entendimento do trabalho.

1.6 ORGANIZAÇÃO DO TRABALHO 5

• Capítulo 3. Neste capítulo há uma descrição da arquitetura GPU, com a qual traba-lhamos. Há um pequeno comparativo entre GPUs e CPUs, o qual mostra a diferençaentre estes hardwares.

• Capítulo 4. Neste capítulo e em suas seções apresentamos as bases metodológicas queusamos no desenvolvimento do projeto. Começamos com a descrição de um algoritmode busca exaustiva que procura o melhor par de preditores com quantização multi-níveis que funciona com até 30 amostras. Estendemos este algoritmo para que funcionecom um número maior de amostras. Também descrevemos a busca exaustiva paraprocurar triplas de preditores para funcionar com um número não fixo de amostras.Propusemos também um algoritmo que funciona em múltiplas máquinas com GPUsheterogêneas/homogêneas sem conhecê-las a priori.

• Capítulo 5. Aqui discutimos os resultados do trabalho. Analisamos as vantagens edesvantagens dos algoritmos propostos no Capítulo 4. Apresentamos uma análise decomplexidade dos algoritmos propostos.

• Capítulo 6. Neste capítulo descrevemos a conclusão obtida do trabalho. Também háalgumas ideias sobre possíveis trabalhos futuros.

6 INTRODUÇÃO 1.6

Capítulo 2

Inferência de Redes de Regulação Gênica(GRNs)

Dado um conjunto de dados de níveis de expressão gênica, um importante e atual pro-blema da bioinformática é a inferência da GRN que explica esses dados. Esse problema étambém conhecido na literatura por “engenharia reversa” . O objetivo de um métodode engenharia reversa é construir de forma automática ou semi-automática um modelo queexplica os dados, sem hipótese a priori sobre o sistema biológico em questão (GRN).

2.1 Definição do Problema

Seja G um conjunto de n genes, denotados por g0, g1, . . . gn−1, e A um conjunto del amostras, denotadas por a0, a1, . . . al−1, as quais são obtidas a partir de uma sequênciatemporal (instantes t0, t1, . . . tl−1) de experimentos. Representamos a entrada do problema,constituída por l amostras de valores de expressão para cada um dos n genes, por umamatriz E, denominada matriz de expressão. A entrada ei,j da matriz E denota o nível deexpressão observado na amostra ai, obtida no instante de tempo ti, 0 ≤ i ≤ l−1 para o genegj, 0 ≤ j ≤ n− 1. Os níveis de expressão ei,j podem assumir valores discretos ou contínuos.

O problema consiste em: dada uma matriz de expressão E, queremos descobrir um modeloM que representa as interações entre os genes de G e que melhor explicam os dados de A.No contexto desse projeto, o modelo M é um grafo dirigido (G,R), sendo que os vérticesde G correspondem univocamente aos genes e as arestas de R representam as interaçõesentre eles, as quais são definidas em termos da relação (gene preditor, gene alvo), isto é,uma aresta dirigida (gi, gj) ∈ R representa o fato de que o gene gi exerce poder preditivosobre o gene gj. Um gene preditor é um gene cujo perfil de expressão possui informaçãosignificante (sozinho ou junto com outros genes preditores) sobre o perfil de expressão deum gene alvo. Usaremos uma técnica de reconhecimento de padrões conhecida como seleçãode características para construir este modelo.

7

8 INFERÊNCIA DE REDES DE REGULAÇÃO GÊNICA (GRNS) 2.3

2.2 Modelos de GRNs e Métodos de Inferência

Embora, como afirmado anteriormente, estejamos aqui interessados em modelar as GRNsinferidas como grafos, é importante observar que existem muitos outros tipos de modelospara GRNs, como por exemplo Redes Booleanas (Kauffman, 1969), Equações Diferenciais(Chen et al., 1999), Redes Bayesianas (Friedman et al., 2000) e as Redes Gênicas Probabi-lísticas (Barrera et al., 2007). Para maiores informações sobre classes de modelos para GRNssugerimos os artigos de revisão de Jong (2002) e Schlitt e Brazma (2007).

Os métodos de inferência de GRNs dependem muito das técnicas utilizadas para amodelagem das GRNs e muitos deles já foram propostos, como por exemplo o REVEAL(REVerse Engineering ALgorithm) (Kelemen et al., 2008; Liang et al., 1998), o ARACNE(Algorithm for the Reconstruction of Accurate Cellular NEtworks) (Butte e Kohane, 2000;Margolin et al., 2006) , o CLR (Context Likelihood of Relatedness) (Faith et al., 2007) , oMRNET (Meyer et al., 2007) e o SFFS-MCE (Sequential Forward Floating Selection - MeanConditional Entropy) (Barrera et al., 2007; Lopes, 2011).

Não é nosso propósito fazer aqui uma revisão dos métodos de inferência. Para maioresdetalhes sobre métodos de inferência de GRNs existentes, há vários artigos de revisão dispo-níveis como os de Hecker et al. (2009), de Bansal et al. (2007) e de Markowetz e Spang(2007).

Na próxima seção iremos descrever a inferência de GRNs utilizando entropia condicionalmédia, que é o foco desse trabalho.

2.3 Inferência de GRNs por Cálculo Entropia Condicio-

nal Média

Como mencionamos anteriormente, um gene preditor é um gene cujo perfil de expressãopossui informação significante (sozinho ou junto com outros genes preditores) sobre o perfilde expressão de um gene alvo. É possível aplicar técnicas de seleção de características (nessecontexto, genes) para achar o melhor subconjunto de genes que predizem genes alvos. Ummétodo de seleção de características é composto por um algoritmo de busca e uma funçãocritério.

Neste trabalho consideraremos a abordagem para inferência de redes de regulação gênicaproposta por Barrera et al. (2007) e Lopes et al. (2008), que usa seleção de característicascomo princípio. A ideia básica dessa abordagem consiste em, escolhido um gene alvo, rea-lizar uma busca pelo subconjunto de preditores que melhor descreve o comportamento dogene alvo. Nestes dois trabalhos, Barrera, Lopes e seus colegas, além de apresentarem ummodelo para GRNs, discutem esta abordagem no contexto da análise de sinais de expressãodo Plasmodium falciparum (um dos agentes da malária) e chegaram a resultados biológicosinteressantes. Além disso, Lopes et al. (2009) fizeram um estudo comparando esta aborda-

2.3 INFERÊNCIA DE GRNS POR CÁLCULO ENTROPIA CONDICIONAL MÉDIA 9

gem com outros métodos de inferência como o MRNET, ARACNE e CLR e mostraram quea abordagem em questão apresenta resultados superiores para predição multivariada.

Tanto nos trabalhos de Barrera e de Lopes como também aqui, foi adotada a entropiacondicional média (do inglês, mean conditional entropy) como função critério, que fornecea informação mútua média de um gene alvo dado seus preditores. Informação mútua éuma medida de independência entre variáveis que foi empregada em muitas campos depesquisa como em processamento de imagem (Martins-Jr et al., 2006; Pluim et al., 2003),física (Fraser e Swinney, 1986) e bioinformática (Zhou et al., 2004a,b). A principal vantagemda informação mútua comparada com outras medidas de similaridade como, por exemplo,a correlação de Pearson, é a capacidade de capturar relações não lineares entre as variáveis(Zhou et al., 2004a).

Como método de busca, usamos Busca Exaustiva para a procura de todos os possíveispares ou triplas de preditores candidatos para um determinado gene alvo. A busca exaustivaé a única maneira de garantir a otimalidade em seleção de características devido ao fenô-meno de predição intrinsecamente multivariada, o que pode ocorrer em sistemas biológicos(Martins-Jr et al., 2008). Este fenômeno está relacionado ao efeito nesting , em que um genejá inserido (ou removido) do conjunto solução não pertence (ou pertence) ao conjunto ótimo(Martins-Jr et al., 2008). Este efeito ocorre quando um algoritmo guloso de seleção de carac-terísticas ou outra heurística sub-ótima é aplicado. A rede é obtida pela aplicação da buscaexaustiva para todo gene considerado como alvo. Para todo gene alvo, há um subconjuntode genes preditores e um valor de entropia condicional média. Através deste subconjunto,é possível desenhar um grafo dirigido (G,R) como descrito na seção 2.1. Nas seções queseguem descrevemos com mais detalhes essa ideia.

2.3.1 Busca Exaustiva

Dado um conjunto G de genes, o algoritmo de busca identifica, para cada gene alvoy ∈ G, o melhor subconjunto X ⊆ G que prediz y de acordo com a função critério H. Oalgoritmo a seguir executa uma busca exaustiva para identificar os pares (X,y):

Algoritmo 1 : BuscaExaustivaEntrada: um conjunto G de genes1: para para cada gene alvo y ∈ G faça2: para para cada subconjunto X ⊆ G faça3: calcular a capacidade de X predizer y de acordo com uma função critério H4: fim para5: fim para


Função Critério

A função critério adotada é baseada na entropia condicional média (MCE). A Entropiade Shannon (Shannon e Weaver, 1963) de uma variável Y é definida por

H(Y ) = −∑y∈YP (Y = y) logP (Y = y),

P (Y = y) é a probabilidade da variável Y ser igual a y. A entropia condicional de Y

dado X = x é:

H(Y |X = x) = −∑y∈YP (Y = y|X = x) logP (Y = y|X = x),

onde X é o vetor de características e P (Y = y|X = x) é a probabilidade condicional de Y

ser igual a y dado a observação a uma instância x ∈ X.Finalmente, a Entropia Condicional Média (MCE) é definida pela média ponderada

das entropias condicionais (Barrera et al., 2007; Lopes et al., 2009):

H(Y |X) =∑

x∈XP (X = x)H(Y |X = x).

Um Exemplo Ilustrativo

A fim de dar maior clareza à descrição do método de inferência de GRNs por cálculo deentropia condicional média, nesta subseção iremos ilustrá-lo através de um exemplo didático:tomemos a Tabela 2.1 como a entrada do método, que é uma matriz de expressão gênicasobre a qual aplicamos quantização binária; nas linhas estão representadas as amostras e nascolunas os genes em estudo.

Gene 0 Gene 1 Gene 2 Gene 3Amostra 0 (tempo 0) 1 1 1 1Amostra 1 (tempo 1) 0 1 0 1Amostra 2 (tempo 2) 1 1 1 1Amostra 3 (tempo 3) 1 0 1 0Amostra 4 (tempo 4) 1 0 1 0Amostra 5 (tempo 5) 0 1 0 0Amostra 6 (tempo 6) 0 0 1 0

Tabela 2.1: Um exemplo de entrada para o método contendo dados temporais (quantizados paravalores binários) de expressão gênica de 4 genes e 7 amostras.

Por concisão, vamos ilustrar os cálculos de entropia para apenas um par de genes can-didatos a preditores de um gene alvo específico: vamos assumir que deseja-se o melhorsubconjunto de cardinalidade igual a 2 que prediz o Gene 2. Como o algoritmo de busca éo Busca Exaustiva, o método irá então testar todas as possíveis duplas para identificar qualdelas melhor prediz o Gene 2, isto é, testará o valor preditivo de (Gene 0, Gene 1); (Gene 0,Gene 2); (Gene 0 , Gene 3); (Gene 1, Gene 2); (Gene 1, Gene 3) e (Gene 2, Gene 3).

Vamos focar a descrição em um passo do algoritmo: dentre todas essas duplas de can-didatos a preditores, vamos detalhar apenas as contas realizadas para avaliar a capacidade


do par (Gene 0, Gene 1) predizer o Gene 2. Ou seja, este procedimento de cálculo, queilustraremos a seguir, embora descreva apenas os cálculos da capacidade do par (Gene 0,Gene 1) predizer o Gene 2, se aplica a todo par de genes candidato a predizer qualquer genealvo.

Como considera-se evolução temporal, usamos os valores dos genes preditores no tempot para prever o valor do gene alvo no tempo t+ 1.

Ainda por concisão e por clareza, copiamos apenas os dados relevantes ao exemplo daTabela 2.1 para a Tabela 2.2.

Gene 0 Gene 1 Gene 2Amostra 0 (tempo 0) 1 1 1Amostra 1 (tempo 1) 0 1 0Amostra 2 (tempo 2) 1 1 1Amostra 3 (tempo 3) 1 0 1Amostra 4 (tempo 4) 1 0 1Amostra 5 (tempo 5) 0 1 0Amostra 6 (tempo 6) 0 0 1

Tabela 2.2: Dados parciais obtidos da tabela de entrada (Tabela 2.1), para facilitar o entendimentodo exemplo, focando na avaliação da capacidade do par (Gene 0, Gene 1) predizer o Gene 2.

Vamos descrever os detalhes no exemplo a seguir. Observamos que o Gene 0 é igual a 1 eo Gene 1 também é igual a 1 no tempo t = 0 (primeira linha da Tabela 2.2) e que o Gene 2possui valor igual a 0 no tempo t = 1 (segunda linha da Tabela 2.2). Dada essa observação,incrementamos em uma unidade o número de ocorrências dessa combinação de valores (Gene0 = Gene 1 = 1 num tempo t e Gene 2 = 0 num tempo t+ 1) na Tabela de ProbabilidadesCondicionais (CPT), do inglês Conditional Probability Table, que está ilustrada na Tabela2.3. Esta tabela possui valor zero em todas as posições inicialmente. A CPT é uma estruturaque fornece a frequência que cada caso possível que genes podem assumir. Ela é essencialpara o cálculo da entropia condicional média.

Outro exemplo, observamos que o Gene 0 é igual a 0 e o Gene 1 é igual a 1 no tempot = 1 (segunda linha da Tabela 2.2) e que o Gene 2 possui valor igual a 1 no tempo t = 2

(terceira linha da Tabela 2.2). Dada essa observação, similarmente incrementamos em umaunidade o número de ocorrências dessa combinação de valores (Gene 0 = 0, Gene 1 = 1 numtempo t e Gene 2 = 1 num tempo t+ 1) na Tabela 2.3.

Fazemos isso para todas as linhas da Tabela 2.2, obtendo assim a Tabela 2.3.

Gene 0 Gene 1 Gene 2 = 0 Gene 2 = 10 0 0 10 1 0 21 0 1 11 1 1 1

Tabela 2.3: Tabela de Probabilidades Condicionais para o caso do par (Gene 0,Gene 1) o predizerGene 2.

Como mencionado na seção 2.3.1, a entropia pode ser calculada da seguinte forma:


H(Y |X = x) = −∑y∈YP (Y = y|X = x) logP (Y = y|X = x).

A base do logaritmo varia de acordo com o número de símbolos de representação dainformação. No caso da entropia de Shannon, o mais usual é base 2, pois na maior partedo tempo mede-se a quantidade de informação por meio de bits. Já no caso do cálculo daentropia para a inferência de GRNs, faz todo sentido que a base seja q, já que este será onúmero de valores que cada gene pode assumir (esse é o nosso número de símbolos). Dessemodo, o valor da entropia sempre será um valor entre 0 e 1 e pode-se calculada da seguinteforma:

H(Y |X = x) = −∑y∈YP (Y = y|X = x) logq P (Y = y|X = x),

onde q é a quantidade de classes que um gene pode assumir. Como neste exemplo a quanti-zação dos dados é binária (q = 2), a entropia tem que ser calculada para cada caso possívelde valores que os Genes 0 e 1 podem assumir (dados da Tabela 2.3) :

H(Gene 2 | Gene 0 = 0, Gene 1 = 0) = −(01× log2

0

1+

1

1× log2

1

1) = 0


0

2+

2

2× log2

2

2) = 0


1

2+

1

2× log2

1

2) = 1


1

2+

1

2× log2

1

2) = 1

Na Tabela 2.4 apresenta a entropia para cada caso possível que o Gene 0 e o Gene 1pode assumir.

Gene 0 Gene 1 Gene 2 = 0 Gene 2 = 1 Entropia0 0 0 1 00 1 0 2 01 0 1 1 11 1 1 1 1

Tabela 2.4: Tabela de Probabilidades Condicionais junto com a entropia para cada caso possívelque o Gene 0 e o Gene 1 pode assumir.

O cálculo da entropia condicional média (Hm) é uma média ponderada das entropiasda Tabela 2.4. Dentre os possíveis casos de valores que os Genes 0 e 1 podem assumir(presentes na CPT), devemos descobrir qual deles apresenta o maior poder de predição. Paraisso, identificamos o caso de maior frequência (ocorrência) na CPT para todo caso possível,dividimos este valor pelo número total de amostras e o multiplicamos pela entropia de cadacaso. Por exemplo, para o caso (Gene 0 = 0, Gene 1 = 0), devemos multiplicar 1

7(1 tem maior

frequência, 7 amostras) por 1 (Gene 2 = 1) pela entropia no caso (Gene 0 = 0, Gene 1 = 0).Soma-se o valor da etapa anterior com a entropia do próximo caso Gene 0 = 0, Gene 1 = 1.


Isto acontece até que sejam percorridos todos os valores possíveis para os Genes 0 e 1.O cálculo de Hm encontra-se logo abaixo e segue a seguinte ordem de casos: (Gene 0 =

0, Gene 1 = 0), (Gene 0 = 0, Gene 1 = 1) ,(Gene 0 = 1, Gene 1 = 0),(Gene 0 = 1, Gene 1 =

1).

H(Gene 2 | Gene 0, Gene 1) =1

7× 0 +

2

7× 0 +

2

7× 1 +

2

7× 1 =

4

7

Os passos acima descritos são aplicados para todos os pares de genes. Aquele com omenor valor de entropia condicional média será o escolhido para ser o melhor subconjuntode genes preditores do Gene 2.

Capítulo 3

Arquitetura GPU/CUDA

GPU (do inglês - Graphics Processing Unit) é essencialmente um dispositivo de hard-ware otimizado para processamento gráfico, sendo capaz de fornecer em tempo real umainteração visual com objetos computacionais através de imagens gráficas e vídeos. A execu-ção das operações é altamente paralelizada, multithread e os processadores internos da GPUcontém muitos núcleos, também conhecidos como cores. Tudo isto gera um enorme poderde computação e uma alta largura de banda de memória. As GPUs foram otimizadas paraexecutar operações com vetores e operações aritméticas de ponto flutuante, executando noSIMD (do inglês - Simple Instruction, Multiple Data) (Nvidia1, 2013).

A GPU pode servir tanto como um processador gráfico programável como também umaplataforma computacional paralela escalável. As GPUs podem compor sistemas heterogêneospodendo ser combinadas com a CPU para gerar processamento de propósito geral com altonível e desempenho (Nvidia1, 2013). A Figura 3.1 mostra uma comparação teórica entrequantidade de flops e largura de banda entre uma GPU e uma CPU. Pode-se perceber quehouve pouco aumento no poder de processamento nas CPUs se comparado com o das placasgráficas.

A discrepância que ocorre entre GPUs e CPUs nas operações de ponto flutuante e lar-gura de banda de memória (Figura 3.1) é devido a especialização da GPU em computaçãointensiva e altamente paralelizada. Esta especialização é obtida pelo tipo de design da GPU,feito de tal forma que mais transistores são devotados para processamentos de dados ao invésde utilizados para cache de dados e controle de fluxo (Nvidia1, 2013).

Cada GPU possui um conjunto de Streaming Multiprocessors (SMs), cada um consti-tuído por um array de cores, que são as unidades lógicas aritméticas da GPU. A Figura 3.2ailustra esta organização. Cada SM possui um grande número de registradores, uma pequenaunidade de controle e uma pequena quantidade de memória compartilhada, acessível pelasthreads executadas no SM. O dispositivo de vídeo normalmente possui uma grande quan-tidade de memória global, que é compartilhada pelos SMs. A latência para acessar estamemória é grande e, consequentemente, a memória compartilhada é normalmente usadacomo um cache controlável pelo usuário.

15

16 ARQUITETURA GPU/CUDA 3.0

Figura 3.1: Comparação entre a largura de banda de memória e o número de operações de pontoflutuante por segundo em GPUs e CPUs. Em ambos os gráficos, a linha verde representa a GPU ea linha azul, a CPU. Figura obtida de Nvidia1 (2013).

3.0 17

Um SM cria, gerencia, escalona e executa threads em grupos de 32 threads paralelasconhecidas como warps . Threads individuais que compõem um warp começam a executarjuntas no mesmo endereço do programa, mas estas threads possuem seu próprio contadorde endereço de instruções e o registro de estado de ações. Portanto, estas threads são livrespara ramificar e executar um trecho de código de forma independente (Nvidia1, 2013).

Quando um SM executa um ou mais blocos de execução, este particiona as threads emwarps e cada warp é escalonado por um escalonador de warps para a execução. O jeito que obloco é particionado em warps é sempre o mesmo: cada warp contém threads em consecutivode acordo com o ID de cada thread. A hierarquia de threads descreve como os IDs das threadsse relacionam com os índices dos blocos de execução.

Figura 3.2: A plataforma CUDA. a) Arquitetura de uma GPU moderna, possuindo uma grandequantidade de memória global e um conjunto de multiprocessadores, cada um com um conjuntode processadores de ponto flutuante, uma pequena memória compartilhada e um grande númerode registradores. b) Organização hierárquica das threads nos blocos de execução e em grids, na qualcada bloco de execução é associado a um único multiprocessador. Figura obtida de de Camargo et al.(2010).

A Figura 3.3 mostra a diferença entre as arquiteturas de uma CPU e GPU. Nesta figura,um SM é representado por uma linha na horizontal na cor verde, que possui 16 cores.Cada SM possui uma pequena memória compartilhada, que somente pode ser acessadapelo seu correspondente SM e uma pequena unidade de controle. Já a CPU possui umagrande unidade de controle e um espaço reservado para memória cache, que juntas ocupamaproximadamente metade da pastilha de um processador. A GPU possui mais unidadeslógicas aritméticas (ALU) que a CPU.

Todos os SMs possuem acesso a uma memória global, que é lento se comparado com oacesso de um SM à memória compartilhada. Assim, o desejável é que haja a menor quan-tidade possível de tráfego de dados entre a memória global e a memória compartilhada decada SM.

Existem diferentes arquiteturas GPUs produzidas pela Nvidia. Estas arquiteturas estãorelacionadas ao compute capability da GPU, que define um conjunto de especificaçõestécnicas e recursos para rodar aplicações em CUDA (Ortega e Rueda, 2010). O compute ca-


Figura 3.3: Comparativo entre as arquiteturas CPU e GPU. Figura obtida de Nvidia1 (2013).

pability é composto por um número principal e um por um número secundário. Por exemplo,compute capability igual a 2.1 significa que o número principal é igual a 2 e o secundário éigual a 1. O número principal denota uma identificação arquitetural, de modo que placas como mesmo número principal possuem a mesma arquitetura. O número secundário correspondea uma melhoria incremental no núcleo da arquitetura, possivelmente, por exemplo, inclusãode novos recursos (Nvidia1, 2013). Quanto maior o Compute capability de uma GPU, maioré a quantidade de recursos avançados disponíveis para usar nas aplicações CUDA.

Em novembro de 2006, a NVIDIA introduziu CUDATM (do inglês - Compute UnifiedDevice Architecture), uma arquitetura de computação paralela de propósito geral, com umnovo modelo de programação paralela e um conjunto de instruções que aproveita o meca-nismo de paralelismo da GPU para resolver problemas computacionalmente complexos demaneira mais eficiente que em CPU (Nvidia1, 2013). CUDATM fornece uma extensão dalinguagem C que pode ser usada para programar GPUs para fins de propósito geral. Ocompilador gera um código executável para a GPU a partir do código-fonte CUDA.

O programador define funções especiais chamadas kernels, que são executadas na GPU.O usuário define o número de threads a serem criadas, organizando-as em blocos de threads .A coleção de blocos de um kernel em execução é chamado de grid . Cada bloco de execuçãoroda em um único SM, mas um SM pode executar mais de um bloco de execução em ummesmo espaço de tempo. Todas as threads de um grid executam o mesmo kernel. Um gridé organizado em um vetor 2D de blocos. Cada bloco é organizado em um vetor 1D, 2D ou3D de threads. Uma vez que o kernel é lançado, suas dimensões não podem ser alteradas.Todos os blocos possuem a mesma dimensão (Ryoo et al., 2008).

A GPU possui um recurso chamado syncthreads que permite sincronizar os warps deum bloco. Este recurso não permite sincronizar warps de blocos diferentes. Há uma barreiraglobal implícita entre os diferentes kernels. É uma boa política em limitar ou eliminar rotinasque precisem coordenação global de todas as threads (Ryoo et al., 2008).

O principal desafio de implementar programas eficientes em CUDA é codificar a aplicaçãocom um número grande de threads de modo a manter todos os multi-processadores da GPU

3.0 19

ocupados e com o menor tráfego de informação entre a memória compartilhada de cada SMe a memória global da GPU (de Camargo et al., 2010). Ou seja, o segredo para obter umbom desempenho é manter os SMs da GPU sempre ocupados. Para tal, os blocos devemter tamanhos múltiplos de 32 para coincidirem com o tamanho dos warps. Também deve-se usar o menor número possível de registradores por thread, pois o número de blocos porSM será maior. Com mais blocos por SM, haverá mais opções de threads para execução,especialmente quando as threads estiverem esperando por dados da memória global.

Há algumas características que o programa deve possuir para conseguir bons speedups emGPUs. Uma delas diz respeito à estrutura do problema, que deve permitir ser subdivido empequenos subproblemas, para estes serem alocados a diferentes blocos e threads. Cada threadmantém uma pequena quantidade de estados. É bom possuir alta razão de operações deponto flutuante pela quantidade de memória utilizada e esses subproblemas serem fracamenteacoplados. O acoplamento indica o quanto os subproblemas são dependentes entre si.

Operações atômicas são caras computacionalmente se comparada a operações regularesem memória. Podemos usar índices que combinam os ids das threads para evitar o problemada condição de corrida e o uso de operações atômicas. Basicamente, cada thread terá umidentificador único e escreverá apenas em um único endereço de memória. Haverá umabijeção entre o identificador único da thread e o endereço de memória. Com isto, não énecessário usar operações atômicas e também evitamos o problema da condição de corrida.Esta estratégia de índices pode ser usada na memória global ou compartilhada da GPU.

As threads podem acessar dados presentes em vários tipos de memórias durante suaexecução. Cada thread possui uma memória local. Cada bloco possui uma memória compar-tilhada visível para todas as threads do bloco. Todas as threads possuem acesso a mesmamemória global.

Um das considerações mais importantes relativas a desempenho em GPUs consiste noacesso à memória global. Para cada compute capability, a leitura e escrita de dados podeser de forma diferente. O acesso à memória global é feito pelas threads de um warp. Onúmero de threads em um warp depende do compute capability da GPU. Para entendera coalescência (do inglês coalesced memory access), a memória global da GPU deve servista como segmentos de 16 ou 32 bits. Quando 16 threads de um warp acessam a memóriaao mesmo tempo, a GPU combina os acessos em uma única requisição. Para tal, todas osendereços devem estar localizados em um único intervalo de 128 bytes. No caso de dados comseparações de 2 ou mais posições (endereços), o desempenho cai consideravelmente (Nvidia2,2013).

Para atingir maior largura de banda entre os acessos simultâneos, a memória compar-tilhada é divida em bancos de memória com tamanhos iguais que podem ser acessadossimultaneamente. Portanto, todo armazenamento de endereços que se estende em bancos dememória distintos podem ser atendidos simultaneamente, gerando uma efetiva largura debanda que é maior do que a largura de banda de um único banco (Nvidia2, 2013).

No entanto, se há múltiplas requisições de um endereço de memória e estas apontam


para um mesmo banco de memória, os acessos são serializados. O hardware divide umarequisição de memória que tem conflito de bancos em vários pedidos separados sem conflitos,diminuindo a banda efetiva por um fator igual ao número de pedidos de memória que serárealizado sequencialmente. A única exceção é quando metade de um warp acessa o mesmoendereço de memória, resultando em um acesso broadcast. Apenas as placas com computecapability igual a 2.x ou superior têm a habilidade de vários acessos broadcast à memóriacompartilhada.

Uma decisão importante ao modelar o problema em GPU é a escolha correta da estru-tura de dados. Há basicamente duas estruturas de dados: a primeira opção é um vetor deestruturas e a segunda, uma estrutura de vetores. A segundo opção é mais adequada à GPU,pois pode-se aproveitar a coalescência, já que os endereços para um mesmo tipo de variá-vel (vetores) estão localizados mais próximos. A Figura 3.4 mostra a diferença entre estasestruturas.

Figura 3.4: Opções de estrutura de dados para modelar problemas em GPU. Da esquerda para adireita, a primeira opção é um vetor de estruturas e a segunda, uma estrutura de vetores. A segundoopção é mais adequada a GPU, pois pode-se aproveitar a coalescência.

As chamadas ao Kernel causam um overhead. Além disso, muitas vezes precisamos passardados para o kernel ou obter resultados de execução. Uma maneira de melhorar o desempe-nho é agrupar um maior número de tarefas em uma chamada. Por exemplo, se for precisoresolver diversos sistemas lineares, o melhor é resolver todos os sistemas lineares em umaúnica chamada do kernel ao invés de chamar um kernel cada resolver um sistema linear.

Processamento stream é um paradigma de programação de computadores no modeloSIMD (Single Instruction Multiple Data), que permite a exploração de algumas aplicaçõesde maneira mais fácil através do processamento paralelo. Algumas aplicações podem utilizarunidades funcionais múltiplas, tais como as unidades de ponto flutuante na GPU, sem expli-citamente gerenciar as alocações de memória, sincronização ou comunicação através destasunidades.

O paradigma do processamento stream simplifica o desenvolvimento de hardware e soft-ware limitando as operações que podem ser executadas. Através das abstrações chamadasde stream, um conjunto de dados e um kernel (uma série de operações que pode ser vistascomo um pequeno programa), o programador pode realizar diversas tarefas que exigem alto

3.0 21

poder de processamento.General-Purpose computing on Graphic Processing Units (GPGPU) é uma téc-

nica para a utilização da GPU, que tipicamente lida com computação gráfica, em aplicaçõestradicionalmente realizadas em CPU, para o ganho de performance em processamento. Istosó é possível graças à inserção de estágios programáveis e à alta precisão aritmética dospipelines renderizáveis, o que permite aos desenvolvedores de software usar o processamentostream em dados do tipo não-gráficos (Owens et al., 2007).

GPUs são especificamente desenhadas para processamento gráfico, de tal modo que sãomuito restritas em termos de operação e programação. Por sua natureza, as GPUs sãosomente eficientes na resolução de problemas que podem ser solucionados usando pro-cessamento stream, no qual o hardware só pode ser utilizado em certos casos específi-cos (Owens et al., 2007).

Em um algorítimo sequencial é possível controlar o fluxo do programa utilizando estru-turas condicionais do tipo “if-then-else” e variadas formas de loops. Alguns tipos de controlede fluxo foram adicionadas recentemente às GPUs. Escritas condicionais podem ser com-pletadas usando-se uma série devidamente trabalhada de operações bit/aritméticas, maslooping e ramificações condicionais não são possíveis. Algumas GPUs recentemente lançadaspermitem ramificações, mas geralmente suas performances são penalizadas por utilizar taisartifícios. Ramificações devem geralmente ser evitadas em loops internos, seja em algorítimospara CPU ou GPU.

Capítulo 4

Materiais e Métodos: UsandoGPU/CUDA para Inferência de GRNs

Nesta seção e em suas subseções descrevemos um algoritmo GPU/CUDA para inferên-cia de GRNs através do cálculo de entropia condicional média (Borelli et al., 2012). Estealgoritmo corresponde à base metodológica a partir da qual seguiremos a fim de atingir osobjetivos descritos na seção 1.1.

A ideia geral desse algoritmo paralelo para busca exaustiva consiste em distribuir acomputação da função critério entre os SMs de tal maneira que cada um deles seja responsávelpor calcular a função critério para uma fracão dos genes de G (lembremos que G denota oconjunto de genes). Para isto, o algoritmo particiona G e distribui os segmentos resultantesentre os blocos de execução. Então, cada SM executa a busca exaustiva localmente para umsegmento de G. Em um segundo passo, os segmentos de G são permutados entre os blocosa fim de efetivamente executar uma busca exaustiva global.

4.1 Considerações Iniciais

Omodelo de programação CUDA é baseado no seguinte princípio: copiar o dado requeridoda memória global para a memória compartilhada da GPU, executar a maior quantidadepossível de operações usando a memória compartilhada e salvar os resultados na memóriaglobal. Então, o desafio está em como particionar G e em como permutar os segmentosresultantes entre os blocos de modo a minimizar a troca de dados entre a memória global ea memória compartilhada.

Dado G com n genes, a Busca Exaustiva é exponencial em termos de n, o que torna oprocedimento inviável para típicos valores de n (na ordem de milhares para experimentosde microarray ou RNA-Seq). Para reduzir o espaço de busca, podemos fixar o número depreditores em dois ou três, isto é, utilizando a mesma notação adotada no Algoritmo 1,assumimos que |X| = 2 (seção 4.3) e |X| = 3 (seção 4.6). Esta medida melhora a perspectivade viabilidade computacional e não é muito restritivo no ponto de vista biológico, uma vez

23

24 MATERIAIS E MÉTODOS: USANDO GPU/CUDA PARA INFERÊNCIA DE GRNS 4.3

que existem várias evidências que sugerem que o número médio de genes preditores nasGRNs está entre 2 e 3 (Kauffman, 1993).

Denotamos por th o número de threads lançadas em cada bloco e tg é o número de genesalvos processados por bloco. A razão n/tg é o número de blocos que são lançados na GPU.Este número é denotado por k.

Usando um warp (conjunto de 32 threads), a GPU pode otimizar a transferência dearquivos entre a memória global e a memória compartilhada. Assim, recomenda-se que th

seja múltiplo 32, pois é a quantidade de threads de um warp para compute capabilitiesmaiores ou iguais a 2.

4.2 Pré-Processamento

Inicialmente, a matriz de expressão gênica é carregada do disco rígido e replicada emduas matrizes T e P , que representam a expressão de cada gene alvo e o conjunto de genescandidatos a serem preditores, respectivamente. Cada matriz contém l linhas, representandoas amostras dos experimentos, e n colunas, representando cada uma delas um gene. A Fi-gura 4.1(a) mostra um exemplo de uma matriz com 4 genes e 7 amostras. Depois de carregaros dados nas matrizes T e P na memória principal, o programa aloca espaço e transfere asmatrizes para a memória global da GPU.

Figura 4.1: a) Exemplo de uma matriz de expressão gênica com 7 amostras e 4 genes. T e Psão cópias desta matriz. b) Avaliação da entropia condicional média baseada nas probabilidadescondicionais de um gene alvo dado dois preditores.

4.3 Busca Exaustiva Local com Dois Preditores

Nós consideramos que k blocos são lançados, denotados por Bl0, Bl1, . . . , Blk−1. O al-goritmo então particiona o conjunto de genes alvos T em k segmentos T0, T1, . . . , Tk−1 detamanho n/k e o conjunto de genes candidatos a serem preditores P em 2k segmentosP0, P1, . . . , P2k−1 de tamanho n/2k, como ilustrado na Figura 4.2. Cada bloco de execução

4.4 BUSCA EXAUSTIVA LOCAL COM DOIS PREDITORES 25

é responsável por avaliar a função critério para cada gene alvo em Ti, 0 ≤ i ≤ k − 1, paratodo par de preditor do conjunto P .

Blk−1 k−1

TBl Bl

0 1 2Bl

0 1 2 k−1

0 1 2P: P P P P

. . .

. . .

0 1 2...

T: T T T T

T T T

2k−1

Figura 4.2: Particionando as matrizes T e P em k segmentos e regra de acesso dos blocos aossegmentos T : uma flecha Ti → Bli indica que o bloco Bli acessa o segmento Ti.

Cada thread calcula a entropia condicional média para cada par de candidatos a genespreditores de um único gene alvo em Ti. Para calcular a entropia, cada bloco de execuçãotransfere para a memória compartilhada de seu SM partes da tabela T e P contendo um con-junto de genes alvos Ti e dois conjuntos de preditores Pj1 e Pj2. Estes dados são transferidosda memória global usando coalescência, na qual aumenta à largura de banda de memória.

O Algoritmo 2 descreve a Busca Exaustiva executada em cada bloco de execução. Paracalcular a entropia condicional média de cada gene alvo em Ti e para cada par de genescandidatos a serem preditores de Pj1 e Pj2, a thread cria uma tabela como mostra a Figura4.1(b). Esta tabela, também conhecida como Tabela de Probabilidades Condicionais (CPT),contém o número de vezes que um gene em Ti assume valores 0 ou 1 para cada combinaçãodos valores dos genes preditores e a entropia condicional associada. As threads mantém aCPT nos registradores de seus respectivos SMs durante o cálculo das entropias, evitando olento acesso a memória global.

Algoritmo 2 : BuscaExaustivaLocalEntrada: segmento Ti de genes alvos e segmentos Pj1 e Pj2 de genes candidatos a serem

preditores1: para para cada gene alvo t ∈ Ti faça2: para para cada par (p1, p2) ∈ {Pj1 × Pj2} faça3: calcular a capacidade de (p1, p2) predizer t de acordo com a função critério H4: fim para5: fim para


4.4 Busca Exaustiva Global

A busca exaustiva global fornece, para cada bloco de execução, todos os pares de com-binação de todos os subconjuntos de genes candidatos a serem preditores Pj1 e Pj2. Comestas permutações entre os segmentos de P , cada bloco de execução Bli pode avaliar todosos genes candidatos a serem genes preditores para qualquer gene em Ti, como descrito noAlgoritmo 3 e ilustrado na Figura 4.3.

Bl10

Bl2

BlBlk−1

i=0

i=1

Bl10

Bl2

BlBlk−1

......

Bl10

Bl2

BlBlk−1

0P P

0P

...P0

P1

P2

P2k−2 P

2k−1

...P0

P1

P2

P2k−2 P

2k−1

...P0

P1

P2

P2k−2 P

2k−1

i=2k−1

1P P

1P1

2k−1P P

2k−1P2k−1

...

P:

T0

P T1

T2

Tk−1

...

P:

T0

P T1

T2 k−1

T

...

P:

T0

T1

T2

Tk−1

0

1

2k−1P

Figura 4.3: Regra de acesso dos blocos de execução aos segmentos. Uma flecha Pi → Blj indica queo bloco Blj acessa o segmento Pi. Flechas com a mesma cor indica que os acessos são executadosde forma simultânea.

Ao dividir as matrizes em conjuntos contíguos, podemos utilizar o acesso coalesced (?) damemória global para a memória compartilhada, aumentando a largura de banda da memória.Neste tipo de transferência, w valores de memória são transferidos em um único acesso. O

4.5 ALGORITMO MULTI-AMOSTRA-VARIÁVEL (MAV) 27

Algoritmo 3 : BuscaExaustivaGlobalEntrada: segmento Ti dos genes alvos e segmento Ps dos genes candidatos a serem predi-

tores para cada gene alvo1: Transferir da memória global para memória compartilhada da GPU os dados de expres-

são gênica dos genes alvos para Ti

2: para j1← 0 até 2k − 1 faça3: Transferir os dados de expressão gênica de Pj1 para todos os blocos4: para j2← j1 até 2k − 1 faça5: Transferir os dados de expressão gênica de Pj2 para todos os blocos6: Calcular a entropia para todos os pares de genes candidatos a serem preditores

(p1, p2) ∈ {Pj1 × Pj2}7: fim para8: fim para

valor de w depende da arquitetura e possui um valor igual a 32 para as GPUs utilizadasnossos testes. Consequentemente, o algoritmo funciona de forma ótima para GRNs comtamanhos (número de genes) múltiplos de 32. Isto otimiza não somente as transferênciasentre as memórias global e compartilhada, mas também o uso dos cores da GPU. ParaGRNs de tamanhos diferentes de múltiplo de 32, genes artificiais podem ser adicionados naGRN de forma a completar w.

4.5 Algoritmo Multi-Amostra-Variável (MAV)

Os algoritmos descritos nas subseções anteriores foram desenvolvidos para funcionar comaté 30 amostras, ou seja, l ≤ 30. Tecnologias de grande escala como o RNA-seq estão forne-cendo grandes quantidades de dados de transcriptoma (Lister et al., 2009; Metzker, 2010),o que neste trabalho se traduz na necessidade de desenvolver uma ferramenta computacio-nal que funcione para grandes quantidades de amostras. Para isto, uma possível estratégianeste trabalho seria diminuir a quantidade de genes alvos por bloco para podermos assimaumentar o número de amostras possíveis a serem armazenadas na memória compartilhadade cada SM. Mas isto funcionaria apenas para um número limitado que, embora maior que30, ainda sim limitado por conta do pequeno tamanho da memória compartilhada. Paradriblar este problema, adotamos a seguinte estratégia:

1. Mantivemos a CPT na memória compartilhada de cada SM.

2. Dividimos as amostras em l/sh segmentos, lembrando que l é o número total de amos-tras e sh definimos como sendo o número total de amostras que podem ser armazenadasna memória compartilhada de cada SM.

3. Transferimos estes segmentos de amostras da memória global da GPU para a memóriacompartilhada, um por vez, sendo que em cada um desses passos atualizamos a CPT.


Em geral, o número de amostras do problema (l) é maior que o número de amostrasque podem ser armazenadas na memória compartilhada (sh), portando temos de agrupartodos os segmentos Pj1, Pj2 e Ti em l/sh novos segmentos, os quais são definidos sobre asamostras (linhas das tabelas P e T ) e que serão aqui denominados de agrupamentos. Maisespecificamente, fazemos:

• particionamos as linhas (amostras) de cada segmento Pj1 em l/sh agrupamentosPj1,0, Pj1,1, . . . , Pj1,l/sh−1 de tamanho sh;

• particionamos as linhas (amostras) de cada segmento Pj2 em l/sh agrupamentosPj2,0, Pj2,1, . . . , Pj2,l/sh−1 de tamanho sh;

• particionamos as linhas (amostras) de cada segmento Ti em l/sh agrupamentosTi,0, Ti,1, . . . , Ti,l/sh−1 de tamanho sh;

O particionamento das matrizes P e T em colunas (segmentos de genes) e em linhas(agrupamento de amostras) define uma unidade de trabalho bidimensional que denomina-remos de tablete , que nada mais é do que uma porção de genes e amostras. O tamanhodessa porção é diferente na matriz T e na matriz P : na matriz T um tablete é formado porn/k genes e sh amostras, ao passo que na matriz P um tablete é formado por n/2k genes esh amostras. Podemos pensar também que tabletes são submatrizes: para a matriz T , umtablete é uma submatriz de n/k colunas e sh linhas, ao passo que para a matriz P , umtablete é formado por n/2k colunas e sh linhas. A Figura 4.4 ilustra esquematicamente oconceito de tablete.

Os tabletes Pj1,x, Pj2,x, Ti,x são transferidos para a memória compartilhada com o pro-pósito de atualizar a CPT para cada gene alvo pertencente a Ti. Somente depois de terrealizado a leitura de todos os tabletes Pj1,x, Pj2,x, Ti,x e atualizar a CPT, para cada valorde x, 0 ≤ x < l/sh, é que podemos calcular a entropia condicional média de cada gene alvo.O Algoritmo 4 reflete esta mudança. Assumimos que o valor de l seja múltiplo de sh.

A Figura 4.5 ilustra os procedimentos das cópias dos l/sh tabletes Pj1,x, Pj2,x e Ti,x paraa memória compartilhada de cada SM. Cada flecha de uma mesma cor representa a cópia emum mesmo passo do Algoritmo 4, linha 3. O primeiro passo é copiar o primeiro tablete dossegmentos Pj1, Pj2 e Ti (cor preta - tabletes Pj1,0, Pj2,0 e Ti,0 ) da memória global da GPUpara a memória compartilhada de cada SM. Num segundo passo, os tabletes Pj1,1, Pj2,1 e Ti,1

(cor verde) são copiados da memória global da GPU para a memória compartilhada e assimpor diante até que os últimos tabletes (de cor vermelha) são copiados da memória globalda GPU para a memória compartilhada. Somente após a cópia de todos os l/sh tabletesé que podemos calcular a entropia para os genes alvos. Enquanto os tabletes Pj1,x e Pj2,x,0 ≤ x < l/sh, são copiados para todos os blocos, os tabletes Ti,x são copiados apenas paraos blocos Bli. Estas cópias são feitas para toda combinação de Pj1 e Pj2 (ver Algoritmo 3 -Busca Exaustiva Global).

4.5 ALGORITMO MULTI-AMOSTRA-VARIÁVEL (MAV) 29

Ti,x

... Ti

Tk−1...T0

T1

... ...

...

...

...

...

Pj1,x

Pj2,x

P0 P2k−1

P1

P3

P4

Pj1

Pj1+1 Pj2

0

1

l/sh−1

x

T:

P: x

l/sh−1

1

0

Figura 4.4: Figura ilustrando a estrutura bidimensional tablete. Esta estrutura consiste em umasubmatriz: para a matriz P , tablete é um segmento de genes de tamanho n/2k e um agrupamentode amostras de tamanho sh; para a matriz T , tablete é um segmento de genes de tamanho n/k eum agrupamento de amostras de tamanho sh.

No Algoritmo MAV, a CPT está armazenada na memória compartilhada de cada SM.Com isto, o valor de tg (lembremos que tg é a quantidade de genes alvos utilizada porbloco de execução em paralelo) deve diminuir para que seja possível armazenar todas asvariáveis necessárias para o cálculo da entropia. Como implicação, cada segmento Ti deve sertransferido mais de uma vez para a memória compartilhada, o que aumenta a transferênciaentre as memórias compartilhada e global.

Algoritmo 4 : BuscaExaustivaLocalEntrada: segmento Ti de genes alvos e segmentos Pj1 e Pj2 de genes candidatos a serem

preditores1: para para cada gene alvo t ∈ Ti faça2: para para cada par (p1, p2) ∈ {Pj1 × Pj2} faça3: para para todo tablete Pj1,x, Pj2,x, Ti,x, 0 ≤ x < l/sh faça4: atualizar a CPT5: fim para6: calcular a capacidade de (p1, p2) predizer t ∈ Ti de acordo com a função critério H7: fim para8: fim para

Para melhor entendimento do texto, o algoritmo que funciona com até 30 amostrasdenominaremos de Multi-Amostra-Constante (MAC) e o algoritmo que funciona commais de 30 amostras, de Multi-Amostra-Variável (MAV).

Na próxima seção iremos descrever o Busca Exaustiva considerando o cálculo de trêspreditores.


Bl10

Bl2

BlBlk−1

0P P

0P

T1

Tk−1...T2

T0

...P0

P1 P2

P2k−2 P2k−1

T1,2

P2,2

...T0

P T1

T2 T

k−10

P:

T:

0

0

.

l/sh −1

.

.

0

.

.

.

l/sh −1

Figura 4.5: Regra de acesso dos blocos de execução aos tablete. Uma flecha Pj → Bli indica que obloco Bli acessa o tablete Pj. Uma flecha Ti → Bli indica que o bloco Bli acessa o tablete Ti. Flechascom a mesma cor indicam que os acessos são executados de forma simultânea. Enquanto Pj é copiadopara todos os blocos, Ti é copiado apenas para o bloco Bli. O primeiro passo é copiar os tabletesPj1,0, Pj2,0, Ti,0 (cor preta) da memória global da GPU para a memória compartilhada. Num segundopasso, os tabletes Pj1,1, Pj2,1, Ti,1 (cor verde) são copiados para a memória compartilhada e assimsucessivamente até que os tabletes Pj1,l/sh−1, Pj2,l/sh−1, Ti,l/sh−1 (cor vermelha) sejam copiados paraa memória compartilhada. Após a cópia de todos os tabletes é que podemos calcular a entropia paraos genes alvos de Ti.

4.6 Busca Exaustiva com Três Preditores

Uma busca exaustiva que seleciona em G um subconjunto X de cardinalidade iguala 3 é uma extensão natural do algoritmo Busca Exaustiva com cardinalidade de X iguala 2 (seção 4.3). Embora estruturalmente similar, há algumas características próprias quedevemos descrever:

• A matriz P é particionada em n/3k segmentos.

• Há uma mudança no Algoritmo 3. Com a nova divisão de P , há um aumento depermutações entre os segmentos de P . O Algoritmo 5 reflete esta mudança..

• O número de genes da GRN (n) deve ser múltiplo de três. Para GRNs de tamanhos

4.7 ALGORITMO MULTI-GPU 31

diferentes de múltiplo de 3, genes artificiais podem ser adicionados na GRN.

• A estratégia de cópias dos tabletes de amostras (ver Figura 4.5) também é executadana busca exaustiva com a cardinalidade de X igual a 3. O Algoritmo 6 mostra aBusca Exaustiva Local já com modificações para localizar o melhor subconjunto X decardinalidade igual a 3.

Algoritmo 5 : BuscaExaustivaGlobal 3 Preditores

Entrada: um conjunto G de genes1: para j1← 0 até 3k − 1 faça2: Transferir da memória global para memória compartilhada da GPU os dados de ex-

pressão gênica de Pj1 para todos os blocos3: para j2← j1 até 3k − 1 faça4: Transferir da memória global para memória compartilhada da GPU os dados de

expressão gênica de Pj2 para todos os blocos5: para j3← j2 até 3k − 1 faça6: Transferir da memória global para memória compartilhada da GPU os dados de

expressão gênica de Pj3 para todos os blocos7: Calcular a entropia para todos as triplas de genes candidatos a serem preditores

(p1, p2, p3) ∈ {Pj1 × Pj2 × Pj3}8: fim para9: fim para

10: fim para

Algoritmo 6 : BuscaExaustivaLocal 3 Preditores

Entrada: segmento Ti de genes alvos e segmentos Pj1, Pj2 e Pj3 de genes candidatos a serempreditores

1: para para cada gene alvo t ∈ Ti faça2: para para cada tripla (p1, p2, p3) ∈ {Pj1 × Pj2 × Pj3} faça3: para para todo tablete Pj1,x, Pj2,x, Pj3,x, Ti,x, 0 ≤ x < l/sh faça4: atualizar a CPT5: fim para6: calcular a capacidade de (p1, p2, p3) predizer t ∈ Ti de acordo com a função critério

H7: fim para8: fim para

4.7 Algoritmo Multi-GPU

Com o objetivo de fornecer escalabilidade para o nosso método e melhorar o desempenho,nós estendemos nosso algoritmo de inferência para funcionar em múltiplas GPUs. A ideia ge-ral do algoritmo multi-gpu é particionar o conjunto de genes alvos entre as GPUs disponíveise executar os Algoritmos Busca Exaustiva Local e Busca Exaustiva Global em cada GPU.


Consequentemente, cada GPU é responsável por calcular a entropia para o subconjunto degenes alvos.

Supondo que temos m GPUs denotadas por C0, C1, . . . , Cm−1, o algoritmo multi-GPUpode ser assim descrito:

1. Copiar a matriz P para a memória global de cada GPU. Então, particionar a matriz Tem m supersegmentos de tamanho n/m, denotados por T 0, T 1, . . . , Tm−1 (assumimosque n é um múltiplo m). Copiar cada supersegmento T i para a memória global de Ci,0 ≤ i ≤ m− 1.

2. Lançar k/m blocos de execução por GPU, onde k é o número total de blocos. Deno-tamos por Blij o bloco Blj iniciando em Ci, onde 0 ≤ j ≤ k/m− 1 e 0 ≤ i ≤ m− 1.

3. Executar a Busca Exaustiva Local em cada GPU, de modo que a GPU Ci receba osblocos Bli0, Bli1 . . . , Blik/m−1, que operam sobre os segmentos T i

0, Ti1 . . . , T

in/m−1. Aqui

T ij denota o segmento j que pertence ao supersegmento i.

4. Copiar o valor da entropia calculada e o par de genes preditores de cada gene alvopara a CPU.

A Figura 4.6 mostra uma representação esquemática das principais características doalgoritmo multi-GPU.

4.8 ALGORITMO MULTI-GPUS-MÁQUINAS (MGM) 33

... ... ... ...

T0

... ...

C0 C

i Cm−1

...

T0

T0

10T

0

n/m−1

...

...

Ci

T: T T10 n/m−1

Ti i i

Tn/m−1

m−1TT

0

m−1

1

m−1

T Ti m−1

T10

Tn/m−1

iTi i

0Bl

1Bl Bl

k/m−1

i i i

Figura 4.6: Algoritmo Multi-GPU: uma flecha T i → Ci indica que o supersegmento T i é copiadopara a memória global da GPU Ci; T i

j denota o segmento j pertencente ao supersegmento i; Blijdenota o bloco de execução Blj que começou Ci.

4.8 Algoritmo Multi-GPUs-Máquinas (MGM)

Com o propósito de melhorar ainda mais a escalabilidade do trabalho, desenvolvemos umalgoritmo que funciona em várias máquinas e estas com múltiplas GPUs homogêneas e/ouheterogêneas. Este algoritmo baseia-se no paradigma de programação paralela conhecidocomo mestre-escravo. Este paradigma divide a computação em duas entidades distintas: oprocesso mestre e o conjunto dos processos escravos : o processo mestre é o responsável pordecompor o problema em tarefas, distribuí-las e coletar os resultados dos processos escravos.Os processos escravos obtêm uma tarefa do processo mestre, processa a tarefa recebida eenvia o resultado de volta para o processo mestre.

Sejam M0,M1, . . . ,Mz−1 máquinas, sendo z a quantidade de máquinas disponíveis nocluster. Aqui convém notar que pode haver no cluster uma ou mais máquinas que não têmGPUs disponíveis.

Antes de iniciarmos a inferência da GRN propriamente, executamos um pré-processamentoconstituído de quatro passos e através do qual identificamos a configuração do cluster e fa-zemos a atribuição dos processos entre as máquinas, a saber:

1. Inicialmente o usuário indica quais máquinas pertencem ao cluster fornecendo umalista com z IPs, um para cada máquina.


2. Em seguida executamos um programa de “diagnóstico”, que identifica quais são asmáquinas que têm e as que não têm GPUs disponíveis, e faz a distribuição dos processosentre elas segundo três possíveis configurações e da seguinte forma:

(A) Se todas as máquinas do cluster tiverem GPUs disponíveis, instanciamos z + 1

processos, os quais denominamos processo 0, processo 1, . . . , processo z. Conven-cionamos que o processo 0 corresponde ao processo mestre, que sempre executa namáquina M0. Aqui um processo qualquer sempre executa em uma única e mesmamáquina, e uma máquina sempre executa um único processo; com exceção damáquina M0, que além do processo mestre executa também um processo escravo.A Figura 4.7a) ilustra esse modelo, que correspondente à configuração típica.

(B) Se no cluster houver apenas uma máquina em que não há GPUs disponíveis, entãoela executará o processo mestre e as demais máquinas executarão os processos es-cravos. Nesse caso, um processo qualquer sempre executa em uma única e mesmamáquina, e uma máquina, sem exceção, sempre executa um único processo; por-tanto, aqui instanciamos z processos (denominamos processo 0, processo 1, . . . ,processo z−1), sendo que aqui também convencionamos que o processo 0 corres-ponde ao processo mestre, que sempre executa na máquina M0. A Figura 4.7b)ilustra esse modelo de configuração.

Figura 4.7: Exemplos de configuração de cluster: em a), à esquerda, um exemplo da configuraçãotípica, onde a máquina M0 executa o processo mestre e um processo escravo; em b), à direita, umexemplo da configuração onde a máquina M0 executa apenas o processo mestre (nessa configuraçãosupomos que M0 não possui GPUs disponíveis).

(C) Se no cluster houver mais do uma máquina em que não há GPUs disponíveis,tratamos exatamente como no caso anterior, exceto pelo fato de que a máquinaque hospedará o processo mestre é escolhida aleatoriamente dentre aquelas que


não possuem GPUs disponíveis e as demais máquinas – que não possuem GPUsdisponíveis – são descartadas.

3. Calculamos o número de blocos (k = n/tg) e distribuímos informações sobre a GRNaos escravos como número de genes alvos (n), número de amostras (s), tamanho doagrupamento de amostras (sh), número de genes alvos por bloco (tg), quantização (b)e número de blocos (k). Estas informações são passadas uma única vez aos escravos noinício da execução do algoritmo. Aqui também convém observar que assumimos que asmatrizes de expressão gênica P e T estão armazenadas em todos os processos escravos.

4. Capturamos dos processos escravos o número total de SMs (NumSMs) de cada máquina.Essa informação é armazenada na estrutura de dados denominada lash, descritaadiante. Aqui convém notar que não conhecemos a priori o compute capability dasGPUs antes de o processo mestre começar a execução do algoritmo MGM.

Feita a distribuição dos processos entre as máquinas e conhecido o número total de SMsde cada uma delas, precisamos agora fazer o balanceamento de carga entre os processos, quepode ser estático ou dinâmico. Ele é dito ser estático quando a divisão de tarefas é feitaantes do início da computação, o que implica conhecermos a priori o número de tarefas eo tempo de execução de cada uma delas, o que geralmente é obtido por meio de algumatécnica de estimação. Por outro lado, dizemos que o balanceamento é dinâmico quando adivisão de tarefas é estabelecida durante a realização da computação, o que ocorre quandoo número de tarefas ou o tempo de execução das tarefas é desconhecido antes do início dacomputação. O algoritmo aqui proposto utiliza balanceamento de carga dinâmico.

Para melhor descrever o algoritmo de balanceamento de carga entre os processos, precisa-mos primeiro definir o conceito de tarefa, mas para isso precisamos antes lembrar que os genesalvos estão representados na matriz T e que eles são identificados pelos seus índices, que sãointeiros no intervalo [0..n−1]. Uma tarefa no contexto desse trabalho corresponde a um in-tervalo contíguo de inteiros (denotado por [inicial..final], com 0 ≤ inicial ≤ final ≤ n−1) ea computação necessária para calcular os preditores do subconjunto dos genes alvo represen-tado pelo intervalo [inicial..final]. Nessa notação, inicial e final denotam, respectivamente,os índices do primeiro e último genes alvo no intervalo considerado.

A distribuição das tarefas entre as máquinas é feita pelo processo mestre usando oAlgoritmo 7, denominado Multi-GPUs-Máquinas (MGM). Para melhor compreenderesse algoritmo, precisamos descrever a estrutura de dados do tipo vetor com z posições(lash[0..z-1]) que é usada para controle das tarefas. Ela é armazenada no processomestre e seus elementos são compostos dos seguintes atributos:

• Uma variável nomeada NumSMs ∈ N+, que guarda a quantidade total de SMs de cadamáquina, isto é, lash[i].NumSMs armazena a quantidade total de SMs disponíveisna máquina Mi, 0 ≤ i ≤ z − 1.


• Uma variável nomeada CargaIndividual ∈ N+, responsável por armazenar o valorque multiplicado por NumSMs representará a quantidade de blocos executados numprocesso, isto é, lash[i].CargaIndividual armaneza o número de blocos queserão executados no processo escravo i. Os valores de lash[i].CargaIndividual,para todo i, 0 ≤ i ≤ z − 1, possuem valor inicial igual a 1.

• Uma variável nomeada NumDestin ∈ N+ usada para armazenar o número de ve-zes que o processo mestre destinou tarefas para os processos escravos, isto é,lash[i].NumDestin denota o número de vezes que o processo mestre atribuiualguma tarefa para o processo escravo i.

• Uma variável nomeada Tempo ∈ R+, usada para armazenar o tempo de execução daúltima tarefa em cada processo, isto é, lash[i].Tempo armazena o tempo gastopelo processo escravo i para computar a última tarefa que lhe foi atribuída.

• Uma variável nomeada TempoMedio ∈ R+, usada para armazenar o tempo médio deexecução das tarefas em cada processo, isto é, lash[i].TempoMedio armazena otempo médio gasto pelo processo escravo i para computar as tarefas a ele já atribuídas.Para calcular o tempo médio para cada máquina i, utilizamos as variáveis NumDestine Tempo: TempoMedio = (TempoMedio + Tempo) / NumDestin.

• Uma variável lógica nomeada Estavel usada como flag para indicar o esgotamentoda capacidade das máquinas, isto é, lash[i].Estavel = “TRUE” denota que acarga individual da máquina Mi atingiu seu limite de desempenho, o que significa quequalquer aumento de carga implica em perda de desempenho da máquina. Esse limiteé calculado através de um parâmetro de usuário, denotado por u, que é usado peloalgoritmo para decidir se deve ou não incrementar a variável CargaIndividual.O parâmetro u é uma porcentagem de incremento do tempo da última execução emrelação ao tempo médio de execução, e que serve de limiar para decidir se algoritmocontinua ou não aumentado a carga individual das máquinas.

• Duas variáveis nomeadas Inicial e Final (ambas naturais) que guardam, respecti-vamente, os índices do primeiro e último genes alvo da tarefa, isto é, lash[i].Iniciale lash[i].Final armazenam, respectivamente, os identificadores dos genes iniciale final que definem a tarefa que será enviada ao processo escravo i.

Além do vetor lash[0..z-1], há duas variáveis naturais nomeadas UltimoAlvo ek armazenadas no processo mestre e que permanecem em uma região crítica (recurso doopenMP que permite somente uma thread por vez possa alterar o valor da variável). Avariável UltimoAlvo serve para identificar qual foi o último gene alvo que foi distribuídopara um processo escravo; essa informação serve ao controle e distribuição das tarefas peloprocesso mestre aos processos escravos. A variável k é, lembremos, usada para armazenar onúmero total de blocos lançados pela aplicação.


Uma visão geral do funcionamento do algoritmo de balanceamento de carga pode serassim descrita:

1. O processo mestre, que roda em CPU, distribui 01 (um) bloco por SM para todamáquina onde roda um processo escravo.

2. Os processos escravos ao terminarem sua tarefa devolvem ao processo mestre o melhorsubconjunto de preditores para os genes alvos considerados na tarefa e o tempo gastona execução.

3. O processo mestre testa, para cada máquina, se a diferença entre o tempo de execuçãoe o tempo médio de execução é maior que um percentual pré-definido (um parâmetrode usuário):

- Se o resultado desse teste for “não”, incrementa-se em uma unidade a quantidade deblocos por SM para a máquina, aumentando, portanto, sua carga individual;

- Se o resultado for “sim”, cessa o aumento da carga individual da máquina, estabilizando-a no atual número de blocos por SM.

4. Os passos (2) e (3) são repetidos concorrentemente enquanto houver blocos a distribuir.

Um descrição mais detalhada em pseudo-código pode ser vista no Algoritmo 7. Aqui valeressaltar que uma característica importante desse algoritmo é que ele distribui as tarefasentre as máquinas de forma dinâmica e mantendo a independência na realização das tarefas,finalizando quando não houver mais blocos a serem processados.

Um detalhe que convém aqui observar é que a oitava linha do Algoritmo 7 equivalea uma chamada do Algoritmo 4 (Busca Exaustiva Local do Algoritmo MAV). Ou seja,está implícito que o algoritmo MAV é executado localmente nas máquinas onde rodam osprocessos escravos para realizarem as tarefas a eles enviadas pelo processo mestre.

Na próxima seção iremos analisar a complexidade dos algoritmos propostos neste traba-lho.


Algoritmo 7 : Multi-GPUs-Máquinas (MGM)

Entrada: O conjunto de genes alvos T , número total de blocos (k)1: UltimoAlvo← 02: enquanto k > 0 faça3: para i← 1 até z − 1 em paralelo faça4: lash[i].Inicial← UltimoAlvo5: lash[i].F inal← lash[i].NumSMs× lash[i].CargaIndividual6: UltimoAlvo← lash[i].F inal7: k ← k − lash[i].NumSMs× lash[i].CargaIndividual8: enviar para o processo escravo i os parâmetros lash[i].Inicial e lash[i].F inal9: capturar os resultados (preditores) produzidos pelo processo Mi

10: lash[i].T empo← tempo de execução da máquina Mi

11: lash[i].T empoMedio← (lash[i].T empoMedio+ lash[i].T empo)/lash[i].NumDestin

12: se (|lash[i].T empoMedio− lash[i].T empo|/lash[i].T empoMedio < u) andlash[i].Estavel = false então

13: lash[i].CargaIndividual ++14: else15: lash[i].Estavel = true16: lash[i].CargaIndividual −−17: fim se18: fim para19: fim enquanto

4.9 Algumas Considerações sobre Complexidade

Considerando o Algoritmo MAC, para cada bloco de execução na iteração do loop exteriordo Algoritmo 3, um segmento de genes Pj1 é transferido para a memória. No loop interno,há 2k−j1 iterações para cada valor de j1, onde cada iteração do segmento Pj2 é transferido.Consequentemente, o número de transferências por blocos de execução, considerando as duasestruturas de repetição é:

2k−1∑j1=0

2k − j1 + 1 = 2 + 3 + ...+ (2k + 1) = 2k2 + 3k

Devemos adicionar ao valor acima a transferência de Ti do começo do algoritmo, queneste caso é transferido apenas uma vez. Considerando que há k blocos de execução operandosimultaneamente e que há n/2k genes por segmento, o total de transferências será:

kn

2k(2k2 + 3k + 1) = n (k2 +

3

2k +

1

2)

Consequentemente, podemos ver que o número de transferências da memória global éO(nk2) e que cada gene é transferido O(k2) vezes. Isto significa que aumentando o tamanhodo segmento, há uma diminuição de transferência da memória global.

Se a memória compartilhada não fosse usada, o número total de transferências seria de

4.9 ALGUMAS CONSIDERAÇÕES SOBRE COMPLEXIDADE 39

O(n3), resultando em (n/k)2 mais transferência da memória global. Para n = 4096 genes esegmentos de tamanho igual a 128, resulta em k = 32 blocos, o número de transferências semusar a segmentação será de 128 ∗ 128 = 1.6 ∗ 104 vezes maior. Esta diferença ocorre porquequando um segmento é transferido para a memória compartilhada, os valores de cada geneé usado várias vezes.

Para o Algoritmo MAV, há adicionalmente l/sh leituras referentes ao particionamentodos tabletes das matrizes P e T em relação as amostras. Assim, o total de transferênciasserá:

kn

2k(2k2 + 3k + 1)

l

sh= n (k2 +

3

2k +

1

2)× l

sh

Consequentemente, podemos ver que o número de transferências da memória global éO(nk2l/sh) e que cada gene é transferido O(k2l/sh) vezes. Isto significa que aumentando otamanho do segmento (referente as matrizes P e T ) ou o tamanho do tablete (sh), há umadiminuição de transferência da memória global.

Para a busca exaustiva com 3 preditores e considerando um bloco de execução para cadaiteração do loop exterior do Algoritmo 5, um segmento de genes Pj1 é transferido para amemória. No loop intermediário há 3k− j1 iterações para cada valor de j1 e no loop internohá 3k − j2 iterações para cada valor de j2. Consequentemente, o número de transferênciaspor blocos de execução, considerando as três estruturas de repetição é:

3k−1∑j1=0

3k−1∑j2=j1

3k − j2 + 1 =27

2k3 +

9

2k2

Considerando que há k blocos de execução operando simultaneamente e que há n/3k

genes por segmento e que para cada transferência de Pj1, Pj2 e Pj3, há l/sh transferênciasreferente a leitura dos tabletes das matrizes P e T , o total de transferências será:

kn

3k(27

2k3 +

9

2k2 + 1)

l

sh= n (

9

2k3 +

3

2k2 +

1

3)× l

sh

Consequentemente, podemos ver que o número de transferências da memória global éO(nk3l/sh) e que cada gene é transferido O(k3l/sh) vezes. Isto significa que aumentando otamanho do segmento (referente as matrizes P e T ) ou o tamanho do tablete (sh), há umadiminuição de transferência da memória global.

Se a memória compartilhada não fosse usada, o número total de transferências seria deO(n4), resultando em n sh/(k3l) mais transferência da memória global.

Para o Algoritmo MGM, o número de transferência de dados das memórias comparti-lhada e global permanecem os mesmos para |X| = 2 e |X| = 3. Não incluímos o custo decomunicação na complexidade do algoritmo, pois testes realizados na rede interna da Uni-versidade Federal do ABC (UFABC) mostraram um tempo de resposta média entre doiscomputadores de 0.5 ms utilizando o protocolo ICMP (Internet Control Message Protocol).


O tempo de execução de cada tarefa de um processo escravo é de pelo menos da ordem desegundos. Assim, o tempo de comunicação entre as máquinas não é um gargalo computa-cional para o Algoritmo MGM. Todos os experimentos foram realizados na rede interna daUFABC.

Supomos que tenhamos máquinas iguais com GPUs homogêneas. O Algoritmo MGMprecisa de um tempo constante para calcular experimentalmente o número de blocos queexecutam ao mesmo tempo em cada SM independente da quantidade de máquinas. Isto deve-se ao fato de o algoritmo usar balanceamento dinâmico e o processo coordenador distribuiras tarefas aos processos escravos de forma independente.

Em um mundo teórico, para um número grande de máquinas, pode ser que o AlgoritmoMGM termine de processar todos os blocos antes mesmo de conseguir determinar o númeroideal de blocos a ser executado ao mesmo tempo. Isto pode deixar o algoritmo mais lento secomparado com um número menor de máquinas.

4.10 Implementação

A implementação desse algoritmo paralelo foi feito em CUDA. Aplicamos todas as oti-mizações descritas neste trabalho. No endereço https://sourceforge.net/p/inferencemgpu/localizam-se todos os códigos-fontes e documentação referentes aos algoritmos descritos nestetrabalho.

Foi utilizado o compilador GCC versão 4.6.3, compilador NVCC versão 5.0 e sistemaoperacional Ubuntu 12.04 LTS (Long Term Support).

4.10.1 CPU

A implementação em CPU, que usamos para calcular os speedups, utiliza OpenMP parahabilitar o uso de todos os cores do processador. OpenMP é uma API (Application Pro-gram Interface) designada para implementação de algoritmos paralelos em arquiteturas comprocessadores com memória compartilhada. Dividimos os genes alvos entre as threads, resul-tando em uma boa distribuição de carga entre os cores.

4.10.2 GPU

Também foi utilizado OpenMP para a versão do Algoritmo MGM (seção 4.8). Paratodo processo escravo, há uma thread para que o processo mestre atribua tarefas e recebaos resultados dos processos escravos. Cada thread é criada pelo OpenMP. A variável quecontrola a quantidade de blocos restantes localiza-se em uma região crítica. Esta região foicriada através do OpenMP. As outras variáveis não necessitam de um mecanismo que garantaque apenas um processo escreva em uma região de memória no mesmo espaço de tempo.

https://sourceforge.net/p/inferencemgpu/

4.10 IMPLEMENTAÇÃO 41

OpenMPI é uma biblioteca que implementa o MPI (Message Passing Interface). Este éum sistema de troca de mensagens portátil e padronizado que define a sintaxe e a semânticade um núcleo de rotinas úteis para usuários que desenvolvem programas que necessitam fazertrocas de mensagens. Neste trabalho o OpenMPI foi utilizado para o processo coordenadordistribuir tarefas para os processos escravos (seção 4.8), o que se traduz em um algoritmoque funciona em várias máquinas com múltiplas GPUs. Existe um arquivo que é configuradoqual o IP (Internet Protocol) da máquina executará os processos mestre e escravos.

Foi utilizado OpenMPI versão 1.4.3 com a tag –enable-mpi-thread-multiple na suainstalação/compilação.

Capítulo 5

Experimentos e Resultados

Nós executamos a versão CPU do Algoritmo MAC (número de amostras menor ou iguala 30) em 1 máquina com um processador Intel i7 3930K 3.2 GHz com 6 cores e 32 Gbde memória RAM DDR3. Já para versão CPU do Algoritmo MAV (número de amostrasmaior que 30), utilizamos uma máquina com 1 processador Intel Xeon E5630 2.53 Ghz com4 cores e 8 Gb de memória DDR2. Para a execução da versão GPU do Algoritmo MAC,utilizamos um computador com um processador Intel i7 920 2.6 GHz com 6 Gb de memóriaDDR e 2 placas gráficas NVIDIA GTX 295, com 2 GPUs e 1792 Mb de memória em cadaplaca. Cada GPU dessas contém 30 SMs, estes com 8 cores cada, resultando em um totalde 240 cores por GPU. Para a versão GPU dos Algoritmos MAV e MGM, utilizamos umamáquina com um processador Intel i7 3930K 3.2 GHz com 6 cores e 32 Gb de memóriaRAM DDR3 com 2 placas gráficas GTX 680, sendo que cada uma delas com 1536 coresdistribuídos igualmente entre 8 SMs. Nós usamos Linux Ubuntu 12.04, com o CUDA versão5.0 e o compilador gcc versão 4.6.3 configurado com a opção -O3 em todos os computadoresutilizados nos experimentos.

Em todos os experimentos mensuramos o tempo total da execução dos experimentos.Na versão dos algoritmos para GPU, isto significa incluir no tempo de execução a alocaçãodas variáveis nas memórias da CPU e da GPU e a transferência dos dados entre a CPU e aGPU.

Os dados de amostras binárias usados nos experimentos apresentados neste trabalhoforam gerados usando o simulador Artificial Gene Network (AGN) (Lopes et al., 2011),considerando o modelo de redes booleanas Erdös-Rényi. Este simulador permite controlaro número de genes presentes nas redes e o número de amostras. Nós também executamosexperimentos considerando amostras ternárias, isto é, genes podendo assumir três níveis (-1,0 +1). Para este conjunto de experimentos, nós consideramos a base Plasmodium falciparum(Bozdech et al., 2003), a mesma base considerada em Barrera et al. (2007), cujo valores deexpressão são quantizados em três valores para aplicar a transformação normal (Z-Score).

Nas próximas seções iremos mostrar os resultados obtidos para os Algoritmos MAC (verseção 4.3), MAV (ver seção 4.5) e MGM (ver seção 4.8) usando |X| = 2 e |X| = 3, onde,

43

44 EXPERIMENTOS E RESULTADOS 5.1

lembremos, |X| denota o número de preditores, segundo a notação utilizada no Algoritmo1.

5.1 Supondo Dois Preditores

Nesta seção iremos descrever os resultados para os algoritmos que buscam o subconjunto|X| = 2. Executamos experimentos com os Algoritmos MAC, MAV e MGM. Também exe-cutamos experimentos com o Algoritmo Serial Multi-Thread usando 4 cores, que será escritona próxima seção.

5.1.1 Experimento em CPU Multi-Thread

Nesta seção iremos apresentar os resultados para os experimentos executados em CPU.Utilizamos um processador Intel Xeon E5630 com 4 cores.

Usamos o OpenMP para paralelizar o problema entre os diversos cores da CPU. ATabela 5.1 mostra os tempos de execução para os experimentos executados em CPU comamostras binárias. Executamos experimentos com GRNs de diferentes quantidades de genes(64, 128, 256, 512, 1024, 2048, 4096) e diferentes quantidades de amostras (32, 64 e 128),que correspondem os dados em negrito. O restante dos tempos de execução foram estimadosda seguinte forma: para quantidades maiores de amostras, utilizamos regressão linear e paradiferentes tamanhos de GRN (quantidade de genes), utilizamos uma linha de tendênciautilizando o método dos mínimos quadrados com um polinômio de grau 3, pois o problemada busca exaustiva com |X| = 2 aplicado para todos os genes alvos é da ordem O(n3). Sendon a quantidade de genes e t é o tempo estimado em milissegundos, as equações geradas paraas linhas de tendência foram:

• Experimentos com 32 amostras: t = 0, 001× n3 − 0, 3999× n2 + 203, 6× n− 20258

• Experimentos com 64 amostras: t = 0, 002× n3 + 0, 1× n2 − 231, 6× n+ 32637

• Experimentos com 128 amostras: t = 0, 004× n3 + 0, 638× n2 − 389× n+ 48852

Podemos observar na Tabela 5.1 que ao dobrar a quantidade de amostras, o tempo crescede forma quase linear. Isto deve-se a maior quantidade de operações para atualizar a CPT.Além disso, o algoritmo serial da busca exaustiva utiliza o Algoritmo QuickSort para ordenara CPT e realizar o cálculo da entropia. No caso médio, o QuickSort possui complexidadeassintótica de O(n log(n)), na qual n é o tamanho da entrada (Hoare, 1962). Isto permitededuzir que ao dobrar a quantidade de dados de entrada, o número de operações elementaresaumenta mais se comparado a um algoritmo O(n).

Nas próximas seções iremos mostrar os resultados gerados a partir de experimentos rea-lizados com diversas GPUs para os Algoritmos MAC, MAV e MGM.

5.1 SUPONDO DOIS PREDITORES 45

Tabela 5.1: Tempo de execução para amostras binárias utilizando o Algoritmo Serial Multi-Thread.A coluna mais a esquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se aquantidade de genes). As linhas e colunas em negrito indicam os tempos de execução feitos em CPUcom 4 cores utilizando amostras binárias. O restante dos dados foram estimados usando regressãolinear para as amostras e uma linha de tendência com polinômio de grau 3 para o tamanho dasGRNs. A primeira linha de cima para baixo indica a quantidade de amostras nos experimentos.

Tamanho da GRN 32 a. 64 a. 128 a. 256 a. 512 a. 1024 a.64 230 ms 459 ms 960 ms 1.9 s 3.8 s 7.7 s128 1.7 s 3.6 s 7.6 s 15 s 30 s 62 s256 13 s 28 s 60 s 2.04 min 4.11 min 8.28 min512 1.75 min 3.76 min 8.31 min 17.08 min 34.7 min 69.94 min1024 14.11 min 31.76 min 1.19 h 2.47 h 5.03 h 10.17 h2048 2.02 h 4.52 h 9.59 h 19.7 h 39.92 h 80.35 h4096 17.35 h 1.51 dia 3.27 dias 6.67 dias 13.5 dias 27.16 dias8192 6.07 dias 12.78 dias 25 dias 50.19 dias 100.41 dias 200.86 dias16384 49.7 dias 102.07 dias 201 dias 404.25 dias 808 dias 1610 dias

5.1.2 Experimentos com Algoritmo Multi-Amostra-Constante (MAC)

Nós executamos apenas um experimento para avaliar o desempenho do Algoritmo MACse comparado com o método em CPU. Para este experimento, o método em CPU foi exe-cutado em uma máquina com 6 cores e configurado para utilizar 30 amostras. Para testescom GPUs, utilizamos bases de dados com diferentes tamanhos de GRNs (1024, 2048, 4096,8192). Usamos 2 GPUs GTX 295, cada uma com 2 chips, totalizando 4 GPUs GTX 295.

As Tabelas 5.2, 5.3 e 5.4 mostram os tempos de execução médio para cada experimento(3 execuções para cada experimento) considerando 32, 64 e 128 genes alvos por bloco paraamostras binárias. É possível observar que para um número fixo do tamanho da GRN, aoaumentar o número de genes alvos por bloco resulta em um menor tempo de execução. Istoocorre porque quanto maior o número de genes processados por bloco, maior a quantidadede genes processados em paralelo em cada bloco, o que se traduz em um menor tráfegoentre as memórias global e compartilhada da GPU. Experimentos com tg > 128 não foramfeitos, pois a memória compartilhada da GPU GTX 295 não suporta tamanhos de segmentosmaiores das matrizes de expressão T e G. A pequena quantidade de memória compartilhadaé uma das restrições da arquitetura.

Verificamos que ao aumentar do número de genes alvos por bloco, o tempo de execu-ção diminui, pois o número de transferências da memória global da GPU para a memóriacompartilhada para cada gene alvo é O(n k2) (ver seção 4.9). O número de operações paracalcular a entropia é constante, independente do número de genes alvos por bloco. Isto ex-plica o ganho quase linear em desempenho ao aumentar o tamanho do bloco de 32 para 128genes alvos por bloco.

Os mesmos experimentos executados com amostras binárias também foram executadoscom amostras ternárias (considerando que um gene pode assumir três valores). As Tabelas5.5, 5.6 e 5.7 mostram o tempo de execução médio para cada experimento (três execuçõespara cada experimento) considerando 32, 64 e 128 genes alvos por bloco para amostras


Tabela 5.2: Experimento 1. Tempo de execução para amostras binárias usando 1 GPU GTX 295com a cardinalidade do subconjunto X igual a 2 e utilizando o Algoritmo MAC. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).A segunda coluna da esquerda para a direita apresenta os tempos de execução do algoritmo para aCPU com 6 cores. As outras colunas apresentam os tempos de execução com três experimentos: 32,64 e 128 genes alvos por bloco.

Tamanho da GRN CPU 32 g. alvos/bl 64 g. alvos/bl 128 g. alvos/bl1024 4 min 19,8 s s 20.1 s 9.3 s2048 34.5 min 2.7 min 1.4 min 36 s4096 5 h 16,4 min 11 min 4.8 min8192 1.7 dias 1.82 h 1.07 h 28.6 min

Tabela 5.3: Experimento 2. Tempo de execução para amostras binárias usando 2 GPUs GTX 295com a cardinalidade do subconjunto X igual a 2 e utilizando o Algoritmo MAC. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).A segunda coluna da esquerda para a direita apresenta os tempos de execução do algoritmo para aCPU com 6 cores. As outras colunas apresentam os tempos de execução com três experimentos: 32,64 e 128 genes alvos por bloco.

Tamanho da GRN CPU 32 g. alvos/bl 64 g. alvos/bl 128 g. alvos/bl1024 4 min 19.5 s 20 s 9.2 s2048 34.5 min 1.4 min 1.35 min 35 s4096 5 h 13.35 min 5.6 min 2.4 min8192 1.7 dias 1.1 h 43 min 18.7 min

Tabela 5.4: Experimento 3. Tempo de execução para amostras binárias usando 4 GPUs GTX 295com a cardinalidade do subconjunto X igual a 2 e utilizando o Algoritmo MAC. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).A segunda coluna da esquerda para a direita apresenta os tempos de execução do algoritmo para aCPU com 6 cores. As outras colunas apresentam os tempos de execução com três experimentos: 32,64 e 128 genes alvos por bloco.

Tamanho da GRN CPU 32 g. alvos/bl 64 g. alvos/bl 128 g. alvos/bl1024 4 min 19.5 s 20 s 9.3 s2048 34.5 min 1.3 min 1.3 min 35 s4096 5 h 5.4 min 5.4 min 2.3 min8192 1.7 dias 43 min 22.3 min 9.4 min

ternárias. As mesmas observações feitas para as amostras binárias podem ser feitas nestecaso.

Para demonstrar a dependência do tempo de execução e o número de amostras, condu-zimos um experimento usando 4 GPUs GTX 295 e uma GRN com 4096 genes, variando aquantidade de amostras e genes alvos por bloco. Os resultados (ver Figura 5.3) mostramque há uma dependência linear entre o tempo de execução e a quantidade de amostras paradados de amostras binárias e ternárias.


Tabela 5.5: Experimento 4. Tempo de execução para amostras ternárias usando 1 GPU GTX 295com a cardinalidade do subconjunto X igual a 2 e utilizando o Algoritmo MAC. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).A segunda coluna da esquerda para a direita apresenta os tempos de execução do algoritmo para aCPU com 6 cores. As outras colunas apresentam os tempos de execução com três experimentos: 32,64 e 128 genes alvos por bloco.

Tamanho da GRN CPU 32 g. alvos/bl 64 g. alvos/bl 128 g. alvos/bl1024 4.2 min 48.5 s 28.7 s 13.5 s2048 36.9 min 5 min 3.9 min 53 s4096 5.6 h 33.8 min 24.5 min 7.4 min8192 1.9 dias 4.7 h 2.75 h 45.3 min

Tabela 5.6: Experimento 5. Tempo de execução para amostras ternárias usando 2 GPUs GTX 295com a cardinalidade do subconjunto X igual a 2 e utilizando o Algoritmo MAC. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).A segunda coluna da esquerda para a direita apresenta os tempos de execução do algoritmo para aCPU com 6 cores. As outras colunas apresentam os tempos de execução com três experimentos: 32,64 e 128 genes alvos por bloco.

Tamanho da GRN CPU 32 g. alvos/bl 64 g. alvos/bl 128 g. alvos/bl1024 4.2 min 24.5 s 28 s 13.1 s2048 36.9 min 3.3 s 1.95 min 50 s4096 5.6 h 20.2 min 16 min 3.7 min8192 1.9 dias 2.7 h 1.62 h 29 min

Tabela 5.7: Experimento 6.Tempo de execução para amostras ternárias usando 4 GPUs GTX 295com a cardinalidade do subconjunto X igual a 2 e utilizando o Algoritmo MAC. A coluna mais aesquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes).A segunda coluna da esquerda para a direita apresenta os tempos de execução do algoritmo para aCPU com 6 cores. As outras colunas apresentam os tempos de execução com três experimentos: 32,64 e 128 genes alvos por bloco.

Tamanho da GRN CPU 32 g. alvos/bl 64 g. alvos/bl 128 g. alvos/bl1024 4.2 min 24 s 28 s 12 s2048 36.9 min 1.7 min 1.9 min 49 s4096 5.6 h 13.35 min 8 min 3.5 min8192 1.9 dias 1.6 h 1.06 h 14.5 min

5.1.3 Experimentos com Algoritmo Multi-Amostra-Variável (MAV)

Os experimentos para o Algoritmo MAV foram executados utilizando uma máquina com 2placas gráficas GTX 680. A Tabela 5.8 mostra os tempos de execução para cada experimento(apenas uma execução) considerando 8 genes alvos por bloco, diferentes quantidades deamostras (32, 64, 128, 256, 512 e 1024) e genes (2048, 4096, 8192 e 16384) com discretizaçãobinária. O valor de sh utilizado foi igual a 32 para aproveitar o máximo de eficiência dacoalescência. Experimentos com tg > 8 não foram feitos, pois a memória compartilhada daGPU GTX 680 não suporta tamanhos de segmentos maiores das matrizes de expressão T eG.


Tabela 5.8: Experimento 7. Tempo de execução para amostras binárias usando 2 GPUs GTX 680com a cardinalidade do subconjunto X igual a 2 e utilizando o Algoritmo MAV. A coluna maisa esquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade degenes). As outras colunas apresentam os tempos de execução com apenas um experimento: 32, 64,128, 256, 512 e 1024 amostras e 2048, 4096, 8192 e 16384 genes. A quantidade de genes alvos porbloco é igual a 8.

Tamanho da GRN 32 a. 64 a. 128 a. 256 a. 512 a. 1024 a.2048 20 s 31 s 51 s 1.58 min 3.13 min 6.2 min4096 2.41 min 3.58 min 5.98 min 11.4 min 22.11 min 43.18 min8192 18.07 min 26.21 min 45.6 min 1.45 h 2.73 h 5.32 h16384 2.34 h 3.47 h 6.13 h 11.33 h 21.67 h 42.57 h

O mesmo experimento executado com amostras binárias também foi executado comamostras ternárias. A Tabela 5.9 mostra os tempos de execução para cada experimento(uma execução) considerando 8 genes genes alvos por bloco.

Tabela 5.9: Experimento 8. Tempo de execução para amostras ternárias usando 2 GPUs GTX680 com a cardinalidade do subconjunto X igual a 2 e utilizando o Algoritmo MAV. A coluna maisa esquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade degenes). As outras colunas apresentam os tempos de execução com apenas um experimento: 32, 64,128, 256, 512 e 1024 amostras e 2048, 4096, 8192 e 16384 genes. A quantidade de genes alvos porbloco é igual a 8.

Tamanho da GRN 32 a. 64 a. 128 a. 256 a. 512 a. 1024 a.2048 64 s 1.46 min 2.13 min 3.45 min 6.5 min 12.51 min4096 9.05 min 11.67 min 16.64 min 28 min 52 min 1.64 h8192 1.2 h 1.52 h 2.20 h 3.78 h 6.79 h 13.20 h16384 9.57 h 12.06 h 17.73 h 30.03 h 54.07 h 103.93 h

5.1.4 Experimentos com Algoritmo Multi-GPUs-Máquinas (MGM)

Esta subseção apresenta resultados do algoritmo que funciona em várias máquinas commúltiplas GPUs. Neste experimento foi utilizado duas placas gráficas GTX 680 e duas placasgráficas GTX 295, esta com dois chips cada uma, totalizando 4 GPUs GTX 295. Estealgoritmo (MGM) não foi executado em 1 máquina, pois para isto propusemos o AlgoritmoMAV. O valor de u utilizado em todos os experimentos com o Algoritmo MGM foi igual a20. Este valor foi calculado experimentalmente. Percebemos que há um salto no tempo deexecução quando um SM executa 1 ou mais blocos em relação ao número máximo de blocosexecutados em um mesmo espaço de tempo. Isto pode ser observado na Figura 5.1: se umSM consegue executar apenas 1 bloco em um mesmo espaço de tempo (Figura 5.1a)) e oprocesso escravo receber uma tarefa para executar 2 blocos por SM, os SMs irão apenas umbloco (Figura 5.1b) - blocos de cor vermelha) e somente depois irá executar o bloco restante(Figura 5.1b) - blocos de cor azul), o que aumenta o tempo de execução em mais de 20 %se comparado com o tempo médio de execução do Algoritmo MGM.


Figura 5.1: Explicação do cálculo do valor de u. Em a), os SMs podem processar apenas um blocono mesmo espaço de tempo. Em b), os SMs primeiramente processam os blocos em vermelho parasomente depois executar os blocos em azul. Lembrando que a ordem de execução é determinada peloescalonador da GPU. A ordem de execução dos blocos desta figura é apenas um exemplo didático.

Tabela 5.10: Experimento 9. Tempo de execução para amostras binárias usando 2 GPUs GTX680 e 4 GPUs GTX 295 com a cardinalidade do subconjunto X igual a 2 e utilizando o AlgoritmoMGM. A coluna mais a esquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes). As outras colunas apresentam os tempos de execução com apenas umexperimento: 32, 64, 128, 256, 512 e 1024 amostras e 2048, 4096, 8192 e 16384 genes. A quantidadede genes alvos por bloco é igual a 8.

Tamanho da GRN 32 a. 64 a. 128 a. 256 a. 512 a. 1024 a.2048 26 s 37 s 62 s 1.86 min 3.51 min 6.85 min4096 2.34 min 3.36 min 5.87 min 10.85 min 20.84 min 41.6 min8192 13.89 min 22.17 min 34.2 min 1.06 h 2.02 h 4.02 h16384 1.54 h 2.36 h 4.13 h 7.66 h 14.58 h 29 h

A Tabela 5.10 mostra os resultados das execuções com 8 genes alvos por bloco com amos-tras binárias. O mesmo experimento executado com amostras binárias também foi executadocom amostras ternárias. A Tabela 5.11 mostra os tempos de execução para o experimento(uma execução) considerando 4 genes alvos por bloco, pois a memória compartilhada daGPU GTX 295 não suporta tamanhos de segmentos maiores das matrizes de expressão T eG.

Tabela 5.11: Experimento 10. Tempo de execução para amostras ternárias usando 2 GPUs GTX680 e 4 GPUs GTX 295 com a cardinalidade do subconjunto X igual a 2 e utilizando o AlgoritmoMGM. A coluna mais a esquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes). As outras colunas apresentam os tempos de execução com apenas umexperimento: 32, 64, 128, 256, 512 e 1024 amostras e 2048, 4096, 8192 e 16384 genes. A quantidadede genes alvos por bloco é igual a 4.

Tamanho da GRN 32 a. 64 a. 128 a. 256 a. 512 a. 1024 a.2048 1.76 min 2.5 min 3.88 min 6.89 min 12.91 min 25 min4096 11.18 min 14.91 min 23 min 41.23 min 1.3 h min 2.5 h8192 1.05 h 1.55 h 2.57 h 4.6 h 8.65 h 16.78 h16384 6.75 h 9.98 h 16.47 h 28.26 h 52.82 h 103.04 h


Tabela 5.12: Experimento 11. Tempo de execução para amostras binárias usando 4 GPUs GTX680 distribuídas igualmente entre 2 computadores com a cardinalidade do subconjunto X igual a 2e utilizando o Algoritmo MGM. A coluna mais a esquerda indica os diferentes tamanhos de GRNstestadas (tamanho refere-se a quantidade de genes). As outras colunas apresentam os tempos deexecução com apenas um experimento: 32, 64, 128, 256, 512 e 1024 amostras e 2048, 4096, 8192 e16384 genes. A quantidade de genes alvos por bloco é igual a 8.

Tamanho da GRN 32 a. 64 a. 128 a. 256 a. 512 a. 1024 a.2048 22 s 32 s 54 s 1.6 min 3.1 min 6.25 min4096 2.05 min 3.01 min 5.18 min 9.58 min 18.61 min 37.6 min8192 13.38 min 19.85 min 34.6 min 1.08 h 2.08 h 4.18 h16384 1.43 h 2.14 h 3.75 h 7.07 h 13.65 h 27.1 h

Para mostrar a escalabilidade do Algoritmo MGM com amostras ternárias, o testamos em2 máquinas cada qual possui 2 placas gráficas GTX 680. A Tabela 5.13 mostra os resultadosdeste experimento (apenas uma execução).

A Tabela 5.14 mostra a quantidade de blocos executados ao mesmo tempo para diferentesarquiteturas GPU e quantidade de genes alvos por bloco. Uma observação importante é queos valores apresentados na Tabela 5.14 para o Algoritmo MAV foram calculados a partirdo resultados dos experimentos para o Algoritmo MGM. Não desenvolvemos uma forma decapturar da GPU a quantidade de blocos executados no mesmo espaço de tempo para oAlgoritmo MAV.

Tabela 5.13: Experimento 12. Tempo de execução para amostras ternárias usando 4 GPUs GTX680 distribuídas igualmente entre 2 computadores com a cardinalidade do subconjunto X igual a 2e utilizando o Algoritmo MGM. A coluna mais a esquerda indica os diferentes tamanhos de GRNstestadas (tamanho refere-se a quantidade de genes). As outras colunas apresentam os tempos deexecução com apenas um experimento: 32, 64, 128, 256, 512 e 1024 amostras e 2048, 4096, 8192 e16384 genes. A quantidade de genes alvos por bloco é igual a 8.

Tamanho da GRN 32 a. 64 a. 128 a. 256 a. 512 a. 1024 a.2048 43 s 58 s 1.39 min 2.21 min 4.08 min 8.01 min4096 5.2 min 6.7 min 9.5 min 15.84 min 29.08 min 56.5 min8192 38.88 min 49.18 min 1.19 h 2 h 3.58 h 7.04 h16384 5 h 6.3 h 9.15 h 15.3 h 27.72 h 54.54 h

Tabela 5.14: Número ideal de blocos executados no mesmo espaço de tempo para o algoritmo MGMao terminar o experimento independente do tamanho da GRN e da quantidade de amostras para acardinalidade do subconjunto X igual a 2.

Natureza dos Dados 4 GTX 295 + 2 GTX 680 4 GTX 680Binária A GPU GTX 295 finalizou com 1 bloco/SM

e a GPU GTX 680 finalizou com 5 blo-cos/SM. Utilizou-se 8 genes alvos por bloco.

GTX 680 finalizou com 5 blocos/SM.Utilizou-se 8 genes alvos por bloco.

Ternária A GTX 295 finalizou com 4 blocos/SM ea GTX 680 finalizou com 13 blocos/SM.Utilizou-se 4 genes alvos por bloco.


Nas Tabelas 5.8 e 5.9, referentes ao Algoritmo MAV, e nas Tabelas 5.10, 5.11, 5.12 e 5.13,


referentes ao Algoritmo MGM, é possível observar que ao aumentar o número de amostras,o tempo de execução cresce de forma quase linear. Isto ocorre porque ao dobrar o número deamostras, dobra-se a quantidade de operações para atualizar a CPT e o número de operaçõespara calcular a entropia para cada gene alvo é constante, ou seja, é a mesma independenteda quantidade de genes alvos por bloco. Mesmo com o aumento de tráfego entre as memóriasglobal da GPU e compartilhada, o valor l/sh pode ser pequeno se comparado ao número deblocos k. Lembremos que o número de transferência da memória global dos Algoritmos MAVe MGM são O(n k2 (l/sh)) (ver seção 4.9), ou seja, o valor de k cresce mais rápido que ovalor de l/sh quando o tamanho da GRN tende ao infinito. Além disso, ao ler e escrever emendereços contíguos de memória, conseguimos utilizar a coalescência, que permite melhoraproveito da largura de banda de memória.

O Algoritmo MGM foi possui melhor desempenho para GRNs com 4096 ou mais genes,qualquer quantidade de amostras e dados utilizando amostras binárias se comparado como Algoritmo MAV. Isto deve-se a maior quantidade de SMs que executa a aplicação emparalelo, mesmo que o Algoritmo MGM temha que calcular o número máximo de blocosexecutados ao mesmo tempo em cada SM de cada GPU. O mesmo comentário vale paraexperimentos com o Algoritmo MGM ao utilizar amostras ternárias, exceto para GRNs com8192 genes e número de amostras igual ou maior a 64. Com a redução do número de genesalvos por bloco (de 8 para 4), há um aumento no número de blocos e consequentemente umaumento na quantidade de tráfego entre as memórias global e compartilhada. Além disso,para grandes valores do tamanho da GRN, o Algoritmo MGM precisa de muitos passos(incremento da variável times) para conseguir achar a melhor configuração de execuçãopara cada conjunto de GPUs, ou seja, até encontrar o número ideal de blocos para serexecutado ao mesmo tempo por cada SM e em cada GPU. Quando utiliza-se uma mescla deplacas gráficas (diferentes compute capabilities), as placas de gerações mais novas levam maispassos para calcular o número máximo de blocos por SM, pois possuem maior capacidade dearmazenamento da memória compartilhada e portanto conseguem executar mais blocos nomesmo espaço de tempo. Já no Algoritmo MAV, o escalonador da GPU distribui os blocosde forma que cada SM execute número máximo de blocos ao mesmo tempo.

O Algoritmo MAV possui menor tempo de execução para GRNs com 2048 genes: comosão lançados 256 blocos (GRN com 2048 genes e 8 genes alvos por bloco) e cada GPU GTX680 executa 5 blocos por SM no mesmo espaço de tempo (Tabela 5.14), o Algoritmo MAVnecessita de apenas 4 passos (aqui passos refere-se a quantidade de vezes que a variáveltimes foi incrementada) para inferir uma rede com 2048 genes. Em 4 passos, o AlgoritmoMGM não conseguiu capturar o número ideal de blocos por SM para a GPU GTX 680, poisexecutou 16, 32, 48, 64 blocos para valores de times iguais a 1, 2, 3 e 4, respectivamente.

Podemos observar que o Algoritmo MGM é escalável e cresce de forma quase linear(Tabelas 5.12 e 5.13) quando usado em arquiteturas GPUs com arquiteturas mais novas secomparada com o Algoritmo MAV. Isto deve-se ao fato de usar mais genes alvos por bloco,diminuindo o número de transferência entre as memórias global e compartilhada, e a maior


capacidade de armazenamento na memória compartilhada, que permite executar mais blocosno mesmo espaço de tempo.

5.1.5 Speedups obtidos

Nós também calculamos o speedup obtido com os algoritmos desenvolvidos para GPUs.Definimos speedup sendo o tempo de execução gasto pelo algoritmo paralelizado em CPUdividido pelo tempo de execução gasto em GPU para a mesma instância do problema. AsFiguras 5.2(a) ,5.2(b), 5.2(c) mostram o speedup versus número de genes considerando 32,64 e 128 genes alvos por bloco, respectivamente para amostras binárias e ternárias utilizandoo Algoritmo MAC.

Figura 5.2: (a), (b) e (c): gráfico mostrando speedup versus tamanho da GRN para 32, 64 e 128genes alvos por bloco. Os termos “BIN” e “TER” indicam amostras binárias e ternárias, respecti-vamente. O termo Tg/Bl indica o número de genes alvos por bloco. Figura obtida de Borelli et al.(2013).

Os resultados mostram bons speedups para redes com 2048 genes ou mais genes, especi-almente ao usar 2 ou 4 GPUs. Por exemplo, ao utilizar 4 GPUs para redes com 8192 genes,obtivemos speedups de aproximadamente 55, 110 e 260 quando executados com 32, 64 e 128genes alvos por bloco, respectivamente. Entretanto, o speedup tende a crescer com o aumentode número de genes, pois há um uso mais efetivo de todos os cores da GPU.

O speedup obtido para as amostras ternárias é menor que os experimentos com amos-tas binárias, pois cada thread usa mais variáveis de estado. Isto resulta em um maior usode registradores e consequentemente, um número menor de threads executando ao mesmo


tempo. Entretanto, o speedup obtido é igual a 185 quando executou-se em 4 GPUs e 60 emuma única GPU.

Em relação ao uso de múltiplas GPUs, a Figura 5.2(a) mostra que, para o uso de amostrasbinárias, não há vantagens de usar 2 ou mais GPUs quando temos 32 genes alvos por blocoe GRN com 1024 genes. Com amostras ternárias, a execução com 2 e 4 GPUs possuem omesmo tempo de execução. O mesmo cenário ocorre para redes com 2048 genes ou mais e64 ou 128 genes por bloco, como podemos observar nas Figuras 5.2(b) e 5.2(c).

Figura 5.3: Curvas representando os tempos de execução em função do número de amostras, naqual cada curva corresponde ao número de alvos por bloco (32, 64 e 128). Neste caso, 4 GPUs sãoempregadas para inferir a rede de 4096 genes. Os termos “BIN” e “TER” indicam amostras bináriase ternárias, respectivamente. O termo Tg/Bl indica o número de genes alvos por bloco. Figura obtidade Borelli et al. (2013).

Este resultado pode ser explicado considerando que o número de blocos para representartodos os genes alvos. Por exemplo, considerando 32 genes alvos por bloco, usamos 32, 64 e128 blocos para redes com 1024, 2048 e 4096 genes, respectivamente. Nestes experimentos,nós utilizamos GPUs com 30 SMs, o que simultaneamente executa um número de blocosmúltiplos de 30. Com 32 genes por bloco e 1024 genes, os speedups com 1, 2 e 4 GPUs sãoos mesmos. Neste caso, é claro que com 1 GPU, 2 SMs executam 2 blocos simultaneamenteenquanto os outros SMs executam 1 único bloco sem a penalidade de desempenho. Já asGRNs com 2048 genes, são lançados 64 blocos e existe um ganho de desempenho com 2 oumais GPUs. Neste caso, com 1 GPU, muitos SMs executaram 3 blocos, na qual pode nãoter sido executados simultaneamente. Consequentemente, foi necessário quase o dobro dotempo se comparado com a execução com 2 GPUs.

Para redes com grandes números de genes, como a de 8192 genes, o uso de múltiplasGPUs fornece um importante ganho de speedup. Por exemplo, considerando 128 genes porbloco e usando 4 GPUs, (Figura 5.2(c)), o speedup foi de duas vezes maior que obtido usando


2 GPUs e três vezes maior se comparado quando utilizado apenas 1 GPU ao usar amostrasbinárias. No caso com amostras ternárias e considerando as mesmas configurações, o speedupobtido para 4 GPUs foi duas vezes maior que o obtido usando 2 GPUs e 3.1 vezes maior queo obtido usando 1 GPU.

Também calculamos o speedup para o Algoritmo MAV. As Figuras 5.4 e 5.5 mostramgráficos que comparam diferentes tamanhos de GRNs (2048, 4096, 8192, 16384) com di-ferentes números de amostras (32, 64, 128, 256, 512 e 1024) para quantizações binárias eternárias, respectivamente. Aqui o speedup foi calculado a partir do Algoritmo CPU com 4cores. Podemos observar que o speedup cresce ao aumentar a quantidade de amostras. Isto édevido ao fato que o Algoritmo GPU consegue otimizar a leitura dos segmentos de amostras,mas o speedup tende a se estabilizar com o aumento de amostras pois a razão l/sh cresce, oque impacta no número de transferências entre as memórias global e compartilhada.

Figura 5.4: Gráfico mostrando speedup versus quantidade de amostras para GRNs com 2048, 4096,8192 e 16384 genes com experimentos utilizando amostras binárias e ternárias ao aplicar o Algo-ritmo MAV. O termo “BIN” indica amostras binárias.

Como não fizemos experimentos com amostras ternárias para o Algoritmo em CPU,calculamos o speedup usando os tempos em CPU das amostras binárias. Com o aumento dememória para armazenar a CPT, o Algoritmo MAV executa menos blocos no mesmo espaçode tempo em cada SM se comparado com o mesmo algoritmo com dados binários, o quediminui o speedup. Isto pode ser observado na Tabela 5.14.

A Figura 5.6 mostra os speedups para o Algoritmo MGM utilizando amostras binárias eternárias. Estes speedups foram calculados utilizando dados capturados com 2 placas GTX680 e 4 placas GTX 295. Os mesmos comentários feitos sobre as Figuras 5.4 e 5.5 tambémsão pertinentes a Figura 5.6. Podemos observar que o Algoritmo MGM com quantizaçãoternária possui valores de speedup menores que o Algoritmo MAV para as mesmas instâncias


Figura 5.5: Gráfico mostrando speedup versus quantidade de amostras para GRNs com 2048, 4096,8192 e 16384 genes com experimentos utilizando amostras binárias e ternárias ao aplicar o Algo-ritmo MAV. O termo “TER” indica amostras ternárias.

Figura 5.6: Gráfico mostrando speedup versus quantidade de amostras para GRNs com 2048, 4096,8192 e 16384 genes com experimentos utilizando amostras binárias usando o Algoritmo MGM.Utilizamos 2 placas gráficas GTX 680 e 4 placas gráficas GTX 295. Os termos “BIN” e “TER”indicam amostras binárias e ternárias, respectivamente.

do problema. Isto deve-se ao fato de utilizar somente 4 genes alvos por bloco. Já para aquantização binária, o Algoritmo MGM foi superior ao Algoritmo MGM. Isto deve-se aofato de possuir mais SMs executando a aplicação com a mesma quantidade de genes alvospor bloco.


Figura 5.7: Gráfico mostrando speedup versus quantidade de amostras para GRNs com 2048, 4096,8192 e 16384 genes com experimentos utilizando amostras binárias usando o Algoritmo MGM.Utilizamos 4 placas gráficas GTX 680, distribuídas em 2 computadores. Os termos “BIN” e “TER”indicam amostras binárias e ternárias, respectivamente.

A Figura 5.7 mostra os speedups para o Algoritmo MGM utilizando amostras binárias eternárias. Estes speedups foram calculados utilizando dados capturados com 4 placas GTX680 distribuídas entre 2 computadores. Os mesmos comentários feitos sobre as Figuras 5.4e 5.5 também são pertinentes a esta figura. Para ambas as quantizações, estes experimentosforam lineares se comparado ao Algoritmo MAV. Isto deve-se ao fato de possuir mais SMsexecutando a aplicação com a mesma quantidade de genes alvos por bloco e a mesma ca-pacidade de processamento das placas gráficas usada para o Algoritmo MAV. Isto mostraque o Algoritmo MGM é escalável, ou seja, o tempo de execução diminui com o aumento deGPUs.

5.1.6 Comparação entre os Algoritmos MAC, MAV e MGM

Esta seção possui alguns comparativos entre os Algoritmos MAC, MAV e MGM. Secompararmos as Tabelas 5.8 (Algoritmo MAV usando amostras binárias e 2 GPUs GTX680) e 5.3 (Algoritmo MAC usando amostras binárias e 2 GPUs GTX 295), percebemos queos tempos de execução são parecidos (para 32 amostras e 128 genes alvos por bloco), apesarda GPU GTX 680 ser mais rápida que a GPU GTX 295. Mas, o Algoritmo MAC transfereapenas uma vez o segmento Ti da memória global para memória compartilhada da GPU enão possui transferências de tabletes.

Se compararmos as Tabelas 5.12 (Algoritmo MGM usando amostras binárias e 4 GPUsGTX 680) e 5.4 (Algoritmo MAC usando amostras binárias e 4 GPUs GTX 295), percebemosque os tempos de execução do Algoritmo MAC é menor (para 32 amostras e 128 genes

5.2 SUPONDO TRÊS PREDITORES 57

alvos por bloco), apesar da GPU GTX 680 ser mais rápida que a GPU GTX 295. Mas, oAlgoritmo MAC transfere apenas uma vez o segmento Ti da memória global para memóriacompartilhada da GPU e não possui transferências de tabletes, além do Algoritmo MGMter que calcular o número máximo de blocos que cada SM pode executar no mesmo espaçode tempo.

Os mesmos experimentos foram feitos para amostras binárias foram feitos com amostrasternárias. Se compararmos as Tabelas 5.9 (Algoritmo MAV usando amostras ternárias e 2GPUs GTX 680) e 5.6 (Algoritmo MAC usando amostras ternárias e 2 GPUs GTX 295),percebemos que os tempos de execução do Algoritmo MAC são menores (para 32 amostrase 128 genes alvos por bloco), apesar da GPU GTX 680 ser mais rápida que a GPU GTX295. Mas, o Algoritmo MAC transfere apenas uma vez o segmento Ti da memória globalpara memória compartilhada da GPU e não possui transferências de tabletes. Além disso, oAlgoritmo MAV guarda a CPT na memória compartilhada, o que se traduz em menor númerode blocos executados no mesmo espaço de tempo em cada SM. Os mesmos comentários valemquando comparamos experimentos com amostras ternárias e a utilização de 4 GPUs (Tabelas5.13 e 5.7).

5.2 Supondo Três Preditores

Esta seção apresenta os resultados para os algoritmos que buscam o melhor subconjuntode cardinalidade igual a três. Para este tipo de busca, não existe um algoritmo desenvolvidopara até 30 amostras, pois novas tecnologias de extração de dados permitem extrair experi-mentos com grandes quantidades de amostras (Lister et al., 2009; Metzker, 2010). Tambémnão conseguimos rodar experimentos em CPU para poder calcular o speedup, pois o algoritmoem CPU utiliza recursão para calcular todos as possíveis triplas para cada gene alvo. Aodistribuir a computação dos genes alvos entre os cores do processador, o sistema operacionalprecisava usar a memória virtual (swap) para guardar as recursões que eram processadas, oque torna inviável o uso deste algoritmo em CPU.

Nós utilizamos bases de dados com diferentes tamanhos de GRNs (360, 720, 2160) equantidade de amostras (36, 72, 108, 360, 720).

5.2.1 Experimentos com Multi-Amostra-Variável (MAV)

Estes experimentos foram executados com uma máquina com 2 placas gráficas GTX 680.Em todos os experimentos desta seção usamos o valor de sh igual a 36. A codificação destealgoritmo obriga que o valor de sh seja múltiplo da quantidade de genes alvos por bloco. Istopermite otimizar a transferência de dados das memória global para memória compartilhadaao utilizar a coalescência. Não executamos este algoritmo variando a quantidade de GPUs emuma máquina pois experimentos da seção 5.1.5 (Algoritmo MAC) mostram que os algoritmosparalelos propostos são quase lineares de acordo com a quantidade de GPUs quando há um


aumento do tamanho (quantidade de genes) da GRN. Também não executamos experimentoscom o Algoritmo MAC com três preditores, pois o Algoritmo MAC possui uma limitaçãoem relação ao número de amostras ser igual ou menor a 30.

A Tabela 5.15 mostra os resultados para experimentos com amostras binárias. Utilizamos9 genes alvos por bloco. Experimentos com tg > 9 não foram feitos, pois a memória com-partilhada da GPU GTX 680 não suporta tamanhos de segmentos maiores das matrizes deexpressão T e G. A Tabela 5.16 mostra os resultados para experimentos com amostras ter-nárias. Utilizamos 6 genes alvos por bloco. Experimentos com tg > 6 não foram feitos, poisa memória compartilhada da GPU GTX 680 não suporta tamanhos de segmentos maioresdas matrizes de expressão T e G.

Tabela 5.15: Experimento 13. Tempo de execução para amostras binárias usando 2 GPUs GTX680 com a cardinalidade do subconjunto X igual a 3 e utilizando o Algoritmo MAV. A coluna maisa esquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade degenes). As outras colunas apresentam os tempos de execução com apenas um experimento: 36, 72,108, 360, 720 amostras e 360, 720, 2160. A quantidade de genes alvos por bloco é igual a 9.

Tamanho da GRN 36 a. 72 a. 108 a. 360 a. 720 a.360 55 s 1.31 min 1.7 min 4.38 min 8.2 min720 12.26 min 18.34 min 23.64 min 57.91 min 1.95 h2160 18.5 h 25 h 31.4 h 81.87 h 166.24 h

Tabela 5.16: Experimento 14. Tempo de execução para amostras ternárias usando 2 GPUs GTX680 com a cardinalidade do subconjunto X igual a 3 e utilizando o Algoritmo MAV. A coluna maisa esquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade degenes). As outras colunas apresentam os tempos de execução com apenas um experimento: 36, 72,108, 360, 720 amostras e 360, 720, 2160. A quantidade de genes alvos por bloco é igual a 6.

Tamanho da GRN 36 a. 72 a. 108 a. 360 a. 720 a.360 3.71 min 4.67 min 5.55 min 13.01 min 21.2 min720 59.6 min 1.34 h 1.84 h 3.45 h 6.11 h2160 100 h 151.1 h 172.28 h 308.04 h 569.77 h

Em ambos os experimentos podemos observar que ao aumentar o número de amostras,o tempo de execução cresce de forma quase linear. Isto ocorre porque ao dobrar o númerode amostras, dobramos a quantidade de operações para atualizar a CPT e a quantidade deoperações para calcular a entropia para cada gene alvo é constante. Mesmo com o aumentode tráfego entre as memórias global e compartilhada, o valor l/sh pode ser pequeno secomparado ao número de blocos k. Lembremos que o número de transferências da memóriaglobal deste Algoritmo é O(n k3 (l/sh)) (ver seção 4.9), ou seja, o valor de k cresce maisrápido que o valor de l/sh. Além disso, ao ler e escrever em endereços contíguos de memória,conseguimos utilizar a coalescência, que permite melhor aproveito da largura de banda dememória da GPU.

5.2 SUPONDO TRÊS PREDITORES 59

5.2.2 Experimentos com Multi-GPUs-Máquinas (MGM)

Esta subseção apresenta resultados do Algoritmo MGM. Neste experimento foi utilizadoduas placas gráficas GTX 680 e duas placas gráficas GTX 295, esta com dois chips cadauma, totalizando 4 GPUs GTX 295. Este algoritmo não foi executado em 1 máquina, poispara isto propusemos o Algoritmo MAV.

O valor sh utilizado foi 36 para amostras binárias e ternárias. A Tabela 5.17 mostra osresultados das execuções com 6 genes alvos por bloco para amostras binárias. Experimentoscom tg > 6 não foram feitos, pois a memória compartilhada da GPU GTX 295 não suportatamanhos de segmentos maiores das matrizes de expressão T e G.

Tabela 5.17: Experimento 15. Tempo de execução para amostras binárias usando 2 GPUs GTX680 e 4 GPUs GTX 295 com a cardinalidade do subconjunto X igual a 3 e utilizando o AlgoritmoMGM. A coluna mais a esquerda indica os diferentes tamanhos de GRNs testadas (tamanho refere-se a quantidade de genes). As outras colunas apresentam os tempos de execução com apenas umexperimento: 36, 72, 108, 360, 720 amostras e 360, 720, 2160. A quantidade de genes alvos porbloco é igual a 6.

Tamanho da GRN 36 a. 72 a. 108 a. 360 a. 720 a.360 2.11 min 3.28 min 4.43 min 12.54 min 24.01 min720 16.48 min 25.84 min 35.1 min 1.65 h 3.17 h2160 15.32 h 23.71 h 32.05 h 43.26 h 83.11 h

Experimentos utilizando amostras ternárias foram executados com 3 genes alvos porbloco, pois a memória compartilhada da GPU GTX 295 não suporta tamanhos de segmentosmaiores das matrizes de expressão T e G. Um experimento utilizando uma GRN com 720genes e 36 amostras ternárias demorou cerca de 6.75 h. Se comparamos o mesmo experimentocom o Algoritmo MAV (Tabela 5.16), percebemos que aquele é quase 7 vezes mais lento eainda utiliza maior número de GPUs. Como a quantidade de genes alvos por bloco reduziuem 3 vezes se comparado com o Algoritmo MAV, a quantidade de transferência de dadosirá aumentar em 27 vezes, pois a complexidade do Algoritmo MAV é O(n k3 (l/sh)). Istoafetará os valores de speedup. Como os experimentos para GRNs com maiores quantidadede genes demorariam em torno de dias, optamos por não executá-los.

Para mostrar a escalabilidade do Algoritmo MGM, nós o executamos em 2 máquinas comcada uma possuindo 2 GPUs GTX 680 para amostras binárias e ternárias. A Tabela 5.18mostra os resultados das execuções com 6 genes alvos por bloco para amostras ternárias.A Tabela 5.19 mostra os resultados para amostras binárias utilizando 9 genes alvos porbloco. Experimentos com maior quantidade de genes alvos por bloco não foram feitos, poisa memória compartilhada da GPU GTX 680 não suporta tamanhos de segmentos maioresdas matrizes de expressão T e G.

A Tabela 5.20 mostra a diferença de quantidade de blocos executados ao mesmo tempopara diferentes arquiteturas GPU e quantidade de genes alvos por bloco. Uma observaçãoimportante é que os valores apresentados na Tabela 5.20 para o Algoritmo MAV foram cal-


Tabela 5.18: Experimento 16. Tempo de execução para amostras ternárias usando 4 GPUs GTX680 distribuídas igualmente entre 2 computadores com a cardinalidade do subconjunto X igual a3 e utilizando o Algoritmo MGM. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). As outras colunas apresentam os temposde execução com apenas um experimento: 36, 72, 108, 360, 720 amostras e 360, 720, 2160. Aquantidade de genes alvos por bloco é igual a 6.

Tamanho da GRN 36 a. 72 a. 108 a. 360 a. 720 a.360 3.76 min 4.71 min 5.6 min 13.1 min 21.35 min720 44.64 min 1.02 h 1.4 h 2.6 h 3.41 h2160 59.54 h 79.74 h 91.63 h 166.50 h 299.88 h

Tabela 5.19: Experimento 17. Tempo de execução para amostras binárias usando 4 GPUs GTX680 distribuídas igualmente entre 2 computadores com a cardinalidade do subconjunto X igual a3 e utilizando o Algoritmo MGM. A coluna mais a esquerda indica os diferentes tamanhos deGRNs testadas (tamanho refere-se a quantidade de genes). As outras colunas apresentam os temposde execução com apenas um experimento: 36, 72, 108, 360, 720 amostras e 360, 720, 2160. Aquantidade de genes alvos por bloco é igual a 9.

Tamanho da GRN 36 a. 72 a. 108 a. 360 a. 720 a.360 39 s 56 s 1.18 min 2.95 min 5.55 min720 7.43 min 11.06 min 14.23 min 34.86 min 68.55 min2160 9.9 h 13.34 h 16.77 h 42.05 h 84.74 h

culados a partir do resultados dos experimentos para o Algoritmo MGM. Não desenvolvemosuma forma de capturar da GPU a quantidade de blocos executados no mesmo espaço detempo para o Algoritmo MAV.

Tabela 5.20: Número ideal de blocos executados no mesmo espaço de tempo para o algoritmo MGMao terminar o experimento independente do tamanho da GRN e da quantidade de amostras para acardinalidade do subconjunto X igual a 3.

Natureza dos Dados 4 GTX 295 + 2 GTX 680 4 GTX 680Binária A GPU GTX 295 finalizou com 2 blo-

cos/SM e a GPU GTX 680 finalizou com6 blocos/SM. Utilizou-se 6 genes alvos porbloco.


Ternária A GTX 295 finalizou com 7 blocos/SM ea GTX 680 finalizou com 21 blocos/SM.Utilizou-se 3 genes alvos por bloco.


Podemos observar as Tabelas 5.15 e 5.16, referentes ao Algoritmo MAV e as Tabelas5.17, 5.18, 5.19, referentes ao Algoritmo MGM, que ao aumentar o número de amostras, otempo cresce de forma quase linear. Os mesmo comentários para os experimentos da seção5.1 ( Experimentos supondo dois preditores) são pertinentes aos experimentos desta seção.Lembremos que o número de transferência da memória global dos Algoritmos MAV e MGMsupondo três preditores são O(n k3 (l/sh)) (ver seção 4.9), ou seja, o valor de k cresce maisrápido que o valor de l/sh quando o tamanho da GRN tende ao infinito.

O Algoritmo MGM somente foi escalável ao usar 4 GPUs igualmente distribuídas entre

5.4 DETALHES DE IMPLEMENTAÇÃO 61

duas máquinas, independente da quantização das amostras utilizadas nos experimentos. Istodeve-se a redução de genes alvos por bloco nos experimentos ao utilizar GPUs heterogêneas,o que aumenta a quantidade de transferências entre as memórias global e compartilhada daGPU. Devido a redução de genes alvos por bloco, houve um aumento de blocos executadosno mesmo espaço de tempo (Tabela 5.20), mas não foi suficiente para diminuir o tempode execução dos experimentos. Isto comprova o alto custo computacional das transferênciasentre as memórias global e compartilhada da GPU. É preferível diminuir as transferênciasentre as memórias global e compartilhada da GPU ao invés de lançar mais blocos.

GRNs com 360 e 720 genes ao serem inferidas pelo Algoritmo MGM com GPUs hete-rogêneas possuem maior tempo de execução se comparado com o Algoritmo MAV para amesma instância do problema. Isto deve-se ao fato de GRNs com 360 e 720 genes seremparticionadas em 60 e 120 blocos (6 genes alvos por bloco), respectivamente. Mas, 4 GPUsGTX 295 e 2 GPUs GTX 680 possuem 136 SMs ao total. Logo, o número de SMs é maiorque a quantidade de blocos a ser executado e alguns SMs ficam ociosos, o que diminui ospeedup do Algoritmo MGM.

5.3 Detalhes de Implementação

O Algoritmo MGM utilizou MPI para implementar a comunicação entre os processosmestre e escravo e openMP para o processo mestre controlar os processos escravos de formaindependente. No processo mestre, é lançada uma thread para cada processo escravo. Istopermite gerenciar de forma independente os processos escravos. Foi implementado uma regiãocrítica na variável que controla a quantidade restante de blocos a serem executados.

Os arquivos com o código CUDA devem ser separados dos arquivos com o código decomunicação entre os processos e gerenciamento de balanceamento de carga. Isto deve-se aofato da necessidade de dois compiladores para gerar o executável: o primeiro compilador é ompicc, para gerar o código relativo ao MPI e o compilador nvcc, relativo ao código CUDA. Édesejável passar o parâmetro -fopenmp para o compilador do C (acoplado ao nvcc) entenderas diretivas de compilação do openMP e o parâmetro -arch para especificar a arquitetura(compute capability) das GPUs.

5.4 Desafios de Implementação

No decorrer do trabalho, houve alguns desafios a serem vencidos. Um deles foi adaptaro código-fonte com alocação dinâmica da memória compartilhada para que fosse possívelexecutar em várias máquinas. No contexto da GPU, alocação dinâmica consiste em calculara quantidade de memória a ser utilizada antes de lançar o kernel e alocar as variáveis usandosomente um ponteiro que referencia o início da memória compartilhada. Isto permite que osparâmetros do problema sejam configurados após a compilação do código-fonte. Apenas os


Algoritmos MGM e MAV possuem este tipo de implementação.No Algoritmo MAC, os parâmetros são configurados antes da compilação do código-

fonte. Para cada possibilidade de configuração de parâmetros, há um executável diferente.Isto dificultava tanto execução de experimentos quanto a distribuição de tarefas entre váriasmáquinas. Visando trabalhos futuros, com a alocação dinâmica é possível conseguir usarparâmetros diferentes em máquinas diferentes.

Outro problema foi tornar o openMPI thread safe. Para uma aplicação ser threadsafe, esta deve suportar a chamada de funções por múltiplas threads concorrentemente,sem apresentar nenhum erro de saída ou problemas com condições de corrida ou deadlocks(Chowdappa et al., 1994). O openMPI por padrão não possui suporte ao padrão POSIXreferente a threads. Para isto, houve a necessidade de recompilar o openMPI para que fossepossível executar o Algoritmo MGM, pois cada thread é responsável por distribuir tarefas ecoletar resultados dos processos escravos (ver seção 4.8).

Capítulo 6

Conclusões

6.1 Considerações Finais

Neste trabalho nós propusemos um algoritmo que funciona em várias máquinas commúltiplas GPUs que permite inferir GRNs com predição multivariada em tempos menoresse comparado com algoritmos CPUs multi-core. A principal contribuição deste algoritmo épermitir a inferência de GRNs usando busca exaustiva utilizando grandes bases de dadosem um tempo razoável.

O Algoritmo MAC permitiu inferir redes de regulação gênicas (GRN) com prediçãomultivariada em um tempo muito menor se comparado com o algoritmo multi-core CPU.Por exemplo, gastou-se aproximadamente uma semana para inferir uma GRN com 8192genes usando o algoritmo busca exaustiva em uma CPU com 6 cores, enquanto gastou-seem torno de uma hora e meia utilizando uma GPU e 128 genes alvos por bloco com oAlgoritmo MAC. Utilizando quatro GPUs com as mesmas configurações, gastou-se apenastrinta minutos, o que indica um speedup da ordem de centenas.

O Algoritmo MAV permitiu inferir GRNs com mais de 30 amostras e apresentou umspeedup da ordem de centenas (quase de milhares). A estrutura tablete permitiu contornaro problema da pequena quantidade da memória compartilhada na GPU e assim permitiuque placas gráficas com diversos compute capabilities executem a busca exaustiva.

O Algoritmo MGM conseguiu speedups da ordem dos milhares. Por exemplo, gastaram-se aproximadamente 27 horas para inferir GRNs com 16384 genes e 1024 amostras e 14minutos para inferir uma GRN com 8192 genes e 32 amostras. Usando o Algoritmo 4 cores,estima-se que demoraria 1610 dias para inferir uma GRN com 16384 genes e 1024 amostras.Teoricamente, mesmo usando 10 máquinas 4 cores para executar o Algoritmo CPU-Multi-Thread e assumindo que o Algoritmo CPU-Multi-Thread é escalável, seria inviável esperaralgumas centenas de dias.

O Algoritmo MGM também permitiu inferir GRNs com 3 preditores a um tempo relati-vamente baixo, o que antes era inviável executar em CPU. Para arquiteturas de GPUs maisnovas, o Algoritmo MGM mostrou-se escalável.

63

64 CONCLUSÕES

Outra importante observação é que o Algoritmo MGM é escalável, uma vez que o speedupaumenta de modo quase linear com o aumento da quantidade de GPUs. Os resultadossugerem uma solução eficiente e de baixo custo para pesquisadores que precisam inferirGRNs de tamanhos reais (na ordem de milhares) para dados de transcriptoma em um temporazoável, considerando relações multivariadas (N-para-1).

O Algoritmo MGM também utiliza uma nova estratégia de distribuição de carga emGPUs homogêneas/heterogêneas sem conhecer o compute capability das GPUs, mostrandoque é possível desenvolver algoritmos que se adaptem a máquinas heterogêneas com resul-tados encorajadores e que apresentam um comportamento escalável. O uso de clusters deGPUs possui um custo relativamente baixo se comparado a supercomputadores.

Além disso, este trabalho apresenta uma prova de princípio, mostrando que é possívelparalelizar um algoritmo de busca exaustiva baseado em arquiteturas GPUs com resultadosencorajadores. Embora o nosso foco seja no problema da inferência de GRNs, a técnica debusca exaustiva em GPUs desenvolvidas aqui pode ser aplicada com pequenas adaptaçõesem outros problemas combinatoriais.

6.2 Sugestões para Pesquisas Futuras

Neste trabalho propusemos uma estratégia de distribuição de carga em GPUs homogê-neas ou heterogêneas. Em trabalhos futuros, podemos estudar possibilidades de generalizarestas estratégias de distribuição de carga em um conjunto de outros problemas computaci-onais. Outro trabalho futuro é propor uma distribuição de carga entre CPUs e GPUs paraminimizar o tempo de execução.

Podemos também tentar criar um algoritmo que consiga variar parâmetros do problemacomo a quantidade de genes alvos em cada bloco ou a quantidade de amostras a ser ar-mazenada na memória compartilhada a fim de que um processo escravo consiga de formaindependente achar os melhores parâmetros de execução para as placas que o processo es-cravo controla. Esta estratégia aplicada em GRNs com milhares de genes pode aumentarainda mais o speedup apresentado neste trabalho.

Outra estratégia de distribuição de carga é executar problemas menores para tentardescobrir os parâmetros de execuçção ideais para o menor tempo de execução antes de iniciaro algoritmo. No decorrer da execução do algoritmo, tentar variar os parâmetros calculadosantes da execução para verificar de fato se a solução inicial é realmente a ideal.

Outros tipos de dados estão se tornando cada vez mais disponíveis, como por exemplo,dados de interação proteína-proteína (proteomics) e de processos químicos envolvendo me-tabólitos (metabolomics). Pode-se adaptar este trabalho para inferir as relações em outrostipos de dados.

Referências Bibliográficas

Alberts et al. (2002) B. Alberts, A. Johnson, J. Lewis, M. Raff, K. Roberts e P. Walter.Molecular biology of the cell. Taylor & Francis Books, Inc., New York, 4th ed. Citado na pág.

1

Bansal et al. (2007) M. Bansal, V. Belcastro, A. Ambesi-Impiombato e D. di Bernardo.How to infer gene networks from expression profiles. Molecular System Biology, 3(1):78.Citado na pág. 8

Barrera et al. (2007) J. Barrera, R. M. Cesar-Jr, D. C. Martins-Jr, R. Z. N. Vencio,E. F. Merino, M. M. Yamamoto, F. G. Leonardi, C. A. B. Pereira e H. A. del Portillo.Constructing probabilistic genetic networks of Plasmodium falciparum from dynamicalexpression signals of the intraerythrocytic development cycle. Em Methods of MicroarrayData Analysis V, chapter 2, páginas 11–26. Springer. Citado na pág. 1, 2, 8, 10, 43

Bearden et al. (2001) Carrie Bearden, Kathleen Hoffman e Tyrone Cannon. The neu-ropsychology and neuroanatomy of bipolar affective disorder: a critical review. TrendsNeurosci, 3:106–150. Citado na pág. 3

Borelli et al. (2012) F. F. Borelli, R. Y. Camargo, D. C. Martins-Jr, B. Stransky e L. C. S.Rozante. Accelerating gene regulatory networks inference through gpu/cuda program-ming. Em 2nd IEEE International Conference on Computational Advances in Bio andMedical Sciences (ICCABS), Las Vegas,NV. Citado na pág. 3, 23

Borelli et al. (2013) F. F. Borelli, R. Y. Camargo, D. C. Martins-Jr e L. C. S. Rozante.Gene regulatory networks inference using a multi-gpu exhaustive search algorithm. BMCBioinformatics. Citado na pág. xvi, 52, 53

Bozdech et al. (2003) Z. Bozdech, M. Llinás, B. L. Pulliam, E. D. Wong, J. Zhu e J. L.DeRisi. The transcriptome of the intraerythrocytic developmental cycle of plasmodiumfalciparum. Plos Biology, 1(1). Citado na pág. 43

Butte e Kohane (2000) Atul Butte e Isaac Kohane. Mutual information relevancenetworks: functional genomic clustering using pairwise entropy measurements. PacificSymposium on Biocomputing, 5:415–426. Citado na pág. 8

Che et al. (2008) Shuai Che, Michael Boyer, Jiayuan Meng, David Tarjan, Jeremy W. She-affer e Kevin Skadron. A performance study of general-purpose applications on graphicsprocessors using cuda. Journal of Parallel Distributed Computing, 68(10):1370–1380. ISSN0743-7315. doi: http://dx.doi.org/10.1016/j.jpdc.2008.05.014. Citado na pág. 2

Chen et al. (1999) Ting Chen, Hongyu L. He e George M. Church. Modeling gene expres-sion with differential equations. Em Pacific Symposium on Biocomputing, páginas 29–40.Citado na pág. 8

65

66 REFERÊNCIAS BIBLIOGRÁFICAS

Chen et al. (2006) X. Chen, M. Chen e K. Ning. Bnarray: an r package for constructinggene regulatory networks from microarray data by using bayesian network. BioinformaticsApplication Notes, 22:2952–2954. Citado na pág. 1

Chowdappa et al. (1994) Aswini K. Chowdappa, Anthony Skjellum e Nathan E. Doss.Thread-safe message passing with p4 and mpi. Relatório técnico, NSF Engineering Rese-arch Center, Mississippi State University. Citado na pág. 62

de Camargo et al. (2010) Raphael Y. de Camargo, Luiz C. S. Rozante e Siang W. Song.A multi-gpu algorithm for large-scale neuronal networks. Concurrency and Computation:Pratice and Experience, 23:556–572. Citado na pág. xv, 17, 19

de Jong (2002) H. de Jong. Modeling and simulation of genetic regulatory systems: Aliterature review. Journal of Computational Biology, 9(1):67–103. Citado na pág. 1, 8

DeBerardinis et al. (2008) Ralph J. DeBerardinis, Julian J. Lum, Georgia Hatzivassilioue Craig B. Thompson. The biology of cancer: Metabolic reprogramming fuels cell growthand proliferation. Cell Metabolism, 7:11–20. Citado na pág. 3

Derisi et al. (1996) J. Derisi, L. Penland, P. O. Brown, M. L. Bittner, P. S. Meltzes, M. Ray,Y. Chen, Y. A. Su e J. M. Trent. Use of a cdna microarray to analyse gene expressionpatterns in human cancer. Nature, 14:457 – 460. Citado na pág. 1

D’haeseleer et al. (2000) P. D’haeseleer, S. Liang e R. Somogyi. Genetic network inference:From co-expression clustering to reverse engineering. Bioinformatics, 16:707 – 726. Citado

na pág. 1

Faith et al. (2007) Jeremiah Faith, Boris Hayete, Joshua Thaden, Ilaria Mogno, JameyWierzbowski, Guillaume Cottarel, Simon Kasif, James Collins e Timothy Gardner. Large-scale mapping and validation of escherichia coli transcriptional regulation from a compen-dium of expression profiles. PLoS Biology, 5:259–265. Citado na pág. 1, 8

Fraser e Swinney (1986) A. M. Fraser e H. L. Swinney. Independent coordinates forstrange attractors from mutual information. Physical Review A, 33:2318–2321. Citado na pág.

9

Friedman et al. (2000) N. Friedman, M. Linial, I. Nachman e D. Pe’er. Using bayesiannetworks to analyze expression data. Journal of Computational Biology, 7:601–620. Citado

na pág. 1, 8

Hecker et al. (2009) Michael Hecker, Sandro Lambeck, Eugene van Someren Susanne To-epfer e Reinhard Guthke. Gene regulatory network inference: Data integration in dynamicmodels - a review. Biosystems, 96:86–103. Citado na pág. 1, 8

Hoare (1962) Charles Antony Richard Hoare. Quicksort. The Computer Journal, 5:10–16.Citado na pág. 44

Karlebach e Shamir (2008) G. Karlebach e R. Shamir. Modelling and analysis of generegulatory networks. Nat Rev Mol Cell Biol, 9(10):770–780. Citado na pág. 1

Kauffman (1993) S. A. Kauffman. The Origins of Order. Oxford University Press, NewYork. Citado na pág. 24

REFERÊNCIAS BIBLIOGRÁFICAS 67

Kauffman (1969) Stuart Kauffman. Metabolic stability and epigenesis in randomly cons-tructed genetic nets. Journal of Theoretical Biology, 22:437–467. Citado na pág. 8

Kelemen et al. (2008) Arpad Kelemen, Ajith Abraham e Yuehui Chen. Computationalintelligence in bioinformatics. Springer. Citado na pág. 8

Liang et al. (1998) Shoudan Liang, Stefanie Fuhrman e Roland Somogyi. Reveal: a ge-neral reverse engineering algorithm for inference of genetic network architectures. PacificSymposium on Biocomputing, 3:18–29. Citado na pág. 1, 8

Lisman et al. (2009) John E. Lisman, Joseph T. Coyle, Robert W. Green, Daniel C.Javitt, Francine M. Benes, Stephan Heckers e Anthony A. Grace. Circuit-based frameworkfor understanding neurotransmitter and risk gene interactions in schizophrenia. TrendsNeurosci, 5:234–242. Citado na pág. 3

Lister et al. (2009) Ryan Lister, Brian D Gregory e Joseph R Ecker. Next is now: newtechnologies for sequencing of genomes, transcriptomes, and beyond. Current Opinion inPlant Biology, 12:109–118. Citado na pág. 27, 57

Lopes et al. (2008) F. M. Lopes, D. C. Martins-Jr e R. M. Cesar-Jr. Feature selectionenvironment for genomic applications. BMC Bioinformatics, 9(451). Citado na pág. 1, 8

Lopes et al. (2009) F. M. Lopes, D. C. Martins-Jr e R. M. Cesar-Jr. Comparative studyof grn’s inference methods based on feature selection by mutual information. Em IEEEInternational Workshop on Genomic Signal Processing and Statistics (GENSIPS), Min-neapolis,MN,USA. Citado na pág. 1, 8, 10

Lopes et al. (2011) F. M. Lopes, R. M. Cesar-Jr e L. F. Costa. Gene expression complexnetworks: synthesis, identification and analysis. Journal of Computational Biology, 18:1353–1367. Citado na pág. 43

Lopes (2011) Fabrício Martins Lopes. Redes complexas de expressão gênica: síntese, iden-tificação, análise e aplicações. Tese de Doutorado, USP - Universidade de São Paulo. Citadona pág. 8

Maniatis e Reed (2002) T. Maniatis e R. Reed. An extensive network of coupling amonggene expression machines. Nature, 416:499–560. Citado na pág. 1

Margolin et al. (2006) Adam Margolin, Ilya Nemenman, Katia Basso, Chris Wiggins,Gustavo Stolovitzky, Riccardo Dalla Favera e Andrea Califano. Aracne: An algorithm forthe reconstruction of gene regulatory networks in a mammalian cellular context. BMCBioinformatics, 57:S1–S7. Citado na pág. 1, 8

Markowetz e Spang (2007) Florian Markowetz e Rainer Spang. Inferring cellular networks- a review. BMC Bioinformatics, 3:S5–17. Citado na pág. 8

Martins-Jr et al. (2006)D. C. Martins-Jr, R. M. Cesar-Jr e J. Barrera. W-operator windowdesign by minimization of mean conditional entropy. Pattern Analysis & Applications, 9:139–153. Citado na pág. 9

Martins-Jr et al. (2008) D. C. Martins-Jr, U. Braga-Neto, R. F. Hashimoto, E. R.Dougherty e M. L. Bittner. Intrinsically multivariate predictive genes. IEEE Journalof Selected Topics in Signal Processing, 2(3):424–439. Citado na pág. 9

68 REFERÊNCIAS BIBLIOGRÁFICAS

Metzker (2010) ML Metzker. Sequencing technologies - the next generation. NatureReviews Genetics, 11:31–46. Citado na pág. 27, 57

Meyer et al. (2007) Patrick Meyer, Kevin Kontos, Frederic Lafitte e Gianluca Bontempi.Information theoretic inference of large transcriptional regulatory networks. EURASIPJournal on Bioinformatics and Systems Biology., 2007:1–9. Citado na pág. 8

Nvidia1 (2013) Nvidia1. NVIDIA CUDA C Programming Guide.http://www.nvidia.com/. Citado na pág. xv, 15, 16, 17, 18

Nvidia2 (2013) Nvidia2. NVIDIA CUDA C Best Practices. http://www.nvidia.com/.Citado na pág. 19

Ortega e Rueda (2010) L. Ortega e A. Rueda. Parallel drainage network computationon cuda. Computers & Geoscience, 36:171–178. Citado na pág. 17

Owens et al. (2008) J. D. Owens, M. Houston, D. Luebke, S. Green, J. E. Stone e J. C.Phillips. GPU computing. Proceedings of the IEEE, 96(5):879–899. Citado na pág. 2

Owens et al. (2007) John D. Owens, David Luebke, Naga Govindaraju, Mark Harris,Jens Krüger, Aaron E. Lefohn e Timothy J. Purcell. A survey of general-purpose com-putation on graphics hardware. Computer Graphics Forum, 26(1):80–113. URL http://www.blackwell-synergy.com/doi/pdf/10.1111/j.1467-8659.2007.01012.x. Citado na pág. 21

Pluim et al. (2003) J. P. W. Pluim, J. B. A. Maints e M. A. Viergever. Mutual-information-based registration of medical images: a survey. IEEE Transactions on Medical Imaging,22:986–1004. Citado na pág. 9

Rolls et al. (2008) E. Rolls, A. Loh, G. Deco e G. Winterer. Computational models ofschizophrenia and dopamine modulation in the prefrontal cortex. Nature Reviews Neu-roscience, 9:696–709. Citado na pág. 3

Ryoo et al. (2008) Shane Ryoo, Christopher I. Rodrigues, Sara S. Baghsorkhi, Sam S.Stone, David B. Kirk e Wen mei W. Hwu. Optimization principles and application per-formance evaluation of a multithreaded gpu using cuda. n Proceedings of the 13thACMSIGPLAN Symposium on Principles andPractice of Parallel Programming, páginas 73–82.Citado na pág. 18

Schlitt e Brazma (2007) Thomas Schlitt e Alvis Brazma. Current approaches to generegulatory network modelling. BMC Bioinformatics, 8:S9. Citado na pág. 1, 8

Shannon e Weaver (1963) C. E. Shannon e W. Weaver. The mathematical theory ofcommunication. Univ. of Illinois Press. Citado na pág. 10

Shi et al. (2011) Haixiang Shi, Bertil Schmidt, Weiguo Liu e Wolfgang Muller-Wittig.Parallel mutual information estimation for inferring gene regulatory networks on gpus.BMC Research Notes, 4:189. Citado na pág. 2

Styczynski e Stephanopoulos (2005) M. P. Styczynski e G. Stephanopoulos. Overviewof computational methods for the inference of gene regulatory networks. Computers &Chemical Engineering, 29(3):519–534. Citado na pág. 1

Velculescu et al. (1995) V. E. Velculescu, L. Zhang, B. Vogelstein e K. W. Kinzler. Serialanalysis of gene expression. Science, 270:484–487. Citado na pág. 1

http://www.blackwell-synergy.com/doi/pdf/10.1111/j.1467-8659.2007.01012.x

http://www.blackwell-synergy.com/doi/pdf/10.1111/j.1467-8659.2007.01012.x

REFERÊNCIAS BIBLIOGRÁFICAS 69

Wang et al. (2009) Z. Wang, M. Gerstein e M. Snyder. Rna-seq: a revolutionary tool fortranscriptomics. Nat Rev Genet, 10(1):57–63. Citado na pág. 1

Zhou et al. (2004a) X. Zhou, X. Wang e E. R. Dougherty. Nonlinear-probit gene classifi-cation using mutual-information and wavelet based feature selection. Biological Systems,12(3):371–386. Citado na pág. 9

Zhou et al. (2004b) X. Zhou, X. Wang, E. R. Dougherty, D. Russ e E. Suh. Gene clusteringbased on clusterwide mutual information. Journal of Computational Biology, 11:147–161.Citado na pág. 9

Índice Remissivo

Busca Exaustiva, 9

CUDA, 15

engenharia reversa, 7Entropia Condicional Média, 9

gene preditor, 7, 8GPU

Compute Capability, 17CUDA, 18blocos de threads, 18grid, 18Kernel, 18

GPGPU, 20Processamento stream, 20Streaming Multiprocessors, 15Warps, 15

Informação Mútua, 8

mestre-escravo, 33balanceamento dinâmico, 33balanceamento estático, 33

MPI, 38OpenMPI, 38

OpenMP, 38

thread safe, 60

70

Inferência de redes de regulação gênica usando algoritmo de busca ...

Documents

Transcript of Inferência de redes de regulação gênica usando algoritmo de busca ...