Quanto velocemente può andare?


39

Go è una delle poche lingue che dovrebbero funzionare "vicino al metal", ovvero è compilata, digitata staticamente ed esegue il codice in modo nativo, senza una VM. Ciò dovrebbe dargli un vantaggio di velocità rispetto a Java, C # e simili. Sembra, tuttavia, che sia dietro Java (vedi il linguaggio di programmazione Shootout )

Suppongo che i compilatori meno maturi siano estremamente responsabili di questo, ma ci sono altri motivi? C'è qualcosa di intrinseco nel design di Go che ne impedisce l'esecuzione più veloce di, per esempio, Java? Ho una visione molto poco sofisticata dei modelli di runtime, ma sembra che almeno in linea di principio dovrebbe essere in grado di funzionare più velocemente di Java, grazie all'esecuzione di codice nativo.


3
Dato un compilatore sufficientemente intelligente (e / o VM e / o compilatore JIT), un determinato linguaggio può sempre andare più veloce (beh, ci sono limiti fisici, ma questo è tutto). Questo truismo ovviamente non aiuta nessuno fintanto che questo compilatore sufficientemente intelligente non è lì. Nota che Java ha già implementazioni sufficientemente intelligenti e incredibilmente intelligenti. Un altro fatto della vita è che l'esecuzione del codice influenza almeno tanto le prestazioni del runtime quanto l'implementazione.

1
Lo capisco, ma mi chiedevo se è ragionevole aspettarsi che la velocità di Go corrisponda / superi, ad esempio Java, mentre il compilatore matura.
Greg Slodkowicz,

17
I linguaggi di programmazione non hanno una velocità. Né implementazioni linguistiche. Un'implementazione di una determinata lingua ha una velocità per un determinato input e questa velocità può dipendere molto dall'input.

8
Svegliami .. prima di andare vai ... WHAM! . Scusa, non ho resistito. Arrivano le bandiere .. ecco venire le bandiere ..
Tim Messaggio

2
@delnan - Oppure è molto più facile dire "Java" che dire "Java (TM) SE Runtime Environment (build 1.6.0_25-b06) VM Server 64-Bit Java HotSpot (TM) (build 20.0-b11 , modalità mista) ":-)
igouy,

Risposte:


46

In termini di design del linguaggio, non c'è davvero nulla che dovrebbe rendere Go più lento di Java in generale. In effetti, ti dà un maggiore controllo del layout di memoria delle tue strutture dati, quindi per molte attività comuni dovrebbe essere un po 'più veloce. Tuttavia, l'attuale compilatore Go principale, lo scheduler, il garbage collector, la libreria regexp e molte altre cose non sono particolarmente ottimizzati. Questo è in costante miglioramento, ma l'obiettivo sembra essere utile, semplice e abbastanza veloce rispetto alla vittoria nei microbenchmark.

Nel benchmark collegato, Go perde molto su Java sull'albero binario e sul test regexp. Quelli sono test del sistema di gestione della memoria e della libreria regexp rispettivamente. La gestione della memoria di Go potrebbe essere più veloce e certamente migliorerà nel tempo e l'attuale libreria regexp standard è un segnaposto per un'implementazione molto migliore che verrà presto. Quindi, perdere su quei due non è sorprendente, e nel prossimo futuro il margine dovrebbe essere più stretto.

Per il benchmark k-nucleotide, è in qualche modo difficile confrontare perché il codice Java sembra utilizzare un algoritmo diverso. Il codice Go trarrà sicuramente beneficio dai miglioramenti del compilatore, dello scheduler e dell'allocatore, anche se scritti, ma qualcuno dovrebbe riscrivere il codice Go per fare qualcosa di più intelligente se volessimo confrontare in modo più accurato.

Java vince nel benchmark mandelbrot perché è tutto aritmetica e loop in virgola mobile, e questo è un ottimo posto per la JVM per generare codice macchina davvero buono e sollevare le cose in fase di esecuzione. Go, in confronto, ha un compilatore piuttosto semplice che attualmente non solleva, srotola o genera codice macchina molto stretto, quindi non sorprende che perda. Tuttavia, si dovrebbe tenere presente che il timing Java non conta il tempo di avvio di JVM o le molte volte che deve essere eseguito affinché JVM lo esegua correttamente. Per i programmi di lunga durata, questo non è rilevante, ma in alcuni casi è importante.

Per quanto riguarda il resto dei benchmark, Java e Go sono sostanzialmente testa a testa, con Go che occupa molta meno memoria e nella maggior parte dei casi meno codice. Quindi, sebbene Go sia più lento di Java in alcuni di questi test, Java è piuttosto veloce, Go fa abbastanza bene in confronto e Go probabilmente diventerà notevolmente più veloce nel prossimo futuro.

Non vedo l'ora di quando gccgo (un compilatore Go che usa il codegen gcc) è maturo; ciò dovrebbe rendere Go praticamente in linea con C per molti tipi di codice, il che sarà interessante.


2
Ben fatto, per capire che è sempre necessario guardare il codice sorgente e controllare cosa si sta facendo!
igouy,


2
Questo è esattamente il tipo di risposta che speravo, grazie!
Greg Slodkowicz,

Molto meno utilizzo di codice e memoria, compila in codice macchina, progettato meglio. Tutto ciò assume lo svantaggio di velocità.
Moshe Revah,

22
  1. Senza nemmeno dire quali problemi sono stati risolti, l'intero benchmark è inutile.
  2. JVM e CLR utilizzano entrambi i JIT per produrre il codice macchina. Non c'è motivo per cui questo dovrebbe essere più lento. Ti costa solo anni per l'avvio.
  3. Go è stato progettato per costruire velocemente . Non hai tonnellate di ottimizzazione del tempo di compilazione e del tempo di avvio. Go compila la propria libreria standard al momento dell'avvio di un'app Java.

Potrebbe andare più veloce in fase di esecuzione? Sì. Go sarà mai più veloce in fase di esecuzione? Non lo so. Forse i costruttori di compilatori aggiungeranno l'ottimizzazione opzionale al costo del tempo di compilazione. Ma non credo che abbiano molto interesse in questo. Lavorano in Google.
Quello che vogliono è un linguaggio che permetta uno sviluppo veloce e che funzioni bene in quello che fanno. Inferno, anche se quel benchmark fosse credibile, significherebbe che sono la metà più veloce di C e 14 volte più veloce di Python. Questo è più che buono.
L'hardware è economico, il codice è costoso. Il codice tende a diventare sempre più grande mentre investi denaro, l'hardware diventa sempre più economico. Volete una lingua, che non richiede 4 framework e 2000 classi per realizzare qualcosa di utile.
Non c'è nulla di inerente al design di Go, che lo rallenta. Tuttavia, c'è qualcosa di intrinseco nei designer di Go, che lo rende più lento dell'assemblaggio: il buon senso.


1
La maggior parte (tutti?) Dei JIT si compila durante il runtime, non quando il codice viene caricato per la prima volta. Questo codice macchina potrebbe non essere affatto generato per un certo codice e può anche essere facilmente invalidato, ad es. Se objsin for (obj : objs) { obj.meth() }ha implementazioni diverse di methvolta in volta e JIT tenta di incorporarlo. Naturalmente, tutto ciò è in realtà un vantaggio nei casi comuni, ma comunque degno di nota.

@delnan: Il V8 JITs qualsiasi codice prima di eseguirlo. Inoltre, LLVM è stato creato pensando a JITting, quindi (con un certo sforzo ovviamente) è possibile eseguire qualsiasi ottimizzazione appena in tempo, che altrimenti si verificherebbe in fase di compilazione. Tuttavia, alcune ottimizzazioni, come l'analisi di escape, funzionano davvero solo con le SIC.
back2dos,

3
>> Senza nemmeno dire quali problemi sono stati risolti << Guarda e scoprirai che quelle pagine web dicono quali problemi sono stati risolti. In effetti, troverai il codice sorgente del programma, i comandi di generazione, i comandi di esecuzione, la versione di implementazione del linguaggio, ya da ya da ya
igouy

10

Ho anche notato che Go era particolarmente lento nel benchmark regex-dna . Russ Cox ha spiegato perché Go non era così performante in questo particolare benchmark . Il motivo è che il pacchetto regexp di Go sta usando un algoritmo di matching diverso che funziona male in questo particolare benchmark ma potrebbe essere molto più veloce in altri benchmark. Anche Ruby, Python e altri linguaggi di scripting utilizzano un'implementazione C di un altro algoritmo di corrispondenza regexp .

Infine, il Linguaggio benchmark del gioco è costituito da micro-benchmark che potrebbero non riflettere con precisione molte caratteristiche dei linguaggi misurati e impressioni sbagliate anche mediare. Questo documento di ricerca, pubblicato di recente da Google, offre una panoramica più accurata di diverse caratteristiche del linguaggio di Go, Scala, Java e C ++ , in particolare la parte "V. Performance Analysis". Quindi, alla fine, Go ha fame di memoria quasi quanto Java (81% della memoria di Java) e consuma anche il 170% della memoria di Scala (non è stato possibile trovare sulla carta se il consumo di memoria di JVM fosse considerato).

Ma ancora una volta, Go è giovane e ancora in fase di sviluppo (modifiche API)! Molti miglioramenti arriveranno presto.


3
>> Questo documento di ricerca, recentemente pubblicato da Google << Non è un documento di ricerca e non è stato pubblicato da Google. È un rapporto sull'esperienza di un dipendente Google presentato al seminario Scala "Giornate della Scala 2011".
igouy,

>> potrebbe non riflettere accuratamente molte caratteristiche dei linguaggi misurati e persino mediare impressioni errate << Questo è altrettanto vero per i programmi di "riconoscimento loop", e probabilmente vale per ogni confronto delle prestazioni tra linguaggi di programmazione diversi. In effetti l'autore ti dice: "Non esploriamo alcun aspetto del multi-threading, o meccanismi di tipo di livello superiore ... inoltre non eseguiamo calcoli numerici pesanti ..."
igouy

@igouy Sulla copertina puoi leggere "Google" e tutto ciò che è rilevante è coperto con riferimenti corrispondenti. Quindi perché non è un "documento di ricerca, pubblicato da Google" se Google viene menzionato con il suo indirizzo di sede? I lavori di ricerca non sono di dominio esclusivamente accademico.
Alex,

Sulla copertina è possibile leggere l'indirizzo postale al quale è possibile contattare l'autore e l'indirizzo e-mail dell'autore. Controlla l'URL del pdf che hai pubblicato. Nota il dominio - days2011.scala-lang.org - il laboratorio della Scala "Giornate della Scala 2011".
igouy,

1

Go è più veloce di Python e un po 'più lento di Java. La mia esperienza approssimativa ha riscontrato che Go è molto più veloce (1-2 ordini di grandezza) di Python e circa il 10-20% più lento di Java. Tuttavia, Go è leggermente più veloce di Java se utilizzato con quad-core (x64). Go è anche molto più efficiente in termini di memoria RAM.

Vorrei aggiungere alcuni punti sul potenziale di prestazioni di Go rispetto a Java e Python. Go consente più cose che fa C, il che consente costantemente a C di superare la maggior parte delle altre lingue. I cache miss sono abbastanza importanti da evitare per codice ad alte prestazioni. La riduzione degli errori nella cache richiede il controllo del layout di memoria delle strutture dei dati. Go ti consente di farlo. Java non lo rende più difficile da evitare la rottura di memoria e cache.

In questo momento Java di solito funziona più velocemente di Go, perché il Garbage Collector Java è molto più sofisticato. Anche se non c'è motivo per cui il Garbage Collector non potrebbe essere molto meglio. La generazione del codice è probabilmente molto meglio per Java al momento. Go ha molte potenzialità per migliorare, ad esempio con il supporto per istruzioni vettoriali ecc.

Quindi penso che sia davvero solo una questione di tempo prima che Go superi il limite di Java. Anche se come con qualsiasi codice di lingua, probabilmente non sarà più veloce automaticamente, essendo scritto in Go. Devi utilizzare le strutture che la lingua ti offre. Direi che Go offre semplicemente più opportunità per ottimizzare il tuo codice.

Comunque, questa è solo l'esperienza di uno sviluppatore.


4
Questa è una domanda di 8 anni e la potenza di calcolo a basso costo l'ha resa praticamente irrilevante. La tua risposta si basa anche sul "tuo sentimento" piuttosto che su dati concreti. Non voglio scoraggiarti, ma ...
Kayaman il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.