Quão rápido pode ir?

37

O Go é uma das poucas linguagens que devem rodar "perto do metal", i. e. é compilado, estaticamente digitado e executa código nativamente, sem uma VM. Isso deve dar uma vantagem de velocidade sobre Java, C # e afins. Parece, no entanto, que está por trás do Java (veja o Programação de Idioma )

Estou assumindo que os compiladores menos maduros são extremamente responsáveis por isso, mas existem outras razões? Existe algo inerente ao design do Go que o impediria de rodar mais rápido do que, digamos, Java? Eu tenho uma visão muito pouco sofisticada dos modelos de tempo de execução, mas parece que, pelo menos em princípio, ele deve ser capaz de rodar mais rápido que o Java, graças à execução de código nativo.

    
por Greg Slodkowicz 14.06.2011 / 14:17
fonte

3 respostas

44

Em termos de design de linguagem, não há realmente nada que deva tornar o Go mais lento que o Java em geral. Na verdade, você tem mais controle sobre o layout da memória de suas estruturas de dados, portanto, para muitas tarefas comuns, deve ser um pouco mais rápido. No entanto, o compilador principal atual do Go, o agendador, o coletor de lixo, a biblioteca regexp e muitas outras coisas não são particularmente otimizados. Isso está melhorando constantemente, mas o foco parece ser ser útil, simples e rápido o suficiente para vencer em microbenchmarks.

No benchmark vinculado, o Go perde muito para o Java na árvore binária e no teste regexp. Esses são testes do sistema de gerenciamento de memória e da biblioteca regexp, respectivamente. O gerenciamento de memória do Go pode ser mais rápido e certamente melhorará com o tempo, e a biblioteca regexp padrão atual é um substituto para uma implementação muito melhor que está prestes a acontecer. Então, perder nesses dois não é surpreendente, e no futuro próximo a margem deve ser mais estreita.

Para o benchmark k-nucleotide, é um pouco difícil comparar, porque o código Java parece estar usando um algoritmo diferente. O código Go certamente se beneficiará das melhorias no compilador, agendador e alocador que virão, mesmo quando escritas, mas alguém teria que reescrever o código Go para fazer algo mais inteligente se quiséssemos comparar com mais precisão.

Java vence no benchmark mandelbrot porque é toda aritmética e loops de ponto flutuante, e este é um ótimo lugar para a JVM gerar um código de máquina realmente bom e içar coisas em tempo de execução. O Go, em comparação, tem um compilador bem simples que não elimina, desenrola ou gera código de máquina realmente rígido atualmente, então não é surpresa que ele perca. No entanto, deve-se ter em mente que o tempo do Java não conta o tempo de inicialização da JVM ou muitas vezes ele precisa ser executado para a JVM para JIT muito bem. Para programas de longa duração, isso não é relevante, mas é importante em alguns casos.

Quanto ao restante dos benchmarks, Java e Go são basicamente “neck-in-neck”, com o Go levando muito menos memória e, na maioria dos casos, menos código. Assim, enquanto o Go é mais lento que o Java em vários desses testes, o Java é bastante rápido, o Go se sai muito bem em comparação, e o Go provavelmente ficará notavelmente mais rápido no futuro próximo.

Estou ansioso para saber quando o gccgo (um compilador Go que usa o codegen gcc) está maduro; Isso deve deixar o Go praticamente alinhado com o C para muitos tipos de código, o que será interessante.

    
por 14.06.2011 / 22:50
fonte
22
  1. Sem nem mesmo dizer quais problemas foram resolvidos, todo o benchmark é inútil.
  2. JVM e CLR usam JITs para produzir código de máquina. Não há razão para que isso deva ser mais lento. Custa apenas você envelhecer.
  3. O Go foi projetado para ser rápido . Você não tem toneladas de tempo de compilação e otimizações de tempo de inicialização. Go compila sua própria biblioteca padrão no momento em que um aplicativo Java é inicializado.

Poderia ser mais rápido em tempo de execução? Sim. Vai sempre ser mais rápido em tempo de execução? Eu não sei. Talvez os construtores de compiladores adicionem otimização opcional ao custo do tempo de compilação. Mas não acho que eles tenham muito interesse nisso. Eles trabalham no Google.
O que eles querem é uma linguagem que permita um desenvolvimento rápido e que tenha bom desempenho naquilo que faz. Inferno, mesmo que esse benchmark fosse credível, isso significaria que eles são tão rápidos quanto C e 14 vezes mais rápidos que o Python. Isso é mais que suficiente.
O hardware é barato, o código é caro. O código tende a se tornar maior e mais lento à medida que você investe dinheiro, o hardware se torna mais barato e menor. Você quer uma linguagem, que não requer 4 estruturas e 2000 classes para realizar qualquer coisa útil. Não há nada inerente ao design do Go, que o torna lento. No entanto, há algo inerente aos designers do Go, que torna mais lento que a montagem: o senso comum.

    
por 14.06.2011 / 14:56
fonte
10

Eu também percebi que o Go era particularmente lento na regex dna benchmark. Russ Cox explicou por que a Go não teve esse desempenho nessa referência específica . A razão é que o pacote regexp da Go está usando um algoritmo de correspondência diferente que executa mal neste benchmark em particular, mas pode ser por uma magnitude mais rápida em outros benchmarks. Também Ruby, Python e outras linguagens de script estão usando uma implementação em C de outro algoritmo de correspondência de expressão regular .

Finalmente, o Benchmarks de Linguagem do Computador Jogo consiste em micro-benchmarks que podem não refletir com precisão muitas características dos idiomas medidos e até mesmo mediar impressões erradas. Este artigo de pesquisa publicado recentemente pelo Google oferece mais visão geral precisa de várias características da linguagem Go, Scala, Java e C ++ - particularmente a parte "V. Performance Analysis". Então, no final, Go é quase tão faminto de memória quanto Java (81% da memória do Java) e consome até 170% da memória do Scala (não foi possível encontrar no papel se o consumo de memória da JVM era considerado).

Mas, novamente, o Go é jovem e ainda está sob strong desenvolvimento (mudanças na API)! Muitas melhorias estão chegando em breve.

    
por 15.06.2011 / 15:37
fonte