Possiamo fare dichiarazioni generali sull'esecuzione del codice interpretato rispetto al codice compilato?

Sto confrontando due tecnologie al fine di ottenere una raccomandazione per la quale una dovrebbe essere utilizzata da un'azienda. Il codice della tecnologia A viene interpretato mentre il codice della tecnologia B viene compilato in codice macchina. Nel mio confronto dichiaro che la tecnologia B in generale avrebbe prestazioni migliori poiché non ha l'ulteriore sovraccarico del processo di interpretazione. Dichiaro anche che, poiché un programma potrebbe essere scritto in molti modi, è ancora possibile che un programma scritto in tecnologia A possa superare quello scritto in tecnologia B.

Quando ho presentato questo rapporto per la revisione, il revisore ha dichiarato che non avevo offerto motivi chiari per cui in generale il sovraccarico del processo di interpretazione sarebbe abbastanza grande da poter concludere che le prestazioni della tecnologia B sarebbero state migliori.

Quindi la mia domanda è: possiamo mai dire qualcosa sulle prestazioni delle tecnologie compilate / interpretate? Se possiamo dire che la compilazione è generalmente più veloce di quella interpretata, come potrei convincere il revisore del mio punto?

No.

In generale, l'esecuzione di un'implementazione del linguaggio dipende principalmente dalla quantità di denaro, risorse, risorse umane, ricerca, ingegneria e sviluppo spesi per essa.

E in particolare, le prestazioni di un determinato programma dipendono principalmente dalla quantità di pensiero messa nei suoi algoritmi.

Ci sono alcuni interpreti molto veloci là fuori e alcuni compilatori che generano un codice molto lento .

Ad esempio, uno dei motivi per cui Forth è ancora popolare, è perché in molti casi un programma Forth interpretato è più veloce del programma C compilato equivalente, mentre allo stesso tempo, il programma utente scritto in Forth più l'interprete Forth scritto in C è più piccolo del programma utente scritto in C.

Generalizzazioni e scenari specifici sono letteralmente opposti.

Sembra che ti stia contraddicendo. Da un lato, si desidera fare una dichiarazione generale sui linguaggi interpretati e compilati. D'altra parte, si desidera applicare tale affermazione generale a uno scenario concreto che coinvolge la tecnologia A e la tecnologia B.

Una volta applicato qualcosa a uno scenario concreto, non è più generalizzato . Quindi, anche se puoi affermare che le lingue interpretate sono più lente in generale , non stai ancora esprimendo il tuo punto. Il tuo recensore non si preoccupa delle generalizzazioni. Stai facendo un'analisi di due tecnologie molto specifiche. Questo è letteralmente l'opposto della generalizzazione.

Come regola generale, un programma interpretato è circa 2x-10 volte più lento rispetto alla scrittura del programma nella lingua host dell'interprete, con gli interpreti per linguaggi più dinamici più lenti. Questo perché il programma interpretato deve svolgere tutto il lavoro effettivo, ma ha anche l'interpretazione generale.

A seconda della struttura dell'interprete, possono esserci differenze molto significative. Esistono due scuole contraddittorie nella progettazione dell'interprete: una dice che i codici operativi dovrebbero essere il più piccoli possibile in modo che possano essere ottimizzati più facilmente, l'altro dice che i codici operativi dovrebbero essere i più grandi possibili in modo da svolgere più lavoro all'interno dell'interprete. Quando la struttura del programma corrisponde alla filosofia dell'interprete, l'overhead diventa trascurabile.

Ad esempio, Perl è un linguaggio interpretato orientato alla manipolazione del testo. Un programma Perl idiomatico che esegue la manipolazione del testo non sarà molto più lento di un programma C e in alcuni casi potrebbe persino superare il programma C (possibile perché Perl utilizza una rappresentazione di stringa diversa e ha varie ottimizzazioni relative al testo e all'IO). Tuttavia, fare scricchiolii in Perl sarà insopportabilmente lento. Un incremento ++xè una singola istruzione di assieme, ma coinvolge più attraversamenti di puntatori e diramazioni per l'interprete Perl. Di recente ho portato su C ++ uno script Perl associato alla CPU e ho ottenuto uno speedup 7x-20x, a seconda del livello di ottimizzazione del compilatore.

Parlare di ottimizzazioni è importante qui, poiché un interprete ottimizzato e ottimizzato può ragionevolmente sovraperformare un compilatore ingenuo non ottimizzante. Poiché la creazione di un compilatore di ottimizzazione è difficile e richiede molti sforzi, è improbabile che la tua "tecnologia B" abbia questo livello di maturità.

(Nota: il sito di gioco dei benchmark dei linguaggi informatici ha una struttura confusa, ma una volta raggiunta la tabella dei tempi per un problema noterai che le prestazioni di varie lingue sono ovunque - spesso, non c'è un chiaro limite di prestazioni tra soluzioni compilate e interpretate. La parte più importante del sito non sono i risultati del benchmark, ma le discussioni su quanto siano difficili i benchmark significativi.)

Quando si sceglie una tecnologia, l'esecuzione di un runtime linguistico di per sé è completamente irrilevante. È più probabile che sia importante che la tecnologia soddisfi alcuni vincoli di base (il nostro budget è $ x, dobbiamo essere in grado di fornire prima del aaaa-mm-gg, dobbiamo soddisfare vari requisiti non funzionali) e che ha un livello inferiore costo totale di proprietà (factoring in termini di produttività degli sviluppatori, costi hardware, costi opportunità commerciali, rischio di bug e vincoli imprevisti nella tecnologia, costi di manutenzione, costi di formazione e assunzione, ...). Ad esempio, in un settore in cui il time-to-market è il fattore più importante, la tecnologia con la migliore produttività degli sviluppatori sarebbe la soluzione migliore. Per un'organizzazione di grandi dimensioni, la manutenibilità e i costi a lungo termine possono essere più interessanti.

Puoi assolutamente dire qualcosa sulle prestazioni delle tecnologie compilate / interpretate. Ma prima devi definire "performance". Se stai costruendo un sistema embedded semplice dal punto di vista computazionale, probabilmente le "prestazioni" si orienterebbero verso il lato dell'utilizzo della memoria. Considerando che un sistema computazionalmente complesso che opera su grandi set di dati si troverebbe a definire "prestazioni" nel numero di calcoli per unità di tempo poiché il sovraccarico di memoria da JVM o .NET sarebbe trascurabile.

Una volta deciso quale "prestazione" è, allora puoi dire qualcosa come "avremo 50 miliardi di oggetti in memoria in un dato momento e la tecnologia interpretata aggiunge altri 8 byte a ciascun oggetto per la gestione interna che equivale a un sovraccarico di memoria di 400 GB rispetto a techB che non aggiunge questi dati "

Questa è una domanda tecnica e hai già ricevuto molte buone risposte tecniche, ma vorrei sottolineare un aspetto leggermente diverso della tua situazione: il fatto che non puoi semplicemente basare una decisione come "tecnologia A o tecnologia B" puramente per motivi tecnici e / o prestazionali.

Gli aspetti tecnici di qualcosa del genere sono solo una piccola parte della decisione tra A e B. Ci sono dozzine di altri fattori da tenere a mente:

• comporta costi di licenza? Ad esempio: è necessario pagare (un importo considerevole) per utilizzare un cluster di macchine SQL Server anziché utilizzare un cluster di macchine PostgreSQL.
• ho dipendenti che hanno familiarità con quella tecnologia (stack) e il suo ecosistema? Se sì, sono disponibili? Se no, posso assumerne un po '? Quanto mi costerà? O alleno quelli esistenti? Quanto mi costerà?
• cosa vuole il cliente? Questo può essere un problema per la maggior parte del tempo.
• la tecnologia che raccomando è pronta per l'uso in produzione? O è solo un clamore attuale che forse si estinguerà? (ad esempio, pensa a Node.js quando è uscito per la prima volta)
• la tecnologia che raccomando si adatta bene all'architettura esistente o all'architettura che avevo in mente? O devo spendere molti soldi facendoli lavorare insieme senza problemi?
• e molti altri aspetti che dipendono dalla tua situazione specifica.

Come puoi vedere, c'è una tonnellata di cose da considerare quando si prende una decisione del genere.

So che questo non risponde in modo specifico alla tua domanda, ma penso che offra una visione più ampia della tua situazione e dei dettagli di tale decisione.

La valutazione parziale è un quadro concettuale rilevante per mettere in relazione interpreti e compilatori.

Possiamo fare dichiarazioni generali sull'esecuzione del codice interpretato rispetto al codice compilato?

I linguaggi di programmazione sono le specifiche (scritte in un certo rapporto, come R5RS o n1570 ). Essi sono non il software, quindi non ha nemmeno senso parlare di prestazioni . Ma alcuni linguaggi di programmazione possono avere diverse implementazioni, inclusi interpreti e compilatori .

Anche in linguaggi tradizionalmente compilati (ovvero linguaggi le cui implementazioni sono spesso compilatori) come C, alcune parti vengono spesso interpretate. Ad esempio, la stringa di controllo del formato di printf (definito nello standard C) è spesso "interpretata" (dalla libreria standard C , che ha una printf funzione utilizzando tecniche argomenti variabili), ma alcuni compilatori (compresi GCC ) sono in grado -in limitata specifico casi - per ottimizzarlo e "compilarlo" in chiamate di livello inferiore.

E alcune implementazioni, anche all'interno di "interpreti", utilizzano tecniche di compilazione JIT (quindi genera codice macchina in fase di esecuzione ). Un buon esempio è il luajit . Altre implementazioni (ad esempio Python, Ocaml, Java, Parrot, Lua) stanno traducendo il codice sorgente in un bytecode che viene quindi interpretato.

SBCL è un "compilatore" Common Lisp che traduce dinamicamente ogni interazione REPL (e chiama ad evalecc ...) in codice macchina. Quindi pensi che sia un interprete. La maggior parte delle implementazioni JavaScript nei browser (ad es. V8 ) utilizza tecniche di compilazione JIT.

In altre parole, la differenza tra interpreti e compilatori è molto confusa (in realtà esiste un continuum tra i due), e in pratica, la maggior parte delle implementazioni del linguaggio di programmazione ha spesso sia un interprete che un compilatore (almeno al codice byte).

Un'implementazione può essere veloce o lenta indipendentemente dall'uso della maggior parte delle tecniche come "compilatore" o "interprete".

Alcuni tratti linguistici favoriscono un approccio interpretativo (e possono essere compilati in modo efficiente solo attraverso l' analisi dell'intero programma ).

Per alcuni tipi di problemi, progettare il software con alcuni approcci di metaprogrammazione è utile e dà importanti accelerazioni. Potresti immaginare che, dato un input specifico, il tuo programma generi dinamicamente codice specializzato per elaborarlo. Ciò è persino possibile con C o C ++ (utilizzando una libreria JIT o generando un codice C, compilandolo come un plugin che viene caricato in modo dinamico).

Vedi anche questa domanda correlata su Python e quella

Per un codice simile A = A + B, che può essere compilato in una o due istruzioni macchina, ognuna prendendo un certo numero di cicli. Nessun interprete può fare la stessa cosa in quel numero di cicli per un semplice motivo.

L'interprete esegue anche un proprio set di istruzioni (chiamali codici byte, codici p, linguaggio intermedio, qualunque cosa). Ogni volta che vede un codice byte come ADD, deve cercarlo in qualche modo e diramarsi al codice che fa l'aggiunta.

La prossima volta che lo vede, deve ripetere quella ricerca, a meno che non abbia un modo per ricordare la ricerca precedente. Se ha un modo per ricordare la ricerca precedente, non è più quello che chiamiamo un "interprete", ma piuttosto un compilatore just-in-time o JITter.

D'altro canto...

Per codice come callSomeFunction( ... some args ...), quanti cicli vengono trascorsi tra l'immissione di quel codice e la sua uscita? Tutto dipende da cosa succede dentro callSomeFunction. Potrebbero essere pochi e potrebbero essere miliardi di miliardi, anche se callSomeFunctionè esso stesso compilato. Se è molto, non ha senso discutere il costo dell'interpretazione di quella riga di codice: il denaro è altrove.

Ricorda che le lingue interpretate hanno un valore proprio, come ad esempio, non è necessario compilarle. (La "compilazione" della sintassi di superficie in codici byte richiede un tempo insignificante. Prendi R o MATLAB, per esempio.)

Inoltre, è necessaria flessibilità per livelli di programmazione intelligenti. In Minsky's Society of Mind , capitolo 6.4 B -Brains, ci sono programmi A che si occupano del mondo, e ci sono programmi B che si occupano di programmi A, e possono esserci ulteriori livelli. I programmi che scrivono e gestiscono altri programmi possono essere eseguiti più facilmente nei sistemi interpretativi.

In Lisp, puoi scrivere (+ A B)per aggiungere A e B, ma una volta scritto hai solo la possibilità di eseguirlo o meno. Puoi anche scrivere (eval (list '+ 'A 'B))quale costruisce il programma e quindi lo esegue. Potrebbe costruire qualcosa di diverso.

L'argomento del programma è un altro programma . È più facile scrivere in un linguaggio interpretato (anche se, come sottolinea Jörg, le versioni più recenti di Lisp, mentre hanno eval, compilano al volo, quindi non hanno la penalità di interpretazione).

In un certo senso dipende, ma come regola generale il compilato - sia tramite JIT o compilato staticamente - l'ambiente sarà più veloce per molte attività ad alta intensità di calcolo - assumendo per semplicità lo stesso linguaggio.

Parte del motivo è che le lingue interpretate devono avere un loop - loop di interprete che legge un'istruzione, seleziona le azioni appropriate da intraprendere ed esegue. Nel migliore dei casi, come interpretare il bytecode Python o Java (come faceva il vecchio JVM) ha un sovraccarico di poche istruzioni e ha causato il caos con il predittore di diramazione - senza l'ultimo puoi aspettarti enormi penalità a causa di false previsioni. Anche un JIT molto stupido dovrebbe accelerare questo in modo significativo.

Detto questo, il linguaggio interpretato può imbrogliare. Ad esempio Matlab ha routine ottimizzate per la moltiplicazione di matrici e con poche modifiche è possibile far funzionare il codice su GPU (disclaimer: lavoro per nVidia - qualsiasi opinione espressa qui è mia e non rappresenta la visione del mio datore di lavoro). In questo modo puoi scrivere un codice breve e potente di livello superiore senza preoccuparti dei dettagli: qualcuno se ne è occupato e ha investito tempo e risorse nell'ottimizzarlo in un linguaggio di basso livello. Non c'è nulla di ereditato al riguardo e non impedisce, ad esempio, che Matlab invii il codice JIT, ma spesso non vi è alcun motivo poiché l'overhead della chiamata di routine di alto livello è minimo rispetto al tempo trascorso in quelli di basso livello.

TL; DR: i programmi compilati offrono enormi vantaggi in termini di prestazioni rispetto a quelli interpretati (per il confronto mele-mele vedi PyPy Speed ). Tuttavia, la velocità dell'eseguibile è solo una parte del problema e potrebbe non contribuire molto alla velocità complessiva (se il tempo viene impiegato principalmente nelle librerie). Anche l'implementazione è importante.

Il tuo presupposto è fondato, sebbene sia un presupposto.

Non esaminerò i motivi per cui il codice compilato dovrebbe essere più veloce del codice interpretato: se sai come funzionano i computer, sarà ovvio. La differenza può essere rappresentata da ordini di grandezza per determinati tipi di problemi. Se il tuo revisore contesta seriamente tale caso generale, non sa di cosa sta parlando.

Dove possono avere un punto però è se la differenza è significativa nel tipo di applicazione che stai sviluppando. Se è principalmente I / O o chiama principalmente librerie compilate e non ha molti calcoli, l'overhead del processo di interpretazione potrebbe essere insignificante.

Ma il punto del mio post è questo: come esperto IT sarai spesso chiamato a prendere decisioni rapide basate su una conoscenza generale di come dovrebbero funzionare le cose. Fare un test specifico potrebbe darti una risposta più accurata, ma costerà molto di più e non ti porterà prima lì.

Ma di tanto in tanto vieni sorpreso. Mi è successo. Fai una buona supposizione e poi scopri di non aver preso in considerazione la stupidità del mondo.

Ma non posso spiegare così come il mio cartone animato Dilbert preferito di tutti i tempi. Niente mostra meglio di questo i pericoli di essere un coglione.

TL; DR: dovresti avere ragione, ma controlla il mondo reale per ogni evenienza.

A meno che tu non usi qualcosa di un po 'esotico, il tuo problema non riguarderà le prestazioni di un linguaggio interpretato A e di un linguaggio compilato B.

Perché se tu / il tuo team conoscete A e non B e quindi scrivete un codice molto migliore in A di B, potreste finire per avere prestazioni molto migliori in A di B. Se avete persone con esperienza in una lingua e la lingua / librerie può fare il lavoro necessario, attenersi ad esso.

Ecco un link su regex in varie lingue; vedrai che regex è implementato meglio in alcune lingue anche se compilato o meno: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna

Penso che non sia una buona idea parlare delle prestazioni di due tecnologie basate solo sul fatto che una è compilata e l'altra interpretata. Come indicato in altre risposte, può dipendere dall'area di applicazione (alcune lingue possono essere ottimizzate per eseguire alcune operazioni molto rapidamente e fare altre cose più lentamente), nonché dall'esperienza delle persone che stanno per utilizzare quella tecnologia.

Non credo sia ragionevole aspettarsi che otterrai un aumento delle prestazioni se prendi alcuni programmatori di linguaggio interpretati eccellenti e dai loro una tecnologia con cui non hanno familiarità - forse in teoria quest'ultimo potrebbe portare a prestazioni migliori, ma in realtà, senza le competenze e l'esperienza necessarie, non utilizzerai tutte le opportunità di ottimizzazione.

Da uno dei noti dipendenti della Silicon Valley ho anche sentito che preferiscono la lingua che è più semplice da usare in quanto è più costoso e problematico pagare alcuni sviluppatori esperti per mantenere un codice complicato, ma altamente ottimizzato rispetto al solo acquistare più rig al fine di gestire un'implementazione meno efficiente, in modo da considerare anche la scelta della tecnologia.

Una volta ho dovuto fare un'affermazione simile per giustificare una decisione importante.

In primo luogo, potrebbero non voler credere a un modesto ingegnere, quindi ho trovato alcuni test comparativi comparabili e li ho citati. Ce ne sono molti in giro, provenienti da persone come Microsoft o università rinomate. E diranno cose come: il metodo A è tra 3 e 10 volte più veloce del metodo B, a seconda delle variabili X e Y.

In secondo luogo, potresti voler eseguire un tuo benchmark, magari usando un pezzo rappresentativo del codice in questione, o qualcosa di simile che hai già. Eseguilo 1000 volte durante la notte, quindi c'è davvero una differenza misurabile.

A questo punto la differenza (o mancanza) tra A e B dovrebbe essere così chiara che devi solo presentarla. Quindi formatta i risultati in modo chiaro, con diagrammi se possibile, indicando tutti i presupposti e definendo tutti i dati utilizzati.

Direi che qualsiasi linguaggio dinamico ha un vantaggio rispetto a quelli compilati staticamente: "Ottimizzazioni del runtime"

Questo è uno dei motivi per cui Java può essere più veloce di C ++

Sì, il caricamento di una lingua tipizzata in modo dinamico avrà sempre il costo della traduzione e sarà svantaggiato. Ma una volta in esecuzione, l'interprete può profilare e migliorare percorsi di codice frequenti con informazioni di runtime che i linguaggi statici non avranno mai

NOTA: Beh, Java è un linguaggio interpretato, non dinamico. Ma è un ottimo esempio di ciò che è possibile accelerare con le informazioni di runtime

... Dichiaro anche che dal momento che un programma potrebbe essere scritto in molti modi, è ancora possibile che un programma scritto in tecnologia A possa superare quello scritto in tecnologia B.

Quando ho presentato questo rapporto per la revisione, il revisore ha dichiarato che non avevo offerto motivi chiari per cui in generale il sovraccarico del processo di interpretazione sarebbe abbastanza grande da poter concludere che le prestazioni della tecnologia B sarebbero state migliori. ...

Questo sarebbe il mio approccio:

In generale, gli interpreti sono compilati, quindi ogni tecnologia interpretata non è altro che una tecnologia compilata se la guardava a basso livello. Pertanto, le tecnologie compilate sono solo di più e con più possibilità non puoi mai peggiorare se sei intelligente (cosa che in generale sei). Dipende da quante informazioni sono disponibili al momento della compilazione e da quante informazioni sono disponibili solo in fase di esecuzione e da quanto sono validi i compilatori e gli interpreti, ma teoricamente dovrebbe essere sempre possibile almeno eguagliare le prestazioni di qualsiasi interprete con un compilatore adatto, solo perché gli interpreti sono fabbricati dai compilatori. Che sia possibile, non significa che sia il caso dei tuoi tecnici A e B.

In pratica, informa il revisore di tutti i benchmark disponibili in cui vengono confrontati i sistemi compilati e interpretati. Quindi chiedigli di suggerire un interprete che batte il tuo algoritmo specifico con codice Assembly ottimizzato.

Si potrebbe forse aggiungere che qualsiasi affermazione di questo genere non aiuta affatto quando si confrontano due specifiche tecniche A e B. Lì la scelta di A e B conta molto, molto di più, che se fossero interpretate o compilate.