TECNOLOGíA, INTERNET, JUEGOS
250 meneos
7270 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
100 150 6 K 122
100 150 6 K 122
Comentarios destacados:                                  
#13 #2 #5 #3 #4 La diferencia en tiempo de ejecucuion puede ser de 0,10 segundos ahora bien en un proceso iterativo que recorra mierda esos 0,1 segundos igual son 45 minutos de proceso en vacio del cpd y ahi si que se empieza a notar la cosa.

No subestimeis las bajadas de rendimiento para estas movidas, para una app para usuario normal claro que te la pela, para procesos que corren en backend en job con miles de operaciones igual no.

#1 Y usted, haga el favor de reciclarse en un lenguaje ya y dejar de insultarlos todos xD
porque java apesta

#killJava
#1 antes me caías bien,pero veo que eres un tio con un gusto cuestionable.
#7 PHP y JavaScript te envían un abrazo.
#12 i.redd.it/3w74rvpac2911.jpg
Nada mas que añadir.
#15 demasiado subjetivo xD. Está hecho por alguien que ama Java, se ve.
#25 Java es para dummies,conviértete,ven al lado oscuro.
#15 No soy informatico y de lenguajes se mas bien poco. Pero, y lo que me he reido :->
#15 Lo que tu quieras con PHP pero es uno de los lenguajes mas utilizados para desarrollo web. Los CMS mas populares ya sea wordpress, drupal, joomla o para ecommerce prestashop, magento estan desarrollados en php
#32 wordpress tiene mas agujeros de seguridad que un queso gruyere.
Para ERPS Java->todo.
PHP esta muy bien para empresas medianas y pequeñas,pero las grandes van a Java,ya que les da igual las pelas que cuesten los servidores,se ahorran mucho con lo fácil que es implementar el proyecto en Java.
#37 Django ... :-D
#65 buena pelicula
#37 Como Facebook, la wikipedia, yahoo.... no sé, cosas de empresas pequeñas y medianas.
#71 facebook usa una extensión de Php llamada hack.
De yahoo ni idea de donde lo has leido,es dificil encontrar información de algo que esta muerto.
#37 Discrepo
#32 Que sepas que configurar un CMS y tocar un poco las plantillas no se puede llamar desarrollo web.
#15 Falta la version en ASM, donde cambia una A por una B y acaba matando a la princesa y follandose al dragon.
#98 hay muchísimas en gittheprincess,esta me marco en la uni,es una versión algo mas antigua.
#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
#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.
#15 Yo sí voy a añadir algo (los "=" se ven un poco mal)  media
#126 No, no falta. Monty Python sale perfectamente referenciado en la primera viñeta de PHP :troll:

cc/ #15  media
#12 Los mayores no usamos juguetes.
#2 #5 #3 #4 La diferencia en tiempo de ejecucuion puede ser de 0,10 segundos ahora bien en un proceso iterativo que recorra mierda esos 0,1 segundos igual son 45 minutos de proceso en vacio del cpd y ahi si que se empieza a notar la cosa.

No subestimeis las bajadas de rendimiento para estas movidas, para una app para usuario normal claro que te la pela, para procesos que corren en backend en job con miles de operaciones igual no.

#1 Y usted, haga el favor de reciclarse en un lenguaje ya y dejar de insultarlos todos xD
#13 me he liado con REACT al final jajaja
#14 Tiene cojones que se queje la reinona de java y esté mirando javascript xD
#17 homeeeeeeeeee, no tiene nada que ver uno con el otro eh!
#24 Lo se pero amos quejarse de java desde otro lenguaje de tipado debil xD
#29 cariño me sumo a las modas, y la moda ahora es odiar Java. Pues no se hable más, odio Java.

jajaajaj
#29 Otro? ... Java no es de tipado debil.
#17 #24 yo con el puto javascript me pillé vicio..... xD llamame raro,....
#82 Eso está muy bien, un primer paso es reconocerlo, pero no debería quedarse ahí y deberías buscar ayuda.
#85 Si, lo dejé de lado y me he vuelto a mis grandes integraciones (Java / C++ ) que me va más la marcha de millones de registros, horas de proceso, y esas cosas... Lo del javascripy esta mas que bien para fumar unos canutitos en casa y "disfrutar"

xD

PD: Compré hace mucho el dominio "JacaScript.net" ;)
#86 "JacaScript.net" ...

Si esto no es motivo de strike por incitacion al odio, yo ya no entiendo esta web

xD
#88 mira que cerca estan la v y la c

PD: Soy de jaca
#17 me imagino que #14 lo dira porque javascript a palo seco es mas guarro que una peli porno alemana de enanos cagandose en el pecho. Con estas librerias como que se queda el lenguaje un poco mas apañado, aunque siga siendo el hermano feo de frankenstein. xD
#75 Creo que le debes un poco de respeto a la coprofagia acondroplasica germana, un género lleno de matices y sutilezas que no se merece tal desprecio
#11 Corrigiendo mi comentario y el tuyo, la diferencia la mide al correr un programa que hace la operación mil millones de veces. Vamos, que para cada iteración viene siendo bastante desdeñable. Eso no quita, como dice #13, que sea una diferencia en un programa muy sencillo, y que en temas complicados sí sea apreciable.
#1 #13 a ver, que estamos hablando de 0.10 segundos en 1000000000 iteraciones, el tiempo de 1000 millones de multiplicaciones
#13 yeah ... .asi me gusta baby. U think clearly.

PD: #1 cariño, si no te justa por el java, pues por el awk.
#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.
#1 programa en Rails!!!
#1 Ya me jodería odiar el lenguaje que se ha convertido en el estándar de la industria....
#61 se ha convertido ahora que deja de serlo...
#1 Aplaudo su detallada argumentación
#1 mis dieses.
Siempre me lo habría preguntado pero nunca me atreví a hacerlo. Gracias.

Si esto no llega a portada yo ya no sé que va a llegar.
#2 ya es hora de que la sociedad despierte y coja el toro por lo cuernos. A los niños no se les puede seguir contando historias edulcoradas de cigüeñas que vienen de París. No podemos seguir haciendo como si aquí no pasase nada mientras 2*i*i tarda más que 2*(i*i) y miramos hipócritamente hacia otro lado mientras egoistamente nos dedicamos a lo nuestro sin preocuparnos por el vecino.
#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.
#2 tortilla de patatas con grafeno y cebolla dentro de un opel corsa,eso no fallaría nunca.
#2 que esto llegue a portada significa que menéname son "machos" informáticos en un 80% xD
Muy bueno. El tener conocimiento de estas cosas, y ahorrar varios segundos de ejecución en un programa, diferencia de un programador de un buen programador.
#3 La diferencia de tiempo de ejecución es de 0,10 segundos; eso no es ser un buen programador, es tener demasiado tiempo libre.
#4 Despues nos quejamos de los recursos que requieren ciertos juegos y que a pesar de tener un pepino de maquina aun hay lag. Seran 0.1 seg aqui, pero solo en esta linea de codigo, ahora piensa en una aplicacion con 100.000 lineas de codigo.
#6 o metido en un loop.
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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...
#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.
#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.
#100 No, no depende, no. ...

Pues menos mal que te dedicas a optimizar rendimiento...
#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...
#50 Es 0,1 segundos en 10^9 iteraciones. Rehaz tus cálculos.
#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.
#4 Bueno, si la operación está en un bucle o una consulta tocha, se va acumulando esa mejora. Y eso sí es de buen programador. Si los nuevos programadores optimizasen como los del principio, igual no habría que estar multiplicando la potencia de las máquinas cada 2 años.
#9 Si tienes que hacer semejante número de operaciones en bucle como para notar este tipo de cosas, me da a mí que el buen programador buscaría una herramienta mejor para hacerlo que a pelo en Java. Algo tipo CUDA, o alguna librería para cálculo masivo.
#4 quizás esta de mantenimiento,entonces tiene tiempo de sobra para hacer eso,si se descuenta algo de tiempo de su hora de café(8 horas al día)
#4 No es una diferencia de 0,05 segundos, es una diferencia del 8% del tiempo.

Si esa operación se ejecuta 1.000 veces a lo largo de un programa, es una diferencia considerable.
#4 Todo depende de qué estés progamando, y de cuantas veces realices operaciones similares. :-D
#4 Depende de lo que programes.

Yo estoy ahora mismo con aplicaciones donde hay un tiempo de ciclo de 20ms.
100 milisegundos es una aplicación que no funciona.
#4 0,10 segundos es una burrada y no, es menos.
#4 0,10 segundos en un algoritmo iterativo complejo con muchos cálculos, se pueden convertir en algunos segundos ;).

0,10 segundos en un calculo en tiempo real necesario en un videojuego es ralentización segura.
#4 en.wikipedia.org/wiki/Fast_inverse_square_root

float Q_rsqrt( float number )
{
 long i;
 float x2, y;
 const float threehalfs = 1.5F;

 x2 = number * 0.5F;
 y = number;
 i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
 y = * ( float * ) &i;
 y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

 return y;
}

Esa ñapa permitió que quake 3 funcionara en los pcs de la época. No subestimes el incremento de rendimiento que te da acelerar una simple función
#51 No permitió que funcionase, permitió liberar el código sin problemas legales, porque el algoritmo "clásico" tenía una patente en vigor.

Lo cual demuestra que John Carmack es el puto amo, básicamente.
#52 Carmack podría haber usado 1/sqrt() clásico. los ordenadores x86 tiene una instrucción dedicada para la raiz cuadrada, pero es mucho más lenta que un desplazamiento binario, una resta y un par de multiplicaciones. Aunque es una aproximación, con ello ganaban rendimiento. El hecho de que la ñapa se haga con ese código o con otro por temas de patentes no es el punto de mi comentario. A lo que iba es que ganando rendimiento en una sola función que se usa millones de veces puede tener un incremento de rendimiento bestial en la aplicación final
#52 No lo escribió él. Pero me parece muy elegante la solución.
#4 Eres un mal programador.
#4 Seguro que trabajas haciendo webs para algun organismo público, eh gañan!
#3 Totalmente en desacuerdo. Aquí el mal programador sería en tal caso el que hizo el compilador, ya que no existe ninguna justificación lógica para que 2 * (i * i) genere distinto bytecode que 2 * i * i.
#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
#3 Teniendo en cuenta que es un fallo de la máquina virtual, más que dedicar tiempo a optimizar esto lo eficiente es reportarlo, y esperar a la siguiente versión de la máquina virtual que arregle el problema.
#57 No se si se puede llamar un fallo. Es mas bien una falta de optimización durante la compilación
#3 Hombre, este ejemplo quizás sea un poco excesivo, pero sí que ves mala praxis a diario. Gente que declara variables dentro de bucles que se ejecutan miles de veces :ffu: o que concatenan cadenas enormes con el operador +=
#62
Int valor = 0;
a=getValorFromservicio();
if (a==1) {
valor = 1;
}
if(a==2)
{
valor = 2
}
if(a==3)
{
Valor=3
}

if (a!=1 && a!=2 && a!=3)
{
a=0;
}



¿Te gusta eh?


C
#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
#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
#3 me dedico a esta industria hace mucho tiempo, y este tipo de cosas no solo no diferencia a un buen programador de un mal programador, sino que suele ser al revés.

Los buenos programadores saben que lo más importante es estructurar el programa de forma correcta, y que como consecuencia de una buena estructura, se obtiene mayor rendimiento, escalabilidad y seguridad, simplemente por qué un programa estructurado correctamente, cambiar cosas es muy fácil, y donde ponia 2*I*I mañana pone otra…   » ver todo el comentario
#67 Nada, el performance no importa

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

O el elegir correctamente una distribucion de un lenguaje u otra, tampoco

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

Nada.... tu sigue a lo tuyo.....


Para mi un mal programador es el que cree que una cosa es más importante que la otra y no valora que todas estaán conectadas y afectan al resultado final....

PD: Tú nunca conseguirás mejorar el rendimiento de un programa Java, por lo que parece,.....
#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.
He cambiado 2 * i * i por 2* (i*i) en mi aplicación y ahora consume un 20% menos de CPU, un 25% de memoria y sin más, acaba de ganar a Alpha 0 al ajedrez mientras conducía un Tesla camino a Venus.

#lo_del_i*i
#20 He cambiado 2 * i * i por 2* (i*i) en mi aplicación y ahora mis relaciones con las mujeres son mucho más fructiferas, mi cabello tiene más fuerza y volumen y resucitó a mi gatito. Nunca podré agradecer del todo esta mejora.
#20 y que tal iria esta? > ||*|| mas rápido no se, pero igual tu aplicación se independiza en cuanto no te des cuenta xD
Me encanta el olor a Meneame ClassicTM por la mañana. :-)
#22 hay que revindicarlo más. Eso, o seguir con noticias de VOX
yo diria que porque multiplicar 2i por i es mas lento que i*i y desplazar un bit a la izquierda.
#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.
Basicamente porque multiplicar por 2 es extremadamente fácil y cuanto más grande sea el número a multiplicar por 2 más tiempo ahorrará.
Supongamos que multiplicar x2 es un 10% más rápido que multiplicar por cualquier otro número.
La multiplicación tiene un coste (hay bastantes mov, push cambios de registro etc...)
Si yo multiplico 2x500x500 primero hago 2x500=1000 y luego 1000*500 Nos queda que el numéro más grande no se ultiplica por dos
En cambio si yo multiplico (500x500) tengo 250000 y luego lo multiplico por 2 por lo que la operación más costosa la hago con el multiplicador más fácil para la máquina.
#30 Salvo que te estés saliendo de rango y necesites un tipo más gordo, cuesta el mismo tiempo/recursos multiplicar 2x2 que 2.000.000x2.000.000. Los circuitos no funcionan así.
#55 Cuando multiplicas por 2 solo haces 1 mov ;)

1 --> 1 * 2 --> 10
2 --> 10 *2 --> 100
3--> 11 * 2 --> 110
4-->100 *2 --> 1000
#58 Sí, multiplicar por dos se resuelve con un desplazamiento, pero en este caso esa no puede ser la solución, ya que, con paréntesis o sin ellos, tienes que hacer las mismas operaciones: un desplazamiento y una multiplicación. Y la multiplicación tarda lo mismo, sea con números grandes o pequeños.

Al final, la respuesta está en el propio enlace: simplemente el optimizador de código es mierder y en un caso no optimiza lo suficiente. Probablemente en alguna versión posterior lo mejoren, y se resolverá el tema.
#58 #55 Y si no recuerdo mal la instrucción era shl o algo así, la que no rota (hace muchos años ya que hice ensamblador en ingeniería informática).
#64 shl (shift left) desplaza a la izquierda y por tanto multiplica por dos, y shr desplaza a la derecha y divide por dos. Puedes multiplicar dividir por una potencia de 2 (2, 4, 8...) a coste casi cero. En cambio, multiplicar son unos cuantos ciclos.

Obviamente el tema sólo vale para enteros, para floats y compañía no cuela el truqui.
#55 No tiene por qué costar el mismo tiempo. Dependerá de la capacidad de representación de números que tenga tu procesador, de la memoria que tenga... etc... No todos los circuitos funcionan igual.... ni todos los procesadores calculan mediante los mismos algoritmos...
#84 Ya he dicho que si te sales del rango la cosa puede cambiar, pero aquí hablamos de un int que, en Java, es un mundano número entero de 32 bits. Dos multiplicaciones de dos números de 32 bits tardan exactamente lo mismo, independientemente del valor, en cualquier procesador desde el 386 hasta un Core i9.

Otra cosa es que hablemos de números muy tochos, en plan BigInteger y tal, que ya son objetos y la cosa puede depender de la implementación. Pero con tipos básicos no hay diferencia, al circuito le da igual si de esos 32 bits usas todos o sólo unos pocos. Él multiplica todos igual, en paralelo.
#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
# su gusto está fuera de duda...salvo por esa manía de repudiar a Charlize Theron...por lo demás de acuerdo en todo.
Me encanta como todos los comentarios intentan encontrarle una razón y todos se equivocan porque no se han leído la respuesta de stackoverflow.
Desde luego da la sensación que la mayoría aquí para solucionar sus problemas entra en stackoverflow, copian y pegan la solución y a ver si funciona, total para qué leer primero de qué va la solución.
Lo gracioso, o no tanto, es como el programa simplemente compilado en C puede ir 5 veces más rapido, y sin tener que cargar una maquina virtual ni implementar un jit.
#40 viendo el assembly monstruoso que genera el JIT para esa chorrada (ver respuesta de stackoverflow) te quedas corto con 5 veces.
En el assembly del C para esa operación serán 2 o 3 opcodes.
#40 En C en ambos casos se generan los siguientes opcodes de 80x86 (gcc 8 con -O3 -m64)

imul edi, edi
lea eax, [rdi+rdi]


Punto final.
Viene al caso  media
¿Porque Java es una puta mierda de lenguaje?
#46 Qué lenguaje no lo es?
Se me ocurren motivos por lo que casi todos los lenguajes más usados son una puta mierda.
También se me ocurren motivos por los que casi todos son estupendos.

P.D: No me gusta java, pero decir que es una puta mierda es una gilipollez.
#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
¿Nadie pregunta porqué multiplicar por 2 cuando puedes shiftar un cero por la derecha y ser más eficiente?
El problema viene cuando el servidor de turno (tomcat, ihs, was) empieza a devorar recursos.

Entonces si dices, f*ck java x''DDDD
java como plataforma o como lenguaje?
Probablemente al factorizar la multiplicación, el JIT optimice mejor el desenroscado del bucle en el bytecode al tener un stack separado que no necesita preservar.
Nadie dice nada del PUTO AMO que da la respuesta en stackoverflow ?
Llevo años pensando que en informática se estudia muy poco acerca del funcionamiento interno de los lenguajes de programación, y me parece preocupante la gran sorpresa que este problema supone, ya que es solo la punta del iceberg de un problema de verdad importante.
Estudio ingeniería de obras públicas y mis conocimientos de programación son ridículos, puedo programar más o menos bien en Fortran90, y un poco en C, pero tanto si hago desde una hoja de excell hasta un programa propio, ensayo…   » ver todo el comentario
#93 No se, creo que te estás liando un poco.
Lo que aquí se está exponiendo es la ligera mejora de rendimiento que supone factorizar la multiplicación del ejemplo propuesto dentro de un bucle en Java. Lo cual se debe probablemente a una mayor optimización del bytecode por parte del JIT al hacer el desenroscado del bucle (loop unrolling) en el primer caso, quizá por tener un stack separado como resultado de dicha factorización y no tener que hacer tantas llamadas a stack para conservar los resultados intermedios que generaría 2 * i * i
#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?
«12

menéame