EDICIóN GENERAL
250 meneos
7309 clics
¿Por qué es 2 * (i * i) más rápido que 2 * i * i en Java? (Eng)

¿Por qué es 2 * (i * i) más rápido que 2 * i * i en Java? (Eng)

Si reemplazo 2 * (i * i) por 2 * i * i, se tarda entre 0.60 y 0.65s en ejecutarse. ¿Cómo es posible?

| etiquetas: programación , java , rápido
#12 Los mayores no usamos juguetes.
#137 calva!
#32 Que sepas que configurar un CMS y tocar un poco las plantillas no se puede llamar desarrollo web.
#111 Quien ha dicho eso, he dicho que los principales CMS están desarrollados en PHP esto conlleva todo una comunidad de desarrolladores que crean modulos, plugins adicionales para estas plataformas.
#15 Falta Python:

from castle import Princess

Y te sobra una viñeta para escribir un readme y un script de instalación con más líneas que la propia aplicación y subir el paquete a PyPI para que no lo descargue nadie :-D
#126 No, no falta. Monty Python sale perfectamente referenciado en la primera viñeta de PHP :troll:

cc/ #15  media
#132 xD Y el horse typing.

- Si camina como un caballo, galopa como un caballo y suena como un caballo. ¿Qué es?
- Unos cocos.
#15 Yo sí voy a añadir algo (los "=" se ven un poco mal)  media
#5 Sé que no lo has dicho, pero como bien dices entre líneas esto es lo que pasa cuando se permite que un populista llegue a venezuela como presidente. Disfruten lo votado.
#1 mis dieses.
#62 Pues parece que en Java es un poco mas eficiente el caso de declarar las variables dentro del for
stackoverflow.com/questions/407255/difference-between-declaring-variab
#112 En ese ejemplo no creo que sea por tema de eficiencia, sino por ámbito de variable...
#98 hay muchísimas en gittheprincess,esta me marco en la uni,es una versión algo mas antigua.
#1 Aplaudo su detallada argumentación
#49 Java es lento, lento como el solo. Y que tengas que declarar una clase para hacer un puto hola mundo lo convierte automáticamente en basura
#109 Java es mucho más rápido que los siguientes lenguajes:

- Ruby
- PHP
- Python
- Javascript.

Cuatro lenguajes que son muy, muy, muy usados.
Entiendo que esos cuatro lenguajes son basura también no?
#113 El único lenguaje que no es basura es C. Bueno, y Fortran
#37 Discrepo
#116 argumenta por favor.
#97 De hecho, a mi juicio, esto sólo es importante para los que hacen compiladores...
#139 exactamente, estoy totalmente de acuerdo.
#96 el problema no es que un juego pida mucha máquina (que también) El verdadero problema es que una web con 3 divs y dos .js te piden 8 núcleos xD
#30 El problema no viene por ahi. Estoy convencido que estoy pasa tambien si en vez de multiplicar por dos multiplicadas por tres. Internamente, la JVM esta pensada como una maquina de pila, no de registros. Cuando conviertes ese código a código nativo, acabas generando código que utiliza una cantidad muy pequeña de registros.

Muy por encima (en pseudoensamblador), imagino que la opción rápida hace:
MOV RAX [i]
MUL RAX, RAX, RAX
MUL RAX, RAX, 2

Mientras que la opción lenta hace:
MOV RAX,…   » ver todo el comentario
#123 No se porque pero me ha recordado a Mars Attack!!!
#15: Deberían parodiar a Phyton también, que tiene mucho que pwnear, por ejemplo, que la estructura va en la indentación, ideal para copiar y pegar en según que entornos, además de que es más fácil liarse si tienes que añadir cosas anidadas.
Porque el compilador de Java es un truño.
Siguiente pregunta.
#74 Correcto. Algo parecido digo en #60.
Pero no implica que en la grandísima mayoría de ocasiones la diferencia es despreciable.

Más aún, si tienes que analizar todos los problemas del compilador (probablemente esto es un problema del compilador ya que no hay ninguna razón lógica para ello) para casi cualquier operación del programa nunca acabarías el programa.

Premature optimization is the root of all evil.
#80 La lógica, en tu ejemplo, es, a mi juicio, mucho menos problemática que no declarar los enteros como constantes con un nombre descriptivo para saber a qué se refieren.... :-P
#158 quizás nos hemos visto en algún sitio, el mundo es un pañuelo!
#149 por cierto, te he agregado a LinkedIn :-)

He visto allí tu experiencia profesional, si te molan los temas de alto rendimiento creo que no estás en los entornos adecuados y te sugiero cambiar de empresas.

En Everis no vas a aprender muchas cosas de calidad, sinceramente.
#96 Que conste que en general tienes razón en tu comentario, pero es que si te pasa eso, seguro que hay cambios insignificantes que tienen mayor impacto en tu juego. De hecho si te pones a optimizar cualquier cosa en ensamblador seguramente consigas arañar alguna operación más y algún nanosegundo más.
#33 Pues no sabría qué decirte, el compilador lo puedes configurar para que se comporte de muchas maneras al compilar. Por ejemplo en una evaluación tipo (funcion1() && funcion2() && funcion3()) en la que cada una de las fuciones devolviese un booleano puedes hacer que el compilador ejecute las 3 funciones y después ejecutar la evaluación, pero también puedes configurarlo para que vaya ejecutando ambas cosas a la vez y en ese caso en ciertas ocasiones funcion3 no llegaría a…   » ver todo el comentario
#29 Otro? ... Java no es de tipado debil.
#13 Estoy seguro cualquier aplicación hará aguas por muchísimas partes antes que esto sea un problema real. Esto tiene un nombre y es el de micro optimizaciones.
#60 Suscribo tu comentario, pero es que aunque este problema sea algo apreciable, lo más probable es que tu programa haga aguas por cualquier otra parte por otro motivo y con un mayor impacto. En general en este meneo se cae en una falacia de agregar números insignificantes hasta llegar a cantidades monstruosas.

Ejemplo: si todas las personas del mundo dejan un arroz en su plato sin comer, si sumamos un arroz por toda la población mundial, cada día, a lo largo de un año tendrás toneladas de comida... sin embargo, eso no significa que realmente puedas alimentar a nadie con ese grano de arroz.
#23 No, java no usa el byte shift para esa multiplicación. Todo se resume a que en (2 * i) * i se lee el valor i dos veces, mientras que en 2 * (i * i) solo hace falta leer i una vez.
#99 Yo creo que no me he liado...
Yo he entendido perfectamente la mejora de rendimiento que se expone, pero ahora te pregunto, si cambiasemos el rango de esa ecuación, ¿podría esta mejora de rendimiento afectar al resultado? ¿Confiarías en el resultado de esa sencillísima fórmula?
#97 Ya te puse en el anterior comentario que era solo un ejemplo, y que no hablaba de esta optimización en particular, sino de que 100ms para una persona común puede parecer una cantidad de tiempo ínfima, pero por ejemplo, en un videojuego puede ser la diferencia entre una tasa de fotograma estable o no.

En cuanto al motor de física, hay todavia juegos que van asociados a la tasa de fotogramas, ejemplo? La saga fallout, la saga dark souls. No son juegos indie precisamente.
#102 asociar la fisica a los fotogramas es una decisión cuestionable, ya que el motor no sería viable sin modificaciones para plataformas de hardware donde el refreso sea determinante (como oculus rift) pero incluso aunque algún juego lo haga, en esos juegos son optimizaciones mas de alto nivel las que están haciendo funcionar el juego, no la diferencia entre 2*i*i vs 2*(i*i).

100ms es mucho para muchos programadores. a 60fps tienes 16ms por frame. En una petición a una API, quieres siempre…   » ver todo el comentario
#102 Generalmente para una tasa de 60fps necesitas 1 seg / 60 cuadros (16.666 ms o 33 ms si es 30 cuadros). Efectivamente la GPU puede hacer los cálculos concurrentes por fuerza bruta en hilos separados para digamos físicas, pero hay muchos otros factores que inciden en la escena como backface culling, el frustrum etc. en virtud de los cuales ciertas optimizaciones, por ejemplo en los BSPs, octrees o quadtrees para colisiones 2D , sí pueden hacer que no se pierdan cuadros por el camino y hacer que todo el conjunto se represente en esos 16.6 ms, lo que ya es jodido.
Todo el mundo comentando acerca de la operación aritmética pero ninguno parece que haya abierto el programa y lo haya visto.

El programa tarda entre 0.50s y 0.55s en ejecutarse con 2 * i * i.
El programa tarda entre 0.60s y 0.65s en ejecutarse con 2 * (i * i).

¿Y qué es el programa? Mil millones de iteraciones de esa multiplicación.

Mil millones. Y la diferencia es 0.15s contando todas las operaciones.

Obviamente es importante la optimización y está muy bien saber que Java es más rápido haciendo este tipo de cosas.
Pero no es tanta la diferencia entre hacer esto o no hacerlo. En el 99.99% de los programas, no lo será.
#106 Oops! typo! Al revés los tiempos.
#50 Es 0,1 segundos en 10^9 iteraciones. Rehaz tus cálculos.
#114 0,1 segundos son 100ms, rehaz los tuyos.
#57 No se si se puede llamar un fallo. Es mas bien una falta de optimización durante la compilación
#115 Que dos expresiones tan sencillas y equivalentes tengan rendimientos tan diferentes, yo creo que sí se puede considerar un fallo. Pero ya nos metemos en un tema filosófico :-)
#47 si te la pela el i * i como desarrollador, no creo que hayas dado importancia al resto del código, así que imagínate.
#134 Si tanto te importa la diferencia entre i*i respecto a (i*i) entiendo que tú sólo programas en ensamblador aplicaciones de altísimo rendimiento en tiempo real y en la vida te acercas a malignas cosas tales como lenguajes de alto nivel que usen un compilador (o VM) o, herejía, lenguajes interpretados.

Sin acritud.
#67 Tenéis los dos razón.. ambas prácticas son buenas. Y no necesariamente hacer hincapié en una u otra te hace mejor o peor programador.
#149

CC #120

#120 Lee mi post bien. El que no tiene razón es él. Mi comentario dice lo mismo que el tuyo. Las importantes son todas. No sólo lo que dice @jcarlosn que parece que le han hecho ayer analista y se le ha subido a la cabeza...

Analista? Pero qué máquina del tiempo has usado para volver del pasado?

Hace muchos años que no creo en la figura de los analistas, etc. Trabajo en entornos de investigación y en entornos startup, y en ninguno existe la figura del analista.

Mira,…   » ver todo el comentario
#120

No, no tenemos razón los dos. El rendimiento no se obtiene buscando hacks del compilador o esquivando errores del compilador. Si optimizas así, estás ligado a una versión específica del compilador y esos comportamientos no forman parte del contrato del compilador, por lo que van a cambiar.

El rendimiento se obtiene a través de una buena arquitectura, no de hacks.
#146 si, me dedico a optimizar rendimiento entre otras muchas cosa.

Si quieres te explico en que suele consistir , y verás que este tipo de detalles de compilador nunca son importantes.
#148 no hace falta que le faltes al respeto a nadie.

Yo estoy intentando tener este debate se forma respetuosa y constructiva, deja de decir que voy de listo y tonterías así, que no tenemos 15 años y decir ese tipo de cosas no te hace más inteligente no te hace tener razón.

A mí me da igual a lo que te dediques, te he pegado el link por qué has insinuado que no tengo ni idea de esto, en un ad hominem de libro, entonces he decidido compartir cosas que he programado yo para que puedas verlas.…   » ver todo el comentario
12»
comentarios cerrados

menéame