Para operações matemáticas simples como sqrt(2), 1 / 2, 1 + 1, 10^2, 1 * 0, tan(45)e assim por diante, as CPUs já contêm algum tipo de tabela de hardware com o resultado dessas operações para que elas não sejam realmente "calculadas", mas sim buscadas de um dicionário ou "cache matemático" de algum tipo para processamento mais rápido? Claro que prevejo que algumas pessoas aqui perguntarão "quem define o que é uma operação matemática 'simples'?", mas estou apenas curioso.
Não, cabe ao software implementar o cache se valores repetidos forem comuns.
Nunca ouvi falar de nenhuma CPU armazenando em cache resultados para instruções de computação, mesmo as lentas, como divisão FP ou raiz quadrada, ou divisão inteira. (Embora mesmo essas não sejam tão lentas nas CPUs mais novas, como latência de 9 ciclos e taxa de transferência de 6 ciclos
idiv r32no Zen 4). Mesmo CPUs "grandes" com grandes orçamentos de transistores, como núcleos de desempenho x86 e a família Apple M1, não fazem isso.Levaria uma certa área de dados para ter caches, e custaria energia extra para verificar e atualizá-los sem nenhum benefício em casos em que eles falham em quase todas as operações. O que seria comum, já que muitos casos de uso processam dados não redundantes.
Faz mais sentido gastar o orçamento de transistor e energia para fornecer melhor rendimento para todas as operações, que é o que as CPUs de alto desempenho reais fazem: múltiplos pipelines de execução para operações comuns como (SIMD) FP mul ou FMA, que podem iniciar uma nova operação a cada ciclo de clock.
O cache seria realmente contraproducente para quaisquer operações mais simples, como FP ou adição/sub ou multiplicação de inteiros. Elas têm latências curtas que não são dependentes de dados, então o planejador para execução fora de ordem sabe em qual ciclo de clock eles produzirão seu resultado. E pode, portanto, evitar conflitos de write-back. Por exemplo, se você iniciou uma multiplicação de inteiros de latência de 3 ciclos há 2 ciclos, enviar uma adição de inteiro de 1 ciclo para essa porta de execução resultaria em ambos os resultados prontos no próximo ciclo, mas normalmente há apenas um conjunto de fios para obter resultados de ALUs nessa porta de execução para os lugares que eles precisam ir (registrar arquivo e ignorar a rede de encaminhamento). Veja a seção sobre padronização da latência de uop na seção Sandybridge do guia de microarquitetura de Agner Fog , que economizou energia no planejador. (Uarches Intel posteriores adicionaram uops com latências mais diferentes novamente.)
Multiplicadores consomem muita energia (já que muitas portas são alternadas), mas você não vai economizar energia a menos que sacrifique a latência para o caso de cache-miss. Para manter a latência baixa, o hardware iniciaria uma multiplicação em paralelo com a verificação de seu cache de operandos recentes. (O que teria uma tag de 128 bits e dados de 64 bits para multiplicação de 64x64 -> 64 bits. Então os comparadores paralelos teriam que ser muito mais amplos do que em unidades de carga/armazenamento.) No hit, você poderia produzir a saída após 1 ou 2 ciclos em vez dos habituais 3 a 5.
A adição de inteiros normalmente já tem latência de 1 ciclo e muitos rendimentos por clock. (por exemplo, 4 por clock em Intel e AMD recentes). Também pode ser vetorizado SIMD para cálculos de alto rendimento, fazendo 8
uint32_tadições por instrução (x86 com AVX2), até 3 delas por clock. Então, se você fosse ter um cache para essas operações, precisaria de um cache com 24 portas de leitura!! (Ou caches pequenos separados em cada unidade de execução). SIMD inteiro e multiplicação FP também são rendimentos bem altos, como 2 instruções por clock com latência de 4 ou 5 ciclos.A adição de inteiros é mais barata do que verificar um cache, mesmo no caso de acerto de cache, especialmente com SIMD para fazer várias adições em paralelo para apenas uma instrução (ou micro-op) passando pelo pipeline.
Uma que a CPU pode fazer em uma única instrução asm, é claro. Descartar uma sequência inteira de instruções parece ainda menos provável, mesmo se forem consecutivas, e mais custoso em energia para tentar reconhecer padrões de computações repetitivas. E resultados intermediários podem ser deixados em registradores que também são lidos antes de serem sobrescritos, caso em que essas saídas também são efeitos colaterais visíveis que precisam ser armazenados em cache.
Casos em que isso poderia plausivelmente ser mais útil são as instruções lentas do x87 como
fsincosandfyl2x(que podem ser usadas em uma funçãopoworlog). Mas o x87 está praticamente obsoleto, não é usado pela maioria dos softwares. egfsincosé microcodificado como 60-120 uops no Ice Lake.A maioria das CPUs não tem instruções de exponenciação, embora
x^2seja apenas uma multiplicação única que as CPUs suportam nativamente.