EDICIóN GENERAL

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

#38 en la noticia ya esta en un loop, pero 0,10 segundos puede ser mucho dependiendo de lo que estes calculando. Por ejemplo, en un videojuego, 0,10 segundos en tus cálculos es mucho tiempo.
#44 0.10 en mil millones de iteraciones.
Vamos, lo que viene siendo una diferencia al mover una fresita en un juego de mover frutas de quizá un milisegundo.
Optimiza ahora todos los i*i para pasarlos a (i*i) para ahorrar ese milisegundo...
#47 no se que medidas tomas tu, pero 0,10 no es un miliseguno, es 1/10 segundos o lo que es lo mismo 100 milisegundos. En juego a 30 frames/segundo (33ms cada frame) estamos hablando de 3 frames que pierdes en mover la fresita.
#50 el milisegundo me lo he sacado de la manga. La diferencia de 0.10 segundos se da en 1000 millones de iteraciones. Si tú mueves la fresita cambiando la "x" y la "y" en una cuadrícula 2D de píxeles, y la calculas en un bucle que tenga en cuenta todos los píxeles de la imagen a mover, tendrás unos pocos cientos (miles como mucho) de iteraciones. Por tanto la diferencia será prácticamente despreciable y por eso me saco de la manga el milisegundo en una app. En realidad el movimiento de X e Y lo tendrás parametrizado de algún modo, así que ni tendrás que iterar sobre la matriz de píxeles.

Si tú estás trabajando en un juego en HD para video consola ese desfase quizá, sólo quizá, fuera apreciable en casos muy extremos... pero dudo mucho que lo fuera. Francamente lo dudo... además, nunca hemos visto en videojuegos cosas como que haya monigotes que atraviesen paredes o se queden "atorados" en bordes geométricos...

Y si estás trabajando en determinados proyectos muy, muy concretos que exijan un enorme número de operaciones matemáticas en tiempo real (francamente, no se me ocurre ninguno...) pues tal vez se note.
#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.
#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.
#50 la Fresita no creo que haga mil millones de operaciones aritméticas como la descrita, no es realista y significaría que el juego está muy mal hecho.
#68 Imagina que en vez de mover la fresita, estas moviendo la cámara de un juego 3D, y no tienes una fresita sino un millón, y el calculo es similar pero mas complejo.
#74

la camara no la mueve la cpu, la mueve la gpu, ya que los calculos relacionados con la camara y la perspectiva son altamente paralelizables. Son operaciones de matrices que realiza la gpu en paralelo de forma masiva.

Que en java 2*(i*i) sea mas rapido que 2*i*i es irelevante para la programación de la imnesa mayoría de los programas informáticos, juegos incluídos.
Incluso en el procesado masivo de datos, en la lista de cosas a invertir el tiempo para reducir el coste del procesado, esto estaría por el final, compardo con problemas de I/O, estructuras, etc.

#81

PD: Tú nunca conseguirás mejorar el rendimiento de un programa Java, por lo que parece,.....

Me dedico entre muchas otras cosas, a mejorar el rendimiento de programas informáticos a cambio de dinero.

github.com/eyeos/spice-web-client

Eso es una tarjeta gráfica 2d programada por mi en javascript, alcanza 60fps procesando llamadas similares a gdi (otra api, pero es lo mismo). Algo de rendimiento se, y creeme, 2*i*i vs 2*(i*i) es completamente irrelevante.

stackoverflow.com/questions/43513975/awk-gawk-performance

El problema de ese tipo de posts, es que ese no es el caso de uso de la mayoría de la gente, y para la gente que ese es el caso de uso, hacen las cosas bien. Es ridículo que un programador cree un programa a mano en java para parsear un xml de gigabytes.

Obviamente lo estás haciendo muy mal si acabas haciendo eso. Gestionar grandes volumenes de datos es algo que ya está inventando, y si lo estás reimplementando en tu programa en lugar de utilizar spark+hadoop/mysql/mongo/etcetcetc es que lo estás haciendo muy, muy mal.

Por no hablar del hecho de que las máquinas no escalan verticalmente hasta el infinito, y que esas soluciones ya implementadas de las que te hablo, permiten ser distribuidas horizontalmente, además de resolverte muchos otros problemas, para que tu te centres en hacer algo útil, y no en reinventar la informática básica.

Sobre tu segundo post:

brenocon.com/blog/2009/09/dont-mawk-awk-the-fastest-and-most-elegant-b

Conozco muy bien las bondades de awk, pero que tiene que ver eso con microptimizaciones tipo 2*(i*i) vs 2*i*i que además luego se rompen, y se vuelve mas lenta la que era rápida, y rápida la que era lenta?

En resumen:

1. la mayoría de programadores no tienen que reinventar programas ya inventados de manipulación másiva de datos. Solo necesitan reutilizar servicios/librerias de terceros para ese tipo de operaciones de escala. De hecho, de hacerlo en tu programa seguramente lo estás haciendo mucho peor que los programas ya hechos que hacen eso.

2. Si en tu programa aparece el problema de trabajar con xml de gigas, planteate bien como estás haciendo las cosas. Probablemente lo mas inteligente no sea probar si con 2*i*i ganas unos segundos, sino dejar de hacer las cosas de forma que termines con problemas tan poco reducidos en una sola máquina

3. Cuando tus problemas no sean reducibles, y tengas que afrontar esos volumenes, no solo vas a necesitar programas ya hechos que te ayuden a mover ese volumen de datos de forma eficiente, sino que además vas a necesitar escalar en horizontal, y ahí es donde spark te va a ir muy bien (o mongodb, que tiene un map reduce bastante bueno, aunque casi nadie lo use)

Es decir, que en para un programador medio, 2*i*i vs 2*(i*i) es algo intrascendente en los problemas que tiene que resolver, e incluso para un programador trabajando con grandes volumenes de datos, es igual de intrascendente.
#95 Que la cámara la mueva la GPU no quiere decir que la CPU no haga nada, por ejemplo, calcula colisiones, físicas, IA, lógica en cada draw call. Sino los juegos de ahora, no estarían pidiendo monstruos de 4 nucleos a frecuencias altas.

Yo no estoy discutiendo que este ejemplo se vaya a dar en el mundo real o merezca la pena esa optimización (sinceramente casi nadie programa juegos en Java ya, quitando Android, pero incluso en Android me suena que existe otra api alternativa). Lo que estoy diciendo es que aunque 100ms puedan parecer poco tiempo, es mucho en algunos ámbitos como pueden ser los juegos.
#81 Resumen de #95

El rendimiento importa y yo me dedico a ello, pero nunca el rendimiento depende de microoptimizaciones de maquina virtuales o compiladores, sino de gestiones adecuadas de los datos a nivel conceptual, y adaptar un poco el programa a las capacidades y forma de funcionar de una computadora electromagnética.
#95 a ver majo, que pegues este link -> github.com/eyeos/spice-web-client no dice nada.


En resumen:

1.- Vas de listo
2.- Nadie ha hablado de reinventar
3.- Me lo vas a decir tu que llevo 15 años trabajando en sistemas de tarificacion de movil...... Me lo vas a decir tu que he diseñado el sistema de intercambio de datos de factura de vodafone.. me lo vas a decir tu que he estado en la fusión ono vodafone...


Llegó el listo, hablándome de MongoDB.... llegó el cuñado...
#96 el motor de física no se mueve como respuesta al movimiento de la camara. El motor de física es siempre un bucle aparte, en un thread aparte. Si no fuese así, cuando la escena se redenriza mas rápido, la física se movería mas rápido, lo cual no tiene sentido.

El movimiento de la camara del que hablas en #74 es claramente un mal ejemplo.

Si de lo que hablas es de los cálculos de física de un juego, de nuevo, nunca va a tener millones de entidades en la pantalla, por que antes de tener problemas solventables con 2*(i*i) vs 2*i*i, has petado por miles de otros problemas, como el recolector de basura o mil problemas mas. Por eso, en cualquier engine moderno millones de entidades se gestionan a través de sistemas de partículas acelerados via gpu con physx o gestionados con otro tipo de estrategias aproximativas.

En serio, 2*(i*i) vs 2*i*i es irrelevante para la inmensa mayoría de personas del planeta, programadores incluidos.

Piensa que poner 2*(i*i) por que va mas rápido es hacer un programa a medida del compilador/vm. Y hacer un programa a medida del compilador es algo caro de mantener. El compilador cambia, y para que tu programa siga igual de rápido, tendrás que seguir adaptandolo a medida de cada versión del compilador/vm.

Por eso, la mayoría de programas solo necesitan estar hechos a medida de una computadora digital electromagnética moderna, y no a medida de una versión superespecifica de una máquina virtual o un compilador.

De hecho, al imensa mayoría de programas informáticos no necesitan ni estar hechos a medida de un computador digital electromagnético, sino simplemente mover los datos de forma lógica y con sentido común, y entender bien como gestionar la entrada/salida. Solo con eso, puedes acelerar programas cientos de veces, y ganar una fortuna de ello en consultoría.

Entiendeme, para los que nos dedicamos profesionalmente al rendimiento, esto es irrelevante, para los que se dedican a crear programas normales, es también irrelevante.
#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.
#97 De hecho, a mi juicio, esto sólo es importante para los que hacen compiladores...
#50 Es 0,1 segundos en 10^9 iteraciones. Rehaz tus cálculos.
#114 0,1 segundos son 100ms, rehaz los tuyos.
#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.

menéame