Perché alcuni linguaggi di programmazione sono "più veloci" o "più lenti" di altri?

Ho notato che alcune applicazioni o algoritmi basati su un linguaggio di programmazione, ad esempio C ++ / Rust, funzionano più velocemente o in modo più veloce di quelli basati su, Java / Node.js, in esecuzione sulla stessa macchina. Ho qualche domanda al riguardo:

1. Perché succede?
2. Cosa regola la "velocità" di un linguaggio di programmazione?
3. Ha qualcosa a che fare con la gestione della memoria?

Gradirei davvero se qualcuno mi avesse rotto.

Nella progettazione e nell'implementazione del linguaggio di programmazione, esiste un gran numero di scelte che possono influire sulle prestazioni. Ne citerò solo alcuni.

Alla fine, ogni lingua deve essere eseguita eseguendo il codice macchina. Un linguaggio "compilato" come C ++ viene analizzato, decodificato e tradotto in codice macchina una sola volta, al momento della compilazione. Un linguaggio "interpretato", se implementato in modo diretto, viene decodificato in fase di esecuzione, in ogni fase, ogni volta. Cioè, ogni volta che eseguiamo un'istruzione, l'interprete deve verificare se si tratta di un if-then-else, o di un compito, ecc. E agire di conseguenza. Ciò significa che se eseguiamo il loop 100 volte, decodifichiamo lo stesso codice 100 volte, perdendo tempo. Fortunatamente, gli interpreti spesso lo ottimizzano attraverso, ad esempio, un sistema di compilazione just-in-time. (Più correttamente, non esiste un linguaggio "compilato" o "interpretato": è una proprietà dell'implementazione, non del linguaggio. Tuttavia,

Diversi compilatori / interpreti eseguono diverse ottimizzazioni.

Se la lingua ha una gestione automatica della memoria, la sua implementazione deve eseguire la garbage collection. Questo ha un costo di runtime, ma allevia il programmatore da un'attività soggetta a errori.

Un linguaggio potrebbe essere più vicino alla macchina, consentendo al programmatore esperto di micro-ottimizzare tutto e ottenere più prestazioni dalla CPU. Tuttavia, è discutibile se questo sia effettivamente utile in pratica, dal momento che la maggior parte dei programmatori non è davvero micro-ottimizzata, e spesso un buon linguaggio di livello superiore può essere ottimizzato dal compilatore meglio di quello che farebbe il programmatore medio. (Tuttavia, a volte essere più lontano dalla macchina potrebbe avere anche i suoi vantaggi! Ad esempio, Haskell è di altissimo livello, ma grazie alle sue scelte di design è in grado di presentare fili verdi molto leggeri.)

Il controllo statico del tipo può anche aiutare nell'ottimizzazione. In un linguaggio interpretato in modo dinamico, ogni volta che si calcola x - y, l'interprete deve spesso verificare se entrambi x,ysono numeri e (ad esempio) sollevare un'eccezione in caso contrario. Questo controllo può essere ignorato se i tipi erano già stati controllati al momento della compilazione.

Alcune lingue segnalano sempre errori di runtime in modo sano. Se si scrive a[100]in Java dove asono presenti solo 20 elementi, si ottiene un'eccezione di runtime. In C, ciò causerebbe un comportamento indefinito, il che significa che il programma potrebbe bloccarsi, sovrascrivere alcuni dati casuali in memoria o persino eseguire qualsiasi altra cosa (lo standard ISO C non pone limiti di sorta). Ciò richiede un controllo di runtime, ma fornisce una semantica molto più piacevole al programmatore.

Tuttavia, tieni presente che, quando si valuta una lingua, le prestazioni non sono tutto. Non essere ossessionato da questo. È una trappola comune tentare di microottimizzare tutto, senza tuttavia individuare un algoritmo / struttura dati inefficiente. Knuth una volta disse "l'ottimizzazione prematura è la radice di tutti i mali".

Non sottovalutare quanto sia difficile scrivere un programma giusto . Spesso, può essere meglio scegliere una lingua "più lenta" che ha una semantica più umana. Inoltre, se esistono specifiche parti critiche per le prestazioni, queste possono sempre essere implementate in un'altra lingua. Proprio come riferimento, nel concorso di programmazione ICFP 2016 , questi erano i linguaggi utilizzati dai vincitori:

1   700327  Unagi                       Java,C++,C#,PHP,Haskell
2   268752  天羽々斬                     C++, Ruby, Python, Haskell, Java, JavaScript
3   243456  Cult of the Bound Variable  C++, Standard ML, Python

Nessuno di loro ha usato una sola lingua.

Cosa regola la "velocità" di un linguaggio di programmazione?

Non esiste la "velocità" di un linguaggio di programmazione. Esiste solo la velocità di un particolare programma scritto da un particolare programmatore eseguito da una particolare versione di una particolare implementazione di un particolare motore di esecuzione in esecuzione in un determinato ambiente.

Ci possono essere enormi differenze di prestazioni nell'esecuzione dello stesso codice scritto nella stessa lingua sullo stesso computer utilizzando implementazioni diverse. O anche usando versioni diverse della stessa implementazione. Ad esempio, l'esecuzione dello stesso identico benchmark ECMAScript sulla stessa macchina utilizzando una versione di SpiderMonkey di 10 anni fa rispetto a una versione di quest'anno produrrà probabilmente un aumento delle prestazioni tra 2 × –5 ×, forse anche 10 ×. Ciò significa quindi che ECMAScript è 2 volte più veloce di ECMAScript, perché l'esecuzione dello stesso programma sulla stessa macchina è 2 volte più veloce con l'implementazione più recente? Non ha senso.

Ha qualcosa a che fare con la gestione della memoria?

Non proprio.

Perché succede?

Risorse. I soldi. Probabilmente Microsoft impiega più persone a preparare il caffè per i programmatori di compilatori rispetto all'intera comunità di PHP, Ruby e Python che riunisce persone che lavorano sulle loro macchine virtuali.

Per più o meno qualsiasi caratteristica di un linguaggio di programmazione che influisce in qualche modo sulle prestazioni, esiste anche una soluzione. Ad esempio, C (sto usando C qui come stand-in per una classe di linguaggi simili, alcuni dei quali esistevano anche prima di C) non è sicuro per la memoria, in modo che più programmi C in esecuzione contemporaneamente possano calpestare memoria reciproca. Quindi, inventiamo la memoria virtuale e facciamo passare tutti i programmi C attraverso uno strato di indiretta in modo che possano far finta di essere gli unici in esecuzione sulla macchina. Tuttavia, è lento, quindi inventiamo la MMU e implementiamo la memoria virtuale nell'hardware per accelerarla.

Ma! Le lingue sicure per la memoria non hanno bisogno di tutto questo! Avere memoria virtuale non li aiuta un po '. In realtà, è peggio: non solo la memoria virtuale non aiuta i linguaggi a prova di memoria, la memoria virtuale, anche se implementata in hardware, influisce comunque sulle prestazioni. Può essere particolarmente dannoso per le prestazioni dei garbage collector (che è ciò che utilizza un numero significativo di implementazioni di linguaggi sicuri per la memoria).

Un altro esempio: le moderne CPU per uso generale mainstream utilizzano trucchi sofisticati per ridurre la frequenza dei mancati cache. Molti di questi trucchi equivalgono a tentare di prevedere quale codice verrà eseguito e quale memoria sarà necessaria in futuro. Tuttavia, per le lingue con un elevato grado di polimorfismo di runtime (ad es. Lingue OO) è davvero molto difficile prevedere tali schemi di accesso.

Ma esiste un altro modo: il costo totale dei mancati cache è il numero di mancati cache moltiplicato per il costo di una singola perdita cache. Le CPU mainstream cercano di ridurre il numero di errori, ma cosa succede se si potesse ridurre il costo di un singolo errore?

La CPU Azul Vega-3 è stata appositamente progettata per l'esecuzione di JVM virtualizzate e disponeva di una MMU molto potente con alcune istruzioni specializzate per aiutare la raccolta di rifiuti e il rilevamento di escape (l'equivalente dinamico dell'analisi di escape statica) e potenti controller di memoria e l'intero sistema potrebbe ancora fare progressi con oltre 20000 mancati cache mancanti in volo. Sfortunatamente, come la maggior parte delle CPU specifiche del linguaggio, il suo design è stato semplicemente esaurito e forzato dai "giganti" Intel, AMD, IBM e simili.

L'architettura della CPU è solo un esempio che ha un impatto su quanto sia facile o difficile avere un'implementazione ad alte prestazioni di un linguaggio. Un linguaggio come C, C ++, D, Rust che si adatta bene al moderno modello di programmazione della CPU tradizionale sarà più facile da rendere veloce rispetto a un linguaggio che deve "combattere" e aggirare la CPU, come Java, ECMAScript, Python, Ruby , PHP.

Davvero, è tutta una questione di soldi. Se si spendono le stesse quantità di denaro per sviluppare un algoritmo ad alte prestazioni in ECMAScript, un'implementazione ad alte prestazioni di ECMAScript, un sistema operativo ad alte prestazioni progettato per ECMAScript, una CPU ad alte prestazioni progettata per ECMAScript come è stata spesa nell'ultima decenni per accelerare le lingue di tipo C, quindi probabilmente vedrai pari prestazioni. È solo che, in questo momento, sono stati spesi molti più soldi per velocizzare i linguaggi di tipo C piuttosto che per velocizzare i linguaggi di tipo ECMAScript, e le ipotesi dei linguaggi di tipo C sono inserite nell'intero stack da MMU e CPU a sistemi operativi e sistemi di memoria virtuale fino a librerie e framework.

Personalmente, conosco meglio Ruby (che è generalmente considerato un "linguaggio lento"), quindi Hashfornirò due esempi: la classe (una delle strutture di dati centrali in Ruby, un dizionario chiave-valore) nel Rubinius L'implementazione di Ruby è scritta in Ruby puro al 100% e ha circa le stesse prestazioni diHashclasse in YARV (l'implementazione più utilizzata), che è scritta in C. E c'è una libreria di manipolazione delle immagini scritta come estensione C per YARV, che ha anche una (lenta) Ruby "versione fallback" pura per implementazioni che don supporta C che utilizza una tonnellata di trucchi Ruby altamente dinamici e riflessivi; un ramo sperimentale di JRuby, che utilizza il framework di interpreti Truffle AST e il framework di compilazione Graal JIT di Oracle Labs, può eseguire quella "versione fallback" di Ruby con la stessa velocità con cui YARV può eseguire l'originale versione C altamente ottimizzata. Questo è semplicemente (beh, tutt'altro) raggiunto da alcune persone davvero intelligenti che fanno cose davvero intelligenti con ottimizzazioni di runtime dinamiche, compilazione JIT e valutazione parziale.

Teoricamente, se scrivi un codice che fa esattamente lo stesso in due lingue e compili entrambi usando un compilatore "perfetto", le prestazioni di entrambi dovrebbero essere le stesse.

In pratica, ci sono diversi motivi per cui le prestazioni saranno diverse:

1. Alcune lingue sono più difficili da ottimizzare.

   Ciò include in particolare funzionalità che rendono il codice più dinamico (digitazione dinamica, metodi virtuali, puntatori a funzione), ma anche ad esempio garbage collection.

   Esistono vari modi per rendere il codice veloce utilizzando tali funzionalità, ma di solito finisce almeno un po 'più lentamente che senza usarle.

2. Alcune implementazioni linguistiche devono eseguire alcune compilazioni in fase di esecuzione.

   Questo vale soprattutto per le lingue con macchine virtuali (come Java) e le lingue che eseguono il codice sorgente, senza passaggi intermedi per i file binari (come JavaScript).

   Tali implementazioni linguistiche devono svolgere più lavoro in fase di esecuzione, il che influisce sulle prestazioni, in particolare il tempo di avvio / prestazioni subito dopo l'avvio.

3. Le implementazioni linguistiche impiegano intenzionalmente meno ottimizzazioni di quanto potrebbero.

   Tutti i compilatori si preoccupano delle prestazioni del compilatore stesso, non solo del codice generato. Ciò è particolarmente importante per i compilatori di runtime (compilatori JIT), dove impiegare troppo tempo per la compilazione rallenta l'esecuzione dell'applicazione. Ma si applica ai compilatori in anticipo, come quelli anche per C ++. Ad esempio, l' allocazione dei registri è un problema NP completo, quindi non è realistico risolverlo perfettamente e vengono invece utilizzate euristiche che si eseguono in tempi ragionevoli.

4. Differenze nei modi di dire in diverse lingue.

   Il codice scritto nello stile comune per un determinato linguaggio (codice idiomatico) usando librerie comuni può comportare differenze nelle prestazioni, poiché tale codice idiomatico si comporta in modo leggermente diverso in ogni lingua.

   Ad esempio, considera vector[i]in C ++, list[i]in C # e list.get(i)in Java. Il codice C ++ probabilmente non esegue il controllo dell'intervallo e non esegue chiamate virtuali, il codice C # esegue il controllo dell'intervallo, ma nessuna chiamata virtuale e il codice Java esegue il controllo dell'intervallo ed è una chiamata virtuale. Tutte e tre le lingue supportano metodi virtuali e non virtuali e sia C ++ che C # possono includere il controllo dell'intervallo o evitarlo quando si accede all'array sottostante. Ma le librerie standard di questi linguaggi hanno deciso di scrivere queste funzioni equivalenti in modo diverso e, di conseguenza, le loro prestazioni saranno diverse.

5. Ad alcuni compilatori potrebbero mancare alcune ottimizzazioni.

   Gli autori di compilatori dispongono di risorse limitate, quindi non possono implementare ogni possibile ottimizzazione, anche ignorando gli altri problemi. E le risorse che hanno potrebbero essere focalizzate su un'area di ottimizzazione più di altre. Di conseguenza, il codice scritto in lingue diverse può avere prestazioni diverse a causa delle differenze nei loro compilatori, anche se non vi è alcun motivo fondamentale per cui una lingua dovrebbe essere più veloce o persino più facile da ottimizzare rispetto all'altra.

Questa è una domanda molto generica, ma nel tuo caso la risposta potrebbe essere semplice. Il C ++ viene compilato in codice macchina, dove Java viene compilato in codice byte Java, che viene quindi eseguito da una macchina virtuale Java (sebbene sia presente anche la compilazione just-in-time, che compila ulteriormente il codice byte Java in codice macchina nativo). Un'altra differenza potrebbe essere la garbage collection, che è un servizio fornito solo da Java.

La tua domanda è troppo generica, quindi temo di non poter dare una risposta esatta di cui hai bisogno.

Per la mia migliore spiegazione, diamo un'occhiata alla piattaforma C ++ e .Net.

C ++, molto vicino al codice macchina e una delle programmazioni preferite in passato (come più di 10 anni fa?) A causa delle prestazioni. Non ci sono molte risorse necessarie per sviluppare ed eseguire il programma C ++ anche con l'IDE, sono considerate molto leggere e molto veloci. Puoi anche scrivere codice C ++ in console e sviluppare un gioco da lì. In termini di memoria e risorse, ho dimenticato all'incirca quanta capacità ci vuole in un computer, ma la capacità è qualcosa che non si può paragonare all'attuale generazione del linguaggio di programmazione.

Ora diamo un'occhiata a .Net. Il prerequisito per lo sviluppo .Net è un IDE gigante che non consiste in un solo tipo di linguaggi di programmazione. Anche se vuoi solo sviluppare in diciamo C #, l'IDE stesso includerà molte piattaforme di programmazione di default come J #, VB, mobile ed ecc. Di default. A meno che tu non esegua l'installazione personalizzata e installi solo esattamente ciò che desideri, a condizione che tu abbia l'esperienza sufficiente per giocare con l'installazione IDE.

Oltre all'installazione del software IDE stesso, .Net offre anche un'enorme capacità di librerie e framework allo scopo di facilitare l'accesso a qualsiasi tipo di piattaforma di cui gli sviluppatori hanno bisogno e di cui non hanno bisogno.

Lo sviluppo in .Net può essere un'esperienza divertente perché molte funzioni e componenti comuni sono disponibili per impostazione predefinita. È possibile trascinare e utilizzare molti metodi di convalida, lettura dei file, accesso al database e molto altro nell'IDE.

Di conseguenza, è un compromesso tra risorse del computer e velocità di sviluppo. Quelle librerie e framework occupano memoria e risorse. Quando si esegue un programma in .Net IDE, potrebbe essere necessario un sacco di tempo nel tentativo di compilare le librerie, i componenti e tutti i file. E quando esegui il debug, il tuo computer richiede molte risorse per gestire il processo di debug nel tuo IDE.

Di solito, per fare lo sviluppo .Net, hai bisogno di un buon computer con alcuni RAM e processore. Altrimenti, potresti non programmare affatto. Sotto questo aspetto, la piattaforma C ++ è molto meglio di .Net. Anche se hai ancora bisogno di un buon computer, ma la capacità non sarà di grande preoccupazione rispetto a .Net.

Spero che la mia risposta possa aiutare con la tua domanda. Fammi sapere se vuoi saperne di più.

MODIFICARE:

Solo un chiarimento al mio punto principale, rispondo principalmente alla domanda "Cosa regola la velocità di programmazione".

Dal punto di vista IDE, l'uso del linguaggio C ++ o .Net nel relativo IDE non influisce sulla velocità di scrittura del codice, ma influirà sulla velocità di sviluppo perché il compilatore di Visual Studio impiega più tempo per eseguire il programma, ma IDE C ++ è molto più leggero e consumare meno risorse del computer. Quindi, a lungo termine, puoi fare una programmazione più veloce con il tipo di IDE C ++ rispetto a .Net IDE che dipende fortemente dalle librerie e dal framework. Se si impiega il tempo di attesa dell'IDE per l'avvio, la compilazione, l'esecuzione del programma e così via, ciò influirà sulla velocità di programmazione. A meno che "la velocità di programmazione" non sia effettivamente focalizzata solo sulla "velocità di scrittura del codice".

La quantità di librerie e framework in Visual Studio consuma anche la capacità del computer. Non sono sicuro che questo risponda alla domanda di "gestione della memoria", ma voglio solo sottolineare che l'IDE di Visual Studio può occupare molte risorse durante l'esecuzione e quindi rallentare la "velocità di programmazione" complessiva. Naturalmente, questo non ha nulla a che fare con la "velocità di scrittura del codice".

Come avrai intuito, non conosco troppo il C ++ poiché lo uso solo come esempio, il mio punto principale riguarda il tipo di IDE pesante di Visual Studio che consuma risorse del computer.

Se ho avuto l'idea e non ho risposto alla domanda di discussione, chiedete scusa per il lungo post. Ma consiglierei a chi inizia il thread di chiarire la domanda e chiedere esattamente cosa deve sapere su "più veloce" e "più lento"