Recientemente, en el trabajo, estábamos jugando con la siguiente pregunta de prueba realizada por IBM https://www.research.ibm.com/haifa/ponderthis/challenges/May2015.html
Después de un poco de esfuerzo, un colega y yo llegamos a dos soluciones, una en GoLang https://gist.github.com/walesey/e2427c28a859c4f7bc920c9af2858492#file-main-go-L57 y la otra en Java https://gist. github.com/boyter/42df7f203c0932e37980f7974c017ec5#file-puzzle-java-L63 con el método crítico de rendimiento tanto para juegos en Java como para juegos en GoLang (ambos vinculados arriba).
El programa Go es casi una copia literal del de Java y, sin embargo, su tiempo de ejecución es de ~6 segundos, mientras que el de Java es de unos ~26 segundos (en mi máquina local). Se replicaron números similares en algunas otras máquinas con el programa Go siendo aproximadamente ~ 5 veces más rápido.
El programa Go se compila usando 1.7.5 y Java usando la versión 1.8.0_65, ambos ejecutándose en macOS Sierra 10.12.3 en una retina Macbook Pro de finales de 2013 con CPU i5 de 2,6 GHz.
¿Por qué el programa Go es 5 veces más rápido que el de Java cuando la mayoría de los puntos de referencia indican que Java debería tener aproximadamente el mismo tiempo de ejecución? Es solo matemática básica en un bucle, por lo que parece que deberían ejecutarse aproximadamente al mismo tiempo. Podría entender un segundo más o menos para la hora de inicio de JVM, pero esto parece estar apagado.
Ambos programas utilizan prácticamente el mismo bucle. Todas las permutaciones posibles de los resultados del juego se crean y se repiten para cada cantidad inicial de dinero. Simplemente parece que para cualquier cantidad de operaciones de bucle en el bucle principal que Go está ejecutando suena alrededor de Java.
Entiendo que este es un punto de referencia "micro", pero me pregunto por qué exactamente el código Go está superando masivamente al código Java. ¿Es solo que Go for simple loops/math es más eficiente y, por lo tanto, más rápido? ¿Es capaz de desenrollar el ciclo tal vez (aunque parece poco probable que esto produzca una diferencia tan grande)?
Si no, ¿cómo debería estructurar un programa Java para obtener el máximo rendimiento de un simple bucle y una operación matemática?
EDITAR - Gracias a Dolda2000 he modificado la versión de Java. Ahora tiene aproximadamente la misma velocidad que la versión GoLang. De hecho, el problema fue que los juegos se crearon y la versión de Java tuvo que simular más juegos para determinar si el juego duraba lo suficiente. Con los cambios, ahora se está ejecutando en aproximadamente ~ 6 segundos y ha restaurado mi fe en Java.
Actualización : aquí hay un ensayo ampliado que analiza los antecedentes de esta pregunta con más detalle.
Resulta que sus programas no son tan iguales como cree que son. Los instrumenté para ver cuántos juegos (es decir, rondas de apuestas individuales) simulaban, y mientras la versión Go simuló 1 612 629 805 juegos, la versión Java simuló 12 323 903 502 juegos, casi un orden de magnitud más.
En mi máquina, desactivando subprocesos múltiples para obtener resultados más predecibles, el programa Java registró alrededor de 75 segundos y el programa Go en 12,5 segundos. Comparando eso con el tiempo de ejecución total, parece que el programa Java es un poco más rápido por juego simulado, aproximadamente 6,1 ns, en comparación con los 7,8 ns del programa Go.
Sin embargo, aún no estoy seguro de por qué simulan un número de juegos tan diferente. Quizás la forma en que la versión Go genera las rondas simplemente encuentra terminaciones mucho más rápidas.
EDITAR : En realidad, esa última suposición tiene mucho sentido. La versión Go comienza modulando las rondas iniciales de un juego, mientras que la versión Java comienza modulando las últimas rondas de un juego (en otras palabras, observa la lista de rondas como una lista de 11 dígitos en base 3 crecientes). números, la versión de Go es little-endian, mientras que la versión de Java es big-endian, por así decirlo), por lo que la versión de Java tendrá que simular a través de inicios mucho más idénticos para llegar a las variaciones que terminan. No he tratado de verificar esta hipótesis, pero estoy lo suficientemente seguro de que no siento la necesidad de hacerlo.