¿Por qué un movimiento condicional no es vulnerable a un Fallo en la Predicción de Ramas?

Se trata de la tubería de instrucciones . Recuerde, las CPU modernas ejecutan sus instrucciones en una canalización, lo que produce un aumento significativo del rendimiento cuando el flujo de ejecución es predecible por la CPU.

Cmov

    add     eax, ebx
    cmp     eax, 0x10
    cmovne  ebx, ecx
    add     eax, ecx

En el momento en que esa instrucción ASM es evaluada, el resultado de la instrucción CMP anterior aún no se conoce.

Quizás, pero la CPU aún sabe que la instrucción que sigue a cmov se ejecutará inmediatamente después, independientemente del resultado de la instrucción cmp y cmov. Por lo tanto, la siguiente instrucción se puede recuperar/decodificar con seguridad antes de tiempo, lo que no es el caso con las ramas.

La siguiente instrucción podría incluso ejecutarse antes de que lo haga cmov (en mi ejemplo esto sería seguro)

Branch

    add     eax, ebx
    cmp     eax, 0x10
    je      .skip
    mov     ebx, ecx
.skip:
    add     eax, ecx

En este caso, cuando el decodificador de la CPU vea je .skip tendrá que elegir si continuar prefetching / decoding instrucciones ya sea 1) de la siguiente instrucción, o 2) desde el objetivo de salto. La CPU adivinará que esta rama condicional no sucederá, por lo que la siguiente instrucción mov ebx, ecx irá a la canalización.

Un par de ciclos más tarde, se ejecuta el je .skip y se toma la rama. Oh, mierda! Nuestro pipeline ahora contiene basura aleatoria que nunca debería ser ejecutada. La CPU tiene que vaciar todas sus instrucciones en caché y empezar de nuevo desde .skip:.

Esa es la penalización de rendimiento de ramas mal interpretadas, que nunca puede suceder con cmov ya que no altera el flujo de ejecución.

De hecho, el resultado puede aún no ser conocido, pero si otras circunstancias lo permiten (en particular, la cadena de dependencias) la cpu puede reordenar y ejecutar instrucciones siguiendo el cmov. Dado que no hay ramificación, esas instrucciones deben evaluarse en cualquier caso.

Considere este ejemplo:

cmoveq edx, eax
add ecx, ebx
mov eax, [ecx]

Las dos instrucciones que siguen a cmov no dependen del resultado de la cmov, por lo que pueden ejecutarse incluso mientras la cmov está pendiente (esto se llama ejecución fuera de orden ). Incluso si no se pueden ejecutar, todavía se pueden recuperar y decodificar.

Una versión ramificada podría ser:

    jne skip
    mov edx, eax
skip:
    add ecx, ebx
    mov eax, [ecx]

El problema aquí es que el flujo de control está cambiando y la cpu no es lo suficientemente inteligente como para ver que podría simplemente "insertar" la instrucción omitida mov si la rama se malinterpreta como tomada - en su lugar, tira todo lo que hizo después de la rama, y se reinicia desde cero. Aquí es donde viene el castigo.

Usted debe leer estos. Con Fog + Intel, simplemente busque CMOV.

La crítica de Linus Torvald a CMOV circa 2007
Comparación de las microarquitecturas de Agner Fog
Manual de referencia de Optimización de arquitecturas Intel® 64 e IA-32

Respuesta corta, las predicciones correctas son 'gratis', mientras que los errores de interpretación condicionales pueden costar 14-20 ciclos en Haswell. Sin embargo, CMOV nunca es libre. Aún así creo que CMOV es mucho mejor ahora que cuando Torvalds despotricó. No hay una sola respuesta correcta para todos los tiempos en todos los procesadores.

Tengo esta ilustración de [Peter Puschner et al.] diapositiva que explica cómo se transforma en código de ruta única, y acelerar la ejecución.