Alineación de memoria en un procesador Intel de 32 bits

Question

Los procesadores Intel de 32 bits, como Pentium, tienen un bus de datos de 64 bits de ancho y, por lo tanto, obtienen 8 bytes por acceso. Basado en esto, supongo que las direcciones físicas que emiten estos procesadores en el bus de direcciones son siempre múltiplos de 8.

En primer lugar, ¿es correcta esta conclusión?

En segundo lugar, si es correcto, entonces uno debe alinear los miembros de la estructura de datos en un límite de 8 bytes. Pero he visto personas que utilizan una alineación de 4 bytes en estos procesadores.

¿Cómo pueden justificarse al hacerlo?

Answer 1

La regla general habitual (directamente de Intels y los manuales de optimización de AMD) es que cada tipo de datos debe estar alineado por su propio tamaño. Un int32 debe estar alineado en un límite de 32 bits, un int64 en un límite de 64 bits, y así sucesivamente. Un char encajará bien en cualquier lugar.

Otra regla general es, por supuesto, " se le ha informado al compilador sobre los requisitos de alineación " ;. No necesita preocuparse porque el compilador sabe agregar el relleno y las compensaciones correctas para permitir un acceso eficiente a los datos.

La única excepción es cuando se trabaja con instrucciones SIMD, donde debe garantizar manualmente la alineación en la mayoría de los compiladores.

  

En segundo lugar, si es correcto, entonces uno   debe alinear los miembros de la estructura de datos en   Un límite de 8 bytes. Pero he visto   personas que usan una alineación de 4 bytes   en cambio en estos procesadores.

No veo cómo eso hace la diferencia. La CPU simplemente puede emitir una lectura para el bloque de 64 bits que contiene esos 4 bytes. Eso significa que obtiene 4 bytes adicionales antes de los datos solicitados o después. Pero en ambos casos, solo toma una sola lectura. La alineación de 32 bits de datos de 32 bits de ancho garantiza que no cruzará un límite de 64 bits.

Answer 2

El bus físico tiene 64 bits de ancho ... múltiplo de 8 - > sí

SIN EMBARGO, hay dos factores más a considerar:

1. Algunos conjuntos de instrucciones x86 se direccionan en bytes. Algunos están alineados con 32 bits (es por eso que tienes una cosa de 4 bytes). Pero ninguna instrucción (núcleo) está alineada a 64 bits. La CPU puede manejar el acceso a datos desalineados.
2. Si le importa el rendimiento, debe pensar en la línea de caché, no en la memoria principal. Las líneas de caché son mucho más anchas.

Answer 3

Se justifica hacerlo porque cambiar a una alineación de 8 bytes constituiría un cambio de ABI, y la mejora marginal del rendimiento no merece la pena.

Como alguien más ya dijo, las líneas de caché son importantes. Todos los accesos en el bus de memoria real son en términos de líneas de caché (64 bytes en x86, IIRC). Vea & Quot; Lo que todo programador necesita saber sobre la memoria & Quot; doc que ya se mencionó. Por lo tanto, el tráfico de memoria real está alineado a 64 bytes.

Answer 4

Para acceso aleatorio y siempre que los datos no estén desalineados (por ejemplo, cruzando un límite), no creo que importen demasiado; La dirección correcta y el desplazamiento en los datos se pueden encontrar con una simple construcción AND en hardware. Se vuelve lento cuando un acceso de lectura no es suficiente para obtener un valor. Esa es también la razón por la cual los compiladores generalmente ponen valores pequeños (bytes, etc.) juntos porque no tienen que estar en un desplazamiento específico; los cortos deben estar en direcciones pares, 32 bits en direcciones de 4 bytes y 64 bits en direcciones de 8 bytes.

Tenga en cuenta que si tiene acceso de datos en caché invocado y lineal, las cosas serán diferentes.

Answer 5

El bus de 64 bits al que se refiere alimenta las cachés. Como CPU, siempre lea y escriba líneas de caché completas. El tamaño de una línea de caché siempre es un múltiplo de 8, y su dirección física está realmente alineada en desplazamientos de 8 bytes.

Las transferencias de caché a registro no utilizan el bus de datos externo, por lo que el ancho de ese bus es irrelevante.