Cluster Benchmarking. Autores: Bernardo Nunes Figueiredo Patrão Susana Filipa de Noronha Boavida Fernandes

Transcrição

1 Cluster Benchmarking Autores: Bernardo Nunes Figueiredo Patrão Susana Filipa de Noronha Boavida Fernandes

2 Índice Introdução... página 2 O que é um cluster?... página 2 Cluster benchmarking... página 3 Tipos de High-Performance Computing Benchmarks... página 3 NAS Parallel Benchmark... página 4 High-Performance Linpack. página 6 Hierarchical Integration... página 7 Perf... página 8 IOzone... página 9 Tutoriais... página 10 Case Study.. página 13 Perguntas página 18 Bibliografia página 19 Pagina nº1

3 Introdução Com o rápido desenvolvimento dos processadores e das tecnologias de rede, os sistemas distribuídos têm vindo a ganhar cada vez mais importância, tendo-se tornado cada vez mais atraentes pela sua elevada performance. As necessidades de poder computacional estão em constante crescimento, desta forma, cada vez mais se trabalha no sentido de arranjar soluções baratas para conseguir grande capacidades de processamento e/ou de armazenamento. É neste contexto que nasceu a ideia de cluster. O que é um cluster? Um cluster é um conjunto de duas ou mais máquinas (nodos) interligadas de um modo dedicado, funcionando como uma só supermáquina. Um dos primeiros clusters era constituído por 4 nodos, cada um com um processador DX4 a 100Mhz. Este cluster chamava-se Wiglaf e data de Desde essa altura que se têem vindo a criar clusters cada vez mais potentes e maiores. Desta forma e em paralelo com o crescimento dos novos clusters, apareceram métodos para os testar e comparar: As benchmarks para clusters! Pagina nº2

4 Cluster Benchmarking Tradicionalmente, as benchmarks são os instrumentos utilizados para quantificar o desempenho de um sistema que permitem fazer uma análise comparativa entre sistemas. No entanto, em clusters de alta performance (High Performance Computing, HPC), o uso de benchmarks não serve apenas para medir a performance de um cluster, mas também para medir a escalabilidade dos nodos e/ou aplicações intensivas de comunicação. Quando consideramos o uso de um HPC cluster (High Performance Computing cluster) para correr aplicações computacionais intensivas, é necessário prever a maneira como o cluster se irá comportar com um grande número de nodos e como se comportará com grandes fluxos de tráfego. Tipos de High Performance Computing Benchmarks As HPC benchmarks dividem-se em vários tipos. Existem benchmarks específicas para testar o subsistema de memória, ou outros subsistemas específicos. Outras benchmarks actuam ao nível da performance de aplicações paralelas. As benchmarks existentes normalmente resumem o resultado a um simples número. As duas unidades de medida de desempenho mais importantes em HPC são MFLOPS (millions of floating-point operations per second), também chamada megaflops, MIPS (millions of instructions per second) e QUIPS (quality improvement per second). A unidade MIPS estão relacionadas com o clock rate, o que nem sempre é a melhor maneira de comparação entre sistemas, devido às grandes diferenças entre arquitecturas dos vários processadores. As unidades QUIPS medem a velocidade a que os resultados se estão a aproximar da solução final. Esta medida varia, obviamente, com o desenrolar da execução do programa. Pagina nº3

5 NAS Parallel Benchmark Para medição e comparação do desempenho de sistemas paralelos (ao nível de aplicações), têm sido largamente utilizadas as Numerical Aerodynamic Simulation (NAS) Parallel Benchmarks (NPB). As NPB foram desenvolvidas pela NASA Ames Research Center. Como a versão 2.4 desta benchmark se baseia em MPI (message passing interface), permite fazer uma análise comparativa da performance de um cluster com vários nodos. A suite de benchmarks NPB consiste em oito programas que derivam de código CFD (computational fluid dynamics). CFD consiste em de substituir as equações diferenciais que orientam os problemas fluídos por equações algébricas lineares. Figura 1 Exemplos de CFD As características de CFD fazem com que as NPB sejam ideais para medir e testar vários níveis da comunicação entre máquinas de um mesmo cluster, assim como velocidade de processamento, pois é necessário processar paralelamente grandes matrizes. Dos oito programas que constituem as NPB, cinco são kernels e três são aplicações CFD. Os cinco kernels EP, FT, MG, CG e IS tentam simular o núcleo computacional de aplicações CFD. As três aplicações CFD são SP, BT e EP. A seguir resumimos as funções de cada um destes oito programas. IS (Integer Sort) esta benchmark testa a velocidade de computação de inteiros, e performance de comunicação através da realização de operações paralelas de organização de inteiros. Pagina nº4

6 FT (Fast Fourier Transformation) esta benchmark testa a performance da comunicação de longa distância, resolvendo equações diferenciais 3D. MG (Multigrid Benchmark) testa tanto a comunicação estruturada de curta e longa distância. CG (Conjugate Gradient) testa a comunicação irregular de longa distância. LU (Lower-Upper diagonal) o kernel LU serve para testar comunicação bloqueante. Para isso esta benchmark utiliza um esquema numérico para resolver matrizes triangulares superiores e inferiores. SP (Scalar pentadiagonal) e BT (Block tridiagonal) estas duas benchmarks testam o equilíbrio entre processamento e comunicação. Para isso faz um uso relativamente alto de I/O paralelo, ou seja, escreve num disco, lê de outros, etc. Invulgarmente, estas benchmarks precisam de um cluster com um número de processadores cuja raiz seja um número inteiro (i.e., 2, 4, 9, 16, 25, etc), ou seja, precisam de ser executados paralelamente com esse número de processos. EP (Embarassingly Parallel) este teste gera pares de variáveis Gaussianas aleatórias, não havendo comunicação inter-processador quer dentro da mesma máquina quer para outras maquinas do cluster. Por isso, este tipo de programas são normalmente chamados de Embarassingly Parallel. Os resultados das NBP podem ser usados para comparar a escalabilidade de um cluster, assim como a performance dos vários nodos. Pagina nº5

7 High-Performance Linpack (HPL) A benchmark Linpack foi desenvolvida por Jack Dongarra e é uma das mais conhecidas e mais largamente utilizada na área de HPC. Esta benchmark utiliza rotinas algébricas para medir o tempo necessário para a resolução de um sistema denso de equações lineares de precisão dupla (64 bits), utilizando para esse efeito o conceito de memória distribuída. Os resultados desta benchmark são expressos em número de FLOPS (floating point operations per second). A benchmark inicial, em 1980, tinha um tamanho fixo (matriz de tamanho aproximado 100x100) que deixou de ser viável assim que essa matriz passou a caber na cache de um micro-processador. Para ultrapassar este problema foi assim criada a nova Linpack, denominada High- Performance Linpack, que é a utilizada hoje em dia. Esta difere da versão anterior na medida em que o utilizador pode definir o tamanho da matriz. A ideia é escolher uma matriz suficientemente grande mas que ainda assim caiba na memória principal. Para atingir isto, é recomendado escolher o tamanho da matriz, como sendo 80% do tamanho total da memória. Se o tamanho escolhido for demasiado grande, pode ocorrer swapping o que irá reduzir a performance significativamente. A HPL é frequentemente utilizada para medição de performance genérica de super computadores. Para correr esta benchmark é necessário o uso de MPI e ou BLAS (Basic Linear Algebra Subprograms) ou VSIPL (Vector Signal Image Processing Library). Pagina nº6

8 Hierarchical Integration (HINT) Esta benchmark foi desenvolvida pelo U.S Departement of Energy s Ames Research Laboratory. É bastante popular, sendo largamente utilizada para medir a performance de subsistema. Os resultados obtidos representam graficamente a performance de floating-point e de inteiros, hierarquia de memória, performance da memória e precisão numérica. A HINT benchmark utiliza como medida de velocidade QUIPS (quality improvement per second), ou seja uma medida que indica a velocidade a que os resultados se estão a aproximar da solução final. O teste da performance é efectuado através da tentativa de resolução de um problema de integração sucessiva. Quando se corre a benchmark o requisito de memória começa por ser pequeno, aumentando drasticamente ao longo do tempo, enchendo primeiro as caches, depois a memória principal e depois passando a aceder a disco. Figura 2 Exemplo de resultados gráficos obtidos com a benchmark HINT Pagina nº7

9 Perf Perf é uma benchmark simples de medição da latency e bandwidth que permite comunicação ponto a ponto (ping pong). São enviadas mensagens de diferentes tamanhos entre dois nodos que podem variar entre 1byte a 1MB. É assim calculada a latência, ou seja, o tempo que decorre entre o envio de uma mensagem e a recepção do respectivo acknowledge. A bandwidth é calculada com base nos valores médios dos tempos de respostas. Figura 3 Exemplo de um gráfico gerado pelos resultados obtidos com Perf Pagina nº8

10 IOzone O subsistema de I/O é um dos subsistemas frequentemente testados, assim como o desempenho do file system. A benchmark IOzone mede uma variedade de operações sobre ficheiros. As seguintes operações são testadas por esta benchmark: read, write, reread, rewrite, read backwards, read strided, fread, fwrite, random read, pread, mmap, aio_read, e aio_write. A IOzone além de medir o subsistema de I/O e comparar a performance dos diferentes sistemas de ficheiros, pode também ser utilizada para comparar e medir a performance de diferentes níveis de RAID. Em HPC, o armazenamento de dados é um factor bastante importante, visto que os dados estão normalmente armazenados exteriormente, sendo depois transferidos para o nodo principal e depois para os restantes nodos, sendo assim fundamental que o throughput seja suficiente para não haver estrangulamentos. Figura 4 Exemplo de comparação de sistemas RAID com a benchmark IOzone Pagina nº9

11 Tutoriais NAS Parallel Benchmark: (download: - Descomprimir file.tar.gz - Entrar na directoria do programa - Entrar na directoria config - Criar um ficheiro make.def de acordo com as nossas máquinas e de acordo com o ficheiro de exemplo fornecido (make.def.template) - Voltar a directoria principal - Se quisermos compilar as várias benchmarks 1 a 1, entramos dentro da directoria onde se encontra cada uma a fazemos apenas: $> make CLASS=x NPROCS=y onde x é a classe A, B, C, D, S ou W e y é o número de processos com que a benchmark deve correr. - Se quisermos compilar as várias benchmarks de uma vez, criamos um ficheiro na directoria config chamado suite.def. Este ficheiro deve conter todos os nomes das benchmarks a ser compiladas seguidas do número de processos de cada uma. É possível, por exemplo, mandar compilar diferentes variantes da mesma benchmark. - Para correr cada uma das benchmarks, posicionamo-nos na directoria bin e corremos cada um dos executáveis através do comando: $>mpirun np x nome_executavel onde x é o numero de processos a serem utilizados pelo executável. Pagina nº10

12 HPL Benchmark: (download: - Fazer o download do ficheiro principal - Posicionar-se na directoria do ficheiro - Correr o comando: $>gunzip hpl.tgz; tar xvf hpl.tar - Criar um ficheiro Make.<arch> na directoria principal do programa. Podemos para isso utilizar um dos vários exemplos fornecidos, - Executar o comando: $>make arch=<arch>. Isto irá criar na directoria bin/ dentro da directoria principal um ficheiro chamado xhpl. - Depois para correr a benchmark basta fazer: $>mpirun np x xhpl, onde x é o número de nodos do cluster onde queremos que a benchmark corra - Podem-se modificar vários parâmetros de performance da benchmark através da modificação do ficheiro bin/<arch>/hpl.dat Pagina nº11

13 HINT Benchmark: (download: - Fazer o download do ficheiro para MPI - Posicionar-se na directoria do ficheiro - Descomprimir o ficheiro com o comando: $>tar xzvf hint.tar.gz - Criar uma Makefile (já inclui duas makefiles exemplo) a partir das características do cluster em questão - Na Makefile ter a certeza que ARCH=MPI e certificar que path e as library do MPI - Compilar o programa através do comando: $>make - Correr a benchmark executando o comando: $>mpirun np x nome_executável Pagina nº12

14 Case Study: Corremos algumas das benchmarks estudadas neste trabalho no Cluster TITAN do Grupo de Sistemas Confiáveis. E apresentamos de seguida os resultados obtidos: - NAS: NAS Parallel Benchmarks SP Benchmark No input file inputsp.data. Using compiled defaults Size: 102x102x102 Iterations: 400 dt: Number of active processes: 16 Time step 1 Time step 20 Time step 40 Time step 60 Time step 80 Time step 100 Time step 120 Time step 140 Time step 160 Time step 180 Time step 200 Time step 220 Time step 240 Time step 260 Time step 280 Time step 300 Time step 320 Time step 340 Time step 360 Time step 380 Time step 400 Verification being performed for class B accuracy setting for epsilon = E-07 Comparison of RMS-norms of residual E E E E E E E E E E E E E E E-13 Comparison of RMS-norms of solution error E E E E E E E E E-12 Pagina nº13

15 E E E E E E-13 Verification Successful SP Benchmark Completed. Class = B Size = 102x 102x 102 Iterations = 400 Time in seconds = Total processes = 16 Compiled procs = 16 Mop/s total = Mop/s/process = Operation type = floating point Verification = SUCCESSFUL Version = 2.4 Compile date = 05 Jun 2003 Compile options: MPIF77 = mpif77 FLINK = mpif77 FMPI_LIB = -L/usr/local/lib -lmpi FMPI_INC = -I/usr/local/include FFLAGS = -O3 FLINKFLAGS = (none) RAND = (none) NAS Parallel Benchmarks LU Benchmark Size: 102x102x102 Iterations: 250 Number of processes: 16 Time step 1 Time step 20 Time step 40 Time step 60 Time step 80 Time step 100 Time step 120 Time step 140 Time step 160 Time step 180 Time step 200 Pagina nº14

16 Time step 220 Time step 240 Time step 250 Verification being performed for class B Accuracy setting for epsilon = E-07 Comparison of RMS-norms of residual E E E E E E E E E E E E E E E-14 Comparison of RMS-norms of solution error E E E E E E E E E E E E E E E-14 Comparison of surface integral E E E-14 Verification Successful LU Benchmark Completed. Class = B Size = 102x 102x 102 Iterations = 250 Time in seconds = Total processes = 16 Compiled procs = 16 Mop/s total = Mop/s/process = Operation type = floating point Verification = SUCCESSFUL Version = 2.4 Compile date = 05 Jun 2003 Compile options: MPIF77 = mpif77 FLINK = mpif77 FMPI_LIB = -L/usr/local/lib -lmpi FMPI_INC = -I/usr/local/include FFLAGS = -O3 FLINKFLAGS = (none) RAND = (none) Pagina nº15

17 NAS Parallel Benchmarks IS Benchmark Size: (class B) Iterations: 10 Number of processes: 16 iteration IS Benchmark Completed Class = B Size = Iterations = 10 Time in seconds = Total processes = 16 Compiled procs = 16 Mop/s total = 9.48 Mop/s/process = 0.59 Operation type = keys ranked Verification = SUCCESSFUL Version = 2.4 Compile date = 05 Jun 2003 Compile options: MPICC = mpicc CLINK = mpicc CMPI_LIB = -L/usr/local/lib -lmpi CMPI_INC = -I/usr/local/include CFLAGS = -O3 CLINKFLAGS = (none) Pagina nº16

18 - HPL: ===================================================================== HPLinpack 1.0 -High-Performance Linpack benchmark- September 27, 2000 Written by A. Petitet and R. Clint Whaley, Innovative Computing Labs ===================================================================== An explanation of the input/output parameters follows: T/V : Wall time / encoded variant. N : The order of the coefficient matrix A. NB : The partitioning blocking factor. P : The number of process rows. Q : The number of process columns. Time : Time in seconds to solve the linear system. Gflops : Rate of execution for solving the linear system. The following parameter values will be used: N : NB : 64 P : 4 Q : 5 PFACT : Left NBMIN : 8 NDIV : 4 RFACT : Left BCAST : 1ring DEPTH : 8 SWAP : Mix (threshold = 96) L1 : transposed form U : transposed form EQUIL : yes ALIGN : 8 double precision words The matrix A is randomly generated for each test. - The following scaled residual checks will be computed: 1) Ax-b _oo / ( eps * A _1 * N ) 2) Ax-b _oo / ( eps * A _1 * x _1 ) 3) Ax-b _oo / ( eps * A _oo * x _oo ) - The relative machine precision (eps) is taken to be e-16 - Computational tests pass if scaled residuals are less than 16.0 ===================================================================== T/V N NB P Q Time Gflops W80L4L e Ax-b _oo / ( eps * A _1 * N ) = PASSED Ax-b _oo / ( eps * A _1 * x _1 ) = PASSED Ax-b _oo / ( eps * A _oo * x _oo ) = PASSED ===================================================================== Finished 1 tests with the following results: 1 tests completed and passed residual checks, 0 tests completed and failed residual checks, 0 tests skipped because of illegal input values End of Tests. ===================================================================== Pagina nº17

19 Perguntas: 1 Como é que se pode medir a performance de um cluster? Que processos se usam? O que se pode medir? Na prática, um cluster funciona como um único computador, mas, para isso, é necessário existir uma programação prévia em paralelismo. Desta forma, os programas corridos no Cluster são distribuídos pelos vários nodos. Quanto melhores forem os nodos, em termos de computação, quanto mais forem e quanto mais rápida for a rede que os interliga, mais potente é o cluster que estamos a investigar. Assim, as benchmarks que estudam a performance de um dado cluster devem incidir sobre estas questões: a velocidade de processamento de cada um dos nodos, o bandwidth da rede que interliga os nodos do cluster e a quantidade de memória principal em cada nodo e a velocidade de acesso a ela. Desta maneira podemos medir todas esses pontos singularmente para cada nodo do cluster e/ou podemos trabalhar cada característica paralelamente. Para isso, a maior parte das benchmarks utiliza interfaces (libraries) para poder transferir dados entre os vários nodos do mesmo cluster. A interface mais utilizada é o MPI (Message Passing Interface). 2 O que é mais importante num cluster de alta performance? CPU, memória, disco...? Quando testamos a performance de um sistema simples (uniprocessador), tentamos identificar se existe algo que possa atrasar tudo o resto, por exemplo, se tivermos um processador muito rápido, mas pouca memória principal, o sistema irá passar uma grande parte do tempo a fazer swapping, ficando assim muito mais lento. Num cluster, além de ser necessário que cada nodo tenha um bom desempenho por si só, é muito importante que os nodos trabalhem de uma forma síncrona, ou seja, deve-se tentar ao máximo evitar que todos os nodos que já terminaram uma dada tarefa fiquem bloqueados à espera de um nodo mais lento. Para isto os nodos devem ter todos as mesmas características, ou seja, processadores semelhantes, de preferência iguais, mesma quantidade de memória e disco, devendo os discos atingir todos as mesmas rotações. Pagina nº18

20 Além disso a comunicação entre os nodos é de extrema importância, pois quanto melhor e mais rápida for efectuada a comunicação, mais rápida será a execução dos processos. Num cluster de alta performance não faz qualquer sentido investir em grandes capacidades de processamento individual de cada máquina, quando a comunicação é deficiente ou muito lenta. Um cluster assenta na paralelização de processos, sendo assim o lema que rege estes sistemas: dividir para reinar. Bibliografia IOzone: NAS: HINT: Linpack: Pagina nº19