Dado Sintético

Para facilitar os testes e a comparação dos resultados, foi utilizado um único dado sísmico sintético 2D. Entretanto, com ele foi possível simular, devido ao seu tamanho, diferentes volumes de dados sísmicos. Com isso conseguimos ver como o volume influencia na performance do algoritmo. O dado em questão foi criado e fornecido com cortesia pela

BP (BILLETTE; BRANDSBERG-DAHL, 2005) para uso acadêmico.

O dado se trata de uma linha sísmica marítima sintética 2D criada a partir do modelo de velocidade, representado pela Figura 5.1. A Figura 5.2 mostra uma seção empilhada dessa mesma linha. Como dito anteriormente, o objetivo da análise de velocidade é obter um campo de velocidade, a partir dos dados pré-empilhamento, que gere uma seção mais fidedigna da subsuperfície da terra. Portanto, o uso de dados sintéticos, aonde normal- mente conhecemos o campo de velocidade, ajuda na avaliação da ferramenta usada.

1_{Pacote de processamento sísmico de código livre desenvolvido mantido pela Center for Wave Pheno-}

Figura 5.1: Mo delo de velo cidade do dado da BP ,com 67km no eixo x e 12km no eixo y. Fon te: gerado pelo autor.

Figura 5.2: Seção empilhada do dado da BP ,tendo as mesmas dimensõ es do mo delo de velo ci dade. Fon te: gerado pelo autor.

Todos os dados sísmicos tem características importantes que devem ser informadas para uma análise mais completa dos resultados. Elas dão uma dimensão do problema enfrentado. Os dados sísmicos são digitalizados no momento do registro. Dessa forma, podemos olhar para esses dados como vetores ou matrizes, dependendo apenas do domínio analisado. A Tabela 3 mostra as principais informações do conjunto de dados utilizado neste trabalho. Razão de amostragem (DT) 6ms Número de amostras (NS) 2001 Número de traços 1.529.398 Números de CDPs 10784 Offset mínimo 0m Offset máximo 15.000m Cobertura nominal do CDP 150 Volume 11,6GB

Tabela 3: Características do conjunto de dados.

Algumas informações podem ser deduzidas apenas olhando a tabela de características dos dados. Uma delas é a quantidade de pixels que uma seção empilhada terá, nesse caso, com 10784 CDPs e 2001 NS. O tamanho da imagem resultante é calculado pelo produto entre NS e CDPs, tendo neste caso 21.578.784 pixels. Existem diversos tamanhos de linhas sísmicas 2D, e o tamanho do conjunto de dados utilizado nos permite simular linhas sísmicas com diversos tamanhos, podendo assim analisar como o volume dos dados influencia nos speedups dos algoritmos paralelos.

5.2

Experimentos

Para os experimentos foram utilizados os seguintes hardwares: PC-1: CPU I7-7700 3.60GHz com 4 núcleos e 8 threads, com 16Gb de Ram e HD de 1TB 7200 RPM SATA 3.1 (6Gb/s). Para os testes sequenciais e paralelos com o OpenMP e para os testes paralelos em CUDA, fora usadas as GPUs listadas na tabela 4.

Foram utilizadas duas metodologias para medir os tempos de execução, para a Versão 3 CVS (CPU, OMP e CUDA) e a Versão Semblance, os tempos foram medidos utilizando o programa Time do Ubuntu 16.04, onde foram executados uma série de testes para todas as versões e ao final, foi calculado o tempo médio de todas elas. Dessa forma, foi tentou-se minimizar a influência do uso da CPU por outros processos. Para a Versão 4 foi utilizado a biblioteca QTime provida pelo QT. Novamente, foi calculado o tempo médio após a

execução de diversos teste.

GPU CUDA Cores Basic clock Memory Memory speed Capability major

GTX 980 2048 1126 MHz 4GB 7Gbps 5.2

GTX 1080 2560 1606 MHZ 8GB 10Gbps 6.1

GTX 1080TI 3584 1586 MHz 11GB 11Gbps 6.1

Tabela 4: Detalhes das GPUs utilizadas.

Como dois algoritmos foram avaliados e eles trabalham em domínios diferentes, foram criados conjuntos de dados diferentes para cada. O Algoritmo 2, que implementa o sem- blance, foi o primeiro a ser testado. Como ele trabalha no domínio CDP, foram simuladas quatro agrupamentos CDPs com diferentes coberturas. Desta forma, a influência do vo- lume processado fica mais clara na análise da performance. A Tabela 5 mostra os detalhes dos conjuntos de dados. É possível notar que a quantidade de traços é elevada, porém, para volumes 3D ou CDP gathers com janelas grandes de agrupamentos (junção de 2 ou mais CDPs), podemos facilmente chegar nesses números.

Teste Cobertura do agrupamento CDP

1 450

2 751

3 1351

4 3153

Tabela 5: Testes executados para o algoritmo do semblance.

O Algoritmo 3, que implementa o CVS, é computacionalmente mais caro. Enquanto o algoritmo anterior trabalha em uma pequena parte do volume de dados original, esse, na teoria, trabalha no volume todo, salvo quando há limitações da memória do hardware. Foram implementadas duas versões finais CUDA (3 e 4) para esse algoritmo e, como elas usam o mesmo domínio de dados, não foi necessário criar dois conjuntos de dados para os testes. Essas duas versões se diferem apenas em um ponto, a versão 3 gera um painel para cada velocidade que está na lista, enquanto que a versão 4 gera apenas um painel para a velocidade indicada. Em outras palavras, a versão 3 gera todas as seções em uma requisição, servindo para programas que utilizam dados pré calculados, e a versão 4, é utilizada por programas que fazem as requisições em tempo de execução, sendo todo o

processamento feito pela GPU. Esse pequeno detalhe gera grande diferença na forma de implementar para o CUDA. Os conjuntos de dados criados estão listados na Tabela 6. Como o dado sintético era demasiadamente grande, para a versão 4 isso era um problema, visto que ela depende da memória da GPU para conseguir carregar todo o dado, foram simulados diversos volumes, partindo de volumes de dados menores, onde normalmente as diferenças de performance entre CPU e GPU são pequenas, à situações com volumes maiores onde as diferenças de performances se acentuam.

Teste Número de CDPs Número de traços Volume Volume do CVS

1 10 1,498 11MB 12,7MB 2 50 7.506 59MB 42,7MB 3 500 75.062 590MB 600MB 4 1000 150.125 1,2GB 1,2GB 5 2000 300.250 2,4GB 2,4GB 6 3000 450.375 3,5GB 3,6GB 7 4000 600.500 4,7GB 4,8GB 8 5000 750.625 5,8GB 6GB

Tabela 6: Testes executados para o algoritmo CVS. O volume CVS foi calculado levando-se em conta o número de 151 velocidades distintas (faixa de 1500 a 6000m/s com incrementos de 30m/s).

Em todos os testes foram utilizadas 3 versões de implementação: CPU sequencial, CPU OMP com 4 núcleos e CUDA. Portanto, os gráficos e tabelas com as comparações e resultados irão conter as três.

5.3

Resultados

O primeiro conjunto de testes executados foram os da Tabela 5. Parâmetro dos testes: velocidade mínima de 1000m/s, velocidade máxima de 7000m/s e incremento de veloci- dade de 30m/s. Na comparação foi levado em consideração o tempo total da execução, ou seja, o tempo de todas as etapas das versões foram computados. A Figura 5.3 mostra tempo total da execução enquanto que a Figura 5.4 mostra os speedups atingidos.

Figura 5.3: O gráfico apresenta os tempos de execução das versões implementadas para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo autor.

Figura 5.4: O gráfico apresenta o speedup das versões implementadas para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo autor.

Analisando os resultamos fica claro que na medida em que o volume de dados pro- cessados aumenta, o algoritmo em GPU obtém uma melhor performance em relação aos demais. Uma das análises feitas diante disso, é que a GPU provavelmente está sendo sub-utilizada. Existem vários motivos para isso, um deles está relacionado à quantidade de cálculos enviados à GPU, pois normalmente a GPU precisa de grandes volumes de cálculos para poder sobressair o tempo de cópia dos dados. Conseguir enviar uma grande quantidade de cálculos de uma única vez é um dos pontos chaves para se conseguir um bom desempenho. No entanto, esse ponto fica enrijecido ao dado de entrada. Outro motivo é disparar kernels com baixa quantidade de threads devido a uma baixa paralelização do

seu código. Diante disso e dos resultados, o primeiro motivo acaba sendo o mais prová- vel, visto que na medida em que o volume de dados aumenta o speedup também aumenta, mostrando que existe uma folga na utilização da GPU. O ganho alcançado nesse algoritmo foi satisfatório, porém ainda há espaço para otimizações.

Antes de iniciar a análise dos resultados da Versão 3, vale ressaltar a evolução obtida ao longo do caminho. Abaixo estão listados os speedups alcançados das versões OpenMP, Versão 1, Versão 2 e Versão 3, todos em relação à Versão sequencial executada na CPU. A primeira versão em CUDA, de acordo com a Tabela 7, praticamente não teve ganho de performance. O principal motivo é o baixo paralelismo que ela tem. Olhando para a terceira coluna dessa tabela essa versão executa 2001 (NS) operações por kernel, isso quer dizer que apenas o loop mais interno do Algoritmo 3 foi paralelizado. Claramente essa versão estava longe do ideal. Na Versão 2, o principal objetivo era aumentar nível de paralelismo do código. Voltando os olhos novamente para o Algoritmo 3, ele pode ser definido como um problema de 3 dimensões, sendo elas, as amostras do traço sísmico, a lista de velocidades e os traços sísmicos de entrada. Com o objetivo definido e com uma dimensão já paralelizada, a Versão 2 paralelizou a dimensão da lista de velocidades. Dessa forma, o código passou a usar kernels 2D executando um total de (NS* Número de velo- cidades) operações, o speedup alcançado já foi mais expressivo, no entanto, ainda faltava trabalhar em uma dimensão, a dos traços de entrada. Devido ao problema enfrentado não foi possível paralelizar por completo essa dimensão, por esse motivo ela foi fracionada por agrupamentos CDP. A Versão 3 então passou a usar kernels que executavam (NS * Número de velocidade * Cobertura do CDP) operações.

Versão Speed UP Operações por kernel

OpenMP 6.88 -

Cuda V1 1,06 2001

Cuda V2 68,47 300.150

Cuda V3 102,39 45.022.500

Tabela 7: Speed UP médio dos testes executados em relação a versão CPU. Parâmetros usados: velocidade mínima de 1500 m/s, velocidade máxima de 6000 m/s e incremento de velocidade de 30 m/s.

Para o segundo conjunto de testes (Tabela 6), especificamente para Versão 3, foram utilizados os seguintes parâmetros: velocidade mínima de 1500m/s, velocidade máxima de 6000m/s e incremento de velocidade de 30m/s. Para estes testes, a comparação tam- bém levou em consideração o tempo total da aplicação. As Figuras 5.5 e 5.6 mostram, respectivamente, o tempo de execução e speedup para os 8 testes diferentes. A diferença

de speedups entre o Semblance e o CVS são bem relevantes. No entanto, é facilmente explicada pelos volumes processados por cada um. Para ter uma noção dessa diferença, o número de cálculos executados pelos testes mais caros, o 4 para o cálculo do semblance e o 8 para o cálculo do CVS, são 1.261.830.600 e 225.300.093.750 respectivamente, uma razão de aproximadamente 178 vezes.

Figura 5.5: O gráfico apresenta, em escala logarítmica, os tempos de execução da Versão 3 para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo autor.

Figura 5.6: O gráfico apresenta o speedup da Versão 3 para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo autor.

Novamente a diferença de volumes mostra o crescimento do speedup. Porém, mais su- ave para grandes volumes. Isso indica que para esse kernel a GPU está tento praticamente o mesmo trabalho, a tendência é que o speedup se estabilize à medida em que o volume processado aumenta.

O speedup atingido nessa versão foi realmente surpreendente. Conseguir reduzir o tempo gasto no processamento sísmico, consequentemente na exploração sísmica, é um do principais objetivos da indústria. O uso da GPU está cada vez mais presente na indústria do petróleo, sendo usada em todos os seus setores, e esse tipo de trabalho disseminou ainda mais a abrangência do seu uso. A próxima versão foi pensada exatamente a partir desse trabalho, o que mostra a importância do estudo contínuo de aceleradores gráficos.

A Versão 4 trouxe uma nova forma de apresentar o problema para o usuário final. Onde ele, em tempo de execução, a cada requisição, analisa uma seção empilhada com velocidade constante. Esse novo método precisa que todo o dado de entrada esteja na memória para conseguir funcionar. Como a metodologia proposta transfere apenas uma vez os dados de entrada para a GPU, o tempo dessa transferência não foi incluído nas comparações abaixo. O código sequencial escrito foi baseado em dois programas do Seismic Unix: sunmo2

e sustack3_{. Para o cálculo do speedup foram utilizados os tempos da aplicação do NMO}

e empilhamento do dado para todas as versões (CPU, OpenMP e CUDA). Além desses dois tempos, para a versão CUDA, o tempo de cópia da seção empilhada para a CPU foi incluído também. É possível ver na Figura 5.8 que o speedup alcançado foi ainda maior que os anteriores. A explicação para isso está no kernel usado, sendo necessário apenas um para realizar todo o processo. Para ter noção do tempo de cópia omitido, foi selecionado o teste que requer maior esforço do hardware e medido esse tempo. Para o teste 8, a cópia dos dados levou 493 milissegundos e teve um throughput de 12.5 GB/s.

Figura 5.7: O gráfico apresenta, em escala logarítmica, os tempos de execução da Versão 4 para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo autor.

2_{Programa que aplica a correção normal moveout para um conjunto CMP.}

Figura 5.8: O gráfico apresenta o speedup da Versão 4 para cada teste, usando a GPU GTX 1080. Fonte: gerado pelo autor.

O que chamou atenção nessa versão foi a performance atingida, que possibilita a utilização interativa do método proposto. O tempo que a GPU gasta para aplicar o NMO e realizar o empilhamento é muito baixo até para grandes volumes. Com o teste 8, se tentou atingir o máximo de desempenho da GPU.

Sabemos que o speedup pode variar de acordo com a GPU utilizada. Esse entendi- mento é facilmente comprovado quando olhamos para as suas especificações, que variam muito de acordo com o modelo. As principais especificações das GPUs são a quantidade de núcleos CUDA, o Clock básico, a quantidade de memória, a velocidade da memória e a CUDA Capability Major. Para mostrar como o speedup pode variar de acordo com a placa, foram utilizadas 3 GPUs, a GTX 980, GTX 1080 (usada nos testes anteriores) e a GTX 1080TI, cujas especificações estão listados na Tabela 4.

Os resultados obtidos nas três placas se comportaram como o esperado, onde os me- lhores foram na GTX 1080TI seguidos da GTX 1080 e GTX 980. Esse comportamento, mais uma vez, é compreensível quando olhamos as especificações das placas. Abaixo são listados os tempos médios de cada um dos testes das Tabelas 6 e 5 nas Tabelas 8 e 9, respectivamente. As Figuras 5.9 e 5.10 mostram os tempos de execução das três placas para os cenários de teste listados nas Tabelas 8 e 9, respectivamente. Um dos problemas enfrentados nesse teste foi que a GTX 980 não conseguiu executar os testes 7 e 8 da Ta- bela 6 na Versão 4 do algoritmo paralelo devido à sua memória ser de 4GB. Dois pontos que devem ser levados em consideração é que o método precisa alocar dados auxiliares além do volume de entrada, e que se a placa utilizada for a mesma usada pelo sistema operacional, recomenda-se que os programas CUDA deixem uma parte da memória da

GPU livre para outras tarefas do sistema. Dessa forma, o volume máximo de dado para esse método é de 90% da memória da GPU.

Versão do Teste 1 Teste 2 Teste 3 Teste 4 Algoritmo CPU 1,56 2,54 4,56 10,67 OMP 0,53 0,89 1,60 3,73 GTX 980 0,17 0,18 0,18 0,23 GTX 1080 0,15 0,16 0,17 0,21 GTX 1080TI 0,13 0,14 0,15 0,18

Tabela 8: Tempos de execução (em milissegundos) para os testes do Semblance.

Versão do Teste Teste Teste Teste Teste Teste Teste Teste

Algoritmo 1 2 3 4 5 6 7 8 CPU 27,85 138 1370 2739 5534 8257 10974 13765 OMP 9,50 41,30 391,9 784,3 1565,9 2331,7 3122,07 3910,1 GTX 980 0,15 0,48 4,360 8,60 17,23 25,20 - - GTX 1080 0,13 0,40 3,77 7,40 14,75 21,65 28,30 34.86 GTX 1080TI 0,10 0,29 2,64 5,26 10,43 15,28 20,44 25,33 Tabela 9: Tempos de execução (em milissegundos) para os testes do CVS Versão 4.

Figura 5.9: O gráfico apresenta os tempos médios gasto para cada GPU em todos os testes da Tabela 5. Fonte: gerado pelo autor.

Figura 5.10: O gráfico apresenta os tempos médios, da Versão 4, gasto para cada GPU em todos os testes da Tabela 6 , com exceção dos testes 7 e 8 para a GTX 980. Fonte: gerado pelo autor.

Uma das premissas do método de análise de velocidade em tempo de execução é a necessidade de fluidez entre as exibições das seções sísmicas para o usuário. Nós definimos a taxa de FPS mínima desejável como sendo 24 FPS, com a qual é possível atingir uma boa fluidez, sem que o usuário tenha sensação de delay na atualização das imagens processadas. Analisando a Tabela 9, vemos que todas as placas gráficas conseguiram atingir a meta de 24 FPS. Apesar da versão OMP conseguir uma redução no tempo de execução, ela não foi suficiente para chegar no FPS mínimo. Ainda nessa tabela, o teste 1 conseguiu atingir o FPS mínimo em todas as versões. No entanto, esse teste foi feito apenas para mostrar o desempenho em diferentes volumes de dados. Como esse teste tem apenas 10 CDPs, ele foge de um dos objetivos da análise de velocidade utilizando o CVS, que é poder ver a variação lateral de velocidade.

Com os avanços das GPUs, é natural que as placas mais atuais consigam melhores desempenhos. Afim de mostrar essa diferença, as Figuras 5.11 e 5.12, mostram as compa- rações de desempenho entre as GPUs testadas. Nas comparações, é possível ver que para o cálculo do semblance a diferença de desempenho entre as GPUs é menor em relação ao cálculo do CVS. Uma das razões para isso acontecer, é a diferença de cálculos utilizados entre os métodos, já que no algoritmo CVS, devido ao volume de dados, a GPU é mantida ocupada (fazendo cálculos) por mais tempo.

Figura 5.11: O gráfico apresenta os speedups entre os desempenhos obtidos usando as GPUs para o algoritmo do semblance. Fonte: gerado pelo autor.

Figura 5.12: O gráfico apresenta os speedups entre os desempenhos obtidos usando as GPUs para o algoritmo do CVS Versão 4. Fonte: gerado pelo autor.