I have become comfortably numb

Esta entrada es técnicamente bastante compleja. Avisados estáis.

Como alguno de los lectores sabrá, uno de mis pasatiempos es la ingeniería financiera. Sinceramente no tengo ninguna intención de hacerme insultantemente rico, simplemente me pareció una manera entretenida de hacer gimnasia mental con lo ya sé sobre computación, matemáticas y estadística.

Siempre me ha sorprendido que, aunque lo llaman ingeniería, la herramienta más utilizada para la implementación de algoritmos sea MS Excel. Es más, hablando con la gente de Microsoft, me aseguran que el nuevo Excel que ejecuta en paralelo será un bombazo dentro de los mercados financieros. Y yo, mientras tanto, sigo sin dar crédito a lo que oigo

La mayoría de las cosas que hago empiezan con un "seguro que no tiene que ser tan difícil". Muchas de ellas terminan en nada porque resulta que sí eran tan difíciles. En estos casos me siento como un necio, no lo cuento a nadie y termina en un directorio perdido de algún ordenador. En el tema de la ingeniería financiera me planteé que seguro que no era tan difícil hacer lo siguiente:

Muchos de los algoritmos de cálculo de futuros y opciones, especialmente los que tratan de predecir el precio de opciones de más de un asset, requieren integraciones en muchas dimensiones, lo que implica el uso de grandes potencias de cálculo. La respuesta obvia es: -usa un superordenador, melón. El gran inconveniente de un ordenador de memoria compartida es que los trabajos no entran instantáneamente. Estás a merced de un gestor de colas que luego se encarga de ejecutar tu aplicación y devolverte un resultado. Luego escribe en disco, te llevas el archivo y lo post procesas en otro sitio. Esto es demasiado lento para alguien que tiene que tomar una decisión en segundos o para los sistemas de compra y venta automatizados.

Se me ocurrió entonces que nada impide que un proceso MPI se quede activo en un cluster del mismo modo que un servidor web se queda activo esperando algún request. Pero un servidor debe ser capaz de gestionar su memoria en tiempo real, algo que no es especialmente fácil si utilizas un lenguaje estático como los habituales en entornos de supercomputación. La elección de una arquitectura servidor - cliente implica que también hay que programar el cliente y definir el protocolo de comunicación. Un sarao, vamos.

Hasta que me acordé que es fácil hacer estas cosas con Python. Y me puse a hacerlo.

¿Qué tengo ahora? Un servidor que se ejecuta en un cluster como un proceso python paralelo en el que las cuentas se hacen mediante una biblioteca escrita en C++ que se conecta al servidor mediante un wrapper hecho con swig. Tanto el cliente como el servidor se conectan mediante Twisted (los que progamaron twisted se merecen un puto monumento) de manera que cualquiera que tenga un cliente conectado al servidor le pueden pedir que valore una opción americana o europea mediante el método de cálculo disponible (de momento Black Scholes para las europeas y un Binary Black Scholes Lattice para las americanas). Sin ningún tipo de lag o espera porque el servidor está siempre vivo y escuchando en el puerto que uno elija.

Para rizar aún más el rizo, la aplicación puede utilizar varios núcleos con OpenMP y el mismo código fuente se puede compilar con el compilador de GNU y el de Intel en Linux y el Visual C++ 2008 en Windows. La voy a presentar en sociedad en el ISC 2010 en Hamburgo este Junio. Probablemente nadie entienda absolutamente nada de lo que estoy haciendo pero a mi me suda la polla.

Porque resulta que no era tan difícil.