Parece que todos los principales bancos de inversión utilizan C++ en Unix (Linux, Solaris) para sus aplicaciones de servidor de baja latencia/alta frecuencia. ¿Por qué Windows generalmente no se utiliza como plataforma para esto? ¿Hay razones técnicas por las que Windows no puede competir?Sistemas de negociación de baja latencia usando C++ en Windows?
Técnicamente, no. Sin embargo, hay una razón comercial muy simple: el resto del mundo financiero se ejecuta en Unix. Los bancos funcionan con AIX, el mercado de valores se ejecuta en Unix y, por lo tanto, es más fácil encontrar programadores en el mundo financiero que estén acostumbrados a un entorno Unix, en lugar de uno de Windows.
+1 para no transferir a Unix FUD. –
No se trata de encontrar chicos con conocimiento de Windows. Te aseguro que el conocimiento relacionado con el sistema operativo es el 1% del conocimiento requerido para hacer ese tipo de desarrollo, y todos los que trabajan en esta área pueden cambiar a CUALQUIER sistema operativo si es necesario. – BarsMonster
@BarsMonster: Pude ver, sin embargo, cosas como las pilas de redes, que dependen completamente de la plataforma, requerirían un poco de conocimiento antes de poder cambiar de plataforma. Además de cosas como 'fork', que son comunes en el mundo POSIX pero no son posibles en un entorno Windows. Creo que es una respuesta razonable. –
Linux/UNIX son mucho más útiles para los usuarios remotos simultáneos, lo que facilita la secuencia de comandos alrededor de los sistemas, usa herramientas estándar como grep/sed/awk/perl/ruby / less en registros ... ssh/scp. todo eso está ahí.
También hay problemas técnicos, por ejemplo: para medir el tiempo transcurrido en Windows, puede elegir entre un conjunto de funciones basadas en la marca del reloj de Windows y QueryPerformanceCounter() basado en hardware. El primero se incrementa cada 10 a 16 milisegundos (nota: cierta documentación implica más precisión; por ejemplo, los valores de GetSystemTimeAsFileTime() miden a 100ns, pero informan el mismo borde de 100 segundos del reloj hasta que marca nuevamente). El último - QueryPerformanceCounter() - tiene problemas de show-stopping donde diferentes cores/cpus pueden informar relojes desde el inicio que difieren por varios segundos debido a que se han calentado en diferentes momentos durante el arranque del sistema. MSDN documenta esto como una posible falla de BIOS, pero es común. Entonces, ¿quién quiere desarrollar sistemas de negociación de baja latencia en una plataforma que no se puede instrumentar adecuadamente? (Hay soluciones, pero no encontrará ninguna de software que funcione cómodamente en boost o ACE).
Muchas variantes de Linux/UNIX tienen muchos parámetros fáciles de modificar para compensar la latencia de un solo evento frente a la latencia promedio bajo carga, tamaños de segmento de tiempo, políticas de programación, etc. En sistemas operativos de código abierto, también existe la seguridad con poder referirse al código cuando piensas que algo debe ser más rápido de lo que es, y el conocimiento de que una comunidad (potencialmente enorme) de personas ha estado y lo está haciendo de manera tan crítica: con Windows, obviamente, va a ser sobre todo la gente que Está asignado a mirarlo.
En el lado FUD/reputación - algo intangible pero una parte importante de las razones para la selección de SO - creo que la mayoría de los programadores de la industria confiarían más en Linux/UNIX para proporcionar programación y comportamiento confiables. Además, Linux/UNIX tiene una reputación de estrellarse menos, aunque Windows es bastante confiable en estos días, y Linux tiene una base de código mucho más volátil que Solaris o FreeBSD.
Los sistemas operativos Windows * client * solo permiten que una persona use RDP a la vez. Sin embargo, Windows Terminal Server ha existido desde siempre (fue, de hecho, el uso original de RDP) y permite tantas conexiones como Licencias de acceso de cliente. Los SO de Windows Server vienen con la capacidad de tener más de un usuario remoto de forma predeterminada. Si pudieras obtener el comentario sobre la programación, entonces haría +1 aquí, esa parte de la respuesta parece ser FUD en este momento para mí (el resto de la respuesta es buena). YMMV. –
No hay programación de UNIX/Linux. Es una de las áreas en las que difieren las implementaciones. Y Linux, de hecho, ha tenido más de una opción de planificador (google Completely Fair Scheduler Linux para fondo), por lo que ni siquiera puede decir "La programación de Linux es confiable". – MSalters
@Billy: gracias por la corrección de RDP - respuesta actualizada apropiadamente. He dejado más claro qué es FUD/opinión, que todavía creo que es relevante para la pregunta. @MSalters: Eso es como decir que no hay deporte porque hay fútbol y tenis. La programación de UNIX/Linux aún se puede abordar de forma colectiva. Y puede razonablemente generalizar, del mismo modo que uno puede decir que practicar deporte es saludable ... –
La razón es simple, hace 10-20 años cuando surgieron tales sistemas, los servidores "hardcore" multi-CPU SÓLO estaban en algún tipo de UNIX. Windows NT estaba en kindergarten en estos días. Entonces la razón es "histórica".
Los sistemas modernos pueden desarrollarse en Windows, es solo cuestión de gustos estos días.
PS: Estoy currencly trabajando en uno de tales sistemas :-)
+1 por * otra * respuesta que no devuelve a Unix FUD. –
Hay una variedad de razones, pero la razón no es solamente histórica. De hecho, parece como si más y más aplicaciones financieras del lado del servidor se ejecutan en * nix en estos días que nunca (incluidos grandes nombres como la Bolsa de Londres, que cambió de una plataforma .NET). Para las aplicaciones de escritorio o del lado del cliente, sería absurdo apuntar a cualquier cosa que no sea Windows, ya que esa es la plataforma establecida. Sin embargo, para las aplicaciones del lado del servidor, la mayoría de los lugares en los que he trabajado se implementan en * nix.
Windows ciertamente no era la plataforma de escritorio establecida en 1990, cuando tales sistemas comerciales se desarrollaron por primera vez. Y si necesitabas un rendimiento serio en tu escritorio, Windows de 16 bits no era una opción. – MSalters
Los requisitos de rendimiento en los sistemas de latencia extremadamente baja utilizados para el comercio algorítmico son extreme.En este entorno, microsegundos cuentan.
No estoy seguro acerca de Solaris, pero el caso de Linux, estos chicos están escribiendo y usando parches de baja latencia y personalizaciones para todo el kernel, desde los controladores de la tarjeta de red en adelante. No es que haya una técnica por lo que no se pudo hacer en Windows, pero hay una práctica/legal: acceso al código fuente y la posibilidad de volver a compilarlo con los cambios.
Esto parece una buena respuesta, pero ¿sabe usted con certeza que ellos escriben parches de baja latencia y recompilan el kernel? – Jon
@Jon: Solo tengo evidencia anecdótica, de varias discusiones sobre LKML y lugares similares a lo largo de los años (por ejemplo, Christoph Lameter es un desarrollador de kernel que estuvo trabajando en baja latencia para tales aplicaciones por un tiempo). – caf
@Jon He escrito parches de kernel en áreas como pdflush. Las suposiciones estándar de acceso al kernel no se alinean necesariamente con los patrones de acceso deseados. –
(he trabajado en banca de inversión durante 8 años) De hecho, una gran parte de lo que los bancos llaman baja latencia se hace en Java. Y ni siquiera Java en tiempo real, solo Java normal con el GC desactivado. El truco principal aquí es asegurarse de haber ejercitado todo su código lo suficiente para que el jit se haya ejecutado antes de cambiar una máquina virtual particular a prod (para que tenga un bucle de inicio que se ejecuta durante un par de minutos y failover caliente) .
Las razones para utilizar Linux son:
familiaridad
administración remota es aún mejor, y también bajo impacto - que tendrá un efecto mínimo en los otros procesos en la máquina. Recuerde que estos sistemas suelen ubicarse en el intercambio, por lo que los enlaces a las máquinas (de usted/su equipo de soporte) probablemente sean peores que los de sus centros de datos normales.
Capacidad de ajuste: la capacidad de establecer swappiness en 0, obtener la JVM para preasignar páginas grandes y otros trucos de bajo nivel es bastante útil.
Estoy seguro de que Windows podría funcionar de forma aceptable, pero no hay una gran ventaja para hacerlo, como han dicho otros, los empleados que saqueaste tendrían que redescubrir todos sus trucos de latencia en lugar de simplemente ejecutar un lista de verificación
Realicé prácticas en una firma de fabricación de HFT/mercado, y nuestro código estaba en Java, el proceso de pensamiento era el momento y los errores ahorrados superaban cualquier beneficio potencial del uso de C/C++. – cohensh
Estoy parcialmente de acuerdo con la mayoría de las respuestas anteriores. Aunque lo que me he dado cuenta es la principal razón para usar C++ es porque es relativamente más rápido con una biblioteca de STL muy amplia.
Además, el sistema linux/unix también se usa para aumentar el rendimiento. Conozco muchos equipos de baja latencia que van a ajustar el kernel de Linux. Obviamente, este nivel de libertad no es proporcionado por Windows.
Otras razones como los sistemas heredados, el costo de la licencia, los recursos cuentan también pero son factores de menor impulso. Como mencioné "rjw", he visto equipos usar Java también con una JVM modificada.
En segundo lugar las opiniones de histórico y el acceso a la manipulación del kernel.
Además de esas razones, también creo que al igual que la forma en que desactivan la recolección de basura de .NET y el mecanismo similar en Java al usar estas tecnologías en una baja latencia. Podrían evitar Windows debido a las API de alto nivel que interactúan con el sistema operativo de bajo nivel y luego con el kernel.
Así que el núcleo es, por supuesto, el núcleo con el que se puede interactuar utilizando el sistema operativo de bajo nivel. Las API de alto nivel se proporcionan solo para facilitar la vida de los usuarios comunes. Pero en el caso de baja latencia, esto resulta ser una capa grasa y una fracción de segundos de pérdida en cada operación. Entonces, es una opción lucrativa para ganar unos segundos de fracción por llamada.
Aparte de esto, otra cosa a considerar es la integración. La mayoría de los servidores, centros de datos, intercambios utilizan UNIX no Windows, por lo que usar los clientes de la misma familia facilita la integración y la comunicación.
Luego tienes problemas de seguridad (muchas personas pueden no estar de acuerdo con este punto) piratear UNIX no es fácil comparado con hackear WINDOWS. No estoy de acuerdo en que el licenciamiento sea el problema para los bancos, ya que invierten dinero en cada pieza de hardware y software y en las personas que los personalizan, por lo que comprar licencias no será tan importante cuando se considere lo que obtienen comprando.
¿Alguien trajo malvaviscos? ¡Quiero aprovechar estas llamas! –