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

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.

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.

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.

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.

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%

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.

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.

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.

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.

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)

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.