Quanto velocemente può andare?

In termini di progettazione della lingua, non c'è nulla che dovrebbe rendere Go più lento di Java in generale. In effetti, ti dà più controllo sul layout della memoria delle tue strutture dati, quindi per molte attività comuni dovrebbe essere un po 'più veloce. Tuttavia, l'attuale compilatore primario Go, il programma di pianificazione, il garbage collector, la libreria regexp e molte altre cose non sono particolarmente ottimizzati. Questo sta migliorando costantemente, ma l'attenzione sembra essere quella di essere utile, semplice e abbastanza veloce rispetto alla vincita nei microbenchmarks.

Nel benchmark collegato, Go perde grande a Java nell'albero binario e nel test regexp. Quelli sono test rispettivamente del sistema di gestione della memoria e della libreria regexp. La gestione della memoria di Go potrebbe essere più veloce e sicuramente migliorerà nel tempo e l'attuale libreria standard regexp è 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, è piuttosto difficile confrontare perché il codice Java sembra utilizzare un algoritmo diverso. Il codice Go trarrà sicuramente beneficio dai miglioramenti del compilatore, dello schedulatore e dell'amplificatore, anche se scritti, ma qualcuno dovrebbe riscrivere il codice Go per fare qualcosa di più intelligente se volessimo confrontare più accuratamente.

Java vince nel benchmark di mandelbrot perché è tutto aritmetico e loop in virgola mobile, e questo è un ottimo posto per la JVM per generare codice macchina veramente buono e sollevare cose in fase di runtime. Vai, in confronto, ha un compilatore piuttosto semplice che non solleva, srotola o genera codice macchina veramente stretto al momento, quindi non sorprende che perda. Tuttavia, si dovrebbe tenere presente che i tempi di Java non contano il tempo di avvio della JVM o le molte volte che deve essere eseguito affinché la JVM possa farlo correttamente. Per i programmi a esecuzione prolungata, questo non è rilevante, ma in alcuni casi è importante.

Come per il resto dei benchmark, Java e Go sono fondamentalmente collo-in-collo, con Go che prende molto meno memoria e nella maggior parte dei casi meno codice. Quindi, mentre Go è più lento di Java in una serie di test, Java è piuttosto veloce, Go fa piuttosto bene in confronto, e Go sarà probabilmente notevolmente più veloce nel prossimo futuro.

Non vedo l'ora che gccgo (un compilatore di Go che usa il codegen di gcc) sia maturo; questo dovrebbe rendere Go più o meno in linea con C per molti tipi di codice, che saranno interessanti.

1. Senza nemmeno dire quali problemi sono stati risolti, l'intero benchmark è inutile.
2. JVM e CLR utilizzano entrambi JIT per produrre codice macchina. Non c'è ragione per cui dovrebbe essere più lento. Ti costa solo l'età per l'avvio.
3. Go è stato progettato per build fast . Non hai un sacco di tempo di compilazione e ottimizzazioni del tempo di avvio. Go compila la propria libreria standard al momento dell'avvio di un'app Java.

Potrebbe essere più veloce in fase di runtime? Sì. Andrà mai più veloce in fase di runtime? Non lo so. Forse i compilatori di compilatori aggiungeranno l'ottimizzazione opzionale al costo del tempo di compilazione. Ma non penso che abbiano molto interesse in questo. Funzionano su Google.
Quello che vogliono è un linguaggio che consenta uno sviluppo veloce e che funzioni bene in quello che fanno. L'inferno, anche se quel punto di riferimento era credibile, significherebbe che sono metà della velocità di C e 14 volte più veloce di Python. Questo è più che abbastanza buono.
L'hardware è economico, il codice è costoso. Il codice tende a diventare più grande e più lento man mano che si investe denaro, l'hardware diventa più economico e più piccolo. Vuoi un linguaggio, che non richiede 4 framework e 2000 classi per realizzare qualcosa di utile.
Non c'è nulla di intrinseco nel design di Go, che lo rende lento. Tuttavia c'è qualcosa di intrinseco nei designer di Go, che lo rende più lento del montaggio: buon senso.

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

Infine Benchmark per computer Gioco formato da micro-benchmark che potrebbero non rispecchiare accuratamente molte caratteristiche dei linguaggi misurati e persino mediare impressioni errate. Questo documento di ricerca , recentemente pubblicato da Google offre un panoramica accurata di diverse caratteristiche linguistiche di Go, Scala, Java e C ++ - in particolare la parte "V. Performance Analysis". Quindi, alla fine, Go ha quasi fame di memoria quanto Java (l'81% della memoria di Java) e consuma addirittura il 170% della stessa quantità di memoria di Scala (non è stato possibile trovare sul foglio se il consumo di memoria di JVM è stato preso in considerazione).

Ma ancora una volta, i giovani di Go sono ancora in fase di sviluppo (modifiche API)! Molti miglioramenti arriveranno presto.