Memoria caché: qué es, para qué sirve y cómo funciona

Hay un consejo que sirve para casi todo y que todo el mundo ha dado alguna vez: «apágalo y enciéndelo». Y su primo hermano, el que se dice cuando algo va raro en una web: «borra la caché». Los dos funcionan más veces de las que admite la teoría, y los dos apuntan a lo mismo: hay una memoria intermedia que guarda copias de lo que usas a menudo para que no tengas que volver a pedirlo al sitio lento.

Esa memoria es la caché, y es una de esas piezas que no ves hasta que entiendes qué hace. Mi tesis: la caché explica media docena de misterios cotidianos —la CPU que trabaja y no avanza, la web que muestra una versión vieja, el archivo que se abre dos veces más rápido que la primera— y merece la pena tenerla clara.

Qué es la memoria caché

La memoria caché es una memoria pequeña, muy rápida y muy pegada al procesador que guarda copias de datos e instrucciones de uso frecuente. La idea es simple: si la CPU va a necesitar el mismo dato una y otra vez, mejor tenerlo al lado que ir a buscarlo a la RAM en cada ocasión.

Está fabricada en SRAM —más rápida y más cara que la DRAM de la RAM— y por eso es pequeña: unos pocos kilobytes hasta decenas de megabytes. Cambia poco espacio por mucha velocidad, y ese es todo el trato.

Un matiz que ahorra confusiones: cuando decimos «caché» a secas, normalmente hablamos de la caché del procesador. Pero la palabra también se usa para la caché del navegador, la de disco o la de una aplicación. Comparten la idea (guardar lo frecuente cerca), pero son capas distintas y no se gestionan igual.

Hay una unidad que conviene tener en mente porque explica casi todo lo demás: la caché no mueve bytes sueltos, mueve líneas (cache lines). En la arquitectura x86 una línea son 64 bytes, y en Arm suele ser del mismo tamaño. Es decir, aunque tu programa pida un solo dato, el procesador se trae de la RAM un bloque de 64 bytes alrededor de él. Si los datos que necesitas están juntos, ese bloque llega lleno de cosas útiles; si están dispersos, pagas 64 bytes para usar dos. Los manuales de Intel documentan este comportamiento con detalle, y la guía de programación de Arm insiste en lo mismo para sus núcleos: quien escribe software pensando en la línea va mucho más rápido.

Localidad temporal y espacial: por qué funciona una memoria tan pequeña

La caché acierta porque los programas, casi sin saberlo, repiten y agrupan sus accesos. Esa regularidad tiene nombre —localidad de referencia— y viene en dos sabores que conviene distinguir, porque cada uno se ataca de una forma.

Localidad temporal: el mismo dato se vuelve a usar poco después. Un contador que se incrementa en cada vuelta de un bucle, una variable de configuración que se consulta mil veces, la misma fila de una tabla que se toca en cada iteración. El valor se pide una vez a la RAM y a partir de ahí vive en caché.

Localidad espacial: los datos que necesitas están cerca unos de otros en memoria. Si el programa lee la posición 1000, lo más probable es que la 1001, la 1002 y las siguientes también le hagan falta. Como la caché se trae 64 bytes de golpe, ese patrón sale casi gratis.

Un ejemplo clásico lo enseña sin rodeos: recorrer una matriz. En la mayoría de lenguajes, una matriz bidimensional se guarda por filas en memoria contigua, así que recorrerla fila a fila aprovecha la localidad espacial, mientras que recorrerla columna a columna salta de una fila a otra y provoca un fallo de caché detrás de otro. El algoritmo es el mismo, el resultado es idéntico y el tiempo se puede multiplicar. Los manuales de optimización de Intel dedican capítulos enteros a reordenar bucles y estructuras por este motivo; la guía de Arm hace lo propio para núcleos móviles, donde la energía importa además del tiempo.

Para qué sirve la memoria caché

Sirve para una cosa muy concreta: que el procesador no pierda el tiempo esperando datos. Cada vez que la CPU necesita algo que no tiene a mano, se queda parada. Y a miles de millones de operaciones por segundo, esas esperas se acumulan y se convierten en un equipo que parece ir cuesta abajo.

La magnitud del problema ayuda a entender por qué existe la caché. Un núcleo moderno trabaja en fracciones de nanosegundo: a 4 GHz, un ciclo dura 0,25 nanosegundos. Un acceso que no está en caché y tiene que salir a la RAM se paga en decenas —o cientos— de ciclos, y durante todo ese rato el núcleo no tiene nada que hacer salvo esperar. Esa distancia entre lo rápido que calcula la CPU y lo lento que llegan los datos se conoce como la «pared de la memoria», y la jerarquía de caché es la respuesta: no elimina la espera, la reduce a un acierto en L1 de apenas unos ciclos.

La caché aprovecha lo que acabamos de ver: los programas vuelven a usar los mismos datos o datos que están juntos en memoria. No guarda todo; guarda lo que se repite. Y por eso una memoria que ocupa una milésima parte de la RAM puede decidir si un equipo va suelto o va arrastrando.

Cómo funciona: aciertos, fallos y el precio de cada fallo

Cuando el procesador pide un dato, lo primero que hace es mirar en la caché. Hay dos finales posibles:

• Acierto (cache hit): el dato está ahí y el acceso es casi instantáneo.
• Fallo (cache miss): no está, así que hay que ir a la RAM —mucho más lenta— y traerlo, dejando una copia en caché por si vuelve a hacer falta.

Lo que importa no es cada acceso suelto, sino la proporción de aciertos. Cuanto más alta, más rápido va todo. Y cuando la proporción baja —accesos desordenados, datos que no caben, código con mala localidad—, el procesador empieza a esperar más de lo que trabaja. Ese tiempo perdido muchas veces no aparece como tal en los monitores: solo ves una CPU «ocupada» que no avanza.

Los fallos tienen tres causas clásicas, y saber cuál te toca cambia la solución. Se conocen como las «tres C»:

• Obligatorio (compulsory): la primera vez que se toca un dato, no hay más remedio que traerlo. No se puede evitar del todo; se reduce con prefetching, que adelanta la carga antes de que se pida.
• De capacidad (capacity): el conjunto de datos que el programa usa de verdad no cabe en la caché, así que unos bloques desalojan a otros. Se corrige tocando menos datos a la vez, no cambiando el hardware.
• De conflicto (conflict): dos direcciones que se usan juntas caen en el mismo hueco de la caché y se pisan aunque sobre espacio. Se corrige reordenando la memoria o con estructuras mejor alineadas.

De ahí sale una fórmula sencilla que sirve para priorizar: el tiempo medio de acceso a memoria (AMAT) es igual al tiempo del acierto más la tasa de fallo multiplicada por el coste del fallo.

AMAT = tiempo_acierto + tasa_fallo × coste_fallo

Con eso se ve por qué bajar un par de puntos la tasa de fallo puede importar más que subir el reloj. Si cada fallo se paga en decenas o cientos de ciclos, la cuenta se acumula rápido.

La línea de caché, los conjuntos y las políticas de reemplazo

Por dentro, la caché se organiza como un conjunto de huecos que no coinciden con direcciones de memoria, sino con bloques. A cada bloque se le asocia una etiqueta (tag) que dice de qué dirección viene, un índice que decide en qué hueco cae y un desplazamiento dentro de la línea de 64 bytes. Cuando el procesador pide una dirección, la caché calcula esas tres piezas y compara la etiqueta con las que tiene guardadas: si coincide, acierto; si no, fallo.

¿Y qué pasa cuando varios bloques quieren el mismo hueco? Para eso está la asociatividad. Una caché «directa» tiene un único sitio por conjunto, es la más simple y también la que más conflictos sufre. Una caché N-way guarda N bloques por conjunto y compara varias etiquetas en paralelo: cuesta más hardware, pero reduce los conflictos. La L1 de un núcleo actual suele ser de 8 a 12 vías.

Cuando hay que hacer sitio, entra en juego la política de reemplazo: normalmente se expulsa el bloque menos usado recientemente (LRU) o una aproximación suya, porque implementar LRU perfecto es caro. Es una apuesta: se asume que lo que no se ha tocado hace rato difícilmente hará falta pronto.

También se decide cuándo se escribe. En una política write-back, el dato se escribe primero en caché y solo baja a RAM cuando ese bloque se desaloja; en write-through, se escribe siempre en ambos sitios. La primera es más rápida y la habitual; la segunda es más simple y más segura ante un corte de corriente. Y hay un matiz más: si un bloque es exclusivo de la L3 y sobrevive al desalojo de la L2, algunas arquitecturas lo guardan en una victim cache en vez de tirarlo. Los detalles cambian de un fabricante a otro, pero la idea de fondo es la misma: no perder un bloque que quizá se vuelva a pedir.

A todo esto se suma el prefetcher, un circuito que detecta patrones —recorridos secuenciales, saltos con paso fijo— y va trayendo datos antes de que el programa los pida. Cuando acierta, el fallo obligatorio se convierte en acierto; cuando se equivoca, ocupa ancho de banda con datos que nadie va a usar.

L1, L2 y L3: los tres niveles

La caché del procesador no es un bloque único, sino una escalera de tres niveles. La regla es siempre la misma: cuanto más cerca del núcleo, más rápida y más pequeña. Esa jerarquía tiene décadas de historia y sigue la misma idea que separó a los primeros ordenadores del almacenamiento masivo: lo pequeño y rápido arriba, lo grande y lento abajo. Si te interesa ese recorrido, lo contamos en la historia de la informática.

• L1: la más rápida y la primera que se consulta. Está pegada al núcleo, mide entre 32 KB y 512 KB y responde en 1-5 ciclos. En casi todos los procesadores actuales está dividida en dos: una parte para instrucciones (L1I) y otra para datos (L1D), de modo que buscar la siguiente instrucción no desplace los datos con los que se está trabajando.
• L2: el segundo escalón. Más grande (256 KB a varios MB por núcleo) y algo más lenta, entre 5 y 15 ciclos. Suele ser privada de cada núcleo, no compartida.
• L3: la mayor, normalmente compartida entre todos los núcleos. Decenas de megabytes en un ordenador de escritorio y cientos en un procesador de servidor; 30-50 ciclos de latencia. Es la última parada antes de salir a la RAM.

Que la L3 sea compartida tiene una consecuencia práctica: dos programas que no paran de pedir datos tiran de la misma caché y se la quitan mutuamente. Y que la L2 sea privada explica por qué, a veces, mover un hilo de un núcleo a otro cuesta más de lo que parece: el hilo deja atrás su caché caliente y empieza de cero en el núcleo nuevo. Los fabricantes lo saben y lo recomiendan tener en cuenta al repartir trabajo entre núcleos.

Caché, RAM y almacenamiento: no son lo mismo

Memoria	Qué guarda	Capacidad típica	Latencia
Registros	Los operandos en uso inmediato	Bytes	0–1 ciclos
Caché	Copias de datos de uso frecuente	KB – decenas de MB	1–50 ciclos
RAM	Todo lo que el sistema usa ahora	GB	Decenas–cientos de ciclos
SSD/HDD	Archivos, de forma permanente	TB	Microsegundos–milisegundos

Se confunden caché y RAM porque ambas son rápidas y las dos se borran al apagar. La diferencia está en el propósito: la caché existe para que la CPU no espere a la RAM; y la RAM, para que el sistema no espere al disco. Son tres escalones del mismo problema: acercar los datos a quien los usa. Si quieres profundizar en el escalón intermedio, aquí tienes qué es la memoria RAM y por qué se nota tanto cuando falta.

Hay una forma de leer la escalera que aclara casi todas las dudas: cada nivel guarda una copia parcial del que tiene debajo, y solo de la parte que se usa de verdad en ese momento. La memoria RAM es una copia parcial del disco; la caché, una copia parcial de la RAM; y los registros, una copia parcial de la caché. Quien confunde los niveles acaba buscando el problema en el sitio equivocado: un equipo con 64 GB de RAM puede ir lento si la CPU se pasa el día con fallos de caché, y una caché enorme no arregla un disco saturado.

Caché de procesador en el mundo real

Más allá de la teoría, la caché se nota en cargas muy concretas. Estos son los terrenos donde manda:

• Videojuegos. Los motores gráficos saltan por estructuras de datos grandes y poco ordenadas, y ahí la L3 decide. No es casualidad que procesadores con mucha caché rindan por encima de su frecuencia en juegos concretos, ni que se haya llegado a apilar memoria encima del propio chip para ampliarla.
• Bases de datos y servidores. Si el conjunto de datos con el que se trabaja a diario cabe en caché o en RAM, las consultas vuelan; si no, cada operación toca disco. Por eso el tamaño del working set se mide antes de dimensionar un servidor.
• Compresión, cifrado y análisis de datos. Son tareas que recorren grandes bloques de memoria de forma secuencial: aprovechan la localidad espacial y castigan cualquier estructura mal alineada.
• Virtualización. Varias máquinas virtuales compitiendo por la misma L3 física se estorban entre sí. Tecnologías como el reparto de caché por aplicación de Intel permiten reservar una porción a un proceso crítico para que no se la quiten.
• Móviles. En un teléfono, mover un hilo entre un núcleo grande y otro pequeño afecta al rendimiento y al consumo; el reparto de trabajo se diseña pensando también en la caché.

No toda la caché es la del procesador

El término se usa para varias cosas, y conviene no mezclarlas:

• Caché de CPU: hardware dentro del procesador. No la configuras ni puedes vaciarla; la gestiona él.
• Caché de disco: el sistema operativo guarda en RAM los datos leídos del disco para no volver a golpearlo. Es la razón de que un sistema con memoria de sobra sirva archivos repetidos mucho más rápido. En Windows existen incluso dos modos, uno que retrasa la escritura a disco y otro que la fuerza, y su propia documentación sobre caché de archivos lo explica con detalle.
• Caché del navegador: imágenes, scripts y estilos guardados en tu equipo para no descargarlos en cada visita. Esta sí puedes limpiarla, y a veces toca.
• Caché de aplicación: sistemas como Redis o Memcached que guardan resultados frecuentes entre la aplicación y la base de datos.
• Caché de CDN: servidores intermedios que sirven contenido sin generarlo en origen. Menos latencia para el usuario y menos carga en el servidor.
• Caché de GPU y TLB: la tarjeta gráfica tiene su propia jerarquía, y el procesador guarda aparte, en la TLB, las traducciones de direcciones virtuales a físicas para no repetir ese cálculo en cada acceso.

Cómo vaciar la caché (cuando toca)

La caché del procesador no se vacía: no hay botón. Lo que sí puedes limpiar es la del navegador, y muchas veces es la solución a una web que muestra una versión antigua o se comporta raro:

• Atajo rápido: recarga forzada con Ctrl+F5 (Windows) o Cmd+Shift+R (macOS).
• Completa: en Ajustes del navegador, «Borrar datos de navegación» → imágenes y archivos en caché.
• Móvil: en los ajustes del navegador, «Borrar caché» o «Borrar datos del sitio» para la web concreta.

Si eres quien administra una web, la otra caché que importa es la del servidor o la CDN: ahí no se trata de borrar a lo loco, sino de invalidar lo justo. Y no hace falta adivinar cuándo: el protocolo HTTP tiene sus propias reglas. Una cabecera Cache-Control fija cuánto vale una respuesta; un ETag o un Last-Modified permiten preguntar al servidor si sigue siendo la misma, y si lo es responde con un 304 Not Modified sin reenviar el contenido. Todo eso está definido en el estándar del IETF RFC 9111 (HTTP Caching), y la guía de caché HTTP de MDN lo traduce a la práctica: cachear con criterio ahorra ancho de banda, y cachear de más es lo que provoca que los usuarios vean versiones viejas.

Cómo saber si la caché te está frenando

La buena noticia es que no hay que intuirlo: se mide. Los procesadores llevan contadores de rendimiento que anotan aciertos y fallos, y hay herramientas para leerlos sin tocar el hardware.

En Linux, perf stat muestra de un vistazo la tasa de fallos de caché y las instrucciones por ciclo (IPC) de un proceso; un IPC bajo con la CPU al cien por cien es la firma clásica de un cuello de botella en memoria. En Windows, el analizador de rendimiento y las herramientas de Intel y AMD permiten llegar al mismo sitio. La métrica útil no es «cuántos fallos hay» —siempre los hay—, sino cuántos se producen por cada mil instrucciones y si bajan al cambiar el programa.

Y una vez medido, las contramedidas son pocas y conocidas: recorrer los datos en el orden en que están en memoria, agrupar la información que se usa junta en una misma estructura, trocear los bucles que trabajan sobre bloques grandes (blocking o tiling) y evitar que dos hilos escriban en posiciones distintas de la misma línea de caché, porque se invalidan entre sí sin necesidad. Nada de esto es magia: es tener presente que una línea son 64 bytes y que traerla cuesta.

Cuándo la caché explica que algo «vaya lento»

Una caché de CPU no se rompe como un disco: no hay log, no se reinicia, no se puede vaciar. Lo que puede pasar es que el patrón de acceso del sistema no le siente bien. Cuando eso ocurre, aparecen tres señales que conviene reconocer:

• CPU alta con poco avance. El procesador está ocupado esperando datos, no ejecutando trabajo útil.
• Latencia irregular. Todo va bien hasta que varios procesos compiten por el mismo espacio de caché y se van desalojando datos entre ellos (el famoso thrashing).
• Algo que no escala. Añadir hilos o procesos no mejora nada, o incluso empeora, porque la contención supera al beneficio.

Si reconoces el patrón, el siguiente paso no es cambiar el procesador, sino revisar qué hace el programa con la memoria. Casi siempre es más barato reordenar datos que comprar hardware.

Preguntas frecuentes

¿Cuál es la diferencia entre caché y RAM?

La caché es pequeña, carísima y vive pegada al procesador; su trabajo es que la CPU no espere a la RAM. La RAM es más grande y algo más lenta, y existe para que el sistema no tenga que tirar del disco. Son dos escalones distintos.

¿Se puede ampliar la caché de un procesador?

No. Viene integrada en el chip y no se cambia. Por eso, cuando comparas procesadores, la cantidad de caché es un dato fijo que marca diferencias, especialmente en cargas repetitivas.

¿Qué es un fallo de caché (cache miss)?

Es el acceso que no encuentra el dato en caché y obliga a ir a un nivel inferior, normalmente la RAM. Cada fallo cuesta decenas o cientos de ciclos, así que lo que de verdad pesa no es el fallo aislado, sino la proporción de fallos sobre el total.

¿Es malo vaciar la caché?

No es malo, pero tiene un precio: la próxima vez que visitas esa web, todo se descarga de nuevo. Por eso no conviene hacerlo «por si acaso»; solo cuando sospechas que estás viendo una versión antigua.

¿La caché del navegador hace que las webs vayan más lentas?

Al contrario: bien usada, hace que carguen antes. El problema no es que exista, sino que guarde una versión desactualizada. De ahí que las webs serias combinen caché con validación: el navegador reutiliza lo que no ha cambiado y pregunta solo por lo que sí.

¿Por qué el archivo se abre más rápido la segunda vez?

Porque la primera lectura lo deja en la caché de disco, y la segunda se sirve desde memoria en lugar del almacenamiento. Si esa diferencia te parece enorme, merece la pena revisar por dónde van los cuellos de botella del equipo.

Conclusión

La caché es de esas piezas que no se configuran ni dan la cara, pero deciden si un sistema va suelto o va arrastrando. No hace falta ser ingeniero de microarquitectura para aprovecharla: basta con entender que existe una escalera —L1, L2, L3, RAM, disco— y que cada escalón que bajas cuesta tiempo. Y que casi siempre el problema no es la potencia del procesador, sino a qué distancia tiene los datos.

Y al próximo «va lento», antes de tirar de apágalo y enciéndelo, pregúntate algo tan simple como esto: ¿está el procesador trabajando… o esperando?