Si y no.
Consideremos primero las optimizaciones arquitectónicas, el paralelismo y demás.
Estos pueden hacer una * gran * diferencia en algo como un sombreador.
- ¿Los estudiantes de ciencias de la computación e ingeniería de software aprenden muchas matemáticas en la universidad?
- Me gustaría escanear mis dibujos dibujados a mano y usar una computadora para trabajar en ellos, ¿qué paquete de software sería mejor para mí?
- ¿Cómo debo prepararme para una entrevista de ingeniero de software sénior en PHP en Big MNC / Company?
- ¿Qué lecciones podrían aprender el gobierno y la legislación de la ingeniería de software?
- ¿Por qué es tan barato externalizar un proyecto de software a la India?
Dado que, en algunos casos como ese, no puede evitar simplemente iterar sobre todo xy todo y en una imagen, la estrategia más importante es optimizar para el caso más común en su “doSomething”.
Entonces, si tiene un sombreador que dibuja un halo de radio de 10 píxeles alrededor de todas las fuentes de luz en una escena, debería desaparecer rápidamente en aquellos casos en los que no hay nada que hacer por un píxel. Por lo tanto, una verificación rápida para ver si está dentro del cuadro delimitador 10 × 10 comprobable trivialmente alrededor de cada fuente de luz será mucho más rápido que calcular más, donde el píxel está fuera del radio para cualquier fuente de luz. Entonces
Ahora ignoremos el paralelismo y tal, y centrémonos en un bucle de un solo hilo.
Y eso nos lleva a la pregunta: ¿es su tarea algo que absolutamente debe realizarse para cada entrada de X por Y? Si la respuesta es no, entonces no puede evitar el código O (N ^ 2). Por ejemplo, si está procesando una imagen y desea oscurecer cada píxel en un 50%, no puede evitar hacer algo con cada píxel. Dos bucles anidados es lo mejor que puedes hacer.
La única optimización que se me ocurre hacer es que si conoces la estructura de tu memoria es tal que todos los píxeles están contiguos en la memoria, entonces puedes simplemente pasar de 0 a X * Y, en lugar de repetir todo X para todo Y.
Ahora, puede argumentar que ahora es O (N) en lugar de O (N ^ 2), pero es un argumento gracioso, ya que en un caso, N es X o Y, y en el otro, N es X * Y. Convertirlo en un solo bucle evita un incremento y una ramificación al final de cada bucle interno, lo que es muy poco probable que sea una mejora significativa del rendimiento en la gran mayoría de los casos. El doble bucle es posiblemente más fácil de leer y de asimilar, así que quizás te quedes con eso.
Pero, ¿qué sucede con esos casos en los que toca solo un pequeño subconjunto, pero prueba todos los valores para ver si necesita hacerlo? Puede valer la pena ver si hay formas de mejorar eso, para reducir las que necesita probar.
Considere dibujar un círculo sin llenar de radio r (digamos, 100 px) en una pantalla con resolución (X, Y), por ejemplo, una pantalla 4K en (3840,2160), alrededor de un punto en (x, y), que podría ser ( 150,150).
Un enfoque de fuerza bruta es recorrer cada píxel en la pantalla y ver si se encuentra en el círculo, y si es así, trazarlo:
foreach X
foreach Y
if ((Xx) ^ 2 + (Yy) ^ 2 está dentro de 1 de r ^ 2)
dibuja un píxel en X, Y.
Esto se repetirá en una pantalla 4K 3840 * 2160 veces, o 8,294,400 veces.
Un enfoque más óptimo pero aún de fuerza bruta es recorrer cada píxel dentro del radio del círculo y, si se encuentra en el círculo, trazarlo:
para testX = 0 a 2 * r
para testY = 0 a 2 * r
if (testX ^ 2 + testY ^ 2 está dentro de 1 de r ^ 2)
dibuje un píxel en x + testX, y + testY.
Esto hará un bucle, con un radio de 100 px, 2r ^ 2 veces o 40,000 veces. Toda una mejora!
Un enfoque más óptimo pero aún de fuerza bruta es darse cuenta de que las cuatro esquinas del círculo son idénticas, en relación con el centro, y simplemente recorrer cada píxel en un cuarto del círculo, y si se encuentra en el círculo, trazarlo, y sus tres puntos reflejados:
para testX = 0 to r
para testY = 0 to r
if (testX ^ 2 + testY ^ 2 está dentro de 1 de r ^ 2)
dibuje un píxel en x + testX, y + testY.
dibuje un píxel en x + testX, y – testY.
dibuje un píxel en x – testX, y + testY.
dibuje un píxel en x – testX, y – testY.
Esto repetirá r ^ 2 veces, o 10,000 veces. Esto es más de 800 veces más rápido que recorrer toda la pantalla.
Esperemos que esto demuestre que nuestra selección de límites para X e Y es importante .
Un enfoque aún más óptimo es darse cuenta de que cada * octavo * de un círculo es simétrico, y que cuando dibuja un círculo, comenzando en la parte inferior y hacia la derecha, durante el primer octavo círculo la pendiente nunca será mayor que 45 grados, por lo que solo trazará un solo píxel para cada X. Y cada Y será la Y anterior, o como máximo 1 mayor. Y luego puedes reflejar eso 8 veces alrededor del círculo.
testX = 0
testY = r
mientras testX <testY
testX ++
dibuje un píxel en x + testX, y + testY.
dibuje un píxel en x + testX, y – testY.
dibuje un píxel en x – testX, y + testY.
dibuje un píxel en x – testX, y – testY.
dibuje un píxel en y + testX, x + testY.
dibuje un píxel en y + testX, x – testY.
dibuje un píxel en y – testX, x + testY.
dibuje un píxel en y – testX, x – testY.
if (testX ^ 2 + testY ^ 2 es mayor que r ^ 2)
irascible-
Esto se repetirá r veces, o 100 veces en nuestro ejemplo, para trazar 800 píxeles. Esta es una mejora de velocidad de 82,944 veces sobre nuestro algoritmo original, e incluso en comparación con la mejor fuerza bruta, es O (r) en lugar de O (r ^ 2).
[Tenga en cuenta que en un sistema con paralelismo mayor que r (para que r ^ 2 iteraciones se ejecuten en r tiempo o mejor), lo anterior podría * no * ser el algoritmo más rápido, ya que cada ciclo se basa en el anterior, por lo que no puede ser en paralelo]
El punto aquí es demostrar que nuestra selección de algoritmos es aún más importante .
Entonces, si puede encontrar algún algoritmo que no use O (N ^ 2) para su aplicación específica, puede obtener grandes mejoras de velocidad, al menos en sistemas lineales.
Algo más que acabo de notar, al releer la pregunta, que será cierto al menos en algunos idiomas, es que el -1 se puede mover fuera del ciclo, evitando que se realice la resta en cada iteración:
para (int i = 0; i <n – 1; i ++) {
para (int j = i + 1; j <n; j ++) {
hacer algo (i, j);
}
}
Convirtiéndose:
límite = n – 1;
para (int i = 0; i <límite; i ++) {
para (int j = i + 1; j <n; j ++) {
hacer algo (i, j);
}
}
También está agregando 1 a i en dos lugares, lo que podría refactorizarse, a costa de la legibilidad, para otra aceleración insignificante:
límite = n – 1;
para (int i = 0; i <límite;) {
para (int j = i; j <límite;) {
hacer algo (++ i, ++ j);
}
}
Ahora, lo que parece estar haciendo, es para cada entrada, iterar sobre todas las entradas posteriores en una lista.
Si su DoSomething es, por ejemplo, imprimir (i * j) para imprimir una tabla de multiplicar, esta doble iteración no se puede evitar.
Pero puede haber casos en los que un algoritmo más óptimo funcione en su lugar.