Arquitectura de computadores

Por dentro, una computadora es mucho menos misteriosa de lo que parece y mucho más ingeniosa de lo que uno recuerda. Todo empieza en un componente, la CPU, que hace una sola cosa pero la hace a una velocidad asombrosa: ejecutar instrucciones simples, una tras otra, a razón de miles de millones por segundo. Sumar dos números, mover un dato de un lado a otro, decidir que instrucción viene después. Sobre esos gestos minúsculos se construye todo lo demás.

Esta ficha recorre la máquina por dentro, y explica por qué el rendimiento real depende de cosas que rara vez se mencionan, como la localidad o la jerarquía de memoria.

La CPU y el ciclo de reloj

El corazón de la CPU es la unidad aritmético lógica, o ALU, que efectúa las operaciones, y un conjunto pequeño de cajones ultrarrápidos llamados registros, donde guarda los datos con los que está trabajando en el instante. La CPU no hace todo de golpe: avanza al ritmo de una señal de reloj, y la frecuencia de ese reloj, medida en gigahercios, dice cuantas veces por segundo puede dar un paso. Pero ojo: comparar dos procesadores por su frecuencia es como comparar dos autos solo por las revoluciones del motor. Un procesador puede hacer más trabajo por ciclo que otro, y entonces ganarle aun teniendo menor frecuencia.

Para acelerarse, las CPUs modernas arman un pipeline: en vez de terminar una instrucción antes de empezar la siguiente, dividen el trabajo en etapas y van procesando varias instrucciones a la vez, cada una en una etapa distinta, como una línea de ensamblaje. Encima intentan adivinar el resultado de los saltos (predicción de saltos) y ejecutar instrucciones por adelantado (ejecución especulativa), para no quedarse esperando. Estos trucos explican buena parte del rendimiento actual, y también algunos de los errores de seguridad más sonados, que aprovechan esas ejecuciones adelantadas.

La jerarquía de memoria y por qué la localidad lo decide todo

Los registros son rapidísimos pero escasísimos: caben unos pocos datos. La memoria principal es grande pero comparativamente lenta, y el disco es inmenso y lentísimo. Entre medio hay varias capas de cache, memorias más chicas y más rápidas que guardan lo que la CPU usa con más frecuencia. Esta jerarquía existe porque en hardware lo rápido es caro y lo barato es lento.

Y aquí aparece la idea que más decide el rendimiento real: la localidad. Si tu código accede a datos que están juntos en memoria y los reutiliza, la cache los retiene y todo vuela. Si salta de un lado a otro tocando datos dispersos, cada acceso se pierde hasta la memoria principal y el programa se arrastra. Dos algoritmos pueden tener la misma complejidad teórica y, sin embargo, uno ser diez veces más rápido simplemente porque respeta la localidad y mantiene calientes sus datos en cache. La teoría del costo ignora la cache; la máquina, no.

RISC contra CISC, y la guerra de las arquitecturas

Las instrucciones que una CPU entiende forman su conjunto de instrucciones, la ISA. Históricamente hubo dos filosofías. CISC, encarnada por x86, agrega instrucciones complejas que hacen mucho trabajo de una sola vez. RISC, encarnada por ARM y por RISC-V, apuesta por instrucciones sencillas y rápidas, pocas pero bien pulidas, que el procesador despacha con eficiencia.

Durante años la distinción importo mucho. Hoy los detalles se han difuminado: los procesadores x86 modernos traducen internamente sus instrucciones complejas a operaciones simples, casi como si fueran RISC por dentro, y ARM ha ganado terreno hasta llegar a las computadoras de escritorio. La lección es que la arquitectura importa, pero importa cada vez menos para quien escribe software: lo que de verdad pesa es como se lleva tu código con la jerarquía de memoria.

Por qué se acabó la carrera de la frecuencia

Durante décadas, cada generación de procesadores subía su frecuencia y era más rápida que la anterior. Esa carrera se detuvo. Subir la frecuencia significa aumentar el calor y el consumo eléctrico, y llegó un punto en que los procesadores simplemente no se podían enfriar más. La industria cambio de estrategia: en vez de hacer un núcleo más rápido, empezó a poner varios núcleos en un mismo chip. Un procesador multinúcleo de hoy no es una CPU ultraveloz, sino varias CPUs moderadas que trabajan en paralelo.

Ese giro puso la concurrencia en el centro. Durante años, los programas se volvían más rápidos gratis, simplemente corriendolos en un procesador nuevo. Esa época terminó. Hoy, para aprovechar una máquina, un programa tiene que saber dividir su trabajo entre núcleos, y eso es justo lo difícil: la programación concurrente de la que se ocupa la ficha de sistemas operativos.

La GPU, especialista en paralelismo masivo

Frente a la CPU, generalista y ágil, está la GPU, nacida para dibujar gráficos y hoy crucial para otras tareas. La GPU tiene miles de núcleos diminutos, incapaces cada uno de las sutilezas de un núcleo de CPU, pero capaces de hacer la misma operación simple sobre montones de datos al mismo tiempo. Ese paralelismo masivo la hace ideal para todo lo que se reduce a aplicar el mismo cálculo a muchos elementos: renderizar imágenes, desde luego, pero también entrenar modelos de inteligencia artificial o procesar señales. Es el ejemplo más claro de que la forma del hardware determina para que sirve: una GPU no es una CPU más potente, es una máquina distinta, buena para cosas distintas.

La lección de la máquina

Conocer la arquitectura no sirve para armar computadoras, sino para entender por qué los programas se comportan como lo hacen. El rendimiento real no viene de la frecuencia, sino de mantener los datos calientes en cache; el paralelismo ya no es opcional, porque los núcleos dejaron de acelerarse; y cada pieza de hardware, de la CPU a la GPU, tiene una forma propia que dicta para que sirve. Quien escribe software ignorando todo esto trabaja a ciegas; quien lo tiene presente, entiende de inmediato por qué un cambio pequeño puede acelerar un programa entero.