williansoaress
commented
5 years ago Leitura de artigos
THE NAS PARALLEL BENCHMARKS D Bailey E Barszcz J Barton D Browning R Carter L Dagum R Fatoohi S Fineberg P Frederickson T Lasinski R Schreiber H Simon V Venkatakrishnan and S Weeratunga RNR Technical Report RNR March
The sizes of the current benchmarks were chosen so that implementations are possible on currently available supercomputers. As parallel computer technology progresses, future releases of these benchmarks will specify larger problem sizes.
Submission of Benchmark Results - a complete submission of results should include the following: • A detailed description of the hardware and software configuration used for the benchmark runs. • A description of the implementation and algorithmic techniques used. • Source listings of the benchmark codes. • Output listings from the benchmarks.
THE KERNEL BENCHMARKS
After an evaluation of a number of large scale CFD and computational aerosciences applications on the NAS supercomputers at NASA Ames, a number of kernels were selected for the benchmark. These were supplemented by some other kernels which are intended to test specific features of parallel machines. The following benchmark set was then assembled:
EP: An “embarrassingly parallel” kernel. It provides an estimate of the upper achievable limits for floating point performance, i.e., the performance without significant interprocessor communication.
MG: A simplified multigrid kernel. It requires highly structured long distance communication and tests both short and long distance data communication.
CG: A conjugate gradient method is used to compute an approximation to the smallest eigenvalue of a large, sparse, symmetric positive definite matrix. This kernel is typical of unstructured grid computations in that it tests irregular long distance communication, employing unstructured matrix vector multiplication.
FT: A 3-D partial differential equation solution using FFTs. This kernel performs the essence of many “spectral” codes. It is a rigorous test of long-distance communication performance.
IS: A large integer sort. This kernel performs a sorting operation that is important in “particle method” codes. It tests both integer computation speed and communication performance.
These kernels involve substantially larger computations than previous kernel benchmarks, such as the Livermore Loops or Linpack, and therefore they are more appropriate for the evaluation of parallel machines.
New Implementations and Results for the NAS Parallel Benchmarks 2 Saphir, W.; van der Wijngaart, R.; Woo, A.; Yarrow, M.
The different benchmarks in the NPB 2 suite stress different aspects of the hardware and software in the computer system. For example, IS and FT require efficient implementation of the all-to-all communication routines, and need large network bandwidth to accommodate large data transfers. SP has poor data reuse, unlike BT and LU which spend a major fraction of their execution time inverting dense 5x5 matrices, so it requires high memory bandwidth. BT and LU, on the other hand, stress instruction cache and register use, due to the sizeable loops in which most of the work is performed.
NAS Parallel Benchmarks Version 2.4 van der Wijngaart, R. (October 2002) NAS Technical Report NAS-02-007, NASA Ames Research Center, Moffett Field, CA
The OpenMP Implementation of NAS Parallel Benchmarks and Its Performance rumkin, M.; Schultz, M.; Jin, H.; Yan, J., NAS Technical Report NAS-02-009, NASA Ames Research Center, Moffett Field, CA
Efficient NAS Benchmark Kernels with C++ Parallel Programming Dalvan Griebler, Junior Loff, Gabriele Mencagli, Marco Danelutto, Luiz Gustavo Fernandes
Benchmarking is a way to study the performance of new architectures and parallel programming frameworks.
The heterogeneous landscape of parallel architectures and parallel programming frameworks motivates the use of representative benchmarking suites to characterize their performance and efficiency.
Permitindo Maior Reprodutibilidade de Experimentos em Ambientes Distribuídos com Nodos de Baixa Confiabilidade Nelson Antˆonio Antunes Junior, Weverton Luis da Costa Cordeiro,Luciano Paschoal Gaspary
A reprodutibilidade de experimentos, essencial para a verificação da eficácia/eficiência de contribuições cientı́ficas, é particularmente desafiadora no contexto de sistemas distribuı́dos de larga escala. Falhas não programadas durante os experimentos (sejam nos nodos que fazem parte do sistema, ou de comunicação entre eles) podem dificultar a obtenção de significância estatı́stica nos resultados, ou a verificação da validade dos mesmos. Para abordar esse problema propõe-se E ASY E XP , uma arquitetura tolerante a falhas para garantir a reprodutibilidade de experimentos em testbeds distribuı́dos de baixa confiabilidade. No E ASY E XP , nodos do ambiente de experimentação “interpretam” trabalhadores e executam ações previstas para os mesmos, seguindo o roteiro pré-definido para o experimento.
A reprodutibilidade de experimentos é uma das principais formas de se verificar a eficácia/eficiência de contribuições cientı́ficas [Baker 2016]. O método aplicado, as métricas utilizadas, as condições de operação, os dados de entrada e de saı́da, entre outros, estão entre os requisitos mı́nimos necessários para garantir que os resultados deavaliação de uma contribuição cientı́fica sejam reprodutı́veis. Diversos aspectos de reprodutibilidade têm sido discutidos recentemente, incluindo suporte por parte de ambientes de experimentação [Nussbaum 2017] entre outros desafios [Bajpai et al. 2017]. A importância desse tópico inclusive motivou um workshop no ACM SIGCOMM 2017 sobre reprodutibilidade [Bonaventure et al. 2017].
Para aplicações distribuı́das (por exemplo de live streaming, distribuição de conteúdos, etc.), a reprodutibilidade é particularmente desafiadora. O longo perı́odo de operação dessas aplicações as torna mais suscetı́veis a instabilidades durante a experimentação, devido à probabilidade cumulativa de falhas não programadas transi- entes ou permanentes (nos nodos que fazem parte do testbed, ou de comunicação en- tre os mesmos). Para ilustrar, considere a avaliação de um protocolo para redes de distribuição de conteúdos, para o qual se deseja aferir sua eficácia e eficiência. O am- biente de experimentação é formado por um servidor central S, e por vários nodos N i distribuı́dos geograficamente. Cada nodo N i deverá enviar um conjunto de requisições ao servidor central em um determinado instante, a partir das quais interações subsequentes deverão ocorrer. O objetivo da avaliação é analisar o tempo necessário para que todas as requisições sejam completadas com sucesso e o tempo médio de resposta das solicitações.
A principal consequência negativa é que o resultado da avaliação não será fiel ao roteiro base, e novas execuções dessa mesma avaliação gerarão resultados não passı́veis de comparação. Em resumo, avaliações da mesma natureza que a descrita no exemplo impõem aos pesquisadores um desafio adicional para se alcançar um bom grau de reprodutibilidade.
Os resultados obtidos reproduzindo experimentos com o E ASY E XP mostraram que a arquitetura proposta é capaz de manter menor variação (desvio padrão de 1.6%) e maior precisão (95.7%) entre múltiplas execuções, quando comparado àqueles executados de forma tradicional (desvio de até 25% e precisão de apenas 72%). Mais ainda, esses resultados são alcançados sem intervenção manual durante a execução do experimento. Isso evidencia a efetividade dos mecanismos de detecção de falhas e de salvamento e recuperação de contexto dos trabalhadores.
Visão Conceitual do E ASY E XP Considerando a lacuna existente na literatura, e a importância e necessidade de uma ar- quitetura que permita a reprodutibilidade de experimentos em ambientes distribuı́dos de baixa confiabilidade, nesta seção descreve-se uma visão conceitual do E ASY E XP . O E ASY E XP baseia-se fundamentalmente nos conceitos de controlador e traba- lhador. O controlador é a entidade coordenadora dos experimentos, e reúne as funciona- lidades de gerência e de interação com os trabalhadores. Um trabalhador, por sua vez, é uma abstração de entidade que de fato executa os experimentos (como um conjunto de tarefas). Um trabalhador é “interpretado” por um nodo do ambiente, cabendo ao con- trolador distribuir papéis de trabalhadores aos nodos, e coordenar a execução das tarefas pelos mesmos. A seguir são descritos os componentes que compõem o controlador e os trabalhadores, ambos ilustrados conceitualmente na Figura 2.
Após apresentar uma visão conceitual do E ASY E XP , a seguir discorre-se sobre aspec- tos de implementação do mesmo 1 . O E ASY E XP foi implementado em Python (versão 2.7.13), principalmente pela instalação simplificada de pacotes através do PIP (o que fa- cilita a integração com vários ambientes como GENI e PlanetLab), e a possibilidade de se unificar todos os componentes da arquitetura do E ASY E XP de forma mais simples. O projeto possui atualmente 3.050 linhas de código. As subseções a seguir descrevem em detalhes aspectos de implementação dos componentes do controlador, começando pelo armazenamento de dados na Seção 4.1, composto pelo servidor Apache ZooKeeper em conjunto com o sistema de arquivos. A Seção 4.2 descreve como o Protocolo SSH e o ZooKeeper permitem a interação entre con- trolador e trabalhadores. A Seção 4.3 discorre sobre os gerenciadores de experimentos e de nodos, enquanto que na Seção 4.4 apresenta-se uma visão geral da interface web. Por fim, a Seção 4.5 discorre sobre aspectos de implementação dos trabalhadores.
Descrição do Ambiente e Experimento Os nodos empregados no experimento possuem sistema operacional Linux Fe- dora 8, com casos de Linux Fedora 12 e Linux Centos 6, a maioria em versões de 32-bits. Os processadores disponı́veis nos nodos são (em ordem decrescente de frequência) Intel Xeon, Intel Core 2 Duo, Intel Pentium D, Intel Core 2 Quad, Intel i5 e AMD Opteron. A memória RAM disponı́vel variou entre 1GB e 16GB, com moda em 4GB. Para o con- trolador, foi usado um Dell PowerEdge R815 quatro processadores AMD Opteron 6276, totalizando 64 núcleos a 2.3 GHz, e 64GB de RAM. Seu sistema operacional é o Linux Ubuntu 16.04.2 LTS com kernel 4.4.0-66-generic. Os apps utilizados foram Kazoo 2.4, Paramiko 2.2.1, SCP 0.10.2, Django 1.10.5, PIP 9.0.1 e Apache ZooKeeper 3.4.9.
A experimentação de novas soluções em ambientes distribuı́dos é particularmente desafi- adora, principalmente quando o ambiente não oferece garantias mı́nimas de estabilidade dos nodos que o compõem. Apesar das soluções existentes para facilitar a execução de ex- perimentos, nenhuma oferece suporte nativo à recuperação de falhas que possam impactar na qualidade dos resultados. Para superar essa lacuna, neste artigo propõe-se E ASY E XP , uma arquitetura capaz de recuperar trabalhadores falhos e armazenar seus contextos, ga- rantindo maiores possibilidades de reprodutibilidade de experimentos. Os resultados ob- tidos foram extremamente satisfatórios, e evidenciam a capacidade do E ASY E XP de per- mitir a reprodução de experimentos, dados os recursos necessários. Para tirar proveito do E ASY E XP , a aplicação deve ser necessariamente distribuı́da, com clientes operando de forma independente, com um roteiro bem definido de eventos, e projetada de modo que o contexto de cada entidade participante possa ser salvo periodi- camente. Como mencionado anteriormente, tal pode ser feito pelo operador da aplicação estendendo a estrutura de dados “snapshot”. Exemplos de aplicações incluem aplicações peer-to-peer em geral, como live streaming e de distribuição de conteúdo. É importante destacar que, tal como proposto, o E ASY E XP não é capaz de fornecer um ambiente totalmente tolerante a falhas, ou compatı́vel com os mais diversos experi- mentos em ambientes distribuı́dos. Além disso, o E ASY E XP requer que o controlador se mantenha ativo em todos os momentos, por ser o ponto central da arquitetura. Quando qualquer tipo de falha atingir este componente, todos os trabalhadores conectados a ele serão desativados. Uma maior disponibilidade do controlador pode ser alcançada através da sua replicação em diversas máquinas, obrigando que todos os dados também sejam replicados constantemente. Esse aspecto é deixado como direção de trabalhos futuros.
TorrentLab: Um Ambiente para Avaliação do Protocolo BitTorrent Rodrigo B. Mansilha 1 , Marinho P. Barcellos 2 , Francisco V. Brasileiro 3
Recentemente, houve uma série de trabalhos com avaliações de BitTorrent que identificaram deficiên- cias e oportunidades para melhorias do protocolo. Este trabalho apresenta o projeto e implementação de um ambiente integrado de avaliação de redes BitTorrent, denominado TorrentLab, que permite tanto a simulação quanto a execução de experimentos utilizando BitTorrent.
Tanto a implementação como a plataforma de execução dos experimentos tende a ser completamente distinta. Neste contexto, seria desejável avaliar o BitTorrent através de diferentes metodologias , e que isso pudesse ser feito de maneira inte- grada e sem-esforço, similarmente ao que já foi empregado em outros contextos [Barcellos et al. 2006, Urbán et al. 2002].
Requisitos Funcionais A arquitetura do TorrentLab foi organizada em função de cinco requisitos funcio- nais.
O primeiro requisito é prover uma forma de modelagem unificada de redes BitTorrent: esta deve servir igualmente bem para experimentos e para simulações. Idealmente, o conjunto de cenários modelados deve ser próximo ao conjunto de cená- rios possíveis na realidade. Ainda, os modelos devem ser persistentes, para permitir reaproveitamento.
O segundo requisito é oferecer uma interface para execução de simulações. A interface deve ser modular e extensível para avaliação de novos algoritmos e com- portamentos.
O terceiro requisito é oferecer meios para executar experimentos com imple- mentações de BitTorrent, ou seja, com agentes de usuário (chamados popularmente de “clientes BitTorrent”) e rastreadores. Combinando o conjunto de configurações de conteúdo a ser compartilhado, de tipos de agentes de usuário, de condições da rede, o conjunto de possibilidades resultante é infinito. Se não é viável esperar que o ambiente de experimentação satisfaça todas as possibilidades, por outro lado ele deve ser flexível a ponto de não restringir desnecessariamente as possibilidades de experimento.
O quarto requisito é unificar a consolidação de saídas de agentes e simulado- res. A consolidação de resultados é feita através de dois modos principais: gráficos e extração de dados quantitativos/estatísticos. Algumas estatísticas básicas devem ser implementadas, como por exemplo, tempo médio de download e número máximo de pares na rede, assim como geração automática de gráficos ilustrando a evolução de pares no enxame. Além de oferecer um conjunto de possibilidades “típicas” de métricas e gráficos, a arquitetura deve possibilitar que os existentes sejam estendidos ou novos sejam criados e integrados ao sistema.
Em teoria, um experimento de simulação ou real pode ser executado em um único hardware. Na prática, no entanto, as limitações impostas pela exiguidade de recursos em uma única máquina requerem que as simulações e experimentos sejam executados valendo-se de um conjunto de máquinas, formando uma infraestrutura distribuída. Portanto, o quinto e último requisito é integrar a utilização de agregados ou grades computacionais de maneira a aumentar a escalabilidade dos experimentos e das simulações.
Medindo o Desempenho de Implantações de OpenStack, CloudStack e OpenNebula em Aplicações Cientı́ficas Adriano Vogel 1 , Carlos A. F. Maron 2 , Dalvan Griebler 1,2 Claudio Schepke 3
Para os testes de desempenho, o NPB-3.3 foi executado em MPI (Message-Passing Interface) com até 16 processos (usando 2 máquinas) e OMP (Open Multi-Processing) até 8 threads. Esse conjunto de experimentos é consolidado para testes de poder computaci- onal. Foi utilizada a classe B com os kernels BT, FT, IS, MG, CG, EP, LU e SP os quais foram repetidos 40 vezes em cada ambiente. Na Figura 1 são mostrados os resultados dos kernels OMP. A Figura 2 apresenta os resultados do MPI.
As médias dos tempos de execução do MPI nas instâncias em ambiente distintos foram próximos, o ambiente nativo teve ganhos com um número maior de processos (até 16), porém o overhead nos ambientes virtualizados foi pequeno. Entre as ferramentas, as médias de MPI-CG com 16 processos foram melhores nas instâncias da ferramenta Open- Nebula, o mesmo se repete com o kernel SP. De modo geral, alguns tempos de execução diferentes sugerem um impacto causado pelo experimento ao invés dos ambientes. Outro aspecto relevante observado é que em experimentos que usam intensivamente a rede tive- ram algum tipo de perda nos ambientes virtualizados, o que é relacionado com os desafios da comunicação inter-processos, que depende principalmente de baixas latências de rede.
Performance analysis of selected hypervisors (Virtual Machine Monitors - VMMs) Waldemar Graniszewski, Adam Arciszewski
A. CPU Test (nbench) CPU tests have been conducted with the use of nbench [23], a program which runs ten different benchmarks: • numeric sort - sorting of an array of 32-bit integers, • string sort - sorting of an array of strings of randomised length, • bitfield - various bitwise operations, • emulated floating-point - various floating-point opera- tions, • Fourier - calculating a Fourier transform, • assignment - an algorithm for task allocation, • IDEA - an encryption algorithm, • Huffman - a lossless compression algorithm, • neural net - a neural net simulation, • LU decomposition - a method of matrix factorization
The NAS Benchmark Kernels for Single and Multi-Tenant Cloud Instances with LXC/KVM Anderson M. Maliszewski, Dalvan Griebler, Claudio Schepke
Our methodology is depicted in Figure 1. The NAS OpenMP Parallel Benchmark was used and compiled with class B 3 , i.e., a medium sized incarnation of the bench- mark, which means that the applications will assume: (I) 20 30 random-number pairs for EP; (II) a grid with size of 512x256x256 and 20 iterations for FT; (III) IS will sort 2 25 number of keys with maximum value of 2 21 ; (IV) a grid with size of 256x256x256 and 20 iterations for MG; (V) and CG will have 75000 number of rows with 13 values non-zero and 75 iterations to perform with an eigenvalue shift of 60 [14]. In addition, we create two main scenarios: The first one is a single tenant where CloudStack LXC-based cloud and CloudStack KVM-based cloud instances were deployed with full machine resources. The second is a multi-tenant scenario where two CloudStack instances of LXC-based cloud and two CloudStack instances of KVM-based cloud were deployed and the service offer its a half of the total host resources. The number of threads used were limited to the number of vCPUs available. For instance, in the single tenant scenario, we run NPB-OMP up to 8 threads and in the multi-tenant scenario we run NPB-OMP up to 4 threads. This was done to test multithreading applications, since we do not focus on over-commitment of resources. To create a baseline of results we also measured running on the native hardware, without virtualization. For instance, we define as scenarios the single and multi-tenants and environments as KVM-based cloud, LXC-based cloud and Native.
14 D. Griebler, J. Löff, L. Fernandes, G. Mencagli, and M. Danelutto, “Efficient nas benchmark kernels with c++ parallel programming,” in 26 Euromicro International Conference on Parallel, Distributed and Network-Based Processing (PDP), 01 2018.
Linux-based virtualization for HPC clusters Lucas Nussbaum, Fabienne Anhalt, Olivier Mornard, Jean-Patrick Gelas
The goal of virtualization is to partition one physi-cal node (or system) into several independent virtualmachines. Common applications of virtualization are server consolidation, and testing and development envi-ronments.
There has been an increasing interest in virtualization inthe HPC community, as it would allow to easily and ef-ficiently share computing resources between users, andprovide a simple solution for checkpointing. However,virtualization raises a number of interesting questions,on performance and overhead, of course, but also on thefairness of the sharing.
Next, many processing jobs do not take full advantageof the multicore architecture available on processingnodes. Deploying several Virtual Machines (VM) per node (e.g. 1 VM per core) would provide an easy wayto share physical resources among several jobs.
On most computing grids, a user books a number of re-sources for a given period of time (also calledlease).This period of time is generally a rough estimation madeby the user of the time required for his application tocomplete. When the lease expires, results will be lostif the job did not have enough time to finish, and ifno checkpointing mechanism is implemented. Goodcheckpointing mechanisms are difficult to implement,and virtualization provides an easy way to implement it,by freezing and migrating virtual machines.
Finally, the software configuration of computing plat-forms is generally static, which might be a problem forusers with specific needs. Virtualization could allow todeploy customized user environments on the computingnodes, thus allowing users with specific software needsto customize the operating system on which their appli-cation will be executed.
The hypervisor manages the requests of VMs and theiraccess to the resources (i.e IRQ routing, time keepingand message passing between VMs)
Full virtualization (FV) allows the execution of unmod-ified guest operating systems by emulating the real sys-tem’s resources
We evaluated the overhead caused by us-ing a virtualization solution for such applications, whichare obviously crucial for HPC.
Virtualized High Performance Computing (HPC) Reference Architecture (Part 1 of 2) Mohan Potheri
HPC is the use of multiple computers and parallel-processing techniques to solve complex computational problems. HPC systems have the ability to deliver sustained performance through the concurrent use of computing resources and they are typically used for solving advanced scientific and engineering problems and performing research activities through computer modeling, simulation and analysis
Multidisciplinary areas that can benefit from HPC include:
Aerospace
Biosciences
Energy
Electronic Design
Environment and Weather
Finance
Geographic Information
Media and FilmMessage Passing Interface (MPI) Workloads
Figure 1 illustrates the coupling characteristic of MPI workloads: a MPI job is decomposed into a number of small tasks and these tasks communicate via MPI and are mapped to available processor cores. For example, weather forecast modeling is computationally intensive with the demand for computing power increasing at higher resolutions. In order to run the models in a feasible amount of time, they are decomposed into multiple pieces, with the calculation results from each piece affecting all adjacent pieces. This requires continual message passing between nodes at extremely low latency. Typically, these models are run on a distributed memory system using the MPI standard to communicate during job execution. Other examples of MPI workloads include molecular dynamics, computational fluid dynamics, oil and gas reservoir simulation, jet engine design, and emerging distributed machine learning workloads.
Benefits of Virtual Machines
The fundamental element of virtualization is the virtual machine (VM) – a software abstraction that supports running an operating system and its applications in an environment whose resource configuration may be different from that of the underlying hardware. The benefits of VMs in an HPC environment include:
Increased control and research reproducibility. Infrastructure and HPC administrators can dynamically resize, pause, take snapshots, back up, replicate to other virtual environments, or simply wipe and redeploy virtual machines based on their role-based permissions. Since configurations and files are encapsulated within each VM the VMs can be archived and rerun for research reproduce purpose, such as compliance.
Fault isolation. By running jobs in an isolated VM environment, each job is protected from potential faults caused by jobs running in different VMs.
Planejamento para o projeto de conclusão de curso