x> -1 vs x>= 0, hay una diferencia de rendimiento

Depende mucho de la arquitectura subyacente, pero cualquier diferencia será minúscula.

En todo caso, esperaría que (x >= 0) fuera un poco más rápido, ya que la comparación con 0 viene gratis en algunos conjuntos de instrucciones (como ARM).

Por supuesto, cualquier compilador sensible elegirá la mejor implementación independientemente de qué variante esté en su fuente.

Su maestro ha estado leyendo algunos libros muy antiguos. Solía ser el caso con algunas arquitecturas que carecían de la instrucción greater than or equal de que evaluar > requería menos ciclos de máquina que >=, pero estas plataformas son raras en estos días. Sugiero ir para la legibilidad, y el uso de >= 0.

Una preocupación mayor aquí es optimización prematura. Muchos consideran que escribir código legible es más importante que escribir código eficiente[1, 2]. Aplicaría estas optimizaciones como una última etapa en una biblioteca de bajo nivel una vez que se haya demostrado que el diseño funciona.

No deberías estar considerando constantemente hacer optimizaciones minúsculas en tu código a costa de la legibilidad, ya que hará que leer y mantener el código sea más difícil. Si estos las optimizaciones deben tener lugar, abstraerlas en funciones de nivel inferior para que aún quede código que sea más fácil de leer para los humanos.

Como un ejemplo loco, considere a alguien que escribe sus programas en ensamblado a alguien que está dispuesto a renunciar a esa eficiencia adicional y usar Java por sus beneficios en diseño, facilidad de uso y capacidad de mantenimiento.

Como nota al margen, si está utilizando C, tal vez escribir una macro que utiliza el código ligeramente más eficiente es una más factible solución, ya que logrará eficiencia, legibilidad y mantenibilidad más que operaciones dispersas.

Y, por supuesto, las compensaciones de eficiencia y legibilidad dependen de su aplicación. Si ese bucle se ejecuta 10000 veces por segundo, entonces es un posible cuello de botella y es posible que desee invertir tiempo en optimizarlo, pero si se trata de una sola declaración que se llama de vez en cuando, probablemente no vale la pena por la ganancia de minutos.

Sí, hay una diferencia, deberías ver el bytecode.

Para

    if (x >= 0) {
    }

El bytecode es

    ILOAD 1
    IFLT L1

Para

if (x > -1) {
}

El bytecode es

ILOAD 1
ICONST_M1
IF_ICMPLE L3

La versión 1 es más rápida, porque utiliza una operación especial de operando cero

iflt : jump if less than zero 

Pero es posible ver la diferencia solo ejecutando JVM en modo de solo interpretación java -Xint ..., por ejemplo, esta prueba

    int n = 0;       
    for (;;) {
        long t0 = System.currentTimeMillis();
        int j = 0;
        for (int i = 100000000; i >= n; i--) {
            j++;
        }
        System.out.println(System.currentTimeMillis() - t0);
    }

Muestra 690 ms para n = 0 y 760 ms para n = 1. (Usé 1 en lugar de -1 porque es más fácil demostrar, la idea permanece igual)

De hecho, creo que la segunda versión debería ser un poco más rápida, ya que requiere una verificación de un solo bit(suponiendo que compare a cero como muestra arriba). Sin embargo, tales optimizaciones nunca se muestran realmente, ya que la mayoría de los compiladores optimizarán dichas llamadas.

">=" es una operación única, al igual que ">". No 2 operaciones separadas con OR.

Pero >=0 es probablemente más rápido, porque la computadora necesita verificar solo un bit (signo negativo).

Según este maestro > sería un poco más rápido que>=. En este caso era Java, pero según él esto también se aplica para C, c++ y otros idiomas. ¿Hay algo de verdad en esta declaración?

Tu maestro está fundamentalmente equivocado. No solo por qué el azar es que la comparación con 0 puede ser sligly rápido, sino porque este tipo de optimización local son bien hecho por su compilador / intérprete, y se puede ensuciar todo tratando de ayudar. Definitivamente no es una buena cosa para enseñar.

Puedes leer: this or this

Siento irrumpir en esta conversación sobre el rendimiento.

Antes de hacer una digresión, observemos que la JVM tiene instrucciones especiales para manejar no solo cero, sino también constantes del uno al tres. Dicho esto, es probable que la capacidad de la arquitectura para manejar cero se pierda mucho tiempo detrás de más de la optimización del compilador, sino también bytecode a la traducción de código de máquina y tal.

Recuerdo de mis días de lenguaje ensamblador x86 que había instrucciones en el conjunto tanto para mayor que (ja) y mayor que o igual a (jae). Usted haría uno de estos:

; x >= 0
mov ax, [x]
mov bx, 0
cmp ax, bx
jae above

; x > -1
mov ax, [x]
mov bx, -1
cmp ax, bx
ja  above

Estas alternativas toman la misma cantidad de tiempo, porque las instrucciones son idénticas o similares, y consumen un número predecible de ciclos de reloj. Véase, por ejemplo, este. ja y jae pueden verificar un número diferente de registros aritméticos, pero esa verificación está dominada por la necesidad de que la instrucción tome un tiempo predecible. Esto a su vez es necesario para mantener la arquitectura de la CPU manejable.

Pero vine aquí a divagar.

Las respuestas ante mí tienden a ser pertinentes, y también indicativas de que vas a estar en el mismo estadio en lo que respecta al rendimiento, independientemente del enfoque que elijas.

Lo que te deja con la elección basada en otros criterios. Y aquí es donde quería hacer una nota. Al probar índices, prefiera la comprobación de estilo ajustado, principalmente x >= lowerBound, a la x > lowerBound - 1. El argumento está destinado a ser inventado, pero se reduce a la legibilidad, ya que aquí todo lo demás es verdaderamente igual.

Ya que conceptualmente estás probando contra un límite inferior, x >= lowerBound es la prueba canónica que provoca la cognición más adaptada de los lectores de tu código. x + 10 > lowerBound + 9, x - lowerBound >= 0, y x > -1 son todas formas indirectas de probar contra un límite inferior.

Nuevamente, lamento irrumpir, pero sentí que esto era importante más allá de lo académico de las cosas. Siempre pienso en estos términos y deje que el compilador se preocupe por las optimizaciones de minutos que cree que puede obtener de juguetear con las constantes y el rigor de los operadores.

En primer lugar, depende en gran medida de la plataforma de hardware. Para PCS modernos y SOC ARM diferencia se basan principalmente en optimizaciones del compilador. Pero para las CPU sin FPU, las matemáticas firmadas serían un desastre.

Por ejemplo, las CPU simples de 8 bits como Intel 8008, 8048,8051, Zilog Z80, Motorola 6800 o incluso los microcontroladores RISC PIC o Atmel modernos hacen todas las matemáticas a través de ALU con registros de 8 bits y básicamente solo llevan bits de bandera y bits de bandera z (indicador de valor cero). Todas las matemáticas serias se hacen a través de bibliotecas y expresiones

  BYTE x;
  if (x >= 0) 

Definitivamente ganaría, usando instrucciones JZ o JNZ asm sin llamadas a la biblioteca muy costosas.