Por que temos CPUs com todos os núcleos nas mesmas velocidades e não combinações de velocidades diferentes?

Em geral, se você estiver comprando um computador novo, determinará qual processador comprar de acordo com a carga de trabalho esperada. O desempenho nos jogos tende a ser determinado pela velocidade de núcleo único, enquanto aplicativos como a edição de vídeo são determinados pelo número de núcleos.

Em termos do que está disponível no mercado - todas as CPUs parecem ter aproximadamente a mesma velocidade, com as principais diferenças sendo mais threads ou mais núcleos.

Por exemplo:

• Intel Core i5-7600K, frequência base 3,80 GHz, 4 núcleos, 4 threads
• Intel Core i7-7700K, frequência base 4,20 GHz, 4 núcleos, 8 threads
• AMD Ryzen 5 1600X, frequência base 3,60 GHz, 6 núcleos, 12 threads
• AMD Ryzen 7 1800X, frequência base 3,60 GHz, 8 núcleos, 16 threads

Então, por que vemos esse padrão de aumento de núcleos com todos os núcleos com a mesma velocidade de clock?

Por que não temos variantes com diferentes velocidades de clock? Por exemplo, dois núcleos 'grandes' e muitos núcleos pequenos.

Por exemplo, em vez de, digamos, quatro núcleos a 4,0 GHz (ou seja, 4x4 GHz ~ 16 GHz no máximo), que tal uma CPU com dois núcleos em execução, digamos, 4,0 GHz e digamos quatro núcleos em 2 GHz (ou seja, 2x4,0 GHz + 4x2,0 GHz ~ 16 GHz no máximo). A segunda opção não seria igualmente boa em cargas de trabalho com encadeamento único, mas potencialmente melhor em cargas de trabalho com vários encadeamentos?

Eu faço essa pergunta como um ponto geral - não especificamente sobre as CPUs listadas acima ou sobre qualquer carga de trabalho específica específica. Estou apenas curioso para saber por que o padrão é como é.

Isso é conhecido como multiprocessamento heterogêneo ( HMP ) e é amplamente adotado por dispositivos móveis. Em dispositivos baseados em ARM que implementam big.LITTLE , o processador contém núcleos com diferentes perfis de desempenho e energia, por exemplo, alguns núcleos são executados rapidamente, mas consomem muita energia (arquitetura mais rápida e / ou relógios mais altos), enquanto outros economizam energia, mas são lentos ( arquitetura mais lenta e / ou relógios mais baixos). Isso é útil porque o uso de energia tende a aumentar desproporcionalmente à medida que você aumenta o desempenho quando passa de um determinado ponto. A idéia aqui é obter desempenho quando necessário e duração da bateria quando não for necessário.

Nas plataformas de desktop, o consumo de energia é muito menor e, portanto, isso não é realmente necessário. A maioria dos aplicativos espera que cada núcleo tenha características de desempenho semelhantes, e os processos de agendamento para sistemas HMP são muito mais complexos do que o agendamento para sistemas SMP tradicionais. (O Windows 10 tecnicamente tem suporte para HMP, mas é destinado principalmente a dispositivos móveis que usam o ARM big.LITTLE.)

Além disso, a maioria dos processadores de desktop e laptop atualmente não se limita térmica ou eletricamente ao ponto em que alguns núcleos precisam ser executados mais rapidamente que outros, mesmo em períodos curtos. Basicamente, descobrimos o quão rápido podemos fabricar núcleos individuais ; portanto, substituir alguns núcleos por núcleos mais lentos não permitirá que os núcleos restantes funcionem mais rapidamente.

Embora existam alguns processadores de desktop com um ou dois núcleos capazes de funcionar mais rapidamente que os outros, atualmente esse recurso está limitado a certos processadores Intel de ponta (como o Turbo Boost Max Technology 3.0) e envolve apenas um pequeno ganho de desempenho para aqueles núcleos que podem rodar mais rápido.

Embora seja certamente possível projetar um processador x86 tradicional com núcleos grandes e rápidos e núcleos menores e mais lentos para otimizar cargas de trabalho altamente encadeadas, isso adicionaria uma complexidade considerável ao design do processador e é improvável que os aplicativos o suportem adequadamente.

Pegue um processador hipotético com dois núcleos velozes do Kaby Lake (7ª geração) e oito núcleos lentos do Goldmont (Atom). Você teria um total de 10 núcleos, e as cargas de trabalho altamente encadeadas otimizadas para esse tipo de processador podem ter um ganho de desempenho e eficiência em relação a um processador Kaby Lake normal de quatro núcleos . No entanto, os diferentes tipos de núcleos têm níveis de desempenho totalmente diferentes, e os núcleos lentos nem mesmo suportam algumas das instruções que os núcleos rápidos suportam, como o AVX . (O ARM evita esse problema ao exigir que os núcleos big e LITTLE suportem as mesmas instruções.)

Novamente, a maioria dos aplicativos multithread baseados no Windows pressupõe que todos os núcleos tenham o mesmo ou quase o mesmo nível de desempenho e podem executar as mesmas instruções; portanto, esse tipo de assimetria provavelmente resultará em desempenho abaixo do ideal, talvez até trava se Ele usa instruções não suportadas pelos núcleos lentos. Embora a Intel possa modificar os núcleos lentos para adicionar suporte avançado às instruções para que todos os núcleos possam executar todas as instruções, isso não resolveria problemas com o suporte de software para processadores heterogêneos.

Uma abordagem diferente ao design de aplicativos, mais próxima do que você provavelmente está pensando em sua pergunta, usaria a GPU para acelerar partes altamente paralelas de aplicativos. Isso pode ser feito usando APIs como OpenCL e CUDA . Quanto a uma solução de chip único, a AMD promove o suporte de hardware para aceleração de GPU em suas APUs, que combinam uma CPU tradicional e uma GPU integrada de alto desempenho no mesmo chip, como a Heterogeneous System Architecture , embora isso não tenha visto muita aceitação da indústria no exterior. de algumas aplicações especializadas.

O que você está perguntando é por que os sistemas atuais usam o multiprocessamento simétrico em vez do multiprocessamento assimétrico .

O multiprocessamento assimétrico era usado nos velhos tempos, quando um computador era enorme e alojado em várias unidades.

As CPUs modernas são projetadas como uma unidade, em uma matriz, onde é muito mais simples não misturar CPUs de tipos diferentes, pois todas compartilham o mesmo barramento e RAM.

Há também a restrição do relógio que controla os ciclos da CPU e o acesso à RAM. Isso se tornará impossível ao misturar CPUs de velocidades diferentes. Computadores experimentais sem relógio existiam e eram até bem rápidos, mas as complexidades do hardware moderno impunham uma arquitetura mais simples.

Por exemplo, os núcleos Sandy Bridge e Ivy Bridge não podem ser executados em velocidades diferentes ao mesmo tempo, já que o barramento de cache L3 é executado na mesma velocidade de clock que os núcleos, para evitar problemas de sincronização, todos eles precisam executar nessa velocidade ou estacionar / desligar (link: Sandy Bridge Architecture Exposed da Intel ). (Também verificado nos comentários abaixo para Skylake.)

[EDIT] Algumas pessoas confundiram minha resposta com dizer que é impossível misturar CPUs. Para seu benefício, afirmo: A mistura de diferentes CPUs não está além da tecnologia de hoje, mas não está concluída - "por que não" é a questão. Como respondido acima, isso seria tecnicamente complicado, portanto mais caro e com pouco ou nenhum ganho financeiro, por isso não interessa aos fabricantes.

Aqui estão as respostas para alguns comentários abaixo:

Turbo boost altera as velocidades da CPU para que possam ser alteradas

O Turbo Boost é feito acelerando o relógio e alterando alguns multiplicadores, que é exatamente o que as pessoas fazem quando fazem o overclock, exceto que o hardware faz isso por nós. O relógio é compartilhado entre núcleos na mesma CPU, portanto, isso acelera uniformemente toda a CPU e todos os seus núcleos.

Alguns telefones têm mais de uma CPU de velocidades diferentes

Esses telefones geralmente têm um firmware e uma pilha de software personalizados associados a cada CPU, mais como duas CPUs separadas (ou como CPU e GPU), e eles não têm uma visão única da memória do sistema. Essa complexidade é difícil de programar e, portanto, o multiprocessamento assimétrico foi deixado no domínio móvel, pois requer desenvolvimento de software próximo ao hardware, de baixo nível, que é evitado pelo sistema operacional de desktop de uso geral. Esta é a razão pela qual essas configurações não são encontradas no PC (exceto CPU / GPU, se esticarmos a definição o suficiente).

Atualmente, meu servidor com 2x Xeon E5-2670 v3 (12 núcleos com HT) possui núcleos em 1,3 GHz, 1,5 GHz, 1,6 GHz, 2,2 GHz, 2,5 GHz, 2,7 GHz, 2,8 GHz, 2,9 GHz e muitas outras velocidades.

Um núcleo está ativo ou ocioso. Todos os núcleos ativos ao mesmo tempo são executados na mesma frequência. O que você está vendo é apenas um artefato de tempo ou média. Eu também observei que o Windows não estaciona um núcleo por um longo período de tempo, mas estaciona / desmarca separadamente todos os núcleos muito mais rapidamente que a taxa de atualização do Monitor de Recursos, mas não sei o motivo desse comportamento que provavelmente está por trás a observação acima.

Os processadores Intel Haswell possuem reguladores de tensão integrados que permitem tensões e frequências individuais para cada núcleo

Reguladores de tensão individuais diferem da velocidade do relógio. Nem todos os núcleos são idênticos - alguns são mais rápidos. Os núcleos mais rápidos recebem um pouco menos de energia, criando espaço para aumentar a potência fornecida aos núcleos mais fracos. Os reguladores de tensão do núcleo serão configurados o mais baixo possível para manter a velocidade atual do relógio. A unidade de controle de energia da CPU regula as tensões e substitui as solicitações do SO, quando necessário, para núcleos que diferem em qualidade. Resumo: Os reguladores individuais são para fazer com que todos os núcleos operem economicamente na mesma velocidade de clock, não para definir velocidades de núcleos individuais

Por que não temos variantes com diferentes velocidades de clock? ie 2 núcleos 'grandes' e muitos núcleos pequenos.

É possível que o telefone no seu bolso ostente exatamente esse arranjo - o ARM big.LITTLE funciona exatamente como você descreveu. Não há nem mesmo uma diferença de velocidade de clock, eles podem ser tipos de núcleo totalmente diferentes - normalmente, os de clock mais lento são ainda mais "burros" (sem execução fora de ordem e outras otimizações de CPU).

É uma boa idéia, essencialmente, economizar bateria, mas tem suas próprias falhas; a contabilidade para mover coisas entre diferentes CPUs é mais complicada, a comunicação com o resto dos periféricos é mais complicada e, o mais importante, para usar esses núcleos com eficiência, o agendador de tarefas deve ser extremamente inteligente (e muitas vezes "acertar") .

O arranjo ideal é executar tarefas em segundo plano sem tempo crítico ou tarefas interativas relativamente pequenas nos núcleos "pequenos" e ativar os "grandes" apenas para cálculos grandes e longos (onde o tempo extra gasto nos núcleos pequenos termina comer mais bateria) ou para tarefas interativas de tamanho médio, nas quais o usuário sente lentidão nos pequenos núcleos.

No entanto, o agendador possui informações limitadas sobre o tipo de trabalho que cada tarefa pode estar executando e precisa recorrer a algumas heurísticas (ou informações externas, como forçar alguma máscara de afinidade em uma determinada tarefa) para decidir onde agendá-las. Se isso der errado, você pode acabar perdendo muito tempo / energia para executar uma tarefa em um núcleo lento e proporcionar uma experiência ruim ao usuário ou usar os "grandes" núcleos para tarefas de baixa prioridade e, assim, desperdiçar energia / roubando-os das tarefas que precisariam deles.

Além disso, em um sistema de multiprocessamento assimétrico, geralmente é mais caro migrar tarefas para um núcleo diferente do que seria em um sistema SMP; portanto, o planejador geralmente precisa fazer um bom palpite inicial em vez de tentar rodar em um núcleo livre aleatório e mover mais tarde.

A escolha da Intel aqui é ter um número menor de núcleos inteligentes e rápidos idênticos, mas com escala de frequência muito agressiva. Quando a CPU fica ocupada, ela aumenta rapidamente a velocidade máxima do relógio, faz o trabalho o mais rápido possível e reduz a escala para voltar ao modo de uso de energia mais baixo. Isso não sobrecarrega o agendador e evita os cenários ruins descritos acima. É claro que, mesmo no modo de relógio baixo, esses núcleos são "inteligentes", portanto provavelmente consumirão mais do que os núcleos "estúpidos" grandes.LITTLE do relógio baixo.

O desempenho nos jogos tende a ser determinado pela velocidade de núcleo único,

No passado (jogos da era DOS): Correto.
Hoje em dia, não é mais verdade. Muitos jogos modernos são encadeados e se beneficiam de vários núcleos. Alguns jogos já estão bastante satisfeitos com 4 núcleos e esse número parece aumentar com o tempo.

enquanto aplicativos como edição de vídeo são determinados pelo número de núcleos.

Tipo de verdade.

Número de núcleos * vezes a velocidade do núcleo * de eficiência.
Se você comparar um único núcleo idêntico a um conjunto de núcleos idênticos, estará mais correto.

Em termos do que está disponível no mercado - todas as CPUs parecem ter aproximadamente a mesma velocidade, com as principais diferenças sendo mais threads ou mais núcleos. Por exemplo:

Intel Core i5 7600k, Freq base 3,80 GHz, 4 núcleos Intel Core i7 7700k, Freq base 4,20 GHz, 4 núcleos, 8 threads AMD Ryzen 1600x, Freq base 3,60 GHz, 6 núcleos, 12 threads AMD Ryzen 1800x, Freq base 3,60 GHz, 8 núcleos, 16 fios

Comparar arquiteturas diferentes é perigoso, mas ok ...

Então, por que vemos esse padrão de aumento de núcleos com todos os núcleos com a mesma velocidade de clock?

Parcialmente porque encontramos uma barreira. Aumentar a velocidade do relógio significa ainda mais energia necessária e mais calor gerado. Mais calor significava ainda mais energia necessária. Tentamos assim, o resultado foi o horrível pentium 4. Quente e sedento de energia. Difícil de esfriar. E nem mesmo mais rápido que o Pentium-M, projetado de forma inteligente (um P4 a 3,0 GHz foi aproximadamente tão rápido quanto um P-mob a 1,7 GHz).

Desde então, desistimos de aumentar a velocidade do relógio e, em vez disso, criamos soluções mais inteligentes. Parte disso era usar vários núcleos sobre a velocidade bruta do relógio.

Por exemplo, um único núcleo de 4GHz pode consumir tanta energia e gerar tanto calor quanto três núcleos de 2GHz. Se o seu software puder usar vários núcleos, será muito mais rápido.

Nem todo software pode fazer isso, mas o software moderno normalmente pode.

O que responde parcialmente por que temos chips com vários núcleos e por que vendemos chips com diferentes números de núcleos.

Quanto à velocidade do relógio, acho que consigo identificar três pontos:

• CPUs de baixa potência fazem sentido em alguns casos em que a velocidade bruta não é necessária. Por exemplo, controladores de domínio, configurações de NAS, ... Para estes, temos CPUs de frequência mais baixa. Às vezes, mesmo com mais núcleos (por exemplo, CPU 8x de baixa velocidade faz sentido para um servidor da web).
• Quanto ao resto, geralmente estamos perto da frequência máxima que podemos fazer sem que nosso projeto atual fique muito quente. (digamos 3 a 4GHz com os designs atuais).
• E ainda por cima, fazemos binning. Nem todas as CPUs são geradas igualmente. Algumas CPUs têm uma pontuação ruim ou ruim em parte de seus chips, têm essas partes desativadas e são vendidas como um produto diferente.

O exemplo clássico disso foi um chip AMD de 4 núcleos. Se um núcleo foi quebrado, foi desativado e vendido como um chip de 3 núcleos. Quando a demanda por esses três núcleos era alta, até mesmo os quatro núcleos eram vendidos como a versão de três núcleos e, com o software correto, era possível reativar o quarto núcleo.

E isso não é feito apenas com o número de núcleos, mas também afeta a velocidade. Alguns chips ficam mais quentes que outros. Muito quente e vendê-lo como uma CPU de velocidade mais baixa (onde frequência mais baixa também significa menos calor gerado).

E depois há produção e marketing e isso atrapalha ainda mais.

Por que não temos variantes com diferentes velocidades de clock? ie 2 núcleos 'grandes' e muitos núcleos pequenos.

Nós fazemos. Em lugares onde faz sentido (por exemplo, telefones celulares), geralmente temos um SoC com uma CPU de núcleo lento (baixo consumo de energia) e alguns núcleos mais rápidos. No entanto, no PC de mesa típico, isso não é feito. Isso tornaria a instalação muito mais complexa, mais cara e não há bateria para descarregar.

Por que não temos variantes com diferentes velocidades de clock? Por exemplo, dois núcleos 'grandes' e muitos núcleos pequenos.

A menos que estivéssemos extremamente preocupados com o consumo de energia, não faria sentido aceitar todo o custo associado a um núcleo adicional e não obter o máximo desempenho possível desse núcleo. A velocidade máxima do clock é determinada em grande parte pelo processo de fabricação, e todo o chip é produzido pelo mesmo processo. Então, qual seria a vantagem em tornar alguns dos núcleos mais lentos do que o processo de fabricação suportado?

Já temos núcleos que podem diminuir a velocidade para economizar energia. Qual seria o objetivo de limitar o desempenho máximo?

Por que não temos variantes com diferentes velocidades de clock? Por exemplo, dois núcleos 'grandes' e muitos núcleos pequenos.

Atualmente, as velocidades nominais de clock não significam muito para a maioria dos processadores maiores, já que todos eles têm a capacidade de sincronizar-se para cima e para baixo. Você está perguntando se eles podem ou não criar diferentes núcleos para cima e para baixo de forma independente.

Estou meio surpreso com muitas das outras respostas. Os processadores modernos podem e fazem isso. Você pode testar isso, por exemplo, abrindo a CPU-Z em um smartphone - meu Google Pixel é perfeitamente capaz de executar diferentes núcleos em diferentes velocidades:

É nominalmente 2.15 Ghz, mas dois núcleos estão em 1.593 Ghz e dois estão em 1.132 Ghz.

De fato, desde 2009, os principais processadores Intel têm lógica para aumentar os núcleos individuais, enquanto fazem o underclocking de outros núcleos, permitindo um melhor desempenho de um único núcleo, mantendo-se dentro do orçamento do TDP: http://www.anandtech.com/show/2832/4

Os processadores Intel mais recentes com "Núcleo Favorecido" (um termo de marketing da Intel) têm cada núcleo caracterizado na fábrica, com os núcleos mais rápidos sendo capazes de aumentar a capacidade extra: http://www.anandtech.com/show/11550/the-intel -skylakex-review-core-i9-7900x-i7-7820x-e-i7-7800x-testado / 7

Os chips Bulldozer da AMD tinham uma versão primitiva disso: http://www.anandtech.com/show/4955/the-bulldozer-review-amd-fx8150-tested/4

Os novos chips Ryzen da AMD provavelmente também têm isso, embora não esteja explicitamente declarado aqui: http://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive -on-1800x-1700x-e-1700/11

Em um sistema moderno muitas vezes você faz tem todos os núcleos rodando a velocidades diferentes. Cronometrar um núcleo que não é muito usado reduz o uso de energia e a saída térmica, o que é bom, e recursos como "turbo boost" permitem que um ou dois núcleos funcionem significativamente mais rápido desde que os outros núcleos estejam ociosos e, portanto, o uso de energia e a produção de calor de todo o pacote não aumenta muito. No caso de um chip com esse recurso, a velocidade que você vê na lista é a velocidade mais alta que você pode obter com todos os núcleos de uma só vez. E por que todos os núcleos teriam a mesma velocidade máxima? Bem, eles são todos de design idêntico, no mesmo chip físico, estabelecido com o mesmo processo semicondutor, então por que deveriam ser diferentes?

A razão pela qual todos os núcleos são idênticos é porque isso facilita a execução de um thread em um núcleo em um ponto e a execução em um núcleo diferente em outro momento. Como mencionado em outro lugar, existem chips comumente usados ​​que não seguem esse princípio de núcleos idênticos, a saber, os processadores ARM "big.LITTLE". Embora, na minha opinião, a diferença mais importante entre os núcleos "grande" e "pequeno" não seja a velocidade do relógio (os núcleos "grandes" tendem a ser mais sofisticados, mais largos e mais especulativos que obtêm mais instruções por relógio ao custo de uso de energia, enquanto os "pequenos" núcleos se aproximam das raízes de um único problema, em ordem e de baixo consumo de energia da ARM), pois

E se aprofundando no domínio da computação heterogênea, também está se tornando comum ver os núcleos "CPU" e "GPU" integrados no mesmo chip. Eles têm projetos completamente diferentes, executam conjuntos de instruções diferentes, são tratados de maneira diferente e geralmente também são marcados de maneira diferente.

O desempenho rápido de thread único e a alta taxa de transferência de threads múltiplos são exatamente o que você obtém com uma CPU como o Xeon E5-2699v4 da Intel .

É um Broadwell de 22 núcleos. A velocidade de clock sustentada é de 2,2 GHz com todos os núcleos ativos (por exemplo, codificação de vídeo), mas o turbo máximo de núcleo único é de 3,6 GHz .

Portanto, ao executar uma tarefa paralela, ele usa seu orçamento de energia de 145W como 22 núcleos de 6,6W. Porém, ao executar uma tarefa com apenas alguns threads, esse mesmo orçamento de energia permite que alguns núcleos turbinem até 3,6 GHz. ( Porém, a menor memória de núcleo único e a largura de banda do cache L3 em um Xeon grande significa que ele pode não funcionar tão rápido quanto um quad-core de desktop a 3,6 GHz. Um único núcleo em uma CPU Intel de desktop pode usar muito mais largura de banda total da memória.)

A velocidade do relógio nominal de 2,2 GHz é tão baixa por causa dos limites térmicos. Quanto mais núcleos uma CPU tiver, mais lento eles terão que executar quando estiverem todos ativos. Esse efeito não é muito grande nas CPUs de 4 e 8 núcleos mencionados na pergunta, porque 8 não são muitos núcleos e possuem orçamentos de energia muito altos. Até as CPUs de desktops entusiastas mostram esse efeito: o Skylake-X i9-7900X da Intel é uma peça de 10c20t com base de 3,3 GHz, turbo máximo de 4,5 GHz . Isso é muito mais espaço para turbo de núcleo único do que o i7-6700k (4.0GHz sustentado / 4.2GHz turbo sem overclock).

O escalonamento de frequência / tensão (DVFS) permite que o mesmo núcleo opere em uma ampla faixa da curva de desempenho / eficiência. Veja também esta apresentação da IDF2015 sobre o gerenciamento de energia da Skylake , com muitos detalhes interessantes sobre o que as CPUs podem fazer de maneira eficiente e negociando desempenho versus eficiência, tanto estaticamente no momento do design quanto em tempo real com o DVFS.

No outro extremo do espectro, as CPUs Intel Core-M têm frequência sustentada muito baixa, como 1,2 GHz a 4,5 W , mas podem turbo até 2,9 GHz. Com vários núcleos ativos, eles executam seus núcleos a uma velocidade de clock mais eficiente, assim como os gigantes Xeons.

Você não precisa de uma arquitetura de estilo big.LITTLE heterogênea para obter a maior parte dos benefícios. Os pequenos núcleos no ARM big.LITTLE são núcleos de ordem bastante ruins que não são bons para o trabalho de computação. O objetivo é apenas executar uma interface do usuário com energia muito baixa. Muitos deles não seriam ótimos para codificação de vídeo ou outro processamento sério de números. ( @ Lưu Vĩnh Phúc encontrou algumas discussões sobre o porquê do x86 não ter grande.LITTLE . Basicamente, gastar silício extra em um núcleo extremamente lento e de baixa potência não valeria a pena para o uso típico de desktop / laptop.)

enquanto aplicativos como edição de vídeo são determinados pelo número de núcleos. [2x 4.0 GHz + 4x 2.0 GHz não seriam melhores em cargas de trabalho multithread do que 4x 4GHz?]

Este é o seu principal mal-entendido. Você parece estar pensando que o mesmo número total de tiques do relógio por segundo é mais útil se espalhado por mais núcleos. Esse nunca é o caso. É mais como

cores * perf_per_core * (scaling efficiency)^cores

( perf_per_corenão é a mesma coisa que a velocidade do relógio, porque um Pentium4 de 3GHz recebe muito menos trabalho por ciclo de clock que um Skylake de 3GHz.)

Mais importante, é muito raro que a eficiência seja 1.0. Algumas tarefas paralelas embaraçosas são dimensionadas quase linearmente (por exemplo, compilando vários arquivos de origem). Mas a codificação de vídeo não é assim. Para x264, a escala é muito boa até alguns núcleos, mas piora com mais núcleos. por exemplo, passar de 1 a 2 núcleos quase dobrará a velocidade, mas passar de 32 a 64 núcleos ajudará muito menos a uma codificação típica de 1080p. O ponto em que os platôs de velocidade depende das configurações. ( -preset veryslowfaz mais análises em cada quadro e pode manter mais núcleos ocupados que -preset fast).

Com muitos núcleos muito lentos, as partes de rosca única do x264 se tornariam gargalos. (por exemplo, a codificação final do fluxo de bits do CABAC. É o equivalente a hz64 do gzip e não se paralela.) Ter alguns núcleos rápidos resolveria isso, se o SO soubesse agendá-lo (ou se x264 fixasse os threads apropriados núcleos rápidos).

O x265 pode tirar proveito de mais núcleos do que o x264, uma vez que possui mais análises a serem feitas, e o design WPP do h.265 permite mais paralelismo de codificação e decodificação. Mas mesmo para 1080p, você fica sem paralelismo para explorar em algum momento.

Se você tiver vários vídeos para codificar, a execução de vários vídeos em paralelo será bem dimensionada, exceto pela competição por recursos compartilhados, como capacidade e largura de banda L3 de cache e largura de banda de memória. Menos núcleos mais rápidos poderiam se beneficiar mais da mesma quantidade de cache L3, pois não precisariam trabalhar em tantas partes diferentes do problema ao mesmo tempo.

Embora seja possível projetar computadores com partes diferentes rodando em velocidades independentes diferentes, a arbitragem de recursos geralmente exige que você decida rapidamente qual solicitação primeiro deve ser atendida, o que, por sua vez, exige saber se alguma outra solicitação pode ter chegado em breve para obter prioridade. . Decidir essas coisas, na maioria das vezes , é bastante simples. Algo como um circuito "quiz buzzer" pode ser implementado com apenas dois transistores. O problema é que tomar decisões rápidas e confiáveisinequívoco é difícil. A única maneira prática de fazer isso em muitos casos é usar uma decisão chamada "sincronizador", que pode evitar ambiguidades, mas introduz um atraso de dois ciclos. Pode-se projetar um controlador de armazenamento em cache que arbitraria de maneira confiável entre dois sistemas com relógios separados, se alguém estivesse disposto a tolerar um atraso de dois ciclos em cada operação para determinar quem ganhou a arbitragem. Essa abordagem seria menos que útil, no entanto, se alguém gostaria que um cache respondesse imediatamente a solicitações na ausência de contenção, pois mesmo solicitações não contestadas ainda teriam um atraso de dois ciclos.

Executar tudo em um relógio comum evita a necessidade de sincronização, o que evita um atraso de comunicação de dois ciclos toda vez que é necessário passar informações ou controlar sinais entre os domínios do relógio.

Os computadores de mesa já fazem isso.

Eles possuem (conjunto de) uma (s) CPU (s), com 1-72 threads ativos de uma só vez, e um (conjunto de) GPU (s), com 16 a 7168 unidades de computação.

Os gráficos são um exemplo de uma tarefa que descobrimos que um trabalho paralelo maciço é eficiente. A GPU é otimizada para executar o tipo de operação que queremos executar gráficos (mas não se limita a isso).

Este é um computador com poucos núcleos grandes e muitos núcleos pequenos.

Em geral, negociar um núcleo no X FLOPS por três núcleos no X / 2 FLOPS não vale a pena; mas negociar um núcleo no X FLOPS por cem núcleos no X / 5 FLOPS vale muito a pena.

Ao programar para isso, você gera código muito diferente para a CPU e a GPU. Muito trabalho é feito para dividir a carga de trabalho, para que a GPU obtenha as tarefas que são melhor executadas na GPU, e a CPU obtenha tarefas que são melhor executadas na CPU.

É sem dúvida muito mais fácil escrever código para uma CPU, porque é difícil obter o código paralelo em massa. Portanto, somente quando o retorno é grande , vale a pena negociar o desempenho de núcleo único para situações com vários núcleos. As GPUs oferecem um grande retorno quando usadas corretamente.

Agora, os dispositivos móveis fazem isso por um motivo diferente. Eles possuem núcleos de baixo consumo de energia que são significativamente mais lentos, mas também usam significativamente menos energia por unidade de computação. Isso permite que eles aumentem a vida útil da bateria por muito mais tempo quando não executam tarefas intensivas da CPU. Aqui temos um tipo diferente de "grande retorno"; não desempenho, mas eficiência de energia. Ainda é preciso muito trabalho por parte do sistema operacional e, possivelmente, gravador de aplicativos para que isso funcione corretamente; apenas a grande recompensa fez valer a pena.

A razão pela qual os sistemas comuns têm núcleos na mesma velocidade é um simples problema de matemática. Tempo de entrada e saída (com otimizações) com base em um único conjunto de constantes (escaláveis ​​= multiplicáveis ​​por um número de unidades).

E alguém aqui disse que os dispositivos móveis têm várias CPUs com velocidades diferentes. Isso não é verdade. Não é uma unidade central de processamento se não for a unidade central de processamento; não importa o que o fabricante diga que é ou não é. nesse caso [não uma CPU] é apenas um "pacote de suporte".

Eu não acho que o OP entenda eletrônicos básicos. Todos os computadores exigem uma coisa para eles funcionarem - um relógio. Os ciclos de relógio gerados por um relógio interno são o metrônomo para o movimento de todos os dados. Para alcançar a sincronicidade, todas as operações devem estar vinculadas a um relógio comum. Isso é verdade tanto para a execução interna de dados em um computador isolado quanto para redes inteiras.

Se você quiser isolar núcleos em uma CPU executando-os em diferentes frequências, certamente poderá projetar essa plataforma. No entanto, seria necessário criar uma solução de placa-mãe que vincule cada núcleo individual ao seu subconjunto isolado de recursos da placa-mãe. Você ficaria com 4 computadores individuais em vez de um computador quad-core.

Como alternativa, como outra pessoa apontou, você pode adicionar código ao seu kernel que ajusta a frequência principal individualmente. Isso causará impactos no desempenho, no entanto. Você pode ter velocidade ou eficiência de energia - mas não pode ter ambos.