Rendimiento de C++ vs Lenguajes de Máquina Virtual en finanzas de alta frecuencia

Mucho de esto se reduce a una simple diferencia entre hecho y teoría. La gente ha avanzado teorías para explicar por qué Java debería ser (o al menos podría ser) más rápido que C++. La mayoría de los argumentos tienen poco que ver con Java o C++ per se, pero con la compilación dinámica versus estática, con Java y C++ siendo realmente poco más que ejemplos de los dos (aunque, por supuesto, es posible compilar Java estáticamente, o C++ dinámicamente). La mayoría de estas personas tienen puntos de referencia para "probar" su reclamo. Cuando esos puntos de referencia son examinados en cualquier detalle, rápidamente se hace obvio que en bastantes casos, tomaron medidas bastante extremas para obtener los resultados que querían (por ejemplo, un buen número habilitar optimización al compilar el Java, pero específicamente desactivado optimización al compilar el C++).

Compare esto con el Juego Computer Language Benchmarks, donde prácticamente cualquiera puede enviar una entrada, por lo que todo el código tiende a optimizarse en un grado razonable (y, en algunos casos, incluso en un grado irrazonable). Parece bastante claro que un buen número de personas tratan esto como esencialmente una competencia, con los defensores de cada idioma haciendo todo lo posible para "probar" que su idioma preferido es el mejor. Dado que cualquiera puede presentar una implementación de cualquier problema, una presentación particularmente pobre tiene poco efecto en los resultados generales. En esta situación, C y C++ emergen como claros líderes.

Peor, si cualquier cosa que estos resultados probablemente muestran Java en mejor luz que es totalmente precisa. En particular, alguien que usa C o C++ y realmente se preocupa por el rendimiento puede (y a menudo lo hará) usar el compilador de Intel en lugar de g++. Esto típicamente dará al menos un 20% de mejora en la velocidad en comparación con g++.

Editar (en respuesta a un par de puntos planteados por jalf, pero en realidad demasiado largo para caber razonablemente en los comentarios):

1. Punteros ser un optimizador escritores pesadilla. Esto es realmente exagerar las cosas (bastante) un poco. Los punteros conducen a la posibilidad de aliasing, lo que evita ciertas optimizaciones bajo ciertas circunstancias. Dicho esto, la inserción evita los efectos nocivos la mayor parte del tiempo (es decir, el compilador puede detectar si hay aliasing en lugar de siempre generar código bajo la suposición de que podría haber). Incluso cuando el código tiene que asumir aliasing, el almacenamiento en caché minimiza el impacto en el rendimiento al hacerlo (es decir, los datos en la caché L1 son solo minuciosamente más lento que los datos en un registro). Prevenir el aliasing ayudaría al rendimiento en C++, pero no tanto como se podría pensar.

2. La asignación es mucho más rápida con un recolector de basura. Ciertamente es cierto que el asignador predeterminado en muchas implementaciones de C++ es más lento que lo que la mayoría de los (actuales) asignadores de basura recolectados proporcionan. Esto está equilibrado (al menos en un grado) por el hecho de que las asignaciones en C++ tienden a estar en la pila, que es también rápido, mientras que en un lenguaje GC casi todas las asignaciones están generalmente en el montón. Peor aún, en un lenguaje administrado normalmente se asigna espacio para cada objeto individualmente, mientras que en C++ normalmente se asigna espacio para todos los objetos de un ámbito juntos.

También es cierto que C++ admite directamente el reemplazo de asignadores tanto globalmente como clase por clase, por lo que la velocidad de asignación cuando/si realmente es un problema, generalmente es bastante fácil de solucionar.

En última instancia, jalf tiene razón: ambos puntos indudablemente favorecen las implementaciones "gestionadas". Sin embargo, el grado de esa mejora debe mantenerse en perspectiva: no son suficientes para permitir que las implementaciones compiladas dinámicamente se ejecuten más rápido en mucho código not ni siquiera los puntos de referencia diseñados desde el principio para favorecerlos tanto como sea posible.

Edit2: Veo que Jon Harrop ha intentado insertar el valor de sus dos (mil millonésimas de un) centavo. Para aquellos que no lo conocen, Jon ha sido un notorio troll y spammer para años, y parece estar buscando nuevos caminos en el que se siembran las malas hierbas. Trataría de responder a su comentario en detalle, pero (como es típico para él) consiste únicamente en generalizaciones no calificadas y sin apoyo que contienen tan poco contenido real que una respuesta significativa es imposible. Todo lo que se puede hacer es dar a los espectadores una advertencia justa de que se ha hecho bien conocido por ser deshonesto, egoísta, y mejor ignorado.

Un compilador JIT teóricamente podría realizar muchas optimizaciones, sí, pero ¿cuánto tiempo está dispuesto a esperar? Una aplicación de C++ puede tardar horas en compilarse porque sucede sin conexión, y el usuario no está sentado allí tocando los dedos y esperando.

Un compilador JIT tiene que terminar en un par de milisegundos. Entonces, ¿cuál crees que puede salirse con la suya con las optimizaciones más complejas?

El recolector de basura es un factor también. No porque sea más lento que la gestión manual de memoria per se (creo que su costo amortizado es bastante bueno, definitivamente comparable al manejo manual de memoria), pero es menos predecible. puede introducir un stall en casi cualquier punto, lo que podría no ser aceptable en sistemas que deben ser extremadamente receptivos.

Y por supuesto, los lenguajes se prestan a diferentes optimizaciones. C++ le permite escribir código muy ajustado, prácticamente sin sobrecarga de memoria, y donde muchas operaciones de alto nivel son básicamente gratuitas (digamos, construcción de clase).

En C# por otro lado, se desperdicia una buena parte de la memoria. Y simplemente instanciar una clase conlleva una buena parte de sobrecarga, ya que la base Object debe inicializarse, incluso si su clase real está vacía.

C++ permite al compilador eliminar el código no utilizado de forma agresiva. En C#, la mayor parte tiene que estar allí para que se pueda encontrar con reflexión.

Por otro lado, C# no tiene punteros, que son la pesadilla de un compilador de optimización. Y la memoria las asignaciones en un lenguaje administrado son mucho más baratas que en C++.

Hay ventajas de cualquier manera, por lo que es ingenuo esperar que pueda obtener una respuesta simple "una u otra". Dependiendo del código fuente exacto, el compilador, el sistema operativo, el hardware en el que se está ejecutando, uno u otro puede ser más rápido. Y dependiendo de sus necesidades, el rendimiento bruto podría no ser el objetivo #1. Tal vez estés más interesado en la capacidad de respuesta, en evitar paradas impredecibles.

En general, su típico El código C++ se ejecutará de manera similar al código C# equivalente. A veces más rápido, a veces más lento, pero probablemente no es una diferencia dramática de cualquier manera.

Pero de nuevo, depende de las circunstancias exactas. Y depende de cuánto tiempo estés dispuesto a gastar en optimización. si está dispuesto a pasar tanto tiempo como sea necesario, el código C++ generalmente puede lograr un mejor rendimiento que C#. Solo toma mucho trabajo.

Y la otra razón, por supuesto, es que la mayoría de las empresas que use C++ ya tiene una gran base de código C++ que no quieren deshacerse particularmente. Lo necesitan para seguir funcionando, incluso si migran gradualmente (algunos) nuevos componentes a un lenguaje administrado.

Estas empresas generalmente no tienen límite en cuanto a lo caro que es el hardware.

Si tampoco les importa lo caro que es el software, entonces yo pensaría que, por supuesto, C++ puede ser más rápido: por ejemplo, el programador podría usar memoria asignada a medida o preasignada; y/o pueden ejecutar código en el núcleo (evitando transiciones de anillo), o en un O/S en tiempo real, y/o tenerlo estrechamente acoplado a la pila de protocolos de red.

Hay otras razones para usar C++ además del rendimiento. Existe una ENORME biblioteca de código C y C++. Reescribir todo eso en idiomas alternativos no sería práctico. Para que cosas como P / Invoke funcionen correctamente, el código de destino tiene que ser diseñado para ser llamado desde otro lugar. Si nada más tendría que escribir algún tipo de envoltura alrededor de las cosas exponiendo una API de C completamente porque no puede invocar P/a las clases de C++.

Finalmente, P / Invoke es muy caro operación.

Los compiladores JIT son cada vez mejores. Pueden hacer optimizaciones a medida que el programa se ejecuta

Sí, pueden hacer esto. Pero se olvida que cualquier compilador de C++ es capaz de hacer las mismas optimizaciones. Claro, el tiempo de compilación será peor, pero el hecho de que tales optimizaciones tengan que hacerse en tiempo de ejecución es una sobrecarga. Hay casos en los que los lenguajes administrados pueden vencer a C++ en ciertas tareas, pero esto generalmente se debe a sus modelos de memoria y no al resultado de optimizaciones de tiempo de ejecución. Estrictamente hablando, por supuesto, podría tener un modelo de memoria en C++, EDITAR: como el manejo de cadenas de C#, / EDITAR, pero pocos programadores de C++ pasan tanto tiempo optimizando su código como los chicos de JIT.

Hay algunos problemas de rendimiento que son una desventaja heredada de los lenguajes administrados, a saber, E/S de disco.Es un costo único, pero dependiendo de la aplicación puede ser significativo. Incluso con los mejores optimizadores, todavía necesita cargar más de 30 MB de compilador JIT desde disco cuando se inicia el programa; mientras que es raro que un binario C++ se acerque a ese tamaño.

El simple hecho es que C++ está diseñado para la velocidad. C # / Java no lo son.

Tomemos las innumerables jerarquías hereditarias endémicas de esos lenguajes (como Iumerable), en comparación con la sobrecarga cero de std::sort o std::for_each siendo genéricas. La velocidad de ejecución raw de C++no es necesariamente más rápida,pero el programador puede diseñar sistemas rápidos o sin sobrecarga. Incluso cosas como desbordamientos de búfer - no se puede desactivar su detección. En C++, usted tiene el control. Fundamentalmente, C++ es un rápido lenguaje-no pagas por lo que no usas. Por el contrario, en C#, si usa, por ejemplo, stackalloc, no puede dejar de hacer la comprobación de desbordamiento de búfer. No puedes asignar clases en la pila, o contiguamente.

También está todo el tema del tiempo de compilación, donde las aplicaciones C++ pueden tomar mucho más tiempo, tanto para compilar como para desarrollar.

Esto podría estar un poco fuera de tema, pero vi un video hace un par de semanas que podría parecer de interés para usted: http://ocaml.janestreet.com/?q=node/61

Proviene de una empresa comercial que decidió usar ocaml como su idioma principal para el comercio, y creo que sus motivaciones deberían ser esclarecedoras para usted (básicamente, valoraron la velocidad, por supuesto, pero también la escritura fuerte y el estilo funcional para incrementos más rápidos y una comprensión más fácil).

La mayor parte de nuestro código termina teniendo que ejecutarse en una Cuadrícula de 1000 máquinas.

Creo que este entorno cambia el argumento. Si la diferencia entre la velocidad de ejecución de c++ y c# es del 25%, por ejemplo, entonces entran en juego otros factores. Cuando esto se ejecuta en una cuadrícula, puede no hacer ninguna diferencia en cuanto a cómo se codifica, ya que todo el proceso, una vez distribuido entre las máquinas, puede no ser un problema o resolverse asignando o comprando algunas máquinas más. El problema más importante y costo mayo conviértase en 'time to market' donde c# puede probar la opción ganadora y más rápida.

¿Cuál es c++ o c#más rápido?

C# por seis meses......

No es solo una cuestión de lenguaje de programación, el hardware y el sistema operativo serán relevantes.
El mejor rendimiento general que obtendrá con un sistema operativo en tiempo real, un lenguaje de programación en tiempo real y eficiente (!) programming.

Así que usted tiene bastantes posibilidades en la elección de un sistema operativo, y unos pocos en la elección del idioma. Hay C, Java en tiempo Real, Fortran en tiempo Real y algunos otros.

O tal vez usted tendrá los mejores resultados en la programación un FPGA / Procesador para eliminar el costo de un sistema operativo.

La opción más grande que tiene que hacer, cuántas optimizaciones de rendimiento posibles ignorará a favor de elegir un lenguaje que facilite el desarrollo y se ejecute más estable, porque puede hacer menos errores, lo que resultará en una mayor disponibilidad del sistema. Esto no debe pasarse por alto. Usted no tiene ninguna victoria en el desarrollo de una aplicación que se realiza 5% más rápido que cualquier otra aplicación que se bloquea cada pocos puntos debido a algunos pequeños errores difíciles de encontrar.

En HFT, la latencia es un problema mayor que el rendimiento. Dado el paralelismo inherente en la fuente de datos, siempre puede lanzar más núcleos al problema, pero no puede compensar el tiempo de respuesta con más hardware. Ya sea que el lenguaje se compile de antemano o Justo a tiempo, la recolección de basura puede destruir su latencia. Existen JVM en tiempo real con latencia de recolección de basura garantizada. Es una tecnología bastante nueva, un dolor para afinar, y ridículamente caro, pero si usted tiene la recursos, se puede hacer. Probablemente se convertirá en mucho más corriente en los próximos años, a medida que los primeros adoptantes financien la I + D que está sucediendo ahora.

Una de las cosas más interesantes en C++ es que sus números de rendimiento no son mejores, sino más fiables.

No es necesariamente más rápido que Java/C#/..., pero es consistente accross runs.

Al igual que en las redes, a veces el rendimiento no es tan importante como una latencia estable.

Una gran razón para preferir c++ (o nivel inferior) en este caso aparte de lo que ya se ha dicho, es que hay algunos beneficios de adaptabilidad de ser de bajo nivel.

Si la tecnología de hardware cambia, siempre puede caer en un bloque __asm { } y realmente usarlo antes de que los lenguajes/compiladores se pongan al día

Por ejemplo, todavía no hay soporte para SIMD en Java.

Los motores de ejecución virtual (JVM o CLR de.Net) no permiten estructurar el trabajo de manera eficiente, ya que las instancias de proceso no pueden ejecutarse en tantos subprocesos como sean necesarios.

Por el contrario, C++ simple permite la ejecución de algoritmos paralelos y la construcción de objetos fuera de las rutas de ejecución críticas en el tiempo. Eso es casi todo, simple y elegante. Además, con C++ solo paga por lo que usa.

El elefante en la habitación aquí es el hecho de que C++ es más rápido que Java .

Todos lo sabemos. Pero también sabemos que si lo declaramos claramente, como acabo de hacer, no podemos pretender participar en un debate significativo sobre este tema indiscutible. ¿Cuán mucho más rápido es C++ que Java para su aplicación? Eso tiene el anillo de un tema discutible, pero, por desgracia, siempre será hipotético a menos que implemente su aplicación en ambos idiomas, momento en el que se no habrá lugar para el debate.

Volvamos a su primera reunión de diseño: el requisito difícil para su proyecto es un alto rendimiento. Todos en la sala pensarán en "C++" y un puñado de otros lenguajes compilados. El tipo en la sala que sugiere Java o C# tendrá que justificarlo con evidencia (es decir, un prototipo), no con hipótesis, no con afirmaciones hechas por los proveedores, no con declaraciones en sitios de chismes de programadores, y ciertamente no con puntos de referencia de "hola mundo".

Tal como está ahora, tienes que seguir adelante con lo que sabes, no con lo que es hipotéticamente posible.

Nikie escribió: "¿Podrías explicar lo que puedes hacer con los hilos de C++ y no con los hilos de. NET, por ejemplo?"

El threading con. Net podría realizar prácticamente todo lo que el threading de C++ puede, excepto:

1. Ejecución eficiente de código binario encapsulado COM. Por ejemplo, algoritmos sensibles que podrían tener que mantenerse en secreto de los desarrolladores de aplicaciones. (Podría ser relevante en HFT)
2. Creación de hilos magros que no agoten los recursos del sistema con bloques de construcción gruesos – api de SO empaquetadas y primitivas de sincronización y señalización de SO. (Extremadamente relevante con algoritmos paralelos para la optimización del tiempo de rendimiento en HFT)
3. Escalar el rendimiento de una aplicación de proceso de negocio 10 o más veces en el mismo hardware y con la misma latencia. (No pertinente en HFT)
4. Escalar 100 veces o más el número de interacciones de usuario manejadas simultáneamente por unidad de hardware. (No pertinente en HFT)

Usar más núcleos de CPU no puede completarse compense el agotamiento de los recursos del sistema por los bloques de construcción de.Net, ya que más núcleos de CPU son una garantía para la apariencia de contención de memoria.