Mostrando entradas con la etiqueta GPU. Mostrar todas las entradas
Mostrando entradas con la etiqueta GPU. Mostrar todas las entradas

jueves, 26 de febrero de 2026

La cadena de producción en computación: el viaje de la especialización de los procesadores

Termino con este post una serie un poco espontánea (no tenía decidido realmente hacer una serie, sino que ha salido así) que he dedicado al mundo del hardware y los procesadores, tema que, la verdad sea dicho, apenas había abordado antes en este blog.

Y mi interés sobre el particular ha surgido suscitado por las reflexiones sobre algunos episodios en que he participado del podcast 'Código abierto' y en que hemos hablado del tema, y de forma más inmediata por la lectura del libro 'Mastering NVIDIA CUDA and Tensor Cores' que explica la arquitectura de procesadores de NVIDIA y cómo se programa con ellos.

En este post, simplemente quiero resaltar una paradoja y una metáfora respecto a los procesadores.

La paradoja es que, a medida que queremos conseguir más potencia, acudimos a procesadores más sencillos en cierto sentido. La metáfora es la de una cadena de producción en computación.

Y todo ello, aderezado con una especie de arqueología tecnológica o 'memoria histórica' de la computación.


Recordando los microprocesadores para PC


Y empiezo un poco con esa memoria histórica, casi con esa nostalgia.

Pues si, no puedo dejar de recordar los tardíos años ochenta o principios de los noventa cuando asistimos, y en mi caso con mucha implicación, a la aparición y expansión súbita de los ordenadores personales, los famosos PC.

Recuerdo que mi primer ordenador personal, un Inves 640-X, incorporaba un microprocesador Intel 8088, aunque en aquel momento ya la mayoría de PCs venían dotados de un Intel 8086. Y si, para quien no lo recuerde y a lo mejor hoy en día le resulte extraño, Intel dominaba de forma aplastante el mundo de los microprocesadores para ordenador personal y marcaba completamente la pauta.

Todas las revistas de informática, abundantes en aquella época, y todos los aficionados, asistíamos con expectación a cada lanzamiento de un nuevo microprocesador de Intel. El siguiente de importancia fue el 80286. Luego vendría el 80386, hasta que Intel decidió cambiar un poco la marca y, al que debía llamarse, siguiendo la misma lógica, como 80596, decidió denominarlo 'Pentium'.

Más allá de la curiosidad y la nostalgia, lo relevante de cara a este post es hacer ver que cada nuevo microprocesador, que era más potente que el anterior, aparte de mejoras como acelerar la señal de reloj, se hacía más y más complejo, soportaba más y más instrucciones, se hacía físicamente más y más grande y, energéticamente, disipaba más y más calor.

Un poco como anticipo de lo que vendría después, y que en seguida comento, para algunos ordenadores un poquito más especializados y más potentes, se les dotaba del llamado coprocesador matemático, una especie de microprocesador pero ya no de propósito general sino especializado en operaciones matemáticas. 


Arquitecturas CISC y RISC


No recuerdo bien los años, pero creo que, aunque tiene antecedentes más antiguos, hacia los años 90 se comenzó a hablar con más fuerza del concepto de RISC. ¿Qué era eso?

Bueno, los microprocesadores como los de Intel, evolucionaban soportando más y más instrucciones y constituían, pues, lo que se denominaba CISC ('Complex Instruction Set Computers').

Sin embargo, RISC ('Reduced Instruction Set Computers'), y a pesar de buscar precisamente una mayor eficiencia en la computación, apostaba en la dirección contraria: procesadores con un juego de instrucciones pequeño (reducido) y que, aparte de otras optimizaciones y mejoras ya buscaba el paralelismo en la computación. Y, realmente, hablar de RISC se convirtió en una especie de sinónimo de altas prestaciones.

Si la memoria no me falla, más que a los ordenadores personales, ésta filosofía se aplicaba a servidores o a las entonces llamadas 'workstations' (típicamente de Hewlett-Packard o Sun Microsystems) que, aunque tenían características parecidas a los ordenadores personales, eran más potentes, utilizaban sistemas operativos UNIX y se las consideraba más del ámbito profesional que personal. 


Las GPU


Abandono un poco ya la memoria nostálgica para situarme en el presente. En este presente, y aunque ya están entre nosotros hace algunos años, son populares las famosas GPU ('Graphical Processing Units').

En cierto modo, las GPU son herederas de los coprocesadores matemáticos porque, en el fondo, eso es o que son. Salvo en casos muy particulares, las GPU no son una alternativa a las CPU ('Central Processsing Unit'), es decir, los microprocesadores tradicionales, sino unas compañeras de estos. La computación general suele correr a cargo de CPUs, pero ciertos tipos de cálculos, se delegan en GPUs.

¿Qué cálculos?

Pues las GPU están especializadas en operaciones algebraicas del mundo de los vectores, las matrices y los tensores. Se trata de un tipo de cálculos que son fundamentales en todo lo que tiene que ver con gráficos y movimiento y por eso las GPUs surgieron para apoyar el mundo de los videojuegos y aplicaciones similares, de ahí el nombre de 'gráfico' que puede sorprender hoy en día.

Y es que, no sólo el mundo de la imagen en movimiento se apoya en cálculos algebraicos, sino que también el 'machine learning' y muy particularmente el 'deep learning' se implementa, fundamentalmente con ese álgebra lineal en espacios vectoriales... y eso explica la popularidad y demanda actual de GPUs... y el éxito empresarial de NVIDIA.

Las GPUs apuestan muy decididamente por el paralelismo, condicionando, como vimos en un post anterior, la forma de programar con ellas en el bajo nivel. Pero hago notar que, en el fondo, en busca de la eficiencia computacional, sufren una enorme especialización: ya no son procesadores de propósito general como las CPU, sino procesadores muy especializados en computación algebraica paralela. 

La transacción: especialización a cambio de potencia.


Las TPU


Y un caso más particular son las TPU ('Tensor Processing Units') o, al menos, los 'tensor cores' de NVIDIA, que se centran en una única operación: la multiplicación de matrices con acumulación consiguiendo una espectacular eficiencia en esa operación.

Estamos ante una 'super-especialización' pero que tiene sentido porque se trata de una operación usada masivamente en el deep learning actual, que ya sabemos que es enormemente demandante, especialmente en el caso de los grandes modelos generativos.

Estamos extremando en este caso la transacción de especialización a cambio de potencia, pero sigue teniendo una total lógica técnica e incluso económica.


La especialización y las cadenas de producción en computación


Y esto me lleva a la metáfora. No he podido dejar de pensar en los principios de la organización científica de Taylor, origen de las cadenas de producción industriales.

En esas cadenas de producción, los trabajadores (y también las máquinas) dejan de ser personas o máquinas de propósito general, como ocurriría en el caso de la artesanía o del trabajo intelectual, para especializarse en tareas muy concretas, tareas que realizan una y otra vez de forma muy eficaz y, sobre todo, muy eficiente. 

Procesadores como las GPUs o las TPUs no dejan de ser, en la computación, algo así como los trabajadores especializados de una cadena de producción, en este caso una cadena de producción de la computación, mientas que las CPU se quedan un poco como los artesanos o intelectuales de esa computación.

Y, ante la demanda masiva de computación, procedente sobre todo de la inteligencia artificial, hemos debido poner en marcha una capacidad productiva en computación, altamente especializada y, por ello, altamente eficiente, pero apoyada en procesadores especializados.


Conclusiones


El conseguir unas mayores dosis de eficiencia en computación ha llevado, a lo largo de los años, a buscar esquemas de procesadores especializados en operaciones concretas y con altas dosis de paralelismo.

En ese sentido, y aunque sea metafóricamente, lo que buscamos son 'trabajadores especializados', y muy eficientes integrados en una suerte de cadena de producción de computación.


Artículos de este blog relacionados


lunes, 23 de febrero de 2026

Una aparente paradoja: el retorno de la programación de bajo nivel

En los dos últimos post he hablado de dos fenómenos, en apariencia independientes y casi contradictorios y que, precisamente, van a colisionar en este artículo. 

Hablo, por un lado, de la evolución del desarrollo software que explicaba en 'La evolución del desarrollo software: productividad frente a deskilling' y que nos muestra una clara evolución a una programación cada vez más alejada de los detalles técnicos y más centrada en la productividad y cercanía a las necesidades funcionales. Una programación, en fin, de alto nivel.

Por otro, en el último post, 'El retorno del hardware: razones y perspectivas', destacaba cómo el hardware, al que hacía años que apenas dábamos importancia, ha vuelto a cobrar valor técnico, económico y estratégico, debido en buena medida a las demandas técnicas y de volumen que impone la inteligencia artificial generativa.

En este post examino un fenómeno en cierto modo sorprendente y contradictorio: el retorno, no ya del hardware, sino de la programación de bajo nivel.


Programación de bajo nivel


Como paso previo, y por si algún lector no esta suficientemente advertido, aclarar a qué nos referimos con lo de la programación de bajo nivel.

La programación de bajo nivel es la creación de un software que trabaja en temas de detalle y, sobre todo, muy cerca del procesador, ya sea un microprocesador de tipo CPU ('Central Processing Unit') tradicional, o los modernos GPU ('Graphical Processing Unit') o TPU ('Tensor Processing Unit'). La programación de bajo nivel suele implicar conocer bien el hardware, tanto los procesadores como la estructura de registros y de la memoria o cómo relacionarse directamente con dispositivos y periféricos.

Con la programación de bajo nivel normalmente no podemos resolver grandes problemas funcionales, pero, a cambio, podemos conseguir nuevas capacidades y, sobre todo, si se hace bien, unas altísimas prestaciones y una gran optimización computacional. Y eso es así porque al trabajar muy cerca del hardware y conociendo cómo funciona, explotamos al máximo sus capacidades y, además, hacemos ´únicamente lo que se necesita'.

El software de alto nivel, por su lado, en su búsqueda de generalidad y facilidad de uso, añade ingentes cantidades de lógica adicional no estrictamente necesaria en muchos casos y, además, al alejarse del hardware no optimiza su uso. Prima la productividad y facilidad de uso frente a la optimización computacional.


¿Por que realizar programación de alto nivel?


En realidad lo acabamos de mencionar y lo vimos también en un post anterior: favorecemos la programación de alto nivel porque es muchísimo más productiva en términos de cantidad de software producido, porque además es más sencilla de llevar a cabo (lo que redunda en productividad y, además, elimina barreras de entrada de profesionales) y, finalmente, porque permite concentrarse más en los problemas de negocio o en lo que realmente queremos proporcionar.

Por eso, una vez que el hardware alcanzó una potencia tal que ya no nos exigía su optimización para tener buenos resultados de prestaciones, se ha ido favoreciendo la programación de alto nivel


¿Y por qué realizar programación de bajo nivel?


Y, entonces ¿Por qué podríamos interesados, a estas alturas, en hacer programación de bajo nivel?

Bueno, en algunos casos no hay más remedio. Por ejemplo, para relacionarse con un nuevo dispositivo o periférico, hay que comenzar trabajando en el bajo nivel, aunque luego, de cara a otros programadores se preparen ya APIs o conectores simplificados.

Un poco en esa misma línea, si estás programando un sistema operativo no tienes más remedio que enfrentarte al bajo nivel porque una de las funciones principales de un sistema operativo es precisamente relacionarse con el hardware y ofrecer, hacia el exterior, un modo abstracto, una máquina virtual que independice a aplicaciones y programadores de ese hardware. Los programadores de esas aplicaciones pueden trabajar en el alto nivel, pero los del sistema operativo están obligados a relacionarse con el bajo nivel.

Pero hay algo que me importa mucho más ahora mismo, en relación con lo que quiero exponer en este artículo: utilizas la programación de bajo nivel porque cuando quieres optimizar el funcionamiento, cuando quieres maximizar las prestaciones, cuando quieres 'exprimir al máximo' la capacidad del hardware, tienes que acercarte al hardware, tienes que conocerlo, tienes que, en fin, realizar programación de bajo nivel.


Nuevas arquitecturas de procesadores


Durante bastantes años, los procesadores, aunque evidentemente evolucionaban, y no poco, eran de tipo CPU.

Con el auge de aplicaciones de gran riqueza gráfica como los videojuegos, nacieron y cobraron importancia las GPU ('Graphical Processing Unit'). Pero la auténtica explosión ha venido de la mano del machine learning al 'descubrir' que las operaciones algebraicas que se utilizan en el mundo gráfico, son similares a las que se utilizan en machine learning, fundamentalmente en redes neuronales. En ambos mundos abundan las operaciones con vectores, matrices y tensores. Y las GPU lo que hacen es optimizar esas operaciones.

En un paso más allá en especialización, existen las TPU ('Tensor Processing Unit') o los 'tensor cores' de NVIDIA que, pese a que suenen a algo muy potente, en realidad se especializan en una única operación: la multiplicación de dos matrices y acumulación del resultado en una de ellas. En cierto modo, son elementos muy sencillos, pero altamente especializados y optimizados.


La nueva programación de bajo nivel


Aunque la programación de bajo nivel, pese a su escasa visibilidad, nunca se había ido, ahora cobra una gran importancia para explotar estos nuevos procesadores.

¿Por qué?

Pues porque estos procesadores son muy especializados pero, para que produzcan los resultados esperados, hay que programarlos conociendo cómo funcionan. Así, para explotar bien las GPU hay que convertir la resolución de nuestros problemas en operaciones de algebra lineal y, además ser capaces de definir la resolución de un problema en términos de unas funciones, los denominados 'kernel', en que la misma lógica pueda trabajar en paralelo sobre diferentes datos (por ejemplo, sobre diferentes partes de una misma matriz).

Más específico aún es el caso de los 'tensor cores' en que, para aprovecharlos, hay que ser capaces de identificar o forzar operaciones que consistan en una multiplicación de matrices seguidas por una acumulación.

Y esto no se puede hacer con sólo conocer un problema de negocio o la sintaxis de un lenguaje de programación. Para ello hay que comprender el hardware con que se trabaja y la mejor forma de obtener todo su rendimiento.

Es decir, hay que trabajar en el bajo nivel.


Deshaciendo la aparente contradicción


Y llega el momento de deshacer la aparente contradicción.

¿No habíamos dicho que la evolución del software nos conducía a una visión cada vez más alejada del hardware, una visión que en sus vertientes 'No Code' o 'Vibe coding' ni siquiera trabajaba con código fuente e incluso que en las soluciones de más alto nivel el desarrollador expresaba sus necesidades en lenguaje natural?

Si, lo habíamos dicho y así es.

Lo que ocurre que el trabajo en el bajo nivel lo realizan, comparativamente, muy pocas personas organizadas en equipos especializados. Esas pocas personas programan el software más exigente y, además, preparan componentes optimizados para su uso en el alto nivel por desarrolladores menos especializados.

Así, las típicas librerías python usadas en machine learning y deep learning, están fuertemente optimizadas a nivel interno, aunque el común de los programadores las utilicen directamente sin preocuparse de los detalles. Y no digamos ya nada cuando ni siquiera se trabaja con las librerías sino con componentes gráficos que las abstraen (caso del 'low-code / 'no-code') o cuando incluso es la inteligencia artificial la que general el código que invoca a las librerías, sin que el desarrollador sea necesariamente consciente de ello.

En el fondo, esa ha sido siempre la relación entre al bajo y el alto nivel: unos pocos equipos especializados trabajan en el bajo nivel, cerca del hardware, y preparan componentes optimizados reutilizables en el alto nivel.

Lo único que ocurre es que ahora, con la enorme demanda computacional existente y procedente de la inteligencia artificial, muy especialmente en su vertiente generativa., cobra nueva importancia el  contar con algunos de esos equipos especializados para sacar jugo a un hardware especializado y que, pese a las enormes inversiones, se nos está quedando corto en volumen. 


Conclusiones


La gran demanda computacional exigida por la inteligencia artificial generativa ha llevado al desarrollo de procesadores especializados a nivel hardware, pero el uso adecuado y óptimo de ese hardware implica el trabajo en el bajo nivel aunque luego los resultados puedan ser reutilizados vía librerías y APIs, en la programación de alto nivel.

lunes, 16 de febrero de 2026

El retorno del hardware: razones y perspectivas

¿No resulta llamativo la frecuencia con que ahora oímos hablar de asuntos que tienen que ver con el hardware

No paramos de escuchar hablar de GPUs, de NVIDIA, la empresa estrella del momento, del papel estratégico de la producción de semiconductores, de la lucha por las tierras raras y tantas cosas relacionadas con los aspectos físicos de la computación, con la microelectrónica y el hardware.

¿Qué está pasando?


El hardware como 'commodity'



Hasta no hace mucho, el hardware ha sido 'el hermano pobre' de la tecnología digital, algo de lo que se hablaba relativamente poco fuera de ámbitos especializados. 

Pasada ya hace mucho la fiebre de los ordenadores personales en que sí que nos volvíamos locos los aficionados a la informática conociendo las nuevas características del último microprocesador Intel, y ahora que la gran proliferación de servicios en la nube nos hace muchas veces casi invisible el hardware corporativo, al menos los servidores, durante muchos años apenas nos hemos fijado en el hardware.

A nivel de programación, y como revisamos en el reciente post 'La evolución del desarrollo software: productividad frente a deskilling' también nos hemos ido alejando de la realidad física que soportaba la computación, de los procesadores, las CPUs, las GPUs, etc.

Sabíamos que era necesario, claro, y que evolucionaba y mejoraba, pero lo valorábamos poco, le prestábamos poca atención y, seguramente, el número de profesionales, ya no digamos aficionados, del software, supera con mucho, con muchísimo, al de los dedicados al hardware.

Además nos acostumbramos a que el hardware fuese relativamente barato, en el caso de ordenadores personales o portátiles, y casi invisible en el caso de los servidores, por mor de los servicios en la nube.

En cierto modo, habíamos convertido al hardware en una 'commodity', necesario, pero sin valor diferencial.


Y de repente ha vuelto


Y de repente, en los últimos meses, quizá algún año, vuelve a ser importante. Vuelve a estar en el discurso técnico y en el geoestratégico. ¿Por qué?

Voy a aventurar cuatro razones:

  • La escasez relativa de la capacidad de computación
  • La escasez relativa de materiales concretos
  • La especialización de la demanda
  • Un conocimiento escaso y concentrado 

Veamos


La escasez relativa de capacidad de computación


La primera es que, lo que en su momento pudimos considerar abundante, la capacidad de computación, se nos ha vuelto escasa. 

Hablo de escasez relativa porque no es que no exista capacidad de computación. Existe mucha capacidad de computación distribuida en unidades relativamente modestas como ordenadores de sobremesa, portátiles, tablets y smartphones. Existe muchísima capacidad de computación concentrada en centros de Proceso de Datos corporativos y existe, sobre todo, una ingente capacidad de computación en los data centers de los grandes proveedores de la nube (Amazon, Microsoft, Google, IBM, etc)

Lo que pasa es que la demanda crece aun más. En parte por la digitalización creciente pero muy singularmente por la explosión de la inteligencia artificial basada en modelos muy demandantes de computación tanto en entrenamiento como en inferencia, y por la previsión de que esa demanda no vaya a hacer otra cosa que crecer y trasladarse a otros ámbitos como robots, vehículos, etc, la oferta de hardware parece que se nos está quedando corta, o amenaza con quedarse corta.

Y ya se sabe que, desde un punto de vista económico y estratégico, un recurso gana importancia cuando es escaso.


La escasez de materiales concretos


Ante la enorme demanda de microelectrónica y hardware cuando algunos de sus componentes es en sí mismos escasos, como las famosas tierras raras, se perciben como aún más escasos y, por tanto, con mucho mayor valor económico y geoestratégico. 


La especialización de la demanda de hardware


Quizá en menor medida, pero también influye creo, que ya no nos vale con un hardware más generalista, digamos una CPUs tradicionales agregadas mediante mecanismos de virtualización. Ahora los cálculos en el ámbito de la inteligencia artificial. de los videojuegos, de la realidad virtual o de la simulación,  nos reclaman procesadores especializados, procesadores especializados en los cálculos algebraicos y su realización de operaciones en paralelo (caso de los GPU, 'Graphical Processing Units') y especializados en alguna operación muy específica realizada con muchísima frecuencia (caso, por ejemplo, de las TPUs, ('Tensor Processing Units')).

La necesidad de esa especialización, de esa búsqueda de procesadores más potentes y especializados, realza y revitaliza la industria del hardware pero, además, le añade más valor diferencial. Y si no, que se lo digan a NVIDIA. 


La concentración y escasez de conocimientos


Además, y a nivel casi más geoestratégico que económico, la industria de los semiconductores está muy concentrada.

Está muy concentrada geográficamente, siendo tremendamente relevante el papel de Taiwan y está concentrada en empresas, siendo tremendamente especial el caso de la empresa holandesa ASML poseedora, hasta ahora en exclusiva, de la tecnología EUVL ('Extreme Ultra Violet Lithography').

Aunque esa concentración pudiera tener sentido económico como una forma de eficiencia considerando una cadena de suministro global, lo cierto es que es también un unto de fragilidad y, en el convulso mapa geoestratégico actual, un elemento de lucha competitiva, no ya de empresas, sino de grandes potencias.

A eso añadiría, aunque confieso que más como intuición que con base en datos, que creo que existen muy pocos profesionales en el mundo con conocimientos avanzados de microelectrónica y diseño hardware.


Perspectivas: los algoritmos frugales y la computación cuántica


¿Existe alguna vía para que se suavice esa demanda de hardware, incluso esa lucha competitiva por el mismo?

Sinceramente, a corto plazo no veo que la atención en el hardware y, sobre todo, la lucha competitiva y geoestratégica él mismo vaya a disminuir. No veo que la demanda vaya a bajar, sino todo lo contrario, y no veo mecanismos para aumentar de forma sencilla y eficiente la oferta.

Fantaseando un poco, no obstante, apuntaría a dos posibilidades, aunque la segunda no es de corto plazo.

La primera sería que la industria virase, pensando en este caso en la inteligencia artificial, del uso de los grandes modelos de lenguaje, a los denominados pequeños modelos de lenguaje y/o que se encontrase una algoritmia radicalmente diferente a la utilizada últimamente, muy apoyada en la arquitectura transformer, y que esa nueva algoritmia fuese muchísimo más frugal en necesidades de computación. No es que crea que esa es una posibilidad del todo realista en sí misma e, incluso, caso de conseguirse esa algoritmia, a lo mejor nos encontrábamos con más despliegues, más caso de uso con lo que, aunque cada modelo consumiese mucho menos, la demanda global podría seguir creciendo.

Otra posibilidad, pero no es de corto plazo, es la llegada real, con viabilidad comercial y a gran escala, de la computación cuántica. Dada su enormemente superior capacidad de computación para cierto tipo de aplicaciones (incluyendo el machine learning), eso podría llevar a una drástica disminución de demanda del hardware basado en semiconductores. Pero este escenario, caso de ser realista, no es inminente y, como mínimo, parece que habrá que esperar cinco años, si no diez, o quién sabe cuánto.


Conclusiones


El hardware parece que se ha vuelto a poner de moda. Y hay razones de aumento de demanda, de especialización y de escasez de recursos que justifican el aumento de su valor discursivo, económico y geoestratégico.

Y parece que, al menos durante unos pocos años, esa importancia se va a mantener.