Perché C è così veloce e perché altre lingue non sono così veloci o più veloci? [chiuso]

Nell'ascolto del podcast StackOverflow, il jab continua a pensare che "veri programmatori" scrivano in C e che C è molto più veloce perché è "vicino alla macchina". Lasciando la precedente affermazione per un altro post, cosa c'è di speciale in C che gli permette di essere più veloce di altre lingue? O in altri termini: cosa impedisce ad altre lingue di essere in grado di compilare in binario che funziona alla stessa velocità di C?

Non c'è molto di speciale in C. Questo è uno dei motivi per cui è veloce.

Lingue più recenti che supportano la garbage collection , la digitazione dinamica e altre funzionalità che semplificano la scrittura dei programmi da parte del programmatore.

Il problema è che c'è un sovraccarico di elaborazione aggiuntivo che peggiorerà le prestazioni dell'applicazione. C non ha nulla di tutto ciò, il che significa che non c'è sovraccarico, ma ciò significa che il programmatore deve essere in grado di allocare memoria e liberarli per evitare perdite di memoria , e deve occuparsi della tipizzazione statica delle variabili.

Detto questo, molti linguaggi e piattaforme, come Java (con la sua Java Virtual Machine ) e .NET (con il suo Common Language Runtime) hanno migliorato le prestazioni nel corso degli anni con strumenti come la compilazione just-in-time che produce codice macchina nativo da bytecode per ottenere prestazioni più elevate.

C'è un trade off che i designer C hanno fatto. Vale a dire, hanno preso la decisione di mettere la velocità al di sopra della sicurezza. C no

• Controlla i limiti dell'indice dell'array
• Verifica valori variabili non inizializzati
• Verificare la presenza di perdite di memoria
• Controlla la dereferenza del puntatore null

Quando si esegue l'indicizzazione in un array, in Java sono necessarie alcune chiamate di metodo nella macchina virtuale, il controllo associato e altri controlli di integrità. Questo è valido e assolutamente valido , perché aggiunge sicurezza dove è dovuto. Ma in C, anche le cose piuttosto banali non vengono messe in sicurezza. Ad esempio, C non richiede memcpy per verificare se le regioni da copiare si sovrappongono. E ' non è stato progettato come un linguaggio per programmare una grande applicazione aziendale.

Ma queste decisioni di progettazione sono non insetti nel linguaggio C . Sono progettate, in quanto consentono a compilatori e scrittori di biblioteche di ottenere tutte le prestazioni dal computer. Ecco lo spirito di C come spiega il documento C Rationale :

Il codice C può essere non portatile. Sebbene si sia sforzato di offrire ai programmatori l'opportunità di scrivere programmi veramente portatili, il Comitato non ha voluto forzare i programmatori a scrivere in modo portabile, per impedire l'uso di C come `` assemblatore di alto livello '': la capacità di scrivere su macchine specifiche il codice è uno dei punti di forza di C.

Mantenere lo spirito di C. Il Comitato ha mantenuto come obiettivo principale la conservazione dello spirito tradizionale di C. Ci sono molte sfaccettature dello spirito di C, ma l'essenza è un sentimento comunitario dei principi sottostanti su cui si basa il linguaggio C. Alcune delle sfaccettature dello spirito di C possono essere riassunte in frasi come

• Fidati del programmatore.
• Non impedire al programmatore di fare ciò che deve essere fatto.
• Mantieni la lingua piccola e semplice.
• Fornire un solo modo per eseguire un'operazione.
• Renderlo veloce, anche se non è garantito che sia portatile.

L'ultimo proverbio ha bisogno di una piccola spiegazione. Il potenziale per un'efficace generazione di codice è uno dei punti di forza più importanti di C. Per aiutare a garantire che non si verifichi un'esplosione di codice per quella che sembra un'operazione molto semplice, molte operazioni sono definite come l'hardware della macchina target fa piuttosto che da una regola astratta generale. Un esempio di questa volontà di convivere con ciò che fa la macchina può essere visto nelle regole che regolano l'ampliamento degli oggetti char da usare nelle espressioni: se i valori degli oggetti char si allargano a quantità con o senza segno, in genere dipende da quale operazione di byte è maggiore efficiente sulla macchina target.

Se passi un mese a costruire qualcosa in C che gira in 0,05 secondi, e io passo un giorno a scrivere la stessa cosa in Java, e gira in 0,10 secondi, allora C è davvero più veloce?

Ma per rispondere alla tua domanda, il codice C ben scritto sarà generalmente più veloce del codice ben scritto in altre lingue perché parte della scrittura del codice C "bene" include l'ottimizzazione manuale a livello di macchina.

Sebbene i compilatori siano davvero molto intelligenti, non sono ancora in grado di elaborare in modo creativo codice che compete con gli algoritmi massaggiati a mano (supponendo che le "mani" appartengano a un buon programmatore C).

Modificare:

Molti commenti sono sulla falsariga di "scrivo in C e non penso alle ottimizzazioni".

Ma per fare un esempio specifico da questo post :

In Delphi potrei scrivere questo:

function RemoveAllAFromB(a, b: string): string;
var
  before, after :string;
begin
  Result := b;
  if 0 < Pos(a,b) then begin
    before := Copy(b,1,Pos(a,b)-Length(a));
    after := Copy(b,Pos(a,b)+Length(a),Length(b));
    Result := before + after;
    Result := RemoveAllAFromB(a,Result);  //recursive
  end;
end;

e in CI scrivi questo:

char *s1, *s2, *result; /* original strings and the result string */
int len1, len2; /* lengths of the strings */
for (i = 0; i < len1; i++) {
   for (j = 0; j < len2; j++) {
     if (s1[i] == s2[j]) {
       break;
     }
   }
   if (j == len2) {  /* s1[i] is not found in s2 */
     *result = s1[i]; 
     result++; /* assuming your result array is long enough */
   }
}

Ma quante ottimizzazioni ci sono nella versione C? Prendiamo molte decisioni sull'implementazione a cui non penso nella versione di Delphi. Come viene implementata una stringa? A Delfi non lo vedo. In C, ho deciso che sarà un puntatore a un array di numeri interi ASCII, che chiamiamo caratteri. In C, testiamo l'esistenza del personaggio una alla volta. In Delphi, utilizzo Pos.

E questo è solo un piccolo esempio. In un programma di grandi dimensioni, un programmatore C deve prendere questo tipo di decisioni di basso livello con poche righe di codice. Aggiunge un eseguibile realizzato a mano e ottimizzato a mano.

Non ho visto già, così lo dirò: C tende ad essere più veloce perché quasi tutto il resto è scritto in C .

Java è costruito su C, Python è costruito su C (o Java, o .NET, ecc.), Perl è, ecc. Il sistema operativo è scritto in C, le macchine virtuali sono scritte in C, i compilatori sono scritti in C, gli interpreti sono scritti in C. Alcune cose sono ancora scritte in linguaggio Assembly, che tende ad essere ancora più veloce. Sempre più cose vengono scritte in qualcos'altro, che è esso stesso scritto in C.

Ogni istruzione scritta in altre lingue (non in Assembly) viene in genere implementata come diverse istruzioni in C, che vengono compilate in codice macchina nativo. Dato che quelle altre lingue tendono ad esistere al fine di ottenere un livello di astrazione più elevato rispetto a C, quelle dichiarazioni extra richieste in C tendono a concentrarsi sull'aggiunta di sicurezza, aggiunta di complessità e gestione degli errori. Quelle sono spesso cose buone, ma hanno un costo , e i suoi nomi sono velocità e dimensioni .

Personalmente, ho scritto letteralmente in dozzine di lingue che coprono la maggior parte dello spettro disponibile e personalmente ho cercato la magia a cui accenni:

Come posso avere la mia torta e anche mangiarla? Come posso giocare con le astrazioni di alto livello nella mia lingua preferita, quindi passare alla nitidezza di C per la velocità?

Dopo un paio d'anni di ricerche, la mia risposta è Python (su C). Potresti dare un'occhiata. A proposito, puoi anche scorrere verso Assembly anche da Python (con qualche piccolo aiuto da una libreria speciale).

D'altra parte, il codice errato può essere scritto in qualsiasi lingua . Pertanto, il codice C (o Assembly) non è automaticamente più veloce. Allo stesso modo, alcuni trucchi per l'ottimizzazione possono portare porzioni di codice linguistico di livello superiore vicino al livello prestazionale di C. crudo. Ma, per la maggior parte delle applicazioni, il programma trascorre la maggior parte del tempo in attesa di persone o hardware, quindi la differenza non ha importanza.

Godere.

Ci sono molte domande lì dentro - principalmente quelle a cui non sono qualificato per rispondere. Ma per quest'ultimo:

cosa impedisce ad altre lingue di essere in grado di compilare in binario che gira veloce quanto C?

In una parola, astrazione.

C dista solo uno o 2 livelli di astrazione dal linguaggio macchina. Java e i linguaggi .Net sono ad almeno 3 livelli di astrazione dall'assemblatore. Non sono sicuro di Python e Ruby.

In genere, più programmatore gioca (tipi di dati complessi, ecc.), Più si viene dal linguaggio automatico e più deve essere eseguita la traduzione.

Vado di qua e di là ma questo è l'essenza di base.

Aggiornamento ------- Ci sono alcuni buoni commenti su questo post con maggiori dettagli.

Non è tanto che C è veloce in quanto il modello di costo di C è trasparente . Se un programma C è lento, è lento in modo ovvio: eseguendo molte istruzioni. Rispetto al costo delle operazioni in C, le operazioni di alto livello sugli oggetti (in particolare la riflessione) o le stringhe possono avere costi non ovvi.

Due lingue che generalmente si compilano in binari che sono veloci quanto C sono Standard ML (usando il compilatore MLton ) e Objective Caml . Se dai un'occhiata al gioco dei benchmark , scoprirai che per alcuni benchmark, come gli alberi binari, la versione OCaml è più veloce di C. (Non ho trovato alcuna voce MLton.) Ma non prendere lo shootout troppo sul serio; è, come si suol dire, un gioco, i risultati spesso riflettono quanto sforzo le persone hanno fatto nel mettere a punto il codice.

C non è sempre più veloce.

C è più lento di, ad esempio, Modern Fortran.

C è spesso più lento di Java per alcune cose. (Soprattutto dopo che il compilatore JIT ha provato il tuo codice)

C consente che si verifichi un alias puntatore, il che significa che alcune buone ottimizzazioni non sono possibili. Soprattutto quando si hanno più unità di esecuzione, ciò provoca blocchi di recupero dati. Ow.

Il presupposto che l'aritmetica del puntatore funzioni davvero causa prestazioni lenta e gonfie su alcune famiglie di CPU (in particolare PIC!).

Fondamentalmente, quando ottieni un'unità vettoriale o un compilatore in parallelo, C puzza e Fortran moderno funziona più velocemente.

Trucchi del programmatore C come il thunking (modifica al volo dell'eseguibile) causano blocchi di precaricamento della CPU.

Hai la deriva?

E il nostro buon amico, l'x86, esegue un set di istruzioni che oggigiorno ha poca relazione con l'architettura della CPU attuale. Registri ombra, ottimizzatori di caricamento del carico, tutto nella CPU. Quindi C è vicino al metallo virtuale. Il vero metal, Intel non ti fa vedere. (Storicamente le CPU VLIW erano un po 'un busto, quindi, forse non è poi così male.)

Se si programma in C su un DSP ad alte prestazioni (forse un DSP TI?), Il compilatore deve fare alcune cose complicate per srotolare il C tra le diverse unità di esecuzione parallele. Quindi in quel caso C non è vicino al metal, ma è vicino al compilatore, che farà l'ottimizzazione dell'intero programma. Strano.

Infine, alcune CPU (www.ajile.com) eseguono i bytecode Java nell'hardware. C sarebbe un PITA da usare su quella CPU.

cosa impedisce ad altre lingue di essere in grado di compilare in binario che gira veloce quanto C?

Niente. I linguaggi moderni come i linguaggi Java o .NET sono più orientati alla produttività del programmatore piuttosto che alle prestazioni. L'hardware costa poco oggi. Anche la compilazione per la rappresentazione intermedia offre molti bonus come sicurezza, portabilità, ecc. .NET CLR può sfruttare diversi hardware, ad esempio non è necessario ottimizzare / ricompilare manualmente il programma per utilizzare il set di istruzioni SSE.

I principali fattori sono che si tratta di un linguaggio tipicamente statico e compilato in codice macchina. Inoltre, poiché è un linguaggio di basso livello, generalmente non fa nulla a cui non lo dici.

Questi sono alcuni altri fattori che vengono in mente.

• Le variabili non vengono inizializzate automaticamente
• Nessun limite di controllo sugli array
• Manipolazione puntatore non selezionata
• Nessun controllo di overflow di numeri interi
• Variabili di tipo statico
• Le chiamate di funzione sono statiche (a meno che non si utilizzino i puntatori di funzione)
• Gli autori di compilatori hanno avuto molto tempo per migliorare il codice di ottimizzazione. Inoltre, le persone programmano in C allo scopo di ottenere le migliori prestazioni, quindi c'è la pressione per ottimizzare il codice.
• Parti delle specifiche del linguaggio sono definite dall'implementazione, quindi i compilatori sono liberi di fare le cose nel modo più ottimale

La maggior parte dei linguaggi di tipo statico potrebbero essere compilati altrettanto velocemente o più velocemente di C, soprattutto se possono fare ipotesi che C non può a causa dell'aliasing del puntatore, ecc.

Immagino che hai dimenticato che anche la lingua dell'Assemblea è una lingua :)

Ma seriamente, i programmi C sono più veloci solo quando il programmatore sa cosa sta facendo. È possibile scrivere facilmente un programma C che viene eseguito più lentamente rispetto ai programmi scritti in altre lingue che svolgono lo stesso lavoro.

Il motivo per cui C è più veloce è perché è progettato in questo modo. Ti consente di fare molte cose di "livello inferiore" che aiutano il compilatore a ottimizzare il codice. Oppure, dovremmo dire, il programmatore è responsabile dell'ottimizzazione del codice. Ma è spesso piuttosto complicato e soggetto a errori.

Altre lingue, come altre già menzionate, si concentrano maggiormente sulla produttività del programmatore. Si ritiene comunemente che il tempo del programmatore sia molto più costoso del tempo della macchina (anche ai vecchi tempi). Quindi ha molto senso ridurre al minimo il tempo che i programmatori impiegano per scrivere e eseguire il debug dei programmi anziché il tempo di esecuzione dei programmi. Per fare ciò, sacrificherai un po 'ciò che puoi fare per rendere il programma più veloce perché molte cose sono automatizzate.

Per la maggior parte, ogni istruzione C corrisponde a pochissime istruzioni assembler. Stai essenzialmente scrivendo un codice macchina di livello superiore, quindi hai il controllo su quasi tutto ciò che fa il processore. Molti altri linguaggi compilati, come C ++, hanno molte semplici istruzioni che possono trasformarsi in molto più codice di quanto pensi (funzioni virtuali, costruttori di copie, ecc.) E i linguaggi interpretati come Java o Ruby hanno un altro livello di istruzioni che non vedi mai: la macchina virtuale o l'interprete.

So che molte persone l'hanno detto in modo lungo e tortuoso, ma:

C è più veloce perché fa di meno (per te).

Il C ++ è in media più veloce (com'era inizialmente, in gran parte un superset di C, anche se ci sono alcune differenze). Tuttavia, per benchmark specifici, esiste spesso un'altra lingua che è più veloce.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/

fannjuch-redux è stato il più veloce a Scala

n-bodyed fastaerano più veloci in Ada.

spectral-norm è stato il più veloce a Fortran.

reverse-complement, mandelbrotE pidigitssono stati più veloci in ATS.

regex-dna è stato il più veloce in JavaScript.

chameneou-redux è stato il più veloce è Java 7.

thread-ring è stato il più veloce ad Haskell.

Il resto dei benchmark sono stati i più veloci in C o C ++.

Molte di queste risposte forniscono validi motivi per cui C è o non è più veloce (in generale o in scenari specifici). È innegabile che:

• Molte altre lingue forniscono funzionalità automatiche che diamo per scontate. Il controllo dei limiti, il controllo del tipo di runtime e la gestione automatica della memoria, ad esempio, non sono gratuiti. Ce ne sono almeno alcuni costi associati a queste funzionalità, alle quali potremmo non pensare, o addirittura realizzare, durante la scrittura di codice che utilizza queste funzionalità.
• Il passaggio dall'origine alla macchina spesso non è diretto in altre lingue come in C.
• OTOH, dire che il codice C compilato viene eseguito più velocemente di altri codici scritti in altre lingue è una generalizzazione che non è sempre vera. I contro-esempi sono facili da trovare (o escogitare).

Ciò nonostante, c'è qualcos'altro che ho notato che, penso, influenza le prestazioni comparative della C rispetto a molte altre lingue più di qualsiasi altro fattore. Per dire:

Altre lingue spesso semplificano la scrittura di codice che viene eseguito più lentamente. Spesso è persino incoraggiato dalle filosofie progettuali del linguaggio. Corollario: un programmatore C ha maggiori probabilità di scrivere codice che non esegue operazioni non necessarie.

Ad esempio, considera un semplice programma Windows in cui viene creata una singola finestra principale. La versione AC popolerebbe una WNDCLASS[EX]struttura a cui verrebbe passato RegisterClass[Ex], quindi chiamerebbe CreateWindow[Ex]ed entrava in un ciclo di messaggi. Segue un codice altamente semplificato e abbreviato:

WNDCLASS wc;
MSG      msg;

wc.style         = 0;
wc.lpfnWndProc   = &WndProc;
wc.cbClsExtra    = 0;
wc.cbWndExtra    = 0;
wc.hInstance     = hInstance;
wc.hIcon         = NULL;
wc.hCursor       = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1);
wc.lpszMenuName  = NULL;
wc.lpszClassName = "MainWndCls";

RegisterClass(&wc);

CreateWindow("MainWndCls", "", WS_OVERLAPPEDWINDOW | WS_VISIBLE,
             CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

while(GetMessage(&msg, NULL, 0, 0)){
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

Un programma equivalente in C # potrebbe essere solo una riga di codice:

Application.Run(new Form());

Questa riga di codice fornisce tutte le funzionalità di quasi 20 righe di codice C e aggiunge alcune cose che abbiamo lasciato fuori, come il controllo degli errori. La libreria più ricca e più completa (rispetto a quelle utilizzate in un tipico progetto C) ha fatto molto lavoro per noi, liberando il nostro tempo per scrivere molti più frammenti di codice che ci sembrano brevi ma comportano molti passaggi dietro le quinte.

Ma una ricca libreria che consente di gonfiare il codice in modo semplice e rapido non è proprio il mio punto di vista. Il mio punto è più evidente quando inizi a esaminare cosa succede effettivamente quando il nostro piccolo one-liner esegue effettivamente. Per un po 'di divertimento, abilita l'accesso ai sorgenti .NET in Visual Studio 2008 o versioni successive e passa alla semplice riga precedente sopra. Una delle piccole gemme divertenti che incontrerai è questo commento nel getter per Control.CreateParams:

// In a typical control this is accessed ten times to create and show a control.
// It is a net memory savings, then, to maintain a copy on control.
// 
if (createParams == null) {
    createParams = new CreateParams(); 
} 

Dieci volte . Le informazioni all'incirca equivalenti alla somma di ciò che è archiviato in una WNDCLASSEXstruttura e ciò a cui CreateWindowExviene passato viene recuperato dalla Controlclasse dieci volte prima di essere archiviato in una WNDCLASSEXstruttura e trasmesso a RegisterClassExeCreateWindowEx .

Tutto sommato, il numero di istruzioni eseguite per eseguire questo compito di base è di 2-3 ordini di grandezza in più in C # che in C. Parte di ciò è dovuta all'uso di una libreria ricca di funzionalità, che è necessariamente generalizzata, contro il nostro semplice codice C che fa esattamente ciò di cui abbiamo bisogno e niente di più. Ma in parte è dovuto al fatto che la natura modulare e orientata agli oggetti del framework .NET si presta a molte ripetizioni di esecuzione che spesso vengono evitate da un approccio procedurale.

Non sto cercando di scegliere C # o .NET Framework. Né sto dicendo che la modularizzazione, la generalizzazione, le funzionalità di libreria / linguaggio, OOP, ecc. Siano cose cattive . Ero solito fare la maggior parte del mio sviluppo in C, in seguito in C ++ e ultimamente in C #. Allo stesso modo, prima di C, ho usato principalmente il montaggio. E ad ogni passo "più alto" la mia lingua va, scrivo programmi migliori, più gestibili, più robusti in meno tempo. Tendono, tuttavia, a eseguire un po 'più lentamente.

Non credo che nessuno abbia menzionato il fatto che sono stati fatti molti più sforzi nei compilatori C rispetto a qualsiasi altro compilatore, con l'eccezione di Java.

C è estremamente ottimizzabile per molte delle ragioni già indicate, più di quasi qualsiasi altra lingua. Quindi, se la stessa quantità di sforzo viene impiegata in altri compilatori di lingue, probabilmente C continuerà ad essere in cima.

Penso che ci sia almeno un linguaggio candidato che con sforzo potrebbe essere ottimizzato meglio di C e quindi potremmo vedere implementazioni che producono file binari più veloci. Sto pensando a digital mars D perché il creatore si è preso cura di costruire un linguaggio che potrebbe essere potenzialmente ottimizzato meglio di C. Potrebbero esserci altre lingue che hanno questa possibilità. Tuttavia, non riesco a immaginare che nessun linguaggio avrà compilatori più di qualche percento più veloci dei migliori compilatori C. Mi piacerebbe sbagliarmi.

Penso che il vero "frutto basso appeso" sarà nelle lingue che sono progettate per essere FACILE da ottimizzare per gli esseri umani. Un programmatore esperto può rendere più veloce qualsiasi lingua, ma a volte devi fare cose ridicole o usare costrutti innaturali per farlo accadere. Sebbene ci vorrà sempre uno sforzo, un buon linguaggio dovrebbe produrre un codice relativamente veloce senza dover ossessionare esattamente come è scritto il programma.

È anche importante (almeno per me) che il codice del caso peggiore tenda ad essere veloce. Esistono numerose "prove" sul web che Java è più veloce o più veloce di C, ma che si basa su esempi di raccolta delle ciliegie. Non sono un grande fan di C, ma so che QUALUNQUE cosa scrivo in C funzionerà bene. Con Java funzionerà "probabilmente" entro il 15% della velocità, di solito entro il 25% ma in alcuni casi può essere molto peggio. Tutti i casi in cui è altrettanto veloce o entro un paio di percento sono generalmente dovuti alla maggior parte del tempo trascorso nel codice della libreria che è fortemente ottimizzato C comunque.

Questo è in realtà un po 'una menzogna perpetuata. Mentre è vero che i programmi C sono spesso più veloci, non è sempre così, specialmente se il programmatore C non è molto bravo.

Un grande buco evidente che le persone tendono a dimenticare è quando il programma deve bloccare una sorta di IO, come l'input dell'utente in qualsiasi programma della GUI. In questi casi, non importa quale lingua utilizzi poiché sei limitato dalla velocità con cui i dati possono arrivare piuttosto che dalla velocità con cui puoi elaborarli. In questo caso, non importa molto se stai usando C, Java, C # o persino Perl; non puoi andare più veloce di quanto possano entrare i dati.

L'altra cosa importante è che l'uso della garbage collection e non l'utilizzo di puntatori adeguati consente alla macchina virtuale di rendere non disponibili altre ottimizzazioni in altre lingue. Ad esempio, JVM è in grado di spostare oggetti sull'heap per deframmentarlo. Ciò rende le allocazioni future molto più veloci poiché l'indice successivo può essere semplicemente utilizzato anziché cercarlo in una tabella. Inoltre, le moderne JVM non devono realmente dislocare la memoria; invece, spostano semplicemente gli oggetti dal vivo quando GC e la memoria esaurita dagli oggetti morti viene recuperata essenzialmente gratuitamente.

Questo porta anche un punto interessante su C e ancora di più in C ++. C'è una sorta di filosofia del design di "Se non ne hai bisogno, non paghi per questo". Il problema è che se lo vuoi, finisci per pagare per il naso. Ad esempio, l'implementazione della vtable in Java tende ad essere molto migliore delle implementazioni C ++, quindi le chiamate di funzione virtuali sono molto più veloci. D'altra parte, non hai altra scelta che utilizzare funzioni virtuali in Java e costano ancora qualcosa, ma in programmi che usano molte funzioni virtuali, il costo ridotto si somma.

Non si tratta tanto del linguaggio quanto degli strumenti e delle librerie. Le librerie e i compilatori disponibili per C sono molto più vecchi di quelli per le lingue più recenti. Potresti pensare che questo li renderebbe più lenti, ma al contrario.

Queste librerie sono state scritte in un momento in cui la potenza di elaborazione e la memoria erano un premio. Hanno dovuto essere scritti in modo molto efficiente per funzionare affatto. Gli sviluppatori di compilatori C hanno anche avuto molto tempo per lavorare su tutti i tipi di ottimizzazioni intelligenti per diversi processori. La maturità e l'ampia adozione di C offrono un vantaggio significativo rispetto ad altre lingue della stessa età. Offre inoltre a C un vantaggio in termini di velocità rispetto a strumenti più recenti che non enfatizzano le prestazioni grezze tanto quanto C doveva.

La mancanza di astrazione è ciò che rende C più veloce. Se scrivi un'istruzione di output sai esattamente cosa sta succedendo. Se scrivi un'istruzione di output in Java, viene compilata in un file di classe che viene quindi eseguito su una macchina virtuale introducendo un livello di astrazione. La mancanza di funzionalità orientate agli oggetti come parte del linguaggio aumenta anche la sua velocità rispetto a meno codice generato. Se usi C come linguaggio orientato agli oggetti, stai facendo tutto il codice per cose come classi, inharitence, ecc. Ciò significa piuttosto fare qualcosa di abbastanza generalizzato per tutti con la quantità di codice e la penalità delle prestazioni che richiede solo di scrivere quello che ti serve per fare il lavoro.

Incredibile vedere il vecchio "C / C ++ deve essere più veloce di Java perché Java è interpretato" il mito è ancora vivo e vegeto. Ci sono articoli che vanno indietro di alcuni anni , oltre a quelli più recenti , che spiegano con concetti o misurazioni perché semplicemente non è sempre così .

Le attuali implementazioni di macchine virtuali (e non solo la JVM, tra l'altro) possono sfruttare le informazioni raccolte durante l'esecuzione del programma per ottimizzare dinamicamente il codice durante l'esecuzione, utilizzando una varietà di tecniche:

• rendere frequenti i metodi al codice macchina,
• allineando piccoli metodi,
• regolazione del bloccaggio

e una varietà di altre regolazioni basate sulla conoscenza di ciò che il codice sta effettivamente facendo e sulle caratteristiche effettive dell'ambiente in cui è in esecuzione.

Il codice più veloce sarebbe il codice macchina accuratamente realizzato a mano. L'assemblatore sarà quasi altrettanto buono. Entrambi sono di livello molto basso e ci vuole molto codice per scrivere. C è un po 'sopra l'assemblatore. Hai ancora la possibilità di controllare le cose a un livello molto basso nella macchina reale, ma c'è abbastanza astrazione che rende la scrittura più veloce e più facile dell'assemblatore. Altre lingue come C # e JAVA sono ancora più astratte. Mentre assemblatore e codice macchina sono chiamati linguaggi di basso livello, C # e JAVA (e molti altri) sono chiamati linguaggi di alto livello. C è talvolta chiamato una lingua di livello medio.

Non dare per scontato qualcuno, guarda il disassemblaggio sia per C che per la tua lingua preferita in qualsiasi parte critica del rendimento del tuo codice. Penso che puoi semplicemente guardare nella finestra di smontaggio in fase di esecuzione in Visual Studio per vedere .Net smontato. Dovrebbe essere possibile se complicato per Java usando windbg, anche se lo fai con .Net molti dei problemi sarebbero gli stessi.

Non mi piace scrivere in C se non ne ho bisogno, ma penso che molte delle affermazioni fatte in queste risposte che sostengono la velocità di lingue diverse da C possano essere messe da parte semplicemente smontando la stessa routine in C e nella tua lingua di livello superiore, specialmente se sono coinvolti molti dati, come è comune nelle applicazioni critiche per le prestazioni. Fortran potrebbe essere un'eccezione nella sua area di competenza, non lo so. È di livello superiore a C?

La prima volta che ho confrontato il codice JITed con il codice nativo ho risolto tutte le domande sul fatto che il codice .Net potesse essere comparato al codice C. Il livello extra di astrazione e tutti i controlli di sicurezza comportano un costo significativo. Gli stessi costi verrebbero probabilmente applicati a Java, ma non crederci, provalo su qualcosa in cui le prestazioni sono fondamentali. (Qualcuno sa abbastanza su JITed Java per individuare una procedura compilata in memoria? Dovrebbe certamente essere possibile)

1) Come altri hanno già detto, C fa di meno per te. Nessuna variabile di inizializzazione, nessun controllo dei limiti dell'array, nessuna gestione della memoria, ecc. Quelle funzionalità in altre lingue costano i cicli di memoria e CPU che C non spende.

2) Le risposte dicendo che C è meno astratto e quindi più veloce sono solo metà corrette, penso. Tecnicamente parlando, se avessi un "compilatore sufficientemente avanzato" per il linguaggio X, allora il linguaggio X potrebbe avvicinarsi o eguagliare la velocità di C. La differenza con C è che dal momento che mappa così ovviamente (se hai seguito un corso di architettura) e direttamente al linguaggio assembly che anche un compilatore ingenuo può fare un lavoro decente. Per qualcosa come Python, è necessario un compilatore molto avanzato per prevedere i probabili tipi di oggetti e generare al volo il codice macchina: la semantica di C è abbastanza semplice da consentire a un semplice compilatore di funzionare bene.

In passato, c'erano solo due tipi di lingue: compilate e interpretate.

I linguaggi compilati hanno utilizzato un "compilatore" per leggere la sintassi del linguaggio e convertirlo in un codice identico per il linguaggio assembly, che potrebbe non solo direttamente sulla CPU. Le lingue interpretate utilizzavano un paio di schemi diversi, ma essenzialmente la sintassi del linguaggio veniva convertita in una forma intermedia e quindi eseguita in un "interprete", un ambiente per eseguire il codice.

Quindi, in un certo senso, c'era un altro "livello" - l'interprete - tra il codice e la macchina. E, come sempre nel caso di un computer, più significa che vengono utilizzate più risorse. Gli interpreti erano più lenti, perché dovevano eseguire più operazioni.

Più recentemente, abbiamo visto più linguaggi ibridi come Java, che impiegano sia un compilatore che un interprete per farli funzionare. È complicato, ma una JVM è più veloce, più sofisticata e molto più ottimizzata rispetto ai vecchi interpreti, quindi presenta un cambiamento molto migliore nell'esecuzione (nel tempo) più vicino al semplice codice compilato. Ovviamente, i compilatori più recenti hanno anche trucchi per l'ottimizzazione più fantasiosi, quindi tendono a generare codice molto migliore di quanto non facessero anche loro. Ma la maggior parte delle ottimizzazioni, il più delle volte (sebbene non sempre) effettuano un qualche tipo di compromesso in modo tale da non essere sempre più veloci in tutte le circostanze. Come tutto il resto, niente viene offerto gratuitamente, quindi gli ottimizzatori devono trarre vantaggio da qualche parte (anche se spesso lo utilizzano utilizzando la CPU in fase di compilazione per salvare la CPU di runtime).

Tornando a C, è un linguaggio semplice, che può essere compilato in assembly abbastanza ottimizzato e quindi eseguito direttamente sulla macchina di destinazione. In C, se si incrementa un numero intero, è più che probabile che sia solo un passo dell'assemblatore nella CPU, in Java, tuttavia, potrebbe finire per essere molto più di questo (e potrebbe includere anche un po 'di garbage collection: -) C ti offre un'astrazione che è molto più vicina alla macchina (l'assemblatore è il più vicino), ma alla fine devi fare molto più lavoro per farlo funzionare e non è così protetto, facile da usare o facile da correggere. La maggior parte delle altre lingue ti dà una maggiore astrazione e si prende cura di più dei dettagli sottostanti per te, ma in cambio della loro funzionalità avanzata richiedono più risorse per funzionare. Man mano che generalizzi alcune soluzioni, devi gestire una gamma più ampia di elaborazione,

Paolo.

Mettendo da parte tecniche di ottimizzazione avanzate come l'ottimizzazione hot-spot , meta-algoritmi precompilati e varie forme di parallelismo , la velocità fondamentale di un linguaggio è fortemente correlata alla complessità implicita dietro le quinte richiesta per supportare le operazioni che comunemente essere specificato nei circuiti interni .

Forse il più ovvio è il controllo di validità sui riferimenti di memoria indiretta, come il controllo dei puntatori nulle il controllo degli indici rispetto ai limiti dell'array. La maggior parte delle lingue di alto livello esegue questi controlli implicitamente, ma C no. Tuttavia, questo non è necessariamente un limite fondamentale di questi altri linguaggi : un compilatore sufficientemente intelligente potrebbe essere in grado di rimuovere questi controlli dai loop interni di un algoritmo attraverso una qualche forma di movimento del codice invariante .

Il vantaggio più fondamentale di C (e in misura simile del C ++ strettamente correlato) è una forte dipendenza dall'allocazione di memoria basata su stack , che è intrinsecamente veloce per allocazione, deallocazione e accesso. In C (e C ++) lo stack di chiamate principale può essere utilizzato per l'allocazione di primitive, array e aggregati ( struct/class ).

Mentre C offre la possibilità di allocare dinamicamente memoria di dimensioni e durata arbitrarie (usando il cosiddetto 'heap'), per impostazione predefinita viene evitato (viene invece utilizzato lo stack).

Tantalizing, a volte è possibile replicare la strategia di allocazione della memoria C all'interno degli ambienti di runtime di altri linguaggi di programmazione. Ciò è stato dimostrato da asm.js , che consente di tradurre il codice scritto in C o C ++ in un sottoinsieme di JavaScript ed eseguirlo in sicurezza in un ambiente browser Web, con una velocità quasi nativa.

A parte questo, un'altra area in cui C e C ++ superano la maggior parte degli altri linguaggi per la velocità è la capacità di integrarsi perfettamente con i set di istruzioni della macchina nativa. Un esempio notevole di ciò è la disponibilità ( intrinseca del compilatore e della piattaforma) di intrinseci SIMD che supportano la costruzione di algoritmi personalizzati che sfruttano l'ormai quasi onnipresente hardware di elaborazione parallela, pur utilizzando le astrazioni di allocazione dei dati fornite dal linguaggio (inferiore l'allocazione del registro di livello è gestita dal compilatore).

Ho trovato una risposta sul link sul perché alcune lingue sono più veloci e alcune sono più lente, spero che questo chiarisca di più sul perché C o C ++ è più veloce di altri, ci sono anche altre lingue più veloci di C, ma non possiamo usali tutti. Qualche spiegazione -

Uno dei motivi principali per cui Fortran rimane importante è perché è veloce: le routine di scricchiolio dei numeri scritte in Fortran tendono ad essere più veloci delle routine equivalenti scritte nella maggior parte delle altre lingue. I linguaggi che sono in competizione con Fortran in questo spazio - C e C ++ - sono usati perché competitivi con questa performance.

Questo solleva la domanda: perché? Cosa c'è in C ++ e Fortran che li rendono veloci e perché superano altri linguaggi popolari, come Java o Python?

Interpretazione contro compilazione Esistono molti modi per classificare e definire i linguaggi di programmazione, in base allo stile di programmazione che incoraggiano e alle funzionalità che offrono. Quando si guarda alla performance, la più grande distinzione singola è tra i linguaggi interpretati e quelli compilati.

La divisione non è difficile; piuttosto, c'è uno spettro. Ad una estremità, abbiamo linguaggi compilati tradizionali, un gruppo che include Fortran, C e C ++. In queste lingue, esiste una fase di compilazione discreta che traduce il codice sorgente di un programma in una forma eseguibile che il processore può utilizzare.

Questo processo di compilazione prevede diversi passaggi. Il codice sorgente viene analizzato e analizzato. A questo punto è possibile rilevare errori di codifica di base come errori di battitura e errori di ortografia. Il codice analizzato viene utilizzato per generare una rappresentazione in memoria, che può essere utilizzata anche per rilevare errori, questa volta errori semantici, come la chiamata di funzioni che non esistono o il tentativo di eseguire operazioni aritmetiche su stringhe di testo.

Questa rappresentazione in memoria viene quindi utilizzata per guidare un generatore di codice, la parte che produce codice eseguibile. L'ottimizzazione del codice, per migliorare le prestazioni del codice generato, viene eseguita in vari momenti all'interno di questo processo: ottimizzazioni di alto livello possono essere eseguite sulla rappresentazione del codice e ottimizzazioni di livello inferiore vengono utilizzate sull'output del generatore di codice.

L'esecuzione effettiva del codice avviene successivamente. L'intero processo di compilazione viene semplicemente utilizzato per creare qualcosa che può essere eseguito.

All'estremità opposta, abbiamo interpreti. Gli interpreti includeranno una fase di analisi simile a quella del compilatore, ma questo viene quindi utilizzato per guidare l'esecuzione diretta, con il programma che viene eseguito immediatamente.

L'interprete più semplice ha al suo interno un codice eseguibile corrispondente alle varie funzionalità supportate dalla lingua, quindi avrà funzioni per l'aggiunta di numeri, l'unione di stringhe, qualsiasi altra lingua abbia. Mentre analizza il codice, cercherà la funzione corrispondente ed eseguirà. Le variabili create nel programma verranno mantenute in una sorta di tabella di ricerca che associa i loro nomi ai loro dati.

L'esempio più estremo dello stile dell'interprete è qualcosa come un file batch o uno script di shell. In queste lingue, il codice eseguibile spesso non è nemmeno incorporato nell'interprete stesso, ma piuttosto in programmi autonomi separati.

Quindi perché questo fa la differenza per le prestazioni? In generale, ogni livello di riferimento indiretto riduce le prestazioni. Ad esempio, il modo più veloce per aggiungere due numeri è di avere entrambi quei numeri nei registri del processore e di usare le istruzioni di aggiunta del processore. Ecco cosa possono fare i programmi compilati; possono inserire variabili nei registri e trarre vantaggio dalle istruzioni del processore. Ma nei programmi interpretati, quella stessa aggiunta potrebbe richiedere due ricerche in una tabella di variabili per recuperare i valori da aggiungere, quindi chiamare una funzione per eseguire l'aggiunta. Tale funzione può benissimo utilizzare le stesse istruzioni del processore utilizzate dal programma compilato per eseguire l'aggiunta effettiva, ma tutto il lavoro extra prima che l'istruzione possa effettivamente essere utilizzata rende le cose più lente.

Se vuoi saperne di più, controlla la fonte

Alcuni algoritmi C ++ sono più veloci di C e alcune implementazioni di algoritmi o modelli di progettazione in altri linguaggi possono essere più veloci di C.

Quando le persone affermano che C è veloce e poi passano a parlare di qualche altra lingua, generalmente usano la performance di C come riferimento.

Con i moderni compilatori di ottimizzazione, è altamente improbabile che un programma C puro sia molto più veloce del codice .net compilato, se non del tutto. Con il miglioramento della produttività che framework come .net forniscono allo sviluppatore, puoi fare cose in un giorno che impiegava settimane o mesi nella normale C. Insieme al costo economico dell'hardware rispetto allo stipendio di uno sviluppatore, è semplicemente MODO più economico scrivere il materiale in un linguaggio di alto livello e getta l'hardware a qualsiasi lentezza.

Il motivo per cui Jeff e Joel parlano del fatto che C è il linguaggio "programmatore reale" è perché non c'è tenuta di mano in C. Devi allocare la tua memoria, deallocare quella memoria, fare il tuo controllo dei limiti, ecc. Non esiste nulla del genere come nuovo oggetto (); Non ci sono garbage collection, classi, OOP, framework di entità, LINQ, proprietà, attributi, campi o simili. Devi sapere cose come l'aritmetica del puntatore e come dereferenziare un puntatore. E, del resto, conosci e capisci cos'è un puntatore. Devi sapere cos'è uno stack frame e qual è il puntatore alle istruzioni. Devi conoscere il modello di memoria dell'architettura CPU su cui stai lavorando. C'è molta comprensione implicita dell'architettura di un microcomputer (di solito ilmicrocomputer su cui stai lavorando) durante la programmazione in C che semplicemente non è presente né necessaria quando si programma in qualcosa come C # o Java. Tutte queste informazioni sono state scaricate nel programmatore del compilatore (o VM).

È la differenza tra automatico e manuale, le lingue di livello superiore sono le astrazioni così automatizzate. C / C ++ sono controllati e gestiti manualmente, anche il codice di controllo degli errori a volte è un lavoro manuale.

C e C ++ sono anche linguaggi compilati, il che significa che nessuno di questi funziona ovunque, queste lingue devono essere ottimizzate per l'hardware con cui lavori, aggiungendo così un ulteriore livello di gotcha. Anche se questo è un po 'inquietante ora come i compilatori C / C ++ stanno diventando più comuni su tutte le piattaforme. È possibile eseguire compilazioni incrociate tra piattaforme. Non è ancora una situazione dappertutto, il tuo fondamentalmente istruisci il compilatore A di compilare contro lo stesso codice B con architettura diversa.

I linguaggi della linea di fondo C non sono pensati per essere facili da capire o ragionare, anche per questo vengono chiamati linguaggi di sistema. Sono usciti prima di tutte queste assurdità di astrazione di alto livello. Questo è anche il motivo per cui non vengono utilizzati per la programmazione Web front-end. Non sono adatti al compito, ma sono intesi a risolvere problemi complessi che non possono essere risolti con strumenti linguistici convenzionali.

Questo è il motivo per cui ottieni cose folli come (micro-architetture, driver, fisica quantistica, giochi AAA, sistemi operativi) ci sono cose per cui C e C ++ sono adatte. La velocità e lo scricchiolio dei numeri sono le aree principali.

C è veloce perché è un linguaggio di basso livello compilato in modo nativo. Ma C non è il più veloce. Il benchmark ricorsivo di Fibonacci mostra che Rust, Crystal e Nim possono essere più veloci.

Ci sono molte ragioni, tra cui:

• Si compila in linguaggio assembly.
• È staticamente tipizzato.
• Nessuna raccolta rifiuti.
• Nessuna gestione degli errori.
• Molti linguaggi di programmazione aggiungono nuove funzionalità. Parte della filosofia di C è quella di mantenere le cose semplici invece di aggiungere più funzionalità.