Dlaczego Go działa tak wolno (w porównaniu z Javą)?

109

Jak mogliśmy zobaczyć z The Computer Language Benchmarks Game w 2010 roku:

  • Go jest średnio 10 razy wolniejsze niż C
  • Go jest 3x wolniejsze niż Java !?

Jak to możliwe, pamiętając, że kompilator Go tworzy natywny kod do wykonania?
Niedojrzałe kompilatory dla Go? Czy jest jakiś nieodłączny problem z językiem Go?

EDYCJA:
Większość odpowiedzi zaprzecza samoistnej powolności języka Go, twierdząc, że problem tkwi w niedojrzałych kompilatorach.
Dlatego wykonałem własne testy do obliczania liczb Fibonacciego : algorytm iteracyjny działa w Go (freebsd, 6g) z sameprędkością jak w C (z opcją O3). Tępy rekurencyjny działa w Go 2 timeswolniej niż w C (z opcją -O3; z -O0 - to samo). Ale nie widziałem 10-krotnego upadku jak w grze wzorcowej.

Oleg Razgulyaev
źródło
36
Aby być uczciwym, C to ASM w przebraniu, a Java ma obecnie pod maską kilka poważnych optymalizacji.
Matthew Scharley,
16
Być może benchmark również nie odzwierciedla mocnych stron Go. Może się zdarzyć, że inne testy porównawcze są w rzeczywistości szybsze niż to. Poza tym często nie liczy się wydajność, ale czytelność kodu.
extraneon
7
@extraneon: Zgadzam się. Pamiętaj, Go jest przeznaczone dla Google, a Google rutynowo uruchamia kod na 2 milionach rdzeni. Wydaje mi się, że gra Benchmarks wykorzystuje tylko 4 rdzenie.
Jörg W Mittag
4
@extraneon: Generalnie się zgadzam, ale Go został specjalnie zaprojektowany z myślą o szybkości, jak w przypadku „programów wynikowych działa prawie tak szybko, jak porównywalny kod C lub C ++”.
shosti
4
Twoje pytanie zakłada zbyt wiele: „Większość odpowiedzi zaprzecza samoistnej powolności języka Go” to niepoprawne sformułowanie do użycia w pytaniu. Masz pytanie lub chcesz złożyć oświadczenie? Zobacz c2.com/cgi/wiki?HostileStudent, aby zrozumieć swój błąd.
Chris

Odpowiedzi:

102

Kompilatory 6g i 8g nie są specjalnie optymalizujące, więc kod, który generują, nie jest szczególnie szybki.

Są zaprojektowane tak, aby same działały szybko i tworzyły kod, który jest w porządku (jest trochę optymalizacji). gccgowykorzystuje istniejące przebiegi optymalizacji GCC i może zapewnić bardziej przydatne porównanie z C, ale gccgo nie jest jeszcze kompletne.

Dane porównawcze prawie w całości dotyczą jakości wdrożenia. Nie mają one wiele wspólnego z językiem jako takim, z wyjątkiem tego, że implementacja spędza środowisko wykonawcze obsługując funkcje języka, których benchmark tak naprawdę nie potrzebuje. W większości języków kompilowanych wystarczająco sprytny kompilator mógłby teoretycznie usunąć to, co nie jest potrzebne, ale przychodzi moment, w którym ustawiasz demo, ponieważ bardzo niewielu prawdziwych użytkowników języka napisałoby programy, które nie używałyby tej funkcji . Usunięcie rzeczy z drogi bez ich całkowitego usuwania (np. Przewidywanie wirtualnych miejsc docelowych połączeń w skompilowanej JIT Javie) zaczyna być trudne.

FWIW, mój własny, bardzo trywialny test z Go, kiedy się temu przyglądałem (w zasadzie pętla dodawania liczb całkowitych), kod gccgo generował kod pod koniec zakresu pomiędzy gcc -O0i gcc -O2dla odpowiednika C. Go nie jest z natury powolne, ale kompilatory jeszcze nie wszystko. Trudno się dziwić w języku, który ma 10 minut.

Steve Jessop
źródło
7
Co więcej, może się zdarzyć, że programy Go w The Computer Language Benchmarks Game nie są tak zoptymalizowane, jak programy C i Java.
el.pescado
A co z gcc -O0 i gcc -O3? Czy jest w ogóle zamiar, że kompilatory „zrobią wszystko”?
igouy
@igouy: cóż, jestem prawie pewien, że gccgo ma zamiar zbierać śmieci, a obecnie tego nie robi. Nadal jest kilka funkcji, które należy wprowadzić do kompilatorów g, na przykład obecnie nie używają one szczególnie dobrze wątków hosta (w szczególności harmonogram goroutine nie działa z wywłaszczaniem). Poza tym nie znam planów Google, czy kompilatory g będą kiedykolwiek zaciekle optymalizować, czy tylko gccgo to zrobi.
Steve Jessop
1
@xitrium: Myślę, że intencją Go jest to, aby implementacje nie musiały planować współpracy, mogą wyprzedzać, jeśli chcą. Zobacz na przykład code.google.com/p/go/issues/detail?id=543 , który nie został zamknięty jako „bezsensowny, naprawienie tego tak zwanego błędu byłoby sprzeczne z definicją języka Go”, którą powinno być, jeśli Implementacje Go nie mogą wyprzedzać :-) Problem był spotęgowany przez fakt, że domyślnie Go używał tylko jednego wątku hosta, niezależnie od tego, ile goroutines było uruchomionych.
Steve Jessop
6
Odpowiedź może być na razie nieco nieaktualna. Niedawno ukazała się pierwsza beta Go 1.1 , podają, że wydajność skompilowanych programów wzrasta o około 30% do 40%. Niech ktoś powtórzy te testy.
fuz
51

W następnej wersji Go FAQ powinno pojawić się coś podobnego do następującego.

Występ

Dlaczego Go źle wypada w teście X?

Jednym z celów projektowych Go jest podejście do wydajności C dla porównywalnych programów, ale w niektórych testach porównawczych radzi sobie dość słabo, w tym kilka w testach / benchmarkach. Najwolniejsze zależą od bibliotek, dla których wersje o porównywalnej wydajności nie są dostępne w Go. Na przykład, pidigits zależą od pakietu matematycznego o dużej precyzji, a wersje C, w przeciwieństwie do Go, używają GMP (który jest napisany w zoptymalizowanym asemblerze). Testy porównawcze, które zależą od wyrażeń regularnych (na przykład regex-dna), zasadniczo porównują pakiet stopgap regexp Go z dojrzałymi, wysoce zoptymalizowanymi bibliotekami wyrażeń regularnych, takimi jak PCRE.

Gry benchmarkowe wygrywają dzięki rozbudowanemu tuningowi, a wersje Go większości testów wymagają uwagi. Jeśli zmierzysz porównywalne programy C i Go (jednym z przykładów jest odwrotne dopełnienie), zobaczysz, że oba języki są znacznie bliższe w surowej wydajności, niż wskazywałby ten zestaw.

Mimo to jest miejsce na ulepszenia. Kompilatory są dobre, ale mogłyby być lepsze, wiele bibliotek wymaga dużej wydajności, a garbage collector nie jest jeszcze wystarczająco szybki (nawet gdyby tak było, uważanie, aby nie generować niepotrzebnych śmieci, może mieć ogromny wpływ).

A oto więcej szczegółów na temat gry Computer Benchmarks z ostatniego wątku na liście mailingowej.

Zbieranie śmieci i wydajność w gccgo (1)

Zbieranie śmieci i wydajność w gccgo (2)

Należy zauważyć, że komputerowa gra porównawcza to tylko gra. Osoby z doświadczeniem w mierzeniu wydajności i planowaniu wydajności dokładnie dopasowują się do podobnych, realistycznych i rzeczywistych obciążeń; nie grają w gry.

peterSO
źródło
1
A tutaj kilka szczegółów z tego samego wątku, który wyłączyłeś - groups.google.com/group/golang-nuts/msg/2e568d2888970308
igouy
3
Należy zauważyć, że „testy porównawcze to bzdura” - nie tylko testy porównawcze opublikowane jako gra porównawcza - shootout.alioth.debian.org/flawed-benchmarks.php
igouy
18
(i wszyscy…) Jasne, że to „gra” , ale kiedy widzę, że Go jest tylko dwa razy wolniejsze niż najszybszy w tych testach porównawczych, moje pierwsze wrażenie brzmi: „wow, Go wydaje się szybka” , ponieważ wiem, że te testy są wadliwy. Wręcz przeciwnie, kiedy widzę, że Ruby jest 65 razy wolniejszy niż najszybszy, myślę sobie: „nie zamierzam używać Rubiego do mojego kolejnego, intensywnego numerycznie zadania” . Może to więc być „gra”, ale jest w niej trochę prawdy, jeśli wziąć ją z przymrużeniem oka.
SyntaxT3rr0r
Planowanie wydajności ma bardzo ważny aspekt: ​​koszt. To, czy będziesz potrzebować X pudełek, czy 2 * X, robi ostatecznie ogromną różnicę. A ponieważ nikt nie jest w stanie oszacować, co będzie na nich działać w przyszłości, najlepszym rozwiązaniem jest przyjrzenie się różnym obciążeniom. Sprawdziłem kilka ich implementacji i stwierdziłem, że są one w większości w porządku. Myślę, że wyniki można wykorzystać jako podstawę do oszacowań.
Agoston Horvath
Ogólnie rzecz biorąc, rzeczywiste systemy są ograniczone przez IO, a nie przez CPU. Dlatego to, czy Go jest 2x czy 5x, jest wolniejsze, nie robi tak dużej różnicy w planowaniu pojemności, jak przełączanie awaryjne, równoważenie obciążenia, buforowanie, topologia bazy danych i tym podobne. Dlatego aplikacje na skalę YouTube mogą pozwolić sobie na uruchamianie wielu swoich systemów w Pythonie.
Sujoy Gupta
34

Moja odpowiedź nie jest tak techniczna jak u wszystkich innych, ale myślę, że nadal jest aktualna. Widziałem te same testy porównawcze w Computer Benchmarks Game, kiedy zdecydowałem się rozpocząć naukę Go. Ale szczerze uważam, że wszystkie te syntetyczne testy porównawcze są bezcelowe, jeśli chodzi o decydowanie, czy Go jest wystarczająco szybkie dla Ciebie.

Napisałem ostatnio serwer wiadomości w Pythonie przy użyciu Tornado + TornadIO + ZMQ i dla mojego pierwszego projektu w Go zdecydowałem się przepisać serwer w Go. Jak dotąd, po ustawieniu serwera do tej samej funkcjonalności co wersja Python, moje testy pokazują mi około 4,7-krotny wzrost szybkości w programie Go. Pamiętaj, że kodowałem w Go dopiero od tygodnia, a programuję w Pythonie od ponad 5 lat.

Go będzie działać szybciej, gdy będą dalej nad nim pracować, i myślę, że tak naprawdę sprowadza się to do tego, jak działa w rzeczywistej aplikacji, a nie do małych, małych obliczeniowych testów porównawczych. Dla mnie Go najwyraźniej zaowocowało wydajniejszym programem niż to, co mogłem stworzyć w Pythonie. Oto moja odpowiedź na to pytanie.

jdi
źródło
3
Jak myślisz, o ile wolniej będziesz pisać kod w Go niż w Pythonie?
Erik Engheim
7
@AdamSmith - powiedziałbym, że pisałbym kod Go wolniej niż Python tylko dlatego, że piszę Pythona od 7+ lat i tylko trochę Go. Ale jeśli chodzi o Go w porównaniu z innymi statycznie wpisywanymi, kompilowanymi językami, założę się, że napisałbym Go szybciej niż inne. Osobiście uważam, że jest to najbliższe prostocie Pythona z szybkością między C i C ++
jdi
5
Mam podobną historię. Właśnie zacząłem uczyć się Go i według Benchmarks Game, Go jest WOLNIEJSZE niż JavaScript V8. Okazuje się, że mój program, który jest intensywny w operacjach binarnych, działa 10 razy szybciej z niezoptymalizowanym kodem Go niż w wysoce zoptymalizowanej maszynie wirtualnej V8. Go może być wolniejsze niż C w wielu operacjach, jednak nikt nie pisze stron internetowych w C. Go już jest całkowicie opłacalną opcją i powinna być lepsza, gdy pojawiają się nowe biblioteki, frameworki i narzędzia.
jeśli __name__ to None
1
@ user962247 to jest szalone i fałszywe ogólne stwierdzenie. Piszę Go od lat i jest to bardzo szybkie. Nikt nie twierdzi, że pokona C / C ++ / Java w każdym możliwym syntetycznym teście porównawczym. Ale na niektórych wygrywa (patrz strona z grami testowymi). Weź to od kogoś, kto od lat pisze kod produkcji Go. Jest szybki i produktywny.
jdi
6

Rzeczy się zmieniły.

Myślę, że obecną poprawną odpowiedzią na twoje pytanie jest zakwestionowanie pojęcia, że ​​idź jest wolny. W czasie twojego zapytania twój osąd był uzasadniony, ale od tego czasu go zyskał wiele uwagi pod względem wydajności. Teraz nadal nie jest tak szybki jak C, ale nie jest prawie 10 razy wolniejszy, w ogólnym sensie.

Gra z testami językowymi

W chwili pisania tego tekstu:

source  secs    KB      gz      cpu     cpu load

reverse-complement
1.167x
Go      0.49    88,320  1278    0.84    30% 28% 98% 34%
C gcc   0.42    145,900 812     0.57    0% 26% 20% 100%

pidigits
1.21x
Go      2.10    8,084   603 2.10    0% 100% 1% 1%
C gcc   1.73    1,992   448 1.73    1% 100% 1% 0%

fasta
1.45x
Go      1.97    3,456   1344    5.76    76% 71% 74% 73%
C gcc   1.36    2,800   1993    5.26    96% 97% 100% 97%

regex-dna
1.64x
Go      3.89    369,380 1229    8.29    43% 53% 61% 82%
C gcc   2.43    339,000 2579    5.68    46% 70% 51% 72%

fannkuch-redux
1.72x
Go      15.59   952 900 62.08   100% 100% 100% 100%
C gcc   9.07    1,576   910 35.43   100% 99% 98% 94%

spectral-norm
2x
Go      3.96    2,412   548 15.73   99% 99% 100% 99%
C gcc   1.98    1,776   1139    7.87    99% 99% 100% 99%

n-body
2.27x
Go      21.73   952 1310    21.73   0% 100% 1% 2%
C gcc   9.56    1,000   1490    9.56    1% 100% 1% 1%

k-nucleotide
2.40x
Go      15.48   149,276 1582    54.68   88% 97% 90% 79%
C gcc   6.46    130,076 1500    17.06   51% 37% 89% 88%

mandelbrot
3.19x
Go      5.68    30,756  894 22.56   100% 100% 99% 99%
C gcc   1.78    29,792  911 7.03    100% 99% 99% 98%

Chociaż cierpi brutalnie w benchmarku drzewa binarnego:

binary-trees
12.16x
Go      39.88   361,208 688 152.12  96% 95% 96% 96%
C gcc   3.28    156,780 906 10.12   91% 77% 59% 83%
tiffon
źródło
Jest teraz na równi z Javą, ale czy Go nie został utworzony wyraźnie, aby był szybszy niż Java, a jednocześnie był używany do tych samych rzeczy (aplikacje sieciowe po stronie serwera)?
MaxB,
1
@MaxB nie, nie został stworzony w celu bycia szybszym niż Java. Został stworzony w celu uzyskania dobrej wydajności, szybszej kompilacji niż C ++ oraz łatwiejszej i natywnej współbieżności, aby umożliwić programistom większą produktywność. Pokonanie szybkości działania innych języków nie było czynnikiem napędzającym.
jdi
5

Pomimo niezbyt dobrej wydajności Go na temat wykorzystania cykli procesora, model współbieżności Go jest na przykład znacznie szybszy niż model wątków w Javie i może być porównywalny z modelem wątków C ++.

Zwróć uwagę, że w teście pierścienia wątków Go było 16x szybsze niż Java. W tym samym scenariuszu Go CSP był prawie porównywalny z C ++, ale zużywał 4x mniej pamięci.

Wielką siłą języka Go jest jego model współbieżności, komunikowanie procesów sekwencyjnych, CSP, określony przez Tony'ego Hoare'a w latach 70-tych, który jest prosty we wdrożeniu i dostosowany do bardzo współbieżnych potrzeb.

DLopes
źródło
2

Istnieją dwa podstawowe powody, dla których Java jest szybsza niż Go i C ++ oraz może być szybsza niż C w wielu przypadkach:

1) Kompilator JIT. Może wbudowywać wywołania funkcji wirtualnych na wielu poziomach, nawet z klasami obiektowymi, w oparciu o profil środowiska wykonawczego. Nie jest to możliwe w języku kompilowanym statycznie (chociaż może pomóc nowsza ponowna kompilacja oparta na zarejestrowanym profilu). Jest to bardzo ważne w przypadku większości testów porównawczych, które obejmują powtarzalne algorytmy.

2) GC. Alokacja pamięci oparta na GC jest prawie bezpłatna w porównaniu do malloc. A „bezpłatna” kara może być amortyzowana przez cały czas działania - często jest pomijana, ponieważ program kończy działanie, zanim wszystkie śmieci będą musiały zostać zebrane.

Istnieją setki (tysiące?) Niezwykle utalentowanych programistów, dzięki którym GC / JVM jest wydajne. Myślenie, że potrafisz „kodować lepiej niż oni wszyscy”, jest głupotą. U podstaw leży problem ludzkiego ego - ludziom trudno jest zaakceptować, że przy odpowiednim przeszkoleniu przez utalentowanych ludzi komputer będzie działał lepiej niż ludzie, którzy go zaprogramowali.

Przy okazji, C ++ może być tak samo szybki jak C, jeśli nie używasz i nie korzystasz z funkcji OO, ale na początku jesteś prawie blisko programowania w C.

Co najważniejsze, „różnice prędkości” w tych testach są zwykle bez znaczenia. Koszty we / wy są o rzędy wielkości większe niż różnice w wydajności, a zatem właściwe projekty, które minimalizują koszty we / wy, zawsze wygrywają - nawet w języku interpretowanym. Bardzo niewiele systemów jest związanych z procesorem.

Na koniec, ludzie nazywają „komputerową grę porównawczą” jako „miernik naukowy”. Testy są całkowicie błędne, na przykład, jeśli przeglądasz testy Java dla nbody. Kiedy uruchamiam testy na tym samym systemie operacyjnym / sprzęcie, otrzymuję około 7,6 sekundy dla Javy i 4,7 sekundy dla C - co jest rozsądne - a nie czterokrotne spowolnienie, które zgłaszają testy. To przynęta na kliknięcia, fałszywe wiadomości, mające na celu generowanie ruchu w witrynie.

Na koniec, ostatnia uwaga ... Przeprowadziłem testy używając Go i trwało to 7,9 sekundy. Fakt, że po kliknięciu Go, porównuje ją z Javą, a po kliknięciu Java porównuje ją z C, powinien być czerwoną flagą dla każdego poważnego inżyniera.

Aby zobaczyć rzeczywiste porównanie Java, Go i C ++, zobacz https://www.biorxiv.org/content/10.1101/558056v1 alert spoilera, Java jest najlepsza pod względem surowej wydajności, a Go wychodzi na szczyt dzięki połączonemu użyciu pamięci i czas ściany.

Robert Engels
źródło
źle. C ++ JEST tak samo szybki jak C, zwłaszcza gdy używasz OOP, to jest jego metryka urodzenia. więcej abstrakcji (jak w klasach) BEZ ŻADNEJ DEGRADACJI WYDAJNOŚCI PRACY, Z ZEROWĄ PAMIĘCIĄ DODATKOWYCH BYTÓW. jeśli tego nie wiesz, baw się dalej z java, c #, go, python, et cetera
// Btw, C ++ może być tak samo szybkie jak C, jeśli nie używasz i nie korzystasz z funkcji OO //, ale na początku jesteś bardzo blisko programowania w C //. jeśli tak mówisz, masz bardzo mało pojęcia o c ++, dla własnego dobra, nie używaj go. c i c ++ nienawidzą magii i średniowiecznych umysłów, przesądnych z natury, tak jak słyszałem, przeczytaj to w Internecie, to musi być prawda ... trzymaj się z daleka od c i c ++, oni cię odgadną przyjacielu (szczera rada)
c jest przodkiem c ++. wiele osób nadal go używa ... c ++ to lepsze c, w którym można zrobić więcej bez płacenia ceny. autorzy java, c # i go nie dostali tego, cóż, oczywiście, tak, ale co mogą z tym zrobić?!? to samo dotyczy zgodności z istniejącym (c) kodem. prawdziwe oceany kodu C! python to fajna zabawka, miłej zabawy, żałuję, że nie zrobili tego dobrze, ale nie, zen Pythona powinien zaczynać się od „kompilator jest twoim przyjacielem” ...
>> pokazuje wykorzystanie procesora na poziomie 30% dla programu Java. << Nie —— "1% 0% 0% 100%".
igouy
1
@igouy Przyznaję, że jest to błąd, który prawdopodobnie popełniłem - kiedy zobaczyłem obciążenie, interpretowałem termin `` obciążenie systemu '' i zakładając, że użytkownik / system / io / idle - mój błąd i był poważny.
robert engels
1

Myślę, że często pomijanym faktem jest to, że kompilacja JIT może być> kompilacją statyczną, szczególnie w przypadku funkcji lub metod związanych z późnym wiązaniem (runtime). Hotspot JIT decyduje w RUNTIME, które metody wbudować, może nawet dostosować układ danych do rozmiaru / architektury pamięci podręcznej procesora, na którym obecnie działa. Ogólnie C / C ++ może nadrobić zaległości (i ogólnie nadal będzie działać lepiej), mając bezpośredni dostęp do sprzętu. W przypadku Go rzeczy mogą wyglądać inaczej, ponieważ są bardziej wysokopoziomowe w porównaniu do C, ale obecnie brakuje systemu / kompilatora optymalizacji czasu wykonywania. Mój instynkt podpowiada mi, że Go może być szybsze niż Java, ponieważ Go nie wymusza tak bardzo podążania za wskaźnikami i zachęca do lepszej struktury danych, lokalność + wymaga mniejszej alokacji.

R.Moeller
źródło
1

W rzeczywistości Go jest nie tylko eleganckie i wydajne w czasie projektowania, ale także bardzo wydajne w czasie wykonywania. Kluczem jest użycie odpowiedniego systemu operacyjnego, czyli LINUX. Wyniki profilowania wydajności w Windows i Mac OS są, z braku lepszego słowa, o jeden lub dwa rzędy wielkości gorsze.

Dan Marinescu
źródło
0

pod linuxem środowisko uruchomieniowe go jest super szybkie, doskonale porównywalne z c / c ++. środowisko uruchomieniowe go pod windows i unix nie są w tej samej lidze

Porównanie z Javą nie jest tak ważne, go jest przeznaczone zarówno do tworzenia systemów, jak i aplikacji (ponieważ java jest bardziej jak niebieski kołnierz tylko do tworzenia aplikacji). nie będzie wprowadzać szczegółów, ale kiedy rzeczy takie jak kubernetes są zapisywane w go, zdajesz sobie sprawę, że nie jest to zabawka przyjazna dla konsultantów przedsiębiorstwa

Nie pamiętam, żeby google wspominało choć raz o kompromisie, o którym pan mówi. go jest dobrze zaprojektowany, prosty, elegancki i wydajny do projektowania programów na poziomie systemu i aplikacji, ma wskaźniki, wydajną alokację i zwalnianie pamięci, pozwala uniknąć komplikacji wynikających z tak łatwego do pominięcia dziedziczenia implementacji, dając ci wspólne procedury i inne nowoczesne sposoby pisania aplikacji o wysokiej wydajności w czasie i budżecie. znowu, go jest super szybki pod Linuksem, do czego został zaprojektowany (bardzo się cieszę, że tak)

Dan Marinescu
źródło
-4

Zarówno Java, jak i C są bardziej przejrzyste dzięki swoim definicjom danych i metod (funkcji). C jest typowany statycznie, a Java jest mniej podatna na model dziedziczenia. Oznacza to, że sposób obsługi danych jest prawie określony podczas kompilacji.

Go jest bardziej niejawny z definicjami danych i funkcji. Wbudowane funkcje mają bardziej ogólny charakter, a brak hierarchii typów (takich jak Java lub C ++) powoduje, że Go ma niekorzystny wpływ na szybkość.

Pamiętaj, że celem Google dla języka Go jest uzyskanie akceptowalnego kompromisu między szybkością wykonywania a szybkością kodowania. Myślę, że trafiają w dobry słodki punkt we wczesnych próbach, a sytuacja poprawi się tylko wtedy, gdy wykonasz więcej pracy.

Jeśli porównasz Go z bardziej dynamicznie wpisywanymi językami, których główną zaletą jest szybkość kodowania, zobaczysz przewagę szybkości wykonywania Go. Go jest 8 razy szybsze niż Perl i 6 razy szybsze niż Ruby 1.9 i Python 3 w tych testach porównawczych, których użyłeś.

W każdym razie, lepszym pytaniem jest: Go to dobry kompromis między łatwością programowania a szybkością wykonywania? Moja odpowiedź brzmi: tak i powinno być lepiej.

Bill C.
źródło
20
„brak hierarchii typów (takich jak Java lub C ++) powoduje pogorszenie szybkości działania Go” - co?
Erik Kaplun,
6
„Go jest bardziej niejawne dzięki definicjom danych i funkcji”. Błędny. Czy masz na myśli, jak typy mogą implementować metody, nie mówiąc o tym wprost? Kompilator wykrywa typ - członkostwo w interfejsie. To jest szybkie. „Funkcje wbudowane mają bardziej ogólny charakter” nie, funkcje wbudowane są, jak wszystko inne, kompilowane. To samo dzieje się z szablonami C ++. „Brak hierarchii typów (takich jak Java czy C ++) powoduje pogorszenie szybkości działania Go” - niepoprawne, hierarchia typów nie ma nic wspólnego z wykonywaniem w czasie wykonywania.
Malcolm,