¿Qué tan rápido puede ir Go?

39

Go es uno de los pocos lenguajes que se supone que se ejecuta 'cerca del metal', es decir, está compilado, estáticamente escrito y ejecuta código de forma nativa, sin una VM. Esto debería darle una ventaja de velocidad sobre Java, C # y similares. Parece, sin embargo, que está detrás de Java (vea el Shootout del lenguaje de programación )

Supongo que los compiladores menos maduros son enormemente responsables de esto, pero ¿hay alguna otra razón? ¿Hay algo inherente en el diseño de Go que impida que se ejecute más rápido que, por ejemplo, Java? Tengo una visión muy poco sofisticada de los modelos de tiempo de ejecución, pero parece que al menos en principio debería poder ejecutarse más rápido que Java, gracias a la ejecución de código nativo.

Greg Slodkowicz
fuente
3
Dado un compilador suficientemente inteligente (y / o VM, y / o un compilador JIT), un lenguaje dado siempre puede ir más rápido (bueno, hay limitaciones físicas, pero eso es todo). Este truismo, por supuesto, no ayuda a nadie, siempre y cuando este compilador suficientemente inteligente no esté allí. Sin embargo, tenga en cuenta que Java ya tiene esas implementaciones suficientemente inteligentes, y son increíblemente inteligentes. Otro hecho de la vida es que la ejecución del código tiene al menos tanta influencia en el rendimiento del tiempo de ejecución como la implementación.
1
Entiendo eso, pero me preguntaba si es razonable esperar que la velocidad de Go coincida / supere, por ejemplo, Java a medida que madura el compilador.
Greg Slodkowicz
17
Los lenguajes de programación no tienen velocidad. Tampoco las implementaciones de lenguaje. Una implementación de un lenguaje dado tiene una velocidad para alguna entrada dada, y esta velocidad puede variar mucho dependiendo de la entrada.
8
Despiértame ... antes de que te vayas ... ¡WHAM! . Lo siento, no pude resistirme. Aquí vienen las banderas ... aquí vienen las banderas ..
Tim Post
2
@delnan - ¿O es mucho más fácil decir "Java" que decir "Java (TM) SE Runtime Environment (build 1.6.0_25-b06) Java HotSpot (TM) 64-Bit Server VM (build 20.0-b11 , modo mixto) ":-)
igouy

Respuestas:

46

En términos de diseño de lenguaje, en realidad no hay nada que deba hacer que Go sea más lento que Java en general. De hecho, le brinda un mayor control del diseño de memoria de sus estructuras de datos, por lo que para muchas tareas comunes debería ser algo más rápido. Sin embargo, el compilador Go, el planificador, el recolector de basura, la biblioteca regexp y muchas otras cosas principales no están particularmente optimizados. Esto está mejorando constantemente, pero el enfoque parece estar en ser útil, simple y lo suficientemente rápido como para ganar en microbenchmarks.

En el punto de referencia vinculado, Go pierde mucho frente a Java en el árbol binario y la prueba regexp. Esas son pruebas del sistema de administración de memoria y la biblioteca regexp respectivamente. La administración de memoria de Go podría ser más rápida y ciertamente mejorará con el tiempo, y la biblioteca de expresiones regulares estándar actual es un marcador de posición para una implementación mucho mejor que está por venir. Entonces, perder en esos dos no es sorprendente, y en el futuro cercano el margen debería ser más estrecho.

Para el punto de referencia de k-nucleótidos, es algo difícil de comparar porque el código Java parece estar usando un algoritmo diferente. El código Go sin duda se beneficiará de las futuras mejoras del compilador, el planificador y el asignador, incluso tal como está escrito, pero alguien tendría que reescribir el código Go para hacer algo más inteligente si quisiéramos comparar con mayor precisión.

Java gana en el punto de referencia de mandelbrot porque todo es aritmética de punto flotante y bucles, y este es un gran lugar para que la JVM genere un código de máquina realmente bueno y levante cosas en tiempo de ejecución. Go, en comparación, tiene un compilador bastante simple que no levanta, desenrolla ni genera un código de máquina realmente ajustado actualmente, por lo que no es sorprendente que pierda. Sin embargo, uno debe tener en cuenta que el tiempo de Java no cuenta el tiempo de inicio de JVM o las muchas veces que debe ejecutarse para que JVM lo ejecute correctamente. Para programas de larga duración, esto no es relevante, pero es importante en algunos casos.

En cuanto al resto de los puntos de referencia, Java y Go están básicamente unidos, y Go toma significativamente menos memoria y, en la mayoría de los casos, menos código. Entonces, mientras que Go es más lento que Java en varias de esas pruebas, Java es bastante rápido, Go lo hace bastante bien en comparación, y Go probablemente será notablemente más rápido en el futuro cercano.

Estoy deseando que gccgo (un compilador de Go que usa el código de gcc) esté maduro; eso debería hacer que Go esté bastante en línea con C para muchos tipos de código, lo que será interesante.

Kyle C
fuente
2
Bien hecho, para comprender que siempre es necesario mirar el código fuente y verificar lo que se está haciendo.
igouy
1
Sobre el tiempo de inicio de Java para esos programas, vea shootout.alioth.debian.org/help.php#java
igouy
2
Ese es exactamente el tipo de respuesta que esperaba, ¡gracias!
Greg Slodkowicz
Mucho menos uso de código y memoria, compila el código de la máquina, mejor diseñado. Todo esto se hace cargo de la desventaja de la velocidad.
Moshe Revah
22
  1. Sin siquiera decir qué problemas se resolvieron, todo el punto de referencia no tiene sentido.
  2. JVM y CLR usan JIT para producir código de máquina. No hay razón para que esto sea más lento. Simplemente te cuesta años arrancar.
  3. Go fue diseñado para construir rápido . No tiene toneladas de tiempo de compilación y optimizaciones de tiempo de arranque. Go compila su propia biblioteca estándar cuando se inicia una aplicación Java.

¿Podría ir más rápido en tiempo de ejecución? Sí. ¿Go alguna vez será más rápido en tiempo de ejecución? No lo sé. Tal vez los creadores del compilador agregarán una optimización opcional a costa del tiempo de compilación. Pero no creo que tengan mucho interés en eso. Ellos trabajan en Google.
Lo que quieren es un lenguaje que permita un desarrollo rápido y que funcione bien en lo que hacen. Demonios, incluso si ese punto de referencia fuera creíble, significaría que son la mitad de rápido que C y 14 veces más rápido que Python. Esto es más que suficiente.
El hardware es barato, el código es caro. El código tiende a hacerse más grande y más lento a medida que invierte dinero, el hardware se vuelve más barato y más pequeño. Desea un lenguaje que no requiera 4 frameworks y 2000 clases para lograr algo útil.
No hay nada inherente en el diseño de Go, eso lo hace lento. Sin embargo, hay algo inherente en los diseñadores de Go, que lo hace más lento que el ensamblaje: sentido común.

back2dos
fuente
1
La mayoría de los JIT (¿todos?) Se compilan durante el tiempo de ejecución, no cuando se carga el código por primera vez. Este código máquina no se puede generar en absoluto para un cierto código y también puede ser fácilmente invalidado, por ejemplo, si el objsde for (obj : objs) { obj.meth() }tener diferentes implementaciones de methtodos los tiempos y los intentos JIT a Inline ella. Por supuesto, todo esto es realmente un beneficio en los casos comunes, pero aún es digno de mención.
@delnan: El V8 JITs cualquier código antes de ejecutarlo. Además, el LLVM se creó con JITting en mente, por lo tanto (con un poco de esfuerzo, por supuesto) puede hacer cualquier optimización justo a tiempo, que de lo contrario sucedería en el momento de la compilación. Sin embargo, ciertas optimizaciones, como el análisis de escape, solo funcionan realmente con JIT.
back2dos
3
>> Sin decir siquiera qué problemas se resolvieron << Mire y verá que esas páginas web SÍ dicen qué problemas se resolvieron. De hecho, encontrará el código fuente del programa, los comandos de compilación, los comandos de ejecución, la versión de implementación del lenguaje, ya da ya da ya
igouy
10

También he notado que Go fue particularmente lento en el benchmark regex-dna . Russ Cox explicó por qué Go no era tan eficiente en este punto de referencia en particular . La razón es que el paquete regexp de Go está utilizando un algoritmo de coincidencia diferente que funciona mal en este punto de referencia en particular, pero podría ser mucho mayor en otros puntos de referencia. También Ruby, Python y otros lenguajes de secuencias de comandos están utilizando una implementación en C de otro algoritmo de coincidencia de expresiones regulares .

Finalmente, el juego Computer Benchmarks Game consta de micro-puntos de referencia que podrían no reflejar con precisión muchas características de los idiomas medidos e incluso mediar en impresiones erróneas. Este trabajo de investigación, publicado recientemente por Google, ofrece una descripción más precisa de varias características del lenguaje de Go, Scala, Java y C ++ , en particular la parte "V. Análisis de rendimiento". Entonces, al final, Go está casi tan hambriento de memoria como Java (81% de la memoria de Java) y consume hasta un 170% de memoria que Scala (no pudo encontrar en el documento si se consideraba el consumo de memoria de JVM).

Pero, de nuevo, Go es joven y aún está en desarrollo (cambios de API). Muchas mejoras vendrán pronto.

Alex
fuente
3
>> Este trabajo de investigación, publicado recientemente por Google << No es un trabajo de investigación, y no fue publicado por Google. Es un informe de experiencia de un empleado de Google presentado en el taller Scala "Scala Days 2011".
igouy
>> podría no reflejar con precisión muchas características de los lenguajes medidos e incluso mediar en impresiones erróneas << Eso es tan cierto para los programas de "reconocimiento de bucle", y es probable que sea cierto para cada comparación de rendimiento entre diferentes lenguajes de programación. De hecho, el autor le dice: "No exploramos ningún aspecto de los subprocesos múltiples o mecanismos de tipo de nivel superior ... tampoco realizamos cálculos numéricos pesados ​​..."
igouy
@igouy En la portada puede leer "Google" y todo lo relevante está cubierto con las referencias correspondientes. Entonces, ¿por qué no es un "documento de investigación, publicado por Google" si se menciona a Google con su dirección de la sede? Los trabajos de investigación no son un dominio exclusivo de la academia.
Alex
En la portada puede leer la dirección postal en la que se puede contactar al autor y la dirección de correo electrónico del autor. Verifique la URL del pdf que publicó. Tenga en cuenta el dominio - days2011.scala-lang.org - los Scala Days 2011 "Taller Scala.
igouy
1

Go es más rápido que Python y un poco más lento que Java. Mi experiencia aproximada ha encontrado que Go es mucho (1-2 órdenes de magnitud) más rápido que Python, y aproximadamente 10-20% más lento que Java. Sin embargo, Go es un poco más rápido que Java si se usa con quad-core (x64). Go también es mucho más eficiente en términos de memoria RAM.

Me gustaría agregar algunos puntos sobre el potencial de rendimiento de Go frente a Java y Python. Go permite más de las cosas que hace C, lo que constantemente le permite a C superar a la mayoría de los otros lenguajes. Las fallas de caché son bastante importantes para evitar el código de alto rendimiento. La reducción de errores de caché requiere controlar el diseño de memoria de sus estructuras de datos. Ir te permite hacer eso. Java no lo que hace que sea más difícil evitar la fractura de memoria y caché.

En este momento, Java generalmente se ejecuta más rápido que Go, porque el recolector de basura de Java es mucho más sofisticado. Aunque no hay razón para que el recolector de basura Go no pueda ser mucho mejor. La generación de código también es mucho mejor para Java en este momento. Go tiene mucho potencial para mejorar, por ejemplo, con soporte para instrucciones vectoriales, etc.

Así que creo que es solo una cuestión de tiempo antes de que Go supere a Java. Aunque al igual que con cualquier código de idioma, no es probable que sea más rápido automáticamente al estar escrito en Go. Tienes que utilizar las instalaciones que te da el idioma. Diría que Go simplemente brinda más oportunidades para ajustar su código.

De todos modos, esa es solo la experiencia de un desarrollador.

Milo Banks
fuente
44
Esta es una pregunta de 8 años y el poder de cómputo barato la ha hecho prácticamente irrelevante. Su respuesta también se basa en "su sentimiento" en lugar de datos duros. No quiero desanimarte, pero ...
Kayaman