Reproducibility and Transparency Audit of Parallel Runtime Performance Reporting in Open-Source Benchmarks: A Case Study of the Rust, Julia, Haskell, and Python Ecosystems

No mundo da ciência da computação, pesquisadores comparam constantemente diferentes linguagens de programação para ver qual delas lida melhor com o trabalho pesado. Imagine uma equipe de trabalhadores tentando mover uma pilha enorme de caixas. Algumas equipes usam uma única pessoa forte, enquanto outras usam muitas pessoas trabalhando juntas. No reino digital, esse "trabalhar juntos" é chamado de desempenho paralelo, onde um computador divide uma tarefa difícil entre vários processadores para terminá-la mais rápido. Cientistas usam essas comparações para decidir qual linguagem usar para tudo, desde a previsão do tempo até serviços web. No entanto, para que essas comparações sejam confiáveis, os pesquisadores devem fornecer uma receita completa de exatamente como realizaram seus testes. Eles precisam listar o computador específico que usaram, a versão exata do software, quantos trabalhadores atribuíram ao trabalho e como mediram o tempo. Sem esses detalhes, a afirmação de que uma linguagem é mais rápida que outra é apenas uma história, não um fato científico.

Um pesquisador da University College London, Magnus Bright, decidiu investigar se os cientistas estão realmente fornecendo esses detalhes necessários. Em vez de realizar novos testes em computadores, Bright conduziu uma auditoria sistemática de 160 estudos publicados envolvendo quatro linguagens de programação populares: Rust, Julia, Haskell e Python. O objetivo não era ver qual linguagem venceu, mas verificar se os vencedores foram declarados de forma justa. O estudo analisou artigos publicados entre 2015 e 2025, examinando se o autor incluiu as informações específicas necessárias para que outra pessoa pudesse repetir o experimento e obter o mesmo resultado. Os achados revelam um cenário onde alguns detalhes são compartilhados livremente, enquanto outros são frequentemente omitidos, deixando o registro científico incompleto.

A auditoria descobriu que os pesquisadores são geralmente bons em relatar o básico. A maioria dos artigos declarou claramente o tamanho dos dados que estavam processando e quantos trabalhadores ou threads usaram para processá-los. Estas são as partes mais óbvias do experimento, e omiti-las tornaria os resultados impossíveis de entender. No entanto, o estudo revelou lacunas significativas nos detalhes mais sutis, porém críticos. Por exemplo, apenas cerca de um terço dos estudos relatou como lidaram com o período inicial de "aquecimento" (warm-up). Este é um passo crucial para certas linguagens que precisam se preparar antes de rodar em velocidade máxima; sem saber quanto tempo durou essa preparação, é impossível saber se a velocidade relatada foi real ou apenas um artefato da configuração. Da mesma forma, menos de um em cada quatro estudos explicou como posicionou seus trabalhadores nos processadores do computador. Esse posicionamento pode mudar drasticamente a velocidade com que uma tarefa é executada, mas a maioria dos autores deixou essa informação de fora.

A situação era ainda mais desigual quando se tratava de rigor estatístico. Em muitos campos da ciência, os pesquisadores relatam não apenas um resultado médio, mas também o quanto esse resultado varia. Essa variação diz ao leitor se a diferença entre duas linguagens é real ou apenas ruído aleatório. Nesta auditoria, apenas cerca de 40 por cento dos estudos incluíram qualquer medida dessa variação. Sem ela, o leitor não consegue dizer se uma diferença de velocidade relatada é significativa ou se poderia ter ocorrido por acaso. O estudo também observou se o código e os dados reais estavam disponíveis para que outros pudessem verificar. Embora quase 70 por cento dos estudos tenham fornecido o código-fonte, muito poucos forneceram o ambiente completo necessário para executá-lo, como um contêiner digital pré-embalado que garante que o software se comporte exatamente da mesma forma em uma máquina diferente. Apenas cerca de 9 por cento dos estudos ofereceram tal contêiner, o que significa que, mesmo quando o código está disponível, muitas vezes é difícil usá-lo para verificar os resultados.

Os pesquisadores também notaram que a qualidade do relato dependia fortemente de onde o estudo foi publicado e de qual comunidade de linguagem o produziu. Estudos que aparecem em veículos dedicados a sistemas de computação de alto desempenho foram os mais minuciosos, frequentemente incluindo especificações detalhadas de hardware e configurações. Em contraste, estudos em veículos de computação geral eram muito menos propensos a incluir esses detalhes. Além disso, as próprias comunidades de linguagens mostraram hábitos diferentes. As comunidades em torno de Rust e Julia tendiam a ser mais cuidadosas ao relatar versões de software e configurações de compilador, provavelmente porque suas ferramentas são projetadas para tornar esses detalhes fáceis de rastrear. A comunidade Haskell apresentou as pontuações de relato mais baixas no geral, enquanto os estudos de Python frequentemente falharam em relatar quantas vezes executaram seus testes. O estudo sugere que essas diferenças não são apenas sobre diligência individual, mas sobre as normas e expectativas dos grupos e periódicos específicos envolvidos.

Quando os pesquisadores olharam para o motivo pelo qual os autores deixaram esses detalhes de fora, descobriram que as razões eram frequentemente práticas, em vez de maliciosas. Muitos autores citaram limites estritos de páginas em artigos de conferências como a razão para omitir longas listas de especificações técnicas. Outros assumiram que certos detalhes eram tão óbvios para seus pares que não precisavam ser escritos. Alguns autores simplesmente priorizaram os resultados finais sobre o método, acreditando que a história da descoberta era mais importante do que a receita técnica. O estudo também destacou um ponto cego legal e ético: em mais da metade dos casos, não estava claro se os dados ou o código usados nos benchmarks poderiam ser legalmente reutilizados por outros. Essa falta de clareza torna difícil para futuros pesquisadores construírem sobre trabalhos passados sem correr riscos legais.

Para abordar essas questões, o estudo propõe um checklist simples e mínimo para qualquer pessoa que publique uma comparação de linguagens de programação. Este checklist pede aos autores que listem o hardware específico do computador, as versões exatas do software, como os trabalhadores paralelos foram configurados, o tamanho e a origem dos dados, quantas vezes o teste foi executado e as medidas estatísticas usadas para analisar os resultados. Também pede que o código e os dados sejam compartilhados de uma forma que permita que outros os executem facilmente. O estudo conclui que a credibilidade de uma afirmação de desempenho depende inteiramente da documentação que a sustenta. Um número de aceleração sem contexto é apenas um número; com os detalhes certos, ele se torna um conhecimento científico confiável. Ao adotar esses padrões mais claros, a comunidade pode garantir que o esforço substancial colocado na pesquisa de desempenho resulte em resultados que possam ser confiados, compreendidos e construídos por todos.