dah um certo trabalho determinar o performance relativa correta!
tradicionalmente, o valor em MIPS eh calculado em funcao do clock do processador e de quantos ciclos ele demora para rodar as instrucoes. o maior problema eh que as instrucoes costumam rodar em tempos muito variados, entao existem diversos valores possiveis de MIPS. como eu nao conheco o 8051 a fundo, vou pegar como referencia o 68000 original dd 1979: as instrucoes mais curtas dele sao executadas em 4 clocks, entao a 16MHz a performance de pico seria 4 MIPS. porem, isso tem restricoes:
a) vc pode usar apenas operandos em registros ou operandos imediatos embutidos (branch curto, move curto, add e sub curto)
b) no caso de operandos em registros, vc pode usar apenas operacoes de 16 bits (a largura do bus eh apenas 16 bits no core original)
embora pareca vantagem sustentar um pico de 4MIPS, a desvantagem eh que vc nao pode usar a melhor parte do set de instrucoes. se vc faz a mesma conta usando o set de instrucoes 32 bits e modos de enderecamento mais avancados, vc minimiza o numero de instrucoes, mas ao mesmo tempo aumenta o numero de ciclos. uma operacao registro a registro de 32 bits jah vai consumir pelo menos 6 clocks. uma instrucao de loop (decrementa contador, testa e salta) jah vai consumir 10 clocks. uma operacao memoria a memoria de 32 bits com pos-incremento nos ponteiros, literalmente um r=(*q++=*p++), jah vai consumir mirabolantes 22 clocks. e daih o calculo dos MIPS se confunde todo!
para resolver isso, surgiram diversos benchmarks, como o dhrystone (para ponto fixo) e o wetstone (para ponto flutuante). inicialmente, temos apenas uma contagem de loops/segundo, assim vc pode comparar o numero de loops num processador A e processador B, determinando assim o offset de performance relativa, mas nada absoluto.
bom, o truque eh que determinou-se, apos exaustivos estudos, que um determinado computador VAX conseguia sustentar 1MIPS rodando o dhrystone. desde entao usa-se o numero de loops do VAX como referencia para 1MIPS, surgindo assim o DMIPS. no caso especifico do VAX, um 1MIPS = 1DMIPS, mas nao eh o caso em outros processadores.
se vc pega um 68000 de 16MHz, vc consegue algo em torno de 1DMIPS (lembrando que a performance de pico calculada precisamente eh de 4MIPS). em outros casos, como em alguns ARMs nao superescalares, vc consegue digamos, 120DMIPS a 100MHz, porem sabemos que a performance de pico deste processador seria na verdade 100MIPS.
a diferenca parece consideravel, mas isso eh o que o seu compilador vai conseguir de um codigo generico. declarar "int i" no arm eh tipico, pq ele possui melhor performance com inteiros de 32 bits, como seria em um coldfire ou powerpc. vc nem pensa em otimizar pq o processador jah trabalha de forma otimizada com 32 bits. mas no caso do 68000 isso eh um pesadelo pq comuta justamente para o conjunto de instrucoes com maior penalidade. se vc otimizar isso e trocar "int i" por "register short i", vc consegue uma otimizacao de quase 4x, mas daih jah eh algo dedicado demais (dae vale mais a pena fazer update para um coldfire, q eh compativel em codigo com o 68000).
eh dificil achar uma tabela dhrystone com processadores menores que um 68000, mas aqui nesse site tem algumas referencias:
http://www.homebrewcpu.com/software_bringup.htm
se for considerar o 8086 como o parente vivo mais proximo do 8051, a 8MHz vc teria um index em torno de 250, o que resulta em quase 0.2 DMIPS com um clock de 8MHz. para um 8051 de 32MHz, entao, vc teria uns 0.8 MIPS x 8 (nivel de otimizacao do seu 8051 em relacao ao original), ou seja, 6.4DMIPS (os 21 MIPS q vc calculou seria a performance de pico!). isso q eu peguei um 8086, mas talvez o 8051 realmente esteja em um meio termo entre o 8086 e Z80. no pior caso seria apenas 0.1DMIPS e a performance liquida no dhrystone seria de 3.2DMIPS.
portanto, para a mesma *aplicacao final*, o arm provavelmente seria entre 3 e 6x mais rapido jah considerando as otimizacoes relativas da arquitetura. note tb que a performance do arm eh mais conscisa e varia menos com o benchmark pq ele jah eh, literalmente, otimizado para rodar o benchmark, ou seja, vai rodar aplicacoes tipicas em C melhor do que o 8051
