INSTITUTO DE COMPUTAÇÃO
Hércules Cardoso da Silva
Aceleração de métodos de processamento sísmico
com OpenCL
CAMPINAS
2017
Aceleração de métodos de processamento sísmico com OpenCL
Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestre em Ciência da Computação.
Orientador: Prof. Dr. Edson Borin
Coorientador: Dr. Jorge Henrique Faccipieri Junior
Este exemplar corresponde à versão final da Dissertação defendida por Hércules Cardoso da Silva e orientada pelo Prof. Dr. Edson Borin.
CAMPINAS
2017
Ficha catalográfica
Universidade Estadual de Campinas
Biblioteca do Instituto de Matemática, Estatística e Computação Científica Ana Regina Machado - CRB 8/5467
Silva, Hércules Cardoso da,
Si38a SilAceleração de métodos de processamento sísmico com OpenCL / Hércules
Cardoso da Silva. – Campinas, SP : [s.n.], 2017.
SilOrientador: Edson Borin.
SilCoorientador: Jorge Henrique Faccipieri Junior.
SilDissertação (mestrado) – Universidade Estadual de Campinas, Instituto de
Computação.
Sil1. Método sísmico de reflexão. 2. Computação de alto desempenho. 3.
Programação paralela (Computação). 4. Heurística computacional. I. Borin, Edson, 1979-. II. Faccipieri Junior, Jorge Henrique, 1983-. III. Universidade Estadual de Campinas. Instituto de Computação. IV. Título.
Informações para Biblioteca Digital
Título em outro idioma: Acceleration of seismic processing methods with OpenCL Palavras-chave em inglês:
Seismic reflection method High performance computing
Parallel programming (Computer science) Computer heuristics
Área de concentração: Ciência da Computação Titulação: Mestre em Ciência da Computação Banca examinadora:
Edson Borin [Orientador] Tiago Antonio Coimbra Rodolfo Jardim de Azevedo
Data de defesa: 06-11-2017
Programa de Pós-Graduação: Ciência da Computação
INSTITUTO DE COMPUTAÇÃO
Hércules Cardoso da Silva
Aceleração de métodos de processamento sísmico com OpenCL
Banca Examinadora: • Prof. Dr. Edson Borin
Instituto de Computação - Unicamp • Dr. Tiago Antonio Coimbra
Centro de Estudos de Petróleo - Unicamp • Prof. Dr. Rodolfo Jardim de Azevedo
Instituto de Computação - Unicamp
A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se no processo de vida acadêmica do aluno.
We are made of stardust. (Carl Sagan)
wubba lubba dub dub. (Rick Sanchez)
Eu agradeço, em primeiro lugar a minha mãe (Jania Claudia de Castro Cardoso) que foi de essencial importância para a conclusão deste trabalho, já que, sem o apoio dela, esse trabalho nunca teria sido concluído.
Agradeço ao meu orientador (Edson Borin) pela paciência infinita, compreensão e ajuda, ele também é uma peça importante para a realização deste trabalho.
Agradeço a minha família pelo apoio que foi muito importante para a conclusão deste trabalho.
Agradeço a meu coorientador (Jorge Henrique Faccipieri Júnior) pela ajuda nas duvi-das com geofísica que surgiram durante o desenvolvimento deste trabalho.
Agradeço também a toda a minha família e amigos que residem em Campo Grande MS. Agradeço aos meus amigos Rafael Kendy Arakaki, Luana Loubet Borges e Leandro de Bortoli, por ouvirem as minhas conversas malucas e sempre me ajudarem quando era necessário.
Também agradeço a Isabela Maria de Assis por me ouvir em noites de insônia; graças ao fuso horário, eu não me sentia incomodando ninguém. Também agradeço a Thuanny Cristina, pelo apoio e pelas conversas completamente malucas. Também agradeço a José Cleber de Oliveira, por me auxiliar na revisão do texto. Também agradeço a Flávia Pisani, pela ajuda para escrever um artigo. Agradeço a todas as pessoas do HPG, CEPETRO e IC, que me ajudaram a realizar este trabalho. Agradeço a todos os integrantes do LMCAD.
A exploração de hidrocarbonetos depende de técnicas computacionais que são utiliza-das para determinar possíveis reservatórios a partir de análises de estruturas do subsolo. empilhamento CMP (Common Midpoint ) e CRS (Common Reflection Surface), assim como a migração CRP (Common Reflection Point ) em tempo são técnicas utilizadas para auxiliar especialistas a caracterizar se em um determinado local é possível determinar certas estruturas geológicas. Esses métodos normalmente são computacionalmente exaus-tivos, tornando sua execução proibitiva em alguns casos. Tais características dificultam o uso dessas técnicas. Neste trabalho é proposta uma nova abordagem de programação paralela utilizando aceleradores de hardware para otimizar o desempenho dessas técnicas. Este trabalho propõe uma implementação em OpenCL (Open Computing Language) que possibilite o uso de aceleradores de hardware como GPUs e o Xeon Phi, com o objetivo de reduzir o tempo de execução da busca de parâmetros para o empilhamento CMP, empi-lhamento CRS e migração CRP em tempo. Resultados são apresentados com dados reais e sintéticos para validar as propostas desse trabalho.
Hydrocarbon exploration depends on computational techniques that are used to dis-covery possible hydrocarbon reservoirs through subsurface structure analysis. CMP (Com-mon Mid Point) and CRS (Com(Com-mon Reflection Surface) staking and CRP (Com(Com-mon Reflection Point) time migration are the techniques used to help specialists determine certain geological structures. These methods are usually computationally exhaustive, making their execution prohibitive in some cases. Such features hamper the use of these techniques. In this work we propose a new parallel programming approach using hard-ware accelerators to optimize the performance of these techniques. This work proposes an OpenCL (Open Computing Language) implementation that enables the use of hardware accelerators such as GPUs and Xeon Phi to reduce processing time of CMP, CRS, and CRP time migration.
2.1 Configuração de aquisição organizada em fonte comum. . . 20 2.2 Configuração de aquisição organizada em ponto médio comum. . . 20 2.3 Raio normal que parte do ponto m, atinge o refletor e volta para o ponto m. 21 2.4 Par fonte-receptor de afastamento 2h, com ponto médio m, em um meio
de velocidade constante v, com um refletor plano horizontal. . . 21 2.5 Representação da curva de tempo de trânsito sobre um gather de traços
CMP. . . 24 2.6 Resultado do empilhamento do gather CMP mostrada na Figura 2.5 . . . . 24 2.7 Organização dos traços com fonte em m − h, receptor em m + h e ponto
médio m, na vizinhança de m0. . . 27
2.8 Mostra como os parâmetros A, B, C, determinam a superfície do CRS nos eixos de pontos médios, tempo e afastamento. . . 27 2.9 Plano com os eixos tempo e ponto médio mostrando os parâmetros A, B. . 28 2.10 Plano com os eixos afastamento e tempo mostrando como o parâmetro C
se relaciona com a curva de tempo de trânsito. . . 28 2.11 Principais estágios do Diferential Evolution. . . 33 2.12 Mostrando como que o DE se aplica no espaço de busca de parâmetros para
a migração CRP em tempo. . . 35 4.1 Modelo da Plataforma OpenCL. . . 42 4.2 Cubo de dados que mostra em suas arestas os gathers CMPs, amostras e
traços. . . 44 5.1 Empilhamento realizado na CPU. . . 51 5.2 Empilhamento realizado na GPU. . . 51 5.3 Diferença entre as Figuras 5.1 e 5.2; a primeira imagem mostra a imagem
resultante da subtração da imagem 5.1 e 5.2 e a segunda é o histograma da diferença. . . 51 5.4 O histograma à esquerda representa a diferença entre a GPU e a
imple-mentação com MPFR de 1024 bits. O histograma à direita representa a diferença entre a CPU e a implementação usando MPFR de 1024 bits. . . . 55 5.5 Resultados experimentais para o CMP usando o Simple-synthetic como
dado de entrada, descrito na Tabela 5.1. . . 58 5.6 Resultados experimentais para o CMP usando o Jequitinhonha como dado
de entrada, descrito na Tabela 5.4. . . 59 5.7 Resultados experimentais para o CMP usando o Micro-synthetic como dado
de entrada, descrito na tabela 5.4. . . 60 5.8 Resumo dos resultados experimentais usando a métrica descrita na
5.11 Modelo roofline para a GPU R9-290x. . . 65
5.12 Modelo roofline para a GPU R9-290x, levando em consideração a cache L2. 67 5.13 Modelo roofline para a GPU GTX-Titan, levando em consideração a cache L2. . . 68
5.14 Modelo roofline para a GPU Tesla K20. . . 68
5.15 Modelo roofline para a GPU GTX-770. . . 69
5.16 Resultados experimentais para o CRS usando o Simple-synthetic como dado de entrada, descrito na tabela 5.14. . . 70
5.17 Resultados experimentais para o CRS usando o Jequitinhonha como dado de entrada, descrito na tabela 5.14. . . 72
5.18 Resultados experimentais para o CRS usando o Micro-synthetic como dado de entrada, descrito na Tabela 5.14. . . 73
5.19 Resumo dos resultados experimentais para CRS usando como métrica a equação 5.10. . . 75
5.20 Resultados experimentais para o CRP usando o Jequitinhonha como dado de entrada, descrito na tabela 5.19. . . 77
B.1 Modelo roofline para a GPU GTX-Titan. . . 97
B.2 Modelo roofline para a GPU R9-290x. . . 98
B.3 Modelo roofline para a GPU GTX 770. . . 98
B.4 Modelo roofline para a GPU Tesla K40. . . 99
3.1 Resumo dos trabalhos relacionados. . . 39 5.1 Plataformas computacionais usadas nos experimentos. . . 49 5.2 Características dos processadores e dos aceleradores usados nos experimentos. 50 5.3 Intensidade operacional mínima para se atingir o desempenho máximo no
dispositivo, supondo o pico na largura de banda da memória. . . 50 5.4 Descrição dos dados de entrada usados nos experimentos com o CMP. . . . 57 5.5 Ganho de desempenho entre os diferentes dispositivos, usando o
Simple-synthetic como dado de entrada. . . 57 5.6 Ganho de desempenho entre os diferentes dispositivos, para o dado de
en-trada Jequitinhonha. . . 59 5.7 Ganho de desempenho entre os diferentes dispositivos, para o dado de
en-trada Micro-synthetic. . . 60 5.8 Resultados do perfilamento das aplicações CMP-OpenCL e CMP-OpenMP. 62 5.9 Desempenho das GPUs em GFLOPS para a implementação CMP-OpenCL. 63 5.10 Intensidade operacional para as GPUs para implementação CMP-OpenCL. 63 5.11 Características das caches da R9-290x. . . 65 5.12 Largura de banda de memória principal das GPUs para a implementação
CMP-OpenCL. . . 66 5.13 Largura de banda de memória da cache L2, para a GPUs GTX-Titan e
R9-290x . . . 67 5.14 Descrição de entradas usadas nos experimentos com o CRS. . . 69 5.15 Ganho de desempenho entre os diferentes dispositivos, para o dado de
en-trada Simple-synthetic. . . 71 5.16 Ganho de desempenho entre os diferentes dispositivos, para o dado de
en-trada Jequitinhonha. . . 72 5.17 Ganho de desempenho entre os diferentes dispositivos, para o dado de
en-trada Micro-synthetic. . . 73 5.18 Resultados do perfilamento das aplicações CRS-OpenCL e CMP-OpenMP. 74 5.19 Descrição do dado de entrada usado nos testes do CRP . . . 76
AP I Application Programming Interface GP U Graphics Processing Unit
CM P Common Midpoint
CRS Common Reflection Surface CRP Common Reflection Point OpenCL Open Computing Language OpenM P Open Multi-Processing
HP C High Performance Computing AV X Advanced Vector Extensions
CU DA Compute Unified Device Architecture F P GA Field Programmable Gate Array
M P F R Multiple-Precision Binary Floating-Point Library IEEE Institute of Electrical and Electronics Engineers
V HDL Very High Speed Integrated Circuit Hardware Description Language V SF A Very Fast Simulated Annealing
DE Diferential Evolution
N U M A Non Uniform Memory Access LRU Least Recently Used
F M A Multiply–accumulate operation HP G High Performance Geophysics N IP Normal Incidence Point
1 Introdução 16 1.1 Organização do Texto . . . 17 1.2 Lista de publicações . . . 17 2 Conceitos básicos 19 2.1 Método CMP . . . 19 2.1.1 Tempo de trânsito . . . 20 2.1.2 Análise de velocidade . . . 22 2.1.3 Empilhamento CMP . . . 23 2.1.4 Algoritmo CMP . . . 24 2.2 Método CRS . . . 25 2.2.1 Tempo de trânsito CRS . . . 26 2.2.2 Empilhamento CRS . . . 28 2.2.3 Algoritmo CRS . . . 28 2.3 Migração CRP em tempo . . . 30 2.3.1 Tempo de trânsito . . . 31 2.3.2 Evolução diferencial . . . 32
2.3.3 Algoritmo de evolução diferencial . . . 32
2.3.4 CRP-Evolução diferencial . . . 34
3 Trabalhos relacionados 36 3.1 Índice de reprodutibilidade . . . 36
3.2 Trabalhos que usam aceleradores de hardware . . . 36
3.3 Trabalhos que não utilizam técnicas de paralelismo . . . 38
3.4 Meta-heurísticas em aceleradores de hardware . . . 38
4 Implementação dos Métodos com OpenCL 40 4.1 Modelo OpenCL . . . 40
4.1.1 Plataforma OpenCL . . . 41
4.1.2 Modelo de execução OpenCL . . . 41
4.1.3 Modelo de programação OpenCL . . . 42
4.1.4 Modelo de memória . . . 43
4.2 Implementação do método CMP . . . 43
4.3 Implementação do método CRS . . . 44
4.4 Organização da memória . . . 45
5.2 Materiais . . . 48
5.3 Validação de resultados . . . 50
5.4 Medidas . . . 55
5.5 Resultados experimentais com o método CMP . . . 56
5.6 Resultados experimentais com o método CRS . . . 69
5.7 Resultados experimentais para o método CRP . . . 76
6 Conclusões 78
A Prova da equivalência das implementações 82
Capítulo 1
Introdução
Desde a invenção da sísmica de exploração até os dias atuais, a exploração de hi-drocarbonetos se tornou cada vez mais difícil e custosa, devido ao aumento do consumo global, os níveis de produção tiveram que se equiparar. Assim, as técnicas usadas para se determinar um reservatório se tornaram cada vez mais custosas e essenciais para a exploração desses recursos, já que os reservatórios de mais fácil acesso já estavam sendo explorados. A partir desse cenário começaram a surgir técnicas mais avançadas para determinar a estrutura do subsolo, entre elas podemos citar o empilhamento CMP (Com-mon midpoint ) [29], empilhamento CRS (Com(Com-mon Reflection Surface) [21] e a migração CRP (Common Reflection Point ) em tempo [8]. As técnicas aqui citadas têm como ob-jetivo obter informações do subsolo a partir de dados que contêm registros de reflexão e refração de ondas nas camadas da subsuperfície, para determinar qual a estrutura dessas camadas. Normalmente essas técnicas são usadas para analisar grandes quantidades de dados. Além disso, esses métodos exigem um grande número de operações sobre esses dados para que se consiga retirar alguma informação útil, e tais características tornam esses métodos muito custosos em termos computacionais. Dessa forma, o uso de métodos de paralelização torna-se essencial, já que em alguns casos o tempo de execução de um programa que utiliza uma das técnicas pode ser proibitivo. Um dos métodos de parale-lização que ganhou muita força na academia na segunda metade da primeira década do século XXI foi o uso de GPUs (Graphics Processing Unit ) de propósito geral para o pro-cessamento de aplicações muito paralelas, como é o caso das técnicas aqui mencionadas, dessa forma o trabalho aqui descrito utilizará GPUs para paralelizar o processamento de dados sísmicos aplicando esses métodos sendo, para isso, utilizado o padrão de programa-ção conhecido por OpenCL (Open Computing Language) [31] que é o padrão proposto pelo consórcio khronos [3], composto de várias empresas fabricantes de hardware. Esse padrão possibilita que a mesma implementação possa ser executada em vários dispositivos diferentes, incluindo o hardware da Intel chamado Xeon Phi, que tem como objetivo ser a solução da Intel para concorrer com as GPUs no mercado de HPC (high performance computing).
Os objetivos deste trabalho são: 1) apresentar uma implementação eficiente dos méto-dos acima citaméto-dos em OpenCL; 2) apresentar uma análise do desempenho das implemen-tações; 3) demonstrar que o uso de GPUs pode contribuir de forma significativa para o campo do processamento de imagens sísmicas. As contribuições deste trabalho se resumem
a três implementações em OpenCL, uma para cada um dos métodos de processamento sísmico acima.
1.1
Organização do Texto
Nesta seção, são apresentados os resumos dos capítulos contidos neste trabalho. Capítulo 2 - Conceitos básicos
No Capítulo 2, é apresentada uma base teórica das técnicas dos métodos CMP, CRS, e a migração CRP em tempo, conceitos básicos de geometria de aquisição de sísmica, também são discutidos os conceitos de tempo de trânsito e análise de velocidade para os três métodos.
Capítulo 3 - Trabalhos relacionados
No Capítulo 3, apresentamos trabalhos correlacionados com esta dissertação, onde se discutem brevemente os resultados de desempenho e a reprodutibilidade de cada um dos trabalhos lá mencionados.
Capítulo 4 - Implementação dos métodos com OpenCL
No Capítulo 4, são apresentadas as implementações em OpenCL que foram realizadas para o CMP, CRS e migração CRP em tempo, também são discutidos detalhes como, técnica usada para fazer acesso de memória coalescido e organização das threads.
Capítulo 5 - Resultados experimentais
No Capítulo 5, descreve-se a metodologia, o hardware usado nos experimentos e ca-racterísticas dos dados de entrada. Apresenta-se uma métrica para comparar resultados de desempenho em máquinas diferentes e dados de entrada diferentes. São também apre-sentados resultados de desempenho e são discutidas hipóteses para explicá-los. Também são discutidos aspectos de corretude das implementações, onde mostramos que as imple-mentações em OpenCL estão corretas.
Capítulo 6 - Conclusões
No Capítulo 6, é apresentada uma discussão sobre as conclusões e limitações referentes a este trabalho.
1.2
Lista de publicações
1. E. Borin, H. C. D. Silva, J. H. Faccipieri Jr., and M. Tygel. Accelerating semblance computations on heterogeneous devices using OpenCL. In 2015 Wave Inversion Technology Consortium (WIT). Tech Report, 2015.
2. H. C. D. Silva, F. Pisani, and E. Borin. A comparative study of sycl, opencl, and openmp. In 2016 International Symposium on Computer Architecture and High Performance Computing Workshops (SBAC-PADW), pages 61–66, Oct 2016.
Capítulo 2
Conceitos básicos
Este capítulo é composto por três seções principais, sendo que a primeira descreve o método CMP, a segunda descreve o método CRS e, por fim, a terceira descreve a migração CRP em tempo.
2.1
Método CMP
Os dados sísmicos são adquiridos posicionando-se fontes de ondas sísmicas e recep-tores na superfície. Os receprecep-tores captam informações de ondas produzidas pela fonte que refletem ou refratam em estruturas do subsolo. Esse processo é repetido diversas vezes, mudando-se o posicionamento das fontes e/ou dos receptores, e pode ser visto na Figura 2.1, em que existe uma fonte e quatro receptores. Nesse caso, pode-se abstrair a onda para um raio que sai da fonte e é captado pelos receptores após a reflexão sobre um refletor plano. O sinal registrado em cada receptor é chamado de traço sísmico. Para cada raio gerado pela fonte, esses traços sísmicos registram as respostas do subsolo em tempos diferentes, já que, a onda sísmica gerada pela fonte percorre caminhos diferentes até o receptor, como mostrado na Figura 2.1. Além dessa dependência da distância dos receptores com a fonte, esses dados podem ser difíceis de serem interpretados, já que, geralmente, apresentam uma forte componente de ruído ambiental. Uma das maneiras de resolver o problema do ruído é a utilização de uma técnica conhecida como empilha-mento. O empilhamento tem como objetivo obter uma alta relação sinal/ruído. O método CMP [29] é uma das técnicas usadas no empilhamento, e funciona da seguinte maneira: reordenam-se os dados sísmicos em grupos de ponto médio comum, ou seja, agrupam-se os traços em conjuntos de tal forma que cada conjunto tenha traços com o mesmo ponto médio, como podemos ver na Figura 2.2. Depois disso, os grupos de traços são somados na posição de ponto médio, ao longo de uma curva de tempo de trânsito. No caso do empilhamento com o CMP, essa curva é monoparamétrica, ou seja, depende apenas de um único parâmetro. O processo que é computacionalmente exaustivo para se realizar o empilhamento CMP ou CRS é a busca dos parâmetros para se determinar a melhor equação de tempo de trânsito.
Figura 2.1: Configuração de aquisição organizada em fonte comum.
Figura 2.2: Configuração de aquisição organizada em ponto médio comum.
2.1.1
Tempo de trânsito
Em uma seção sísmica1 2D, com meio de velocidade constante, organizada em pontos
médios comuns, ou famílias CMPs (gather CMP), pode-se definir um raio normal que representa o caso em que a fonte e o receptor estão na mesma posição. Esse raio parte da superfície em um ponto m, atinge um refletor no subsolo com um ângulo de 90 e o raio refletido volta para a superfície no mesmo ponto m, como mostra a Figura 2.3.
1Uma seção sísmica consiste de um conjunto de traços localizados ao longo do eixo x e tempo de
Figura 2.3: Raio normal que parte do ponto m, atinge o refletor e volta para o ponto m. O tempo de trânsito para a ida e volta, ao longo do raio normal, é representado por t0 e em um dado CMP considera-se esse tempo como referência, como pode-se ver na
Figura 2.4. Se for levada em conta a posição de cada receptor em um gather CMP que dista h do ponto médio, pode-se aplicar o teorema de Pitágoras, chegando-se à Equação 2.1.
t = tF N + tN R = s t0 2 2 + h v 2 + s t0 2 2 + h v 2 (2.1)
Onde temos os significados dos termos da Equação 2.1:
• tF N : tempo de trânsito de onde parte da fonte e é refletido no ponto N .
• tN R : tempo de trânsito do raio que parte do ponto N e vai até o receptor.
• v : velocidade da propagação da onda no meio.
• t0 : tempo de ida e volta do raio normal para um dado CMP.
Figura 2.4: Par fonte-receptor de afastamento 2h, com ponto médio m, em um meio de velocidade constante v, com um refletor plano horizontal.
t2 = t20+4h
2
Pode-se reescrever a Equação 2.2 considerando c = v42, e dessa forma obtém-se a
Equação 2.3.
t2 = t20+ ch2. (2.3)
Para um meio com multicamadas pode-se substituir v por vnmo, onde vnmo representa a
velocidade média nessas camadas.
2.1.2
Análise de velocidade
Com base na Equação 2.2 de tempo de trânsito de um dado sísmico organizado em CMPs, pode-se traçar uma superfície de tempo de trânsito para cada amostra de tempo t0
centradas em um ponto médio, e testar diversos valores v, a fim de encontrar qual destas melhor se ajusta a esse conjunto de traços.
O ajuste de tais curvas é mensurado através de medidas de coerência. A medida de coerência usada neste trabalho é a semblance [32], sendo que o valor de semblance é proporcional à qualidade do ajuste da curva e é definida pela Equação 2.4.
S = k0+0.5∗w X k=k0−0.5∗w N X i=1 ui,k !2 N k0+0.5∗w X k=k0−0.5∗w N X i=1 ui,k2 (2.4) onde:
• ui,k : Amplitude da amostra de tempo k para o traço i.
• N : número de traços.
• k0: primeira amostra da janela de tempo.
• w: Tamanho da janela.
O Algoritmo 1 realiza o cálculo da Equação 2.4, para um conjunto de traços g = {tr1, ..., trng} onde tri ∈ g é um traço representado na forma de um vetor, ou seja, um
vetor de amostras {a1, ..., ans}. Para cada tri temos o conjunto de valores {hx, hy}, que
indicam a localização espacial do traço.
O Algoritmo 1 recebe um conjunto de traços g, um c tal que c = v42, um t0 e um número
inteiro w. O algoritmo calcula um tempo de trânsito ti para cada traço de tri ∈ g usando
o Algoritmo 2. Após o cálculo do tempo de trânsito ti é utilizado para se determinar
quais amostras do traço tri ∈ g serão utilizadas no cálculo da semblance. São usadas w
amostras de cada traço. Como as amostras estão discretizadas em um vetor, usa-se o Algoritmo 8 para se realizar uma interpolação linear entre dois valores da amostra de um traço e assim se determinar a amplitude a, que é acumulada em numj a fim de realizar
o somatório (PN
i=1ui,k)
2 e acumula em den a2 a fim de realizar o somatório PN
i=1u 2 i,k.
Como o laço executa w vezes, então temos que a variável den terá o valor do somatório Pk0+w
k=k0
PN i=1u
2
Algoritmo 1: Semblance
Entrada: t0,g,c,w,tempo2D() Saída: S ∈ {0, .., 1}
início
Seja num = {num1, ..., numw}, numi = 0 para todo numi ∈ num
den ← 0
para tr ∈ g faça
t = tempo2D(t0, hx, hy, c) para j = 0 até j = w faça
k ← bt ∗ idtc + j − tau
a ← interpolacao_linear(k, k + 1, tr[k], tr[k + 1], t ∗ idt + j − tau) num[j] ← num[j] + a
den ← den + a2
fim fim
sumN um ← 0
para j=0 até j=w faça
sumN um ← sumN um + num[j]2 fim
retorna sumN umden∗w fim
terá o valor do somatórioPk0+w
k=k0(
PN
i=1ui,k)
2. Sendo a amostra central ki
0 = k0− 0.5 ∗ w,
podemos reescrever o somatório como o da equação 2.4, trocando k0 por ki0.
O Algoritmo 2 implementa a Equação 2.3 para calcular o tempo de trânsito, onde as variáveis hx e hy representam a posição espacial do traço.
Algoritmo 2: tempo2d Entrada: t0,hx,hy,c início t2 ← t02 t2 ← t2 + c ∗ (hx2+ hy2) retorna√t2 fim
2.1.3
Empilhamento CMP
Nesse processo, os traços de cada gather CMP, que nesse momento possuem os eventos de reflexão, são somados na posição de seu ponto médio em h = 0 ao longo de uma curva de tempo de trânsito. Na seção resultante, cada traço representa a informação útil contida em um gather CMP do dado sísmico. Portanto, além de eliminar a dependência do afastamento fonte-receptor na imagem final, uma melhora significativa na relação sinal-ruído é obtida, uma vez que a soma de informação não coerente contida nos traços não é construtiva.
A Figura 2.5 mostra uma curva de tempo de trânsito sobre um conjunto de amostras de um gather CMP. Os traços estão representados de maneira simplista: onde se houve um evento a amplitude é 1, caso contrário, é 0. Na Figura 2.6, pode-se ver o gather após o empilhamento das amplitudes que interceptam a curva de tempo de trânsito. Também pode-se ver na Figura 2.5 que, para esse exemplo, discretizamos a curva de tempo de trânsito usando o valor da amostra mais próxima da curva de tempo de trânsito. Nas implementações que foram feitas neste trabalho, nós usamos uma interpolação linear entre as duas amostras em que a curva de tempo de trânsito passa.
Figura 2.5: Representação da curva de tempo de trânsito sobre um gather de traços CMP.
Figura 2.6: Resultado do empilhamento do gather CMP mostrada na Figura 2.5
2.1.4
Algoritmo CMP
Pode-se escrever um algoritmo de força bruta que resolve esse problema de encontrar os parâmetros para o empilhamento CMP testando todos c ∈ C, onde C é o conjunto
de parâmetros que serão testados. Dessa maneira, temos certeza de achar o melhor c. Pode-se descrever tal algoritmo como a composição de dois algoritmos: o algoritmo 3, que só faz o trabalho de organizar os traços em gathers CMP e chama o algoritmo 4, que testa cada c para um dado gather CMP e devolve o c com o melhor valor de semblance. Antes de descrever o algoritmo para resolver o problema da busca de parâmetros para o CMP, precisamos das definições abaixo:
• CDPi = {tr1, ..., trl}
• tri = {gx, sx, gy, sy, data}
• data = {a1, ..., ans}
• gx,sx,gy,sy: coordenadas espaciais do traço. • tri: traço sísmico.
• data: conjunto de amostras do traço.
• ai: amostra de um evento detectado pelo receptor.
• CDP s = {CDP1, ...., CDPn}.
Algoritmo 3: CMP Entrada: C, CDP s
Saída: Conjunto de melhores C início
para CDPi ∈ CDP s faça
para t de 0 até ns faça
bestC ← bestC ∪ M elhorC(CDPi, t, C)
fim fim bestC fim
2.2
Método CRS
Devido ao aumento do consumo global os reservatórios de mais fácil acesso já foram ou estão sendo explorados. com objetivo de encontrar novos reservatórios surgiram novos métodos que conseguiam retirar mais informações úteis dos dados coletados. Uma dessas técnicas é o CRS, que se utiliza de traços vizinhos a um ponto médio comum para construir o empilhamento. O CRS funciona da seguinte forma: agrupam-se os traços em grupos, de forma que os pontos médios de cada traço estejam a uma distância máxima determinada de um ponto médio definido para esse grupo. Depois disso, os traços são somados em uma posição de ponto médio ao longo de uma curva de tempo de trânsito, mas, enquanto o CMP define uma curva monoparamétrica, o CRS define uma superfície multiparamétrica no volume de dados.
Algoritmo 4: MelhorC Entrada: CDP, C, t Saída: M elhorc ∈ C início sem ← 0 para CDPi ∈ CDP s faça para c ∈ C faça s ← Semblance(CDP, t, C, tempo2d) se s > sem então sem ← s mc ← c fim fim fim retorna mc fim
2.2.1
Tempo de trânsito CRS
Para se determinar a equação de tempo de trânsito utilizada no método CRS, utili-zaremos uma expansão em polinômio de Taylor até a segunda ordem, para se obter uma função aproximada numa vizinhança de um ponto dado, desde que se conheçam as deriva-das da função nesse ponto. No caso da superfície de tempo de trânsito, para se conseguir uma função aproximada na vizinhança do ponto central m0, precisamos conhecer o tempo
de afastamento nulo e as derivadas dessa função ponto. Dessa maneira, obtemos, por fim, uma aproximação de uma função que aproxima o tempo de trânsito entre um par fonte receptor.
A Equação 2.5 é a equação multiparamétrica de tempo de trânsito utilizada no método CRS. Essa equação pode ser obtida a partir do cenário descrito na Figura 2.7, onde se considera um raio normal que parte do ponto central m0 na superfície de aquisição e incide
perpendicularmente sobre o refletor em um ponto chamado de NIP (Normal Incidence Point ) e retorna à superfície de aquisição no mesmo ponto (m0, z0).
Figura 2.7: Organização dos traços com fonte em m − h, receptor em m + h e ponto médio m, na vizinhança de m0.
A Figura 2.8 mostra como os parâmetros A, B, C determinam a superfície de tempo de trânsito. O parâmetro A é a derivada parcial da equação que define a superfície de tempo de trânsito no ponto (m0, t0) em relação aos pontos médios. Isso fica mais claro na
Figura 2.9. O parâmetro B é a segunda derivada parcial de equação que define a superfície de tempo de trânsito no ponto (m0, t0) em relação aos pontos médios e o tempo, como
pode-se observar na Figura 2.9. O parâmetro C é a segunda derivada parcial da equação que define a superfície de tempo de trânsito no ponto (m0, t0) em relação ao afastamento,
isso pode ser visto em mais detalhes na Figura 2.10.
Figura 2.8: Mostra como os parâmetros A, B, C, determinam a superfície do CRS nos eixos de pontos médios, tempo e afastamento.
Figura 2.9: Plano com os eixos tempo e ponto médio mostrando os parâmetros A, B.
Figura 2.10: Plano com os eixos afastamento e tempo mostrando como o parâmetro C se relaciona com a curva de tempo de trânsito.
2.2.2
Empilhamento CRS
Após obter os coeficientes A, B e C usando o algoritmo descrito na seção 2.2.3, pode-se realizar o empilhamento fazendo a soma do dado sísmico ao longo da superfície definida pela Equação 2.5, analogamente como é feito com o método CMP.
2.2.3
Algoritmo CRS
O problema da busca de parâmetros para o empilhamento CRS, pode ser resolvido com um algoritmo de força bruta que testa todas as triplas {a,b,c} de maneira a achar a que resulta na superfície de tempo de trânsito com o melhor valor de semblance, e repetir esse processo para cada grupo de traços (chamaremos esses grupos traços de gather ).
O algoritmo 5 realiza esse processo, onde o Algoritmo 6 é responsável por calcular a semblance para todos as triplas {a,b,c} conjunto de traços em que uma superfície de tempo de trânsito passa, enquanto que o Algoritmo 7 implementa a equação de tempo de trânsito para o CRS, ou seja, ele implementa a Equação 2.5.
Algoritmo 5: CRS
Entrada: A, B, C, CDP s
Saída: Conjunto de melhores A, B, C início
para CDPi ∈ CDP s faça
para Cada CDPj ∈ CDP s faça
se CDPj se CDPj está na vizinhança de m0 então
CDPi ← CDPi∪ CDPj
fim
para t de 0 até ns faça
{A, B, C} ← M elhorABC(CDPi, t, A, B, C) fim fim fim fim Algoritmo 6: MelhorABC Entrada: CDP, A, B, C
Saída: Conjunto de melhores A, B, C início
sem ← 0
para Cada a ∈ A faça para Cada b ∈ B faça
para Cada c ∈ C faça
s ← semblance(CDPi, t, A, B, C, tempo2dcrs) se s > sem então sem ← s ma ← a mb ← b mc ← c fim fim fim fim retorna {ma, mb, mc} fim
Algoritmo 7: tempo2dcrs Entrada: t0,hx,hy,m0x,m0y,mx,my,a,b,c início _mx ← mx − m0x _my ← my − m0y _m2 ← _mx2_my2 t2 ← t0 + a ∗√_m2 t2 ← t22 t2 ← b ∗ _m2 t2 ← t2 + c ∗ (hx2+ hy2) se t2 ≥ 0 então retorna√t2 fim retorna -1 fim Algoritmo 8: interpolacao_linear Entrada: x0, x1, y0, y1, x Saída: a ∈ R início retorna (y1− y0) ∗ (x − x0)/(x1− x0) + y0 fim
2.3
Migração CRP em tempo
Neste trabalho só iremos acelerar a primeira etapa das duas usadas na migração2 CRP em tempo [9], que é a etapa referente à estimativa dos parâmetros para a realização da migração. Dessa forma, pode-se definir o problema que se refere a essa etapa como, dado um conjunto de parâmetros X = {x1, ..., xnx}, T = {t1, ..., tnt}, um conjunto de
traços g{tr1, ..., trng}, uma função de coerência c(p) e uma função de tempo de trânsito
f (t, x, a, v), onde t ∈ T , x ∈ X, a ∈ A, v ∈ V , onde p é o conjunto de traços por onde a superfície de tempo de trânsito passa; em que o objetivo é encontrar para cada x ∈ X e t ∈ T um par {a, v} que maximize c(p). A etapa de se determinar os parâmetros para realizar a migração CRP em tempo.
Nessa etapa da migração, é bem parecida com a busca pelos parâmetros realizadas no CRS e CMP, com a única diferença de termos uma nova equação de trânsito.
2Segundo Oilfield Glossary [1], o processo de migração em tempo é uma técnica para o processamento
sísmico usada quando há mergulhos. Ela funciona corrigindo mergulhos aparentes contidos na seção sísmica para mergulhos corretos, resultando em imagens que mostram os eventos em termo de tempo de trânsito, e não em profundidade.
2.3.1
Tempo de trânsito
A equação de tempo de trânsito pode ser visto na Equação 2.6 é definida por Coim-bra et al. [9]. tcrp = th + ah(m − mh) (2.6) H = 2Ah (2.7) mh = m0+ 2Ah2 t0+ √ t02+ H2 (2.8) xs = x − mh + h (2.9) xr = x − mh − h (2.10) ts = r t2 4 + xs2 V2 (2.11) tr = r t2 4 + xr2 V2 (2.12) th = ts + tr (2.13) ah = − xr (tr + xs)tsV2 (2.14) Onde: t0 = t q 1 −A24V2 (2.15) m0 = x + t0AV2 4 (2.16)
Algoritmo 9: tempo2D_CRP Entrada: t,h,A,V início t0 ← q t 1−A2V 2 4 m0 ← x + t0AV 2 4 H ← 2Ah mh ← m0+2Ah2 t0+ √ t2 0+H2 xs ← x − mh + h xr ← x − mh − h ts ← q t2 4 − xs2 V2 tr ← q t2 4 + xr2 V2 ah ← −(tr+xs)tsVxr 2 tcrp ← th + ah(m − mh) retorna tcrp fim
2.3.2
Evolução diferencial
Diferente dos algoritmos descritos nas seções 2.1 e 2.2, o algoritmo para encontrar os parâmetros para a migração CRP em tempo não usa uma busca de força bruta pelos parâmetros, mas sim uma meta-heurística chamada Differential Evolution [13]. Esta meta-heurística é inspirada pela teoria da evolução. Basicamente ela funciona colocando os indivíduos para competir e escolhendo os que melhor se adaptam para originarem os indivíduos para a próxima geração. Os indivíduos são representados por dois elementos o genótipo e fenótipo, onde o genótipo é uma solução viável para o problema em questão, enquanto que o fenótipo é uma medida dada por uma função que diz o quão bom é o genótipo de tal indivíduo.
2.3.3
Algoritmo de evolução diferencial
O algoritmo de evolução diferencial é dividido em 4 etapas principais, como mostrado na Figura 2.11. Essas etapas são as seguintes: inicialização da população, mutação, recombinação e seleção. Nesta seção essas etapas serão mostradas em detalhes. Após a execução das 3 etapas (Mutação, Recombinação, Seleção) N vezes para se obter a melhor solução basta escolher o indivíduo da população com o melhor fenótipo.
Inicialização da População
Seja a população de soluções candidatas da t-ésima geração representada por Xt =
{xt,i; i = 1, ..., N } onde i é o índice do indivíduo na população. Para cada xt,i ∈ Xt temos
Figura 2.11: Principais estágios do Diferential Evolution. Mutação
Seja a população mutante da t-ésima geração Vt = {vt,i; i = 1, ..., N } onde vt,i =
xt,r1+ (xt,r2− xt,r3) ∗ p, seja r1, r2, r3 ∈ {1, ...., N } e r1 6= r2 6= r3 e seja p ∈ {0, .., 1}.
Recombinação
Podemos gerar a população recombinada da t-ésima geração Ut = {ut,i; i = 1, ..., N }
onde ut,i = {ut,i,1, ..., ut,i,n}, e seja R(0,1), que devolve um número real aleatório de 0 a 1
com uma distribuição normal.
ut,i,j =
(
vt,i,j se R(0, 1) ≤ C ∨ vj = δi.
xt,i,j caso contrário.
(2.17) Em que δi ∈ {1, ..., n} é um índice aleatório. C determina qual é a fração de elementos
de Xt vão ser copiados para Ut.
Seleção
Seja o conjunto de F ent= {ft,i; i = 1, ..., N }, que representa o fenótipo da população
Xt da t-ésima geração Onde:
ft,i =
(
F (ut,i) se F (ut,i) > F (xt,i).
F (xt,i) caso contrário.
(2.18) Além disso, temos a atualização da população, que pode ser representada pela Equa-ção 2.19:
xt+1,i=
(
ut,i se F (ut,i) > F (xt,i).
xt,i caso contrário.
Algoritmo 10: Evolução diferencial Entrada: CDP, X, n, N gen, p, F
Saída: xi ∈ X = {x0, ...xn} com o maior valor de F
início
para t ∈ {0, .., N gen} faça Seja U = {ui, ..., un} Seja V = {vi, ..., vn} para vi ∈ V faça Seja R1 6= R2 6= R3 ∧ R1, R2, R3 ∈ {1, ..., N } vi,j ← xr1 + {xr2− xr3} ∗ p para ui ∈ U faça se R(0, 1) ≤ C ∨ vj = δi então ui,j ← vi,j fim senão ui,j ← xi,j fim fim
para xi ∈ X faça faça
se F (ui) > F (xi) então xi ← vi fim fim fim fim mx ← 0 para xi ∈ X faça se F (mx) < F (xi) então mx ← xi fim fim retorna mx fim
2.3.4
CRP-Evolução diferencial
O Algoritmo 11 descreve um algoritmo que acha os parâmetros para a migração CRP usando a meta-heurística de evolução diferencial. O Algoritmo funciona executando uma busca com o DE para cada par dos {x, t}, onde x ∈ X e t ∈ T , sendo assim, encontrando, para cada um desses pares, um outro par {a,v}.
{a1, v1} {a1, v2} . . . {a1, vnx} {a2, v1} {a2, v2} . . . {a2, vnx} .. . ... . .. ... {ant, v1} {ant, v2} . . . {ant, vnx} =
DE(t1, x1) DE(t1, x2) . . . DE(t1, xnx)
DE(t2, x1) DE(t2, x2) . . . DE(t2, xnx)
..
. ... . .. ...
DE(tnt, x1) DE(tnt, x2) . . . DE(tnt, xnx)
Figura 2.12: Mostrando como que o DE se aplica no espaço de busca de parâmetros para a migração CRP em tempo.
A Figura 2.12 representa como o DE se aplica no espaço de busca de parâmetros do CRP. Algoritmo 11: CRP Entrada: CDP, X, T, n, N gen, p, F, nx, nt Saída: os conjuntos Sa e Sv início Seja Sa=[0...nx] [0...nt] Seja Sv=[0...nx] [0...nt] para ti ∈ T faça para xi ∈ X faça Seja IP = {Ii, ..., In} Seja Ii = {ti, xi, a, v} Seja e{a, v}
e ← Evolucaodif erencial(CDP, IP, n, N Gen, p, semblance) Sa[t][x] ← a ∈ e Sv[t][x] ← v ∈ e fim fim fim retorna Sa,Sv
Capítulo 3
Trabalhos relacionados
Neste capítulo, temos a descrição sobre os trabalhos que implementam algum dos métodos listados no capítulo 2. O que inclui trabalhos que aceleram de alguma forma os métodos descritos no capítulo 2. Também, para cada trabalho citado neste capítulo, existe uma pequena discussão de sua reprodutibilidade.
3.1
Índice de reprodutibilidade
Nesta seção, avaliaremos a reprodutibilidade dos trabalhos analisados usando um ín-dice baseado no ínín-dice proposto por Collberg et al.[10]. Nosso ínín-dice é uma simplificação que avalia os itens abaixo:
• Descrição dos hardwares utilizados nos testes.
• Descrição dos compiladores e flags usados nos testes. • Descrição de como os testes foram realizados.
• Disponibilização do código usado nos testes.
Nós dividiremos os trabalhos em três categorias: a de trabalhos que são fáceis de se reproduzir, na qual estão todos os trabalhos que cumprem todos os itens listados acima; a categoria de trabalhos difíceis de se reproduzir, que inclui trabalhos que não cumprem algum dos itens mencionados acima, e, por fim, a categoria de trabalhos que são de média reprodutibilidade, em que o artigo cumpre todos os quesitos listados a cima, menos o último, mas o artigo nos fornece informações suficientes para reescrever o código usado nos testes.
3.2
Trabalhos que usam aceleradores de hardware
Nesta seção, são relatados referentes que utilizam aceleradores de hardware.
Marchetti et al. [28] aceleraram o método CRS 3D usando OpenCL, onde relatam um ganho de desempenho de até 60 vezes com o uso da GPU (Radeon HD 5870) em relação a uma CPU que, segundo os autores, é um dos mais recentes processadores X86, o que
é uma informação insuficiente para se determinar a CPU exata usada nos experimentos de desempenho. Apesar de os autores descreverem que a sua implementação foi baseada em uma implementação de um trabalho anterior e descreverem quais otimizações foram usadas na implementação que fora realizada, eles não mostram o código OpenCL usado nos testes de desempenho e não relatam no trabalho nenhum repositório onde se possa adquirir os códigos utilizados nos experimentos. Todos esses fatores apresentados tornam a reprodução desse trabalho difícil ou inviável.
Marchetti et al. [27] implementam o método 3D-CRS-OIS (Output Imaging Scheme) usando VHDL (Very High Speed Integrated Circuit Hardware Description Language) em uma FPGA (Field Programmable Gate Array). Os autores relatam um ganho de desem-penho de 230 vezes usando duas Virtex-5 FPGAs em relação a um core de um Intel Xeon 5450. Os autores, apesar de relatar como a técnica é implementada, não mostram nenhum código em VHDL ou referência a um repositório onde se possa obter o código. Por esses motivos, pode-se dizer que esse trabalho é difícil de reproduzir.
Yang et al. [33] implementam o método 3D-CRS-OIS utilizando CUDA (Compute Unified Device Architecture), os autores relataram um ganho de desempenho de 10 a 220 vezes usando uma GPU Tesla c1060 em relação a uma CPU x86 single core não especi-ficada. Apesar de os autores descreverem a técnica implementada em um algoritmo em um fluxograma, não disponibilizam o código fonte no texto ou referência a um repositório externo onde pode-se encontrar o código usado no experimento de desempenho. Essas características apresentadas pelo trabalho criam dificuldades para uma reprodução.
Lawrens et al. [25] estimam os parâmetros para o empilhamento CRS com uma imple-mentação multicore com OpenMP e reportam um ganho de desempenho de 3.6 com o uso de um processado Intel I7 2600K entre a implementação com uma thread e a implementa-ção usando 8 threads. Os autores não reportam o código da implementaimplementa-ção utilizada nos testes de desempenho, nem reportam algum repositório onde se possa adquirir o código utilizado nos testes. Porém, os autores descrevem de maneira clara a implementação e até quais escalonamentos de threads foram usados na implementação OpenMP e o hard-ware usado nos testes, sendo assim então classificado como de reprodutibilidade média, já que os 3 primeiros itens e nós podemos reescrever o código usado nos testes com as informações do algoritmo.
Lawrens et al. [24] implementam um algoritmo em uma arquitetura NUMA(Non Uni-form Memory Access) [5] e reportam um ganho de desempenho de 11.3. Compara-se a implementação usando uma thread contra uma usando 24 threads em uma máquina com dois processadores Xeon X5650. Os autores descrevem as otimizações realizadas na im-plementação, mas não disponibilizam nenhum tipo de código ou repositório onde se possa obter o código utilizado nos experimentos, tornando, assim, mais difícil a reprodução dos experimentos de desempenho.
3.3
Trabalhos que não utilizam técnicas de
parale-lismo
Além do uso de aceleradores de hardwares, pode-se utilizar outras técnicas para se acelerar os métodos descritos no capítulo 2, como meta-heurísticas, nesta seção é dedicada a trabalhos que se utilizam dessas técnicas.
Gabarito et al. [20] utilizam uma meta-heurística chamada de VFSA (Very Fast Simu-lated Annealing) [22] para estimar os parâmetros do empilhamento CRS. São reportados bons resultados na determinação dos parâmetros do CRS, mas não reportam nenhum ganho de desempenho em relação a outra implementação. Os autores não reportam o código fonte usada na implementação, o que torna a reprodução dos experimentos difícil. Barros et al. [6] implementam uma busca global pelos parâmetros do CRS usando uma meta-heurística chamada de Diferential Evolution. Os autores comparam essa busca global com uma busca usando o VFSA, reportando uma taxa de conversão 10 vezes maior para o Diferential Evolution em comparação com o VFSA.
3.4
Meta-heurísticas em aceleradores de hardware
Veronese et al. [15] implementam a Differential Evolution usando CUDA para várias funções objetivo diferentes e reportam um ganho de desempenho de 9 a 39 vezes com uma GTX 280 em relação a um processador AMD Athlon x2 5200+ 2.7 GHz. O trabalho é fácil de reproduzir, já que os autores disponibilizam quase todo o código no artigo e descrevem a plataforma de testes em detalhes.
Ferreiro et al. [17] implementam a meta-heurística SA (Simulated Annealing), onde reportam um ganho de desempenho de 79 a 269 vezes com uma GPU GTX 470 em relação a uma implementação single core na CPU Xeon E5620. O autores utilizam o SA para otimizar diversas funções numéricas. Os autores mostram os códigos no trabalho, descre-vem o hardware usado e as funções objetivo usadas nos testes. Já que o artigo cumpre os 3 primeiros itens do nosso índice e é possível reescrever o código usado com informações contidas no artigo, então classificamos esse trabalho como de média reprodutibilidade.
A tabela 3.1 apresenta o resumo dos trabalhos encontrados na literatura. Como mos-trado na tabela, poucos dos trabalhos mencionados proporcionam uma fácil reprodução; a maioria deles não dá informações precisas sobre a implementação ou sobre o hardware usado.
Muitos dos trabalhos citados que utilizam aceleradores de hardware não reportam de maneira satisfatória o hardware, enquanto que os trabalhos que se utilizam de meta-heurísticas não chegam a reportar hardwares, já que para esse tipo de trabalho o hardware normalmente não é importante, já que normalmente a medida para se medir o desempenho de uma meta-heurística está relacionada com a qualidade da solução gerada. A principal diferença dos trabalhos citados nesta seção com este trabalho é que implementamos três métodos: CMP, CRS, e migração CRP em tempo. Além disso, fornecemos informações suficientes para se reproduzir os experimentos, o que inclui um repositório com o código das implementações que foram testadas.
Trabalho Método Acelerador Referencial Ganho de
desempenho Linguagem Reprodução
Marchetti, et al.[28] 3D-CRS radeon hd 5870 - 60 OpenCL difícil
Marchetti, et al.[27] 3D-CRS Virtex-5 FPGAs Xeon 5450 230 VHDL difícil
Yang, et al.[33] 2D-CRS Tesla c1060 - 10 a 220 CUDA difícil
Lawrens, et al.[25] 2D-CRS I7 2600K I7 2600K 3.6 OpenMP média
Lawrens, et al.[24] 2D-CRS Xeon X5650 Xeon X5650 11.3 OpenMP difícil
Veronese, et al.[15] DE GTX 280 Athlon x2 5200+ 9 a 39 CUDA difícil
Ferreiro, et al.[17] SA GTX 470 Xeon E5620 79 a 269 CUDA média
Gabarito, et al.[20] 2D-CRS - - - - difícil
Barros, et al.[6] 2D-CRS - - - - difícil
Tabela 3.1: Resumo dos trabalhos relacionados.
Nós não iremos comparar os resultados dessa dissertação em termos de desempenho com os trabalhos relacionados, já que nenhum oferece informações suficientes para isso.
Capítulo 4
Implementação dos Métodos com
OpenCL
Este capítulo é composto por três seções, sendo que a primeira apresenta os principais pontos da arquitetura OpenCL, a segunda apresenta como foi realizada a implementação dos métodos CMP e CRS e, por fim, a terceira discute como é realizada a implementação da estimativa dos parâmetros da migração CRP em tempo.
4.1
Modelo OpenCL
Com o crescimento do interesse na capacidade de processamento paralelo das GPUs, tornou-se necessária a criação de modelos de programação que permitam a implementa-ção de problemas de propósito geral em GPU de uma maneira mais simples e amigável entre esses modelos [7]. Atualmente, se destacam o CUDA (Compute Unified Device Ar-chitecture) [34], o OpenCL (Open Computing language) [31] e o OpenACC. OpenCL é um modelo de programação criado pelo consórcio Khronos [3], que é constituído de vá-rias empresas de computação e vem sendo incorporado como método de programação de aceleradores de hardware, incluindo GPUs. A ideia principal é fornecer aos fabricantes de dispositivos uma linguagem, uma API (Application Programing Interface) e bibliotecas para que eles implementem drivers que permitam a execução de OpenCL em seus disposi-tivos. O OpenCL foi criado com o objetivo de ser executado em plataformas heterogêneas como processadores convencionais e GPUs.
Este trabalho usa OpenCL por dois motivos: o primeiro e principal deles é que, ao contrário do CUDA, que só está disponível para os dispositivos da NVIDIA, o OpenCL pode ser executado em uma gama extremamente diversa de dispositivos, incluindo GPUs, CPUs e FPGAs (Field Programmable Gate Array) [11]; já o segundo motivo é que o CUDA desenvolvido unicamente pela NVIDIA é uma linguagem proprietária, enquanto que o OpenCL é livre e mantido por um consórcio de empresas chamado Khronos.
Antes de continuarmos com a descrição do modelo OpenCL vamos introduzir alguns termos:
• Contexto: O ambiente em que o kernel é executado e onde a sincronização e o gerenciamento de memória é definido. O contexto inclui um conjunto de dispositivos,
a memória acessível por esses dispositivos e uma ou mais filas de comandos usada para escalonar a execução de kernels ou operações de memória.
• work-group: Uma coleção de work-items que são executados em uma única unidade de computação.
• work-item: Uma coleção de execuções paralelas do kernel invocada no dispositivo pelo host. Um work-item é executado por um ou mais elementos de processamento que é parte de um work-group que executa em uma unidade de computação.
4.1.1
Plataforma OpenCL
A plataforma sobre qual o OpenCL é executado é mostrada na Figura 4.1 e consiste de:
• Uma máquina host, conectada a um ou mais dispositivos de computação e respon-sável por fornecer instruções a serem executadas nestes dispositivos.
• Dispositivos de Computação, capazes de receber e executar programas em OpenCL enviados pelo host. Um dispositivo de computação é formado por uma ou mais unidades de computação.
• Unidades de computação são conjuntos de elementos de processamento.
• Elementos de processamento (EP) são os processadores responsáveis pela computa-ção.
EPs de uma mesma unidade de computação executam os mesmos conjunto de ins-truções, podendo se comportar como um sistema SIMD (Single Instruction Multiple Data) [19]. No momento da execução em um dispositivo, as unidades de computação são mapeadas para a arquitetura do dispositivo.
4.1.2
Modelo de execução OpenCL
A execução de um programa OpenCL é feita em duas partes: kernels que executam em um ou mais dispositivos OpenCL e o programa do host, que define um contexto para a execução dos kernels. Esse contexto contém os seguintes elementos:
• Dispositivos: O conjunto de dispositivos usados pelo host.
• Kernels: As funções que são executadas nos dispositivos OpenCL.
• Objetos de programa: O código fonte e o executável que implementa o kernel. • Objetos de memória: O conjunto de objetos de memória visíveis pelo host e pelos
dispositivos OpenCL. Os objetos de memória contêm valores que serão computados por uma instância de um kernel.
. . . . . . . . . . . . . . . . . . . . . . Host . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dispositivo de Computação Dispositivo de Computação
Unidade de computação
EP
Figura 4.1: Modelo da Plataforma OpenCL.
O contexto é manipulado pelo host ; através de chamadas da API do OpenCL, o host cria uma estrutura de dados chamada de fila de comandos para coordenar a execução de kernels nos dispositivos. O host envia comandos para a fila de comandos que são escalonados para serem executados em dispositivos disponíveis no contexto.
Quando um kernel é submetido pelo host, um espaço de execução é definido pelo usuário e um work-item é definido para cada ponto com coordenadas inteiras reais e não negativas neste espaço. Cada work-item tem, como identificação, as suas coordenadas neste espaço; work-groups também possuem um identificador único. Essas identificações são usadas para determinar por quais partes do problema cada work-item deve ser res-ponsável.
4.1.3
Modelo de programação OpenCL
Divide-se o modelo de execução OpenCL em dois tipos:
• Baseado no paralelismo de tarefas, no qual apenas uma instância de um kernel é executada, ou seja, um work-group com um work-item. O paralelismo é explorado, por exemplo, enfileirando vários kernels para serem executados nos dispositivos disponíveis.
• Baseado no paralelismo de dados, no qual a computação é definida em termos de sequências de instruções aplicadas a vários elementos da memória. Work-items x e y referentes ao mesmo kernel calculam posições diferentes de memória, definidas
pelos seus identificadores de work-item e work-group. Esse é o modelo utilizado para as implementações deste trabalho, já que é ideal para GPUs.
Todos os work-items associados a um mesmo kernel executam o mesmo código e work-items de um mesmo work-group são executados em paralelo. Embora o nível de paralelismo seja alto, o OpenCL permite a sincronização de work-items de um mesmo work-group através de barreiras. Já os work-groups não possuem sincronismo entre si.
4.1.4
Modelo de memória
Um work-item de um kernel tem acesso a quatro regiões de memoria, tais regiões são descritas abaixo.
• Global: Região da memória que pode ser acessada por qualquer work-item do espaço de execução.
• Constante: Região da memória que pode ser acessada por qualquer work-item, mas não pode ser alterada durante a execução do kernel.
• Local : Região da memória visível entre todos os items de um mesmo work-group.
• Exclusiva: Região de memória exclusiva a um work-item.
4.2
Implementação do método CMP
Nesta seção, são discutidos aspectos da implementação em OpenCL do método CMP. O primeiro aspecto a se determinar antes de fazer uma implementação paralela de um algoritmo é em que partes do código o algoritmo consome mais tempo. Para isso foi feito um experimento simples utilizando a ferramenta perf e os resultados desse experimento mostram que 96% do tempo de execução da implementação do método CMP, usando OpenMP [12], são gastos fazendo o cálculo da semblance.
Com base nesse resultado, o foco da implementação descrita neste capítulo é im-plementar o cálculo da semblance de maneira eficiente em GPUs. Para realizar uma implementação eficiente em uma GPU, dois fatores são importantes: primeiro, o quão paralelo o algoritmo é; normalmente essa característica é intrínseca ao problema. No caso do CMP isso não é um problema, uma vez que a busca por parâmetros CMP é extrema-mente paralelizável. O segundo favor é o acesso coalescido à memória global da GPU, que é essencial para conseguir uma boa largura de banda com a memória global [16, 35, 37], de sorte que tal característica depende da implementação. Este capítulo explica como o acesso coalescido é realizado para implementação descrita nesta seção.
A implementação em OpenCL funciona da seguinte forma: primeiro organiza-se os traços em gathers CMP; segundo organiza-se Ngathers gathers CMP na forma de um cubo, como mostra a Figura 4.2, onde N gather ∈ {64, 128, 256, 512}; e então envia-se N gather para a GPU, a fim de processar os N gather, e repete-se o processo até não haver mais gathers CMP para serem processados.
Abaixo está descrito como a computação é mapeada para o modelo OpenCL. Tal mapeamento foi feito com o objetivo de possibilitar o acesso coalescido e aumentar o paralelismo na GPUs.
Figura 4.2: Cubo de dados que mostra em suas arestas os gathers CMPs, amostras e traços.
• Um t0 por work-group: dessa forma, computa-se um t0 para cada gather em paralelo
e essa organização também ajuda a realizar o acesso coalescido.
• Um gather por work-item: dessa maneira, pode-se computar vários gathers em paralelo e assim é simples realizar o acesso coalescido dos work-items.
• nc semblance por work-item: cada work-item é responsável pelo cálculo das sem-blance para cada c, dessa forma, se aumenta o paralelismo.
Essa organização proposta não exige nenhum tipo de sincronia e não gera nenhuma condição de corrida entre nenhum dos work-groups e work-itens. Com isso, a implemen-tação não exige nenhum tipo de barreira ou uso de instruções atômicas,1 sem mencionar que tal organização usa de maneira eficiente os recursos de hardware das GPUs.
4.3
Implementação do método CRS
A implementação OpenCL do método CRS é chamada de CRS-OpenCL será discutida nesta seção.
Como ocorre com o algoritmo do método CMP, o algoritmo do método CRS também tem o gargalo no cálculo da semblance, e como os algoritmos propostos para o CMP e CRS são muito parecidos, suas implementações em OpenCL também serão muito parecidas, com poucos detalhes diferentes, dessa forma a descrição do CRS-OpenCL será muito semelhante a do CMP-OpenCL. Temos duas diferenças na organização do paralelismo da 1Uma instrução que garante a correção de uma operação na memória mesmo quando tal posição é
implementação CMP-OpenCL e a CRS-OpenCL a primeira é que em vez de se testar um c por semblance se testa uma tripla {a,b,c}, a segunda diferença é o tamanho dos gathers, que é maior, já que para o CRS também temos que olhar os traços com ponto médio na vizinhança de m0.
4.4
Organização da memória
Nesta seção, são discutidos os métodos utilizados para realizar o acesso coalescido nas implementações em OpenCL do CMP e do CRS. As implementações organizam os dados, como mostra o cubo da Figura 4.2. O cubo é organizado da seguinte forma: temos vários gathers CMP; cada gather tem vários traços e cada traço contém várias amostras; dessa forma, tem-se um cubo de amostras dos traços. Esse cubo é mapeado para uma estrutura no código OpenCL, que é um vetor de uma dimensão, onde pode-se encontrar a amostra i do traço j da gather CMP k, usando-se a Equação 4.1.
p = i ∗ (sj ∗ sk) + j ∗ sk + k (4.1) onde :
• p: posição do vetor que representa o cubo na implementação OpenCL. • sj: quantidade de traços no gather CMP.
• sk: quantidade de gathers CMP.
• j: índice do traço que se deseja acessar a amostra. • i: índice da amostra no traço que se deseja acessar. • k: índice do gather CMP que se deseja acessar.
Podemos ver como o acesso de memória é feito no kernel OpenCL descrito nas linhas 10 e 11 do código 4.1. 1 for (int t r _ i d x = 0; t r _ i d x < n t r a c e s ; t r _ i d x ++) { 2 . 3 . 4 . 5 f l o a t t = t i m e 2 d ( C , t0 . . .) ;
6 int it = (int) ( t * idt ) ;
7 if ( it - tau >= 0 && it + tau +1 < ns ) {
8 for (int j = 0; j < w ; j ++) { 9 int k = it + j - tau ; 10 f l o a t d1 = c u b e [ p o s 3 d ( k , tr_idx , g a t h e r _ i d x , M A X _ N T R S , ng ) ]; 11 f l o a t d2 = c u b e [ p o s 3 d ( k +1 , tr_idx , g a t h e r _ i d x , M A X _ N T R S , ng ) ]; 12 f l o a t v = i n t e r p o l _ l i n e a r ( k , k +1 , d1 , d2 , t * idt + j - tau ) ; 13 num [ j ] += v ; 14 den += v * v ;
15 s t a c k _ v a l u e += v ; 16 } 17 M ++; 18 } e l s e if (++ s k ip == 2) { 19 v a l i d = 1; 20 } 21 }
Código 4.1: Trecho do kernel que calcula semblance para o CMP e CRS
No código 4.1 temos as seguintes variáveis importantes para o cálculo da amostra que será acessada:
• tr_idx : índice do traço no cubo. • gather_idx: índice da família no cubo. • k: índice da amostra dentro da janela w. • t: amostra de tempo.
• ntraces: quantidade de traços em uma família.
Vamos mostrar abaixo como o acesso dos work-items pertencentes ao mesmo work-group ocorre na estrutura de dados cube no código 4.1. Vamos usar como exemplo o acesso que é mostrado na Figura 4.2.
Nas linhas 16 e 17 do trecho de código 4.1, têm-se dois acessos à memória cruciais para o cálculo da semblance, já que são os dados usados para calcular as amplitudes para o traço tr_idx para o tempo de trânsito t, onde pos3d é uma função que faz exatamente o cálculo da Equação 4.1. Dessa forma, o acesso dos work-items de um mesmo work-group pode acontecer como mostra a Figura 4.2, onde temos 6 work-items, onde o work-item i acessa a amostra wi.
4.5
Implementação da estimativa de parâmetros para
a migração CRP
O método CRP é semelhante ao CMP e CRS, como podemos ver na Seção 2.3.2; porém, utilizaremos outra estratégia para a sua implementação em OpenCL.
A implementação do CRP é feita da seguinte forma. Primeiro, todos os traços em uma matriz são organizados e enviados para o dispositivo OpenCL. Após a execução, o kernel OpenCL retorna um par {a,v} para cada par {x,t}, onde x ∈ X e t ∈ T .
• um work-group para cada t ∈ T : dessa forma, pode-se executar o DE com um t diferente para cada work-group;
• um work-item por x ∈ X: dessa forma, pode-se executar o DE para cada x inde-pendentemente para cada work-item.
Com a organização acima, pode-se executar o DE em paralelo para cada par {x,t}. Por motivos de limitação de hardware, o processamento é limitado para no máximo 256 x diferentes por vez, que é o máximo de work-itens que um dos nossos dispositivos usados nos experimentos pode executar.
Capítulo 5
Resultado experimentais
Neste capítulo, a proposta do trabalho é validada baseando-se na apresentação dos resultados de desempenho obtidos a partir das implementações dos métodos CMP, CRS e migração CRP em tempo, escritas em OpenMP e OpenCL. Além disso, também discu-timos sobre a corretude das implementações realizadas. Ademais, as implementações do CRS e do CMP que são usadas nos testes de desempenho deste capítulo realizam a busca de parâmetros e o empilhamento.
5.1
Metodologia
Os hardwares e os softwares utilizados nos experimentos são descritos na seção 5.2. São realizados 30 experimentos para cada implementação em OpenCL e para cada hardware. Para as implementações do CRS e do CMP, ainda se tem essa repetição para cada tamanho de gather que podem ser 64, 128, 256, 5121. Os resultados são mostrados em tabelas com
os ganhos de desempenho relativos entre cada hardware e em gráficos com o tempo médio de execução para cada hardware; além disso, os gráficos também mostram o desvio padrão para cada experimento. Todos os experimentos realizados utilizam a flag de compilação -O3. Para facilitar a reprodução deste trabalho, disponibilizamos os códigos usados nos experimentos em um repositório público2. As implementações do CMP, CRS e CRP
discutidas nesse capítulo são validadas com implementações fornecidas pelo HPG (High Performance Geophysics ) [4].
5.2
Materiais
Nesta seção são descritas as plataformas, aceleradores de hardware e dados de entrada e softwares utilizados nos experimentos. Primeiro, tem-se a Tabela 5.1, que descreve cada uma das plataformas que são utilizadas para realizar os experimentos. A Tabela 5.2 con-tém a descrição mais detalhada dos processadores e aceleradores utilizados. A Tabela 5.3 contém a intensidade operacional mínima para alcançar o desempenho máximo, quando 1menos para a GPU Radeon R9 290x, já que por alguma restrição, de hardware ou software, o número
máximo de work itens do OpenCL é de 256
se tem a máxima largura banda de cada dispositivo listado na Tabela 5.1. Além disso, os dados usados em todos os testes estão em formato Seismic Unix [23]. Utilizam-se três dados sísmicos para realizar os experimentos de desempenho das implementações do CMP, CRS e migração CRP em tempo. Dois são sintéticos e um é referente a um dado real. Os sintéticos são chamados de Simple-synthetic e Micro-synthetic, enquanto que o referente ao dado real é chamado de Jequitinhonha, já que é um dado sísmico extraído da bacia do Jequitinhonha. Abaixo são listados os softwares usados nos experimentos, tanto nos de desempenho, quanto nos de corretude:
• perf : utilizado para se colher estatísticas de eventos de hardware, para se tirar conclusões sobre o desempenho das implementações em CPU.
• gcc-4.4.7, gcc-4.84, nvcc v7.5: compiladores utilizados.
• Pacote de softwares Seismic Unix : utilizado para gerar imagens a partir dos arquivos de saída das implementações e assim, auxiliar em se determinar a corretude das implementações aqui propostas.
• CodeXL 15: utilizado para se colher estatísticas sobre eventos de hardware das GPUs da AMD, com o objetivo de reunir evidencias para conclusões acerca dos resultados de desempenho.
Plataformas 1 2 3 4 5
Host Processador 2 x Intel Xeon 1 x Intel Xeon 1x Intel Xeon
E5-2670 v2 E5-2630 v2 E5-2670 v3
Memória DDR3 64 GB DDR3 32 GB DDR3 64 GB
SO Red Hat 4.4.7-16 Ubuntu 14.04 SUSE Enterprise
Server 12 SP1
Compilador gcc 4.8.4 gcc 4.8.4 nvcc-8.0 nvcc-7.5
Runtime OpenCL Runtime 14.2 AMD
OpenCL 2.0 OpenCL 1.2 CUDA 8.0 OpenCL 1.2 CUDA 7.5 Drivers Driver (3.1.2-1) Driver (17) Driver (375) Driver (352.93)
Aceleradores Modelo Xeon Phi
3120 Radeon R9 290x GTX 770 GTX Titan Tesla K20 Tesla K40 Mem. Band.(GB/s) 240 320 224.3 288.4 250 288 Núcleos 57 cores 2816 1536 2688 2496 2880 Frequência(GHz) 1,1 1,04 1,05 0,84 0,705 0,745
Hardware Potência (W) Número de processadores Núcleos por processador Threads por núcleo Pico de Desempenho GFLOPS Xeon E5-2670 230 2 8 2 883,2 Xeon Phi 300 57 1 4 1000 GTX Titan 210 14 192 - 4500 GTX 770 193 8 192 - 3213 R9 290x 185 44 64 - 5632 Xeon E5-2630 80 1 6 2 249,6 Tesla K20 225 13 192 - 3950 Tesla K40 235 15 192 - 4290
Tabela 5.2: Características dos processadores e dos aceleradores usados nos experimentos.
Dispositivo E5-2670 E5-2630 GTX-770 GTX-Titan R9-290x Tesla K20 Tesla K40 Intensidade
operacional 17,28 5,8 14,31 15,6 17,6 15,8 14,9
Tabela 5.3: Intensidade operacional mínima para se atingir o desempenho máximo no dispositivo, supondo o pico na largura de banda da memória.
5.3
Validação de resultados
As figuras 5.1 e 5.2 mostram o resultado do empilhamento CMP do dado Simple-synthetic utilizando-se a CPU e a GPU, respectivamente. Apesar da semelhança, estas imagens possuem diferenças sutis em alguns dos pontos computados.
A Figura 5.3 é a diferença entre as figuras do empilhamento. Essa figura exibe uma diferença, mas essa diferença é muito sutil para ser vista a olho nu com essa resolução. No entanto, o histograma da Figura 5.3 mostra que essas diferenças ocorrem com frequências muito mais altas em bits menos significativos do que em bits mais significativos. Com o uso de uma ferramenta chamada suximage, pode-se ver que a diferença gerada por esses bits é de no máximo 0.0003884.
A primeira hipótese para tais diferenças é que elas são ocasionadas por erros numéri-cos devido a diferentes implementações do padrão IEEE-754-2008 [2]. Para avaliar essa hipótese, foram realizados dois experimentos que estão descritos abaixo:
• Experimento 1: Simplesmente usar ponto flutuante de precisão dupla. Dessa forma, os resultados das implementações se mostraram iguais.
• Experimento 2: Localizar os pontos da imagem gerada que são diferentes e depois analisar qual é a causa dessa diferença.
0 1 2 3 4 5 100 200 300 400 -1 0 1 2 3 4 x10 -4
Figura 5.1: Empilhamento reali-zado na CPU. 0 1 2 3 4 5 100 200 300 400 -1 0 1 2 3 4 x10 -4
Figura 5.2: Empilhamento reali-zado na GPU. 0 1 2 3 4 5 100 200 300 400 -4 -3 -2 -1 0 1 2 3 4 x10 -4 0 5 10 15 20 25 30 35 40 45 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Bits Porcentagem de pontos errados
Figura 5.3: Diferença entre as Figuras 5.1 e 5.2; a primeira imagem mostra a imagem resultante da subtração da imagem 5.1 e 5.2 e a segunda é o histograma da diferença.
O experimento 1 fornece fortes evidências de que a diferença observada é oriunda de erro numérico, mas ainda assim não fornece informações suficientes para concluir quais operações estão gerando tal erro. Os resultados do experimento 2, por sua vez, indicam que a diferença encontrada é oriunda do trecho de código que implementa o algoritmo 2. Neste trecho de código tem-se as seguintes operações:
1. t2 *= t2
2. t2 += C * (hx*hx + hy*hy) 3. sqrt(t2)
