optimization - programacion - operadores relacionales ejemplos
¿El operador de desigualdad es más rápido que el operador de igualdad? (10)
Sé que esto es una microoptimización, así que lo pido por pura curiosidad.
Lógicamente, un microprocesador no necesita comparar todos los bits de ambos operandos de un operador de igualdad para determinar un resultado "FALSO".
Tenga en cuenta que esto está relacionado con la programación porque afecta la velocidad de ejecución de un programa.
Esto depende de su plataforma, pero en general, funcionará de manera idéntica.
Por ejemplo, en X86, puede ver esto al observar cómo funciona el ensamblaje. Verifique las operaciones de flujo de control de conjunto de X86 : ya sea que esté haciendo igualdad o desigualdad, se hace como 2 operaciones.
Primero, haces una operación CMP (comparación). A continuación, haga una comprobación para ver si la comparación es igual, no igual, etc. Esto solo es verificar los resultados de la comparación, en ambos casos, está haciendo 2 operaciones.
En muchos lenguajes de programación de alto nivel, sin embargo, las cosas son diferentes. Muchos idiomas definen la desigualdad en términos de igualdad: para verificar la desigualdad, realiza la verificación de igualdad y luego una segunda comprobación para ver si es falsa. Esto hace que la igualdad sea (microscópicamente) más rápida en estos idiomas. Muchos idiomas le permiten escribir específicamente ambos, también, pero muchas personas tienden a escribir la desigualdad en términos de igualdad, lo que nuevamente hace que la igualdad, en general, sea ligeramente más rápida.
Hay algunos casos menores en los que puede tener algún efecto.
En procesadores ARM (para la arquitectura del conjunto de instrucciones de 32 bits / no pulgar (ISA)), todas las instrucciones son condicionales. A veces puede salirse con un bucle interno que tiene una sola bifurcación (desde el final hasta el inicio) a pesar de las múltiples condiciones. En unos pocos casos que tienen una comparación lógica ( TEQ ), perturba unos pocos indicadores (afecta negativamente (N) y cero (Z), pero no lleva (C) o desbordamiento (V)), permite que el código peludo evite una instrucción de bifurcación (no tomada )
Por el contrario, IIRC (nunca he programado, pero he visto la salida de un compilador de C hace más de una década) 68000 tiene una instrucción EOR / XOR literal solo para el registro D4. Por lo tanto, una comparación aritmética probablemente sería mejor (aunque aún podría ignorar las banderas extrañas; el punto es que el conjunto de instrucciones es un poco irregular).
Como se mencionó en un póster anterior, la mayor parte de la acción es más alta con memoria, disco, red y latencia del servicio web.
La cantidad de tiempo que toma hacer una comparación como esta generalmente es un ciclo de reloj.
Un procesador de 32 bits hará los 32 bits a la vez; un 64 bits hará 64 bits a la vez.
Si hay un retraso, o pérdida, en la tubería sería porque el operando no está disponible y tuvo que ser recuperado. Ahí es donde está la mayor sobrecarga. Pero eso se habría hecho en un trozo apropiado para la arquitectura del procesador, por lo que aún se habría incluido como una unidad de 32 o 64 bits.
La comparación generalmente se implementa como una resta que ignora el resultado. El sumador en la CPU funcionaría en todos los bits simultáneamente, por lo que esta es una operación de tiempo constante.
La igualdad es solo determinante si el resultado es 0. En x86, hay indicadores que se establecen como resultado de la comparación y la bifurcación se realiza mediante jz o jnz (salto si es cero, salto si no es cero). Entonces no, no habría una diferencia de velocidad real.
Otras plataformas (como ARM e IA64) se comportan de manera similar.
La operación de comparación se produce en el flanco ascendente (o tal vez descendente) de la señal de reloj del microprocesador. Luego, la siguiente operación ocurre en el siguiente ciclo de reloj. Entonces, en términos de velocidad de ejecución, la igualdad y la desigualdad toman la misma cantidad de tiempo para casi todos los procesadores en el mercado hoy en día.
Digo casi porque recuerdo haber leído acerca de algunos procesadores que se suponía que no estaban basados en reloj, sino en tiempo de operación, por lo que si la operación de comparación era más rápida que la operación de agregar, entonces un conjunto de n comparaciones tomaría menos tiempo que n agrega. Pero estoy casi 99% seguro de que fue solo un proyecto de investigación y no un producto comercial :)
Las instrucciones mismas se ejecutarán a la misma velocidad, como sugieren las otras respuestas.
Donde podría encontrar una diferencia sería en predicción de bifurcación o efectos de caché. Esto variará de procesador a procesador y compilador a compilador, por lo que es imposible hacer generalizaciones. Si se encuentra en el nivel donde esto marcaría la diferencia, la única forma de saber es probarlo y medirlo.
Parece que debería leer el Manual de referencia de optimización de arquitecturas Intel 64 e IA-32 .
Busque la "Latencia del oleoducto" y la "Demora del oleoducto" en las instrucciones que utiliza. Baste decir que todo lo que haces con ints toma alrededor de 1 ciclo de reloj para ejecutar (4 mil millones de esos por segundo). Leer los datos de la memoria puede tomar 100-1000 dependiendo de la cantidad de datos con los que está trabajando. Mucho mas importante
Si quisiera plantear esto a una pregunta más general, debería considerar una distribución razonable de respuestas VERDADERAS y FALSAS, y debería considerar una longitud de palabra arbitraria, que incluye más tiempo que un registro.
En los algoritmos de búsqueda (y la clasificación puede considerarse una extensión de la búsqueda) es más común usar operadores como "<" o "<=" que "==". Esto se debe a que la distribución de los resultados del operador "==" tiende a ser muy sesgada hacia "falsa" y, por lo tanto, tienen baja entropía (es decir, bajo rendimiento de la información) por ejecución. Esto significa que tienen que ejecutarse más veces para obtener la misma información: prueba de búsqueda lineal.
En cualquier caso, toman O (longitud de palabra) número de comparaciones de bit, aunque, si la longitud de palabra es <= longitud de registro, las comparaciones tienen lugar en paralelo, posiblemente con una pequeña demora para la propagación de portes. (En realidad, cuando lo pienso, en el caso desigual típico, cualquier comparación puede detenerse en el primer bit desigual, y si la probabilidad de igualdad es lo suficientemente pequeña, eso podría ocurrir bastante temprano).
Un aspecto que todos asumen es que está hablando de instrucciones de nivel de registro. Todos tienen razón, es básicamente discutible en un nivel de CPU de cosas. Y aún más arriba, la mayoría de las operaciones de alto nivel escriben desigualdad como una llamada a la igualdad negada.
Sin embargo, incluso más arriba, usar la optimización del cuestionario funcionaría en ambos sentidos. Es decir, la igualdad se puede escribir tan eficientemente como la desigualdad.
Además, hasta el punto de que las personas se preocupen por las operaciones de ensamblaje, la única diferencia entre un CMP y un SUB es qué banderas están configuradas. Por lo general, se ejecutan con las mismas partes de la máquina, ya que CMP debe devolver indicadores que representen igualdad, menor que y mayor que.
Usualmente, el microprocesador hace la comparación usando puertas eléctricas y no paso a paso así. Comprueba todos los bits a la vez.