Bajo nivel y rendimiento

Llega el momento de exprimir la máquina. Pero optimizar bien no es meter trucos: es entender qué frena de verdad al hardware —casi siempre, la memoria— y medir en vez de adivinar. Aquí está la diferencia entre creer que optimizas y hacerlo de verdad.

La caché lo es casi todo

El mito del rendimiento es que importan las instrucciones. La realidad: importa la memoria. Un acceso a la caché L1 tarda ~1 ns; uno a la RAM principal, ~100 ns. Cien veces más. Tu CPU pasa la mayor parte del tiempo esperando datos, no calculando.

// recorrer una matriz por filas vs por columnas: MISMO trabajo, ORDEN distinto
for (int i = 0; i < N; i++)
    for (int j = 0; j < N; j++)
        suma += m[i][j];        // por filas: memoria contigua → caché feliz

for (int j = 0; j < N; j++)
    for (int i = 0; i < N; i++)
        suma += m[i][j];        // por columnas: saltos → fallo de caché por acceso

El segundo bucle puede ser varias veces más lento que el primero, haciendo exactamente la misma suma. La única diferencia es el patrón de acceso a memoria.

SIMD e intrinsics

Las CPUs pueden operar sobre varios datos con una instrucción (Single Instruction, Multiple Data): sumar 8 floats de golpe. El compilador vectoriza automáticamente con -O3, pero puedes hacerlo explícito con intrinsics:

#include <immintrin.h>
__m256 a = _mm256_loadu_ps(x);      // carga 8 floats
__m256 b = _mm256_loadu_ps(y);
__m256 c = _mm256_add_ps(a, b);     // los suma los 8 a la vez
_mm256_storeu_ps(z, c);

Y para lo verdaderamente específico, inline assembly te deja escribir instalaciones concretas (raro, pero posible):

int r;
__asm__ ("rdtsc" : "=a"(r));   // leer el contador de ciclos, por ejemplo

Mide, no adivines

perf stat ./prog                  # ciclos, fallos de caché, instrucciones
perf record ./prog && perf report # dónde se va el tiempo, línea a línea