Por que você não pode ter instruções altas por ciclo e alta velocidade de relógio?

O Megahertz Myth se tornou uma tática promocional devido a diferenças entre o processador INTEL 8086 do PC e o processador Rockwell 6502 da Apple. O 8086 rodava em 4.77MHz enquanto o 6502 rodava em 1MHz. No entanto, as instruções no 6502 precisavam de menos ciclos; tantos menos, na verdade, que rodou mais rápido que o 8086. Por que algumas instruções precisam de menos ciclos? E por que as instruções do 6502, que precisam de menos ciclos, 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

Fatores que governam o IPC
Um determinado nível de instruções por segundo pode ser alcançado com um IPC alto e uma baixa velocidade de clock ... ou com um IPC baixo e alta velocidade de clock.

Por que você não pode ter instruções altas por ciclo e alta velocidade de relógio?

Talvez isso tenha a ver com o que é um ciclo de relógio? Wikipedia menciona sincronização de circuitos? Não tenho certeza o 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 idéia seria ótima! Apenas tentando entender a arquitetura por trás do mito. Obrigado!

Referências:

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

http://en.wikipedia.org/wiki/Instructions_per_cycle

http://en.wikipedia.org/wiki/Clock_cycle

tl; dr

Tubulações mais curtas significam velocidades de clock mais rápidas, mas podem reduzir o rendimento. Além disso, veja as respostas 2 e 3 na parte inferior (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 dez ou vinte) instruções de volta

Um pipeline muito simplificado (o que acontece nos modernos chips Intel está além do complexo) possui vários estágios:

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

Em cada -> há um custo de tempo incorrido. Além disso, a cada tick (ciclo do relógio), tudo se move de um estágio para o próximo, de modo que o estágio mais lento se torna a velocidade para TODOS os estágios (realmente vale a pena que tenham o maior comprimento possível).

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

Embora cada instrução precise de 5 ciclos de relógio para ser concluída, uma instrução finalizada sai do pipeline a cada ciclo. Se o tempo necessário para cada estágio for de 40 ns e 15 ns para os bits intermediários (usando meu pipeline de seis estágios acima), serão necessários 40 * 6 + 5 * 15 = 315 ns para obter a primeira instrução.

Por outro lado, se eu eliminasse completamente o pipeline (mas mantivesse tudo o mesmo), seriam necessários apenas 240 ns para obter a primeira instrução. (Essa diferença de velocidade para obter a "primeira" instrução é denominada latência. Geralmente é menos importante que a taxa de transferência, que é o número de instruções por segundo).

A diferença é que, no exemplo em pipeline, recebo uma nova instrução (após a primeira) a cada 60 ns. No não-pipelined, são necessários 240 todas as vezes. Isso mostra que os pipelines são bons para melhorar a taxa de transferência.

Indo um passo adiante, parece que no estágio de acesso à memória, precisarei de uma unidade adicional (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, eu posso fazer outra adição. Assim, eu posso executar dois estágios de execução (sendo 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 adicional no caso de um salto, para que eu possa executar três estados de execução de adição em um tick). Por ter um pipeline, ele pode ser projetado de modo que duas (ou mais) instruções possam usar estágios diferentes (ou estágios de salto em distância, etc.), economizando um tempo valioso.

Observe 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 sejam publicadas mais rapidamente do que sem um pipeline (observe que os pipelines que são muito longos são muito difíceis de gerenciar e incorrem em um custo mais alto apenas esperando entre os estágios). Por outro lado, se você prolongar o pipeline por muito tempo, poderá obter uma velocidade de relógio insana, mas perderá muitos 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 nº 2:

Os processadores SIMD (instrução única de dados múltiplos) (como a maioria das GPUs) trabalham muito em muitos bits de informação, mas isso leva mais tempo. A leitura de todos os valores leva mais tempo (significa um relógio mais lento, embora esse deslocamento tenha um barramento muito mais amplo, em certa medida), mas você pode obter muito mais instruções por vez (instruções mais eficazes por ciclo).

Resposta nº 3:

Como você pode "enganar" e prolongar artificialmente a contagem de ciclos, é possível executar duas instruções a cada ciclo (reduza pela metade a velocidade do relógio). Também é possível fazer algo a cada dois ticks em vez de um (dando uma velocidade de clock 2x, mas não alterando as instruções por segundo).

Estou simplificando muito 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 de 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 a limpeza de todo o pipeline. Se for bem-sucedido, isso significa que seu próximo ciclo não será otimizado porque você precisará preencher o pipeline novamente, o que pode levar algum tempo.

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

Os detalhes envolvem muita física e engenharia elétrica que eu realmente não entendo, mas lembre-se de que a freqüência não é alcançada apenas adicionando ingenuamente a tensão de entrada ao processador e esperando o melhor. No mínimo, o perfil térmico é outra preocupação necessária.

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

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

Como alternativa, você pode dizer: "Busque o primeiro número em um registro. Em seguida, busque o segundo número. Em seguida, adicione os bits menos significativos. Em seguida, adicione o segundo bit menos significativo com o carry de antes. Em seguida, adicione o terceiro ... . Em seguida, adicione os bits mais significativos. Se houver um transporte, defina o sinalizador de estouro. Em seguida, escreva o resultado na memória. " Agora você tem um grande número de etapas. Mas cada passo pode ser absurdamente rápido. Portanto, você tem poucas instruções por ciclo (mais ou menos 1/36 neste caso). Mas a velocidade do seu relógio pode ser muito alta, pois cada ciclo tem apenas um pouquinho muito a fazer.

Para ter instruções altas por ciclo e uma velocidade de clock alta, é necessário 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 compensações específicas reais e os números de ciclo são muito diferentes porque as CPUs modernas são canalizadas e se sobrepõem às instruções. Mas a ideia básica está correta.

Você pode ter instruções altas por ciclo e uma velocidade de clock alta. 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 da CPU, mas deve-se notar que isso aumentará o consumo de energia (e, portanto, o calor dissipado).

Portanto, se você deseja uma velocidade de clock mais rápida, precisa aumentar a tensão (aumentando a velocidade de desvio do elétron ) para reduzir o atraso de propagação. Se esse atraso exceder um ciclo de clock, é provável que a CPU não se comporte conforme o esperado, e o software executado nela falhará ou lançará uma exceção. Obviamente, existe um limite para a voltagem que você pode executar através de um processador, e isso é ditado pelo design da própria CPU - principalmente, a capacidade de transporte de corrente dos caminhos elétricos internos.

O pipelining permite velocidades de clock mais altas em alguns casos, porque cada instrução é dividida em várias "micro-operações" menores. Essas micro-operaçõ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 de propagação por uma subunidade específica).

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

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

O efeito das operações de vários ciclos é menos perceptível em um design RISC (por exemplo, ARM), em oposição a um design CISC (por exemplo, x86). Isso ocorre porque os projetos baseados em RISC terão apenas as operações elementares mais usadas e são muito mais fáceis de canalizar de maneira a obter uma taxa de transferência de uma instrução por ciclo.

Quanto tempo o computador leva para concluir uma tarefa específica 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 tomada pelo projetista da CPU, às vezes por boas razões (eficiência), às vezes por más (publicidade).

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 exatamente em 1 tick. No entanto, se os tempos de execução da instrução forem distribuídos uniformemente, isso significa que suas unidades computacionais ficariam ociosas 50% do tempo (a velocidade média de execução seria 50ns, deixando os outros 50ns do tick inativos). Se, por outro lado, você definir seu tick para 10ns, as instruções variarão entre 1 e 10 ticks, mas a unidade nunca ficará inativa por mais de 9ns antes do início da próxima instrução, e o idle médio será 5ns.

Durante o desenvolvimento, uma CPU será projetada para funcionar a uma certa velocidade, com base em quanto trabalho a CPU é capaz de realizar. Se você aumenta ou diminui a velocidade do relógio, na verdade não está alterando a quantidade de trabalho que a CPU pode realizar, apenas mexendo na taxa de eficiência.

(E antes de você chorar por overclock de CPUs: isso oferece duas vantagens que resultam em ganhos de velocidade no mundo real: instruções de execução rápida (que levam menos de 1 ciclo) terminam com tempos de execução mais rápidos e todas as instruções têm menos tempo ocioso. de fato, isso pode aumentar a quantidade de trabalho que seu computador pode executar, mas você descobrirá que o overclock de uma CPU em X% nem sempre é igual a um aumento de X% no trabalho realizado quando você a compara.)

TL; DR

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

Não se pode ter instruções altas por ciclo e alta velocidade do relógio porque os requisitos são contraditórios.

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

IPC = um sqrt (A)

considerando que a frequência máxima (F) alcançável pelo projeto é dimensionada como [1]

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

com parâmetros a, bec.

Assim, aumentar a complexidade do muarch aumenta o IPC às custas da redução da frequência de trabalho, enquanto reduzir a 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.

• Projeto Brainiac: IPC alto e baixa frequência
• Design demônio da velocidade: alta frequência e baixo 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.