¿Cuál es el efecto real del éxito de los accesos no alineados en x86?

Question

Siempre he oído que los accesos no alineados son malos porque pueden causar errores en el tiempo de ejecución y bloquear el programa o ralentizar los accesos a la memoria. Sin embargo, no puedo encontrar datos reales sobre cuánto van a ralentizar las cosas.

Supongamos que estoy en x86 y tengo una parte (aún desconocida) de accesos no alineados: ¿cuál es la peor ralentización posible y cómo la estimo sin eliminar todos los accesos no alineados y comparando el tiempo de ejecución de dos versiones de código?

Answer 1

Depende de la (s) instrucción (es), para la mayoría de las instrucciones de carga/almacenamiento x86 SSE (excluyendo variantes no alineadas), causará un error, lo que significa que probablemente bloqueará su programa o dará lugar a muchos viajes redondos su manejador de excepciones (lo que significa que casi todo el rendimiento se pierde). Las variantes de carga/almacenamiento no alineados se ejecutan al doble de ciclos IIRC, ya que realizan lecturas/escrituras parciales, por lo que se requieren 2 para realizar la operación (a menos que tenga suerte y esté en caché, lo que reduce la penalización).

Para las instrucciones generales de carga/almacenamiento x86, la penalización es la velocidad, ya que se requieren más ciclos para leer o escribir. la desalineación también puede afectar el almacenamiento en caché, lo que lleva a la división de la línea de caché y a los límites de la caché. También evita la atomicidad en lecturas y escrituras (que están garantizadas para todas las lecturas/escrituras alineadas de x86, las barreras y la propagación es otra cosa, pero el uso de la instrucción LOCK en datos desalineados puede causar una excepción o aumentar en gran medida la penalización lock incurs), que es un no-no para la programación concurrente.

Intels x86 & x64 optimizations manual entra en gran detalle sobre cada problema antes mencionado, sus efectos secundarios y cómo remediarlos.

Agner Fog' optimization manuals debe tener los números exactos que está buscando en términos de rendimiento del ciclo sin procesar.

Answer 2

En general, la velocidad de estimación en los procesadores modernos es extremadamente complicada. Esto es cierto no solo para los accesos no alineados sino en general.

Los procesadores modernos tienen arquitecturas segmentadas, desordenadas y posiblemente la ejecución paralela de instrucciones y muchas otras cosas que pueden afectar la ejecución.

Si no se admite el acceso no alineado, se obtiene una excepción. Pero si es compatible, puede o no tener una desaceleración dependiendo de muchos factores. Estos factores incluyen qué otras instrucciones estaba ejecutando antes y después de la desalineación (porque el procesador puede comenzar a buscar sus datos mientras ejecuta las instrucciones anteriores o seguir adelante y seguir las instrucciones mientras espera).

Otra diferencia muy importante ocurre si el acceso desalineado ocurre a través de los límites de la línea de caché. Wile, en general, un acceso 2x a la memoria caché puede ocurrir para un acceso no alineado, la verdadera ralentización es si el acceso cruza un límite de la caché y causa una doble falta de caché. En el peor caso posible, una lectura desalineada de 2 bytes puede requerir que el procesador elimine dos cachelines de la memoria y luego lea 2 chachelines de la memoria. Eso es una gran cantidad de datos en movimiento.

La regla general para la optimización también se aplica aquí: primer código, luego mida, luego si y solo si hay un problema para encontrar una solución.

Answer 3

En algunas microarquitecturas Intel, una carga que se divide por un límite de caché toma una docena de ciclos más de lo normal, y una carga que se divide por un límite de página tarda más de 200 ciclos. Ya es suficientemente malo que si las cargas van a desalinearse de manera consistente en un bucle, vale la pena hacer dos cargas alineadas y combinar los resultados manualmente, incluso si palignr no es una opción.Incluso las cargas desalineadas de SSE no lo salvarán, a menos que estén divididos exactamente en el medio.

En AMD esto nunca fue un problema, y ​​el problema desapareció en su mayoría en Nehalem, pero todavía hay muchos Core2 disponibles.