¿Puede el MOV de x86 ser realmente "gratis"? ¿Por qué no puedo reproducir esto en absoluto?

assembly cpu-registers

Question

Sigo viendo que las personas afirman que la instrucción MOV puede ser gratuita en x86, debido al cambio de nombre del registro.

Por mi vida, no puedo verificar esto en un solo caso de prueba. Cada caso de prueba que intento lo desacredita.

Por ejemplo, aquí está el código que estoy compilando con Visual C ++:

#include <limits.h>
#include <stdio.h>
#include <time.h>

int main(void)
{
    unsigned int k, l, j;
    clock_t tstart = clock();
    for (k = 0, j = 0, l = 0; j < UINT_MAX; ++j)
    {
        ++k;
        k = j;     // <-- comment out this line to remove the MOV instruction
        l += j;
    }
    fprintf(stderr, "%d ms/n", (int)((clock() - tstart) * 1000 / CLOCKS_PER_SEC));
    fflush(stderr);
    return (int)(k + j + l);
}

Esto produce el siguiente código de ensamblaje para el bucle (siéntase libre de producir esto como desee; obviamente no necesita Visual C ++):

LOOP:
    add edi,esi
    mov ebx,esi
    inc esi
    cmp esi,FFFFFFFFh
    jc  LOOP

Ahora ejecuto este programa varias veces, y observo una diferencia bastante consistente del 2% cuando se elimina la instrucción MOV:

Without MOV      With MOV
  1303 ms         1358 ms
  1324 ms         1363 ms
  1310 ms         1345 ms
  1304 ms         1343 ms
  1309 ms         1334 ms
  1312 ms         1336 ms
  1320 ms         1311 ms
  1302 ms         1350 ms
  1319 ms         1339 ms
  1324 ms         1338 ms

Entonces, ¿qué da? ¿Por qué el MOV no es "gratis"? ¿Es este ciclo demasiado complicado para x86?
¿Hay un solo ejemplo por ahí que pueda demostrar que MOV es gratis como la gente dice?
Si es así, ¿qué es? Y si no, ¿por qué todos afirman que MOV es gratis?

Answer 1

Aquí hay dos pequeñas pruebas que creo que muestran de manera concluyente evidencia de eliminación de mov:

__loop1:
    add edx, 1
    add edx, 1
    add ecx, 1
    jnc __loop1

versus

__loop2:
    mov eax, edx
    add eax, 1
    mov edx, eax
    add edx, 1
    add ecx, 1
    jnc __loop2

Si mov agrega un ciclo a una cadena de dependencia, se esperaría que la segunda versión tome alrededor de 4 ciclos por iteración. En mi Haswell, ambos toman alrededor de 2 ciclos por iteración, lo que no puede suceder sin la eliminación de mov.

Answer 2

El rendimiento del bucle en la pregunta no depende de la latencia de MOV, o (en Haswell) del beneficio de no usar una unidad de ejecución.

El bucle sigue siendo solo 4 uops para que el front-end se emita en el núcleo fuera de servicio. ( mov todavía tiene que ser rastreado por el núcleo fuera de orden, incluso si no necesita una unidad de ejecución, pero cmp/jc fusiona en un solo uop).

Las CPU de Intel desde Core2 han tenido un ancho de problema de 4 uops por reloj, por lo que el mov no impide que se ejecute a (casi) un iter por reloj en Haswell. También funcionaría a una por hora en Ivybridge (con eliminación de mov), pero no en Sandybridge (sin eliminación de mov). En SnB, sería aproximadamente un iter por 1.333c ciclos, con un cuello de botella en el rendimiento de ALU porque el mov siempre necesitaría uno . (SnB / IvB tienen solo tres puertos ALU, mientras que Haswell tiene cuatro).

Tenga en cuenta que el manejo especial en la etapa de cambio de nombre ha sido algo para x87 FXCHG (intercambiar st0 con st0 ) durante mucho más tiempo que MOV. Agner Fog enumera FXCHG como latencia 0 en PPro / PII / PIII (núcleo P6 de primera generación).

El bucle en la pregunta tiene dos cadenas de dependencia entrelazadas (el add edi,esi depende del EDI y del contador de bucles ESI), lo que lo hace más sensible a la programación imperfecta. Una ralentización del 2% frente a la predicción teórica debido a instrucciones aparentemente no relacionadas no es inusual, y pequeñas variaciones en el orden de las instrucciones pueden hacer este tipo de diferencia. Para ejecutarse exactamente a 1c por iter, cada ciclo necesita ejecutar un INC y un ADD. Dado que todos los INC y ADD dependen de la iteración anterior, la ejecución fuera de orden no puede ponerse al día ejecutando dos en un solo ciclo. Peor aún, el ADD depende del INC en el ciclo anterior, que es lo que quise decir con "enclavamiento", por lo que perder un ciclo en la cadena de depósito INC también detiene la cadena de depósito ADD.

Además, las ramas tomadas de forma prevista solo pueden ejecutarse en el puerto 6, por lo que cualquier ciclo en el que el puerto 6 no ejecute un cmp / jc es un ciclo de rendimiento perdido . Esto sucede cada vez que un INC o ADD roba un ciclo en el puerto 6 en lugar de ejecutarse en los puertos 0, 1 o 5. IDK si este es el culpable, o si el problema es perder ciclos en las cadenas de depósito INC / ADD. algunos de los dos.

Agregar el MOV adicional no agrega ninguna presión en el puerto de ejecución, suponiendo que se elimine al 100%, pero evita que el front-end se ejecute por delante del núcleo de ejecución . (Solo 3 de los 4 uops en el bucle necesitan una unidad de ejecución, y su CPU Haswell puede ejecutar INC y ADD en cualquiera de sus 4 puertos ALU: 0, 1, 5 y 6. Por lo tanto, los cuellos de botella son:

• El rendimiento máximo de front-end de 4 uops por reloj. (El bucle sin MOV es de solo 3 uops, por lo que el front-end puede ejecutarse por delante).
• rendimiento de rama tomada de uno por reloj.
• la cadena de dependencia que implica esi (latencia INC de 1 por reloj)
• la cadena de dependencia que implica edi (ADD latencia de 1 por reloj, y también depende del INC de la iteración anterior)

Sin el MOV, el front-end puede emitir los tres uops del bucle a 4 por reloj hasta que el núcleo fuera de servicio esté lleno. (AFAICT, "desenrolla" pequeños bucles en el bucle-buffer (Loop Stream Detector: LSD), por lo que un bucle con ABC uops puede emitirse en un patrón ABCA BCAB CABC ... El contador de lsd.cycles_4_uops para lsd.cycles_4_uops confirma que en su mayoría emite en grupos de 4 cuando emite uops).

Las CPU de Intel asignan uops a los puertos a medida que se emiten en el núcleo fuera de servicio . La decisión se basa en contadores que rastrean cuántos uops para cada puerto ya están en el planificador (también conocido como Reservation Station, RS). Cuando hay muchos Uops en el RS esperando para ejecutarse, esto funciona bien y generalmente debería evitar programar INC o ADD en el puerto 6. Y supongo que también evita programar el INC y ADD de modo que se pierda tiempo de cualquiera de esas cadenas de dep. Pero si el RS está vacío o casi vacío, los contadores no impedirán que un ADD o INC robe un ciclo en el puerto 6.

Pensé que estaba en algo aquí, pero cualquier programación subóptima debería permitir que el front-end se ponga al día y mantenga el back-end lleno. No creo que debamos esperar que el front-end provoque suficientes burbujas en la tubería para explicar una caída del 2% por debajo del rendimiento máximo, ya que el pequeño bucle debería ejecutarse desde el búfer del bucle a un rendimiento muy constante de 4 por reloj. Tal vez hay algo más pasando.

Un verdadero ejemplo del beneficio de la eliminación de mov .

lea para construir un bucle que solo tiene un mov por reloj, creando una demostración perfecta donde la eliminación de MOV tiene éxito al 100%, o el 0% del tiempo con mov same,same para demostrar el cuello de botella de latencia que produce.

Dado que el dec/jnz macro-fusionado es parte de la cadena de dependencia que involucra el contador de bucles, la programación imperfecta no puede retrasarlo. Esto es diferente del caso en el que cmp/jc "se bifurca" de la cadena de dependencia de la ruta crítica en cada iteración.

_start:
    mov     ecx, 2000000000 ; each iteration decrements by 2, so this is 1G iters
align 16  ; really align 32 makes more sense in case the uop-cache comes into play, but alignment is actually irrelevant for loops that fit in the loop buffer.
.loop:
    mov eax, ecx
    lea ecx, [rax-1]    ; we vary these two instructions

    dec ecx             ; dec/jnz macro-fuses into one uop in the decoders, on Intel
    jnz .loop

.end:
    xor edi,edi    ; edi=0
    mov eax,231    ; __NR_exit_group from /usr/include/asm/unistd_64.h
    syscall        ; sys_exit_group(0)

En la familia Intel SnB, LEA con uno o dos componentes en el modo de direccionamiento se ejecuta con latencia 1c (consulte http://agner.org/optimize/ y otros enlaces en el wiki de etiquetas x86 ).

Construí y ejecuté esto como un binario estático en Linux, por lo que los contadores de rendimiento del espacio de usuario para todo el proceso miden solo el bucle con una carga general insignificante de inicio / apagado. (la perf stat es realmente fácil en comparación con poner consultas de contador de rendimiento en el programa en sí)

$ yasm -felf64 -Worphan-labels -gdwarf2 mov-elimination.asm && ld -o mov-elimination mov-elimination.o &&
  objdump -Mintel -drwC mov-elimination &&
  taskset -c 1 ocperf.py stat -etask-clock,context-switches,page-faults,cycles,instructions,branches,uops_issued.any,uops_executed.thread  -r2 ./mov-elimination

Disassembly of section .text:

00000000004000b0 <_start>:
  4000b0:       b9 00 94 35 77          mov    ecx,0x77359400
  4000b5:       66 66 2e 0f 1f 84 00 00 00 00 00        data16 nop WORD PTR cs:[rax+rax*1+0x0]

00000000004000c0 <_start.loop>:
  4000c0:       89 c8                   mov    eax,ecx
  4000c2:       8d 48 ff                lea    ecx,[rax-0x1]
  4000c5:       ff c9                   dec    ecx
  4000c7:       75 f7                   jne    4000c0 <_start.loop>

00000000004000c9 <_start.end>:
  4000c9:       31 ff                   xor    edi,edi
  4000cb:       b8 e7 00 00 00          mov    eax,0xe7
  4000d0:       0f 05                   syscall 

perf stat -etask-clock,context-switches,page-faults,cycles,instructions,branches,cpu/event=0xe,umask=0x1,name=uops_issued_any/,cpu/event=0xb1,umask=0x1,name=uops_executed_thread/ -r2 ./mov-elimination

 Performance counter stats for ''./mov-elimination'' (2 runs):

    513.242841      task-clock:u (msec)       #    1.000 CPUs utilized    ( +-  0.05% )
             0      context-switches:u        #    0.000 K/sec                  
             1      page-faults:u             #    0.002 K/sec                  
 2,000,111,934      cycles:u                  #    3.897 GHz              ( +-  0.00% )
 4,000,000,161      instructions:u            #    2.00  insn per cycle   ( +-  0.00% )
 1,000,000,157      branches:u                # 1948.396 M/sec            ( +-  0.00% )
 3,000,058,589      uops_issued_any:u         # 5845.300 M/sec            ( +-  0.00% )
 2,000,037,900      uops_executed_thread:u    # 3896.865 M/sec            ( +-  0.00% )

   0.513402352 seconds time elapsed                                          ( +-  0.05% )

Como se esperaba, el ciclo se ejecuta 1G veces ( branches ~ = 1 billón). Los ciclos "extra" de 111k más allá de 2G son gastos generales que también están presentes en las otras pruebas, incluida la que no tiene mov . No se debe a fallas ocasionales de la eliminación de mov, pero sí escala con el recuento de iteraciones, por lo que no se trata solo de una sobrecarga de inicio. Probablemente sea por interrupciones del temporizador, ya que el rendimiento de IIRC Linux no juega con los contadores de rendimiento mientras maneja las interrupciones, y simplemente les permite seguir contando. ( perf virtualiza los contadores de rendimiento del hardware para que pueda obtener recuentos por proceso incluso cuando un hilo migra a través de las CPU). Además, las interrupciones del temporizador en el núcleo lógico hermano que comparte el mismo núcleo físico perturbarán un poco las cosas.

El cuello de botella es la cadena de dependencia transportada por el bucle que involucra el contador del bucle. 2G ciclos para 1G iters son 2 relojes por iteración, o 1 reloj por decremento. El confirma que la longitud de la cadena dep es de 2 ciclos. Esto solo es posible si mov tiene latencia cero . (Sé que no prueba que no haya otro cuello de botella. Realmente solo prueba que la latencia es a lo sumo 2 ciclos, si no crees mi afirmación de que la latencia es el único cuello de botella. Hay un resource_stalls.any contador de rendimiento, pero no tiene muchas opciones para desglosar qué recurso microarquitectura se agotó).

El bucle tiene 3 uops de dominio fusionado: mov , lea y dec/jnz macro-fusionado . El conteo 3G uops_issued.any confirma que: Cuenta en el dominio fusionado, que es toda la tubería desde los decodificadores hasta el retiro, excepto el planificador (RS) y las unidades de ejecución. (los pares de instrucciones con fusibles macro permanecen como un solo UOP en todas partes. Es solo para la micro fusión de tiendas o la carga ALU + que 1 UOP de dominio fusionado en el ROB rastrea el progreso de dos Uops de dominio no fusionado).

2G uops_executed.thread (dominio sin fusionar) nos dice que todos los movimientos se eliminaron (es decir, se manejaron mediante la etapa de emisión / cambio de nombre y se colocaron en el ROB en un estado ya ejecutado). Todavía ocupan el ancho de banda de emisión / retirada, y el espacio en la caché uop, y el tamaño del código. Ocupan espacio en el ROB, limitando el tamaño de la ventana fuera de servicio. Una instrucción mov nunca es gratis. Hay muchos posibles cuellos de botella microarquitectónicos además de los puertos de latencia y ejecución, el más importante generalmente es la tasa de emisión de 4 en el front-end.

En las CPU Intel, tener latencia cero es a menudo un problema mayor que no necesitar una unidad de ejecución, especialmente en Haswell y más tarde donde hay 4 puertos ALU. (Pero solo 3 de ellos pueden manejar uops vectoriales, por lo que los movimientos vectoriales no eliminados serían un cuello de botella más fácilmente, especialmente en el código sin muchas cargas o tiendas que quiten el ancho de banda frontal (4 uops de dominio fusionado por reloj) lejos de los uops ALU Además, programar uops para unidades de ejecución no es perfecto (más bien, como el más antiguo listo primero), por lo que los uops que no están en la ruta crítica pueden robar ciclos de la ruta crítica).

Si ponemos un nop o un xor edx,edx en el bucle, también se emitirían pero no se ejecutarían en las CPU de la familia Intel SnB.

La eliminación de movimiento de latencia cero puede ser útil para la extensión cero de 32 a 64 bits, y para 8 a 64. ( movzx eax, bl se elimina, movzx eax, bx no ).

Sin mov-elimination

Todas las CPU actuales que admiten la eliminación de mov no lo admiten para mov same,same por lo tanto, elija diferentes registros para enteros de extensión cero de 32 a 64 bits, o vmovdqa xmm,xmm a vmovdqa xmm,xmm cero a YMM en un caso raro donde sea necesario (A menos que necesite el resultado en el registro en el que ya está. Rebotar a un registro diferente y viceversa normalmente es peor). Y en Intel, lo mismo se aplica para movzx eax,al por ejemplo. (AMD Ryzen no mueve mov-eliminado movzx.) Las tablas de instrucciones de Agner Fog muestran que mov siempre se elimina en Ryzen, pero supongo que quiere decir que no puede fallar entre dos reglas diferentes de la misma manera que en Intel.

Podemos usar esta limitación para crear un micro punto de referencia que lo derrote a propósito.

mov ecx, ecx      # CPUs can''t eliminate  mov same,same
lea ecx, [rcx-1]

dec ecx
jnz .loop

 3,000,320,972      cycles:u                  #    3.898 GHz                      ( +-  0.00% )
 4,000,000,238      instructions:u            #    1.33  insn per cycle           ( +-  0.00% )
 1,000,000,234      branches:u                # 1299.225 M/sec                    ( +-  0.00% )
 3,000,084,446      uops_issued_any:u         # 3897.783 M/sec                    ( +-  0.00% )
 3,000,058,661      uops_executed_thread:u    # 3897.750 M/sec                    ( +-  0.00% )

Esto requiere ciclos 3G para iteraciones 1G, porque la longitud de la cadena de dependencia es ahora de 3 ciclos.

El conteo de UOP de dominio fusionado no cambió, aún 3G.

Lo que sí cambió es que ahora el conteo de UOP del dominio no fusionado es el mismo que el del dominio fusionado. Todos los uops necesitaban una unidad de ejecución; ninguna de las instrucciones mov se eliminó, por lo que todas agregaron latencia 1c a la cadena dep transportada en bucle.

(Cuando hay uops micro fusionados, como add eax, [rsi] , el recuento de uops_executed puede ser mayor que uops_issued . Pero no tenemos eso).

Sin el mov en absoluto:

lea ecx, [rcx-1]

dec ecx
jnz .loop


 2,000,131,323      cycles:u                  #    3.896 GHz                      ( +-  0.00% )
 3,000,000,161      instructions:u            #    1.50  insn per cycle         
 1,000,000,157      branches:u                # 1947.876 M/sec                  
 2,000,055,428      uops_issued_any:u         # 3895.859 M/sec                    ( +-  0.00% )
 2,000,039,061      uops_executed_thread:u    # 3895.828 M/sec                    ( +-  0.00% )

Ahora volvemos a la latencia de 2 ciclos para la cadena dep transportada en bucle.

Nada es eliminado.

Probé en un Skylake i7-6700k de 3.9GHz. Obtengo resultados idénticos en un Haswell i5-4210U (dentro de 40k de 1G recuentos) para todos los eventos de rendimiento. Eso es aproximadamente el mismo margen de error que volver a ejecutar en el mismo sistema.

Tenga en cuenta que si ejecuté perf como root ¹ , y conté cycles lugar de cycles:u (solo espacio de usuario), medirá la frecuencia de la CPU como exactamente 3.900 GHz. (IDK por qué Linux solo obedece la configuración de bios para turbo máximo justo después del reinicio, pero luego cae a 3.9GHz si lo dejo inactivo durante un par de minutos. Asus Z170 Pro Gaming mobo, Arch Linux con kernel 4.10.11-1-ARCH Vi lo mismo con Ubuntu. Escribir balance_performance en cada uno de /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference desde /etc/rc.local arregla, pero escribir balance_power hace que retroceda a 3.9GHz nuevamente más tarde.)

1: actualización: como una mejor alternativa para ejecutar sudo perf , configuro sysctl kernel.perf_event_paranoid = 0 en /etc/syctl.d/99-local.conf

Debería obtener los mismos resultados en AMD Ryzen, ya que puede eliminar el movimiento entero. La familia Bulldozer de AMD solo puede eliminar copias de registro xmm. (Según Agner Fog, las copias de registro ymm son una mitad baja eliminada y una operación ALU para la mitad alta).

Por ejemplo, AMD Bulldozer e Intel Ivybridge pueden mantener un rendimiento de 1 por reloj para

 movaps  xmm0, xmm1
 movaps  xmm2, xmm3
 movaps  xmm4, xmm5
 dec
 jnz .loop

Pero Intel Sandybridge no puede eliminar movimientos, por lo que obstaculizaría 4 UUP de ALU para 3 puertos de ejecución. Si fuera pxor xmm0,xmm0 lugar de movaps, SnB también podría soportar una iteración por reloj. (Pero la familia Bulldozer no pudo hacerlo, porque la reducción a cero de la imagen aún necesita una unidad de ejecución en AMD, aunque es independiente del valor anterior del registro. Y la familia Bulldozer solo tiene un rendimiento de 0.5c para PXOR).

Limitaciones de la eliminación de mov

Dos instrucciones MOV dependientes seguidas exponen una diferencia entre Haswell y Skylake.

.loop:
  mov eax, ecx
  mov ecx, eax

  sub ecx, 2
  jnz .loop

Haswell: variabilidad menor de ejecución a ejecución (1.746 a 1.749 c / iter), pero esto es típico:

 1,749,102,925      cycles:u                  #    2.690 GHz                    
 4,000,000,212      instructions:u            #    2.29  insn per cycle         
 1,000,000,208      branches:u                # 1538.062 M/sec                  
 3,000,079,561      uops_issued_any:u         # 4614.308 M/sec                  
 1,746,698,502      uops_executed_core:u      # 2686.531 M/sec                  
   745,676,067      lsd_cycles_4_uops:u       # 1146.896 M/sec                  

No se eliminan todas las instrucciones MOV: aproximadamente 0,75 de las 2 por iteración usaban un puerto de ejecución. Cada MOV que se ejecuta en lugar de ser eliminado agrega 1c de latencia a la cadena dep transportada en bucle, por lo que no es una coincidencia que uops_executed y los cycles sean muy similares. Todos los uops son parte de una sola cadena de dependencia, por lo que no hay paralelismo posible. cycles siempre son aproximadamente 5M más altos que uops_executed independientemente de la uops_executed de ejecución a ejecución, por lo que supongo que solo se están utilizando 5M ciclos en otro lugar.

Skylake: más estable que los resultados de HSW y más eliminación de movimientos: solo 0.6666 MOV de cada 2 necesitaban una unidad de ejecución.

 1,666,716,605      cycles:u                  #    3.897 GHz
 4,000,000,136      instructions:u            #    2.40  insn per cycle
 1,000,000,132      branches:u                # 2338.050 M/sec
 3,000,059,008      uops_issued_any:u         # 7014.288 M/sec
 1,666,548,206      uops_executed_thread:u    # 3896.473 M/sec
   666,683,358      lsd_cycles_4_uops:u       # 1558.739 M/sec

En Haswell, lsd.cycles_4_uops representaba todos los uops. (0.745 * 4 ~ = 3). Entonces, en casi todos los ciclos donde se emiten uops, se emite un grupo completo de 4 (desde el buffer de bucle. Probablemente debería haber mirado un contador diferente que no le importa de dónde vinieron, como uops_issued.stall_cycles para contar ciclos donde no se emitieron uops).

Pero en SKL, 0.66666 * 4 = 2.66664 es inferior a 3, por lo que en algunos ciclos el front-end emitió menos de 4 uops. (Por lo general, se detiene hasta que haya espacio en el núcleo fuera de servicio para emitir un grupo completo de 4, en lugar de emitir grupos no completos).

Es extraño, IDK, cuál es la limitación microarquitectura exacta. Como el ciclo es de solo 3 uops, cada grupo de problemas de 4 uops es más que una iteración completa. Por lo tanto, un grupo de problemas puede contener hasta 3 MOV dependientes. ¿Quizás Skylake está diseñado para romper eso a veces, para permitir una mayor eliminación de movimientos?

actualización : en realidad esto es normal para los bucles de 3 uop en Skylake. uops_issued.stall_cycles muestra que HSW y SKL emiten un simple bucle de 3 uop sin eliminación de movimiento de la misma manera que emiten este. Por lo tanto, una mejor eliminación de mov es un efecto secundario de la división de grupos de problemas por alguna otra razón. (No es un cuello de botella porque las ramas tomadas no pueden ejecutarse más rápido que 1 por reloj, independientemente de lo rápido que se emitan). Todavía no sé por qué SKL es diferente, pero no creo que sea algo de qué preocuparse.

En un caso menos extremo, SKL y HSW son iguales, y ambos no logran eliminar 0.3333 de cada 2 instrucciones MOV:

.loop:
  mov eax, ecx
  dec eax
  mov ecx, eax

  sub ecx, 1
  jnz .loop

 2,333,434,710      cycles:u                  #    3.897 GHz                    
 5,000,000,185      instructions:u            #    2.14  insn per cycle         
 1,000,000,181      branches:u                # 1669.905 M/sec                  
 4,000,061,152      uops_issued_any:u         # 6679.720 M/sec                  
 2,333,374,781      uops_executed_thread:u    # 3896.513 M/sec                  
 1,000,000,942      lsd_cycles_4_uops:u       # 1669.906 M/sec                  

Todos los uops se emiten en grupos de 4. Cualquier grupo contiguo de 4 uops contendrá exactamente dos MOV uops que son candidatos para la eliminación. Como claramente logra eliminar ambos en algunos ciclos, IDK explica por qué no siempre puede hacer eso.

El manual de optimización de Intel dice que sobrescribir el resultado de la eliminación de mov lo antes posible libera los recursos de microarquitectura para que pueda tener éxito con mayor frecuencia, al menos para movzx . Ver Ejemplo 3-25. Secuencia de reordenamiento para mejorar la efectividad de las instrucciones MOV de latencia cero .

Entonces, ¿tal vez se realiza un seguimiento interno con una tabla de recuentos de tamaño limitado? Algo tiene que evitar que la entrada del archivo de registro físico se libere cuando ya no se necesita como el valor del registro arquitectónico original, si todavía se necesita como el valor del destino mov. La liberación de entradas PRF lo antes posible es clave, ya que el tamaño PRF puede limitar la ventana fuera de servicio a un tamaño menor que el tamaño ROB.

Probé los ejemplos en Haswell y Skylake, y descubrí que la eliminación de movimiento funcionaba significativamente más tiempo al hacerlo, pero que en realidad era un poco más lenta en ciclos totales, en lugar de más rápido. El ejemplo tenía la intención de mostrar el beneficio en IvyBridge, que probablemente tiene cuellos de botella en sus 3 puertos ALU, pero HSW / SKL solo tiene cuellos de botella en conflictos de recursos en las cadenas de dep y no parece molestarse al necesitar un puerto ALU para más de instrucciones movzx .

Consulte también ¿Por qué XCHG reg, reg es una instrucción 3 micro-op en arquitecturas Intel modernas? para más investigación + conjeturas sobre cómo funciona la eliminación de mov, y si podría funcionar para xchg eax, ecx . (En la práctica, xchg reg,reg es 3 ALU uops en Intel, pero 2 eliminó uops en Ryzen. Es interesante adivinar si Intel podría haberlo implementado de manera más eficiente).

Por cierto, como solución para una errata en Haswell, Linux no proporciona uops_executed.thread cuando hyperthreading está habilitado, solo uops_executed.core . El otro núcleo definitivamente estuvo inactivo todo el tiempo, ni siquiera las interrupciones del temporizador, porque lo desconecté con echo 0 > /sys/devices/system/cpu/cpu3/online . Desafortunadamente, esto no se puede hacer antes de que perf decida que HT está habilitado, y mi computadora portátil Dell no tiene una opción de BIOS para deshabilitar HT. Por lo tanto, no puedo obtener perf para usar los 8 contadores de PMU de hardware a la vez en ese sistema, solo 4.: /