.net - usados - uso de c++ en la actualidad

Rendimiento de los lenguajes de máquinas virtuales vs C++ en finanzas de alta frecuencia (15)

Pensé que la pregunta de rendimiento de C / C ++ frente a C # / Java estaba bien trillada, lo que significa que había leído suficiente evidencia para sugerir que los lenguajes de VM no son necesariamente más lentos que los lenguajes "cercanos al silicio". Principalmente porque el compilador JIT puede hacer optimizaciones que los lenguajes compilados estáticamente no pueden.

Sin embargo, recientemente recibí un CV de un tipo que afirma que el comercio de alta frecuencia basado en Java siempre es superado por C ++, y que había estado en una situación en la que este era el caso.

Una búsqueda rápida en los sitios de trabajo muestra que los solicitantes de HFT necesitan conocimiento de C ++, y un vistazo al foro de Wilmott muestra a todos los profesionales que hablan sobre C ++.

¿Hay alguna razón particular por la que este es el caso? Habría pensado que con el negocio financiero moderno es algo complejo, se preferiría un lenguaje de máquina virtual con seguridad de tipo, memoria administrada y una biblioteca rica. La productividad es más alta de esa manera. Además, los compiladores JIT están mejorando y mejorando. Pueden realizar optimizaciones a medida que se ejecuta el programa, por lo que podría pensar que usan esa información en tiempo de ejecución para mejorar el rendimiento del programa no administrado.

¿Quizás estos tipos escriben los bits críticos en C ++ y los llaman desde un entorno administrado (P / Invoke, etc.)? ¿Es eso posible?

Finalmente, ¿alguien tiene experiencia con la pregunta central en esto, por lo que, en este dominio, el código no administrado es, sin duda, preferido sobre el manejo?

Por lo que puedo decir, los chicos de HFT necesitan reaccionar lo más rápido posible a los datos del mercado entrante, pero esto no es necesariamente un requisito en tiempo real . Está peor si es lento, eso es seguro, pero no necesita garantizar una cierta velocidad en cada respuesta, solo necesita un promedio rápido.

EDITAR

Correcto, un par de buenas respuestas hasta ahora, pero bastante generales (terreno transitado). Permítanme especificar qué tipo de programa HFT chicos estarían ejecutando.

El criterio principal es la capacidad de respuesta. Cuando una orden llega al mercado, quieres ser el primero en poder reaccionar a ella. Si llega tarde, alguien más podría tomarla antes que usted, pero cada empresa tiene una estrategia ligeramente diferente, por lo que podría estar bien si una iteración es un poco lenta.

El programa se ejecuta durante todo el día, casi sin intervención del usuario. Cualquiera que sea la función que maneja cada nueva pieza de datos del mercado, ejecute docenas (incluso cientos) de veces por segundo.

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

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

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

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

Tome las innumerables jerarquías de herencia endémicas de esos idiomas (como IEnumerable), en comparación con la sobrecarga cero de std :: sort o std :: for_each que es genérico. La velocidad de ejecución sin procesar de C ++ no es necesariamente más rápida, pero el programador puede diseñar sistemas rápidos o sin sobrecarga. Incluso cosas como el exceso de búfer, no se puede desactivar su detección. En C ++, tienes control. Fundamentalmente, C ++ es un lenguaje rápido: no paga por lo que no usa. Por el contrario, en C #, si usa, por ejemplo, stackalloc, NO puede realizar la comprobación de saturación del búfer. No puedes asignar clases en la pila, o contiguamente.

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

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 esté compilado de antemano o Just-In-Time, la recolección de basura puede destruir su latencia. Existen JVM en tiempo real con una latencia de recolección de basura garantizada. Es una tecnología bastante nueva, un dolor para sintonizar y ridículamente costoso, pero si tiene los recursos, puede hacerlo. Probablemente se convertirá en una práctica mucho más generalizada en los próximos años, ya que los primeros adoptantes financian la I + D que está ocurriendo ahora.

En primer lugar, 1 ms es una eternidad en HFT. Si crees que no es así, sería bueno leer un poco más sobre el dominio. (Es como estar a 100 millas del intercambio). El rendimiento y la latencia están profundamente entrelazados como lo indican las fórmulas en cualquier libro de texto de teoría de colas elemental. Las mismas fórmulas mostrarán valores de fluctuación de fase (dominados con frecuencia por la desviación estándar de la demora en la cola de la CPU si la estructura de la red es correcta y no ha configurado suficientes núcleos).

Uno de los problemas con el arbitraje de HFT es que una vez que decide capturar una propagación, hay dos pasos (o más) para obtener el beneficio. Si no golpea todas las piernas, puede quedarse con una posición que realmente no quiere (y una pérdida subsiguiente); después de todo, estaba arbitrando y no invirtiendo.

No desea posiciones a menos que su estrategia sea predecir el futuro (¡¡¡MUY corto plazo !!!) (y esto, créanlo o no, se hace MUY exitosamente). Si está a 1 ms del intercambio, no se ejecutará una fracción significativa de sus órdenes y se eliminará lo que deseaba. Lo más probable es que los que han ejecutado una pierna terminarán perdiendo o al menos no sean rentables.

Cualquiera que sea su estrategia, por el bien del argumento, permítanos decir que termina con una proporción de ganancia / pérdida de 55% / 45%. Incluso un pequeño cambio en la relación ganancia / pérdida puede tener un gran cambio en la rentabilidad.

re: "ejecutar docenas (incluso cientos)" parece desactivado por órdenes de magnitud Incluso mirando 20000 tics por segundo parece bajo, aunque este podría ser el promedio de todo el día para el conjunto de instrumentos que está mirando.

Existe una alta variabilidad en las tasas observadas en cualquier segundo dado. Daré un ejemplo. En algunas de mis pruebas, veo 7 acciones OTC (CSCO, GOOG, MSFT, EBAY, AAPL, INTC, DELL) en el medio del día, las tasas por segundo para esta corriente pueden variar desde 0 mps (muy, muy raro) a Casi casi 2000 cotizaciones y operaciones por segundo pico. (ver por qué creo que el 20000 anterior es bajo).

Construyo software de infraestructura y medición para este dominio y los números de los que hablamos son 100000 y millones por segundo. Tengo bibliotecas de infraestructura de productor / consumidor de C ++ que pueden impulsar casi 5000000 (5 millones) de mensajes / segundo entre productor y consumidor, (32 bits, núcleos de 2,4 GHz). Estos son mensajes de 64 bytes con nuevos, construir, poner en cola, sincronizar , en el lado del productor y sincronizar, en cola, tocar cada byte, ejecutar un destructor virtual, gratis en el lado del consumidor. Ahora hay que admitir que es un punto de referencia simple sin Socket IO (y Socket IO puede ser feo) como lo sería en los puntos finales de las etapas de la tubería de punto final. Son TODAS las clases de sincronización personalizadas que solo se sincronizan cuando están vacíos, asignadores personalizados, colas y listas personalizadas sin bloqueo, STL ocasional (con asignadores personalizados) pero más a menudo colecciones intrusivas personalizadas (de las cuales tengo una biblioteca importante). Más de una vez le he dado a un proveedor en este ámbito un cuádruple (y más) en el rendimiento sin aumentar el procesamiento por lotes en los puntos finales de socket.

Tengo clases OrderBook y OrderBook :: Universe que toman menos de 2us para la secuencia nueva, insertar, buscar, rellenar parcialmente, buscar, segundo relleno, borrar, eliminar cuando se promedian más de 22000 instrumentos. El punto de referencia se repite en todos los 22000 instrumentos en serie entre el primer relleno insertado y el último relleno, por lo que no hay trucos de almacenamiento en caché. Las operaciones en el mismo libro están separadas por accesos de 22000 libros diferentes. Estas no son en gran medida las características de almacenamiento en caché de los datos reales. Los datos reales están mucho más localizados en el tiempo y los intercambios consecutivos frecuentemente llegan al mismo libro.

Todo este trabajo implica una cuidadosa consideración de las constantes y las características de almacenamiento en caché en cualquiera de los costos algorítmicos de las colecciones utilizadas. (A veces parece que las K en K O (n) K O (n * log n) etc., etc., se descartan un poco con demasiada facilidad)

Trabajo en el lado de la infraestructura de Marketdata de las cosas. Es inconcebible pensar siquiera en usar java o un entorno administrado para este trabajo. Y cuando puede obtener este tipo de rendimiento con C ++ y creo que es bastante difícil obtener un rendimiento de millones + / mps en un entorno administrado) No puedo imaginar ninguno de los bancos de inversión o fondos de cobertura significativos (para quienes un salario de $ 250000 para un programador de C ++ de primera categoría no es nada) no va con C ++.

¿Alguien está realmente obteniendo un rendimiento de 2000000 + / mps en un entorno administrado? Conozco a algunas personas en este ámbito y nadie me jactó de ello. Y creo que 2 mm en un entorno administrado tendría algunos derechos para presumir.

Sé de un decodificador de orden FIX de un jugador importante haciendo 12000000 decodificaciones de campo / seg. (CPU de 3 GHz) Es C ++ y el tipo que lo escribió casi desafió a cualquiera a encontrar algo en un entorno administrado que sea incluso la mitad de esa velocidad.

Tecnológicamente es un área interesante con muchos desafíos divertidos de rendimiento. Tenga en cuenta el mercado de opciones cuando cambie la seguridad subyacente: podría haber, por ejemplo, 6 puntos de precio pendientes con 3 o 4 fechas de vencimiento diferentes. Ahora para cada comercio probablemente hubo 10-20 citas. Esas cotizaciones pueden desencadenar cambios de precios en las opciones. Así que para cada operación puede haber 100 o 200 cambios en las cotizaciones de opciones. Es solo una tonelada de datos, no una gran cantidad de datos parecidos al detector de colisiones del Gran Colisionador de Hadrones, pero aún es un reto. Es un poco diferente a tratar con las pulsaciones de tecla.

Incluso el debate sobre FPGA continúa. Mucha gente toma la posición de que un analizador bien codificado que se ejecuta en el producto básico de 3GHZ puede superar a un FPGA de 500MHz. Pero incluso si es un poco más lento (sin decir que lo son), los sistemas basados en FPGA pueden tender a tener distribuciones de retardo más ajustadas. (Lea "tend", esto no es una afirmación general). Por supuesto, si tiene un excelente analizador de C ++, presione un Cfront y luego lo empuje a través del generador de imágenes FPGA ... Pero ese otro debate ...

Esto podría ser un poco fuera de tema, pero vi un video hace un par de semanas que podría interesarte: http://ocaml.janestreet.com/?q=node/61

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

Hay razones para usar C ++ además del rendimiento. Hay una enorme biblioteca existente 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 debe diseñarse para ser llamado desde otra parte. Si nada más tendría que escribir algún tipo de envoltorio alrededor de las cosas exponiendo una API completamente C porque no puede P / Invocar a las clases de C ++.

Finalmente, P / Invoke es una operación muy costosa.

Los compiladores JIT están mejorando y mejorando. Pueden hacer optimizaciones mientras el programa se está ejecutando.

Sí, pueden hacer esto. Pero olvida que cualquier compilador de C ++ puede hacer las mismas optimizaciones. Claro, el tiempo de compilación será peor, pero el hecho de que dichas optimizaciones se hagan en tiempo de ejecución es una sobrecarga. Hay casos en 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 las optimizaciones en tiempo de ejecución. Estrictamente hablando, por supuesto, podría tener un modelo de memoria de este tipo en C ++, EDIT: como el manejo de cadenas de C #, / EDIT, pero pocos programadores de C ++ dedican tanto tiempo a optimizar su código como los chicos de JIT.

Existen algunos problemas de rendimiento que son inherentes a los idiomas administrados, como la E / S del disco. Es un costo de una sola vez, pero dependiendo de la aplicación puede ser significativo. Incluso con los mejores optimizadores, aún necesita cargar 30MB + de compilador JIT desde el disco cuando se inicia el programa; mientras que es raro que un binario de C ++ se acerque a ese tamaño.

La mayoría de nuestro código termina siendo ejecutado en una cuadrícula de miles de 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 otros factores entran en juego. Cuando esto se ejecuta en una cuadrícula, puede no hacer ninguna diferencia en cuanto a cómo se codifica como todo el proceso, una vez distribuido en las máquinas puede no ser un problema o resolverse mediante la asignación o la compra de algunas máquinas más. El problema y el costo más importante puede convertirse en ''tiempo de comercialización'', donde c # puede ser el ganador y la opción más rápida.

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

C # por seis meses ......

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

En contraste, C ++ plano 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 ++ pagas solo por lo que usas.

Mucho de esto se reduce a una simple diferencia entre hecho y teoría. Las personas tienen theories avanzadas 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 en lo que respecta a la compilación dinámica frente a la estática, Java y C ++ realmente son poco más que ejemplos de los dos (aunque, por supuesto, es posible compilar Java estáticamente o C ++ dinamicamente). La mayoría de estas personas tienen puntos de referencia para "probar" su afirmación. Cuando se examined esos puntos de referencia con algún detalle, rápidamente se hace evidente que en bastantes casos, tomaron medidas bastante extremas para obtener los resultados que deseaban (por ejemplo, un número bastante grande de optimización al compilar Java, pero deshabilitó específicamente la optimización al compilar el C ++).

Compare esto con el Juego de puntos de referencia del lenguaje de computadora , donde casi cualquier persona puede enviar una entrada, por lo que todo el código tiende a ser optimizado en un grado razonable (y, en algunos casos, incluso en un grado no razonable). Parece bastante claro que un buen número de personas tratan esto como esencialmente una competencia, y los defensores de cada idioma hacen todo lo posible por "probar" que su idioma preferido es el mejor. Dado que cualquiera puede enviar una implementación de cualquier problema, una presentación particularmente deficiente tiene poco efecto en los resultados generales. En esta situación, C y C ++ emergen como líderes claros.

Peor aún, si acaso, estos resultados probablemente muestren Java con una mejor luz de lo que es totalmente preciso. En particular, alguien que usa C o C ++ y realmente se preocupa por el rendimiento puede (y con frecuencia lo hará) usar el compilador de Intel en lugar de g ++. Esto típicamente proporcionará 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 es demasiado largo para caber razonablemente en comentarios):

Los punteros son una pesadilla optimizadores de escritores. Esto es realmente exagerar las cosas (bastante) un poco. Los punteros conducen a la posibilidad de crear alias, lo que impide ciertas optimizaciones en determinadas circunstancias. Dicho esto, la alineación previene los efectos negativos la mayor parte del tiempo (es decir, el compilador puede detectar si hay aliasing en lugar de generar siempre un código bajo el supuesto de que podría haberlo). Incluso cuando el código tiene que asumir un alias, el almacenamiento en caché minimiza el impacto del rendimiento al hacerlo (es decir, los datos en el caché L1 son solo un poco más lentos que los datos en un registro). Evitar el alias ayudaría al rendimiento en C ++, pero no tanto como podría pensar.
La asignación es mucho más rápida con un recolector de basura. Es cierto que el asignador predeterminado en muchas implementaciones de C ++ es más lento que lo que la mayoría de los asignadores de basura recolectados (actuales) proporcionan. Esto está equilibrado (al menos hasta cierto punto) por el hecho de que las asignaciones en C ++ tienden a estar en la pila, que también es rápida, 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 asigna espacio para cada objeto individualmente, mientras que en C ++ normalmente asigna espacio para todos los objetos en un ámbito juntos.

También es cierto que C ++ admite directamente la sustitución de los asignadores de forma global y por clase, por lo que cuando / si la velocidad de asignación realmente es un problema, generalmente es bastante fácil de solucionar.

En última instancia, Jalf tiene razón: ambos puntos, sin duda , 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 gran parte del código, 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 centavo. Para aquellos que no lo conocen, Jon ha sido un notorious troll and spammer for years , y parece estar buscando un nuevo terreno para sembrar malezas. Trataré de responder a su comentario en detalle, pero (como es típico de él) consiste únicamente en generalizaciones no calificadas y sin respaldo que contienen tan poco contenido real que es imposible una respuesta significativa. Todo lo que se puede hacer es advertir a los espectadores que es bien conocido por ser deshonesto, egoísta y mejor ignorado.

Nikie escribió: "¿Podría explicar qué puede hacer con los subprocesos en C ++ y no con, por ejemplo, los subprocesos .NET?"

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

Ejecución eficiente de código binario encapsulado COM. Por ejemplo, algoritmos confidenciales que deben mantenerse secretos de los desarrolladores de aplicaciones. (Podría ser relevante en HFT)
Creación de subprocesos lean que no agotan los recursos del sistema con bloques de construcción macizos: API de SO envueltas y primitivas de OS de sincronización y señalización. (Extremadamente relevante con algoritmos paralelos para la optimización del rendimiento del tiempo en HFT)
Ampliación del rendimiento de una aplicación de proceso empresarial 10 o más veces en el mismo hardware y con la misma latencia. (No relevante en HFT)
Incrementando 100 y más veces el número de interacciones de usuario manejadas simultáneamente por unidad de hardware. (No relevante en HFT)

El uso de más núcleos de CPU no puede compensar completamente el agotamiento de los recursos del sistema por parte de los componentes básicos de .Net, ya que más núcleos de CPU son una garantía para la aparición de la contención de memoria.

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 una programación eficiente (!).

De modo que tiene bastantes posibilidades para elegir un sistema operativo y algunas para elegir el idioma. Hay C, Java en tiempo real, Fortran en tiempo real y algunos otros.

O quizás tenga los mejores resultados en la programación de un procesador / FPGA para eliminar el costo de un sistema operativo.

La mejor opción que tiene que hacer, cuántas posibles optimizaciones de rendimiento ignorará a favor de elegir un lenguaje que facilite el desarrollo y se ejecute de forma más estable, ya que puede hacer menos errores, lo que dará como resultado una mayor disponibilidad del sistema. Esto no debe ser pasado por alto. No tiene ninguna ventaja en el desarrollo de una aplicación que se ejecute un 5% más rápido que cualquier otra aplicación que se bloquee cada pocos puntos debido a algunos errores menores difíciles de encontrar.

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 compilar porque sucede fuera de línea, y el usuario no está sentado allí tocando sus dedos y esperando.

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

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

Y, por supuesto, los idiomas 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 (por ejemplo, construcción de clase).

Por otro lado, en C #, desperdicias una buena parte de la memoria. Y simplemente crear una instancia de una clase conlleva una buena parte de los gastos generales, ya que el Object base debe inicializarse, incluso si su clase real está vacía.

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

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

Hay ventajas de cualquier manera, por lo que es ingenuo esperar que puedas obtener una respuesta simple "una o la otra". Dependiendo del código fuente exacto, el compilador, el sistema operativo, el hardware en el que se está ejecutando, uno u otro pueden ser más rápidos. Y dependiendo de sus necesidades, el rendimiento en bruto podría no ser el objetivo número 1. Quizás esté más interesado en la capacidad de respuesta, en evitar los puestos impredecibles.

En general, su código C ++ típico tendrá un rendimiento similar al código C # equivalente. A veces más rápido, a veces más lento, pero probablemente no sea una diferencia dramática de ninguna manera.

Pero una vez más, depende de las circunstancias exactas. Y depende de cuánto tiempo esté dispuesto a dedicar a la optimización. Si está dispuesto a pasar todo el tiempo que sea necesario, el código C ++ generalmente puede lograr un mejor rendimiento que C #. Solo se necesita mucho trabajo.

Y la otra razón, por supuesto, es que la mayoría de las compañías que usan C ++ ya tienen una base de código de C ++ grande que no quieren abandonar. Lo necesitan para seguir trabajando, incluso si migran gradualmente (algunos) componentes nuevos a un idioma administrado.

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

No es necesariamente más rápido que Java / C # / ..., pero es consistente en todas las ejecuciones .

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 nivel bajo .

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

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

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 afirmamos claramente, como acabo de decir, no podemos pretender participar en un debate significativo sobre este tema indiscutible. ¿ Cuánto más rápido es C ++ que Java para su aplicación ? Eso tiene el sonido 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 no habrá espacio para el debate.

Regresemos a su primera reunión de diseño: el requisito importante para su proyecto es el alto rendimiento. Todos en la sala pensarán "C ++" y un puñado de otros lenguajes compilados. El chico de 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 sobre sitios de chismes de programadores, y ciertamente no con "hola". mundo "puntos de referencia.

Tal como está ahora, tiene que avanzar con lo que sabe , no con lo que es hipotéticamente posible.