Daniel López Azaña

Tema

Social Media

Blog

GNU/Linux, Open Source, Cloud Computing, DevOps y más...

Diferencias entre CPU física, CPU lógica, Core/Núcleo, Thread/Hilo y Socket

single-core-hyperthreading-cpu-diagram

Cuando tratamos de conocer la arquitectura y prestaciones a nivel de CPU de una máquina mediante comandos Linux como nproc o lscpu , muchas veces nos encontramos con que no somos capaces de interpretar sus resultados porque confundimos términos como CPU física, CPU lógica, CPU virtual, núcleos o cores, threads, sockets, etc. Si a esto le añadimos conceptos como HyperThreading (no confundir con multithreading)), llega un momento en que ya no podemos estar seguros de cuántos cores tiene nuestra máquina, no entendemos por qué comandos como htop nos indican que tenemos 8 cpus cuando creíamos que habíamos comprado un único procesador quad-core, etc. En fin, un lío.

Salida del comando htop

Para aclararlo voy a explicar de forma gráfica mediante un par de diagramas todos estos conceptos. Espero que de solo un vistazo te quede todo esto mucho más claro y no vuelvas a tener nunca más este tipo de dudas.

Los orígenes: CPU’s de un sólo núcleo y aparición del hyperthreading

Antes de que aparecieran conceptos como multicore, cpu virtual o lógica, etc., allá por la época de los procesadores Pentium, la mayoría de los ordenadores montaban en su placa base un único chip de considerable tamaño que llamábamos simplemente CPU, microprocesador o sencillamente procesador. Sólo algunos ordenadores empresariales o servidores más grandes que requerían una mayor capacidad de procesamiento se podían permitir montar 2 ó más de estos chips en la misma placa: eran los sistemas multiprocesador. Estos chips se comunicaban con el resto de elementos de la placa base a través de un conector o socket. Y la matemática era de lo más sencilla: tantos conectores o sockets tenía una placa, tantas CPU podía tener como máximo una máquina. Si se quería mayor capacidad de procesamiento, tan sólo había que buscar una máquina con un mayor número de estos procesadores o esperar a que éstos evolucionaran para ofrecer mayores prestaciones.

Pero entonces Intel se percató de que la comunicación entre los distintos procesadores de un sistema multiprocesador era muy ineficiente, pues ésta se tenía que realizar a través del bus del sistema , que trabajaba a una velocidad normalmente bastante inferior a la de los propios procesadores, por lo que se formaban cuellos de botella que impedían sacar todo el partido posible a la capacidad de cómputo que ofrecía cada CPU.

Diagrama de CPU de un solo núcleo con HyperThreading

Para tratar de mejorar esta situación se inventó la tecnología HyperThreading, que duplicó dentro del chip del procesador varios de sus elementos internos como registros o memorias caché de primer nivel de modo que se pudiera compartir información entre dos hilos de ejecución distintos sin tener que pasar por el bus del sistema con los correspondientes problemas de cuellos de botella y pérdidas de velocidad. Esto también permitía que si un proceso debía quedar a la espera de una interrupción, por ejemplo, otro proceso pudiera seguir haciendo uso de la CPU sin que ésta se quedara parada.

De este modo se conseguía acelerar diversos procesos y comenzaron a ofrecerse procesadores con un mayor rendimiento global que los tradicionales, y al sistema operativo se le «engañaba» porque se le ofrecían 2 cpus virtuales o lógicas (LCPU) en lugar de una sola, dado que se le permitía ejecutar 2 procesos «al mismo tiempo». Pero es importante tener claro que en realidad no se alcanzaba un rendimiento equivalente al doble respecto a un procesador tradicional, ni en realidad se podían ofrecer capacidades completas de procesamiento en paralelo.

Así, desde el punto de vista de Linux o de cualquier otro sistema operativo, una máquina con 1 único procesador de 1 único core o núcleo, pero con la tecnología HyperThreading, aparecería ante nuestros ojos como que tiene 2 CPU’s. Pero se trataría de 2 cpus lógicas correspondientes a 1 única CPU física.

Una vuelta de tuerca más: aparición de las arquitecturas multicore

Pero tal y como decía en el apartado anterior, aunque las CPU’s con hyperthreading ofrecen mayor capacidad de procesamiento, no pueden llegar a ofrecer las características de 2 procesadores completos, por lo que se decidió dar una vuelta de tuerca más y se consiguió miniaturizar todos los componentes de un procesador y encapsularlos junto a los de otros en una única pastilla o chip. A cada uno de esos procesadores encapsulados se les llamó cores o núcleos , y con ello se consiguió que la comunicación entre ellos se realizara de una forma mucho más rápida a través de un bus interno integrado en la propia pastilla de silicio sin tener que recurrir por tanto al bus del sistema , mucho más lento.

Diagrama de CPU quad-core con HyperThreading

Al contrario que en el caso de la tecnología HyperThreading, en este caso sí tendríamos a todos los efectos varias cpus completamente independientes, una por cada core o núcleo. De hecho de cara al rendimiento es mejor tener un único procesador multicore que el número equivalente de CPU’s de un solo core en una misma placa. Por supuesto seguiría siendo mejor tener 2 procesadores dual-core que uno solo, pero aún mejor sería tener un único quad-core.

A nivel de sistema operativo, al usuario de un sistema con 1 procesador quad-core se le indicaría que tiene 4 CPU’s, pero serían 4 cpus lógicas (LCPU), no físicas. Si además ese procesador incorporara la tecnología HyperThreading, los comandos como htop o nproc indicarían que hay 8 cpus en el sistema, pero ofrecería un menor rendimiento que si se trataran de 8 cpus provenientes de un único procesador octa-core sin HyperThreading.

1 LCPU = 1 thread

CPU quad-core con HyperThreading en Windows

Por último comentar que a veces se indica que un procesador ofrece por ejemplo un total de 4 threads, o que tiene 2 threads por núcleo. Esto se refiere simplemente a que permiten un determinado número de hilos de ejecución o trabajos de procesamiento simultáneamente, y esto sería el equivalente a la capacidad de procesamiento que ofrece una LCPU. Si un procesador permite 2 threads por núcleo quiere decir que tiene HyperThreading, y si no lo normal es que el número de cores coincida con el de threads.

CPU lógica vs CPU virtual

El término CPU virtual es comparable al de CPU lógica, pero introduce un cierto matiz, ya que se encuadra más en términos de virtualización informática. Se refiere a aquellas cpus mapeadas a una máquina virtual desde el hardware subyacente del host, que pueden ser cpus físicas o lógicas, con HyperThreading o no. Pero normalmente 1 cpu lógica del sistema host se mapea a 1 cpu virtual dentro de la máquina virtual, por lo que se podría decir que son términos casi equivalentes.

Lectura recomendada:
Cómo saber cuántos procesadores y núcleos tiene una máquina Linux

CPU HyperThreading
Daniel López Azaña

Sobre el autor

Daniel López Azaña

Emprendedor tecnológico y arquitecto cloud con más de 20 años de experiencia transformando infraestructuras y automatizando procesos.

Especialista en integración de IA/LLM, desarrollo con Rust y Python, y arquitectura AWS & GCP. Mente inquieta, generador de ideas y apasionado por la innovación tecnológica y la IA.

Artículos relacionados

terraform-and-route53-logos

Cómo importar rápidamente todos los registros de una zona DNS de Route53 en Terraform

El comando terraform import nos permite importar en HashiCorp Terraform recursos que ya existían previamente en el proveedor con el que estemos trabajando, es este caso AWS. Sin embargo, sólo permite importar dichos registros uno por uno, con una ejecución de terraform import cada vez. Esto, aparte de ser tremendamente tedioso, en algunas situaciones se vuelve directamente impracticable. Este es el caso de los registros de una zona DNS de Route53. La tarea puede resultar inabarcable si tenemos varias zonas DNS, y cada una tiene decenas o cientos de registros. En este artículo te ofrezco un script en bash que te permitirá importar en Terraform todos los registros de una zona DNS de Route53 en cuestión de segundos o de pocos minutos.

8 de febrero de 2022
Script para cambiar automáticamente todos los volúmenes gp2 a gp3 con aws-cli

Script para cambiar automáticamente todos los volúmenes gp2 a gp3 con aws-cli

El pasado diciembre Amazon anunció sus nuevos volúmenes EBS gp3, los cuales ofrecen mejores prestaciones y un ahorro en el coste del 20% respecto a los que se venían utilizando hasta ahora, los gp2. Pues bien, tras probar satisfactoriamente estos nuevos volúmenes en varios clientes, no puedo hacer otra cosa más que recomendar su utilización, pues son todo ventajas y en estos 2 meses y medio que han transcurrido desde el anuncio no he apreciado ningún problema ni efecto secundario.

16 de febrero de 2021
AWS security groups

Cómo actualizar automáticamente todos nuestros grupos de seguridad EC2 de AWS cuando nuestra IP dinámica cambia

Uno de los mayores fastidios cuando trabajamos con AWS y nuestra conexión a Internet tiene IP dinámica es que cuándo ésta cambia, automáticamente dejamos de tener acceso a todos los servidores y servicios que habíamos protegido mediante un grupo de seguridad EC2 cuyas reglas sólo permiten el tráfico a ciertas IP’s específicas en lugar de abrir las conexiones a todo el mundo (0.0.0.0/0).Ciertamente lo más sencillo es siempre indicar en el grupo de seguridad que permitimos el tráfico en un puerto a todo el mundo, de modo que aunque tengamos IP dinámica en nuestra conexión a Internet siempre podremos continuar accediendo aunque ésta cambie. Pero abrir el tráfico a un puerto a todo el mundo no es la forma correcta de proceder desde el punto de vista de la seguridad, pues entonces cualquier atacante podrá tener acceso a ese puerto sin restricciones, y eso no es lo que queremos.

12 de enero de 2021

Comentarios

Julián 28 de junio de 2018
Muy bueno y completo! Gracias
Cristian 28 de septiembre de 2018
En pocas y llanas palabras, muy bueno, seguiré consultando temas de tu blog.
Miguel 8 de noviembre de 2018
Me gustó mucho la explicación, gracias amigo
sergio 24 de marzo de 2019
Perfecta la síntesis y explicación. Muy agradecido!!
Roberto Metcalfe 29 de abril de 2019
Súper gráfica la explicación. Gracias.
Edgar 7 de mayo de 2019
Gracias por la explicación, muy clara!
Juan Diego Chica Salazar 17 de mayo de 2019
excelente, sencilla explicación
Erick Antonio 30 de enero de 2020
Gracias por la explicacion, bastante sencilla
Andres Ivan Rodriguez Galan 1 de abril de 2020
Espectacular la explicación, el contexto del origen es completamente necesario para entender el cuento. Muchas Gracias, tremendamente util. Solo me queda la duda de si dependiendo de los sistemas operativos esto tiene alguna implicación, es decir es distinto el manejo en un solaris a un Linux en cuanto a la cantidad de CPU?
Daniel 20 de abril de 2020
Gracias Andrés. En principio todos los sistemas operativos deberían tener la misma constancia del hardware subyacente que manejan, es decir, que todos reconocerán el mismo número de CPU's, núcleos, sockets, etc. si ofrecen soporte para ello. Es decir, por ejemplo un sistema operativo X podría no tener soporte para Hyper Threading y no aprovechar esa característica. Y aunque sí ofrezcan soporte, cada uno gestionará esos recursos de forma particular y no tiene por qué coincidir con cómo lo hacen Linux u otros sistemas operativos.
Mila 29 de octubre de 2020
Muchas gracias, es un articulo muy didactico y claro. ¿tienes alguna recomendación de lectura o quizás un articulo tuyo para entender también el concepto de socket en entornos virtualizados cuando configuran VM con varias vCPUs? por ejemplo en VMware.
Daniel 27 de febrero de 2021
Lo siento, no dispongo de ese artículo, pero tomo nota, ¡gracias!

Enviar comentario