Andrew Phillips ha trabajado en el bróker LMAX durante 17 años y actualmente es el director de tecnología (CTO) de la empresa. Su presupuesto se mide en milisegundos. Aunque la latencia de extremo a extremo que LMAX garantiza para transacciones de alta frecuencia es de 50 ms, el tiempo máximo que se permite que funcione cualquier aplicación es de ocho nanosegundos. Cuando el presupuesto se mide en nanosegundos, incluso el retraso potencial más pequeño tiene un impacto negativo. «Nuestros clientes son las grandes casas comerciales y quieren algo que funcione muy rápido y de manera muy determinista», dice Phillips. «Probaremos varios cables Twinax y usaremos conexión directa en lugar de usar fibra óptica, porque se necesita una cantidad pequeña pero medible de nanosegundos para convertir una señal eléctrica en luz, transmitirla por una fibra y luego convertirla nuevamente en una señal eléctrica». Un enfoque diferente al rendimiento del software Cuando la empresa comenzó a construir su plataforma en 2010, Phillips dice que era una práctica común usar una metodología en cascada y desarrollar el software utilizando el lenguaje de programación C++. Sin embargo, el intercambio de LMAX se construye utilizando una metodología ágil y está programado en Java. «El uso de técnicas ágiles y Java, con su ecosistema de pruebas inmensamente rico, se consideraba bastante extraño», dice. A diferencia de C++, donde el código de la aplicación primero se compila en un programa de código de máquina que luego se ejecuta directamente en el microprocesador (procesador), Java es un lenguaje de programación que utiliza la compilación en tiempo de ejecución. Esto significa que el código Java se compila «sobre la marcha» a medida que se ejecuta el programa. Java también ofrece una gestión de memoria incorporada llamada «recolección de basura», que puede afectar el rendimiento de un programa, como explica Phillips: «Tenemos muchas preguntas incómodas de clientes potenciales sobre picos de latencia y recolección de basura. «Comenzamos con el JDK estándar en 2013. Lo que nos dimos cuenta fue que Java tenía una herencia: fue diseñado para decodificadores y era más feliz cuando le dabas unos 4 GB de memoria». Según Phillips, más de 4 GB de memoria del sistema significaba que los tiempos de recolección de basura se volvían inestables desde una perspectiva de latencia. “No queríamos sacrificar la expresividad o la velocidad de escritura en Java, así como el ecosistema de pruebas, que realmente ha sustentado gran parte de nuestro éxito”. La empresa ha estado utilizando la plataforma Java del sistema Azul para sortear las limitaciones de memoria del entorno Java estándar. “En ese momento, si tenía un servidor con 64 Gb de memoria, evitar la recolección de basura era esencial”, añade Phillips. Azul, dice, solo recolecta basura como último recurso. “Esto es genial para nosotros porque estábamos reduciendo nuestra latencia de intercambio, en ese momento, de un milisegundo a donde estamos ahora, que son 50 microsegundos”. Y dentro de esa pequeña ventana de 50 microsegundos, suceden muchísimas cosas. “50 microsegundos es el tiempo que transcurre desde que se envía un pedido en el borde de nuestra red, hasta que se procesa, se combina y luego se envía el acuse de recibo”, añade Phillips. “A falta de ser un desarrollador de compiladores profesional, desafío incluso a los mejores programadores a que lo hagan tan bien como un compilador en términos de optimización” Andrew Phillips, LMAX Con esta ventana de 50 microsegundos, el código Java tiene solo ocho nanosegundos para ejecutarse, ya que la mayor parte de la latencia se produce cuando la transacción pasa por la infraestructura de red hasta el servidor. Phillips cree que Java, como lenguaje de programación, es mejor para optimizar el código en comparación con alguien que codifica manualmente para un alto rendimiento. “Vengo de un entorno de C, C++ y Fortran, y tiendes a recurrir al lenguaje ensamblador para que las cosas se ejecuten más rápido. [Java] “Es un poco contraintuitivo”, dice. Según Phillips, los microprocesadores modernos son tan increíblemente complicados que si un desarrollador elige escribir algo en C o C++, el código se optimiza solo para la arquitectura de procesador “objetivo” que el desarrollador configuró en la herramienta de compilación de C o C++. “Una de las ventajas de ejecutar Java es que está optimizado para el procesador en el que se ejecuta”, dice. “Eso puede ser bastante importante. A menos que sea un desarrollador de compiladores profesional, desafío incluso a los programadores extremadamente buenos a que lo hagan tan bien como un compilador en términos de optimización”. Por lo general, un programador de C++ usaría el compilador de C++ en su máquina de desarrollo para compilar la aplicación, utilizando el procesador del servidor como la arquitectura de destino. Esto se soluciona de manera efectiva y la aplicación solo se optimiza para ese procesador de servidor en particular. Pero, como señala Phillips, los entornos de desarrollo y prueba pueden tener varias generaciones de arquitectura de procesador detrás de los servidores de producción. Los entornos de ensayo, donde se mueve el código antes de pasar a producción, también es probable que ejecuten generaciones anteriores de procesadores de servidor. Java es capaz de optimizar el código en tiempo de ejecución y, por lo tanto, aprovechar cualquier característica de aceleración de código disponible en el hardware de destino en el que se ejecuta el código. «Como soy un poco incrédulo, era bastante escéptico de que Java pudiera hacer esto», dice Phillips. «Me convertí después de tener una competencia de codificación entre un programador experto de Java y yo, escribiendo en lenguaje C y ensamblador. Simplemente no podía superar la velocidad del programa Java». Cuando se le pregunta sobre el mayor desafío al que se enfrenta, Phillps dice: «Lo más importante que me ralentiza en Java es poder acceder a una gran cantidad de memoria con latencias deterministas muy bajas. Este es uno de nuestros desafíos de ingeniería clave. El mayor problema que tengo ahora es probablemente la latencia de la memoria». Avances en la tecnología de baja latencia En el futuro, Phillips dice que está impresionado por las oportunidades en latencia de hardware que promete la tecnología CXL. Compute Express Link (CXL) permite la conectividad de memoria directa entre diferentes bits de hardware. “CXL tiene un potencial enorme para cambiar por completo lo que hacemos porque la diferencia entre el bus de memoria, el bus periférico y la capa de red comienza a difuminarse en una sola”, afirma. Sin embargo, aunque CXL se promocionó como una tecnología que cambiaría la arquitectura del hardware informático en cuestión de meses, aún no ha ganado impulso. Haciendo una analogía entre CXL y la energía de fusión, Phillips agrega: “Siempre son 10 años. La idea de realizar llamadas a procedimientos remotos sobre una estructura CXL es muy atractiva”. Para Phillips, CXL ofrece una forma de evitar la sobrecarga de los protocolos de red tradicionales. “Todo se ejecuta en UDP IP o TCP IP, que son [networking] Protocolos diseñados en los años 60 y principios de los 70, cuando un módem de acceso telefónico [connectivity] Aunque reconoce el “fantástico esfuerzo de ingeniería” que ha permitido que estos protocolos evolucionen hasta donde están ahora con 25 gigabit ethernet, Phillips dice: “Sería bueno y haría las cosas mucho más rápidas si no tuviéramos la sobrecarga de la encapsulación IP”. Este trabajo continuo de exploración del arte de lo posible ayuda a LMAX a procesar transacciones comerciales con la menor latencia que permitan las leyes de la física, le da a la empresa un margen de maniobra y le permite manejar un rendimiento inesperadamente alto. Por ejemplo, recordando la enorme cantidad de volatilidad en el mercado de criptomonedas que ocurrió el año pasado que hizo que las bolsas de criptomonedas cayeran, Phillips dice: “No caímos. De hecho, vimos un aumento masivo en el volumen a medida que las personas descargaban los riesgos de nuestra bolsa entre sí”. A pesar de que el volumen de operaciones no estaba ni cerca del máximo que LMAX podía manejar, dice que la empresa pudo manejar las operaciones para el mercado de criptomonedas total y, según Phillips, había mucho margen de maniobra.