00:17 Introducción
03:35 Órdenes de magnitud
06:55 Etapas de la optimización de la cadena de suministro
12:17 Las curvas S del hardware
15:52 La historia hasta ahora
17:34 Ciencias auxiliares
20:25 Computadoras modernas
20:57 Latencia 1/2
27:15 Latencia 2/2
30:37 Cálculo, velocidad de reloj
36:36 Cálculo, canalización, 1/3
39:11 Cálculo, canalización, 2/3
40:27 Cálculo, canalización, 3/3
46:36 Cálculo, superescalar 1/2
49:55 Cálculo, superescalar 2/2
56:45 Memoria 1/3
01:00:42 Memoria 2/3
01:06:43 Memoria 3/3
01:11:13 Almacenamiento de datos 1/2
01:14:06 Almacenamiento de datos 2/2
01:18:36 Ancho de banda
01:23:20 Conclusión
01:27:33 Próxima conferencia y preguntas del público
Descripción
Las cadenas de suministro modernas requieren recursos informáticos para operar, al igual que las cintas transportadoras motorizadas requieren electricidad. Sin embargo, los sistemas de cadena de suministro lentos siguen siendo omnipresentes, mientras que la potencia de procesamiento de las computadoras ha aumentado en más de 10,000 veces desde 1990. La falta de comprensión de las características fundamentales de los recursos informáticos modernos, incluso entre los círculos de TI o científicos de datos, explica en gran medida este estado de cosas. El diseño de software subyacente a las recetas numéricas no debería antagonizar el sustrato informático subyacente.
Transcripción completa
Bienvenidos a esta serie de conferencias sobre cadena de suministro. Soy Joannes Vermorel y hoy presentaré “Computadoras modernas para la cadena de suministro”. Las cadenas de suministro occidentales se han digitalizado desde hace mucho tiempo, a veces hasta hace tres décadas. Las decisiones basadas en computadoras están en todas partes y las recetas numéricas asociadas reciben varios nombres, como puntos de reorden, inventario mínimo-máximo y existencias de seguridad, con diferentes grados de supervisión humana.
No obstante, si observamos las grandes empresas en la actualidad que operan cadenas de suministro igualmente grandes, vemos millones de decisiones que son impulsadas esencialmente por computadoras, las cuales impulsan el rendimiento de la cadena de suministro. Por lo tanto, cuando se trata de mejorar el rendimiento de la cadena de suministro, rápidamente se reduce a mejorar las recetas numéricas que impulsan la cadena de suministro. Aquí, invariablemente, cuando comenzamos a considerar recetas numéricas superiores de cualquier tipo, donde queremos mejores modelos y pronósticos más precisos, esas recetas superiores terminan costando mucho más recursos informáticos.
Los recursos informáticos han sido una lucha para la cadena de suministro, ya que cuestan mucho dinero, y siempre está la siguiente etapa de evolución para el próximo modelo o el próximo sistema de pronóstico que requiere diez veces más recursos informáticos que el anterior. Sí, podría brindar un rendimiento adicional a la cadena de suministro, pero conlleva un mayor costo informático. En las últimas décadas, el hardware informático ha progresado enormemente, pero como veremos hoy, este progreso, aunque aún en curso, a menudo es antagonizado por el software empresarial. Como resultado, el software no se vuelve más rápido con hardware más moderno; al contrario, muy frecuentemente puede volverse más lento.
El objetivo de esta conferencia es inculcar entre la audiencia cierto grado de simpatía mecánica, para que puedan evaluar si un software empresarial que se supone que implementa recetas numéricas destinadas a ofrecer un rendimiento superior de la cadena de suministro abraza el hardware informático tal como existe actualmente y como existirá dentro de una década, o si lo antagoniza y, por lo tanto, no aprovecha al máximo el hardware informático que tenemos hoy en día.
Uno de los aspectos más desconcertantes de las computadoras modernas es la gama de órdenes de magnitud involucrados. Desde la perspectiva de la cadena de suministro, típicamente tenemos alrededor de cinco órdenes de magnitud, y eso ya es estirarlo; por lo general, ni siquiera es eso. Cinco órdenes de magnitud significa que podemos ir de una unidad a 100,000 unidades. Recuerden algo que discutí en conferencias anteriores, la ley de los números pequeños en juego. Si tienes un gran número de unidades, no las procesarás individualmente; las empaquetarás en cajas y, por lo tanto, te quedarás con un número mucho menor de cajas. De manera similar, si tienes muchas cajas, las empaquetarás en paletas, etc., para que tengas un número mucho menor de paletas. Las economías de escala inducen predicciones de cantidades y, desde la perspectiva de la cadena de suministro, cuando estamos lidiando con el flujo de bienes físicos, una ineficiencia del 10% tiende a ser bastante significativa.
En el ámbito de las computadoras, es muy diferente; estamos lidiando con 15 órdenes de magnitud, lo cual es absolutamente gigantesco. Pasamos de una unidad a un millón de billones de unidades, el número es tan grande que en realidad es muy difícil de visualizar. Pasamos de un byte, que son solo ocho bits y se pueden usar para representar una letra o un dígito, a un petabyte, que es un millón de gigabytes. Un petabyte es aproximadamente el orden de magnitud de la cantidad de datos que Lokad maneja actualmente, y las grandes empresas que operan grandes cadenas de suministro también operan conjuntos de datos del orden de magnitud de un petabyte.
Pasamos de una FLOP (operación de punto flotante por segundo) a un petaFLOP, que es un millón de gigaFLOPS. Estas órdenes de magnitud son absolutamente gigantescas y muy engañosas. Como resultado, en el ámbito de la cadena de suministro, donde se considera que el 10% es ineficiente, lo que suele suceder en el ámbito de las computadoras es que no se trata de ser ineficiente en un 10%, sino más bien de ser ineficiente en un factor de 10, y a veces varias órdenes de magnitud. Entonces, si haces algo mal en términos de rendimiento en el ámbito de las computadoras, tu penalización no será del 10%; en cambio, tu sistema será 10 veces más lento de lo que debería ser, o 100 veces, y a veces incluso mil veces más lento de lo que debería haber sido. Eso es realmente lo que está en juego: tener una verdadera alineación, que requiere algún tipo de simpatía mecánica entre el software empresarial y el hardware informático subyacente.
Al considerar una receta numérica que se supone que proporciona un rendimiento superior en la cadena de suministro, hay una serie de etapas de madurez que son de interés conceptual. Obviamente, su experiencia puede variar en la práctica, pero eso es típicamente lo que hemos identificado en Lokad. Estas etapas se pueden resumir en: hacer que funcione, hacerlo bien, hacerlo rápido y hacerlo barato.
“Hacer que funcione” se trata de evaluar si una receta numérica de prototipo realmente está entregando los resultados previstos, como niveles de servicio más altos, menos stock muerto, mejor utilización de activos o cualquier otro objetivo que sea valioso desde una perspectiva de cadena de suministro. El objetivo es asegurarse primero de que la nueva receta numérica realmente funcione en la primera etapa de madurez.
Luego, tienes que “hacerlo bien”. Desde una perspectiva de cadena de suministro, esto significa transformar lo que era esencialmente un prototipo único en algo con calidad de producción. Esto generalmente implica agregar a la receta numérica cierto grado de corrección por diseño. Las cadenas de suministro son vastas, complejas y, lo que es más importante, muy desordenadas. Si tienes una receta numérica que es muy frágil, incluso si el método numérico es bueno, es muy fácil equivocarse y terminar creando muchos más problemas en comparación con los beneficios que pretendías brindar en primer lugar. Esta no es una propuesta ganadora. Hacerlo bien es asegurarse de tener algo que se pueda implementar a gran escala con fricción mínima. Luego, quieres hacer que esta receta numérica sea rápida, y cuando digo rápida, me refiero a rápida en términos de tiempo de reloj de pared. Cuando comienzas el cálculo, deberías obtener los resultados en cuestión de minutos, o tal vez una hora o dos como máximo, pero no más. Las cadenas de suministro son desordenadas y habrá un momento en la historia de tu empresa en el que habrá interrupciones, como barcos de carga atascados en medio del Canal de Suez, una pandemia o un almacén inundado. Cuando esto suceda, necesitas poder reaccionar rápidamente. No estoy diciendo que reacciones en los próximos milisegundos, pero si tienes recetas numéricas que tardan días en completarse, crea una fricción operativa masiva. Necesitas cosas que se puedan operar en un corto período de tiempo humano, por lo que debe ser rápido.
Recuerda, el software empresarial moderno se ejecuta en la nube y siempre puedes pagar por más recursos informáticos en plataformas de computación en la nube. Por lo tanto, tu software puede ser rápido simplemente porque estás alquilando mucha potencia de procesamiento. No es que el software en sí mismo tenga que estar diseñado correctamente para aprovechar toda la potencia de procesamiento que puede proporcionar una nube, pero puede ser rápido y muy ineficiente simplemente porque estás alquilando tanta potencia de procesamiento de tu proveedor de computación en la nube.
La siguiente etapa es hacer que el método sea barato, lo que significa que no utiliza demasiados recursos informáticos en la nube. Si no pasas a esta etapa final, significa que nunca podrás mejorar tu método. Si tienes un método que funciona, es correcto y es rápido pero consume muchos recursos, cuando quieras pasar a la siguiente etapa de la receta numérica, que inevitablemente implicará algo que cuesta aún más recursos informáticos que los que estás utilizando actualmente, te quedarás atascado. Necesitas hacer que el método que tienes sea muy eficiente para que puedas comenzar a experimentar con recetas numéricas que sean menos eficientes que las que tienes actualmente.
Esta última etapa es donde realmente necesitas aprovechar el hardware subyacente que está disponible en las computadoras modernas. Puedes manejar las tres primeras etapas sin demasiada afinidad, pero la última es clave. Recuerda, si no llegas a la etapa de “hacerlo barato”, no podrás iterar, por lo que te quedarás atascado. Es por eso que, aunque sea la última etapa, este es un juego iterativo y es esencial pasar por todas las etapas si quieres iterar repetidamente.
El hardware está progresando y parece una progresión exponencial, pero la realidad es que esta progresión exponencial del hardware informático está compuesta en realidad por miles de curvas S. Una curva S es una curva donde se introduce un nuevo diseño, proceso, material o arquitectura, y al principio no es realmente mejor que lo que tenías antes. Luego, el efecto de la innovación prevista entra en juego y tienes un aumento, seguido de un plateau después de que consumes todos los beneficios de la innovación. Las curvas S en plateau son características del progreso en el hardware informático, que está compuesto por miles de estas curvas. Desde la perspectiva de un lego, esto parece un crecimiento exponencial. Sin embargo, los expertos ven las curvas S individuales en plateau, lo que puede llevar a una visión pesimista. Incluso los expertos no siempre ven la aparición de nuevas curvas S que sorprenden a todos y continúan el crecimiento exponencial del progreso.
Aunque el hardware informático sigue progresando, la tasa de progreso está lejos de lo que experimentamos en los años 80 o 90. El ritmo ahora es mucho más lento y bastante predecible, en gran parte debido a las enormes inversiones necesarias para construir nuevas fábricas para producir hardware informático. Estas inversiones a menudo ascienden a cientos de millones de dólares, lo que proporciona visibilidad de cinco a diez años por delante. Si bien el progreso se ha ralentizado, todavía tenemos una visión bastante precisa de lo que sucederá en términos de progreso del hardware informático en la próxima década.
La lección para el software empresarial que implementa recetas numéricas es que no puedes esperar pasivamente que el hardware futuro haga todo mejor para ti. El hardware todavía está progresando, pero capturar este progreso requiere esfuerzo por parte del software. Podrás hacer más con el hardware que exista dentro de una década, pero solo si la arquitectura en el núcleo de tu software empresarial abraza el hardware informático subyacente. De lo contrario, es posible que en realidad hagas peor de lo que estás haciendo hoy, una proposición que no es tan irrazonable como parece.
Esta conferencia es la primera del cuarto capítulo de esta serie de conferencias sobre la cadena de suministro. No he terminado el tercer capítulo sobre los personajes de la cadena de suministro. En las siguientes conferencias, es probable que alterne entre el capítulo actual, donde estoy cubriendo las ciencias auxiliares de la cadena de suministro, y el tercer capítulo sobre los personajes de la cadena de suministro.
En el primer capítulo del prólogo, presenté mis puntos de vista sobre la cadena de suministro como un campo de estudio y una práctica. Hemos visto que la cadena de suministro es esencialmente una colección de problemas complejos, en oposición a problemas simples, plagados de comportamiento adversarial y juegos competitivos. Por lo tanto, debemos prestar mucha atención a la metodología porque las metodologías directas y simples funcionan mal en este campo. Es por eso que el segundo capítulo estuvo dedicado a la metodología necesaria para estudiar las cadenas de suministro y establecer prácticas para mejorarlas con el tiempo.
El tercer capítulo, Personajes de la Cadena de Suministro, se centró en caracterizar los propios problemas de la cadena de suministro, con el lema “enamórate del problema, no de la solución”. El cuarto capítulo que estamos abriendo hoy trata sobre las ciencias auxiliares de las cadenas de suministro.
Las ciencias auxiliares son disciplinas que apoyan el estudio de otra disciplina. No hay juicio de valor; no se trata de que una disciplina sea superior a otra. Por ejemplo, la medicina no es superior a la biología, pero la biología es una ciencia auxiliar para la medicina. La perspectiva de las ciencias auxiliares está bien establecida y es prevalente en muchos campos de investigación, como las ciencias médicas y la historia.
En las ciencias médicas, las ciencias auxiliares incluyen la biología, la química, la física y la sociología, entre otras. Un médico moderno no sería considerado competente si no tuviera conocimientos de física. Por ejemplo, entender los conceptos básicos de la física es necesario para interpretar una imagen de rayos X. Lo mismo ocurre con la historia, que tiene una larga serie de ciencias auxiliares.
En lo que respecta a la cadena de suministro, una de mis mayores críticas a los materiales, cursos, libros y artículos típicos de la cadena de suministro es que tratan el tema sin profundizar en ninguna ciencia auxiliar. Tratan la cadena de suministro como si fuera un conocimiento aislado y autosuficiente. Sin embargo, creo que la práctica moderna de la cadena de suministro solo se puede lograr aprovechando al máximo las ciencias auxiliares de las cadenas de suministro. Una de estas ciencias auxiliares, y el enfoque de la conferencia de hoy, es el hardware de computación.
Esta conferencia no es estrictamente una conferencia sobre cadena de suministro, sino más bien sobre hardware de computación con aplicaciones en cadena de suministro en mente. Creo que es fundamental para practicar la cadena de suministro de una manera moderna, en contraposición a cómo se hacía hace un siglo.
Veamos las computadoras modernas. En esta conferencia, revisaremos lo que pueden hacer por la cadena de suministro, centrándonos especialmente en aspectos que tienen un impacto masivo en el rendimiento del software empresarial. Revisaremos la latencia, el cálculo, la memoria, el almacenamiento de datos y el ancho de banda.
La velocidad de la luz es de aproximadamente 30 centímetros por nanosegundo, lo cual es relativamente lento. Si consideramos la distancia característica de interés para una CPU moderna que opera a 5 gigahertz (5 mil millones de operaciones por segundo), la distancia de ida y vuelta que la luz puede recorrer en 0.2 nanosegundos es solo de 3 centímetros. Esto significa que, debido a la limitación de la velocidad de la luz, las interacciones no pueden ocurrir más allá de 3 centímetros. Esta es una limitación estricta impuesta por las leyes de la física y no está claro si alguna vez podremos superarla.
La latencia es una restricción extremadamente difícil. Desde una perspectiva de cadena de suministro, tenemos al menos dos distribuciones de hardware de computación involucradas. Cuando digo hardware de computación distribuido, me refiero a hardware de computación que involucra muchos dispositivos que no pueden ocupar el mismo espacio físico. Obviamente, necesitas mantenerlos separados solo porque tienen dimensiones propias. Sin embargo, la primera razón por la que necesitamos computación distribuida es la naturaleza de las cadenas de suministro, que están geográficamente distribuidas. Por diseño, las cadenas de suministro se extienden por geografías y, por lo tanto, también habrá hardware de computación distribuido en esas geografías. Desde la perspectiva de la velocidad de la luz, incluso si tienes dispositivos que están a solo tres metros de distancia, ya es muy lento porque lleva 100 ciclos de reloj hacer el viaje de ida y vuelta. Tres metros es una distancia considerable desde la perspectiva de la velocidad de la luz y la frecuencia de reloj de las CPU modernas.
Otro tipo de distribución es la escalabilidad horizontal. La forma moderna de tener más potencia de procesamiento a nuestra disposición no es tener un dispositivo de computación que sea 10 veces o un millón de veces más potente; no es así como está diseñado. Si quieres más recursos de procesamiento, necesitas dispositivos de computación adicionales, más procesadores, más chips de memoria y más discos duros. Es apilando el hardware que puedes tener más recursos computacionales a tu disposición. Sin embargo, todos esos dispositivos ocupan espacio y, por lo tanto, terminas distribuyendo tu hardware de computación solo porque no puedes centralizarlo en una computadora de un centímetro de ancho.
Cuando se trata de latencias, al observar el tipo de latencias que tenemos en Internet profesional (las latencias que se pueden obtener en un centro de datos, no a través de tu Wi-Fi en casa), ya estamos dentro del 30% de la velocidad de la luz. Por ejemplo, la latencia entre un centro de datos cerca de París, Francia, y Nueva York, Estados Unidos, está solo dentro del 30% de la velocidad de la luz. Este es un logro increíble para la humanidad; la información fluye a través de Internet casi a la velocidad de la luz. Sí, todavía hay margen de mejora, pero ya estamos cerca de los límites impuestos por la física.
Como resultado, incluso hay empresas ahora que quieren tender cables a través del fondo del mar Ártico para conectar Londres con Tokio con un cable que pasaría por debajo del Polo Norte, solo para reducir unos pocos milisegundos de latencia en las transacciones financieras. Fundamentalmente, la latencia y la velocidad de la luz son preocupaciones muy reales, y el Internet que tenemos es esencialmente tan bueno como siempre será a menos que haya avances en física. Sin embargo, no tenemos nada parecido a eso en el horizonte para la próxima década.
Debido a que la latencia es un problema muy difícil, las implicaciones para el software empresarial son significativas. Los viajes de ida y vuelta en términos del flujo de información son mortales, y el rendimiento de tu software empresarial dependerá en gran medida del número de viajes de ida y vuelta entre los diversos subsistemas que existen dentro de tu software. El número de viajes de ida y vuelta caracterizará la latencia incompresible que sufres. Minimizar los viajes de ida y vuelta y mejorar las latencias es, para la mayoría de los software empresariales, incluidos aquellos dedicados a la optimización predictiva de la cadena de suministro, el problema número uno. Mitigar las latencias a menudo se traduce en ofrecer un mejor rendimiento.
Un truco interesante, aunque no es algo que todos en esta audiencia implementarán en producción, es abordar las complicaciones introducidas por la latencia. El tiempo mismo se vuelve esquivo y difuso cuando entras en el ámbito de los cálculos de nanosegundos. Los relojes precisos son difíciles de encontrar en la computación distribuida, y su ausencia introduce complicaciones dentro del software empresarial distribuido. Se necesitan numerosos viajes de ida y vuelta para sincronizar las diversas partes del sistema. Debido a la falta de un reloj preciso, terminas con alternativas algorítmicas como relojes vectoriales o marcas de tiempo multipartitas, que son estructuras de datos que reflejan un orden parcial de los relojes de los dispositivos en tu sistema. Estos viajes de ida y vuelta adicionales pueden afectar el rendimiento.
Un diseño inteligente adaptado por Google hace más de una década fue utilizar relojes atómicos a escala de chip. La resolución de estos relojes atómicos es significativamente mejor que la de los relojes basados en cuarzo que se encuentran en relojes electrónicos o computadoras. NIST demostró una nueva configuración de reloj atómico a escala de chip con una deriva diaria aún más precisa. Google utilizó relojes atómicos internos para sincronizar las diversas partes de su base de datos SQL distribuida a nivel mundial, Google Spanner, para ahorrar viajes de ida y vuelta y mejorar el rendimiento a escala global. Esta es una forma de engañar a la latencia a través de mediciones de tiempo muy precisas.
Mirando una década hacia el futuro, es probable que Google no sea la última empresa en utilizar este tipo de truco ingenioso, y son relativamente asequibles, con relojes atómicos a escala de chip que cuestan alrededor de $1,500 cada uno.
Ahora, echemos un vistazo a la computación, que se trata de hacer cálculos con una computadora. La velocidad del reloj fue el ingrediente mágico de mejora durante los años 80 y 90. De hecho, si pudieras duplicar la velocidad del reloj de tu computadora en general, efectivamente duplicarías el rendimiento de tu computadora, sin importar qué tipo de software esté involucrado. Todo el software sería más rápido de manera lineal según la velocidad del reloj. Es extremadamente interesante aumentar la velocidad del reloj, y aún se está mejorando, aunque la mejora se ha estancado con el tiempo. Hace casi 20 años, la velocidad del reloj era de aproximadamente 2 GHz, y hoy en día es de 5 GHz.
La razón clave de esta mejora estancada es la barrera de potencia. El problema es que cuando aumentas la velocidad del reloj en un chip, tiendes a duplicar aproximadamente el consumo de energía, y luego tienes que disipar esta energía. El problema es la disipación térmica porque, si no puedes disipar la energía, tu dispositivo acumula calor hasta el punto en que daña el propio dispositivo. Hoy en día, la industria de semiconductores ha pasado de tener más operaciones por segundo a tener más operaciones por vatio.
Esta regla de un aumento del 30% duplicando el consumo de energía es una espada de doble filo. Si estás de acuerdo en renunciar a una cuarta parte de tu potencia de procesamiento por unidad de tiempo en la CPU, en realidad puedes dividir el consumo de energía por dos. Esto es especialmente interesante para los teléfonos inteligentes, donde el ahorro de energía es crucial, y también para la computación en la nube, donde uno de los principales impulsores del costo es la energía misma. Para tener una potencia de procesamiento de computación en la nube rentable, no se trata de tener CPUs súper rápidas, sino de tener CPUs subaceleradas que pueden ser tan lentas como 1 GHz, ya que proporcionan más operaciones por segundo para tu inversión de energía.
La barrera de potencia es un problema tan grande que las arquitecturas modernas de CPU están utilizando todo tipo de trucos ingeniosos para mitigarla. Por ejemplo, las CPUs modernas pueden regular su velocidad de reloj, aumentándola temporalmente durante un segundo aproximadamente antes de reducirla para disipar el calor. También pueden aprovechar lo que se llama silicio oscuro. La idea es que si la CPU puede alternar las áreas calientes en el chip, es más fácil disipar la energía en lugar de tener siempre la misma área activa ciclo tras ciclo de reloj. Este es un ingrediente muy importante del diseño moderno. Desde la perspectiva del software empresarial, significa que realmente quieres poder escalar. Quieres poder hacer más con muchas veces más CPUs, pero individualmente, esos procesadores serán más débiles que los anteriores que tenías. No se trata de obtener mejores procesadores en el sentido de que todo es mejor en general; se trata de tener procesadores que te brinden más operaciones por vatio, y esta tendencia continuará.
Tal vez dentro de una década, lleguemos, con dificultad, a siete o tal vez ocho gigahercios, pero ni siquiera estoy seguro de que lleguemos allí. Cuando miro la velocidad del reloj en 2021 en la mayoría de los proveedores de computación en la nube, está más alineada con típicamente 2 GHz, por lo que volvemos a la velocidad del reloj que teníamos hace 20 años, y esa es la solución más rentable.
Alcanzar el rendimiento actual de la CPU requirió una serie de innovaciones clave. Voy a presentar algunas de ellas, especialmente las que tienen un mayor impacto en el diseño de software empresarial. En esta pantalla, lo que estás viendo es el flujo de instrucciones de un procesador secuencial, como se hacían los procesadores hasta principios de los años 80. Tienes una serie de instrucciones que se ejecutan desde la parte superior del gráfico hasta la parte inferior, representando el tiempo. Cada instrucción pasa por una serie de etapas: buscar, decodificar, ejecutar y escribir de vuelta.
Durante la etapa de búsqueda, buscas la instrucción, registras, agarras la siguiente instrucción, incrementas el contador de instrucciones y preparas la CPU. Durante la etapa de decodificación, decodificas la instrucción y emites el microcódigo interno, que es lo que la CPU está ejecutando internamente. La etapa de ejecución implica agarrar las entradas relevantes de los registros y hacer el cálculo real, y la etapa de escritura implica obtener el resultado que acabas de calcular y ponerlo en algún lugar de uno de los registros. En este procesador secuencial, cada etapa requiere un ciclo de reloj, por lo que se necesitan cuatro ciclos de reloj para ejecutar una instrucción. Como hemos visto, es muy difícil aumentar la frecuencia de los ciclos de reloj en sí debido a muchas complicaciones.
El truco clave que se ha utilizado desde principios de los años 80 en adelante se conoce como segmentación. La segmentación puede acelerar enormemente el cálculo de tu procesador. La idea es que, debido a que cada instrucción pasa por una serie de etapas, vamos a superponer las etapas, y así la CPU misma va a tener todo un pipeline de instrucciones. En este diagrama, puedes ver una CPU con un pipeline de profundidad cuatro, donde siempre se están ejecutando cuatro instrucciones simultáneamente. Sin embargo, no están en la misma etapa: una instrucción está en la etapa de búsqueda, una en la etapa de decodificación, una en la etapa de ejecución y una en la etapa de escritura. Con este sencillo truco, representado aquí como un procesador de pipeline, hemos multiplicado el rendimiento efectivo del procesador por cuatro simplemente segmentando las operaciones. Todos los CPUs modernos utilizan la segmentación.
La siguiente etapa de esta mejora se llama supersegmentación. Los CPUs modernos van mucho más allá de la simple segmentación. En realidad, el número de etapas involucradas en un CPU moderno real es más parecido a 30 etapas. En el gráfico, puedes ver una CPU con 12 etapas como ejemplo, pero en realidad serían más parecidas a 30 etapas. Con este pipeline más profundo, se pueden ejecutar simultáneamente 12 operaciones, lo cual es muy bueno para el rendimiento y aún se utiliza el mismo ciclo de reloj.
Sin embargo, surge un nuevo problema: la siguiente instrucción comienza antes de que la anterior termine. Esto significa que si tienes operaciones que dependen entre sí, tienes un problema porque el cálculo de las entradas para la siguiente instrucción aún no está listo y tienes que esperar. Queremos utilizar todo el pipeline a nuestra disposición para maximizar la potencia de procesamiento. Por lo tanto, los CPUs modernos no buscan solo una instrucción a la vez, sino algo así como 500 instrucciones a la vez. Miran mucho más adelante en la lista de próximas instrucciones y las reorganizan para mitigar las dependencias, entrelazando los flujos de ejecución para aprovechar toda la profundidad del pipeline.
Hay muchas cosas que complican esta operación, especialmente las ramas. Una rama es simplemente una condición en la programación, como cuando escribes una declaración “if”. El resultado de la condición puede ser verdadero o falso, y dependiendo del resultado, tu programa ejecutará una pieza de lógica u otra. Esto complica la gestión de dependencias porque el CPU tiene que adivinar la dirección que van a tomar las ramas próximas. Los CPUs modernos utilizan la predicción de ramas, que implica heurísticas simples y tiene una precisión de pronóstico muy alta. Pueden predecir la dirección de las ramas con más del 99% de precisión, lo cual es mejor de lo que la mayoría de nosotros podemos hacer en un contexto real de supply chain. Esta precisión es necesaria para aprovechar los pipelines superprofundos.
Solo para darte una idea de las heurísticas utilizadas para la predicción de ramas, una heurística muy simple es decir que la rama irá en la misma dirección en la que fue la última vez. Esta heurística simple te da algo así como un 90% de precisión, lo cual es bastante bueno. Si le agregas un giro a esta heurística, que es que la rama irá en la misma dirección que la última vez, pero debes considerar el origen, por lo que es la misma rama proveniente del mismo origen, entonces obtendrás algo así como un 95% de precisión. Los CPUs modernos están utilizando perceptrones bastante complejos, que es una técnica de aprendizaje automático, para predecir la dirección de las ramas.
En las condiciones adecuadas, puedes predecir las ramas con bastante precisión y así aprovechar todo el pipeline para obtener el máximo rendimiento de un procesador moderno. Sin embargo, desde una perspectiva de ingeniería de software, debes llevarte bien con tu procesador, especialmente con la predicción de ramas. Si no te llevas bien, significa que el predictor de ramas se equivocará, y cuando eso suceda, el CPU predecirá la dirección de la rama, organizará el pipeline y comenzará a hacer cálculos antes de tiempo. Cuando se encuentre la rama y el cálculo se haya realizado efectivamente, el CPU se dará cuenta de que la predicción de la rama fue incorrecta. Una predicción de rama incorrecta no resulta en un resultado incorrecto; resulta en una pérdida de rendimiento. El CPU no tendrá otra alternativa que vaciar todo el pipeline, o una gran parte de él, esperar a que se realicen otros cálculos y luego reiniciar el cálculo. El impacto en el rendimiento puede ser muy significativo, y puedes perder fácilmente uno o dos órdenes de magnitud en rendimiento debido a la lógica del software empresarial que no se lleva bien con la lógica de predicción de ramas de tu CPU.
Otro truco notable más allá de la segmentación es la instrucción superescalar. Los CPUs típicamente procesan escalares, o pares de escalares, a la vez, por ejemplo, dos números con precisión de punto flotante de 32 bits. Realizan operaciones escalares, procesando esencialmente un número a la vez. Sin embargo, los CPUs modernos de la última década prácticamente todos han presentado instrucciones superescalares, que pueden procesar varios vectores de números y realizar operaciones vectoriales directamente. Esto significa que un CPU puede tomar un vector de, digamos, ocho números de punto flotante y un segundo vector de ocho números de punto flotante, realizar una suma y obtener un vector de números de punto flotante que representan los resultados de esta suma. Todo eso se hace en un solo ciclo.
Por ejemplo, conjuntos de instrucciones especializados como AVX2 te permiten realizar operaciones considerando 32 bits de precisión con paquetes de ocho números, mientras que AVX512 te permite hacerlo con paquetes de 16 números. Si eres capaz de aprovechar estas instrucciones, significa que literalmente puedes ganar un orden de magnitud en términos de velocidad de procesamiento porque una instrucción, un ciclo de reloj, realiza muchas más operaciones que procesar números uno por uno. Este proceso se conoce como SIMD (Single Instruction, Multiple Data) y es muy poderoso. Ha impulsado la mayor parte del progreso en la última década en términos de potencia de procesamiento, y los procesadores modernos son cada vez más basados en vectores y superescalares. Sin embargo, desde la perspectiva del software empresarial, es relativamente complicado. Con la segmentación, tu software tiene que comportarse bien, y tal vez esté comportándose bien con la predicción de ramas por accidente. Sin embargo, cuando se trata de instrucciones superescalares, no hay nada accidental. Tu software realmente necesita hacer algunas cosas de manera explícita, la mayor parte del tiempo, para aprovechar esta potencia de procesamiento adicional. No lo obtienes de forma gratuita; necesitas adoptar este enfoque y, por lo general, necesitas organizar los datos mismos para que tengas paralelismo de datos y los datos estén organizados de una manera adecuada para las instrucciones SIMD. No es ciencia de cohetes, pero no sucede por accidente y te brinda un impulso masivo en términos de potencia de procesamiento.
Ahora, los CPUs modernos pueden tener muchos núcleos, y un núcleo de CPU puede darte un flujo distinto de instrucciones. Con CPUs muy modernos que tienen muchos núcleos, típicamente, los CPUs actuales pueden llegar hasta 64 núcleos, es decir, 64 flujos de ejecución concurrentes independientes. Puedes alcanzar aproximadamente un teraflop, que es el límite superior de rendimiento de procesamiento que puedes obtener de un procesador muy moderno. Sin embargo, si quieres ir más allá de eso, puedes mirar las GPUs (Unidades de Procesamiento Gráfico). A pesar de lo que puedas pensar, estos dispositivos se pueden utilizar para tareas que no tienen nada que ver con gráficos.
Una GPU, como la de NVIDIA, es un procesador superescalar. En lugar de tener hasta 64 núcleos como los CPUs de gama alta, las GPUs pueden tener más de 10,000 núcleos. Estos núcleos son mucho más simples y no tan potentes o rápidos como los núcleos regulares de CPU, pero hay muchas veces más de ellos. Llevan SIMD a un nuevo nivel, donde puedes procesar no solo paquetes de 8 o 16 números a la vez, sino literalmente miles de números a la vez para realizar instrucciones vectoriales. Con las GPUs, puedes alcanzar un rango de más de 30 teraflops en solo un dispositivo, lo cual es enorme. Los mejores CPUs en el mercado pueden darte un teraflop, mientras que las mejores GPUs te darán más de 30 teraflops. Esa es una diferencia de más de un orden de magnitud, lo cual es muy significativo.
Si vas más allá de eso, para tipos especializados de cálculos como álgebra lineal (por cierto, cosas como el aprendizaje automático y deep learning son esencialmente álgebra lineal basada en matrices en todas partes), puedes tener procesadores como las TPUs (Tensor Processing Units). Google decidió llamarlas Tensores debido a TensorFlow, pero la realidad es que las TPUs serían mejor llamadas Unidades de Procesamiento de Multiplicación de Matrices. Lo interesante de la multiplicación de matrices es que no solo hay un montón de paralelismo de datos involucrado, sino que también hay una enorme cantidad de repetición involucrada porque las operaciones son altamente repetitivas. Al organizar una TPU como una matriz sistólica, que es esencialmente una cuadrícula bidimensional con unidades de cálculo en la cuadrícula, puedes superar la barrera del petaflop, logrando más de 1000 teraflops en solo un dispositivo. Sin embargo, hay un inconveniente: Google lo está haciendo con números de punto flotante de 16 bits en lugar de los habituales 32 bits. Desde una perspectiva de la cadena de suministro, una precisión de 16 bits no está mal; significa que tienes aproximadamente un 0.1% de precisión en tus operaciones, y para muchas operaciones de aprendizaje automático o estadísticas, una precisión del 0.1% está bastante bien si se hace correctamente y sin acumular sesgos.
Lo que vemos es que el camino del progreso en términos de hardware informático, cuando se trata solo de cálculo, ha sido ir hacia dispositivos más especializados y rígidos. Gracias a esta especialización, se pueden lograr enormes ganancias en potencia de procesamiento. Si pasas de una instrucción superescalar, ganas un orden de magnitud; si optas por una tarjeta gráfica, ganas uno o dos órdenes de magnitud; y si optas por álgebra lineal pura, ganas esencialmente dos órdenes de magnitud. Esto es muy significativo.
Por cierto, todos estos diseños de hardware son bidimensionales. Los chips modernos y las estructuras de procesamiento son muy planos. Una CPU moderna no involucra más de 20 capas, y dado que estas capas tienen solo unos pocos micrones de grosor, las CPUs, GPUs o TPUs son estructuras esencialmente planas. Podrías pensar, “¿Y qué pasa con la tercera dimensión?” Bueno, resulta que debido a la barrera de potencia, que es el problema de disipar la energía, realmente no podemos ir a la tercera dimensión porque no sabemos cómo evacuar toda la energía que se vierte en el dispositivo.
Lo que podemos predecir para la próxima década es que estos dispositivos seguirán siendo esencialmente bidimensionales. Desde la perspectiva del software empresarial, la lección más importante es que necesitas diseñar el paralelismo de datos desde el núcleo mismo de tu software. Si no haces eso, entonces no podrás aprovechar todo el progreso que está ocurriendo en cuanto a la potencia de cálculo en bruto. Sin embargo, no puede ser una ocurrencia tardía. Tiene que suceder en el núcleo mismo de la arquitectura, en el nivel en el que organizas todos los datos que deben procesarse en tus sistemas. Si no haces eso, te quedarás con el tipo de procesadores que teníamos hace dos décadas.
Ahora, en los años 80, la memoria era tan rápida como los procesadores, lo que significa que un ciclo de reloj era un ciclo de reloj tanto para la memoria como para la CPU. Sin embargo, esto ya no es así. Con el tiempo, desde los años 80, la relación entre la velocidad de la memoria y las latencias para acceder a los datos que ya están en los registros del procesador solo ha ido aumentando. Empezamos con una relación de uno a uno, y ahora tenemos una relación típicamente mayor a mil. Este problema se conoce como la barrera de la memoria, y solo ha ido aumentando en las últimas cuatro décadas. Aún está aumentando en la actualidad, aunque muy lentamente, principalmente porque la velocidad de reloj de los procesadores está aumentando muy lentamente. Debido a que los procesadores no están progresando mucho en términos de velocidad de reloj, este problema de la barrera de la memoria no está aumentando más. Sin embargo, el lugar en el que nos encontramos actualmente está increíblemente desequilibrado, donde acceder a la memoria es esencialmente tres órdenes de magnitud más lento que acceder a los datos que ya se encuentran convenientemente dentro del procesador.
Esta perspectiva contradice por completo toda la algorítmica clásica que todavía se enseña hoy en día en la mayoría de las universidades. El punto de vista algorítmico clásico asume que tienes un tiempo uniforme para acceder a la memoria, lo que significa que acceder a cualquier bit de memoria lleva la misma cantidad de tiempo. Pero en los sistemas modernos, esto no es absolutamente cierto. El tiempo que lleva acceder a una cierta porción de memoria depende mucho de dónde se encuentren físicamente los datos reales dentro de tu sistema informático.
Desde la perspectiva del software empresarial, resulta que, desafortunadamente, la mayoría de los diseños de software que se establecieron durante los años 80 y 90 ignoraron por completo el problema porque era muy menor durante la primera década. Solo se infló realmente en las últimas dos décadas, pero como resultado, la mayoría de los patrones vistos en el software empresarial actual antagonizan por completo este diseño, porque asumen que tienes acceso constante a la memoria.
Por cierto, si empiezas a pensar en lenguajes de programación como Python (lanzado por primera vez en 1989) o Java (en 1995) que presentan programación orientada a objetos, va en contra de la forma en que funciona la memoria en las computadoras modernas. Siempre que tienes objetos, y es aún peor si tienes enlaces tardíos como en Python, significa que para hacer cualquier cosa, tendrás que seguir punteros y hacer saltos aleatorios en la memoria. Si uno de esos saltos resulta ser desafortunado porque es una porción que no está sentada en el procesador, puede ser mil veces más lento. Eso es un problema muy grande.
Para comprender mejor la magnitud de la barrera de la memoria, es interesante observar las latencias típicas en una computadora moderna. Si escalamos esas latencias en términos humanos, supongamos que un procesador funciona a un ciclo de reloj por segundo. Bajo esa suposición, la latencia típica de la CPU sería de un segundo. Sin embargo, si queremos acceder a datos en la memoria, podría llevar hasta seis minutos. Entonces, mientras puedes realizar una operación por segundo, si quieres acceder a algo en la memoria, tienes que esperar seis minutos. Y si quieres acceder a algo en el disco, puede llevar hasta un mes o incluso todo un año. Esto es increíblemente largo, y de eso se trata de esas órdenes de magnitud de rendimiento que mencioné al principio de esta conferencia. Cuando estás lidiando con 15 órdenes de magnitud, es muy engañoso; no te das cuenta necesariamente del gran impacto en el rendimiento que puedes tener, donde literalmente puedes terminar teniendo que esperar el equivalente humano de meses si no estás colocando la información en el lugar correcto. Esto es absolutamente gigantesco.
Por cierto, los ingenieros de software empresarial no son los únicos que luchan con esta evolución del hardware informático moderno. Si observamos las latencias que obtenemos con tarjetas SSD súper rápidas, como la serie Intel Optane, podemos ver que la mitad de la latencia para acceder a la memoria en este dispositivo es causada por la sobrecarga del propio kernel, en este caso, el kernel de Linux. Es el propio sistema operativo el que genera la mitad de la latencia. ¿Qué significa eso? Bueno, significa que incluso las personas que están diseñando Linux tienen más trabajo por hacer para ponerse al día con el hardware moderno. No obstante, es un gran desafío para todos.
Sin embargo, realmente afecta al software empresarial, especialmente cuando se piensa en la optimización de la cadena de suministro, debido al hecho de que tenemos toneladas de datos para procesar. Ya es bastante complejo desde el principio. Desde la perspectiva del software empresarial, realmente necesitas adoptar un diseño que se lleve bien con la caché porque la caché contiene copias locales que son más rápidas de acceder y están más cerca de la CPU.
La forma en que funciona es que cuando accedes a un byte en tu memoria principal, no puedes acceder solo a un byte en el software moderno. Cuando quieres acceder incluso a un byte en tu RAM, el hardware en realidad copiará 4 kilobytes, esencialmente toda la página que tiene un tamaño de 4 kilobytes. La suposición subyacente es que cuando comienzas a leer un byte, el siguiente byte que vas a solicitar será el que sigue. Ese es el principio de localidad, lo que significa que si juegas según la regla y aplicas un acceso que preserve la localidad, entonces puedes tener una memoria que parezca funcionar casi tan rápido como tu procesador.
Sin embargo, eso requiere una alineación entre los accesos a la memoria y la localidad de los datos. En particular, hay muchos lenguajes de programación, como Python, que no ofrecen estas cosas de forma nativa. Al contrario, presentan un desafío enorme para lograr cualquier grado de localidad. Esta es una lucha inmensa y, en última instancia, es una batalla en la que tienes un lenguaje de programación que ha sido diseñado en torno a patrones que antagonizan por completo el hardware a nuestra disposición. Este problema no va a cambiar en la próxima década; solo empeorará.
Por lo tanto, desde la perspectiva del software empresarial, quieres aplicar la localidad de los datos pero también la minimización. Si puedes hacer que tus grandes datos sean pequeños, serán más rápidos. Eso es algo que no es muy intuitivo, pero si puedes reducir el tamaño de los datos, típicamente eliminando redundancias, puedes hacer que tu programa sea más rápido porque serás mucho más amigable con la caché. Encajarás más datos relevantes en los niveles de caché inferiores que tienen latencias mucho más bajas, como se muestra en esta pantalla.
Finalmente, discutamos específicamente el caso de la DRAM. La DRAM es literalmente el componente físico que compone la RAM que utilizas para tu estación de trabajo de escritorio o tu servidor en la nube. La DRAM también se llama memoria principal, que está construida a partir de chips de DRAM. En la última década, en términos de precios, la DRAM apenas ha disminuido. Pasamos de $5 por gigabyte a $3 por gigabyte una década después. El precio de la RAM sigue disminuyendo, aunque no muy rápido. Se ha estancado en los últimos años, y debido al hecho de que solo hay tres actores principales en este mercado que tienen la capacidad de fabricar DRAM a gran escala, hay muy pocas esperanzas de que haya algo inesperado en este mercado en la próxima década.
Pero eso ni siquiera es lo peor del problema. También está el consumo de energía por gigabyte. Si observas el consumo de energía, resulta que la RAM de hoy en día consume un poco más de energía por gigabyte que hace una década. La razón es esencialmente que la RAM que tenemos actualmente es más rápida, y se aplica la misma regla del límite de potencia: si aumentas la frecuencia del reloj, aumentas significativamente el consumo de energía. Por cierto, la RAM consume bastante energía porque la DRAM es fundamentalmente un componente activo. Necesitas actualizar la RAM todo el tiempo debido a las fugas eléctricas, por lo que si apagas la RAM, pierdes todos tus datos. Necesitas actualizar las celdas constantemente.
Por lo tanto, la conclusión para el software empresarial es que la DRAM es el único componente que ya no está progresando. Hay muchas cosas que aún están progresando muy rápidamente, como la potencia de procesamiento; sin embargo, este no es el caso de la DRAM, está muy estancada. Si tenemos en cuenta el consumo de energía, que también representa una parte importante de los costos de computación en la nube, la RAM apenas está progresando. Por lo tanto, si adoptas un diseño que enfatiza demasiado la memoria principal, y eso es típicamente lo que obtendrás cuando tienes un proveedor que dice: “Oh, tenemos un diseño en memoria para el software”, recuerda estas palabras clave.
Cada vez que escuches a un proveedor que te diga que tienen un diseño en memoria, lo que el proveedor te está diciendo, y esto no es una propuesta muy convincente, es que su diseño depende completamente de la evolución futura de la DRAM, donde ya sabemos que los costos no van a disminuir. Entonces, si tenemos en cuenta el hecho de que dentro de 10 años, es probable que tu cadena de suministro tenga aproximadamente 10 veces más datos para procesar solo porque las empresas están mejorando cada vez más en la recopilación de más datos dentro de sus cadenas de suministro y colaborando para recopilar más datos de sus clientes y proveedores, no es irrazonable esperar que dentro de una década, cualquier empresa grande que opere una gran cadena de suministro esté recopilando 10 veces más datos de los que tiene actualmente. Sin embargo, el precio por gigabyte de RAM seguirá siendo el mismo. Entonces, si haces los cálculos, podrías terminar con costos de computación en la nube o costos de TI que son casi una orden de magnitud más caros, solo para hacer prácticamente lo mismo, solo porque tienes que lidiar con una masa de datos en constante crecimiento que no se ajusta fácilmente en la memoria. La clave es que realmente quieres evitar todo tipo de diseños en memoria. Estos diseños están muy desactualizados, y veremos a continuación qué tipo de alternativa tenemos.
Ahora, echemos un vistazo al almacenamiento de datos, que se trata del almacenamiento persistente de datos. Básicamente, tienes dos clases de almacenamiento de datos generalizado. La primera es el disco duro (HDD) o discos rotativos. La segunda es la unidad de estado sólido (SSD). Lo interesante es que la latencia en los discos rotativos es terrible, y cuando miras esta imagen, puedes entender fácilmente por qué. Estos discos literalmente giran, y cuando quieres acceder a cualquier punto aleatorio de datos en el disco, en promedio, necesitas esperar medio giro del disco. Teniendo en cuenta que los discos de gama alta giran a unas 10,000 rotaciones por minuto, significa que tienes una latencia incorporada de tres milisegundos que no se puede comprimir. Es literalmente el tiempo que tarda el disco en girar y poder leer el punto preciso de interés en el disco. Es mecánico y no mejorará más.
Los HDD son terribles en términos de latencia, pero también tienen otro problema, que es el consumo de energía. Como regla general, tanto un HDD como un SSD consumen alrededor de tres vatios por hora por dispositivo. Ese es típicamente el estado actual en términos generales. Sin embargo, cuando el disco duro está funcionando, incluso si no estás leyendo activamente nada del disco duro, estarás consumiendo tres vatios solo porque necesitas mantener el disco girando. Alcanzar las 10,000 rotaciones por minuto lleva mucho tiempo, por lo que necesitas mantener el disco girando todo el tiempo, incluso si estás usando el disco con poca frecuencia.
Por otro lado, cuando se trata de unidades de estado sólido, consumen tres vatios cuando las accedes, pero cuando no accedes a los datos, casi no consumen energía. Tienen un consumo de energía residual, pero es extremadamente pequeño, del orden de los milivatios. Esto es muy interesante porque puedes tener toneladas de SSD; si no los estás usando, no pagas por la energía que consumen. Toda la industria ha estado haciendo una transición gradual de los HDD a los SSD en la última década.
Para entender esto, podemos ver esta curva. Lo que vemos es que el precio por gigabyte tanto de los HDD como de los SSD ha estado disminuyendo en los últimos años. Sin embargo, el precio ahora se está estabilizando. Los datos son un poco antiguos, pero no han variado mucho en los últimos años. Durante los últimos 10 años, vemos que hace una década, los SSD eran extremadamente caros, a $2,400 por terabyte, mientras que los discos duros eran solo $60 por terabyte. Sin embargo, en la actualidad, el precio de los discos duros se ha dividido por tres, esencialmente a $20 por terabyte. El precio de los SSD se ha dividido por más de 25, y la tendencia de disminución de los precios de los SSD no se detiene. Los SSD son en este momento, y probablemente durante la próxima década, el componente que más está progresando, y eso es muy interesante.
Por cierto, te dije que el diseño de los dispositivos informáticos modernos (CPU, GPU, TPU) era esencialmente bidimensional con un máximo de 20 capas. Sin embargo, cuando se trata de los SSD, el diseño es cada vez más tridimensional. Los SSD más recientes tienen algo así como 176 capas. Estamos alcanzando, en términos de orden, las 200 capas. Debido a que esas capas son increíblemente delgadas, no es irrazonable esperar que en el futuro tengamos dispositivos con miles de capas y capacidades de almacenamiento potencialmente de órdenes de magnitud mayores. Obviamente, el truco será que no podrás acceder a todos estos datos todo el tiempo, nuevamente, debido al silicio oscuro y la disipación de energía.
Resulta que si lo haces bien, se accede muy poco a muchos datos. Los SSD implican un diseño de hardware muy específico que viene con muchas peculiaridades, como el hecho de que solo puedes encender los bits pero no apagarlos. Básicamente, imagina que inicialmente tienes todos ceros; puedes convertir un cero en un uno, sin embargo, no puedes convertir este uno en un cero localmente. Si quieres hacer eso, tienes que reiniciar todo el bloque que puede ser tan grande como ocho megabytes, lo que significa que cuando estás escribiendo, puedes convertir bits de cero a uno, pero no de uno a cero. Para convertir bits de uno a cero, debes vaciar todo el bloque y volver a escribirlo, lo que conduce a todo tipo de problemas conocidos como amplificación de escritura.
Durante la última década, las unidades SSD tienen internamente una capa llamada capa de traducción de flash que puede mitigar todos esos problemas. Estas capas de traducción de flash están mejorando cada vez más con el tiempo. Sin embargo, hay grandes oportunidades para mejorar aún más, y en términos de software empresarial, significa que realmente quieres optimizar tu diseño para aprovechar al máximo los SSD. Los SSD ya son una opción mucho mejor que la DRAM cuando se trata de almacenar datos, y si lo haces inteligentemente, puedes esperar, dentro de una década, ganancias de órdenes de magnitud que se obtendrán a través del progreso de la industria del hardware, lo cual no es el caso en lo que respecta a la DRAM.
Finalmente, hablemos de ancho de banda. El ancho de banda es probablemente el problema más resuelto en términos de tecnología. Sin embargo, incluso si se puede lograr el ancho de banda, podemos lograr los tipos de anchos de banda que son absolutamente increíbles en la fecha actual. Comercialmente, la industria de las telecomunicaciones es muy compleja y hay toneladas de problemas, por lo que los consumidores finales no ven realmente todos los beneficios del progreso que se ha logrado en términos de comunicaciones ópticas.
En términos de comunicación óptica con transceptores de fibra óptica, el progreso es absolutamente increíble. Probablemente sea una de esas cosas que están progresando como lo hacían las CPUs en los años 80 o 90. Solo para darte una idea, con la multiplexación por división de longitud de onda (WDM) o la multiplexación por división de espacio (SDM), ahora podemos alcanzar literalmente una décima de terabytes de datos transferidos por segundo en un solo cable de fibra óptica. Esto es absolutamente enorme. Estamos llegando al punto en el que un solo cable puede transportar suficientes datos para alimentar prácticamente un centro de datos completo. Lo que es aún más impresionante es que la industria de las telecomunicaciones ha logrado desarrollar nuevos transceptores que pueden ofrecer estas actuaciones absolutamente locas basadas en cables antiguos. Ni siquiera tienes que desplegar nuevas fibras en las calles o físicamente; literalmente puedes tomar la fibra que se desplegó hace una década, desplegar el nuevo transceptor y tener varios órdenes de magnitud más de ancho de banda en el mismo cable.
Lo interesante es que hay una ley general de las comunicaciones ópticas: cada década, la distancia se reduce en la que se vuelve interesante reemplazar la comunicación eléctrica con comunicaciones ópticas. Si retrocedemos unas décadas, hace dos décadas, se necesitaban unos 100 metros para que la comunicación óptica superara a la comunicación eléctrica. Entonces, si tenías distancias inferiores a 100 metros, optabas por el cobre; si tenías más de 100 metros, optabas por la fibra. Sin embargo, hoy en día, con la última generación, podemos tener una distancia donde la óptica está ganando incluso a distancias tan cortas como tres metros. Si miramos una década hacia adelante, no me sorprendería ver situaciones en las que las comunicaciones ópticas estén ganando incluso si estamos mirando distancias tan cortas como medio metro. Esto significa que en algún momento, no me sorprendería si las computadoras mismas tienen vías ópticas en su interior, simplemente porque es más eficiente que las vías eléctricas.
Desde la perspectiva del software empresarial, esto también es muy interesante porque significa que si estás pensando en el futuro, el ancho de banda va a disminuir drásticamente en costos. Esto está subsidiado en gran medida por empresas como Netflix, que tienen un consumo dramático de ancho de banda. Esto significa que, para evitar la latencia, podrías hacer cosas como recopilar toneladas de datos de manera preventiva hacia el usuario y luego permitir que el usuario interactúe con datos que se han acercado mucho más a ellos con una latencia mucho más corta. Incluso si traes datos que no se necesitan, lo que te mata es la latencia, no el ancho de banda. Es mejor decir: “Tengo dudas sobre qué tipo de datos se necesitarán; puedo tomar mil veces más datos de los que realmente necesito, simplemente acércalos al usuario final, permite que el usuario o el programa interactúen con estos datos y minimiza el viaje de ida y vuelta, y estaré ganando en términos de rendimiento”. Esto nuevamente tiene un impacto profundo en el tipo de decisiones arquitectónicas que se toman hoy en día porque condicionarán si puedes obtener rendimiento con el avance de esta clase de hardware dentro de una década.
En conclusión, la latencia es la gran batalla de nuestro tiempo en términos de ingeniería de software. Esto realmente condiciona todos los tipos de rendimiento que tenemos y que tendremos. El rendimiento es absolutamente clave porque no solo impulsará el costo de TI, sino que también impulsará la productividad de las personas que operan en tu cadena de suministro. En última instancia, eso también impulsará el rendimiento de la cadena de suministro en sí, porque si no tienes este rendimiento, ni siquiera puedes implementar una especie de receta numérica que realmente sea inteligente y ofrezca optimización avanzada y eventos de optimización predictiva, que es lo que buscamos. Sin embargo, en general, esta batalla por un mejor rendimiento no se está ganando, al menos no en el ámbito del software empresarial. Los nuevos sistemas pueden ser, y con frecuencia son, más lentos que los antiguos. Este es un problema agudo. Un rendimiento de software más lento genera costos desorbitados para las empresas que caen en ello.
Solo para darte un ejemplo, no se debe considerar como un hecho que un hardware informático mejor te brinde un mejor rendimiento. Algunas personas en Internet decidieron medir la latencia de entrada, o retraso de entrada, que es el tiempo que transcurre después de presionar una tecla hasta que se muestra la letra correspondiente en la pantalla. Con un Apple II en 1983, que tenía un procesador de 1 MHz, el tiempo que llevaba era de 30 milisegundos. En 2016, con un Lenovo X1, equipado con un procesador de 2.6 GHz, una computadora portátil muy buena, el tiempo de latencia resultó ser de 110 milisegundos. Entonces tenemos un hardware informático que es varias miles de veces mejor, pero terminamos con una latencia que es casi cuatro veces más lenta. Esto es característico de lo que sucede cuando no tienes empatía mecánica y no prestas atención al hardware informático que tienes. Si te enfrentas al hardware informático, te recompensa con un mal rendimiento.
El problema es muy real. Mi sugerencia es que, cuando comiences a buscar cualquier software empresarial para tu empresa, ya sea de código abierto o no, recuerdes los elementos de empatía mecánica que has aprendido hoy. Mira el software y piensa detenidamente si abraza las tendencias profundas del hardware informático o si las ignora por completo. Si las ignora, significa que no solo el rendimiento no mejorará con el tiempo, sino que lo más probable es que empeore. La mayoría de las mejoras en la actualidad se logran a través de la especialización en lugar de la velocidad del reloj. Si te pierdes esta autopista, estás tomando un camino que se volverá más lento con el tiempo. Evita estas soluciones porque generalmente resultan de decisiones de diseño clave tempranas que no se pueden deshacer. Estarás atrapado con ellas para siempre, y solo empeorará año tras año. Piensa en una década por delante cuando comiences a mirar estos ángulos.
Ahora echemos un vistazo a las preguntas. Esa fue una conferencia bastante larga, pero es un tema desafiante.
Pregunta: ¿Cuál es tu opinión sobre las computadoras cuánticas y su utilidad para abordar problemas complejos de optimización de la cadena de suministro?
Una pregunta muy interesante. Me registré para la versión beta de la computadora cuántica de IBM hace 18 meses, cuando abrieron el acceso a su computadora cuántica en la nube. Mi sensación es que es emocionante, ya que los expertos pueden ver todas las curvas S aplanándose, pero no ven las nuevas curvas que aparecen de la nada. La computación cuántica es una de ellas. Sin embargo, creo que las computadoras cuánticas presentan desafíos muy difíciles en lo que respecta a las cadenas de suministro. Primero, como dije, la batalla de nuestro tiempo en términos de software empresarial es la latencia, y las computadoras cuánticas no hacen nada al respecto. Las computadoras cuánticas te brindan hasta potencialmente 10 órdenes de magnitud de aceleración para problemas de cálculo muy ajustados. Entonces, las computadoras cuánticas serían la siguiente etapa más allá de las TPUs, donde puedes realizar operaciones muy ajustadas increíblemente rápido.
Esto es muy interesante, pero siendo honesto, en este momento hay muy pocas empresas, que yo sepa, que incluso estén logrando aprovechar las instrucciones superscalares dentro de su software empresarial. Eso significa que todo el mercado está dejando una mejora de velocidad de 10 a 28 en la mesa que son las GPUs superscalares. Hay muy pocas personas en el mundo de la cadena de suministro que lo estén haciendo; tal vez Lokad, tal vez no. Las TPUs, creo que literalmente nadie. Google lo está haciendo extensivamente, pero no conozco a nadie que haya utilizado TPUs para algo relacionado con la cadena de suministro. Los procesadores cuánticos serían la etapa más allá de las TPUs.
Definitivamente estoy muy atento a lo que está sucediendo con las computadoras cuánticas, pero creo que este no es el cuello de botella al que nos enfrentamos. Es emocionante porque revisamos el diseño de von Neumann establecido hace unos 70 años, pero este no es el cuello de botella al que nos enfrentaremos nosotros ni la cadena de suministro en la próxima década. Después de eso, tu conjetura es tan buena como la mía. Sí, podría cambiar todo o no.
Pregunta: Las ofertas de Cloud y SaaS están permitiendo a las organizaciones aprovechar y convertir costos fijos. ¿Las empresas que ofrecen dichos servicios también están trabajando para reducir sus costos fijos y el riesgo asociado?
Bueno, depende. Si soy una plataforma de computación en la nube y te vendo potencia de procesamiento, ¿realmente me interesa hacer que tu software empresarial sea lo más eficiente posible? No realmente. Te vendo máquinas virtuales, gigabytes de ancho de banda y almacenamiento, así que en realidad, todo lo contrario. Mi interés es asegurarme de que tengas un software que sea lo menos eficiente posible, para que consumas y pagues por una cantidad loca de recursos según lo necesites.
Internamente, las grandes empresas de tecnología como Microsoft, Amazon y Google son increíblemente agresivas cuando se trata de la optimización de sus recursos informáticos. Pero también son agresivas cuando se trata de pagar la factura cuando cobran a un cliente por alquilar una máquina virtual. Si el cliente está alquilando una máquina virtual que es 10 veces más grande de lo que debería ser solo porque el software empresarial que están utilizando es muy ineficiente, no les interesa interrumpir el error del cliente. Para ellos está bien, es buen negocio. Cuando piensas que los integradores de sistemas y las plataformas de computación en la nube tienden a trabajar juntos como socios, te das cuenta de que estas categorías de personas no necesariamente tienen tu mejor interés en mente. Ahora, cuando se trata de SaaS, es un poco diferente. De hecho, si terminas pagando a un proveedor de SaaS por usuario, entonces es de interés de la empresa, y ese es el caso de Lokad, por ejemplo. No cobramos por los recursos informáticos que consumimos; normalmente cobramos a nuestros clientes según tarifas mensuales fijas. Por lo tanto, los proveedores de SaaS tienden a ser muy agresivos cuando se trata de su propio consumo de recursos informáticos.
Sin embargo, ten cuidado, hay un sesgo: si eres una empresa de SaaS, es posible que no quieras hacer algo que sería mucho mejor para tus clientes pero mucho más costoso en términos de hardware para ti. No todo es bueno y bonito. Hay una especie de conflicto de intereses que afecta a todos los proveedores de SaaS que operan en el espacio de la cadena de suministro. Por ejemplo, podrían invertir en la reingeniería de todos sus sistemas para ofrecer una mejor latencia y páginas web más rápidas, pero el problema es que eso cuesta recursos y sus clientes no necesariamente les van a pagar más por hacerlo.
El problema tiende a amplificarse cuando se trata de software empresarial. ¿Por qué es eso? Porque la persona que compra el software generalmente no es la persona que lo usa. Es por eso que gran parte del sistema empresarial es increíblemente lento. La persona que compra el software no sufre tanto como un planificador de demanda pobre o un administrador de inventario que tiene que lidiar con un sistema súper lento todos los días del año. Así que hay otro ángulo que es específico del ámbito del software empresarial. Realmente necesitas analizar la situación, teniendo en cuenta todos los incentivos que están en juego, y cuando se trata de software empresarial, generalmente hay muchos incentivos conflictivos.
Pregunta: ¿Cuántas veces ha tenido que revisar Lokad su enfoque, dado el progreso en el hardware observado? ¿Puede mencionar un ejemplo, si es posible, para poner este contenido en contexto de problemas reales resueltos?
Lokad, creo, reingenierizó extensivamente nuestra pila tecnológica unas seis veces. Sin embargo, Lokad fue fundada en 2008 y tuvimos unas seis reescrituras importantes de toda la arquitectura. No fue porque el software hubiera progresado tanto; el software había progresado, sí, pero lo que impulsó la mayoría de nuestras reescrituras no fue el hecho de que el hardware hubiera progresado tanto. Fue más como que habíamos ganado comprensión en el hardware. Todo lo que he presentado hoy era conocido por las personas que ya estaban prestando atención hace una década. Entonces, ves, sí, el hardware está evolucionando, pero esto es muy lento y la mayoría de las tendencias son muy predecibles, incluso una década antes. Se está jugando un juego largo.
Lokad tuvo que someterse a reescrituras masivas, pero fue más un reflejo de que gradualmente nos estábamos volviendo menos incompetentes. Estábamos adquiriendo competencia y, por lo tanto, teníamos una mejor comprensión de cómo aprovechar el hardware, en lugar de que el hardware hubiera estado cambiando la tarea. No siempre fue cierto; hubo elementos específicos que realmente cambiaron el juego para nosotros. El más notable fue SSD. Hicimos la transición de HDD a SSD y fue un cambio completo en nuestro rendimiento, con impactos masivos en nuestra arquitectura. En términos de ejemplos muy concretos, todo el diseño de Envision, el lenguaje de programación específico del dominio que Lokad proporciona, se basa en las ideas que recopilamos a nivel de hardware. No es solo un logro; se trata de hacer todo lo que puedas pensar simplemente más rápido.
¿Quieres procesar una tabla con mil millones de filas y 100 columnas, y quieres hacerlo 100 veces más rápido con los mismos recursos informáticos? Sí, puedes hacerlo. ¿Quieres poder hacer uniones entre tablas muy grandes con recursos informáticos mínimos? Sí, de nuevo. ¿Puedes tener paneles de control súper complejos con literalmente cien tablas mostradas al usuario final en menos de 500 milisegundos? Sí, lo logramos. Estos son logros mundanos, pero es porque logramos todos esos que podemos poner recetas de optimización predictiva bastante sofisticadas en producción. Necesitamos asegurarnos de que todos los pasos que nos llevaron allí se realicen con una productividad muy alta.
El mayor desafío cuando quieres hacer algo muy sofisticado para la cadena de suministro en términos de recetas numéricas no es la etapa de “hacer que funcione”. Puedes tomar estudiantes universitarios y lograr una serie de prototipos que brindarán alguna mejora en el rendimiento de la cadena de suministro en cuestión de semanas. Solo tomas Python y cualquier biblioteca de aprendizaje automático de código abierto al azar del día, y esos estudiantes, si son inteligentes y están dispuestos, producirán un prototipo funcional en cuestión de semanas. Sin embargo, nunca lo llevarás a producción a gran escala. Ese es el problema. Se trata de cómo superar todas esas etapas de madurez de “hacerlo bien”, “hacerlo rápido” y “hacerlo barato”. Ahí es donde realmente brilla la afinidad con el hardware y tu capacidad para iterar.
No hay un solo logro. Sin embargo, todo lo que hacemos, por ejemplo, cuando decimos que Lokad está haciendo pronóstico probabilístico, no requiere tanto poder de procesamiento. Lo que realmente requiere poder de procesamiento es aprovechar distribuciones muy extensas de probabilidades y analizar todos esos futuros posibles y combinar todos esos futuros posibles con todas las decisiones posibles que puedes tomar. De esa manera, puedes elegir los mejores con optimización financiera, lo cual es muy costoso. Si no tienes algo que esté muy optimizado, estás atrapado. El simple hecho de que Lokad pueda usar pronóstico probabilístico en producción es una prueba de que tuvimos una optimización a nivel de hardware extensa en todos los pasos para todos nuestros clientes. Actualmente estamos sirviendo a alrededor de 100 empresas.
Pregunta: ¿Es mejor tener un servidor interno para software empresarial (ERP, WMS) en lugar de usar servicios en la nube para evitar la latencia?
Diría que hoy en día no importa porque la mayoría de las latencias que experimentas están dentro del sistema. Este no es el problema de la latencia entre tu usuario y el ERP. Sí, si tienes una latencia muy pobre, podrías agregar alrededor de 50 milisegundos de latencia. Obviamente, si tienes un ERP, no quieres tenerlo en Melbourne mientras operas en París, por ejemplo. Quieres mantener el centro de datos cerca de donde estás operando. Sin embargo, las plataformas modernas de computación en la nube tienen docenas de centros de datos, por lo que no hay mucha diferencia en términos de latencia entre el alojamiento interno y los servicios en la nube.
Típicamente, el alojamiento interno no significa colocar el ERP en el suelo en medio de la fábrica o el almacén. En cambio, significa poner tu ERP en un centro de datos donde estás alquilando hardware de computación. Creo que no hay una diferencia práctica entre el alojamiento interno y las plataformas de computación en la nube desde la perspectiva de las plataformas modernas de computación en la nube con centros de datos en todo el mundo.
Lo que realmente marca la diferencia es si tienes un ERP que minimiza internamente todos los viajes de ida y vuelta. Por ejemplo, lo que típicamente afecta el rendimiento de un ERP es la interacción entre la lógica empresarial y la base de datos relacional. Si tienes cientos de interacciones de ida y vuelta para mostrar una página web, tu ERP será terriblemente lento. Por lo tanto, debes considerar diseños de software empresarial que no tengan una gran cantidad de viajes de ida y vuelta. Esta es una propiedad interna del software empresarial que estás analizando y no depende mucho de dónde ubiques el software.
Pregunta: ¿Crees que necesitamos nuevos lenguajes de programación que abarquen el nuevo diseño de hardware a nivel de núcleo, utilizando las características de la arquitectura de hardware al máximo?
Sí, y sí. Pero para ser sincero, tengo un conflicto de intereses aquí. Esto es precisamente lo que Lokad ha hecho con Envision. Envision nació de la observación de que es complicado aprovechar toda la potencia de procesamiento disponible en las computadoras modernas, pero no debería ser así si diseñas el lenguaje de programación en sí mismo teniendo en cuenta el rendimiento. Puedes hacerlo sobrenatural, y por eso, en la conferencia 1.4 sobre paradigmas de programación para la cadena de suministro, dije que si eliges los paradigmas de programación correctos, como la programación de matrices o la programación de marcos de datos, y construyes un lenguaje de programación que abarque esos conceptos, obtienes un rendimiento casi gratuito.
El precio que pagas es que no eres tan expresivo como un lenguaje de programación como Python o C++, pero si estás dispuesto a aceptar una expresividad reducida y cubrir todos los casos de uso relevantes para la cadena de suministro, entonces sí, puedes lograr mejoras de rendimiento masivas. Esa es mi creencia, y por eso también afirmé que, por ejemplo, la programación orientada a objetos desde la perspectiva de la optimización de la cadena de suministro no aporta nada.
Al contrario, este es una especie de paradigma que solo antagoniza el hardware informático subyacente. No estoy diciendo que la programación orientada a objetos sea completamente mala; eso no es lo que estoy diciendo. Estoy diciendo que hay áreas de la ingeniería de software donde tiene mucho sentido, pero no tiene sentido en lo que respecta a la optimización predictiva de la cadena de suministro. Así que sí, definitivamente necesitamos lenguajes de programación que realmente abracen eso.
Sé que tiendo a repetir esto, pero Python fue diseñado básicamente a fines de los años 80 y se perdieron todo lo que había que ver sobre las computadoras modernas. Tienen algo donde, por diseño, no pueden aprovechar el multi-threading. Tienen este bloqueo global, por lo que no pueden aprovechar múltiples núcleos. No pueden aprovechar la localidad. Tienen enlace tardío que realmente complica los accesos a la memoria. Son muy variables, por lo que consumen mucha memoria, lo que significa que jugará en contra de la caché, etc.
Estos son los tipos de problemas donde, si usas Python, significa que vas a enfrentar batallas cuesta arriba en las próximas décadas, y la batalla solo empeorará con el tiempo. No mejorarán en absoluto.
La próxima conferencia será dentro de tres semanas, el mismo día de la semana, a la misma hora. Será a las 3 PM hora de París, el 9 de junio. Vamos a discutir algoritmos modernos para la cadena de suministro, que es un poco el contraparte de las computadoras modernas para la cadena de suministro. Nos vemos la próxima vez.
