Cuando pretendemos incrementar simultánea e indefinidamente la velocidad y la capacidad de computación chocamos con limitaciones insalvables. Una de ellas, como traté de explicar someramente en la entrada Un importante límite físico, se deriva de la velocidad de transmisión de las ondas por los conductores, velocidad relativista. Cuanto más corta es la onda más limitada es la distancia a la que la formación de ondas estacionarias puede provocar fenómenos de resonancia destructiva.
En las redes de alta tensión una frecuencia relativamente baja, 50 Hz, (50 ciclos por segundo), produce ondas muy largas que limitan la distancia entre nodos a unos pocos cientos de kilómetros. En los circuitos de los ordenadores la frecuencia de reloj ha llegado a ser de casi 5 GHz, unos cien millones de veces superior, lo que lleva a longitudes de onda muy cortas y limita las distancias a pocos centímetros. Esta es una de las razones, no la única, de la creciente miniaturización.
La carrera por la velocidad está llena de obstáculos.
En los ordenadores, la velocidad de la computación está ligada a la de transmisión de las interminables secuencias de "ceros" y "unos" que emplea el lenguaje de máquina, absolutamente ininteligible para la mente humana. Esto obliga a emplear lenguajes de programación accesibles a la capacidad mental del programador, y de compiladores que puedan efectuar la traducción entre ambos lenguajes.
La complejidad física se añade a la lógica. Para que el proceso no sea una única y larguísima secuencia se impone la simultaneidad de varios desarrollos paralelos entrelazados. La historia de la computación es una carrera por acelerar las operaciones, haciendo en paralelo todas las posibles. Claro está que eso complica la arquitectura de la máquina.
Al principio la arquitectura interna de los procesadores de juego de instrucción era compleja y requería muchas etapas diferentes, superando las 12 en varios casos. Luego se empezó a trabajar en sistemas más sencillos, con menos etapas, para ejecutar instrucciones más simples.
La idea era quitar instrucciones que lo hacían todo más complicado, pero que se usaban rara vez, por sólo las instrucciones necesarias para los cometidos básicos, de tal manera que la complejidad pasaba al programa (que necesitaba ahora más instrucciones, un programa más largo) para hacer esas cosas enrevesadas, pero eso permitía que las cosas sencillas, que constituyen la mayor parte del programa, se ejecutasen de forma más rápida, aunque las cosas complicadas fuesen más lentas, con una ganancia neta de velocidad.
Eso se hizo famoso con la Ley de Moore: cada dos años se dobla la potencia de cálculo.
La velocidad en cuanto a MHz lleva tiempo estancada. Se ha esquivado el frenazo brusco tirando de procesamiento paralelo: aceleradores gráficos, coprocesadores, y luego, al ir empeorando la situación, el aumento de núcleos con la idea de ir repartiendo trabajo.
El blog The Oil Crash viene publicando la serie Las guerras COB, sobre esta batalla por la velocidad de computación (COB, siglas en inglés para chip en placa). Su cuarta entrega señala el límite relativista que impone la velocidad de la luz, el mismo que dificulta el aprovechamiento global de las energías renovables:
Todos los elementos que tienen que trabajar a gran velocidad y acoplados entre sí, como por ejemplo la CPU con la memoria, o con buses de comunicación de alta velocidad (o sea, video y red de comunicaciones) se encuentran con que a 1GHz el reloj apenas se desplaza 15 cm en un cable, 10 cm en un circuito impreso. Si subimos a 2 GHz, bajamos esta distancia a la mitad: 5cm en un circuito.
Eso implica que no podemos poner la CPU y la memoria donde nos dé la gana. Es más, todas las señales que van de uno a otro componente tienen que tener una longitud similar, y generalmente estipulada con un máximo y un mínimo.
Y eso no es todo: la alimentación sufre al mismo ritmo, pero con una intensidad mayor.
Es lo mismo que pasa con las grandes redes eléctricas y las renovables, sólo que a la escala adecuada: ¼ de la longitud de onda. O sea, 750Km para los 50 Hz de la red eléctrica, 2,5cm para los 2GHz de los procesadores de nuestros teléfonos móviles u ordenadores personales.
Prólogo
Lo primero que le viene a la mente a uno cuando le hablan de la velocidad de la luz, es Einstein, la teoría de la relatividad, y las naves espaciales, con su ‘hiperespacio’ para ir más rápido aún que ese límite físico.
Por supuesto, eso pertenece al campo de la ciencia ficción, y parece que ese límite está muy lejos actualmente como para preocuparnos, y que, cuando llegue, encontraremos una manera de ‘doblar el espacio’ o de ‘arrugarlo’ y así alcanzar velocidades WARP, como lo denominan los Trekkies.
Sin embargo, los efectos relativistas y el límite de la velocidad de la luz nos lo encontramos cada día de forma cotidiana. Usted mismo lo está ‘padeciendo’ en el momento de leer esto: la electrónica utilizada en la informática y la transmisión de video al monitor, por poner un par de ejemplos, se han topado con este efecto hace varias décadas. De hecho, las Leyes de Maxwell trabajan ya con efectos relativistas y preceden a la teoría de Einstein.
De hecho, el WiFi y demás comunicaciones radio, utilizan antenas, que son un caso práctico de relatividad aplicada a la electricidad.
Todo eso forma un límite complicado y que es obviado, ignorado por mucha gente, empezando por ingenieros electrónicos mismamente, pero cuyo alcance va mucho más allá.
(...)
Todos los procesadores y derivados, funcionan a una cierta velocidad. Para conseguir esto, utilizan un reloj de sistema que ‘marca el paso’ al cual las instrucciones de programa van desfilando por el procesador.
Este reloj de mide en ciclos por segundo o sus múltiplos, MegaHercios (MHz) o GigaHercios (GHz), y es la frecuencia máxima en pulsos de reloj a la que puede trabajar ese procesador. Mega para millones, giga para miles de millones. Que se dice rápido.
Cuando salió el primer PC de IBM, el reloj de sistema iba a la extraña velocidad de 4,77 MHz. Extraña por no ser un número ‘redondo’, pero su razón era porque era un múltiplo necesario de la velocidad de comunicación del puerto serie base con el que se comunicaba con el mainframe (pensad que estaba diseñado para ser utilizado también como terminal ‘inteligente’).
El básico microcontrolador 8051 iba a la ‘increíble’ velocidad de 12 MHz.
Sin embargo, el funcionamiento interno de esas CPU’s implicaba que cada instrucción necesitase una serie de pasos para ser ejecutada, 12 por ejemplo en el 8051, lo cual implicaba que como máximo ejecutaba una instrucción cada 12 ciclos de reloj o lo que era equivalente, 1 MHz de instrucción, generalmente llamado 1MIPS (1 Millón de Instrucciones Por Segundo).
Obviamente, la punta de lanza de la tecnología iba en dirección de aumentar la frecuencia de reloj a base de reducir los elementos que la limitaban: el tamaño de la puerta de los MOSFET internos.
Vamos, el famoso nodo de fabricación.
Además, se trabajó en el sistema interno de ‘pasos’ del procesador, para que las unidades que los ejecutaban funcionasen de forma independiente y en paralelo. Lo que ahora se conoce como piping, que básicamente consiste que mientras la instrucción 1 está en el paso 12 en la estación correspondiente, la instrucción 12 está en la estación 1 ejecutándose el primer paso.
Eso permitía que se llegase cerca de 1MIPS por MHz, es decir, que con esa solución el 8051 daría aproximadamente 12MIPS a los mismos 12MHz.
Este sistema se debe a que por aquellos entonces las arquitecturas internas de los procesadores de juego de instrucción complejos (CISC en su acrónimo anglosajón) eran eso, complejos, y requerían muchas etapas diferentes, superando las 12 en varios casos.
La idea es quitar esas instrucciones complicadas que lo hacían todo más complejo, pero que se usaban rara vez, por sólo las instrucciones necesarias para los cometidos básicos, de tal manera que la complejidad pasaba al programa (que necesitaba ahora más instrucciones, un programa más largo) para hacer esas cosas complicadas.
Sin embargo eso permitía que las cosas sencillas, que constituyen la mayor parte del programa, se ejecutasen de forma más rápida, aunque las cosas complicadas fuesen más lentas, con una ganancia neta de velocidad.
Gracias a estos tres puntales (reducción del tamaño del nodo, pipelining, pasar de CISC a RISC), se ha conseguido mantener un ritmo de evolución enorme en cuanto a la velocidad de procesamiento o potencia de cálculo.
Eso se hizo famoso con la Ley de Moore: cada dos años se dobla la potencia de cálculo.
De hecho, hace ya años que se ha pasado de 4,77MHz a más de 4GHz, una ganancia del orden de 1000 veces, sólo en cuanto a velocidad, y básicamente, gracias a la reducción de nodo.
Pero esa velocidad de 4GHz hace ya tiempo que se ha establecido como límite.
Eso implica que la Ley de Moore hace ya tiempo que se ha ‘ralentizado’. Y si no se ha parado de hecho, es porque se ha ido desarrollando el pipelining de otra forma: poniendo más cores, añadiendo redundancia en forma de hyperthreading (que es duplicando parte del procesador sin llegar a hacer un core doble), las memorias Double Data Rate (DDR) y añadiendo complejidad al diseño electrónico.
De hecho, lo primero que se encontró con ‘problemas’ de velocidad, fueron las memorias, sobre todo debido a que en ese campo, en lo que se trabajaba era en aumentar el tamaño: de mi primer PC con 256KB de DRAM, a los habituales 8 – 16 GB de DDR, la ganancia ha sido de millones, no de mil. Pero ese incremento de tamaño ha implicado el incremento de complejidad, que es, una vez más, lo que limitó la velocidad real de las memorias, a pesar de las ganancias por la reducción de nodo.
De hecho, las mejoras esperadas en la reducción de nodo hasta los 2 – 3 nm, no se van a traducir en mayor velocidad, sino sólo en mayor tamaño de memoria/menor precio por GB.
Algo similar ha ocurrido con el cambio de CISC a RISC. El aumento de complejidad de la informática hoy en día, significa que cada vez el procesador hace cosas más complejas de forma más habitual, incluso algunas de ellas de forma mucho más repetitiva. Jevons aplicado.
Eso ha derivado en el uso de HW específico para desarrollar ciertas cosas que generalmente se hacían por SW, pero tan a menudo que vale la pena gastar algo más de electrónica para eliminarlas o reducirlas del programa.
Aunque suene críptico, es fácil de entender: la CPU se pasaba mucho rato dibujando rectángulos en la pantalla, y rellenándolos de color, algo que es, desde el punto de vista algorítmico, muy simple, repetitivo, pero que consume mucho tiempo de procesamiento dado el tamaño de las pantallas (en puntos o píxeles).
Así pues, se partió en dirección opuesta a los RISC/CISC: se puso un ‘subprocesador de vídeo’ o ‘acelerador gráfico’ que no es más que electrónica específica que hace ciertas tareas muy sencillas, particulares y concretas de forma autónoma sin necesidad de utilizar preciosos ciclos de CPU. Ese marca el nacimiento de las GPU.
De la misma forma, se añadieron (y eso ya viene de los tiempos del viejo PC) subprocesadores o coprocesadores matemáticos que ejecutan operaciones que generalmente son complejas, como la raíz cuadrada, trigonometría, exponenciales, convoluciones, matemática en coma flotante, etc.
Es decir, se añade, una vez más HW específico para hacer funciones complejas (es decir, de cierta forma, se vuelve al CISC aunque el procesador principal sea RISC) que hagan esas partes largas del programa que antes hacían las instrucciones complejas de los CISC.
Además, se añaden prestaciones típicas de lo que eran DSP’s, es decir, los procesadores digitales de la señal que básicamente eran machacanúmeros, sistemas dedicados a hacer muchos cálculos matemáticos relativamente complejos (cuadrados y raíz cuadrada a menudo, aunque lo básico era sumar y multiplicar, lo que se llama operación MAC – Multiply And Accumulate), pero encima de forma cíclica, y de forma automática (dicho en jerga informática, un bucle que repite la misma operación matemática n veces).
(...)
Dado el enorme incremento de la complejidad, no sólo desde sus inicios, sino con su aceleración (que se está frenando) durante la primera década de este siglo, se ha hecho demasiado difícil el conocer las ‘interioridades’ de la electrónica sobre la que se trabaja.
Además, la increíble velocidad a la que se producen los cambios, en el momento en que uno llega a dominar esas particularidades, el chisme en cuestión ya está más que obsoleto. Con lo que no vale la pena llegar a profundizar en las posibilidades que trae la máquina en concreto.
Además, el incremento enooooorme de complejidad del programa/sistema, hace que lo que antes hacía un ingeniero, ahora requiera un grupo inmenso de programadores de seguir con esa filosofía.
(...)
La idea es simple: que un mismo programa se pueda ejecutar sobre varios ordenadores DIFERENTES sin que el programador necesite saber ni las particularidades ni las diferencias de dichos ordenadores.
Eso generalmente, lleva a la estandarización de funciones, interfaces, etc. En buena parte, es lo que proporcionan los sistemas operativos utilizados en los ordenadores personales (Windows, Linux, macOS, Android WebOS, etc), teléfonos móviles, hasta televisores…
Es muy práctico y tiene muchas ventajas para los desarrolladores.
Pero es sumamente ineficiente.
Por ejemplo: bajo un HAL simple y efectivo como el utilizado por el Arduino, una operación de poner a 1 e inmediatamente volver a poner a 0 un pin (para encender un LED, por ejemplo), tarda como 50 ciclos de reloj y un porrón de instrucciones. Hacer lo mismo en C, sobre el mismo procesador, pero pasándose por el forro el HAL tarda TRES ciclos de reloj, tres instrucciones. En ensamblador, el resultado es exactamente el mismo. 20X en velocidad.
(...)
Hasta que nos estrellamos con el muro de la relatividad.
Ya he explicado que la velocidad en cuanto a MHz lleva tiempo estancada. Se ha esquivado el frenazo brusco tirando de procesamiento paralelo: aceleradores gráficos, coprocesadores, y luego, al ir empeorando la situación, el aumento de núcleos con la idea de ir repartiendo trabajo.
Ese reparto de trabajo en núcleos es un resultado obvio de la problemática expuesta del code bloating: el aumento de ‘tareas’ que se tienen que ejecutar a la vez para que todo el sistema operativo y el HAL subyacente funcionen.
Al haber tantas tareas (frente a la única del viejuno MSDOS) que ejecutar, lo habitual, lógico y lo que ha sido la respuesta, el ‘truco’ es meter más procesadores donde cada uno se encarga de alguna tarea, trabajando todos a la vez. El reparto de tareas resulta relativamente sencillo… si hay pocos núcleos.
Pero todo tiene un límite, y en lo que respecta a ordenadores personales, se está llegando ahí.
Afortunadamente, para videoconferencias, ver gatitos por internete, escribir artículos en Word, o usar el ‘complicado’ Excel para echar las cuentas de la casa, vamos mas que sobradísimos desde hace varias generaciones de sistemas operativos. Un ‘viejo’ ordenador con el Windos XP va más que sobrado.
De hecho, se están reutilizando muchos viejos ordenadores con sistemas operativos más livianos como el Linux Mint, que permiten hacer lo mismo que los nuevos más potentes pero con muchos menos recursos. Básicamente gracias a una cosa: la simplificación de las labores y el ‘recorte de grasa’ del code bloating (en bastantes ocasiones, basado en sistemas antipiratería, de supervisión de utilización del programa – casi spyware sin llegar a serlo, etc).
Pero hay cierto campos en los que esta ineficiencia ya llega a ser prohibitiva. Hay ciertas aplicaciones donde hace falta hilar fino, muy fino, para sacar todo el jugo posible de la máquina, precisamente porque necesitan máquinas muy potentes para hacer esas cosas particulares… o porque ahora se intenta pasar esas aplicaciones que se han desarrollado en sistemas muy potentes, a sistemas mucho más ligeritos.
Me refiero a la IA y al Big Data, dos campos diferentes pero familiares entre sí.
La aparición de sistemas multiprocesadores con gran capacidad para ejecutar una misma rutina sobre gran cantidad de datos, esos mismos que se pusieron en las tarjetas gráficas para acelerar no sólo los juegos, sino los cálculos de ingeniería, ahora resultaban ser muy útiles para ejecutar redes neuronales, puesto que el algoritmo que ‘ejecuta’ la neurona es sencillo y repetitivo, de naturaleza similar (en el fondo, parece ser una rutina DSP sobre varias señales).
La IA, en el fondo es más ‘caja negra’ que casi ningún otro desarrollo informático, el summum de la abstracción.
(...)
Volviendo a la problemática relativista, hay más puntos limitantes que complican el diseño electrónico propiamente dicho, en la parte concreta.
Todos los elementos que tienen que trabajar a gran velocidad y acoplados entre sí, como por ejemplo la CPU con la memoria, o con buses de comunicación de alta velocidad (o sea, video y red de comunicaciones) se encuentran con que a 1GHz el reloj apenas se desplaza 15 cm en un cable, 10 cm en un circuito impreso. Si subimos a 2 GHz, bajamos esta distancia a la mitad: 5cm en un circuito.
Eso implica que no podemos poner la CPU y la memoria donde nos dé la gana. Es más, todas las señales que van de uno a otro componente tienen que tener una longitud similar, y generalmente estipulada con un máximo y un mínimo.
Y eso no es todo: la alimentación sufre al mismo ritmo, pero con una intensidad mayor, lo que genera toda una ‘ciencia esotérica’ con los ‘místicos condensadores de desacoplo’, (la foto de abajo presenta los condensadores de desacoplo -marrones - y las resistencias de adaptación de impedancias – negras - , junto a un cristal de cuarzo – plateado -, del circuito de portada, visto por debajo) debido a la inestabilidad que genera en la red de alimentación la conmutación a semejante velocidad.
Es lo mismo que pasa con las grandes redes eléctricas y las renovables, sólo que a la escala adecuada: ¼ de la longitud de onda. O sea, 750Km para los 50 Hz de la red eléctrica, 2,5cm para los 2GHz de los procesadores de nuestros teléfonos móviles u ordenadores personales.
Este ‘inconveniente’ puede producir que los rápidos y caprichosos cambios que introducen las renovables causen un gran apagón en toda Europa, razón por la que Austria, Alemania y Suiza avisan del problema.
No hay comentarios:
Publicar un comentario