View Original Text

Hide Table of Contents

BENCHMARK RetroComputaria

Não tão Retro quanto com... hummm... deixa quieto! :-)

O que é

Há algum tempo atrás, na lista appleII_br, um colega (Alexandre Suaide) resolveu do nada comparar dois de seus micros, sem nenhuma pretensão, por pura curiosidade.

A coisa escalou (pra cacete!) para as listas ( em ordem ASCII ;-) )

e eu tomei a liberdade de consolidar os dados num trabalho colaborativo usando Google Docs.

Se você tem um micro que ainda não está lá, participe!

Eu estou especialmente curioso para os mais diversos TRS-80, e também para o Sinclair QL - quase faço uma idiotice e trouxe um pra mim! X-P

(uh... eu fiz uma idiotie e trouxe um QL pra mim!)

Resultados

O link para a tabela de resultados ainda está mais ou menos em PVT, um pouco mais à frente eu pretendo fechar a edição apenas para os colegas que colaboraram e tenham uma conta no Google Docs, e colocarei o link read/only aqui.

Por enquanto, um import em HTML está aqui (atualizado em 2012/10/22).

FAQ

Por quê < Micro A > é mais rápido que < Micro B > no < Teste X >?

Por quê tantos testes diferentes?

Porque alguns micros podem ser melhores nuns testes que outros, e eu quero ver a diferença pra descobrir a causa:

Por quê BASIC ?

Porque todo micro clássico tem um, boa parte deles embutida no firmware do aparelho.

Como o Microsoft BASIC foi largamente empregado (para o bem e para o mal), acabou-se que temos um Minimo Denominador Comum entre várias plataformas - todas as máquinas Z80 com BASIC da Microsoft possuem mais ou menos a mesma base de código, e as diferenças que forem detectadas serão em sua maioria derivadas da arquitetura da máquina.

Nos computadores com a felicidade de usar um BASIC de verdade 3:-) (como os Acorn) teremos uma visão da vantagem (ou desvantagem) estratégica desta decisão.

Por quê não uma linguagem compilada?

Por que eu não vejo necessidade de fazer benchmark de processador - isto, o próprio fabricante já fez e publicou os resultados.

Acabaríamos fazendo benchmark do próprio compilador por tabela - usando a linguagem BASIC, ao menos temos uma baseline algo que estável e eliminamos (bom, maos ou menos) uma variável na análise.

O interessante é ver como a máquina se comporta sendo usada da forma que o fabricante planejou.

Isto não é uma corrida! :-)

Por quê o AmigaBASIC?

Por quê o alerta apocalíptico sobre capacitores no e-mail pras listas?

Porque capacitores eletrolíticos possuem vida útil limitada, e quando resolverm se matar acabam levando o computador junto.

Os benchmarks em não são "perigosos", mas alguns botam a máquina pra funcionar à toda por vários minutos (ou mesmo horas): se um capacitor estourar durante os testes, ele já estava engatilhado e de certeza explodiria em breve - de forma que você deveria já ter providenciado a substituição de qualquer jeito.

Basicamente, o problema é que o fluido eletrolítico do capacitor mais cedo ou mais tarde corrói o isolante e ou vaza pela placa (correndo trilha e componentes), ou causa um curto circuito que por sua vez causa um aquecimento abrupto do componente seguido pela formação de gases e conseqüente explosão - o que não só pode danificar a placa e componentes em si, como dependendo do tramanho do capacitor pode espalhar ácido quente pelo micro inteiro - uma merda pra limpar depois.

E como a máquina talvez fique ligada por horas sem ninguém tomando conta, o estrago pode ser muito maior (talvez catastrófico) por causa disto.

Não quero levar a culpa depois! :-)

Orientações

Quer brincar com a gente? :-)

Manda um email para me at lisias dot net e observe as seguintes regras:

  1. Não sobrescreva a medição de um colega:
  2. Se colocar uma arquitetura "nova", use a nomenclatura:
  3. Se você não tiver saco de fazer todos os testes, não esquenta. Deixa a célula com fundo amarelinho, talvez outro colega se arme de paciência e faça o teste. :-)
  4. Se você for este colega armado de paciência, adicione seu nome (o seu nome mesmo, não a string!!) junto ao do medidor original e coloque no comentário da célula as suas iniciais.
  5. Testar algumas configurações aparenta ser estúpido (usar DOS 3.3 ou ProDOS ou simplesmente a versão interna, carregando pelo K7, no A2, por exemplo). Mas não se acanhe, se tiver saco e quiser testar uma configuração diferente (por exemplo, eu preferi testar no ProDOS por causa da minha CFFA, não fiz nenhum teste Applesoft com DOS 3.3 ou apenas no cassete), ninguém vai ficar chateado.
  6. Email é opcional, mas é conveniente que eu possa entrar em contato com você de alguma forma.
  7. Os programas estão na aba listagens, em ordem incremental de cima para baixo.
  8. Não esqueça de colocar seu nome no campo Medidor!
  9. Os benchmarks não visam "serem justos", visam comparatividade.
  10. Nos benchmarks de ponto flutuante, caso o interpretador tenha mais de um tipo (single, double, etc) usa-se o default da linguagem e esquece-se o assunto. Isto não é uma corrida. :-)
  11. Tenha em mente que isto é um trabalho para satisfazer uma curiosidade.

Fontes e imagens

Aqui estão as imagens para algumas das plataformas (atualizadas em 2012/08/18):

Amiga

Apple II

Acorn

MSX

Sinclair

Como medir

Para micros que geram SOM, eu estou usando a seguinte gambiarra para cronometrar:

  1. Coloca um microfone destes de PC encostado no autofalante
  2. Com o Audacity (ou qualquer outro programa gravador de som), configurando para o sampler mais pimbinha (pra economizar memória: eu uso 8Khz/16bits/mono , não uso 8 bits pq o Audacity não deixa! : 0.5 giga dá pra noite toda!)
  3. Configuro a sensibilidade para abafar o quanto puder o ruído ambiente, mas ainda gravar claramente os beeps.
  4. Deixo gravando, rodo o benchmark, e vou fazer outra coisa (como lavar louça... ugh).
  5. Depois, quando acabar, é só procurar os BEEPs (se você abafou o ruído ambiente direito, fica claramente visível na tela do Audacity) e medir o intervalo de tempo. ;-)

O co-listeiro Alexandre Neves deu a idéia de usar uma filmadora gravando a tela, e depois procurar quando a tela muda. Ou usar um software de CFTV para monitorar apenas as mudanças no vídeo.

Outro co-listeiro, Leonardo Suárez, deu a dica de usar webcam ou um smartphone - há programas para monitorar mudanças de vídeo também para PCs e alguns celulares.


Lisias.
Outubro/2012