Velocidad de construcciones diferentes en lenguajes de programación (Java/C#/C++/Python/...)

Question

Mi jefe acaba de decirme que aprendió sobre los rápidos algoritmos VB6 de un libro y que la forma más corta de escribir cosas no es necesariamente la más rápida (por ejemplo, los métodos integrados a veces son mucho más lentos que los autoescritos, ya que hacen todo tipo de conversiones de comprobación o unicode que podrían no ser necesarias en su caso).

Ahora me pregunto, ¿hay un sitio web con información sobre construcciones rápidas diferentes en varios idiomas, esp. Java/C#/Python/... (también C++ pero hay tantos compiladores que probablemente difieren mucho).

E.g. ¿hay una diferencia entre

if (a()) b(); 

y

a() && b(); 

Otro ejemplo: se a = a * 4 tal vez compilado para el mismo código que a <<= 2?

Podría probar esto yo mismo, por supuesto, escribir ambos, ejecutarlos 100000 veces y comparar el tiempo de ejecución, pero también me gustaría aprender nuevas formas de escribir cosas, tal vez incluso cosas que no había considerado antes. . ¡Gracias por tus respuestas!

Answer 1

¿hay una diferencia entre if (a()) b(); y a() && b();?

Sí, legibilidad. El primero es mucho más claro sobre la intención.

¿Se compila a = a * 4 con el mismo código que a <<= 2?

Probablemente sí. Pero incluso si terminaran como diferentes instrucciones de la CPU, la diferencia de tiempo sería muy pequeña y dependería de las instrucciones anteriores y posteriores.

Micro-Optimización de la CPU moderna es de

• sobre todo inútil
• muy difícil
• menudo al contrario de lo que solía ser una 'optimización' hace 5 o 10 años.

En conclusión, escriba legible código primero. Cuando tienes un problema de rendimiento, primero perfila y mide.

Debería preocuparse por usar los algoritmos correctos, no leer una colección más de la necesaria, etc. Pero en el nivel instrucción/declaración, hay demasiadas capas (compilador, fluctuación, CPU interconectada) entre usted y lo que realmente se ejecuta .

Answer 2

Yo diría que es probable que sean el tipo de micro-optimizaciones que no marcarían la diferencia y que no valen la pena.

La elección del algoritmo es importante, pero los libros que debería leer deberían ser más como this o this.

Si realmente desea ver si los hacks de bits que ha citado hacen una diferencia, recomendaría obtener primero una línea base de rendimiento en el código que desea cambiar. Realice los cambios y vuelva a medir el rendimiento de la misma manera. Si obtienes un resultado que dice que vale la pena, continúa por todos los medios.

Será mejor que perfile su código y descubra dónde vive la parte más lenta de su código y dónde se realiza la mayor parte del trabajo. Adivinar rara vez funciona al optimizar.

Answer 3

No se moleste con tales microoptimizaciones. No te darán nada en aspecto de rendimiento.

Si tiene un problema de rendimiento, encuentre el cuello de botella y optimícelo.

Answer 4

Siempre haga lo posible para crear un código bueno, limpio y eficiente. Esto puede significar micro optimizaciones (como usar stringbuilder en lugar de agregar cadenas, no usar expresiones regulares si no son necesarias, cosas así, no escuchar a las personas que dicen que no tienen sentido: si escribes código incorrecto y no lo haces). incluso te importa, el JITter no te ayudará) o las optimizaciones de cuello de botella (no selecciones * de una tabla completa, use multihilo). El entorno administrado hará el resto. El uso intensivo de la CPU nunca será tan eficaz como el código no administrado, pero también existen muchas ventajas, por eso a la mayoría de las personas les gusta usarlas. Si quieres piezas de código realmente rápidas, hazlo en C, ensamblaje o hardware. La mayoría de las aplicaciones de negocios actuales no requieren una gran cantidad de CPU, como las GUI, los servicios web, las bases de datos, el uso del disco, todas involucran una gran cantidad de CPU en espera y inactivas.

En cuanto a su pregunta: if (a()) b(); y a() & & b(); son completamente iguales, no hay optimización aquí. a * a y < < 2 no son lo mismo, este último es un * 4.