Qual è il significato della frase "volevamo che fosse compilato in modo che non bruci la CPU facendo le cose sbagliate".

10

Stavo leggendo questo articolo. Ha il seguente paragrafo.

E Scala si è rivelata veloce? Bene, qual è la tua definizione di veloce? Circa veloce come Java. Non deve essere veloce come C o Assembly. Python non è significativamente più veloce di Ruby. Volevamo fare di più con meno macchine, sfruttando meglio la concorrenza; volevamo che fosse compilato, quindi non sta bruciando la CPU facendo le cose sbagliate.

Sto cercando il significato dell'ultima frase. In che modo il linguaggio interpretato farà fare alla CPU cose "sbagliate"?

performance cpu compilation

— user2434
fonte

3

Chiamare tutto ciò che viene compilato nel codice byte JVM interpretato è un po 'liberale con l'uso.

— Rig

47

Se il codice dice

A = A + 1

il codice compilato fa questo

add A, 1

il codice interpretato fa questo (o qualche variazione)

look up the location of A in the symbol table
find the value of A
see that 1 is a constant
get its value
add the value of A and the value of 1
look up the location of A in the symbol table
store the new value of A

avere un'idea?

— Mike Dunlavey
fonte

3

A volte l'eccessiva semplificazione rende davvero l'immagine più chiara ;-) (solo per essere completo: molti noti interpreti ottimizzano alcuni passaggi, quindi sono a metà strada tra le due "implementazioni" di esempio qui).

— Joachim Sauer,

3

@JoachimSauer: Hai ragione ovviamente. È ancora difficile far funzionare un interprete con meno di un fattore di penalità di 10 velocità rispetto al codice compilato. Se il linguaggio è davvero uno che passa tutto il suo tempo in funzioni compilate subordinate che devono essere chiamate comunque, come librerie matematiche o I / O, il costo dell'interpretazione non è un problema.

— Mike Dunlavey,

1

Questa è una descrizione incredibile

— Jamie Taylor,

13

volevamo che fosse compilato, quindi non sta bruciando la CPU facendo le cose sbagliate.

Sembra che si stiano riferendo a compilato vs interpretato. Molto probabilmente fino all'intera storia di Twitter che sposta le attività di elaborazione in background su Scala (compilato) dopo lo sviluppo iniziale in Ruby On Rails (interpretato).

Una spiegazione del codice compilato vs interpretato qui .

Con una lingua compilata, il codice inserito viene ridotto a un set di istruzioni specifiche della macchina prima di essere salvato come file eseguibile. Con le lingue interpretate, il codice viene salvato nello stesso formato inserito. I programmi compilati generalmente funzionano più velocemente di quelli interpretati perché i programmi interpretati devono essere ridotti alle istruzioni della macchina in fase di esecuzione.

— KrisG
fonte

Felice di darti il tuo primo +1. Benvenuti in P.SE!

— Hayylem,

4

(Potrebbe valere la pena ricordare che Scala - come è su JVM - è tecnicamente solo byte-compilato).

— Hayylem,

Non sapevo che Scala fosse basato su JVM. Significa che probabilmente è stato compilato JIT. In tal caso, perché Twitter non è passato da Ruby on Rails a JRuby? Penseresti che sarebbe una migrazione più semplice con il vantaggio della compilazione.

— KrisG,

3

Stavano anche cercando un modello di concorrenza migliore e avevano problemi con la raccolta dei rifiuti di Ruby. L'articolo lo descrive in dettaglio.

— scrwtp,

9

"Roba sbagliata" qui significa il sovraccarico necessario all'interprete per analizzare ed elaborare il codice. È collegato alla nozione di linguaggi interpretati vs compilati. Esistono diversi modelli di traduzione del codice in uso, che rientrano approssimativamente in una delle seguenti categorie:

Compilazione nativa: il codice sorgente viene compilato direttamente nel codice macchina. Le migliori prestazioni a scapito della portabilità. Comunemente associato a C e C ++,
Compilazione intermedia: il codice sorgente viene compilato in un linguaggio intermedio semplificato (bytecode), che viene successivamente interpretato o compilato (compilazione just-in-time) in codice macchina durante l'esecuzione. Migliore portabilità rispetto al codice nativo, prestazioni migliori della pura interpretazione pur mantenendo alcuni dei lati positivi dell'interpretazione (come il late binding). Gli esempi includono C #, Java e altre lingue destinate a JVM e .NET CLR,
Interpretazione: il codice sorgente non viene tradotto direttamente in codice macchina, ma viene interpretato ed eseguito da un programma interprete dedicato. Gli interpreti variano in raffinatezza, nell'implementazione ingenua tuttavia si riducono all'analisi, all'analisi e all'esecuzione del codice sorgente riga per riga. L'interpretazione consente una maggiore flessibilità rispetto alla compilazione, quindi i linguaggi interpretati fanno un uso più ampio della tipizzazione dinamica o della riflessione, ad esempio. I linguaggi interpretati sono spesso visti come un aumento della produttività degli sviluppatori, in quanto richiedono meno codice di targa e si prestano bene alla prototipazione rapida. L'aspetto negativo è la prestazione ridotta. Comunemente associato a JavaScript, Ruby o Python.

Quindi la scelta tra linguaggio interpretato e compilato si riduce alla domanda, cosa apprezziamo di più, produttività degli sviluppatori o prestazioni? La migrazione descritta nell'articolo sembra seguire la stessa linea di pensiero, con il forte linguaggio di prototipazione Ruby che viene sostituito da Scala basato su JVM a causa di considerazioni sulle prestazioni.

— scrwtp
fonte

-1 il modo in cui la risposta è formulata, sembra troppo semplicistico. Ignora completamente cose come JIT ( compilazione just-in-time ) - il che è il modo in cui Scala investe JVM / CLR

— gnat

Vero. Riscritta la risposta, stava aggiungendo poco all'argomento per così dire.

— scrwtp,

-3

In questo caso ho the wrong stuffinteso la mancanza di sicurezza del tipo nel codice non compilato.

Pertanto, non solo il codice viene interpretato più lentamente, ma è anche più difettoso ...

— Neil Twist
fonte

8

Stai assumendo che le lingue compilate siano sicure per i tipi e quelle interpretate no. Esistono molti esempi di contatori Ad esempio lisp può essere compilato e non è fortemente tipizzato, mentre Haskell può essere interpretato ed è MOLTO sicuro

— Zachary K

1

L'equivalente di "non sicuro" con "più buggy" è FUD spinto dalle persone con prodotti da vendere.

— user16764

1

@ user16764: non è FUD se è vero. IME le persone che spingono sciocchezze in materia di vendita di prodotti sono quelle che cercano di minimizzare il legame tra la tipizzazione dinamica e gli errori. ("È solo un tipo di errore ", ecc.)

— Mason Wheeler,