¿Cuál es el efecto del segundo argumento en _builtin_prefetch()?

4 minutos de lectura

¿Cual es el efecto del segundo argumento en builtin prefetch
ANTONIO

El documento del CCG aquí especifica el uso de _buitin_prefetch.

El tercer argumento es perfecto. Si es 0, el compilador genera la instrucción prefetchtnta (%rax) Si es 1, el compilador genera la instrucción prefetcht2 (%rax) Si es 2, el compilador genera la instrucción prefetcht1 (%rax) Si es 3 (predeterminado), el compilador genera prefetcht0 (%rax) instrucción.

Si variamos el tercer argumento, el código de operación ya cambió en consecuencia.

Pero el segundo argumento no parece tener ningún efecto.

__builtin_prefetch(&x,1,2);
__builtin_prefetch(&x,0,2);
__builtin_prefetch(&x,0,1);
__builtin_prefetch(&x,0,0);

Lo anterior es el fragmento de código de muestra, que generó:

El siguiente es el montaje:

 27:    0f 18 10                prefetcht1 (%rax)
  2a:   48 8d 45 fc             lea    -0x4(%rbp),%rax
  2e:   0f 18 10                prefetcht1 (%rax)
  31:   48 8d 45 fc             lea    -0x4(%rbp),%rax
  35:   0f 18 18                prefetcht2 (%rax)
  38:   48 8d 45 fc             lea    -0x4(%rbp),%rax
  3c:   0f 18 00                prefetchnta (%rax)

Uno puede observar el cambio en los códigos de operación con el tercer argumento. Pero incluso si cambié el segundo argumento (que especifica lectura o escritura), el código ensamblador sigue siendo el mismo. <27,2a> y <2e,31>. Entonces no le da ninguna información a la máquina. Entonces, ¿cuál es el propósito del segundo argumento?

  • La documentación es muy clara. Las instrucciones que genera para una arquitectura específica, por supuesto, dependen de las funciones disponibles. Para algunas arquitecturas, no emitirá ninguna instrucción. Entonces, ¿verificó qué instrucciones de captación previa proporciona su destino x86 específico? ¿Qué es lo que realmente hacen? ¿Y cómo se relacionan con los argumentos? Los manuales de instrucciones para Intel y AMD están disponibles para su descarga gratuita.

    – demasiado honesto para este sitio

    9 de noviembre de 2016 a las 18:13


  • Gracias por su respuesta. ¿Dónde dar eso -march=-xxxxx.? ¿Qué especifica exactamente esta opción de marcha, máquina/arquitectura de destino?

    – ANTONIO

    12 de noviembre de 2016 a las 7:17


  • @ANTHONY: En la línea de comandos de gcc, en tiempo de compilación, obviamente. gcc.gnu.org/onlinedocs/gcc/x86-Options.html. No creo que importe en el momento del enlace, solo al pasar de .c para .o (o directamente a un ejecutable). Le dice a gcc qué instrucciones puede usar y también establece -mtune=.

    – Peter Cordes

    12 de noviembre de 2016 a las 7:17


  • Para ser más precisos, las versiones anteriores de Windows emuladas para 3DNow! instrucciones de captación previa para CPU Intel más antiguas.

    –Yuhong Bao

    2 de agosto de 2017 a las 8:25

  • PREFETCHWT1 es parte del AVX512PF colocar. Sin embargo, el artículo de wikipedia no menciona explícitamente. se muestra mas claro aquí. Sin embargo, aunque el artículo de WikiChip dice que AVX512PF es compatible con KNL y KNM, Referencia de programación de funciones futuras y extensiones del conjunto de instrucciones de la arquitectura Intel® dice que solo es compatible con KNL.

    –Hadi Brais

    23 de febrero de 2019 a las 0:04

  • Ese artículo de Wikipedia dice que AVX512PF es compatible con KNM y cita el mismo documento de Intel, pero ese documento no dice eso.

    –Hadi Brais

    23 de febrero de 2019 a las 0:06

  • PREFETCHW existe en las CPU de AMD e Intel desde Broadwell. Excelente punto de que incluso si su objetivo de compilación actual no lo admite, aún debe expresar su intención correctamente para obtener un buen ASM en otros objetivos.

    – Peter Cordes

    9 de noviembre de 2016 a las 22:11

  • Gracias @Peter, me lo perdí por completo.

    –Margaret Bloom

    10 de noviembre de 2016 a las 8:47

  • Gracias por sus respuestas. ¿De qué sirve especificar lectura/escritura en el segundo argumento, escribir hardware? ¿Cómo trata el hardware las cosas de manera diferente? Tiene las mismas entradas de MSHR. ¡Solo quiero saber cómo el hardware muestra la diferencia al tratar estos R y W!

    – ANTONIO

    12 de noviembre de 2016 a las 7:14


  • @ANTHONY Google para “protocolo MESI”, es el protocolo que usa x86 para mantener la memoria caché coherente. Una línea de caché puede estar en cualquiera de los cuatro estados M,E,S,I en cualquier momento. Escribir en estados particulares es costoso porque requiere trabajo adicional, la captación previa de W realiza este trabajo adicional además de obtener los datos.

    –Margaret Bloom

    12 de noviembre de 2016 a las 11:39

  • ¿Puede explicar por qué el hardware necesita cambiar el estado en el caché (M, E, S, I) tan pronto como precarga los datos con ‘w’? En mi opinión, una vez que se realiza la captación previa con ‘W’, ahí está el caché. Pero no necesita cambiar el estado a ‘M’ para reflejar ‘w’. Porque el cambio de estado a M implica invalidaciones (eso es lo que mencionaste como costoso). Si la captación previa se realiza antes o después, los cambios de estado costarán más porque contaminaron la memoria caché. Entonces, ¿podemos pensar que la captación previa con ‘W’ cambiará el estado?

    – ANTONIO

    13 de noviembre de 2016 a las 9:30

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad