Pular para conteúdo

Workload Design

MO601 - Arquitetura de Computadores II

http://www.ic.unicamp.br/~rodolfo/mo601

Rodolfo Azevedo - rodolfo@ic.unicamp.br

Criando ou selecionando benchmarks

  • Benchmarks são programas que são utilizados para avaliar o desempenho de um sistema
  • Construir um benchmark requer conhecimento do sistema e do problema
  • Escolhas erradas/imprecisas no processo de construção levarão a avaliações não confiáveis
  • Existem muitos benchmarks disponíveis, mas nem todos são adequados para o seu problema
  • É importante considerar aspectos como:
  • Tipo de compuador (desktop, servidor, embarcado, etc)
  • Comportamento dos subsistemas (memória, cache, disco, rede, etc)
  • Tipo de aplicação (processamento, I/O, etc)
  • Requisitos de memória

Tipos de benchmarks

  • Existem muitas formas de categorizar benchmarks, normalmente levando em conta o tipo de aplicação ou sistema a ser avaliado
  • Quando se fala da construção de benchmarks, eles se dividem em duas categorias
  • Benchmark sintético: são benchmarks que são construídos para avaliar um aspecto específico do sistema, criando um programa ou utilizando partes de programas
  • Benchmark real: são benchmarks que são construídos para avaliar o desempenho de um sistema em um cenário real, utilizando programas reais

Benchmark sintético

  • São benchmarks que são construídos para avaliar um aspecto específico do sistema, criando um programa ou utilizando partes de programas
  • Normalmente são mais fáceis de executar e de interpretar os resultados
  • A execução do benchmark não produz outro resultado além das métricas de desempenho
  • Pode ser burlado por otimizações de compiladores ou sistemas para conseguirem métricas melhores
  • As vezes representam a única alternativa, como no caso dos microbenchmarks

Benchmark real

  • São benchmarks que são construídos para avaliar o desempenho de um sistema em um cenário real, utilizando programas reais
  • Normalmente são mais difíceis de executar e de interpretar os resultados
  • Otimizações de sistema ou compiladores que melhoram o desempenho do benchmark devem melhorar o desempenho de seus componentes
  • Costumam ser construídos através de um conjunto de aplicações diferentes com múltiplas entradas cada
  • São mais confiáveis para avaliar o desempenho de sistemas reais

Criando benchmarks

  • O espaço de possíveis programas para criar um benchmark é chamado de workload space
  • Em alguns sistemas (tipicamente embarcados), é possível utilizar como benchmark todo o universo de software que será executado no sistema
  • Para a maior parte dos sistemas, não é possível coletar todos os softwares que podem ser executados
  • Torna-se necessário criar benchmarks específicos (reference workload)
  • Ainda assim, esse benchmark pode ser muito grande e ele pode precisar ser reduzido (reduced workload)

Workload de referência

  • Apesar de não conter todos os softwares que serão executados, o reference workload deve conter todos os tipos de softwares que serão executados, o que torna a tarefa ainda muito complexa
  • Existem inúmeros domínios de aplicações como: multimídia, computação científica, bioinformática, médica, comercial, computação geral, etc
  • Mesmo restringindo para um sub-domínio, ainda é difícil construir um benchmark representativo
  • Alguns benchmarks foram criados para subdomínios: SPEC CPU (computação geral), MediaBench (multimedia), BioPerf (bioinformática), PARSEC (multithread), DaCapo (Java), STAMP(memória transacional)
  • Sempre que surgem novas demandas, novos benchmarks são criados

O espaço de workloads está sempre mudando

  • Otimizações de workloads para hoje podem não ser tão úteis para o futuro
  • À medida que os sistemas ficam maiores, fala-se cada vez mais de sistemas projetados no passado, com compiladores antigos, definindo o destino do futuro da computação
  • Atualizar sistemas e compiladores é sempre uma tarefa árdua
  • O próprio critério para definição dos programas que comporão um benchmark possui subjetividade
  • Como exemplo, os critérios do SPEC incluem portabilidade e manutenção do código

Reduzindo workload

  • Com muitos domínios de aplicações, o conjunto de benchmarks possíveis cresce significativamente
  • Execuções baseadas em simulação ou mesmo coleta de dados dinâmicos tornam-se inviáveis
  • É necessário reduzir o conjunto de benchmarks para um tamanho que seja viável
  • O processo de redução do benchmark precisa ser metódico
  • Não deve ser baseado no critério "somente o que rodou no meu computador"
  • Nem pode ser baseado em critérios subjetivos como "o que eu acho que é importante"

PCA - Principal Component Analysis

  • Uma técnica de redução de dimensionalidade que pode ser utilizada para reduzir o espaço de workloads
  • O processo costuma passar por 3 fases distintas:
  • Seleção do workload de referência com n programas com a definição e coleta de p características por programa
  • Aplicação do PCA para reduzir o espaço de p características para um número menor de q características
  • Cluster analysis para reduzir o conjunto de n programas para um número menor de m programas

Considerações sobre PCA

  • É comum encontrar características similares em programas distintos e acreditar que eles são similares
  • A parte mais crítica do processo passa a ser a definição e coleta das características, que podem ser caracterizadas como dependentes ou independentes de microarquitetura
  • As características dependentes de arquitetura costumam ser mais fáceis de coletar mas são também dependentes do ambiente de execução
  • As características independentes de arquitetura podem precisar de simuladores com precisão de ciclo para serem coletadas

Hardware performance monitors

  • Praticamente todos os processadores modernos possuem um conjunto de contadores de desempenho
  • Monitorar esse conjunto de contadores é uma forma de coletar características dependentes de microarquitetura como CPI, hit/miss na cache, etc
  • Uma forma melhor seria coletar esses mesmos contadores em múltiplas arquiteturas/processadores diferentes

Exemplo de caracterização dependente de microarquitetura

Característica gzip-graphic fasta
CPI on Alpha 21164 1,01 0,92
CPI on Alpha 21264 0,63 0,66
L1 D-cache misses/instrução 1,61% 1,90%
L1 I-cache misses/instrução 0,15% 0,18%
L2 cache misses/instrução 0,78% 0,25%

Os dois programas parecem iguais sobre essa ótica!

Exemplo de caracterização independente de microarquitetura

Característica gzip-graphic fasta
Data working set size (x4KB) 46.199 4.058
Instruction working set size (x4KB) 33 79
Two consecutive load accssing the same data 0,67 0,30
Two consecutive store acessing the same data 0,64 0,05
Probability of data stride in loads < 64 0,26 0,18
Probability of data stride in stores < 64 0,35 0,93

Características independentes de microarquitetura

  • Instruction mix: Porcentagem de loads, stores, branches, operações de inteiros, operações de ponto-flutuante
  • ILP: Quantidade de ILP para uma dada janela de instruções
  • Data working set size: Número de blocos ou páginas de memória distintos acessados
  • Code footprint: Número de blocos ou páginas de memória distintos executados
  • Branch transition rate: Número de vezes que branches trocam de direção durante a execução
  • Stride de dados: Distribuição de strides entre loads e stores consecutivos estática ou dinamicamente

Simulação detalhada

  • Requer um simulador com preisão de ciclos
  • Por ser um software, pode coletar mais informações sobre os benchmarks
  • Execução muito demorada
  • Precisa executar apenas no momento da caracterização
  • Costuma ser a base para coletar características independente de microarquitetura

Completando o processo (PCA + Cluster Analysis)

  • Com base nas características, a utilização de PCA permite coletar um conjunto menor de componentes onde o primeiro agrega mais características e o último menos
  • Muitos pacotes de software realizam essa tarefa
  • Com base nessas características, os programas são agrupados conforme o espaço de características
  • A escolha do número de características também é uma decisão crítica do processo
  • Pontos próximos nesse novo espaço possuem comportamentos similares
  • O novo espaço também pode ser analisado procurando por locais não representados pelos benchmarks

Plackett and Burman based workload design

  • Uma técnica sistemática de redução de dimensionalidade com um número menor de simulações
  • 2c simulações para c características
  • Permite a escolha das características que mais impactam o sistema
  • Não entraremos em detalhe aqui, mas vale a leitura da descrição no livro

Limitações

  • Benchmarks reduzidos podem não capturar todos os comportamentos necessários
  • É importante projetar os experimentos tendo em mente os parâmetros que foram utilizados para a redução dos benchmarks
  • É importante também ter em mente que o espaço de workloads está sempre mudando
  • Os processadores também estão evoluindo mas as características não costumam ser alteradas de forma drástica de uma geração para a próxima