C'è una diapositiva interessante in questa presentazione Scala su Facebook che mostra le prestazioni relative di alcune lingue rispetto a in C ++.

1. C ++ (1)
2. Java (2)
3. C # (3)
4. Erlang (6)
5. Python (21)
6. Perl (38)
7. PHP (+ -40)
8. Ruby (+ -70)

Ogni volta che ti preoccupi profondamente delle prestazioni, generalmente desideri avvicinarti il più possibile al metallo. Nella maggior parte delle lingue, è possibile scrivere segmenti di prestazioni critici nel codice C. I programmatori C possono passare al linguaggio assembly per le cose veramente importanti. Quindi, se sto scrivendo un codice C #, ma ho davvero bisogno di una prestazione limitata su un loop interno, posso scrivere un codice C o C ++ e usare interop per chiamare quel codice. Se ho bisogno di prestazioni ancora maggiori, posso scrivere assembly nella mia libreria C. Andare più in basso del montaggio è possibile, ma chi vuole scrivere codice macchina in questi giorni?

Tuttavia, e questa è la grande considerazione, il fatto di avvicinarsi al metallo è solo ad alte prestazioni per obiettivi piccoli e ristretti. Se stavo scrivendo un renderer 3D, potrei fare il calcolo a virgola mobile e il rendering in C, (usando una libreria per eseguirlo sulla scheda video.) Ma i problemi di performance sono anche architettonici, e spesso i problemi di prestazioni da problemi su larga scala risolto meglio in un linguaggio di alto livello.

Guarda Erlang: Ericsson aveva bisogno di un linguaggio per eseguire facilmente un lavoro parallelo enorme, perché l'elaborazione parallela avrebbe avuto più prestazioni di qualsiasi routine C strettamente ottimizzata su un core della CPU. Allo stesso modo, avere il codice più veloce in esecuzione nel tuo loop è solo un miglioramento delle prestazioni se non puoi rimuovere completamente il loop facendo qualcosa di meglio al livello più alto.

Puoi fare un enorme sistema, programmazione ad alto livello in C, ma a volte la maggiore espressività di un linguaggio più potente mostrerà opportunità di ottimizzazioni architettoniche che altrimenti non sarebbero ovvie.

C ++

Fondamentalmente tutti i pacchetti di simulazione numerica contemporanea sono scritti in C ++ reale o usano alcune caratteristiche C ++ su un corpo C di grandi dimensioni.

Tradizionalmente, molti pacchetti sono stati scritti in Fortran, specialmente in fisica, qui -
nella lista QC e pacchetti Sim Solid State potresti vedere una "colonna della lingua".

Ecco qualcosa di simile per Physical Chemistry / Molecular Modeling -
Pacchetti di dinamica molecolare .

Saluti

RBO

Direi Java per lo sviluppo rapido di applicazioni e C ++ per il potere grezzo.

Java ha librerie numerose che rendono lo sviluppo molto più semplice - ad esempio l'API Swing che rende lo sviluppo della GUI quasi incredibilmente facile, specialmente con un IDE come Netbeans. Anche il file I / O è molto più semplice (IMO) in Java rispetto a C / C ++. Java ha anche il vantaggio di essere facilmente trasferito su un'altra piattaforma poiché viene eseguito su una macchina virtuale.

C ++ è stato a lungo utilizzato nella comunità grafica. A mio avviso, è usato perché lavora a stretto contatto con l'hardware (essendo tipicamente digitato e compilato, non interpretato in alcun modo) ma utilizza ancora principi orientati agli oggetti per la struttura e l'organizzazione. L'aspetto compilabile è importante per la programmazione della GPU. Inoltre, non penso che tu possa abbandonare le istruzioni ASM in un programma Java. La combinazione di velocità e flessibilità rende C ++ ideale per l'elaborazione grafica e altre applicazioni in tempo reale.

Quindi, in breve, la lingua che si adatta meglio alla tua applicazione. Questi sono solo i due linguaggi orientati agli oggetti a cui sono più familiare; ci possono essere anche altri che sono meglio di questi in certe applicazioni.

Omettere lo sforzo di sviluppo, il tempo e i costi per ottenere il massimo dalle prestazioni da un linguaggio tipizzato e compilato staticamente. Le lingue interpretate dinamicamente (o Just in time compilated a.k.a. JIT), d'altra parte, in genere dovrebbero ridurre gli sforzi, i tempi e i costi di sviluppo. Inoltre, si prevede che riducano gli sforzi, i tempi e i costi di implementazione.

C ++ sta diventando uno degli ovvi vincitori qui e viene utilizzato ampiamente nella comunità di sviluppo del gioco per questo motivo.

Tuttavia, le soluzioni scalabili sembrano beneficiare dei ridotti costi di implementazione dei linguaggi dinamici e interpretati. Pertanto, mentre una casella può essere eseguita più lentamente di un codice C ++ equivalente, un cloud di interpreti o macchine virtuali può avere il vantaggio di assumere budget di distribuzione uguali. Java è un esempio, ma le nuvole di Ruby o di Scala in particolare potrebbero essere più indicative di questa tendenza.

Dipende. Direi che per processi a esecuzione prolungata, Java è una scelta altrettanto valida di C o C ++. Le lingue compilate si attivano molto più rapidamente. Tuttavia, in un runtime JITed, l'ottimizzatore ha informazioni migliori perché accade in fase di runtime.

Infine, non dimenticare di OCaml. È un linguaggio compilato orientato agli oggetti che può essere eseguito a velocità quasi-C.

Oltre al costo di avvio, non so se ci sia una ragione teorica per cui una piattaforma JIT non funzionerebbe come una piattaforma di codice nativo.

Ci sono altre funzionalità linguistiche, come la garbage collection, il che significa che Java utilizzerà più risorse e probabilmente sarà più lento ma è molto facile sopravvalutare questo vantaggio.

In pratica, tuttavia, esistono diverse culture di programmazione attorno a C ++ rispetto a Java. Ciò si traduce in progetti di Java spesso più astratti, che si basano maggiormente sulla riflessione e su vari schemi di collegamento in fase di runtime che rendono difficile o addirittura impossibile ottimizzare abbastanza. Sì, potreste fare tutte queste stesse cose in C ++ e renderlo più lento ma, a mio modesto avviso, c'è meno accettazione culturale di ciò nella comunità C ++. Penso che questo sia in parte dovuto alla reputazione di C ++ per "essere veloce" - quindi è auto-appagante!

Per cose come i driver di dispositivo e alcune applicazioni incorporate non hai altra scelta che usare C / C ++ ma la maggior parte degli sviluppatori non incontrerà questi scenari.