*Adolfo Guzmán ArenasCentro de Investigación en Computación, Instituto Politécnico Nacional
aguzman@ieee.orgEra costumbre para los computólogos producir cada año procesadores más rápidos y con más memoria. Esto reduce drásticamente el precio del equipo. Tradicionalmente, la forma de aumentar el rendimiento del chip que hace los cálculos en una computadora (la Unidad Central de Proceso o “CPU") era mediante circuitos integrados con componentes cada vez más delgadas o finas, lo que permitía tener más procesamiento y memoria en la misma superficie del dispositivo. Por límites físicos, este adelgazamiento llegó a un límite: la barrera física. También se podía hacer trabajar más rápido al dispositivo aumentando la frecuencia del reloj. Desafortunadamente, esto provoca mayor calentamiento del chip, llegando a un límite impuesto por la necesidad de disipar ese calor: la barrera de energía.Entonces aparecieron múltiples núcleos de procesamiento que permitían cálculos paralelos, disponibles hoy en cualquier computadora portátil. Pero ahora resultó insuficiente la interfaz con la que el software (los programas que las computadoras ejecutan) se comunica con el hardware (el equipo electrónico, “los circuitos"). Este acoplamiento se da simplemente mediante un conjunto de instrucciones de máquina. Una CPU se construye para que pueda ejecutar esas instrucciones, y el software se construye para dar esas instrucciones. Las instrucciones se ejecutan una por una, secuencialmente —cuando menos eso era al principio. En la práctica, el hardware  ejecuta simultáneamente varias etapas de distintas instrucciones, las ejecuta fuera de orden, predice a dónde va a saltar el programa, y hace otras maravillas sin violar la idea simple de la ejecución secuencial de las instrucciones. Así, el hardware hace lo que el software le dice. Pero ¿cómo dar órdenes en paralelo?, y en general, ¿cómo puede el software hacer uso efectivo de tanta capacidad de cómputo? Es la barrera de programación. Además, tantos circuitos diminutos en un ambiente tan reducido y caliente (así es una CPU actual) provocan más fallas —entre tantos transistores, algunos fallarán. Es la barrera de confiabilidad.

Eso está muy bien. Pero no es sólo responsabilidad del hardware “saber lo que está pasando”. También es responsabilidad del software “decir lo que ocurrirá pronto”. Lo que va a pasar. No quedarse mudo, sino enunciar qué tareas ordenará ejecutar, en qué orden. Los que hacemos software debemos comunicar nuestras intenciones al hardware, para usarlo mejor.

El software actualmente da órdenes minúsculas al hardware, una lista de instrucciones de máquina, provenientes de programas en Fortran o Python. El hardware tiene que descifrar cuáles bloques de instrucciones se ejecutan más, cuáles instrucciones pueden ejecutarse en desorden, cuáles tareas pueden paralelizarse, cuáles pueden asignarse a núcleos más lentos, etc. ¿Qué no puede el software dar órdenes de nivel más alto? Dar más información al hardware, para que trabaje mejor. No todo lo debe deducir éste.

Sí puede. Puede asignar prioridad a las tareas. Puede indicar cuáles variables son locales (sólo el que las crea las ve y las cambia), cuáles cambiarán poco. Qué bloques de construcción está usando, qué subrutinas, qué aplicaciones de software libre. Qué proceso usado ayer usaré en este momento. Empero, el software sigue dando listas de instrucciones de máquina.

Esto me recuerda a la Ingeniería Química a principios del siglo XX. Los diferentes procesos químicos (producción de jabón, cerveza, ácido nítrico; destilar alcohol…) eran considerados procesos diferentes. Cada uno se enseñaba “paso a paso”. Situación intolerable en el MIT, pues la enseñanza requería mucho tiempo.

Arthur D. Little, William H. Walker y Warren K. Lewis escribieron en 1923 Los principios de la ingeniería química y redujeron toda fabricación industrial a una serie de operaciones unitarias: transporte de fluidos, filtración, fluidización de sólidos, evaporación, intercambio de calor, destilación, extracción, secado, licuefacción, refrigeración, trituración, etcétera.

Como resultado de eso, los ingenieros químicos del MIT (y pronto los de todo el mundo) sólo tenían que aprender esas operaciones unitarias, y “pegarlas” para resolver cualquier problema de ingeniería química industrial.

Propongo que los computólogos definamos estas “operaciones unitarias del software” y que nuestros programas le hablen al hardware en este idioma. Entonces los constructores de hardware buscarán cómo hacer unidades de proceso que faciliten o implementen tales operaciones. ¿Cuáles son?  Búsqueda, ordenamiento (sort), clasificación, actualización, agrupamiento (clustering), transformada de Fourier, filtrado, inversión de matriz, minimización, ­correlación, solución de la ecuación de Laplace, etc. En vez de ir a una ferretería y ordenar, no solamente 30 clavos de 50mm y catorce tornillos para madera 9-25; ahora digo “quiero hacer una estantería de seis anaqueles”.

¿Qué hará el hardware con estas instrucciones de alto nivel? Tareas, las llama el Dr. Valero.

Puede haber unidades de procesamiento específicas. Por ejemplo, los procesadores para Tensor Flow (redes neuronales); chips que detectan movimiento; que detectan rostros. Solución totalmente por hardware.En 2003 en Querétaro, colaboré en el diseño de una computadora para medir flujo en tubos grandes. Usamos procesadores digitales de señales. Algunos tienen la instrucción “mariposa", muy útil para ejecutar la transformada rápida de Fourier. Otros tienen instrucciones que facilitan el filtrado digital, usando los polos y ceros de la función de transferencia. Solución hardware-software.Puede haber unidades reconfigurables (usando FPGA, matrices de puertas programables, por ejemplo) que puedan autorreprogramarse para hacer un ordenamiento, o para hallar los eigenvalues de una matriz. Solución de hardware reconfigurable.

Celebro el llamado de Mateo hacia una colaboración más estrecha entre el software y el hardware. Propongo que el software se piense y construya más con operaciones unitarias que con clavos, tornillos y arandelas.

Dr. Adolfo Guzmán Arenas.  Profesor/investigador, Laboratorio de Ciencia de Datos y Tecnología de Software, Centro de Investigación en Computación (CIC), Instituto Politécnico Nacional. Miembro del Consejo Consultivo de Ciencias.