¿Qué tan bueno es el código administrado para el comercio de algo?

Question

Actualmente trabajo en una empresa que se dedica al comercio de algo. Lo hacemos todo en Java. Y ganamos dinero con ello. Tenemos debates todo el tiempo sobre si habríamos hecho más dinero con nativo o VHDL en las tarjetas de red.

No hacemos operaciones de súper alta frecuencia, aunque sí más complicadas. Aunque tenemos que ser los primeros. Después de trabajar allí durante bastante tiempo me interesa más saber si Java es popular en esta área. (Y como nadie habla en ese campo me gustaría plantear este tema aquí).

Por mi experiencia he notado que tiene mucho que ver con la fiabilidad de la bolsa o del broker. Si no es muy fiable (como en muchas bolsas del mundo) un retraso de 2 milisegundos sería mucho más significativo que el idioma que elijas. Pero aún así, ¿cuántos eligen código gestionado?

Answer 1

Hay toneladas de idiomas utilizados en este campo . En cuanto a las plataformas de negociación basadas en Java, Marketcetera es popular entre los clientes.

Para justificar el cambio de idioma, tendría que demostrar que existe un cuello de botella que impide a su equipo recaudar más P&L. ¿Has ejecutado un perfilador y comparado los resultados con tcpdump? Debes demostrar que tu plataforma actual es la causa del retraso que hace perder oportunidades antes de sumergirte en C++.

(Y si hablamos de milisegundos, asumo que estás co-localizado en las bolsas en cuestión, si es que lo permiten. Si no estás co-localizado, entonces lidiar con eso probablemente tendría más impacto que cambiar de idioma).

Answer 2

Oracle organizó un taller para desarrolladores de aplicaciones comerciales en Nueva York el 15 de marzo de 2011. Las diapositivas de cada una de las presentaciones son aquí . Uno de ellos trata de java para aplicaciones de comercio, y me pareció que el mayor problema planteado por la audiencia era la recolección de basura. La presentación habla de algunos parámetros de configuración que pueden limitar los retrasos en la recolección de basura, pero sólo hasta el milisegundo, mientras que la mayoría de la audiencia estaba buscando microsegundos.

Answer 3

En un escenario típico de HFT (procesar comillas UDP entrantes y enviar respuestas de entrada de órdenes TCP), un Java bien escrito puede competir con C++ en cuanto a velocidad pura. Si necesita más velocidad, busque mejorar lo siguiente:

1. Su código (configure un buen punto de referencia y luego perfílelo y ajústelo)
2. Su entorno de red (conmutadores de baja latencia, NIC de DMA)
3. Su arquitectura (¿está haciendo saltos multiproceso o multiordenador?)

Hemos escrito un par de pequeños benchmarks de red en C++ y Java, y si se utilizan las mismas técnicas en ambos, se obtiene el mismo rendimiento.

Answer 4

Tengo estos posts favoritos de stackoverflow. Puede que te ayuden.

Comercio de alta frecuencia

¿En qué lenguaje(s) de programación está escrito el software de comercio algorítmico?

¿Por qué una posición de negociación de derivados requiere siempre conocimientos de C++?

Jane Street Capital, una empresa de creación de mercados de alta frecuencia, utiliza OCaml. Aquí hay vídeos del programador jefe donde explica por qué. Me pareció bastante interesante.

Answer 5

He trabajado con C++, java y C# implementando un motor de búsqueda similar al de Google para el Departamento de Defensa junto con muchos otros programas que requieren un alto rendimiento (utilizando mapeo de memoria de bajo nivel y named pipes/tcp).

Según mi experiencia, no se puede igualar la velocidad de C++ con el código gestionado. En el código gestionado, cada llamada a new, garbage collection, etc. requiere múltiples búsquedas de memoria para asignar y desasignar memoria. Con cada recolección de basura hay múltiples hilos creados para cada generación de las ubicaciones de memoria (así que si tienes desarrolladores no tan conocedores...). además, cuando estás realizando muchos cambios de hilos o cargando datos en memoria (por ejemplo en flujos de memoria o transferencias a través de tcp/tuberías con nombre) perderás velocidad debido a la necesidad de serialización de los códigos gestionados (puede ser wcf, remoting, servicios web, etc.) no importa que las transferencias de datos en .net sean serializadas a menos que escribas tus propias envolturas tcp/tuberías con nombre. es peor si necesitas usar COM ya que tu código gestionado necesitará envolver todo en envolturas llamables com.

Por último y más importante, no olvides que la mayoría de las librerías .net son envoltorios de la antigua api de win32. .net framework pump sigue traduciendo sus llamadas a la antigua bomba de mensajes de win32 para realizar muchas de sus operaciones (por ejemplo, DllImport("User32",...)). También la librería de sockets de .Net (wcf, remoting, etc.) utiliza la api subyacente tcp/ip y named pipe (por ejemplo, ver la capacidad de WCF de permitirte configurar eitehr named pipes y conexión tcp. Los Namedpipes son como los manejadores de archivos y requieren un acceso de muy bajo nivel, por lo que se les da una simple envoltura).

así que para la velocidad C++; para la facilidad de desarrollo C#/Java. C# puede ser optimizado usando varias tácticas pero requiere de buenos desarrolladores que sepan cómo "manejar" los objetos y la GC (por ejemplo, implementar interfaces para hacer tu propia GC, llamar directamente a la api de win32 cuando sea necesario, suprimir la GC, no usar clases que serialicen y deserialicen al menos tratar de evitarlo, construir tus propias clases de búfer y comprobaciones de crc para facilitar, usar sockets de bajo nivel y no usar wrappers de wcf (a menos que su objetivo sea crear un webservice).