Não entendo por que os fabricantes de CPU fabricam chips com vários núcleos. O dimensionamento de vários núcleos é horrível, isso é altamente específico do aplicativo e tenho certeza de que você pode apontar um determinado programa ou código que funciona muito bem em muitos núcleos, mas na maioria das vezes o dimensionamento é lixo. É um desperdício de espaço de silicone e um desperdício de energia.

Os jogos, por exemplo, quase nunca usam mais de quatro núcleos. Simulações de ciência e engenharia, como Ansys ou Fluent, custam quantos núcleos o PC roda, então você paga mais porque possui mais núcleos, mas o benefício de mais núcleos se torna realmente ruim depois dos 16 núcleos, mas você tem esses 64 núcleos estações de trabalho ... é um desperdício de dinheiro e energia. É melhor comprar um aquecedor de 1500 W para o inverno, muito mais barato.

Por que eles não fazem uma CPU com apenas um grande núcleo?

Eu acho que se eles fizessem o equivalente a um núcleo de uma CPU de oito núcleos, esse núcleo teria um aumento de 800% no IPC, para que você obtivesse o desempenho completo em todos os programas, não apenas naqueles otimizados para vários núcleos. Mais IPC aumentam o desempenho em todos os lugares, é uma maneira confiável e simples de aumentar o desempenho. Múltiplos núcleos aumentam o desempenho apenas em um número limitado de programas e a escala é horrível e não confiável.

O problema está no pressuposto de que os fabricantes de CPU podem simplesmente adicionar mais transistores para tornar um único núcleo de CPU mais poderoso, sem conseqüências.

Para fazer uma CPU fazer mais, você precisa planejar o que fazer mais implica. Existem realmente três opções:

1. Faça o núcleo funcionar com uma frequência de clock mais alta - o problema é que já estamos atingindo as limitações do que podemos fazer.

   O uso de energia e, portanto, a dissipação térmica aumentam com a frequência - se você duplicar a frequência, você nominalmente duplicará a dissipação de energia. Se você aumentar a voltagem, sua dissipação de energia aumentará com o quadrado da voltagem.

   Interconexões e transistores também apresentam atrasos na propagação devido à natureza não ideal do mundo. Você não pode simplesmente aumentar o número de transistores e espera poder rodar na mesma frequência de clock.

   Também estamos limitados por hardware externo - principalmente RAM. Para acelerar a CPU, é necessário aumentar a largura de banda da memória, executando-a mais rapidamente ou aumentando a largura do barramento de dados.

2. Adicione instruções mais complexas - Em vez de correr mais rápido, podemos adicionar um conjunto de instruções mais rico - tarefas comuns como criptografia etc. podem ser reforçadas no silício. Em vez de usar muitos ciclos de clock para calcular em software, temos aceleração de hardware.

   Isso já está sendo feito nos processadores CISC (Complex Instruction Set). Veja coisas como SSE2, SSE3. Hoje, um único núcleo de CPU é muito mais poderoso do que um núcleo de CPU há 10 anos, mesmo que seja executado na mesma frequência de clock.

   O problema é que, ao adicionar instruções mais complicadas, você adiciona mais complexidade e torna o chip maior. Como resultado direto, a CPU fica mais lenta - as frequências de clock alcançáveis ​​caem à medida que os atrasos na propagação aumentam.

   Essas instruções complexas também não ajudam em tarefas simples. Você não pode proteger todos os casos de uso possíveis; assim, inevitavelmente, grandes partes do software que você está executando não se beneficiarão de novas instruções e, de fato, serão prejudicadas pela resultante redução da taxa de clock.

   Você também pode aumentar a largura do barramento de dados para processar mais dados de uma só vez; no entanto, novamente isso aumenta a CPU e você encontra uma troca entre a taxa de transferência obtida através de barramentos de dados maiores e a queda na taxa de clock. Se você possui apenas dados pequenos (por exemplo, números inteiros de 32 bits), ter uma CPU de 256 bits não ajuda muito.

3. Torne a CPU mais paralela - em vez de tentar fazer uma coisa mais rapidamente, faça várias coisas ao mesmo tempo. Se a tarefa que você está realizando se presta a operar várias coisas ao mesmo tempo, você quer uma única CPU que possa executar vários cálculos por instrução (SIMD) ou ter várias CPUs que podem executar uma Cálculo.

   Este é um dos principais drivers para CPUs com vários núcleos. Se você tem vários programas em execução ou pode dividir seu único programa em várias tarefas, ter vários núcleos de CPU permite fazer mais coisas ao mesmo tempo.

   Como os núcleos individuais da CPU são efetivamente blocos separados (exceto caches e interfaces de memória), cada núcleo individual é menor que o único núcleo monolítico equivalente. Como o núcleo é mais compacto, os atrasos na propagação são reduzidos e você pode executar cada núcleo mais rapidamente.

   A questão de saber se um único programa pode se beneficiar de ter vários núcleos, depende inteiramente do que esse programa está fazendo e como foi escrito.

Além das outras respostas, há outro elemento: o rendimento do chip . Um processador moderno possui vários bilhões de transistores, cada um desses transistores precisa funcionar perfeitamente para que todo o chip funcione corretamente.

Ao criar processadores com vários núcleos, você pode particionar de maneira limpa grupos de transistores. Se houver um defeito em um dos núcleos, você poderá desativá-lo e vender o chip por um preço reduzido, de acordo com o número de núcleos em funcionamento. Da mesma forma, você também pode montar sistemas a partir de componentes validados como em um sistema SMP.

Para praticamente todos os CPUs que você compra, a vida começou a ser um modelo premium de ponta para essa linha de processadores. O resultado final depende de quais partes do chip estão funcionando incorretamente e estão desabilitadas. A Intel não fabrica processadores i3: todos estão com defeito no i7, com todos os recursos que separam as linhas de produtos desativados porque falharam no teste. No entanto, as partes que ainda estão funcionando ainda são úteis e podem ser vendidas por muito mais barato. Qualquer coisa pior se torna bugigangas de chaveiro.

E defeitos não são incomuns. Criar perfeitamente esses bilhões de transistores não é uma tarefa fácil. Se você não tiver oportunidades de usar seletivamente partes de um determinado chip, o preço do resultado aumentará rapidamente.

Com apenas um único processador über, a fabricação é tudo ou nada, resultando em um processo muito mais dispendioso. Para alguns dispositivos, como sensores de imagem para fins científicos ou militares, nos quais você precisa de um sensor enorme e tudo tem que funcionar, os custos desses dispositivos são tão grandes que apenas os orçamentos em nível estadual podem pagar.

Dependência de dados

É bastante fácil adicionar mais instruções por relógio, tornando o chip "mais amplo" - essa foi a abordagem "SIMD". O problema é que isso não ajuda na maioria dos casos de uso.

Existem aproximadamente dois tipos de carga de trabalho, independentes e dependentes. Um exemplo de carga de trabalho independente pode ser "com duas seqüências de números A1, A2, A3 ... e B1, B2, ... etc, calcular (A1 + B1) e (A2 + B2) etc." Esse tipo de carga de trabalho é visto em computação gráfica, processamento de áudio, aprendizado de máquina e assim por diante. Muito disso foi atribuído às GPUs, projetadas especialmente para lidar com isso.

Uma carga de trabalho dependente pode ser "Dado A, adicione 5 a ele e procure-o em uma tabela. Pegue o resultado e adicione 16 a ele. Pesquise-o em uma tabela diferente".

A vantagem da carga de trabalho independente é que ela pode ser dividida em várias partes diferentes, para que mais transistores ajudem nisso. Para cargas de trabalho dependentes, isso não ajuda em nada - mais transistores podem apenas torná-lo mais lento . Se você precisa obter um valor da memória, isso é um desastre para a velocidade. Um sinal deve ser enviado através da placa-mãe, viajando abaixo da velocidade da luz, a DRAM precisa carregar uma fila e aguardar o resultado, depois enviá-lo de volta. Isso leva dezenas de nanossegundos. Depois de fazer um cálculo simples, você deve enviar para o próximo.

Gerenciamento de energia

Núcleos de reposição são desativados na maioria das vezes. De fato, em muitos processadores, você não pode executar todos os núcleos o tempo todo sem que a coisa pegue fogo, então o sistema os desativará ou fará o downclock deles para você.

Reescrever o software é o único caminho a seguir

O hardware não pode converter automaticamente cargas de trabalho dependentes em cargas de trabalho independentes. Nem software. Mas um programador que está preparado para redesenhar seu sistema para tirar proveito de muitos núcleos pode.

Voltando no tempo, os processadores não foram capazes de executar tão rápido. Como resultado, se você queria fazer mais processamento, precisava de mais processadores. Isso pode ser com um coprocessador matemático ou simplesmente com mais do mesmo processador. O melhor exemplo disso é o Inmos Transputer dos anos 80, que foi projetado especificamente para processamento massivamente paralelo com vários processadores conectados. Todo o conceito dependia da suposição de que não havia melhor maneira de aumentar o poder de processamento do que adicionar processadores.

O problema é que essa suposição estava (temporariamente) incorreta. Você também pode obter mais poder de processamento fazendo com que um processador faça mais cálculos. A Intel e a AMD encontraram maneiras de aumentar a velocidade do clock cada vez mais e, como você diz, é muito mais fácil manter tudo em um processador. O resultado foi que, até meados dos anos 2000, o rápido processador single-core possuía o mercado. Inmos morreu no início dos anos 90, e toda a sua experiência morreu com eles.

Os bons tempos tiveram que terminar embora. Quando a velocidade do relógio chegou a GHz, realmente não havia margem para ir além. E voltamos a vários núcleos novamente. Se você realmente não pode ficar mais rápido, mais núcleos são a resposta. Como você diz, nem sempre é fácil usar esses núcleos com eficiência. Hoje em dia, estamos muito melhores, mas ainda estamos facilitando o processo como o Transputer.

Claro que também existem outras opções de aprimoramento - você poderia ser mais eficiente. O SIMD e conjuntos de instruções semelhantes realizam mais processamento para o mesmo número de tiques do relógio. O DDR coloca seus dados dentro e fora do processador mais rapidamente. Tudo ajuda. Mas quando se trata de processamento, voltamos aos anos 80 e a vários núcleos novamente.

Boa pergunta, ou pelo menos uma com uma resposta interessante. Parte dessa resposta mostra um mundo em que as CPUs podem ter uma escala eficiente de largura em vez de vários núcleos separados. Modelos de licenciamento / preço seriam diferentes!

O resto explica por que eles não podem. Resumo:

• O custo de múltiplos núcleos é dimensionado quase linearmente
• O custo da ampliação do pipeline superescalar de um núcleo é escalonado ~ quadraticamente Isso é possível com força bruta suficiente, até certo ponto. O desempenho de encadeamento único é muito importante para o uso interativo (a latência de ponta a ponta importa, não apenas a taxa de transferência); portanto, as atuais CPUs high-end de núcleo grande pagam esse preço. por exemplo, Skylake (4 de largura), Ryzen (5 ou 6 de largura) e A12 da Apple (7 de largura para os grandes núcleos, 3 de largura para os pequenos núcleos com eficiência energética)
• O IPC em diminuição grave retorna apenas da ampliação do pipeline para além de 3 ou 4 de largura, mesmo com execução fora de ordem para encontrar o ILP . As falhas de ramificação e de cache são difíceis e ainda paralisam todo o pipeline.

• Você não mencionou frequência, apenas IPC, mas a frequência de escala também é difícil. Uma frequência mais alta requer uma voltagem mais alta; portanto, a potência é escalonada com a frequência em cubo : ^1diretamente da frequência e ^2da tensão. (A energia armazenada no capacitor é dimensionada com V ^ 2, e a maior parte da energia dinâmica além da corrente de fuga é do bombeamento de carga para as cargas capacitivas dos portões + fios FET.)

  Desempenho = frequência vezes IPC. (Dentro da mesma arquitetura. O SIMD mais amplo permite que você faça o mesmo trabalho com menos instruções e alguns ISAs são mais densos que outros, por exemplo, o MIPS geralmente requer mais instruções para fazer o mesmo trabalho que o x86 ou o AArch64.)

Os custos estão na área da matriz (custo de fabricação) e / ou energia (que indiretamente limita a frequência porque o resfriamento é difícil). Além disso, menor potência e desempenho por Watt é um objetivo em si, especialmente para dispositivos móveis (bateria) e servidores (densidade de energia / custos de refrigeração / custos de eletricidade).

Antes que o multi-core por soquete fosse uma coisa, você tinha sistemas com vários soquetes para casos de uso avançados, nos quais desejava mais taxa de transferência do que era possível com uma única CPU que poderia ser fabricada, portanto esses eram os únicos sistemas SMP. (Servidores, estações de trabalho de última geração).

Se um único núcleo pudesse ser dimensionado com a eficiência que você desejasse, teríamos sistemas com 1 núcleo físico por soquete e SMT (por exemplo, HyperThreading) para permitir que eles atuassem como múltiplos núcleos lógicos. Os desktops / laptops típicos teriam apenas um núcleo físico e não teríamos dificuldade em paralelizar coisas que não são dimensionadas linearmente com mais núcleos. por exemplo, make -j4para aproveitar os servidores com vários soquetes e / ou ocultar a latência de E / S em uma área de trabalho. (Ou talvez ainda tentássemos paralelizar muito se a largura do pipeline fosse dimensionada facilmente, mas o IPC não o fizesse, então tivemos que usar mais encadeamentos SMT.) apresentar SMT para o sistema operacional era muito diferente; portanto, algoritmos de bloqueio paralelo e bloqueio ainda seriam necessários lá.

Donald Knuth disse em uma entrevista de 2008

Eu também poderia expor um pouco a minha infelicidade pessoal com a tendência atual em direção à arquitetura multicore. Para mim, parece mais ou menos que os projetistas de hardware ficaram sem ideias e estão tentando passar a culpa do futuro desaparecimento da Lei de Moore para os criadores de software , dando-nos máquinas que trabalham mais rápido apenas em algumas poucas. principais parâmetros de referência!

Sim, se pudéssemos ter CPUs milagrosas de núcleo único com 8x de taxa de transferência em programas reais , provavelmente ainda as estaríamos usando. Com sistemas de soquete duplo, apenas quando vale a pena pagar muito mais por mais rendimento (não desempenho de thread único).

Múltiplas CPUs reduzem os custos de troca de contexto quando vários programas estão em execução (permitindo que eles funcionem paralelamente, em vez de alternar rapidamente entre eles); multitarefa preventiva interrompendo a maquinaria maciça e fora de ordem que uma CPU exigiria provavelmente machucaria ainda mais do que agora.

Fisicamente, ele seria de núcleo único (para uma hierarquia de cache simples, sem interconexões entre núcleos), mas suportaria SMT (por exemplo, HyperThreading da Intel), para que o software pudesse usá-lo como 8 núcleos lógicos que competem dinamicamente pelos recursos de taxa de transferência. Ou quando apenas 1 thread está em execução / não está parado, ele obtém o benefício completo.

Então, você usaria vários encadeamentos quando isso fosse realmente mais fácil / natural (por exemplo, processos separados sendo executados ao mesmo tempo) ou para problemas facilmente paralelizados com cadeias de dependência que impediriam maximizar o IPC dessa fera.

Infelizmente, porém, é uma ilusão da parte de Knuth que as CPUs com vários núcleos deixem de ser uma coisa neste momento.

Escala de desempenho de thread único

Eu acho que se eles fizessem um equivalente de 1 núcleo de uma CPU de 8 núcleos, esse núcleo teria um aumento de 800% no IPC, para que você obtivesse o desempenho completo em todos os programas, não apenas naqueles otimizados para vários núcleos.

Sim, é verdade. Se fosse possível construir tal CPU , seria muito surpreendente. Mas acho que é literalmente impossível no mesmo processo de fabricação de semicondutores (ou seja, a mesma qualidade / eficiência dos transistores). Certamente não é possível com o mesmo orçamento de energia e área de matriz que uma CPU de 8 núcleos, mesmo que você economize na lógica para colar núcleos e não precise de muito espaço para caches privados por núcleo.

Mesmo que você permita aumentos de frequência (como o critério real é trabalhar por segundo, não funcionar por relógio), tornar a CPU ainda 2x mais rápida seria um grande desafio.

Se fosse possível, em qualquer lugar próximo do mesmo orçamento de energia e área de matriz (assim, o custo de fabricação), construir essa CPU, sim, os fornecedores de CPU já as construiriam dessa maneira.

Consulte Microprocessadores modernos Um guia de 90 minutos!

Especificamente, mais núcleos ou núcleos mais amplos? seção, para obter os antecedentes necessários para entender esta resposta; ele começa simples com o funcionamento de CPUs em pipeline em ordem e, em seguida, superescalar (várias instruções por relógio). Em seguida, explica como atingimos o muro de força por volta da era P4, levando ao fim da escala de frequência fácil, deixando principalmente apenas o IPC e realizando mais trabalho por instrução (por exemplo, SIMD) como o caminho a seguir, mesmo com transistores menores.

A ampliação de um pipeline (máximo de instruções por relógio) geralmente aumenta em custo como largura ao quadrado . Esse custo é medido na área da matriz e / ou energia, para uma verificação de dependência paralela mais ampla (detecção de perigos) e um agendador fora de serviço mais amplo para encontrar instruções prontas para execução. E mais portas de leitura / gravação no arquivo de registro e no cache, se você quiser executar instruções diferentes de nop. Especialmente se você tiver instruções de 3 entradas, como FMA ou add-with-carry (2 registros + sinalizadores).

Também há retornos decrescentes do IPC para ampliar as CPUs ; a maioria das cargas de trabalho possui ILP (Paralelismo no Nível da Instrução) de pequena escala / curto alcance para as CPUs explorarem, portanto, aumentar o núcleo não aumenta o IPC (instruções por relógio) se o IPC já estiver limitado a menos do que a largura do núcleo por cadeias de dependência, falhas de ramificação, falhas de cache ou outras paradas. Claro que você obteria uma aceleração em alguns loops desenrolados com iterações independentes, mas não é isso que a maioria dos códigos passa a maior parte do tempo fazendo. As instruções de comparação / ramificação representam 20% da combinação de instruções no código "típico", IIRC. (Acho que li números de 15 a 25% para vários conjuntos de dados.)

Além disso, uma falta de cache que interrompe todas as instruções dependentes (e tudo quando a capacidade do ROB é atingida) custa mais para uma CPU mais ampla. (O custo de oportunidade de deixar mais unidades de execução ociosas; mais trabalho potencial não está sendo realizado.) Ou um erro de ramificação da mesma forma causa uma bolha.

Para obter 8x o IPC, precisaríamos de pelo menos uma melhoria de 8x na precisão da previsão de ramificação e nas taxas de acerto do cache . Mas as taxas de acerto do cache não se adaptam bem à capacidade do cache além de um certo ponto para a maioria das cargas de trabalho. E a pré-busca de HW é inteligente, mas não pode ser tão inteligente. E com 8x do IPC, os preditores de ramificação precisam produzir 8 vezes mais previsões por ciclo, além de serem mais precisos.

As técnicas atuais para a criação de CPUs de execução fora de ordem só podem encontrar ILP em intervalos curtos . Por exemplo, o tamanho do ROB do Skylake é 224 uops de domínio fundido, o planejador para uops não executados é 97 de domínio não fundido. Consulte Compreendendo o impacto do lfence em um loop com duas longas cadeias de dependência, para aumentar os comprimentos de um caso em que o tamanho do planejador é o fator limitante na extração do ILP de duas longas cadeias de instruções, se elas forem muito longas. E / ou veja esta resposta mais geral e introdutória ).

Portanto, encontrar o ILP entre dois loops longos separados não é algo que podemos fazer com o hardware. A recompilação binária dinâmica para fusão de loop pode ser possível em alguns casos, mas as CPUs difíceis e não algo que realmente podem fazer, a menos que sigam a rota Transmeta Crusoe. (camada de emulação x86 em cima de um ISA interno diferente; nesse caso, VLIW). Porém, os projetos x86 modernos padrão com caches uop e decodificadores poderosos não são fáceis de superar na maioria dos códigos.

E fora do x86, todos os ISAs ainda em uso são relativamente fáceis de decodificar, portanto, não há motivação para a recompilação dinâmica além das otimizações de longa distância. TL: DR: esperar que os compiladores mágicos que podem expor mais ILP ao hardware não funcionou para o Itanium IA-64 e é improvável que funcione para uma CPU super ampla para qualquer ISA existente com um modelo serial de execução.

Se você tinha uma CPU super ampla, definitivamente desejaria que ela suportasse o SMT, para que você possa mantê-lo alimentado com o trabalho a executar executando vários threads de baixo ILP.

Como o Skylake atualmente tem 4 uops de largura (e alcança um IPC real de 2 a 3 uops por relógio, ou ainda mais perto de 4 no código de alto rendimento), uma hipotética CPU 8x mais ampla seria de 32!

Ser capaz de gravar isso de volta em 8 ou 16 CPUs lógicas que compartilham dinamicamente esses recursos de execução seria fantástico: os threads não paralisados ​​obtêm toda a largura de banda do front-end e a taxa de transferência de back-end.

Porém, com 8 núcleos separados, quando um encadeamento é interrompido, não há mais nada para manter as unidades de execução alimentadas; os outros threads não se beneficiam.

A execução geralmente é rápida: ela fica parada aguardando um carregamento incorreto do cache e, assim que chega muitas instruções em paralelo, pode usar esse resultado. Com uma CPU super ampla, essa explosão pode ir mais rápido e pode realmente ajudar com o SMT.

Mas não podemos ter CPUs mágicas super amplas

Portanto, para obter rendimento, precisamos expor o paralelismo ao hardware na forma de paralelismo no nível do encadeamento . Geralmente, os compiladores não são bons em saber quando / como usar threads, exceto em casos simples, como loops muito grandes. (OpenMP ou gcc -ftree-parallelize-loops). Ainda é preciso ter inteligência humana para refazer o código para obter um trabalho útil eficiente em paralelo, porque a comunicação entre threads é cara e a inicialização do thread também.

O TLP é um paralelismo de granulação grossa, diferentemente do ILP de granulação fina em um único encadeamento de execução que o HW pode explorar.

As CPUs voltadas para cargas de trabalho interativas (como Intel / AMD x86 e núcleos de ponta Apple / ARM AArch64) definitivamente contribuem para os retornos decrescentes do escalonamento IPC, porque o desempenho de thread único ainda é tão valioso quando a latência importa, não apenas a taxa de transferência. problemas massivamente paralelos.

Ser capaz de executar 8 cópias de um jogo em paralelo a 15fps cada é muito menos valioso do que ser capaz de executar uma cópia a 45fps. Os fornecedores de CPU sabem disso, e é por isso que as CPUs modernas usam execução fora de ordem, mesmo que custe energia e área de matriz significativas. (Mas as GPUs não o fazem porque sua carga de trabalho já é massivamente paralela).

O hardware Xeon Phi de muitos núcleos da Intel (Knight's Landing / Knight's Mill) é um ponto interessante: execução fora de ordem muito limitada e SMT para manter núcleos de 2 largos alimentados com instruções SIMX AVX512 para processar números. Os núcleos são baseados na arquitetura Silvermont de baixa potência da Intel. (Executor avariado, mas com uma pequena janela de reordenação, muito menor que a família Sandybridge de grande porte. E um pipeline mais estreito.)

BTW, tudo isso é ortogonal ao SIMD. Obter mais trabalho por instrução sempre ajuda, se for possível para o seu problema.

Modelos de preços

Os modelos de preços de software são baseados no cenário atual de hardware.

Os modelos de licenciamento por núcleo tornaram-se mais difundidos (e relevantes até para desktops de soquete único) com o advento de CPUs com vários núcleos. Antes disso, era relevante apenas para servidores e grandes estações de trabalho.

Se o software não precisasse de múltiplos núcleos para rodar na velocidade máxima, não haveria realmente uma maneira de vendê-lo mais barato para pessoas que não estão obtendo tanto benefício porque o executam em uma CPU mais fraca. A menos que talvez o ecossistema de software / hardware tenha desenvolvido controles em "canais SMT" que permitem configurar uma largura máxima de execução para o código em execução nesse núcleo lógico. (Imaginando novamente um mundo em que as CPUs escalam na largura do pipeline em vez de vários núcleos separados.)

Deixe-me fazer uma analogia:

Se você tem um macaco digitando em uma máquina de escrever e deseja fazer mais digitação, pode dar café ao macaco, lições de digitação e talvez fazer ameaças para que ele funcione mais rápido, mas chega um momento em que o macaco digitando na capacidade máxima.

Portanto, se você quiser digitar mais, precisará obter mais macacos.

Para estender ainda mais a analogia, você precisa de uma máquina de escrever separada para cada macaco (representando o barramento de dados que cada núcleo precisará), de uma maneira de levar bananas a cada macaco e de algo para capturar seus excrementos (análogo à distribuição de energia e calor) dissipação) e você precisa de uma maneira de garantir que os macacos não estejam todos tentando digitar a mesma passagem na Noite de Reis (análoga a dividir corretamente a carga de trabalho entre os processadores). Mas tudo isso é menos trabalhoso para obter mais ganhos do que tentar obter mais digitação de um macaco.

Você ressalta que muitos softwares não usam mais que (x) núcleos. Mas isso é inteiramente uma limitação colocada pelos projetistas desse software. Os PCs domésticos com vários núcleos ainda são novos (ish) e o design de software multithread também é mais difícil com APIs e idiomas tradicionais.

O seu PC também não está apenas executando esse 1 programa. Ele está fazendo várias outras coisas que podem ser colocadas em núcleos menos ativos, para que seu software principal não seja interrompido por eles.

Atualmente, não é possível apenas aumentar a velocidade de um único núcleo para corresponder à taxa de transferência de 8 núcleos. Provavelmente, mais velocidade terá que vir da nova arquitetura.

À medida que mais núcleos estão disponíveis e APIs são projetadas com essa suposição, os programadores começarão a usar mais núcleos. Esforços para tornar os projetos multiencadeados mais fáceis de fazer estão em andamento. Se você fizesse essa pergunta em alguns anos, provavelmente estaria dizendo "Meus jogos normalmente usam apenas 32 núcleos, então por que minha CPU possui 256?".

A razão mais convincente do ponto de vista histórico é a dissipação de energia .

Após o Pentium IV, a Intel tentou buscar um processador de próxima geração, codinome Tejas, que deveria rodar na faixa de 4 GHz a 12 GHz. O problema era que correr nessa velocidade gerava muito calor para ser viável.

Após o cancelamento de Tejas, a Intel levou outros 10 a 15 anos para finalmente terem núcleos rodando a 4 GHz com níveis aceitáveis ​​de calor.

Veja Tejas e Jayhawk .

A Intel tinha outro projeto em paralelo com Tejas, que envolvia o uso de múltiplos núcleos. Esse projeto tinha níveis aceitáveis ​​de calor, então foi assim que eles foram. Isso lhes permitiu aumentar o desempenho agora, em vez de esperar outros 10 anos pelos processos de fabricação de 10 nm.

Supondo que os núcleos não estejam com falta de recursos, para obter o mesmo número de instruções por segundo de um único núcleo em vez de N núcleos, você precisaria que a taxa de instruções desse núcleo único fosse N vezes mais rápida. A dissipação dinâmica de energia de um núcleo de CPU é linearmente proporcional à frequência de operação. Também é proporcional ao quadrado da tensão operacional. A operação em frequências mais baixas permite o uso de tensões operacionais mais baixas. O uso de tensões mais baixas em frequências mais baixas significa que, na prática, o calor gerado diminui com o cubo da frequência de operação.

Um exemplo extremo disso é o cérebro humano, que pode executar o equivalente a 2 ^ 18 operações por segundo usando apenas 20 W de potência. Consegue isso usando bilhões de neurônios funcionando paralelamente a apenas algumas centenas de Hz.

Lembre-se também de que geralmente existem centenas ou milhares de threads em execução ao mesmo tempo em um PC. O sistema operacional trata da alocação de tempo em um núcleo para cada encadeamento. Portanto, mesmo que um programa individual não aproveite todos os núcleos, ele ainda será beneficiado porque os outros programas estão gastando menos tempo com a CPU se executados em outro núcleo.

De qualquer forma, o mercado de alto desempenho está migrando para um processamento mais paralelo na forma de FPGAs. A Intel comprou recentemente a Altera (o segundo maior fabricante de FPGA) e agora está vendendo placas com um acelerador de hardware FPGA. O software pode carregar o FPGA com uma imagem em tempo de execução usando uma chamada de API. A CPU alimenta os dados no FPGA e permite que ele faça a maior parte do trabalho. Os tipos de aplicativos são tipicamente codificação de vídeo, IA, renderização, pesquisa em banco de dados etc.

Apenas para completar a imagem de onde tudo isso está indo ...

Redes neurais e IA são os tópicos super quentes do momento. Uma razão é que é possível usar eficientemente um grande número de núcleos simples em paralelo e, assim, extrair quase o máximo do desempenho computacional. O requisito é inerentemente paralelo em massa e mapeia com bastante facilidade na matriz de processadores sem muita comunicação necessária entre os núcleos. É por isso que as GPUs foram a primeira tecnologia a ir para a aceleração da IA. No momento, estamos vendo chips otimizados ainda melhor do que as GPUs de vídeo para NNs chegando ao mercado. O próximo passo, ou talvez final, é fazer NNs usando tecnologias analógicas como memristores.

E como um aparte, em algo como um PC para jogos, há muito mais desempenho bruto na placa de vídeo do que os processadores Intel ou AMD multicore

Fundamentalmente, as perdas de CMOS são exponencialmente (^ 1,5) proporcionais à frequência e o desempenho paralelo da CPU é um pouco menor que linear proporcional ao número de CPUs.

Portanto, a taxa de dissipação de energia para dissipação de energia é aprimorada para aplicativos com várias CPUs em diferentes taxas de clock ao comparar velocidade versus quantidade de CPU para uma dissipação de energia fixa.

É mais complexo do que isso, mas esses são os fundamentos da razão pela qual as CPUs paralelas são melhores em termos de watts em aplicativos dinâmicos. Sempre haverá exceções quando otimizadas para um cenário.

Não é o tamanho de uma CPU maior que o torna mais rápido para aplicativos típicos de PCs Intel / AMD, mas o tamanho reduzido da resolução litográfica e da capacitância de porta mais baixa que reduz a energia, juntamente com o nível de sublimiar mínimo e a voltagem do núcleo.

A melhoria não é linear e não significa que 8 núcleos são 4x melhores que 2, mas o objetivo a ser alcançado é ter mais faixa dinâmica de processamento com a otimização da dissipação de energia, velocidade e tensão para melhorar o desempenho e a eficiência e o pico de potência sob demanda sem aumento excessivo de temperatura.

Para uma resposta mais científica, leia https://www.sciencedirect.com/topics/computer-science/dynamic-power-consumption

Multicores geralmente não são multiscalar. E núcleos multiscalares não são multicores.

Seria meio que perfeito encontrar uma arquitetura multiscalar rodando em vários megahertz, mas em geral suas pontes não seriam habilitadas para o consumidor, mas caras, portanto a tendência é a programação multicore em frequência mais baixa do que instruções curtas em altas velocidades de clock.

Vários núcleos de instrução são mais baratos e fáceis de comandar, e é por isso que é uma má idéia ter arquiteturas multiscalar em vários gigahertz.