O `std::fs` do Rust é mais lento que Python? Não, é problema de hardware

O binding Python do OpenDAL é mais lento que Python?

• OpenDAL é uma camada de acesso a dados que permite buscar dados de forma eficiente em vários serviços de armazenamento.
• Há relatos de que o binding Python do OpenDAL é mais lento que o próprio Python.
• Levanta-se a hipótese de que o cache interno do Python, a aceleração de leitura de arquivos e a sobrecarga adicional do PyO3 possam ser as causas.

O serviço Fs do OpenDAL é mais lento que Python?

• É um problema que envolve vários elementos, como Rust, OpenDAL, Python e PyO3.
• Também foi constatado que o serviço fs do OpenDAL, implementado em Rust, é mais lento que Python.

O std::fs do Rust é mais lento que Python?

• O OpenDAL implementa o serviço fs por meio de std::fs.
• Confirmou-se que a implementação usando std::fs do Rust também é mais lenta que Python.

O std::fs do Rust é mais lento que Python? Sério!?

• O resultado de que o std::fs do Rust é mais lento que Python é questionado.
• Aprende-se a analisar chamadas de sistema usando strace.
• Ao analisar o resultado do strace, não se encontra a razão de Python ser mais rápido, mesmo que ambos usem mmap.

Por que usar mmap aqui?

• mmap é usado não apenas para mapear arquivos na memória, mas também para alocar grandes regiões de memória.
• Ao solicitar memória com malloc, o glibc usa mmap para alocar memória.

Python tem o mesmo alocador de memória que Rust?

• Python usa um alocador de memória chamado pymalloc, otimizado para pequenas alocações.
• O pymalloc é otimizado para objetos pequenos, e para grandes alocações usa PyMem_RawMalloc() e PyMem_RawRealloc().

Rust é mais lento que Python com o alocador de memória padrão?

• Suspeita-se que mmap seja a causa do problema.
• Descobre-se que um programa Rust que troca para jemalloc passa a rodar mais rápido que Python.

Rust é mais lento que Python só no meu computador!

• O fato de Rust rodar mais devagar que Python acontece apenas em um computador específico.
• São fornecidas informações detalhadas sobre a CPU e a memória.
• Mesmo ajustando mitigação de vulnerabilidades da CPU, Transparent Hugepage e afinidade de núcleos da CPU, não há mudança no resultado.
• Usando um programa eBPF, confirma-se que Rust é mais lento que Python até no nível de chamadas de sistema.

C é mais lento que Python?

• Descobre-se que a versão implementada em C também é mais lenta que Python.

C é mais lento que Python? Sem offset especificado!

• Descobre-se uma diferença no offset da região de memória e, ao ajustar esse offset, o desempenho do programa em C melhora.
• Confirma-se que, em CPUs AMD Ryzen, há queda de desempenho sem um offset específico.

O AMD Ryzen 9 5900X é lento sem o offset especificado!

• Confirma-se que é um problema relacionado à CPU, e um desenvolvedor do kernel entra na discussão.
• Com profiling usando perf, confirma-se novamente que há queda de desempenho sem o offset.

Opinião do GN⁺: O ponto mais importante deste texto é que Rust e C podem rodar mais lentamente que Python em certos ambientes de hardware, e isso pode estar ligado à alocação de memória e a comportamentos específicos da CPU. O texto mostra, ao explorar os vários fatores que afetam o desempenho de software, o quão complexa pode ser a interação entre hardware e software. Essa investigação oferece uma lição importante para resolver problemas inesperados que podem surgir no mundo da engenharia de software.

[GN⁺]

Comentários do Hacker News

• Opinião sobre uma premissa confusa

  Um usuário demonstrou estranheza com a ideia de que as funções da biblioteca padrão do Python seriam escritas em Python puro. Acha interessante a diferença de desempenho, já que tanto os métodos de leitura de arquivos do Python quanto o OpenDAL são wrappers em Python sobre código nativo, mas considera estranho dizer que algo é "mais lento que Python". Esperava que as funções da biblioteca padrão do Python fossem implementadas em código nativo e que cada uma fosse otimizada. Não se surpreendeu com a conclusão do artigo, de que o problema estava relacionado à forma como o código nativo funciona; ficou surpreso com uma resposta específica, mas reconheceu que, apesar do começo confuso, o artigo foi muito interessante.

• Discussão sobre flags de recursos da CPU

  Há duas flags dedicadas de recursos da CPU indicando que as instruções REP STOS/MOV são rápidas e podem ser usadas como uma sequência curta de instruções para memset/memcpy. Criar manualmente rotinas otimizadas para cada nova geração de CPU tem sido um sofrimento que dura décadas. O usuário questiona se isso não deveria fazer parte da suíte de testes de temporização dos fabricantes de CPU.

• Link para bug relacionado no glibc

  Foi fornecido um link para um bug do glibc relacionado ao Zen 4.

• Reação positiva ao artigo

  Um usuário disse que começou a ler o artigo pronto para rir do uso incorreto de std::fs, mas avaliou que ele é bem escrito e muito interessante, como uma sequência de toca de coelho e mistérios.

• Grande elogio ao artigo

  Outro usuário avaliou que este foi o artigo mais interessante que leu nesta semana e elogiou a excelente qualidade da escrita.

• Sugestão para resolver o problema

  Como solução óbvia, foi sugerido enviar um patch alterando o método do kernel copy_user_generic para usar outra implementação de cópia de memória quando a CPU for detectada como problemática e o alinhamento de memória acionar o bug de lentidão.

• Informação sobre o alocador padrão do Rust

  Foi compartilhada a informação de que o alocador padrão do Rust era o jemalloc até 2018, junto com um link relacionado.

• Considerações de desenvolvedores Rust para melhorar desempenho

  Foi levantada a dúvida se desenvolvedores Rust deveriam considerar migrar para jemallocator para melhorar o desempenho, se isso seria uma forma de todo mundo ganhar desempenho “de graça”, se codebases em C também poderiam se beneficiar disso e se há desempenho sendo deixado na mesa atualmente.

• Explicação sobre diferenças de CPU entre AMD e Intel

  Foi explicado que a forma como a AMD faz armazenamento de strings é diferente da Intel, e que é melhor não usar isso até ultrapassar o tamanho de L2 da CPU. Depois desse ponto, usar armazenamento de strings passa a ser vantajoso e deveria operar em “velocidade de DRAM”, mas, como há um alto custo inicial, é preciso usar loads/stores vetoriais de 256 bits até alcançar esse limiar.

• Compartilhamento do artigo com as pessoas certas

  Um usuário afirmou ter encaminhado este artigo para as pessoas apropriadas.