Prestazioni C++ rispetto a Java/C#

JIT rispetto al compilatore statico

Come già detto nei post precedenti, JIT può compilare IL/bytecode in codice nativo in fase di runtime. Il costo di ciò è stato menzionato, ma non alla sua conclusione:

JIT ha un grosso problema è che non può compilare tutto: la compilazione di JIT richiede tempo, quindi JIT compilerà solo alcune parti del codice, mentre un compilatore statico produrrà un binario nativo completo: Per alcuni tipi di programmi, il compilatore statico semplicemente supererà facilmente JIT.

, naturalmente, C# o Java o VB) è di solito più veloce per produrre valida e robusta soluzione che è il C++ (se non altro perché il C++ è complessa semantica, e la libreria standard del C++, mentre interessanti e potenti, è molto povero se confrontato con la portata della libreria standard da .NET o Java), quindi di solito, la differenza tra C++ e .NET o Java JIT non è visibile per la maggior parte degli utenti, e per i file binari che sono critiche, beh, si può comunque chiamare il C++ elaborazione da C# o Java (anche se questo tipo di chiamate native può essere piuttosto costoso di per sé)...

Metaprogrammazione C++

Si noti che di solito si sta confrontando il codice di runtime C++ con il suo equivalente in C# o Java. Ma C++ ha una caratteristica che può sovraperformare Java/C# fuori dalla scatola, ovvero la metaprogrammazione del modello: l'elaborazione del codice verrà eseguita al momento della compilazione (quindi, aumentando notevolmente il tempo di compilazione), risultando in zero (o quasi zero) runtime.

Ho ancora così vedere un vero e proprio effetto vita su questo (ho giocato solo con i concetti, ma a quel punto, la differenza era secondi di esecuzione per JIT, e zero per C++), ma questo vale la pena menzionare, insieme al fatto modello metaprogrammazione non è banale...

Edit 2011-06-10: {[29] } In C++, giocare con i tipi viene fatto in fase di compilazione, il che significa produrre codice generico che chiama codice non generico (ad esempio un parser generico dalla stringa al tipo T, chiamando l'API di libreria standard per i tipi T it e rendere il parser facilmente estensibile dal suo utente) è molto facile e molto efficiente, mentre l'equivalente in Java o C # è doloroso al massimo da scrivere, e sarà sempre più lento e risolto in fase di runtime anche quando i tipi sono noti in fase di compilazione, il che significa che la tua unica speranza è che il JIT

...

Modifica 2011-09-20: Il team dietro Blitz++ ( Homepage, Wikipedia ) è andato in questo modo, e apparentemente, il loro obiettivo è raggiungere le prestazioni di FORTRAN sui calcoli scientifici spostandosi il più possibile dall'esecuzione del runtime al tempo di compilazione, tramite la metaprogrammazione del modello C++. Quindi il" Ho ancora visto un effetto reale su questa parte " che ho scritto sopra apparentemente esiste nella vita reale.

Utilizzo nativo della memoria C++

C++ ha un utilizzo della memoria diverso da Java / C#, e quindi, ha diverso vantaggi / difetti.

Non importa l'ottimizzazione JIT, nulla andrà veloce come l'accesso diretto del puntatore alla memoria (ignoriamo per un momento le cache del processore, ecc.). Quindi, se si dispone di dati contigui in memoria, accedendo tramite puntatori C++ (cioè puntatori C... Diamo a Cesare il suo dovuto) andrà volte più velocemente che in Java / C#. E C++ ha RAII, che rende molto più facile l'elaborazione che in c# o anche in Java. C++ non ha bisogno di using per scope l'esistenza dei suoi oggetti. E C++ non ha una clausola finally. Questo non è un errore.

:-)

E nonostante le strutture C# primitive, gli oggetti C++ "in pila" non costeranno nulla all'allocazione e alla distruzione e non avranno bisogno di GC per lavorare in un thread indipendente per eseguire la pulizia.

Per quanto riguarda la frammentazione della memoria, gli allocatori di memoria nel 2008 non sono i vecchi allocatori di memoria del 1980 che vengono solitamente confrontati con un GC: l'allocazione C++ non può essere spostata in memoria, vero, ma poi, come su un Linux filesystem: Chi ha bisogno di deframmentazione del disco rigido quando la frammentazione non avviene? L'utilizzo dell'allocatore giusto per l'attività giusta dovrebbe far parte del toolkit per sviluppatori C++. Ora, scrivere allocatori non è facile, e poi, la maggior parte di noi hanno cose migliori da fare, e per la maggior parte di utilizzo, RAII o GC è più che sufficiente.

Modifica 2011-10-04: Per esempi su allocatori efficienti: su piattaforme Windows, da Vista, l'heap a bassa frammentazione è abilitato per impostazione predefinita. Per le versioni precedenti, LFH può essere attivato chiamando la funzione WinAPI HeapSetInformation ). Su altri sistemi operativi, vengono forniti allocatori alternativi (vedi https://secure.wikimedia.org/wikipedia/en/wiki/Malloc per un elenco)

Ora, il modello di memoria sta diventando un po ' più complicato con l'ascesa della tecnologia multicore e multithreading. In questo campo, immagino che. NET abbia il vantaggio, e Java, mi è stato detto, ha tenuto il piano superiore. È facile per alcuni hacker "on the bare metal" lodare il suo codice "near the machine". Ma ora, è molto più difficile produrre un assemblaggio migliore a mano che lasciare il compilatore al suo lavoro. Per C++, il compilatore è diventato solitamente migliore dell'hacker da un decennio. Per C # e Java, questo è ancora più facile.

Tuttavia, il nuovo standard C++0x imporrà un semplice modello di memoria ai compilatori C++, che standardizzerà (e quindi semplificherà) in modo efficace multiprocessing/parallel / threading codice in C++, e rendere le ottimizzazioni più facile e sicuro per i compilatori. Ma poi, vedremo in qualche paio di anni se le sue promesse sono ritenute vere.

C++ / CLI vs. C # / VB.NET

Nota: In questa sezione, sto parlando di C++ / CLI, cioè il C++ ospitato da.NET, non il C++nativo.

La scorsa settimana, ho avuto una formazione sull'ottimizzazione.NET e ho scoperto che il compilatore statico è comunque molto importante. Importante di JIT.

Lo stesso codice compilato in C++/CLI (o il suo antenato, Managed C++) potrebbe essere volte più veloce dello stesso codice prodotto in C# (o VB.NET, il cui compilatore produce lo stesso IL di C#).

Perché il compilatore statico C++ era molto meglio per produrre codice già ottimizzato rispetto a C#.

Ad esempio, l'inlining delle funzioni in.NET è limitato alle funzioni il cui bytecode è minore o uguale a 32 byte di lunghezza. Quindi, un codice in c# produrrà un accessor di 40 byte, che non sarà mai intarsiato dal JIT. Lo stesso codice in C++ / CLI produrrà un accessor di 20 byte, che verrà inserito dal JIT.

Un altro esempio sono le variabili temporanee, che vengono semplicemente compilate dal compilatore C++ mentre vengono ancora menzionate nell'IL prodotto dal compilatore c#. L'ottimizzazione della compilazione statica C++ si tradurrà in meno codice, quindi autorizza un'ottimizzazione JIT più aggressiva, di nuovo.

La ragione di ciò è stata ipotizzata come il compilatore C++/CLI approfittato delle vaste tecniche di ottimizzazione dal compilatore nativo C++.

Conclusione

Amo il C++.

Ma per quanto lo vedo, C # o Java sono tutto sommato una scommessa migliore. Non perché sono più veloci di C++, ma perché quando si sommano le loro qualità, finiscono per essere più produttivi, che necessitano di meno formazione e hanno librerie standard più complete di C++. E come per la maggior parte dei programmi, le loro differenze di velocità (in un modo o nell'altro) saranno trascurabile...

Modifica (2011-06-06)

La mia esperienza su C#/. NET

Ora ho 5 mesi di codifica professionale C# quasi esclusiva (che si aggiunge al mio CV già pieno di C++ e Java, e un tocco di C++/CLI).

Ho giocato con WinForms (Ahem...) e WCF (cool!), e WPF (Freddo!!!! Sia attraverso XAML che raw C#. WPF è così facile che credo che Swing non possa essere paragonato ad esso) e C# 4.0.

La conclusione è che mentre è più facile/veloce produrre un codice che funziona in c # / Java che in C++, è molto più difficile produrre un codice forte, sicuro e robusto in c# (e ancora più difficile in Java) che in C++. Le ragioni abbondano, ma possono essere riassunte da:

1. I generici non sono potenti come i modelli (prova a scrivere un metodo di analisi generico efficiente (da string a T) o un equivalente efficiente di boost:: lexical_cast in c# per capire il problema)
2. RAII rimane senza pari (GC ancora possibile perdita (sì, ho dovuto gestire questo problema) e gestirà solo la memoria. Anche C#using non è così facile e potente perché scrivere una corretta implementazione di Dispose è difficile)
3. C # readonly e Java final non sono utili come C++const ( Non è possibile esporre dati complessi di sola lettura (ad esempio un albero di nodi) in c# senza un lavoro straordinario, mentre è una funzionalità integrata di C++. I dati immutabili sono una soluzione interessante, ma non tutto può essere reso immutabile, quindi non è nemmeno abbastanza, di gran lunga).

Quindi, c# rimane un linguaggio piacevole finché vuoi qualcosa che funzioni, ma un linguaggio frustrante nel momento in cui vuoi qualcosa chefunziona sempre e in modo sicuro .

Java è ancora più frustrante, in quanto ha gli stessi problemi di c#, e altro ancora: mancando l'equivalente della parola chiave using di c#, un mio collega molto abile ha passato troppo tempo ad assicurarsi che le sue risorse fossero correttamente liberate, mentre l'equivalente in C++ sarebbe stato facile (usando distruttori e puntatori intelligenti).

Quindi immagino che il guadagno di produttività di C#/Java sia visibile per la maggior parte del codice... fino al giorno in cui hai bisogno che il codice sia il più perfetto possibile. Quel giorno conoscerai il dolore. (non crederai a ciò che viene chiesto dalle nostre app server e GUI...).

Informazioni su Java lato server e C++

Ho mantenuto i contatti con i team server (ho lavorato 2 anni tra di loro, prima di tornare al team GUI), al dall'altro lato dell'edificio, e ho imparato qualcosa di interessante.

Negli ultimi anni, la tendenza era quella di far sì che le app per server Java fossero destinate a sostituire le vecchie app per server C++, poiché Java ha molti framework/strumenti ed è facile da mantenere, distribuire, ecc. ecc..

...Fino a quando il problema della bassa latenza ha sollevato la sua brutta testa negli ultimi mesi. Quindi, le app Java server, indipendentemente dall'ottimizzazione tentata dal nostro esperto team Java, hanno perso in modo semplice e pulito la corsa contro il vecchio, non server C++ davvero ottimizzato.

Attualmente, la decisione è di mantenere i server Java per uso comune in cui le prestazioni, pur essendo ancora importanti, non sono interessate dal target a bassa latenza e ottimizzano in modo aggressivo le già più veloci applicazioni server C++ per esigenze a bassa latenza e ultra-bassa latenza.

Conclusione

Niente è così semplice come previsto.

Java, e ancora di più C#, sono linguaggi interessanti, con ampie librerie e framework standard, dove è possibile codice veloce, e hanno risultato molto presto.

Ma quando hai bisogno di potenza grezza, ottimizzazioni potenti e sistematiche, forte supporto al compilatore, potenti funzionalità del linguaggio e sicurezza assoluta, Java e C# rendono difficile vincere le ultime percentuali di qualità mancanti ma critiche che devi rimanere al di sopra della concorrenza.

È come se avessi bisogno di meno tempo e di sviluppatori meno esperti in c # / Java che in C++ per produrre codice di qualità media, ma d'altra parte, nel momento in cui ne avevi bisogno eccellente per perfezionare il codice di qualità, è stato improvvisamente più facile e veloce per ottenere i risultati giusti in C++.

Naturalmente, questa è la mia percezione, forse limitata alle nostre esigenze specifiche.

Ma ancora, è quello che succede oggi, sia nei team GUI che nei team lato server.

Naturalmente, aggiornerò questo post se succede qualcosa di nuovo.

Modifica (22/06/2011)

" Troviamo che per quanto riguarda le prestazioni, C++ vince fuori da un ampio margine. Tuttavia, esso richiesto anche il più ampio sforzi di messa a punto, molti dei quali sono stati fatti a un livello di sofisticazione questo non sarebbe disponibile per il programmatore medio.

[...] La versione Java era probabilmente la più semplice da implementare, ma la più difficile da analizzare per le prestazioni. In particolare gli effetti sulla garbage collection erano complicati e molto difficili da accordare."

Fonti:

• https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
• http://www.computing.co.uk/ctg/news/2076322/-winner-google-language-tests

Modifica (20-09-2011)

"La parola corrente su Facebook è che ' il codice C++ ragionevolmente scritto corre veloce,' che sottolinea l'enorme sforzo speso per ottimizzare il codice PHP e Java. Paradossalmente, il codice C++ è più difficile da scrivere che in altre lingue, ma codice efficiente è molto più facile [scrivere in C++ che in altre lingue]."

– Herb Sutter a / / build / , citando Andrei Alexandrescu

Fonti:

• http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T
• http://video.ch9.ms/build/2011/slides/TOOL-835T_Sutter.pptx

Ogni volta che parlo di prestazioni gestite rispetto a quelle non gestite, mi piace puntare alla serie che Rico (e Raymond) hanno fatto confrontando le versioni C++ e C# di un dizionario cinese/inglese. Questo ricerca su Google vi permetterà di leggere per te, ma mi piace riassunto di Rico.

Quindi mi vergogno per la mia sconfitta schiacciante? Difficilmente. Il codice gestito ha un buon risultato per quasi nessuno sforzo. Per sconfiggere il Raymond gestito ha dovuto:

• Scrivere il proprio file di I/O roba
• Scrivere la propria classe stringa
• Scrivere il proprio allocatore
• Scrivere la propria mappatura internazionale

Naturalmente ha usato disponibile inferiore librerie di livello per fare questo, ma questo è ancora un sacco di lavoro. Puoi chiamare cosa rimane di un programma STL? Io no penso di sì, penso che ha mantenuto il std:: classe vettoriale che alla fine era mai un problema e ha mantenuto il ritrovamento funzione. Praticamente tutto il resto e ' sparito.

Quindi, sì, puoi sicuramente battere il CLR. Raymond puo far partire il suo programma ancora più veloce credo.

È interessante notare che il tempo di analizzare il file come riportato da entrambi i programmi timer interno è circa lo stesso -- 30 ms per ciascuno. La differenza è in overhead.

Per me la linea di fondo è che ci sono volute 6 revisioni per la versione non gestita per battere la versione gestita che era una semplice porta del codice non gestito originale. Se hai bisogno di ogni ultimo bit di prestazioni (e hai il tempo e per ottenerlo), dovrai andare non gestito, ma per me, prenderò l'ordine di vantaggio che ho sulle prime versioni rispetto al 33% che guadagno se provo 6 volte.

La compilazione per specifiche ottimizzazioni della CPU è in genere sopravvalutata. Basta prendere un programma in C++ e compilare con ottimizzazione per pentium PRO ed eseguire su un pentium 4. Quindi ricompila con optimize per pentium 4. Ho passato lunghi pomeriggi a farlo con diversi programmi. Risultati generali?? Di solito meno di 2-3% aumento delle prestazioni. Quindi i vantaggi teorici del JIT sono quasi nulli. La maggior parte delle differenze di prestazioni può essere osservata solo quando si utilizzano funzionalità di elaborazione dati scalari, qualcosa che alla fine avrà bisogno di tunning fine manuale per ottenere comunque le massime prestazioni. Ottimizzazioni di questo tipo sono lente e costose da eseguire rendendole a volte inadatte per JIT comunque.

Nel mondo reale e nell'applicazione reale Il C++ è ancora solitamente più veloce di java, principalmente a causa dell'ingombro della memoria più leggero che si traduce in migliori prestazioni della cache.

Ma per utilizzare tutte le funzionalità C++, lo sviluppatore deve lavorare sodo. È possibile ottenere risultati superiori, ma si devi usare il tuo cervello per questo. C++ è un linguaggio che ha deciso di presentarvi con più strumenti, carica il prezzo che si deve imparare loro di essere in grado di utilizzare bene la lingua.

JIT (Just In Time Compiling) può essere incredibilmente veloce perché ottimizza per la piattaforma di destinazione.

Ciò significa che può sfruttare qualsiasi trucco del compilatore in grado di supportare la CPU, indipendentemente dalla CPU su cui lo sviluppatore ha scritto il codice.

Il concetto di base del JIT. NET funziona in questo modo (fortemente semplificato):

Chiamare un metodo per la prima volta:

• Il codice del programma chiama un metodo Foo ()
• Il CLR guarda il tipo che implementa Foo () e ottiene i metadati ad esso associati
• Dai metadati, il CLR sa in quale indirizzo di memoria è memorizzato l'IL (codice byte intermedio).
• Il CLR alloca un blocco di memoria e chiama il JIT.
• Il JIT compila l'IL in codice nativo, lo inserisce nella memoria allocata e quindi cambia il puntatore della funzione nei metadati di tipo di Foo () per puntare a questo codice nativo.
• Viene eseguito il codice nativo.

Chiamare un metodo per la seconda volta:

• Il codice del programma chiama un metodo Foo ()
• Il CLR esamina il tipo che implementa Foo() e trova il puntatore della funzione nei metadati.
• Viene eseguito il codice nativo in questa posizione di memoria.

Come puoi vedere, la seconda volta è praticamente lo stesso processo del C++, tranne che con il vantaggio delle ottimizzazioni in tempo reale.

Detto questo, ci sono ancora altri problemi generali che rallentano una lingua gestita, ma il JIT aiuta molto.

Mi piace la risposta di Orion Adrian , ma c'è un altro aspetto.

La stessa domanda è stata posta decenni fa sul linguaggio assembly rispetto a linguaggi "umani" come FORTRAN. E parte della risposta è simile.

Sì, un programma C++ è in grado di essere più veloce di c# su qualsiasi dato (non banale?) algoritmo, ma il programma in c# sarà spesso più veloce o più veloce di un'implementazione "ingenua" in C++, e una versione ottimizzata in C++ richiederà più tempo per lo sviluppo e potrebbe ancora battere la versione c# con un margine molto piccolo. Quindi, ne vale davvero la pena?

Dovrai rispondere a questa domanda uno per uno.

Detto questo, sono un fan di lunga data del C++, e penso che sia un linguaggio incredibilmente espressivo e potente-a volte sottovalutato. Ma in molti problemi di " vita reale "(per me personalmente, questo significa" il tipo che vengo pagato per risolvere"), C# otterrà il lavoro fatto prima e più sicuro.

La penalità più grande che paghi? Molti programmi. NET e Java sono maiali di memoria. Ho visto le app. NET e Java prendere " centinaia "di megabyte di memoria, quando i programmi C++ di complessità simile graffiano a malapena le" decine " di MB.

Non sono sicuro di quanto spesso scoprirai che il codice Java verrà eseguito più velocemente di C++, anche con Hotspot, ma mi occuperò di spiegare come potrebbe accadere.

Pensa al codice Java compilato come linguaggio macchina interpretato per la JVM. Quando il processore Hotspot nota che alcuni pezzi del codice compilato verranno utilizzati molte volte, esegue un'ottimizzazione sul codice macchina. Poiché l'assemblaggio a mano è quasi sempre più veloce del codice compilato in C++, va bene capire quel codice macchina sintonizzato a livello di codice non sarà troppo male.

Quindi, per un codice altamente ripetitivo, ho potuto vedere dove sarebbe possibile per Hotspot JVM eseguire Java più velocemente di C++... fino a quando la raccolta dei rifiuti entra in gioco. :)

In generale, l'algoritmo del tuo programma sarà molto più importante per la velocità della tua applicazione rispetto al linguaggio . È possibile implementare un algoritmo scadente in qualsiasi lingua, incluso il C++. Con questo in mente, in genere sarai in grado di scrivere codice più velocemente in una lingua che ti aiuti a implementare un algoritmo più efficiente.

Le lingue di livello superiore fanno molto bene in questo, fornendo un accesso più facile a molte efficienti strutture dati pre-costruite e incoraggiando pratiche che ti aiuteranno a evitare codice inefficiente. Naturalmente, a volte possono anche semplificare la scrittura di un sacco di codice molto lento, quindi devi ancora conoscere la tua piattaforma.

Inoltre, C++ sta recuperando le funzionalità "nuove" (nota le virgolette) come i contenitori STL, i puntatori automatici, ecc. vedi la libreria boost, ad esempio. E a volte potresti scoprire che il modo più veloce per eseguire un compito richiede una tecnica come l'aritmetica del puntatore che è proibita in a linguaggio di livello superiore-anche se in genere ti permettono di chiamare una libreria scritta in una lingua che può implementarla come desiderato.

La cosa principale è conoscere la lingua che stai usando, l'API associata, cosa può fare e quali sono i suoi limiti.

Non lo so either...my I programmi Java sono sempre lenti. :- ) Non ho mai notato che i programmi C# sono particolarmente lenti, però.

Ecco un altro benchmark interessante, che puoi provare tu stesso sul tuo computer.

Confronta ASM, VC++, C#, Silverlight, applet Java, Javascript, Flash (AS3)

Roozz plugin velocità demo

Si noti che la velocità di javascript varia molto a seconda del browser che lo sta eseguendo. Lo stesso vale per Flash e Silverlight perché questi plugin vengono eseguiti nello stesso processo del browser di hosting. Ma il plugin Roozz eseguire standard .exe, che vengono eseguiti nel proprio processo, quindi la velocità non è influenzata dal browser di hosting.

È necessario definire "eseguire meglio di..". Beh, lo so, hai chiesto della velocità, ma non è tutto ciò che conta.

• Le macchine virtuali eseguono più overhead di runtime? Sì!
• Mangiano più memoria di lavoro? Sì!
• Hanno costi di avvio più elevati (inizializzazione del runtime e compilatore JIT) ? Sì!
• Richiedono un'enorme libreria installata? Sì!

E così via, il suo parziale, sì ;)

Con c# e Java paghi un prezzo per quello che get (codifica più veloce, gestione automatica della memoria, grande libreria e così via). Ma non hai molto spazio per contrattare sui dettagli: prendi il pacchetto completo o niente.

Anche se queste lingue possono ottimizzare del codice da eseguire più velocemente del codice compilato, l'intero approccio è (IMHO) inefficiente. Immaginate di guidare ogni giorno 5 miglia al vostro posto di lavoro, con un camion! Il suo comodo, ci si sente bene, si è al sicuro (estrema accartocciare zona) e dopo un passo sul gas per qualche tempo, sarà anche essere veloce come una macchina standard! Perché non abbiamo tutti un camion da guidare per andare al lavoro? ;)

In C++ ottieni quello per cui paghi, non di più, non di meno.

Citando Bjarne Stroustrup: "C++ è il mio linguaggio garbage collected preferito perché genera così poca spazzatura" testo del collegamento

Il codice eseguibile prodotto da un compilatore Java o c# non viene interpretato-viene compilato in codice nativo "just in time" (JIT). Quindi, la prima volta che il codice in un programma Java/C# viene rilevato durante l'esecuzione, c'è un sovraccarico in quanto il "runtime compiler" (aka JIT compiler) trasforma il codice byte (Java) o IL codice (C#) in istruzioni macchina native. Tuttavia, la volta successiva che il codice viene rilevato mentre l'applicazione è ancora in esecuzione, il codice nativo viene eseguito immediatamente. Questo spiega come alcuni programmi Java / C # sembrano inizialmente lenti, ma poi funzionano meglio più a lungo vengono eseguiti. Un buon esempio è un ASP.Net sito web. La prima volta che si accede al sito Web, potrebbe essere un po ' più lento in quanto il codice c# viene compilato in codice nativo dal compilatore JIT. Gli accessi successivi si traducono in un sito Web molto più veloce, a parte il caching lato server e client.

Alcune buone risposte qui sulla domanda specifica che hai chiesto. Vorrei fare un passo indietro e guardare il quadro generale.

Tieni presente che la percezione dell'utente della velocità del software che scrivi è influenzata da molti altri fattori oltre a quanto ottimizza codegen. Ecco alcuni esempi:

• La gestione manuale della memoria è difficile da fare correttamente (senza perdite), e ancora più difficile da fare in modo efficace (memoria libera subito dopo aver finito con esso). L'utilizzo di un GC è, in generale, più probabilità di produrre un programma che gestisce bene la memoria. Sei disposto a lavorare molto duramente e ritardare la consegna del tuo software, nel tentativo di superare il GC?

• Il mio c # è più facile da leggere e capire rispetto al mio C++. Ho anche più modi per convincermi che il mio codice c# funziona correttamente. Ciò significa che posso ottimizzare i miei algoritmi con meno rischi di introdurre bug (e agli utenti non piace il software che si blocca, anche se lo fa rapidamente!)

• Posso crea il mio software più velocemente in c # che in C++. Che libera il tempo per lavorare sulle prestazioni, e ancora consegnare il mio software in tempo.

• È più facile scrivere una buona interfaccia utente in c# rispetto a C++, quindi è più probabile che sia in grado di spingere il lavoro in background mentre l'interfaccia utente rimane reattiva, o di fornire progressi o hearbeat UI quando il programma deve bloccare per un po'. Questo non rende nulla più veloce, ma rende gli utenti più felici di aspettare.

Tutto quello che ho detto su C# è probabilmente vero per Java, non ho l'esperienza per dirlo con certezza.

Se sei un programmatore Java/C# che impara il C++, sarai tentato di continuare a pensare in termini di Java/C# e tradurre verbatim in sintassi C++. In tal caso, si ottengono solo i vantaggi menzionati in precedenza del codice nativo rispetto a interpreted/JIT. Per ottenere il massimo guadagno di prestazioni in C++ rispetto a Java / C#, devi imparare a pensare in C++ e progettare il codice in modo specifico per sfruttare i punti di forza di C++.

Per parafrasare Edsger Dijkstra: [la tua prima lingua] mutila la mente oltre recupero.
Per parafrasare Jeff Atwood : puoi scrivere [la tua prima lingua] in qualsiasi nuova lingua.

Una delle ottimizzazioni JIT più significative è l'inlining del metodo. Java può anche integrare metodi virtuali se può garantire la correttezza del runtime. Questo tipo di ottimizzazione di solito non può essere eseguita da compilatori statici standard perché richiede un'analisi dell'intero programma, che è difficile a causa della compilazione separata (al contrario, JIT ha tutto il programma disponibile). Metodo inlining migliora altre ottimizzazioni, dando blocchi di codice più grandi per ottimizzare.

Memoria standard anche l'allocazione in Java/C# è più veloce e la deallocazione (GC) non è molto più lenta, ma solo meno deterministica.

È improbabile che i linguaggi delle macchine virtuali superino i linguaggi compilati, ma possono avvicinarsi abbastanza da non importa, per (almeno) i seguenti motivi (sto parlando per Java qui dal momento che non ho mai fatto C#).

1/ Il Java Runtime Environment è solitamente in grado di rilevare pezzi di codice che vengono eseguiti frequentemente ed eseguire la compilazione just-in-time (JIT) di tali sezioni in modo che, in futuro, vengano eseguiti alla piena velocità di compilazione.

2 / Vaste porzioni di Java le librerie sono compilate in modo che, quando si chiama una funzione di libreria, si sta eseguendo il codice compilato, non interpretato. Puoi vedere il codice (in C) scaricando OpenJDK.

3/ A meno che tu non stia facendo calcoli massicci, la maggior parte del tempo in cui il tuo programma è in esecuzione, è in attesa di input da un umano molto lento (relativamente parlando).

4 / Poiché gran parte della convalida del bytecode Java viene eseguita al momento del caricamento della classe, il normale sovraccarico dei controlli di runtime è notevolmente ridotto.

5/ Nel peggiore dei casi, il codice ad alta intensità di prestazioni può essere estratto in un modulo compilato e chiamato da Java (vedi JNI) in modo che funzioni alla massima velocità.

In sintesi, il bytecode Java non supererà mai il linguaggio macchina nativo, ma ci sono modi per mitigare questo. Il grande vantaggio di Java (come lo vedo io) è l'ENORME libreria standard e la natura multipiattaforma.

Orion Adrian, permettetemi di invertire il tuo post per vedere quanto siano infondate le tue osservazioni, perché molto si può dire anche sul C++. E dire che il compilatore Java / C # ottimizza le funzioni vuote ti fa davvero sembrare non il mio esperto in ottimizzazione, perché a) perché un vero programma dovrebbe contenere funzioni vuote, ad eccezione del codice legacy davvero cattivo, b) che non è davvero un'ottimizzazione nera e sanguinante.

A parte quella frase, hai sbraitato sfacciatamente a proposito di puntatori, ma gli oggetti in Java e C # non funzionano fondamentalmente come puntatori C++? Non possono sovrapporsi? Non possono essere nulli? C (e la maggior parte delle implementazioni C++) ha la parola chiave restrict, entrambi hanno tipi di valore, C++ ha reference-to-value con garanzia non null. Cosa offrono Java e C#?

>>>>>>>>>>

In generale, C e C++ possono essere altrettanto veloci o più veloci perché il compilatore AOT a un compilatore che compila il codice prima della distribuzione, una volta per tutte, sulla tua memoria alta molti core build server can può effettuare ottimizzazioni che un programma compilato c# non può perché ha un sacco di tempo per farlo. Il compilatore può determinare se la macchina è Intel o AMD; Pentium 4, Core Solo o Core Duo; o se supporta SSE4, ecc., e se il tuo compilatore non supporta la spedizione di runtime, puoi risolverlo tu stesso distribuendo una manciata di binari specializzati.

Un programma c# viene comunemente compilato al momento dell'esecuzione in modo che funzioni decentemente bene su tutte le macchine, ma non lo è ottimizzato per quanto potrebbe essere per una singola configurazione (cioè processore, set di istruzioni, altro hardware), e deve passare un po ' di tempo prima. Caratteristiche come la fissione del ciclo, l'inversione del ciclo, la vettorizzazione automatica, l'ottimizzazione dell'intero programma, l'espansione del modello, l'IPO e molti altri, sono molto difficili da risolvere e completamente in un modo che non infastidisce l'utente finale.

Inoltre alcune funzionalità del linguaggio consentono al compilatore in C++ o C di formulare ipotesi codice che consente di ottimizzare alcune parti che non sono sicure per il compilatore Java/C#. Quando non si ha accesso all'ID di tipo completo di generici o a un flusso di programma garantito, ci sono molte ottimizzazioni che non sono sicure.

Anche C++ e C eseguono molte allocazioni di stack contemporaneamente con un solo incremento del registro, che sicuramente è più efficiente delle allocazioni Javas e C# per quanto riguarda il livello di astrazione tra il garbage collector e il codice.

Ora Non posso parlare per Java su questo punto successivo, ma so che i compilatori C++, ad esempio, rimuoveranno effettivamente metodi e chiamate di metodo quando saprà che il corpo del metodo è vuoto, eliminerà le sottoespressioni comuni, potrebbe provare a riprovare a trovare un utilizzo ottimale del registro, non impone il controllo dei limiti, autovettorizzerà loop e loop interni e invertirà l'interno all'esterno, sposta i condizionali dai loop, divide e disinserisce i loop. Espanderà std:: vector in zero nativo array overhead come faresti nel modo C. Farà ottimizzazioni inter procedurali. Costruirà i valori di ritorno direttamente sul sito del chiamante. Piegherà e propagherà le espressioni. Sarà riordinare i dati in un modo amichevole cache. Farà saltare threading. Ti consente di scrivere traccianti ray in fase di compilazione con un sovraccarico di runtime pari a zero. Renderà ottimizzazioni basate su grafici molto costose. Farà riduzione della forza, se sostituisce determinati codici con sintatticamente totalmente disuguali ma codice semanticamente equivalente (il vecchio "xor foo, foo" è solo l'ottimizzazione più semplice, anche se obsoleta di questo tipo). Se lo chiedi gentilmente, puoi omettere gli standard IEEE in virgola mobile e abilitare ancora più ottimizzazioni come il riordino degli operando in virgola mobile. Dopo aver massaggiato e massacrato il codice, potrebbe ripetere l'intero processo, perché spesso alcune ottimizzazioni gettano le basi per ottimizzazioni ancora più certe. Potrebbe anche riprovare con i parametri mischiati e vedere come altri punteggi variante nella sua classifica interna. E userà questo tipo di logica in tutto il tuo codice.

Quindi, come puoi vedere, ci sono molte ragioni per cui alcune implementazioni C++ o C saranno più veloci.

Ora tutto questo ha detto, molte ottimizzazioni possono essere fatte in C++ che spazzerà via tutto ciò che si potrebbe fare con c#, specialmente nel numero scricchiolio, realtime e close-to-metal regno, ma non esclusivamente lì. Non c'è nemmeno bisogno di toccare un solo puntatore a venire un lungo modo.

Quindi, a seconda di ciò che stai scrivendo, andrei con l'uno o l'altro. Ma se stai scrivendo qualcosa che non dipende dall'hardware (driver, videogiochi, ecc.), non mi preoccuperei delle prestazioni di C# (di nuovo non posso parlare di Java). Andra ' bene.

In generale, alcuni argomenti generalizzati potrebbero sembrare interessanti in post specifici, ma in genere non sembrano certamente credibili.

Ad ogni modo, per fare la pace: AOT è grande, come è JIT . L'unica risposta corretta può essere: dipende. E le persone intelligenti reali sanno che è possibile utilizzare il meglio di entrambi i mondi in ogni modo.

Accadrebbe solo se l'interprete Java sta producendo codice macchina che è in realtà migliore ottimizzato rispetto al codice macchina che il compilatore sta generando per il codice C++ che si sta scrivendo, al punto in cui il codice C++ è più lento di Java e il costo di interpretazione.

Tuttavia, le probabilità che ciò accada sono piuttosto basse, a meno che Java non abbia una libreria molto ben scritta e tu abbia la tua libreria C++ scritta male.

In realtà, C# non viene eseguito in una macchina virtuale come Java. IL è compilato in linguaggio assembly, che è codice interamente nativo e funziona alla stessa velocità del codice nativo. È possibile pre-JIT un'applicazione. NET che rimuove interamente il costo JIT e quindi si esegue codice interamente nativo.

Il rallentamento con. NET arriverà non perché il codice. NET è più lento, ma perché fa molto di più dietro le quinte per fare cose come garbage collect, check references, store cornici stack complete, ecc. Questo può essere molto potente e utile quando si costruiscono applicazioni, ma ha anche un costo. Nota che puoi fare tutte queste cose anche in un programma C++ (gran parte della funzionalità.NET di base è in realtà il codice. NET che puoi visualizzare in ROTOR). Tuttavia, se hai scritto a mano la stessa funzionalità, probabilmente finirai con un programma molto più lento poiché il runtime.NET è stato ottimizzato e finemente sintonizzato.

Detto questo, uno dei punti di forza del codice gestito è che può essere completamente verificabile, cioè. è possibile verificare che il codice non accederà mai alla memoria di un altro processo o eseguirà operazioni di annullamento prima di eseguirlo. Microsoft ha un prototipo di ricerca di un sistema operativo completamente gestito che ha sorprendentemente dimostrato che un ambiente gestito al 100% può effettivamente eseguire significativamente più velocemente di qualsiasi sistema operativo moderno sfruttando questa verifica per disattivare le funzionalità di sicurezza che non sono più necessarie dai programmi gestiti (stiamo parlando come 10x in alcuni casi). SE radio ha un grande episodio parlando di questo progetto.

In alcuni casi, il codice gestito può effettivamente essere più veloce rispetto al codice nativo. Ad esempio, gli algoritmi di garbage collection" mark-and-sweep " consentono ad ambienti come JRE o CLR di liberare un gran numero di oggetti di breve durata (di solito) in un singolo passaggio, dove la maggior parte degli oggetti heap C/C++ vengono liberati uno alla volta.

Da wikipedia :

Per molti scopi pratici, gli algoritmi ad alta intensità di allocazione/deallocazione implementati nei linguaggi garbage collected possono in realtà essere più veloce dei loro equivalenti usando l'allocazione heap manuale. Una delle ragioni principali di ciò è che il garbage collector consente al sistema di runtime di ammortizzare le operazioni di allocazione e deallocazione in modo potenzialmente vantaggioso.

Detto questo, ho scritto un sacco di c# e un sacco di C++, e ho eseguito un sacco di benchmark. Nella mia esperienza, C++ è molto più veloce di c#, in due modi: (1) se prendi del codice che hai scritto in C#, portalo in C++ il codice nativo tende ad essere più veloce. Quanto più veloce? Beh, varia molto, ma non è raro vedere un miglioramento della velocità del 100%. (2) In alcuni casi, la garbage collection può in modo massiccio rallentare un'applicazione gestita. Il CLR. NET fa un lavoro terribile con grandi heap (ad esempio, > 2 GB) e può finire per trascorrere molto tempo in GC-anche in applicazioni che hanno pochi-o addirittura nessun-oggetti di durata intermedia.

Naturalmente, nella maggior parte dei casi che ho incontrato, le lingue gestite sono abbastanza veloce, da un colpo lungo, e la manutenzione e codifica compromesso per le prestazioni extra di C++ non è semplicemente una buona.

Ecco un punto di riferimento interessante http://zi.fi/shootout /

In realtà la JVM HotSpot di Sun utilizza l'esecuzione in "modalità mista". Interpreta il bytecode del metodo finché non determina (di solito attraverso un contatore di qualche tipo) che un particolare blocco di codice (metodo, ciclo, blocco try-catch, ecc.) sta per essere eseguito molto, quindi JIT lo compila. Il tempo necessario per compilare un metodo JIT richiede spesso più tempo rispetto a se il metodo dovesse essere interpretato se si tratta di un metodo eseguito raramente. Le prestazioni sono solitamente più elevate per la" modalità mista " perché la JVM non spreca tempo JITing codice che è raramente, se mai, eseguito. C # e. NET non lo fanno. . NET JITs tutto ciò che, spesso, perde tempo.

Vai a leggere su HP Labs' Dynamo , un interprete per PA-8000 che gira su PA-8000, e spesso esegue programmi più velocemente di quanto non facciano in modo nativo. Allora non sembrerà affatto sorprendente!

Non considerarlo come un "passaggio intermedio": l'esecuzione di un programma comporta già molti altri passaggi, in qualsiasi lingua.

Spesso si riduce a:

• I programmi hanno punti caldi, quindi anche se sei più lento a eseguire il 95% del corpo di codice che devi eseguire, puoi ancora essere prestazioni-competitivo se sei più veloce al caldo 5%

• Un HLL sa di più sul tuo intento di un LLL come C / C++, e quindi può generare codice più ottimizzato (OCaml ha ancora di più, e in pratica è spesso ancora più veloce)

• Un compilatore JIT ha molte informazioni che un compilatore statico non ha (come i dati effettivi che hai questa volta)

• Un compilatore JIT può eseguire ottimizzazioni in fase di esecuzione a cui i linker tradizionali non sono realmente autorizzati do (come riordinare i rami in modo che il caso comune sia piatto o inlining delle chiamate alla libreria)

Tutto sommato, C/C++ sono linguaggi piuttosto scadenti per le prestazioni: ci sono relativamente poche informazioni sui tuoi tipi di dati, nessuna informazione sui tuoi dati e nessun runtime dinamico per consentire molto in termini di ottimizzazione del runtime.

Si potrebbero ottenere brevi raffiche quando Java o CLR sono più veloci di C++, ma nel complesso le prestazioni sono peggiori per la vita dell'applicazione: vedi www.codeproject.com/KB/dotnet/RuntimePerformance.aspx per alcuni risultati per quello.

Ecco la risposta da Cliff Click: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain

La mia comprensione è che C/C++ produce codice nativo da eseguire su una particolare architettura della macchina. Al contrario, linguaggi come Java e C# vengono eseguiti su una macchina virtuale che astrae l'architettura nativa. Logicamente sembrerebbe impossibile per Java o C # abbinare la velocità di C++ a causa di questo passaggio intermedio, tuttavia mi è stato detto che gli ultimi compilatori ("hot spot") possono raggiungere questa velocità o addirittura superarla.

Questo è illogico. L'uso di un la rappresentazione intermedia non degrada intrinsecamente le prestazioni. Ad esempio, llvm-gcc compila C e C++ tramite LLVM IR (che è una macchina virtuale a registro infinito) in codice nativo e raggiunge prestazioni eccellenti (spesso battendo GCC).

Forse questa è più una domanda del compilatore che una domanda linguistica, ma qualcuno può spiegare in inglese semplice come sia possibile che uno di questi linguaggi di macchina virtuale funzioni meglio di una lingua madre?

Qui sono alcuni esempi:

• System.Reflection.Emit su.NET) in modo da poter compilare il codice generato al volo in linguaggi come c# e F# ma deve ricorrere alla scrittura di un interprete relativamente lento in C o C++. Ad esempio, per implementare espressioni regolari.

• Le parti della macchina virtuale (ad esempio la barriera di scrittura e l'allocatore) sono spesso scritte in assembler codificato a mano perché C e C++ non generano codice abbastanza veloce. Se un programma sottolinea queste parti di un sistema, potrebbe in teoria sovraperformare tutto ciò che può essere scritto in C o C++.

• Il collegamento dinamico del codice nativo richiede la conformità a un ABI che può impedire le prestazioni e ovviare all'ottimizzazione dell'intero programma, mentre il collegamento è in genere differito sulle macchine virtuali e può beneficiare delle ottimizzazioni dell'intero programma (come i generici reificati di.NET).

Vorrei anche affrontare alcuni problemi con paercebal risposta altamente upvoted sopra (perché qualcuno continua a cancellare i miei commenti sulla sua risposta) che presenta una vista polarizzata in modo controproducente:

L'elaborazione del codice verrà eseguita al momento della compilazione...

Quindi la metaprogrammazione del modello funziona solo se il programma è disponibile in fase di compilazione, il che spesso non è il caso, ad esempio è impossibile scrivere una libreria di espressioni regolari competitive in vanilla C++ perché non è in grado di generare codice in fase di esecuzione (un aspetto importante della metaprogrammazione).

...giocare con i tipi è fatto in fase di compilazione...l'equivalente in Java o C # è doloroso al massimo da scrivere, e sarà sempre più lento e risolto in fase di runtime anche quando i tipi sono noti in fase di compilazione.

In c#, ciò vale solo per i tipi di riferimento e non per i tipi di valore.

Indipendentemente dall'ottimizzazione JIT, nulla andrà veloce come l'accesso diretto del puntatore alla memoria...se si dispone di dati contigui in memoria, accedendo tramite puntatori C++ (cioè puntatori C... Diamo a Cesare il suo dovuto) andrà volte più velocemente che in Java / C#.

Le persone hanno osservato Java che batte C++ sul test SOR dal benchmark SciMark2 proprio perché i puntatori impediscono le ottimizzazioni correlate all'aliasing.

Vale anche la pena notare che. NET digita la specializzazione dei generici su librerie collegate dinamicamente dopo il collegamento, mentre C++ non può perché i modelli devono essere risolti prima collegare. E ovviamente il grande vantaggio che i generici hanno sui modelli è messaggi di errore comprensibili.

Oltre a ciò che alcuni altri hanno detto, dalla mia comprensione.NET e Java sono migliori nell'allocazione della memoria. Ad esempio, possono compattare la memoria quando viene frammentata mentre C++ non può (in modo nativo, ma può se si utilizza un garbage collector intelligente).

Per qualsiasi cosa che abbia bisogno di molta velocità, la JVM chiama solo un'implementazione C++, quindi è una domanda più su quanto siano buone le loro librerie che su quanto sia buona la JVM per la maggior parte delle cose relative al sistema operativo. La garbage collection taglia la memoria a metà, ma l'utilizzo di alcune delle funzionalità STL e Boost più elaborate avrà lo stesso effetto ma con molte volte il potenziale di bug.

Se stai solo usando le librerie C++ e molte delle sue funzionalità di alto livello in un grande progetto con molte classi probabilmente finirai più lento rispetto all'utilizzo di una JVM. Tranne molto più soggetto a errori.

Tuttavia, il vantaggio di C++ è che ti permette di ottimizzare te stesso, altrimenti sei bloccato con ciò che fa il compilatore/jvm. Se crei i tuoi contenitori, scrivi la tua gestione della memoria allineata, usa SIMD e passa all'assemblaggio qua e là, puoi accelerare almeno 2x-4x volte su ciò che la maggior parte dei compilatori C++ farà da soli. Per alcune operazioni, 16x-32x. Questo sta usando gli stessi algoritmi, se usi meglio algoritmi e parallelizzare, gli aumenti possono essere drammatici, a volte migliaia di volte più veloce che i metodi comunemente usati.

Lo guardo da alcuni punti diversi.

1. Dato tempo e risorse infinite, il codice gestito o non gestito sarà più veloce? Chiaramente, la risposta è che il codice non gestito può sempre legare almeno il codice gestito in questo aspetto, come nel peggiore dei casi, si dovrebbe semplicemente codificare la soluzione di codice gestito.
2. Se prendi un programma in una lingua e lo traduci direttamente in un'altra, quanto peggio funzionerà? Probabilmente molto, per qualsiasi due lingue. La maggior parte delle lingue richiedono diverse ottimizzazioni e hanno diversi trucchi. Micro-prestazioni è spesso molto di conoscere questi dettagli.
3. Dato il tempo e le risorse finite, quale delle due lingue produrrà un risultato migliore? Questa è la domanda più interessante, poiché mentre un linguaggio gestito può produrre codice leggermente più lento (dato un programma ragionevolmente scritto per quella lingua), quella versione verrà probabilmente eseguita prima, consentendo più tempo dedicato all'ottimizzazione.

Una risposta molto breve: dato un budget fisso otterrai un'applicazione java più performante di un'applicazione C++ (considerazioni sul ROI) Inoltre la piattaforma Java ha profiler più decenti, che ti aiuteranno a individuare i tuoi hotspot più rapidamente