9 votos

Tamaño del libro de órdenes limitadas

Estoy tratando de escribir un libro de órdenes limitadas altamente optimizado y me preguntaba qué tipo de tamaño puedo esperar:

  • Gama de precios límite
  • Número de órdenes a cada precio límite

Estoy desarrollando hardware a medida (FPGA) y por lo tanto tengo cantidades muy limitadas de memoria disponible y estructuras de datos muy diferentes. (La típica estructura de datos basada en punteros suele ser bastante ineficiente en una FPGA).

La aplicación es una estrategia de creación de mercado de acciones HF en la que requiero el tope de libro actual de una fuente de datos ITCH para decidir los precios internos.

6voto

Alexander Gladysh Puntos 682

Si está escribiendo un libro "altamente optimizado", debe adaptarlo a los lugares de los que recibirá los datos. El precio máximo, por ejemplo, se publica en la especificación Itch de NASDAQ: 200,000.0000.

Si usted planea en el comercio de acciones de EE.UU. es mejor ir a leer cada uno de los lugares de profundidad de las especificaciones del libro con mucho cuidado. Encontrarás todo tipo de formas de optimizar la implementación de tu libro. Lo mismo ocurre con otros mercados e instrumentos.

4voto

John Puntos 5478

La respuesta correcta dependerá de los instrumentos y mercados en los que se opere, y de si se trata de gestionar órdenes públicas o privadas. Por ejemplo, si tuviera que diseñar para el caso simple, acciones estadounidenses y un mercado público, querría que el tamaño de la cola fuera de cada nivel de precios para poder manejar al menos el volumen máximo diario de, por ejemplo, QQQ. Sé que eso no es de ninguna manera "altamente optimizado", pero el peor momento para que tu brillante y rápido libro tenga un colapso es cuando algo inesperado ha sucedido en alguna parte. Lo mismo ocurre con los rangos de precios: tienes que ser capaz de soportar precios que sean al menos varios órdenes de magnitud más altos que el precio más alto jamás impreso en ese mercado. Tomando de nuevo la renta variable como ejemplo, algunos de los ETFs inversos altamente apalancados tienen el potencial de hacer cosas que nunca hemos visto antes.

Si se trata de pares de divisas, por ejemplo, hay demasiadas maneras de que una serie de acontecimientos políticos puedan hacer estallar el código si se intentan hacer estructuras de datos demasiado ajustadas. Utiliza Hungría o Zimbabue como modelo cuando pienses en esto; es posible que elevar al cuadrado el valor total actual de la oferta monetaria de un país determinado no sea un número lo suficientemente grande para el numerador o denominador futuro de un par de divisas.

Quizás la verdadera respuesta correcta es la que probablemente no quieres: Optimiza tus estructuras de datos para la velocidad utilizando los algoritmos adecuados, pero no intentes optimizarlas para el tamaño si quieres que tu código sobreviva a tiempos interesantes. Puede que incluso quieras utilizar el tamaño máximo que tu plataforma permita cómodamente; si estás negociando algo que podría estar sujeto a la hiperinflación, incluso 64 bits podrían no ser suficientes para un campo de precios.

También depende del modelo de negocio al que se pretenda dar soporte; en algún momento la empresa necesita saber dónde están esos límites y cuándo puede necesitar salir de ciertos mercados antes de que sus propios sistemas fallen de forma catastrófica.

Otra forma de enfocar esto sería mirar el tamaño de los datos de las aplicaciones que hablan con el libro de órdenes. Si planea admitir tamaños de datos más pequeños que los de las aplicaciones de los clientes, entonces querrá protegerse de lo que sucederá cuando llegue un valor más grande de lo esperado. El peor caso podría no ser un volcado del núcleo - podría ser una orden grande llenada a un precio que se desborda y se envuelve. ;-)

2voto

Matthew Ruston Puntos 176

En cuanto al tamaño: Supongo que lo más probable es que quiera estructurar el software para implementar cada "libro" como una unidad de órdenes que representan ese valor en particular, y posiblemente (como se mencionó anteriormente) dividir aún más estas estructuras en estructuras de precios individuales tales-estructuras.

Se querría poder escalar cada "unidad" individual a un tamaño bastante arbitrario, por razones de seguridad, y suponer que el sistema en el que se ejecutaran tendría recursos de provisión extremadamente grandes.

También es posible que quieras considerar la capacidad de "amortiguar" grandes elementos de los datos del programa enviándolos a y desde el almacenamiento a largo plazo, tanto por eficiencia, como por seguridad en caso de un fallo catastrófico a nivel de memoria. La estructura de unidades a la que aludo también se presta a un intercambio más rápido de elementos dentro y fuera de la memoria, en lugar de tener que escribir grandes conjuntos contiguos de elementos (órdenes, etc.), lo que obviamente supone un gran consumo de recursos.

He estado trabajando (un poco en mi tiempo libre) para generar código fuente para LOB's en varios idiomas. También he añadido algunas implementaciones en C++ realizadas por otros autores (las entradas de quantcup de 2011)

Otras cuestiones que he considerado para la estructura básica son:

  • Concurrencia (insertar o eliminar órdenes en el orden correcto)
  • Threading (aquí es donde los lenguajes funcionales son valiosos)

https://github.com/jordanbaucke/Limit-Order-Book

Finanhelp.com

FinanHelp es una comunidad para personas con conocimientos de economía y finanzas, o quiere aprender. Puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X