CRITÉRIOS DE BENCHMARKING E DIRETRIZES PARA A COMPARAÇÃO DE DESEMPENHO E AVALIAÇÃO DE IMPLEMENTAÇÃO DO PON PERANTE

OUTRAS ARQUITETURAS

Segundo Ferlin (2008), diversas métricas são comumente utilizadas para se avaliar desempenho em arquiteturas de computadores, tanto sequenciais quanto paralelas. Tais métricas podem ser comparativas, quando permitem que o resultado da avaliação seja comparado com os resultados de avaliações de outras implementações ou arquiteturas. Esta comparação visa principalmente embasar uma discussão a respeito de vantagens ou desvantagens que a solução sendo avaliada apresenta em relação às soluções com as quais é comparado, do ponto de vista de desempenho. Para tanto, a avaliação comparativa de desempenho pode fazer uso de métricas relativas, tais como:

• Ganho de desempenho (speedup), que é a razão entre o desempenho de duas implementações sendo comparadas.

• Eficiência do paralelismo, que diz respeito ao ganho de desempenho obtido em função do número de elementos de processamento paralelos adicionados a uma determinada implementação de arquitetura.

Um requisito importante para execução de uma análise comparativa é que ela seja executada sobre as mesmas configurações de hardware e software para todas as arquiteturas a serem comparadas, com exceção do elemento que se pretende avaliar (p. ex. processador) (FERLIN, 2008). Do contrário, pode ocorrer uma distorção na comparação ou na percepção da ordem de grandeza do critério sendo avaliado.

O desempenho de um sistema computacional é geralmente definido como função da velocidade de processamento em determinado tipo de aplicação, ou seja, o número de operações efetuadas por esta aplicação por unidade de tempo. Tais operações podem ser categorizadas como cálculos de ponto flutuante, de onde surge o termo FLOPS (Floating-

Point Operations Per Second), ou mesmo instruções de forma genérica, de onde surge o

termo MIPS (Million Instructions Per Second). Estas métricas, em particular, viabilizam avaliações quantitativas, que oferecem uma noção de ordem de grandeza no que diz respeito à capacidade de computação.

As avaliações comparativas de sistemas computacionais, e de certa forma também as avaliações quantitativas, dependem de aplicações ditas de benchmarking. Estas são aplicações bem definidas, projetadas para executar operações que exercitem intensivamente o aspecto ou tipo de computação que se pretende avaliar. Exemplos são as suites SPEC2006 (STANDARD..., 2006), EEMBC (EMBEDDED..., 2012), LINPACK (PETITET et al., 2008) /LAPACK (LAPACK, 2012), SPLASH 2 (WOO et al., 1995), ANSYS Fluent (ANSYS, 2012) e alguns benchmarks de escopo específico tais como STREAM (avaliação de largura de banda de memória usando vetores de tamanho superior à capacidade da memória cache).

Um exemplo de avaliação comparativa é o relatório publicado por Dongarra (2011). Este relatório apresenta o desempenho de vários processadores na execução de aplicações específicas de cálculo de sistemas de equações, entre elas as da suite LINPACK. Os resultados são apresentados utilizando-se MFLOPS como unidade e permitem tanto uma avaliação comparativa (p. ex. para se determinar o processador de melhor desempenho para determinada aplicação) quanto quantitativa.

Muitas das aplicações de benchmark anteriormente apresentadas podem ser utilizadas também no domínio de arquiteturas paralelas. No entanto, conforme citado por Patterson e Hennessy (2009), a forma de se viabilizar a execução paralela das aplicações, para se obter um resultado útil para comparação, pode diferir. Aplicações como as da suite LINPACK são fracamente escaláveis, o que significa que dependem que o tamanho do problema a ser resolvido aumente proporcionalmente ao número de elementos de processamento paralelos. Outras aplicações, p. ex. SPLASH 2, são fortemente escaláveis, o

que significa que o tamanho do problema pode ser mantido mesmo com o aumento do número de elementos de processamento disponíveis (portanto, alocando uma porção menor da execução da aplicação para cada elemento de processamento).

Aplicações de vários domínios podem ser utilizadas para benchmarking, tanto de arquiteturas sequenciais quanto paralelas, independente de serem implementadas em uma suíte de benchmarking padronizada ou não. Exemplos são: aplicações de decodificação de

stream de áudio; cálculos de matrizes e matrizes esparsas; modelagem de fluidos e geológica;

controle discreto; banco de dados e mineração de dados; processamento de arquivos (compiladores); entre outros.

Independente da escalabilidade, outra questão que se apresenta no benchmarking de arquiteturas paralelas é o quanto cada aplicação pode ser adaptada para uma diferente proposição de arquitetura ou até mesmo de tecnologia de compilação, dado que adaptações radicais podem invalidar uma análise comparativa (um hipotético ganho de desempenho poderia ocorrer em função de um melhoramento do software e não do hardware em si) (PATTERSON; HENNESSY, 2009). Neste sentido, Asanovic et al. (2006) propuseram um conjunto de problemas de benchmark em um nível de abstração mais alto (apelidados de “anões”). Os problemas propostos incluem cálculo de álgebra linear densa, matrizes esparsas, percurso de grafos e máquinas de estado finitas e são abordados como métodos computacionais, ou seja, independentes de uma implementação específica de algoritmo. O objetivo foi dar margem à utilização de novos frameworks ou até mesmo novos paradigmas de computação em hardware, permitindo que o sistema sendo avaliado implemente a solução para o problema de benchmark da forma mais adequada à sua tecnologia.

No domínio das arquiteturas de fluxo de dados, diversas medidas foram obtidas como parte do benchmarking efetuado por Gurd, Kirkham e Watson (1985) para o computador de fluxo de dados Manchester. As métricas utilizadas incluem MIPS, FLOPS,

speedup e eficiência de paralelização (dado o paralelismo intrínseco que pode ser realizado

em uma arquitetura de fluxo de dados).

Ferlin (2008) cita ainda que podem surgir potenciais dificuldades na utilização de algumas das métricas de avaliação de desempenho. Por exemplo, a avaliação comparativa utilizando MIPS ou FLOPS como métrica é altamente influenciada pelo modelo do conjunto de instruções das arquiteturas sendo comparadas, principalmente se for uma comparação entre uma implementação RISC e uma CISC. De fato, uma implementação CISC tende a utilizar muito menos instruções do que uma implementação RISC para executar as mesmas tarefas, ainda que as instruções CISC tipicamente demorem mais ciclos de clock para executar,

portanto uma avaliação baseada em número de instruções por unidade de tempo pode ser distorcida.

2.5.1 Considerações sobre avaliações comparativas no contexto do PON

Do ponto de vista do PON, dado que um programa é organizado na forma de regras que são habilitadas mediante um mecanismo de notificações, faz-se necessário adaptar aplicações de benchmark para funcionar de acordo com este modelo. Esta adaptação deve manter a funcionalidade da aplicação, de tal maneira que permita comparar os resultados de

benchmarking do PON com os resultados obtidos em outros cenários (arquiteturas e/ou

plataformas). Em particular, aplicações que sejam baseadas na execução sequencial de um grande conjunto de operações matemáticas (tais como as da suite LINPACK) somente são úteis para este propósito se puderem ser (re)compostas na forma de regras. Isto pode ser inviável justamente por este tipo de aplicação não apresentar um conjunto de relações lógico- causais que justifique a sua modelagem em regras.

Alguns pesquisadores efetuaram avaliações de benchmark utilizando aplicações concebidas desde o princípio para serem baseadas em regras. Estas avaliações tiveram como objetivo comparar implementações no domínio dos SBR, com o foco em questões relativas ao desempenho dos mecanismos e modelos de inferência e execução das regras.

Lee e Cheng (2002) efetuaram comparações do mecanismo de inferência HAL, no domínio dos SBR, com outros mecanismos de inferência (RETE, TREAT, etc.) utilizando duas aplicações de benchmark, apelidadas de “Miss Manners” e “Waltz”. A primeira aplicação é uma simulação de alocação de convidados de um jantar para as respectivas mesas, respeitando regras relativas ao sexo (alocação de casais) e afinidade de hobbies de cada uma das pessoas, baseada na execução de um conjunto de 8 regras. A segunda aplicação, por sua vez, é um programa especializado em analisar linhas de um desenho bidimensional e extrapolar estas linhas como arestas de um objeto tridimensional, baseado na execução de um conjunto de 33 regras. A métrica quantitativa utilizada em ambos os experimentos realizados por Lee e Cheng foi o número de operações executadas sobre elementos da memória de trabalho, que é definido como o somatório da quantidade de escritas e leituras efetuadas. Nesta definição, os autores consideraram que operações de apagamento ou modificação são implementadas por meio de uma operação de leitura seguida de uma escrita.

Especificamente no escopo do PON, Banaszewski (2009) efetuou estudos comparativos utilizando uma aplicação no estilo toy problem denominada “Mira Alvo”. Esta aplicação consiste em um jogo no qual entidades que fazem o papel de mira (os “arqueiros”) interagem com entidades que fazem o papel de alvo (as “maçãs”) segundo determinadas regras. As regras consistem basicamente em assinalar que determinado arqueiro flechou uma determinada maçã quando as seguintes premissas forem atendidas: a maçã estiver pronta, for de determinada cor e tiver um identificador compatível com o do arqueiro correspondente (Figura 23 (a)). Outro cenário proposto incluiu uma entidade que faz o papel de elemento sincronizador (uma “arma de fogo”), cujo disparo permite que os arqueiros interajam com as respectivas maçãs (Figura 23 (b)).

Ambos os cenários foram então implementados no PON (framework PON C++), no PI (código em C++) e no PD (shell CLIPS), utilizando-se técnicas e ferramentas apropriadas. Estes cenários foram experimentados com a substituição das maçãs (atingidas ou não) por outras, de maneira que determinado percentual de expressões causais fosse satisfeito.

Figura 23 – Cenários de simulação do problema “mira-alvo” (Fonte: adaptado de BANASZEWSKI, 2009, p. 151 e 163)

Os resultados foram submetidos a análise comparativa, variando-se o percentual de expressões causais satisfeitas e utilizando-se como métrica quantitativa o tempo de execução de cada uma das implementações. Com este procedimento, objetivou-se avaliar o impacto da ocorrência de redundâncias e do aumento do número de notificações no que diz respeito ao desempenho de cada uma das versões implementadas em cada um dos paradigmas.

Peters (2012), por sua vez, também executou avaliações comparativas de desempenho da aplicação mira alvo quando executada no processador NiOS II da Altera, utilizando o framework C++ do PON, e quando executada com o auxílio do coprocessador PON que foi objeto da sua pesquisa. A métrica de desempenho utilizada para comparação também foi o tempo de execução, medido em ciclos de clock.

Outras aplicações de benchmark também utilizadas por Banaszewski e/ou Peters para avaliações comparativas do PON, eu suas respectivas pesquisas, são listadas a seguir:

• Sistema de condicionamento de ar de edifício, baseado em exemplo apresentado por Friedman-Hill (2003) apud Banaszewski (2009) e que consiste em um controle centralizado de regras de acionamento de bombas de calor e entradas de ar em função dos valores de temperaturas fornecidos por termômetros.

• Sistema de portão eletrônico. Este sistema foi inicialmente proposto por Wiecheteck (2011), como caso de estudo para a sua pesquisa relativa ao método DON (Desenvolvimento Orientado a Notificações), e consiste em um conjunto de regras utilizadas para controle de abertura e fechamento de um portão eletrônico em função da atuação em um controle remoto.

• Simulador de semáforo, proposto por Ronszcka (2011) e que consiste em um conjunto de regras que simulam o comportamento de veículos e pedestres em um sistema de tráfego, em função da variação do estado de um conjunto de semáforos de trânsito existentes no sistema.

Todas as aplicações baseadas em regras apresentadas nesta seção podem ser adaptadas ou até mesmo estendidas para utilização em avaliações tanto quantitativas como comparativas da ARQPON, sem requerer alterações radicais na sua lógica dado que já foram concebidas baseadas em regras. Além disso, dada a granularidade de cada uma destas aplicações, na forma de múltiplas instâncias de FBEs e das regras que sobre eles atuam, pode- se considerar que elas são fortemente escaláveis. Ou seja, com o aumento do número de núcleos de processamento, pode-se alocar um número menor de regras para execução por cada núcleo, mantendo o número de regras total da aplicação.

A Tabela 2 apresenta um resumo da aplicabilidade e outras considerações sobre algumas possíveis métricas quantitativas de avaliação no contexto do PON. Estas considerações fazem uso da seguinte terminologia:

• Abordagem/plataforma PON: conjunto das camadas de software e/ou hardware que implementa as abstrações do metamodelo do PON, viabilizando a execução de aplicações segundo aquele paradigma. Exemplos de plataformas consideradas neste estudo são o framework C++ PON, a ARQPON, o coprocessador (CoPON) e PON reconfigurável em circuitos digitais de hardware.

• Implementação de aplicação PON: uma determinada implementação de um sistema (hardware e/ou software) segundo o PON, definida pelo conjunto de instâncias dos elementos do metamodelo de notificações que interagem para a dinâmica do sistema.

• Implementação de aplicação em outro paradigma: uma determinada implementação de um sistema segundo outro paradigma que não o PON.

O Apêndice B contém uma discussão mais detalhada sobre as considerações apresentadas na Tabela 2.