Via YT Combinator. De Auto- arch- tournament.

O que acontece quando você tira um loop de pesquisa autônomo de sua zona de conforto e o aponta para um domínio em que não tem nenhum negócio sendo bom? Andrej Karpathy pesquisa automática mostrou que um agente codificador, dado dois dias e um nanochat de uma única GPU, encontra 20 otimizações de tempo de treinamento por conta própria. A receita é geral — propor, implementar, medir, manter as vitórias — mas a demonstração estava dentro do território do agente: Python, descida gradiente, botões bem conhecidos.

Queria saber se era generalizada. Então eu apontei para uma CPU.

A configuração

auto-arch-tournament é um núcleo RV32IM de 5 estágios em ordem no SystemVerilog — o pipeline do livro didático que você escreveria em uma aula de arquitetura de pós-graduação. Sem caches, sem preditor de ramificações, sem múltiplos problemas no primeiro dia. São hipóteses de pesquisa, não características.

O orquestrador está codificado. O LLM nunca o edita. Cada rodada, três slots correm em paralelo:

1. O agente propõe uma hipótese microarquitetural como YAML, esquema-checked contra schemas/hypothesis.schema.json.
2. Um agente de implementação edita arquivos sob rtl/ numa árvore de trabalho git isolada.
3. O portão de avaliação funciona:
   • riscv- formal — 53 controlos simbólicos BMC (decodificação, armadilhas, encomenda, vida, M-ext)
   • Cosim verificador — RVFI bytes idênticos contra um Python ISS, ~22% barragens aleatórias
   • 3 sementes nextpnr P&R em Gowin GW2A-LV18 (Tang Nano 20K) — mediana Fmax × CoreMark iter/ciclo = aptidão
   • Validação do CoreMark CRC — os mesmos 4 relatórios CRC VexRiscv contra
4. Melhoria → fundiu-se no tronco, torna-se a nova linha de base. Regressão / quebrado / colocação-falhou → worktree destruído.

Uma rotação de diversidade força cada slot a escolher uma categoria diferente (micro_opt | structural | predictor | memory | extension) para que o agente não se fixe numa ideia.

Mostre-me os resultados

Linha de base bloqueada na mesma metodologia que o VexRiscv publica — total sem cache, dados 2K, -O3, ~22% contrapressão do autocarro — a 2.23 CoreMark/MHz, 301 iter/s. O benchmark humano é publicado pela VexRiscv 2.57 CoreMark/MHz @ 144 MHz.

Então deixei correr. 73 hipóteses, 9h 51m wall-clock.

ResultadoContagemMelhoria (aceitada)10Regressão50Quebrado (formal/cosim)9A colocação falhou4

Os 10 vencedores, em ordem:

Δtiter/sCM/MHzFmaxLUT4Hipótese0.0h301.042.226135 MHz9,880Base0.4h313.102.320135 MHz10,186Predictor Recuado0,7h324.482.348138 MHz10,192IF Direct-Jump Predictor2.1h375,432.348160 MHz5.888Unidade DIV/REM multicícleo a frio2.7h397.552.366168 MHz5.854Fenda de aposentadoria de uma loja profunda3.5h422,772.366179 MHz5.933Contador de ordem RVFI segmentado3.8h472.962.891164 MHz5,916Lookahead registrado I-Fitch Replay Predictor4,0h505,652.891175 MHz5.938Etiquetas de repetição de I-Fitch comprimidas sem reset5.3h529,352.891183 MHz5.930RTL-apenas quente / frio ALU Opcode Split6.1h577.762.908199 MHz5,944Bancos registrados I-Fitch Replay Predictor

Estado final: 2.91 CoreMark/MHz, 577 iter/s, 199 MHz Fmax, 5.944 LUT4.

Isto é... +92% sobre a linha de base bloqueada e +56% sobre o VexRiscv no CoreMark iter/sec (370 → 578), com 40% menos LUTs. Os compostos vencedores: ~13% dele é eficiência arquitetônica (2,91 vs 2.57 CoreMark/MHz) eo resto é Fmax (199 vs 144 MHz) - um projeto menor, mais simples que o sintetizador também relógios mais rápido. Para o contexto, o intervalo CoreMark/MHz entre VexRiscv's full no cache e linux balanced configs (seu próximo nível acima, com caches) é de cerca de 40 pontos percentuais — então o loop fechou 13 daqueles em menos de dez horas, em um único alvo FPGA, contra um VexRiscv de base levou anos para alcançar.

A função de passo preta é a melhor corrida. Ele cruza a linha VexRiscv sintonizada humana na iteração 6 e nunca olha para trás. O movimento interessante foi a iteração 3 — puxando DIV/REM para fora do caminho de um único ciclo. O agente não sabia que também iria metade da contagem LUT. Descobriu fazendo-o e observando o sintetizador.

A parte interessante não é o laço

Há muito barulho neste momento sobre loops de agentes. Construir um planejador, construir um codificador, dar-lhes ferramentas, executá-los em um enxame, levantar uma rodada de sementes. O loop é principalmente um problema resolvido. Escolha um modelo, escolha uma biblioteca de andaimes, escolha quantas slots paralelas você pode pagar. Seja qual for o fosso que acha que tem, tem-no há seis meses.

A coisa que ninguém é pago para construir, e a coisa que este projeto é realmente sobre, é o verificador.

De 73 hipóteses, 63 estavam errados.Regrediram, quebraram o ISA ou falharam na hora. Alguns exemplos reais do log:

• A mesma ideia, duas vezes. Move DIV/REM off the single-cycle ALU path primeiro veio na rodada 1, slot 0, e quebrou o cosim no autoteste antes de chegar ao FPGA. O agente reformulou- o como Cold Multi-Cycle DIV/REM Unit duas horas depois — a mesma ideia, a implementação fixa — e tornou-se a vitória decisiva. Sem o portão cosim a primeira tentativa quebrada teria sido enviada.
• Violações na caixa de areia. Duas hipóteses distintas tentaram adicionar um test/_helpers.py arquivo fora do rtl/** e test/test_*.py allowlist. O caminho sandbox rejeitou a rodada antes de qualquer avaliação correr. Se você deixar o agente editar o arnês, eventualmente ele irá editar o arnês.
• Uma regressão de −73%. No 24o round, após o pico de aptidão de 577 iter/s já estava bloqueado, o agente proposto Registered Lookahead JALR Target Predictor. A aptidão desabou para 154 iter/s — uma queda de 73%. Aceito no porta-malas, que um erro desfaz todas as vitórias anteriores em uma única rodada. O orquestrador captou-o na comparação contra a linha de base.
• Erros de esquema. Uma hipótese declarada fitness_delta_pct: 1.5 onde o esquema requer um inteiro. Rejeitado antes de qualquer código ser gerado. Trivial — e exatamente o tipo de coisa que, sem o esquema, torna-se uma coerção tipo silencioso mais tarde no oleoduto.

Cada uma dessas falhas custa ~5-15 minutos de computação. Cada um deles, ungado, teria corrompido a corrida ou ensinado ao agente que um movimento errado era certo.

O verificador neste projeto faz as coisas inglamorosas que você seria tentado a pular:

• A ill / unique / liveness / cover controlos formais, não apenas o insn_* umas. Os quatro primeiros prendem-se silenciosamente; insn_* Só apanham aritmética silenciosamente quebrada.
• Uma caixa de areia. O agente pode editar rtl/** e test/test_*.pyToque formal/checks.cfg, tools/eval/fpga.py, ou a tabela CRC canônica ea rodada é rejeitada antes de qualquer eval corre. Caso contrário, um agente irá eventualmente "melhorar" suavizando um cheque.
• P&R de 3 sementes, mediana Fmax. Uma semente é uma moeda flip; três é um número que você pode comparar através de iterações.
• Validação CRC na saída da bancada. Impressões CoreMark Correct operation validated. Mesmo quando não é, porque verifica os seus próprios CRCs e imprime o literal independentemente. O eval revalida os quatro CRCs contra os valores canônicos de 2K-config.
• Preencher a região cronometrada com marcadores MMIO start/stop. O aquecimento e a impressão do CoreMark vão comer o seu número de fitness se medir de ponta a ponta.

O agente Loop é um produtor. O verificador é a única coisa entre ti e um número confiantemente errado.

O que isto significa para o próximo lote de empresas

A próxima onda de empresas não vai ser pessoas escrevendo código. Vão ser pessoas a escrever verificadores, com um ciclo a correr contra eles.

O laço é mercadoria. Modelo + prompt + ferramentas + placar + slots paralelos. Todos estão convergindo na mesma forma, e os fornecedores dessas peças estão correndo uns aos outros para margem zero.

O verificador não é mercadoria. É o artefato que codifica o que seu negócio realmente significa por corretoEm uma CPU é uma ISA e uma suíte de propriedade formal. Num oleoduto de faturamento são invariantes num livro. Em um compilador é um teste diferencial contra a referência. Num fluxo de trabalho clínico, é uma propriedade que a FDA assinou. Nenhum destes são problemas de IA. Eles são "o que é o seu domínio, e você pode escrever as regras para baixo" problemas.

Se puderes escrever as regras, um agente irá satisfazê-las mais depressa do que a tua equipa. Se você não pode — e a maioria das equipes não pode, porque as regras vivem em três cabeças de engenheiros e uma página de Confluência que ninguém atualizou — o agente vai satisfazer um diferente conjunto de regras, as que inferiu do que podia observar. Você não vai notar até a produção.

As empresas que ganham isto não são as que têm o melhor planeador. Eles é que têm o contrato.

O que vem a seguir

O projeto é atualmente sequencial ao nível redondo — os perdedores são descartados cada rodada, mesmo que seus caminhos fracassados sejam sinal útil. A próxima iteração move-se para uma pesquisa de base populacional: manter o topo K a cada rodada, mutar de qualquer um deles, deixar os ramos sem saída permanecer mortos. Isso deve escalar o espaço de busca sem escalar o projeto de projeto linearmente.

Também estou curioso quanto da vitória nas primeiras 10 horas generaliza fora CoreMark. Alguns desses preditores claramente se ajustam ao perfil de seu ramo. A próxima troca de experiências em Embench contra a mesma linha de base, e vemos quais vencedores sobrevivem a uma mudança de carga de trabalho e quais foram as trivias CoreMark.

Ambas são perguntas interessantes. A questão mais interessante — para mim e para qualquer pessoa que envie um produto — é a que partes do seu negócio já têm um verificador suficientemente afiado para apontar um loop. Encontra isso e a produtividade da tua equipa pára de aumentar com a contagem de cabeças.

O futuro é brilhante. A fronteira é o verificador.