Marcelo Samsoniuk escreveu:mas pense bem, ele soh vai fazer mais de uma instrucao por clock em quatro casos:
Ele não faz mais que uma instrução por ciclo de clock em caso algum, foi exatamente o que eu disse (e o que vc disse tbm, opção "c"): ele "engana" o teste pq a arquitetura de origem tem instruções que tomam vários ciclos de clock e sofrem penalidade praticamente em todo jump.
Tendo isto em mente, o arm7tdmi tem *varias* as instrucoes com mais de 1 ciclo de clock, alias, algumas operacoes como mult e mesmo divisao sao meio pesadas pq sao divididas em varias instrucoes [o arm7tdmi ñ faz single cicle multiply, infelizmente], e no caso da divisao, é emulada, qualquer dividendo q nao seja potencia de dois já envolve pelo menos uma multiplicacao por constante, o q (dependendo da constante) leva varios ciclos (pq multiplicacao ñ é single cycle].
Isto faz com que, quando comparando o cortex-m3 com *este*, ele tenha referencia acima deste, e, por coincidencia, acima da maq de referencia, pq este faz multiplicacoes com single cicle e operacoes q nenhuma das duas (arm7tdmi e maq. de referencia deve fazer). Complementarmente a isto, o branch predictor faz praticamente um loop unrolling na pratica, pq diminui a *media* do custo de cada site para 1 ciclo. No caso do arm7tdmi a penalidade é ao menos 3 ciclos (mais, se a ram/rom tiver wait-states). Em todos os casos tou assumindo q nao existem caches, ñ sei como é o caso do vax.
Eu nao vi, mas suponho q o test case tenha loops apertados (com poucas instrucoes), costuma ser comum em testes q tentam mensurar largura de banda de I/O dentre outros fatores.
Loop apertado no cortex m3 = quase um loop unroll
loop apertado no arm7tdmi (e, suponho, mais ainda no vax) = branch penalities.
Mantendo em mente que DMIPS != media de instrucoes por ciclo de clock, como vc mesmo lembrou, ja que em CISC esta métrica seria meio inútil, fica tudo claro.
Entao, lembrando, os cortex-m"x" ñ fazem + q 1 instr. por ciclo de clock, simplesmente pq ñ são super-escalares. o cortex-m4 tem simd, mas "multiple data" ñ conta como "multiple instruction", neh?
os cortex a-x (ñ sei se todos) são super-escalares, mas eu sei muito pouco da arquitetura deles; sei q alem disso, o cortex-a8 tem uma unidade vetorial como co-processador e q a troca de dados entre o core e esta unidade ñ é lá muito otimizado (dependendo de como for feito o acesso), mas aí tbm não conta muito, pq seria um tipo de simd, apesar das instrucoes correrem em paralelo. Mas se mensurarmos apenas os cores, sem parafernálias externas além do bus, fica mais real, certo?
por polesapart » 23 Fev 2010 17:01 
