Dhrystone

Dhrystone é um programa de referência de computação sintética desenvolvido em 1984 por Reinhold P. Weicker destinado a ser representativo da programação de sistema (inteiro). O Dhrystone cresceu para se tornar representativo do desempenho geral do processador (CPU). O nome "Dhrystone" é um trocadilho com um algoritmo de benchmark diferente chamado Whetstone (trocadilho explicado: whet-stone = wet-stone | dhry-stone = dry-stone), que enfatiza o desempenho do ponto flutuante.

Com Dhrystone, Weicker reuniu metadados de uma ampla gama de software, incluindo programas escritos em FORTRAN, PL/1, SAL, ALGOL 68 e Pascal. Ele então caracterizou esses programas em termos de várias construções comuns: chamadas de procedimento, indireções de ponteiro, atribuições, etc. A partir disso, ele escreveu o benchmark Dhrystone para corresponder a uma mistura representativa. Dhrystone foi publicado em Ada, com a versão C para Unix desenvolvida por Rick Richardson ("versão 1.1") contribuindo muito para sua popularidade.

Dhrystone vs. Whetstone

O benchmark Dhrystone não contém operações de ponto flutuante, portanto, o nome é um trocadilho com o então popular benchmark Whetstone para operações de ponto flutuante. A saída do benchmark é o número de Dhrystones por segundo (o número de iterações do loop de código principal por segundo).

Tanto Whetstone quanto Dhrystone são benchmarks sintéticos, o que significa que são programas simples cuidadosamente projetados para imitar estatisticamente o uso do processador de algum conjunto comum de programas. Whetstone, desenvolvido em 1972, originalmente se esforçou para imitar programas Algol 60 típicos baseados em medições de 1970, mas acabou se tornando mais popular em sua versão Fortran, refletindo a orientação altamente numérica da computação na década de 1960.

Problemas abordados por Dhrystone

A eventual importância de Dhrystone como um indicador de desempenho de uso geral ("inteiro") de novos computadores tornou-o um alvo para escritores de compiladores comerciais. Várias técnicas modernas de análise de código estático do compilador (como a eliminação de código morto: por exemplo, código que usa o processador, mas produz resultados internos que não são usados ou gerados) dificultam o uso e o design de benchmarks sintéticos. A versão 2.0 do benchmark, lançada por Weicker e Richardson em março de 1988, teve uma série de mudanças destinadas a frustrar uma série de técnicas de compilador. No entanto, foi cuidadosamente elaborado para não alterar o benchmark subjacente. Esse esforço para frustrar os compiladores foi apenas parcialmente bem-sucedido. Dhrystone 2.1, lançado em maio do mesmo ano, teve algumas pequenas alterações e em julho de 2010 continua sendo a definição atual de Dhrystone.

Além dos problemas relacionados à otimização do compilador, vários outros problemas foram citados com o Dhrystone. A maioria delas, incluindo o pequeno tamanho do código e o pequeno tamanho do conjunto de dados, foram compreendidas na época de sua publicação em 1984. Mais sutil é a ligeira super-representação das operações de string, que é amplamente relacionada à linguagem: tanto Ada quanto Pascal têm strings como variáveis normais na linguagem, enquanto C não, então o que era simples atribuição de variável em benchmarks de referência tornou-se operações de cópia de buffer na biblioteca C. Outro problema é que a pontuação relatada não inclui informações críticas ao comparar sistemas, como qual compilador foi usado e quais otimizações.

Dhrystone permanece notavelmente resiliente como uma referência simples, mas seu valor contínuo em estabelecer o verdadeiro desempenho é questionável. É fácil de usar, bem documentado, totalmente independente, bem compreendido e pode ser feito para funcionar em praticamente qualquer sistema. Em particular, ele permaneceu em amplo uso no mundo da computação embarcada, embora o conjunto de benchmark EEMBC recentemente desenvolvido, o benchmark independente CoreMark, HINT, Stream e até mesmo Bytemark sejam amplamente citados e usados, bem como benchmarks mais específicos para a memória subsistema (Cachebench), TCP/IP (TTCP) e muitos outros.

Resultados

Dhrystone pode representar um resultado mais significativo do que MIPS (milhões de instruções por segundo) porque as comparações de contagem de instruções entre diferentes conjuntos de instruções (por exemplo, RISC vs. CISC) podem confundir comparações simples. Por exemplo, a mesma tarefa de alto nível pode exigir muito mais instruções em uma máquina RISC, mas pode ser executada mais rapidamente do que uma única instrução CISC. Assim, a pontuação de Dhrystone conta apenas o número de conclusões de iteração do programa por segundo, permitindo que máquinas individuais executem esse cálculo de uma maneira específica da máquina. Outra representação comum do benchmark Dhrystone é o DMIPS (Dhrystone MIPS) obtido quando a pontuação Dhrystone é dividida por 1757 (o número de Dhrystones por segundo obtido no VAX 11/780, nominalmente uma máquina de 1 MIPS).

Outra forma de representar os resultados é em DMIPS/MHz, onde o resultado DMIPS é dividido pela frequência da CPU, para permitir uma comparação mais fácil de CPUs rodando em diferentes taxas de clock.

Deficiências

Usar Dhrystone como referência tem armadilhas:

• Possui código incomum que não é geralmente representativo de programas modernos da vida real.

• É suscetível a otimizações de compiladores. Por exemplo, ele faz muita cópia de cadeia de caracteres em uma tentativa de medir o desempenho de cópia de cadeia. No entanto, as cordas em Dhrystone são de comprimento constante conhecido e seus começos são alinhados em limites naturais, duas características geralmente ausentes de programas reais. Portanto, um otimizador pode substituir uma cópia de cadeia por uma sequência de movimentos de palavras sem qualquer loop, que será muito mais rápido. Esta otimização, consequentemente, supera o desempenho do sistema, às vezes por mais de 30%.

• O tamanho do código pequeno de Dhrystone pode caber no cache de instrução de uma CPU moderna, de modo que o desempenho de busca de instrução não seja rigorosamente testado. Da mesma forma, Dhrystone também pode caber completamente no cache de dados, assim, não exercendo o desempenho da falta de cache de dados. Para combater o problema fits-in-the-cache, o benchmark SPECint foi criado em 1988 para incluir um conjunto de (inicialmente 8) programas muito maiores (incluindo um compilador) que não poderiam caber em caches L1 ou L2 dessa época.