Instrução por Ciclo vs Contagem de Ciclo Aumentada

Question

Aumentar a instrução por ciclo ou aumentar a contagem de ciclos são opções de design válidas para fabricantes de processadores. Eu entendo teoria, mas seria muito mais claro se eu tivesse algum exemplo da vida real.

Então, alguém pode me dar algum exemplo que possa beneficiar tanto essa escolha de design? Como qual aplicativo / tipo de aplicativo / processo aproveita a maior contagem de IPC e que aproveita a contagem de ciclos mais alta.

    

Answer 1

O Arquiteto de Computadores

É preciso muito mais esforço de engenharia para aumentar o IPC do que simplesmente aumentar a freqüência do clock. Por exemplo. pipeline, caches, múltiplos núcleos - completamente introduzidos para aumentar o IPC - ficam muito complexos e requerem muitos transistores.

Embora a freqüência máxima do clock seja restrita pelo comprimento do caminho crítico de um dado design, se você tiver sorte, você pode aumentar a freqüência do clock sem qualquer refatoração. E mesmo que você tenha que reduzir os comprimentos de caminho, as mudanças não são tão profundas quanto as técnicas mencionadas acima requerem.

No entanto, com os processadores atuais, as freqüências de clock já são empurradas para os limites econômicos. Aqui, os ganhos de velocidade resultam exclusivamente do aumento do IPC.

O programador

Do ponto de vista do programador, isso é um problema, já que ele precisa ajustar seu estilo de programação aos novos sistemas criados pelos arquitetos de computadores. Por exemplo. a programação concorrente se tornará cada vez mais inevitável para aproveitar os altos valores do IPC.

    

Answer 2

Na verdade, desenvolvi alguns processadores (há muitos anos) e tenho um pouco de experiência nos trade-offs.

Para aumentar as instuções por ciclo (ou, mais provavelmente, reduzir os ciclos por instrução ) você geralmente tem que "jogar hardware" no problema - adicionar mais portões e trincos e multiplexadores. Além de um certo ponto (que foi passado há cerca de uma década) você deve "pipeline" e estar trabalhando em várias instruções ao mesmo tempo. Esse aumento na complexidade não apenas eleva os custos básicos (já que o custo de um chip está relacionado à área que ocupa), como também aumenta a probabilidade de um bug passar pela revisão inicial do projeto e resultar em um chip ruim que deve ser "respun" - um grande custo e agendamento. Além disso, o aumento na complexidade aumenta as cargas de tal forma que, na ausência de mais hardware, a duração de um ciclo aumenta de fato. Você poderia encontrar a situação em que a adição de hardware diminuiu as coisas. (Na verdade, eu vi isso acontecer em um caso.)

Além disso, o "pipelining" pode encontrar condições em que o pipeline é "interrompido" por causa de ramificações freqüentes (e inesperadas) e outros problemas, fazendo com que o processador fique lento para um rastreamento. Portanto, há um limite para quanto disso pode ser feito de forma produtiva.

Para acelerar os ciclos individuais, você precisa fazer uma das três coisas:

1. Use uma tecnologia mais rápida (um "não-brainer" se a tecnologia estiver disponível, mas tecnologias novas e mais rápidas não aparecerem com tanta frequência quanto costumavam)
2. De alguma forma, remova a lógica do "caminho crítico" (possivelmente apagando instruções complexas do conjunto de instruções ou adicionando outras limitações no nível do software).
3. Reduza o atraso de propagação pelos caminhos de dados mais lentos (o que geralmente significa "jogar hardware" novamente no problema - e novamente com a chance de que isso seja um tiro pela culatra e diminua a velocidade).

Portanto, há muitas compensações e um pouco de sapateado em um campo minado.