Por que você não pode ter instruções elevadas por ciclo e alta velocidade de clock?

34

O Megahertz Myth se tornou uma tática promocional devido às diferenças entre o processador INTEL 8086 do PC e o processador Rockwell 6502 da Apple. O 8086 funcionou a 4.77MHz enquanto o 6502 funcionava a 1MHz. No entanto, as instruções no 6502 precisavam de menos ciclos; muito menos, de fato, que ele correu mais rápido que o 8086. Por que algumas instruções precisam de menos ciclos? E por que as instruções do 6502 não podem ser combinadas com um processador de ciclo rápido do 8086?

O artigo da Wikipedia para instruções por ciclo (IPC) diz

Factors governing IPC
A given level of instructions per second can be achieved with a high IPC and a low clock speed...or from a low IPC and high clock speed.

Por que você não pode ter instruções elevadas por ciclo e alta velocidade de clock?

Talvez isso tenha a ver com o que é um ciclo de clock? Wikipedia menciona sincronização de circuitos? Não tenho certeza do que isso significa.

Ou talvez isso tenha a ver com o funcionamento de um pipeline? Não sei por que as instruções em um pipeline curto são diferentes das instruções em um pipeline longo.

Qualquer ideia seria ótima! Apenas tentando entender a arquitetura por trás do mito. Obrigado!

Referências:

Instrução por ciclo vs aumento da contagem de ciclos

link

link

    
por dobus 12.07.2012 / 05:20

6 respostas

19

tl; dr

Pipelines mais curtos significam velocidades de clock mais rápidas, mas podem reduzir o throughput. Além disso, veja as respostas 2 e 3 na parte inferior (elas são curtas, prometo).

Versão mais longa:

Há algumas coisas a considerar aqui:

  1. Nem todas as instruções levam o mesmo tempo
  2. Nem todas as instruções dependem do que foi feito imediatamente (ou mesmo de dez ou vinte) instruções

Um pipeline muito simplificado (o que acontece nos chips Intel modernos é muito complexo) tem várias etapas:

Buscar - > Decodificar - > Acesso à Memória - > Execute - > Writeback - > Atualização do contador de programa

Em cada um - > há um custo de tempo incorrido. Além disso, todo tick (ciclo de clock), tudo se move de um estágio para o próximo, então seu estágio mais lento se torna a velocidade para TODOS os estágios (realmente vale a pena que eles sejam o mais semelhantes possível).

Digamos que você tenha 5 instruções e queira executá-las (foto tirada da wikipedia, aqui a atualização do PC não foi feita). Ficaria assim:

Emboracadainstruçãoleve5ciclosdeclockparaconcluir,umainstruçãoacabadasaidopipelineacadaciclo.Seotemponecessárioparacadaestágiofor40nse15nsparaosbitsintermediários(usandomeupipelinedeseisestágiosacima),serãonecessárias40*6+5*15=315nsparaobteraprimeirainstrução.

Poroutrolado,seeufosseeliminartotalmenteopipeline(masmantertodoorestoigual),seriamnecessáriosapenas240nsparaobteraprimeirainstrução.(Essadiferençanavelocidadeparaobtera"primeira" saída de instrução é chamada de latência. Geralmente, é menos importante que a taxa de transferência, que é o número de instruções por segundo).

O real diferente é que no exemplo pipeline, eu recebo uma nova instrução (após a primeira) a cada 60 ns. No sem pipeline, são necessárias 240 vezes. Isso mostra que os pipelines são bons em melhorar o rendimento.

Dando um passo adiante, parece que no estágio de acesso à memória, eu precisarei de uma unidade de adição (para fazer cálculos de endereço). Isso significa que, se houver uma instrução que não use o estágio mem desse ciclo, posso fazer outra adição. Assim, posso executar dois estágios de execução (com um no estágio de acesso à memória) em um processador em um único tick (o agendamento é um pesadelo, mas não vamos lá. Além disso, o estágio de atualização do PC também precisará de uma unidade de adição no caso de um salto, então eu posso fazer três estados de execução de adição em um tick). Por ter um pipeline, ele pode ser projetado de tal forma que duas (ou mais) instruções possam usar estágios diferentes (ou estágios leapfog, etc), economizando tempo valioso.

Note que, para fazer isso, os processadores fazem muita "mágica" ( execução fora de ordem , previsão de ramificação e muito mais), mas isso permite que várias instruções saiam mais rápido do que sem um pipeline (nota que os pipelines que são muito longos são muito difíceis de gerenciar, e incorrem em um custo maior apenas esperando entre os estágios). O outro lado é que se você fizer o pipeline ficar muito tempo, você pode obter uma velocidade de clock insana, mas perderá muito dos benefícios originais (de ter o mesmo tipo de lógica que pode existir em vários lugares e ser usado ao mesmo tempo ).

Resposta 2:

SIMD (múltiplos dados de instrução única) processadores (como a maioria das GPUs) fazem muito trabalho em muitos bits de informação , mas leva mais tempo para fazer. A leitura em todos os valores é mais demorada (significa um relógio mais lento, embora isso seja compensado por ter um barramento muito mais amplo até certo ponto), mas você pode obter muito mais instruções por vez (instruções mais efetivas por ciclo).

Resposta 3:

Porque você pode "trapacear" um alongamento artificial da contagem de ciclo para que você possa fazer duas instruções a cada ciclo (diminua a metade a velocidade do clock). Também é possível fazer algo a cada dois ticks em vez de um (dando uma velocidade de clock de 2x, mas não mudando nas instruções por segundo).

    
por 12.07.2012 / 05:45
8

Estou muito simplificando isso, mas o ponto importante a lembrar é que esses termos estão comparando maçãs com laranjas. Um "Ciclo" não é uma única unidade de medida unificada que é a mesma em todos os processadores, como um "segundo" é uma medida unificada do tempo. Em vez disso, um ciclo representa uma certa unidade de trabalho, que é definida de maneira arbitrária, mas limitada pela complexidade do projeto do pipeline e, é claro, pela física.

Em muitos casos, fazer muito trabalho em um ciclo pode permitir que você limpe todo o pipeline. Se for bem-sucedido, isso significa que seu próximo ciclo será desatualizado porque você precisará preencher o pipeline novamente, o que pode levar algum tempo.

Eu poderia projetar um processador muito simplista que processa uma etapa de uma instrução RISC a cada ciclo, e se esta fosse a base da minha CPU, eu provavelmente conseguiria atingir ciclos muito altos por segundo devido à reduzida complexidade do que constitui "um ciclo".

Os detalhes entram em muita física e engenharia elétrica que eu realmente não entendo, mas lembre-se que o clock não é alcançado apenas adicionando ingenuamente tensão de entrada ao processador e esperando pelo melhor. No mínimo, o perfil térmico é outra preocupação necessária.

    
por 12.07.2012 / 05:32
5

Aqui está uma explicação muito simples (talvez excessivamente simplificada): digamos que você tenha um trabalho específico a fazer, por exemplo, adicione dois números de 32 bits. Você pode tomar duas abordagens. Você pode dividi-lo em um número muito grande de etapas muito pequenas ou pode dividi-lo em um pequeno número de etapas muito grandes.

Por exemplo, você poderia apenas dizer "adicionar os dois números". Agora você só tem um passo. Mas essa etapa tem várias partes e levará mais tempo para ser executada. Então você tem instruções altas por ciclo - uma neste caso. Mas a velocidade do seu relógio não pode ser alta porque você tem um lote para fazer nesse ciclo.

Você poderia alternativamente dizer: "Busque o primeiro número em um registrador. Então busque o segundo número. Então adicione os bits menos significativos. Então adicione o segundo bit menos significativo com o carry de antes. Então adicione o terceiro menos .... Em seguida, adicione os bits mais significativos. Se houver um carry, defina o sinalizador de overflow. Em seguida, grave o resultado na memória. " Agora você tem um grande número de etapas. Mas cada passo pode ser absurdamente rápido. Então você tem instruções baixas por ciclo (1/36 ou mais neste caso). Mas a velocidade do seu clock pode ser muito alta, já que cada ciclo tem apenas um pequeno bocado para fazer.

Para ter instruções elevadas por ciclo e uma alta velocidade de clock, você teria que dividir uma instrução complexa em um número muito pequeno de etapas muito simples. Mas isso não pode ser feito porque a instrução é complexa.

As trocas e números específicos de ciclos são muito diferentes porque as CPUs modernas são pipeleadas e se sobrepõem às instruções. Mas a ideia básica está correta.

    
por 12.07.2012 / 07:43
2

Você pode ter altas instruções por ciclo e uma alta velocidade de clock. Onde você encontra limites é quando o atraso de propagação do circuito digital excede a largura de pulso de um único ciclo de clock. Isso pode ser superado aumentando a tensão do processador, mas deve-se notar que isso aumentará o consumo de energia (e, portanto, o calor será dissipado).

Então, se você quer uma velocidade de clock mais rápida, você tem que aumentar a voltagem (aumentando a velocidade do drift de elétrons ) para reduzir o atraso de propagação. Se esse atraso exceder um ciclo de clock, a CPU provavelmente não se comportará como esperado, e o software em execução falhará ou lançará uma exceção. Obviamente, há um limite para a voltagem que você pode percorrer por meio de um processador, e isso é determinado pelo próprio design da CPU - principalmente, a capacidade de transporte de corrente das vias elétricas internas.

O pipelining permite velocidades de clock maiores em alguns casos, porque cada instrução é dividida em várias "micro-operações" menores. Essas microoperações são operações muito simples, usando circuitos muito menores interconectados em uma cadeia (no sentido físico, quanto menor a distância que os elétrons precisam percorrer, menor o atraso da propagação através de uma subunidade específica).

A vantagem adicional de uma CPU em pipeline é que você pode aumentar muito o número de instruções executadas por unidade de tempo, às custas de um design mais complexo.

Por que algumas instruções precisam de mais ou menos ciclos, isso depende de qual instrução você está executando. Por exemplo, no conjunto de instruções x86, há um MOVS instrução que pode mover uma string inteira na memória de um lugar para outro. Claramente, você não pode copiar instantaneamente uma longa string, mas pode copiá-la palavra por palavra, usando vários ciclos de clock. Assim, a instrução MOVS leva um tempo variável (dependendo da quantidade de caracteres a serem copiados).

O efeito das operações multicíclicas é menos perceptível em um projeto RISC (ou seja, ARM) em oposição a um < a href="http://en.wikipedia.org/wiki/Complex_instruction_set_computing"> CISC design (ou seja, x86). Isso ocorre porque os projetos baseados em RISC terão apenas as operações elementares mais comumente usadas e serão muito mais fáceis de serem canalizados, de modo a obter uma taxa de transferência de uma instrução por ciclo.

    
por 18.07.2012 / 15:56
1

O tempo que o seu computador demora para concluir uma determinada tarefa não depende da velocidade do relógio do computador ... depende de como as unidades computacionais são projetadas e projetadas.

A velocidade do relógio é, na verdade, uma decisão (mais ou menos) arbitrária feita pelo projetista da CPU, às vezes por boas razões (eficiência), às vezes para as ruins (propaganda).

Digamos que uma determinada CPU tenha uma mistura de instruções que levam entre 1 e 100 nanossegundos (ns) para serem concluídas. Você pode definir a taxa de clock de modo que 1 "tick" seja 100 ns (10 MHz), o que significa que todas as instruções terminariam em exatamente 1 tick. No entanto, se os tempos de execução da instrução forem distribuídos uniformemente, isso significa que suas unidades computacionais estariam ociosas em 50% do tempo (a velocidade média de execução seria de 50 ns, deixando os outros 50 ns da marca ociosa). Se, por outro lado, você definir seu tick como 10ns, as instruções vão variar entre 1 e 10 ticks, mas a unidade nunca ficará inativa mais de 9ns antes do início da próxima instrução, e a média de inatividade será de 5ns. Isso significa que o tempo ocioso médio caiu de 50% (média de 50 ns para cada 100) para 9% (já que o tempo médio de execução é agora de 55 ns (execução média de 50 ns + inatividade média de 5 ns)).

Durante o desenvolvimento, uma CPU será projetada para rodar a uma determinada velocidade, com base em quanto trabalho a CPU é realmente capaz de realizar. Se você aumentar ou diminuir a velocidade do clock, você não está realmente mudando a quantidade de trabalho que a CPU pode realizar, você está apenas mexendo com a taxa de eficiência dela.

(E antes de chorar sobre CPUs com overclock: isso oferece duas vantagens que resultam em ganhos de velocidade reais: instruções rápidas de execução (que levam menos de 1 ciclo) acabam com tempos de execução mais rápidos e todas as instruções têm menos ociosidade Ambos podem na verdade aumentar a quantidade de trabalho que seu computador pode executar, mas você verá que fazer overclock de uma CPU em X% nem sempre é igual a X% de aumento no trabalho realizado quando você faz benchmark.)

TL; DR

Uma CPU pode realizar X trabalho em um segundo. Se você usar a velocidade do clock H e I IPC, temos I = X / H. Mudar H não muda X, mas isso afeta inversamente I.

    
por 16.07.2012 / 05:24
0

Não é possível ter instruções altas por ciclo e velocidade de clock alta porque os requisitos são contraditórios.

Pode-se mostrar que, em uma primeira aproximação, o IPC depende da complexidade (A) do design como

IPC = um sqrt (A)

enquanto que a frequência máxima (F) alcançável pelas escalas de design como [1]

F = 1 / {b + c sqrt (A)}

com os parâmetros a, b e c.

Assim, aumentar a complexidade do muarch aumenta o IPC em detrimento da redução da frequência de trabalho, enquanto a redução da complexidade aumenta a frequência às custas do IPC. Isso corresponde aos dois casos extremos mencionados no artigo da wikipedia, mas a wikipedia não menciona os nomes: Brainiac e speed-demon.

  • Design de Brainiac: alta IPC e baixa frequência
  • Speed-demon desing: alta frequência e baixa IPC.

[1] Alguns autores afirmam que a expressão para a frequência é "1 / {b + c A}", mas, em ambos os casos, o aumento da complexidade reduz a frequência máxima alcançável.

    
por 09.12.2017 / 19:02