O RISC-V é lento demais

 (marcin.juszkiewicz.com.pl)
3 pontos por GN⁺ 2026-03-24 | 1 comentários | Compartilhar no WhatsApp
  • O trabalho de portar o Fedora Linux para RISC-V está em andamento há cerca de 3 meses, e a maioria dos pacotes já foi compilada para o Fedora 43
  • Atualmente, o hardware RISC-V apresenta velocidade de compilação extremamente lenta, levando até mais de 5 vezes o tempo do x86_64 para compilar o mesmo pacote
  • Para ser adotado como arquitetura oficial do Fedora, é necessário hardware de classe servidor capaz de compilar o binutils em menos de 1 hora
  • O atraso nas compilações provoca reclamações dos mantenedores de pacotes, e chegou a ser mencionada a possibilidade de excluir o RISC-V
  • No futuro, há planos de melhorar o problema de desempenho com as compilações do Fedora 44 e a introdução de builders mais rápidos, além de manter a unificação do kernel e o LTO desativado

Progresso do porte do Fedora para RISC-V

  • O trabalho de portar o Fedora Linux para RISC-V começou há cerca de 3 meses, e várias mudanças ocorreram nesse período
  • A maior parte dos itens no rastreador do Fedora RISC-V já foi resolvida, e atualmente restam apenas 17 itens no estado NEW
  • Os fontes dos pacotes do Fedora são obtidos e a compilação é feita com o comando fedpkg mockbuild -r fedora-43-riscv64
  • Até agora, foram enviados 86 Pull Requests para pacotes, a maioria já foi mesclada, e a compilação para o Fedora 43 foi concluída
  • Também é possível continuar compilações adicionais seguindo a tag ‘f43-updates’

  • Problema de velocidade de compilação no RISC-V

    • O hardware RISC-V atualmente mostra velocidade de compilação extremamente lenta
    • O tempo de compilação do binutils 2.45.1-4.fc43 foi medido em 143 minutos no riscv64, 36 minutos no aarch64 e 29 minutos no x86_64
    • A placa StarFive VisionFive 2 usada tem bom suporte de drivers, mas é lenta
    • Ao compilar o mesmo pacote na placa Milk-V Megrez, o processo levou 58 minutos
    • Atualmente, as compilações em RISC-V estão com o LTO (link-time optimization) desativado, como medida para reduzir o uso de memória e o tempo de compilação
    • Os builders têm 4 a 8 núcleos e 8 a 32 GB de RAM, com desempenho avaliado no nível de um Arm Cortex-A55
    • Para o futuro, espera-se melhora com o SoC UltraRISC UR-DP1000 (até 64 GB de RAM) e com sistemas baseados no SpacemiT K3 (até 32 GB de RAM)

  • Requisitos para entrar como arquitetura oficial do Fedora

    • Para ser incluído como arquitetura oficial do Fedora, é necessário hardware capaz de compilar o pacote binutils em menos de 1 hora
    • Também é preciso garantir velocidade equivalente à de outras arquiteturas mesmo com o LTO ativado em todo o sistema
    • Como os resultados de compilação só vão para o repositório quando todas as arquiteturas terminam, builders lentos provocam reclamações dos mantenedores de pacotes
    • Já houve reclamações no passado por causa da lentidão dos builders AArch64, e alguns desenvolvedores mencionaram a possibilidade de excluir o RISC-V
    • No futuro, os builders precisarão ser sistemas de servidor com montagem em rack e gerenciamento remoto; ambientes baseados em SBC com reinicialização manual não são adequados
    • Se essas condições não forem atendidas, não será possível adotar o RISC-V de 64 bits como arquitetura oficial do Fedora

  • Testes locais com QEMU

    • Como os tempos de compilação são longos, testes locais por emulação com QEMU são úteis
    • Em um desktop AArch64 de 80 núcleos, é possível compilar o pacote llvm15 em cerca de 4 horas usando emulação riscv64 em espaço de usuário no QEMU
    • O mesmo pacote leva 10,5 horas para ser compilado em um builder Banana Pi BPI-F3
    • Como o pacote LLVM usa intensamente tanto núcleos quanto memória, espera-se melhor desempenho em um sistema baseado no Ampere One com 192/384 núcleos
    • O QEMU é usado apenas para compilação e testes locais; o Fedora realiza apenas compilações nativas

  • Planos futuros

    • Está previsto o início das compilações do Fedora Linux 44
    • O objetivo é usar a mesma imagem de kernel em todos os builders, já que hoje há mistura de versões de kernel
    • O LTO continuará desativado
    • Para resolver o problema de desempenho, há planos de introduzir builders novos e mais rápidos e de atribuir alguns dos pacotes mais pesados a esses builders

Leituras relacionadas

1 comentários

 
GN⁺ 2026-03-24
Comentários do Hacker News

  • Em vez de culpar a própria ISA, acho que o problema está na implementação em silício e no software sem otimizações específicas para cada arquitetura
    No fim, o RISC-V também vai evoluir
    O ARM também era focado em velocidade no começo, depois mudou de direção para eficiência energética e teve sucesso no mercado embarcado, e agora mostra um movimento de volta ao foco em velocidade

    • Em alguns casos, considero que a própria especificação da ISA do RISC-V é o problema
      Por exemplo, há casos como LLVM issue #150263, #141488
      Além disso, o tamanho de página fixo de 4KiB também limita o desempenho em comparação com o ARM
    • É difícil concordar com a ideia de que “o RISC-V um dia vai alcançar”
      O ARM foi rápido, ficou lento e depois voltou a ficar rápido, mas o RISC-V ainda não mostrou competitividade nem uma vez na faixa de alto desempenho
      Implementações feitas por equipes pequenas são impressionantes, mas em nível de mobile, desktop e servidor ainda faltam muito
    • A afirmação de que “não é problema da ISA, e sim da implementação” está correta, mas é óbvia demais
      Na prática, o essencial é a projetização analógica em VLSI de coisas como estrutura de cache e interfaces DDR·PCI, e quase não há equipes que façam isso direito
      Além disso, toda empresa quer virar um “vendor de RISC-V de alto desempenho”, mas ninguém quer assumir o “mercado embarcado”
      Nos EUA, a realidade é que, em vez de fabricar chips diretamente, vende-se apenas IP, então para conseguir hardware de verdade é preciso depender de vendors chineses
    • Quando se olha para o padrão de evolução do desempenho de CPUs, repete-se um ciclo em que primeiro se otimiza a eficiência energética e depois se aumenta a velocidade
      Um caso representativo é o da arquitetura Netburst do Pentium 4, que bateu no limite, e da arquitetura Core, derivada de núcleos de baixo consumo, que virou a principal linha da Intel
      A história do ARM mostra um fluxo parecido
    • Em um vídeo do LowSpecGamer, há a história de que os primeiros chips ARM funcionavam até só com diodos de proteção
      Segundo Steve Furber, eles eram tão eficientes que chegaram a executar código mesmo quando esqueceram de ligar a alimentação

  • Compartilho uma correção a um post de blog escrito por um colega
    No sistema de build RISC-V do Fedora, o build do binutils foi concluído em 67 minutos no Milk-V “Megrez”, uma grande melhora em relação ao recorde anterior de 143 minutos
    Atualmente, as dev boards mais rápidas não são a Banana Pi, e sim a SiFive “HiFive P550” e a UltraRISC “DP1000”
    A apresentação do FOSDEM “Fedora on RISC-V: state of the arch” também aborda benchmarks relacionados
    O teste do Marcin foi executado em uma StarFive “VisionFive 2”, que é estável, mas relativamente lenta

    • A VisionFive 2 é confiável, mas como é uma placa com mais de 3 anos, há limitações de memória para builds recentes
      Para linkar 4 binários ao mesmo tempo durante o build do gcc, são necessários pelo menos 16GB, e é preciso ativar swap para funcionar com estabilidade
      Na VisionFive 2, é preciso fazer o build com -j1 ou -j2, então o tempo aumenta de 2 a 4 vezes
      É mais eficiente usar um linker melhor (substituto do ld) ou, como no sistema de build do LLVM, definir separadamente o número de links paralelos

  • O ARM levou 40 anos para chegar onde está hoje, e o RISC-V ainda tem só 15 anos
    Neste ano, a Tenstorrent deve lançar uma plataforma de servidor baseada em RVA23, então vale a pena acompanhar
    No fim, a chave é que os vendors de hardware lancem silício de alto desempenho

    • O RISC-V foi muito influenciado pelo MIPS, e o MIPS também recebeu grandes expectativas no início dos anos 90, mas acabou perdendo espaço no mercado
    • O AArch64 tem só 15 anos, mas é uma arquitetura quase completamente diferente do ARM de 32 bits

  • O felix está compilando o repositório Arch Linux RISC-V com um Milk-V Pioneer
    Acho que a lentidão do desenvolvimento também se deve às sanções contra a SOPHGO
    O Milk-V Oasis baseado no SG2380 da SOPHGO teve o lançamento cancelado, mas era um SoC muito promissor
    Os chips dessa empresa suportavam uma arquitetura dupla com alternância entre ARM/RISC-V
    Consulte o repositório Arch RISC-V e a matéria relacionada

    • Tenho curiosidade sobre quais sanções afetaram concretamente o quê, e se alguém poderia explicar isso em mais detalhes

  • Fico pensando por que o software para RISC-V precisa necessariamente ser compilado em um sistema RISC-V
    Como o compilador embute no código as informações da arquitetura-alvo, em teoria não deveria ser possível fazer isso também em outros sistemas?

    • Para fazer cross-compilation de uma distribuição inteira, essa distribuição precisa dar suporte a isso
      O Fedora atualmente só dá suporte a builds nativos, e seus compiladores cruzados existem apenas na versão bare-metal para firmware
      Além disso, como a automação de testes é difícil, o build nativo com testes em hardware real é mais realista
      O AArch64 também era lento no começo, mas hoje evoluiu a ponto de um build do Qt4 terminar em 18 minutos
    • Há muitos problemas de dependência em que scripts de build consultam bibliotecas ou configurações do SO hospedeiro
      Dá para resolver dependendo da linguagem, mas o ecossistema C/C++ é especialmente complexo
      Por isso, a maioria compila em VM ou no hardware-alvo real
    • Compiladores antigos escolhiam o backend no momento da compilação, então era difícil dar suporte a múltiplas arquiteturas
      Depois do LLVM isso passou a ser possível, mas ainda é preciso um emulador para testar
    • O cross-build em si é possível, mas os testes após o build exigem mais recursos
    • O compilador cruzado em si é fácil, mas como seria preciso corrigir os scripts de build de dezenas de milhares de pacotes, o custo de manutenção é alto

  • Também há a opinião de que “não bastaria fazer cross-compilation em um servidor x86_64?”

    • Mas adaptar todo o software para suportar cross-compilation perfeitamente é um trabalho enorme

  • Há um ano vi no Mastodon uma postagem dizendo que “o hardware RISC-V mais rápido é mais lento que o QEMU”
    Embora o RISC-V esteja se espalhando por várias áreas, ele ainda é fraco em computação de alto desempenho

    • O Milk-V Pioneer superou esse limite, mas é caro e a arquitetura usada também é antiga
      Além disso, a empresa desenvolvedora sumiu por causa das sanções dos EUA

  • Não é que cross-compilation seja impossível, mas a execução de testes nas etapas %install e %check é o problema
    Por exemplo, no PR do pacote rpy, foi necessário desativar os testes vetoriais no RISC-V
    Dá para separar build e testes, mas a economia de tempo não é tão grande em relação à complexidade

    • O Fedora tradicionalmente prefere builds nativos
      Na thread da LWN de 2012 (link), já havia discussões contrárias à cross-compilation
    • O build com QEMU é a alternativa mais realista

  • O resultado de que i686 é 14% mais rápido que x86_64 parece suspeito
    Normalmente o x86_64 é mais rápido, graças ao aumento no número de registradores e às instruções vetoriais
    Ainda assim, como o compilador pode tentar mais otimizações, o tempo de build pode acabar ficando maior
    É possível que haja um fenômeno parecido no RISC-V

    • Quando o i686 é mais rápido, isso pode ser por causa de um gargalo de largura de banda de memória
    • O build x86_64 tem 50% mais testes de linker do que o i686

  • Como o texto não especifica qual CPU RISC-V foi usada, a comparação fica ambígua

    • Na prática, a maioria dos builders tem configuração de 4~8 núcleos e 8~32GB de RAM, e não há muitas opções
      O Milk-V Pioneer é uma exceção, com 64 núcleos e 128GB de RAM, mas usa uma arquitetura antiga e tem preço alto