EDICIóN GENERAL

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

#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.
#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.
#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 respuestas por debajo del segundo, al menos en los casos habituales.

Nadie discute que 100ms es mucho, lo que estoy diciendo es que para que un juego, api, o programa X vaya rápido o lento, el factor determinante es la arquitectura y como de optimizado está para un computador electromagnético con hardware específico.

2*i*i vs 2+*(i*i) no es lo que hacer ir rápido o lento a un programa informático.
#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.
#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
#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.

menéame