EDICIóN GENERAL

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

#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 cosa, sin casi ningun coste.

Mientras tanto, el programador Junior hace programas de mierda, que no se pueden mantener ni extender según se necesite, pero habitualmente habla del rendimiento y de este tipo de trucos específicos de la plataforma.... Como si ese tipo de cosas, fuesen a cambiar el hecho de que mantener y extender su programa es un infierno, y que cuando aparezcan nuevos truquitos de la plataforma, el no podrá aplicarlos fácilmente a su programa, mientras que los programadores expertos con programas mantenibles y extensibles si podrán.
#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,.....
#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.
#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.
#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...
#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.
#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...
#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.

Cuando dices que ese link no dice nada, se nota que no sabes leer código.

github.com/eyeos/spice-web-client/blob/master/lib/images/lz.js

Eso es una implementación de lz que descomprime 8mb de datos en menos de 10ms. Picado en js. Supera a algunas implementaciones en C de lz, y a prácticamente todas las implementaciones de lz que vas a encontrar en JavaScript.

Con esto no intento demostrar nada, simplemente me defiendo de tus ataques ad hominem continuados.


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...


Y a mi que me importa donde has trabajado? Lo importante es el debate, no que me digas que voy de listo o que me digas que has trabajado en x empresa. Si quieres pásame enlaces a códigos, como he hecho yo, para debatir sobre el tema.

Que trabajes en Vodafone no significa nada.

Llegó el listo, hablándome de MongoDB.... llegó el cuñado...

El cuñao en Menéame suele ser el que más usa esa palabra, y tu caso no es una excepción.

He sacado mongodb a la palestra por qué aunque probablemente no lo sabes, mongodb incluye un motor de map reduce muy potente, que tú puedes utilizar para distribuir tareas de computación intensiva paralelizable entre múltiples computadores .
#152 +1 (que no puedo votar) toda la razon.
#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.
#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...
#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, creo que te has metido en camisa de once varas.

Este es mi blog: jcarlosnorte.com

También te he dado enlaces a códigos de altísimo rendimiento desarrollado por mi.

En serio, creo que hace rato que esta estrategia tuya de llamarme cuñado y menospreciar lo que digo con ataques personales, no está dando resultados.

Si quieres podemos volver al debate del rendimiento, que creo que es mucho más interesante que los ataques personales con los que estás quedando en evidencia.

Te insisto, el rendimiento no consiste en detalles del compilador, salvo en contadas excepciones. El rendimiento es consecuencia estructural de la arquitectura y el diseño del programa, y normalmente incluso cuando optimizas casos, lo haces optimizando contra computadores electromagnéticos modernos con sus limitaciones, no es inteligente optimizar contra el compilador, por qué esos detalles implementativos cambian, y tú programa se vuelve más lento.

Mucha gente se ha pillado ya los dedos con estas cosas en el pasado, y podemos aprender de ello: el rendimiento viene como consecuencia del buen diseño de software, no es consecuencia de detallitos que van a cambiar :-)
#153 joder tio

Me suena tu cara
#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.
#156 ya no ando alli, pues "no encajaba" ;)

* no le hago ni caso al linkedin!!!! xD la verdad !!!!


** En Everis no vas a aprender muchas cosas de calidad, sinceramente. --> Si, aprendi a rechazar la MALA CALIDAD ;)
#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.

menéame