Java potrebbe mai abbinare C ++ per quanto riguarda la programmazione di sistemi ad altissima frequenza? La JVM è migliorata abbastanza da consentire questo? Da un punto di vista teorico o pratico è possibile?
Il C ++ è usato nella maggior parte dei sistemi UHF semplicemente per abitudine?
Se sei d'accordo / in disaccordo, quali parti di Java / C ++ sono la base per il tuo punto di vista?
Il problema inerente è il garbage collector. È non deterministico, qualcosa che l'UHF non può mai affrontare. Lavorare su questo problema equivale sostanzialmente a reinventare gli allocatori nativi. Inoltre, il linguaggio comporta un sovraccarico intrinseco che non può essere ridotto, in cui i costrutti di C ++ sono direttamente più efficienti, ad esempio, una variabile membro Java deve essere un altro riferimento, anche se in realtà potrebbe essere allocata come parte del blocco, che è come è fatto in C ++. Ciò impone extra overhead / cache overhead / ecc. Ciò significa che un programma UHF Java sarebbe intrinsecamente significativamente più difficile da scrivere, per risultati scadenti, rispetto a un equivalente C ++.
Fondamentalmente, il determinismo ad alte prestazioni si trova nel design di C ++. Non è nella progettazione di Java.
Modifica: cosa intendevo per "parte del blocco". In C ++, una classe o una struct viene allocata come un singolo chunk, in modo efficace, è una matrice. Ciò significa che l'indicizzazione su quell'array quasi arbitrariamente è praticamente gratuita, ovvero l'accesso a una variabile membro in C ++ equivale a un indice di array, per ogni nidificazione. In Java, tuttavia, è necessario puntare a tutte le variabili membro del tipo di classe. Ciò significa che le classi in Java necessariamente formano elenchi collegati, che sono molto più lenti da accedere. Ogni variabile membro a cui accedi in Java è un riferimento al puntatore, che è terribilmente lento nel confronto. Ora, in C ++, se ne hai bisogno, puoi creare membri di puntatori e accedere attraverso di essi, ma in Java non esiste un'opzione equivalente per rendere i membri in un array. Ciò significa che Java impone la semantica di accesso alle liste collegate più lenta. Lo stesso principio si applica a molti altri casi simili.
E un GC concorrente aiuterà solo con un programma non massimale-simultaneo. Se hai un programma che usa il 100% di CPU, non c'è modo di farlo senza ridurre la quantità disponibile per il programma.
Sì, se si progettano correttamente le strutture dati, gli oggetti e l'architettura (il che è vero sotto qualsiasi piattaforma). Il Disruptor lo ha più che dimostrato di recente.
Detto questo, C e C ++ offrono ancora costrutti di livello inferiore rispetto a Java (che probabilmente ha bisogno di qualcosa come le tuple per aiutare a spingerlo oltre il limite)
Le tue miglia possono variare (YMMV) con tutto questo.
Per la parte sensibile alla velocità in Trading ad alta frequenza , Java non è abbastanza buono.
Java non consente un controllo sufficiente sul layout degli oggetti. In particolare, manca un layout di memoria compatto fornito dall'array e dal vettore. Una lista array di riferimenti a oggetti non è la stessa.
Java ha anche un overhead di oggetto diverso da zero, con conseguente aumento degli oggetti.
Entrambi producono errori di cache, che peggiorano il tempo di reazione.
E in HFT, il vincitore prende tutto - Non c'è un secondo posto.
Molti commenti sulle altre risposte si concentrano in modo errato su Garbage Collector. GC non importa affatto. Durante la parte sensibile alla velocità, GC non verrà attivato. E ci sarà abbastanza tempo tra due eventi sensibili alla velocità per fare tutto il tempo necessario per mantenere la casa, nessun sistema HFT dovrebbe essere vicino al 100% del carico.
Parte di qualsiasi progetto il più veloce possibile, sta posticipando qualsiasi cosa non cruciale per l'invio dell'ordine fino a dopo l'invio. In effetti, GC potrebbe davvero aiutare in questo aspetto! In pratica, di solito è più semplice allocare la memoria necessaria all'avvio e riutilizzarla.
Naturalmente, ci sono anche parti che non sono sensibili alla velocità: GUI, post-elaborazione, calcolo dei rischi, monitoraggio e così via. Queste parti possono essere eseguite in quasi tutte le lingue, incluso Java.