Technologiczna bieda kompilatora Go

31 komentarzy do “Technologiczna bieda kompilatora Go”

1. Nie samym wynikowym kodem asm kompilator żyje ;), szczególnie, gdy za cel ma się produkowanie oprogramowania głównie wielowątkowego.

   Odpowiedz

2. section .text
   global _start
   _start:

   ; write
   mov rax,1
   mov rdi,1
   mov rsi,msg
   mov rdx,len
   syscall

   ; exit
   mov rax,60
   xor rdi,rdi
   syscall

   section .data
   msg db „Hello, 世界”,10
   len equ $-msg

   http://pastebin.com/KicFq83m

   Odpowiedz

3. @antek: Co ma wielowątkowość do miernej jakości kodu wynikowego? Jakby wszyscy myśleli tak jak ty, to kompilatorów nikt by nie rozwijał… bo po co? A tak mamy LLVM + clang-a, Intel ICC, które zmiatają ten mierny kompilator Go bez większego problemu oferując wielowątkowe programowanie oparte np. na OpenMP.

   @OoOo: a teraz przeczytaj jeszcze raz co napisałem, bo mi ręce opadają. W ogóle mówisz, że twój kod przejdzie kodując te chińskie znaki unicode jako db i deklarując ich rozmiar na 1 bajt? Chodziło o przepisanie tego kodu z Go na bardziej zoptymalizowaną wersję.

   Odpowiedz

4. Dobra, ale w jaki sposob powstal taki kod? Moze to ma cos na celu, albo jest skutkiem ubocznym czegos.

   Odpowiedz

   • @MarMar: Ty na serio? Powstał w wyniku kompilacji kodu Go i C do kodu wynikowego ;), jest skutkiem ubocznym nieudolnych zdolności optymalizacyjnych kompilatora Go. Nic więcej. Nie ma niczego na celu.

     Odpowiedz

5. „Jeśli i wy doceniacie piękno assemblera i gardzicie lipnym kodem wpiszcie w komentarzach waszą wersję tej funkcji…” – ja to zrozumiałem, że chcesz hello world w asm.

   A co do wykonania wklejonego kodu to:
   $ nasm -f elf64 *.s && ld *.
   $ ./a.out
   Hello, 世界

   Odpowiedz
6. Pingback: Technologiczna bieda kompilatora PureBasic - Security News

7. @bartek: ale co to za porównania ;). Go osiągnęło stabilność w 2012r, a najmłodszy clang/LLVM istnieje od 10 lat i dopiero od niedawna zyskał popularność, jako alternatywa gcc, pomijając zupełnie fakt, że jest to czysty kompilator, bez projektu nowego języka.

   Gdyby każdy myślał jak ja, to każdy skupiałby się na jednej rzeczy, a nie na wszystkich jednocześnie, czyli tak jak jest teraz – twórcy Go skupiają się na języku a nie na kompilatorze, a twórcy kompilatorów skupiają się na kompilatorach, nie językach 🙂

   Odpowiedz

   • @Antek: Zauważ, że ja słowem nie wspomniałem o języku programowania Go jako takim.

     Analizowałem jedynie kompilator i jego kod wynikowy.

     Język Go posiada dedykowany kompilator, który także ktoś zbudować musiał.

     Za wszystkim stoi Google z niewyobrażalnym potencjałem ludzkim i finansowym, a mimo tego takiego potworka wyprodukowali, dlatego w ogóle przysiadłem do tego tematu, bo wydało mi się to po prostu dziwne.

     A jak wspomniałem lubię grzebać się w low levelu 🙂

     Odpowiedz

8. Może na linuksie wygląda to lepiej. Co oni nie przepuszczają tego przez jakies optymalizatory z LLVM? Ale generalnie od komilatora nie wymaga sie jakies super wydajnosci czy urody, wazne zeby buildboty nadążały z produkcją binarek. Google i tak ma rozproszone systemy do budowania.

   Odpowiedz

   • @MarMar: No ale co z tego, że Google ma rozproszone systemy budowania? Jak ty masz ten kompilator u siebie i chcesz sobie zbudować coś. LLVM to to nie jest najwyraźniej. Czemu na linuxie ma to inaczej wyglądać, czyżby tam instrukcje x86 nagle inaczej wyglądały?

     Odpowiedz

9. Słaba jakość może być skutkiem istnienia takich właśnie systemów 😉

   Odpowiedz

10. @MarMar: może coś więcej w tym temacie, skoro masz jakieś informacje?

    Odpowiedz

11. Jest ta trochę przydługa prezentacja: https://www.youtube.com/watch?v=2qv3fcXW1mg

    Slajd około 53 minuty: 57 sekundy średnio na budowanie od zera (cache jest na serwerach, ale jak rozumiem wszystko trzeba przesłać do klienta), incremental builds 20 sekund, i to wszystko dla dużych projektów tj. chromium.

    Odpowiedz

12. @bartek: „Język Go posiada dedykowany kompilator, który także ktoś zbudować musiał.”

    Tak, ale wszystko wskazuje, że ten kompilator jest po prostu stary – ma z 5 lat lub nawet więcej. I jest raczej przenośny, więc nie ma takiej wiedzy, że pod windowsami cli jest zbędne. Po prostu wzięli, co było (coś z Plan9) i dostosowali [tak piszą w FAQ].

    Poza tym pytanie, czy jest sens to coś poprawiać, skoro powstaje front na GCC, który ma świetną optymalizację by default.

    Odpowiedz

    • @wmu: kompialtor Go nie ma 5 lat. Sprawdź sam:

      go1.3 (released 2014/06/18) – https://golang.org/doc/go1.3

      „The latest Go release, version 1.3, arrives six months after 1.2, and contains no language changes. It focuses primarily on implementation work, providing precise garbage collection, a major refactoring of the compiler tool chain…”

      Ten syf z powtarzaniem CLD to nie jedyne co wskazałem.

      Odpowiedz

13. W jakim manualu jest napisany by unikać xchg? W manualu Intela znalazłem tylko, że przy wymianie z pamięcią zawsze ustawia sygnał lock i jest przydatna w implementacji semaforów (co prawda tylko pobieżnie przeglądnąłem, ale zalecenie by nie używać jakiejś instrukcji powinno bić po oczach).

    Co do TEB, to kod generowany przez Microsoft Visual C++ używa bezpośrednio kilku pól tej struktury, a biblioteka standardowa jeszcze kilku następnych, więc co do części pól można mieć pewność, że na pewno nie ulegną zmianie (chyba Microsoft nie chciałby, żeby na którejś wersji Windowsa ot tak przestały działać programy skompilowane jego narzędziami)

    Odpowiedz

    • @R: W żadnym nie jest napisane żeby nie używać, możesz używać czego chcesz, jednak spójrz sobie na czasy wykonywania instrukcji XCHG i zrozumiesz dlaczego żaden kompilator nie używa tej instrukcji poza implementacją semaforów (czyli jak piszesz bezpośrednio z wymianą z pamięcią), jednak xchg reg1,reg2 nigdzie nie znajdziesz poza badziewnymi kompilatorami jak ten z Go.

      Z tym TEB masz rację. Przejrzałem źródła CRT i nic innego nie znalazłem oprócz SEH i StackBase, tak się akurat składa, że to 2 pierwsze pola struktury TEB no i tego raczej nigdy nie zmienią, co do reszty pól to już nie byłbym taki pewien, struktura jest nieudokumentowana oficjalnie więc po co cisnąć się do używania czegoś co może w każdej kolejnej wersji Windows ulec zmianie?

      Odpowiedz

14. @bartek: ok, popatrzyłem na historię generatora kodu dla x86 (src/cmd/6c) i widać, że jednak coś tam robią.

    Co do xchg nie masz do końca racji, ta instrukcja jest bardzo szybka w nowych procesorach gdy działa tylko na rejestrach (1,5 cykli opóźnienia, 0.25 cykli przepustowości).

    Używanie nieudokumentowanych pól zwykle ma jakiś cel, nikt tego nie robi bo można. 🙂 Kolega np. ustawia nazwy wątków, które ładnie wyświetlają się w debuggerze; łatwiej się zorientować, co się wywala.

    Odpowiedz

    • @wmu: może robią, jednak rezultaty jak widzisz nie są zachwycające.

      Co do xchg i nowych procesorów, np. na AMD xchg jest wykonywanie w trybie VectorPath, w przeciwieństwie do instrukcji wykonywanych w trybie DirectPath, które mogą być dekodowane kilka na raz, nie bez przyczyny trudno znaleźć taką instrukcję w binarkach, ja szczerze mówiąc jak siedzę w deadlistingach tyle lat, oprócz semaforów implementowanych na xchg reg,[mem] nie widziałem w kompilatorach VC, Borlanda, Delphi żeby gdziekolwiek używane były instrukcje xchg reg,reg. Poza tym konieczność użycia xchg często świadczy o źle zaprojektowanym / zoptymalizowanym fragmencie kodu co widać po serii wielu xchg w podanym przykładzie dla Go.

      Nazwy wątków i ich ustawianie jest akurat udokumentowane oficjalnie na MSDN

      http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx

      Nie trzeba korzystać z TEB i pvArbitrary.

      Odpowiedz

15. @bartek: co do użycia xchg to też nie widziałem, a siedzę na MSVC i GCC… sam nie używałem xchg od nie wiadomo ilu lat. Dlatego bardzo się zdziwiłem, że xchg reg, reg został przez intela tak miło potraktowany. 🙂

    Z tym użyciem nieudokumentowanych coś poplątałem, w każdym razie koledzy się chwalili, że robili jakieś nielegalne rzeczy. 🙂 Ale teraz jestem naocznym świadkiem, jak nowy kolega przygotowuje przyzwoite API na nieudokumentowane bebechy MSVC. To nam pomoże, a ryzyko, że się może zepsuć po aktualizacji mamy wliczone.

    Odpowiedz

    • @wmu: a to heheszki :), ja się wyleczyłem z używania undocumented features w trakcie pisania exe-protectora, połowa metod antydebug na coraz nowszych systemach Windows wywalała się, druga połowa okazała się zupełnie nieskuteczna, a jeszcze jedna oprócz wykrywania debuggerów wykrywała przypadkowo VMware (co moim klientom nie bardzo się spodobało). Korzystanie z PEB i TEB jak już robię to bardzo ostrożnie i po uprzednim sprawdzeniu wersji Windows, bo też cuda nie raz wychodziły np. przy opcjach bootowania z parametrem /3GB.

      Odpowiedz

16. Bez urazy Bartoszu, ale Twoja krytyka kompilatora Go w tym poście jest mniej więcej tak samo głęboka jak Twoja krytyka Kościoła Katolickiego w innym poście. Przyczepiłeś się kilku niskopoziomowych szczegółów – ignorując kompletnie okoliczności powstania Go oraz priorytetów jakie zostały postawione przed tym językiem. A jednym z głównych priorytetów Go jest szybkość kompilacji, prostota języka oraz łatwa integracja systemów (stąd zarąbiscie rozwiązana współbieżność – z tym OpenMP to już strzeliłeś kulą w płot; to się nawet nie umywa do modelu Go; ba, ten archaizm się w ogóle nie umywa do niczego w nowoczesnych językach wysokopoziomowych np. Erlang, Scala, Closure).

    Dlatego porównywać Go do innych kompilatorów (np. gcc albo VS) będziesz mógł, jak te kompilatory będą kompilować porównywalnie szybko jak Go, a języki będą oferować podobne udogodnienia. Póki co są one koszmarnie powolne, są jednymi z najpowolniejszych kompilatorów – nawet kompilator Scala krytykowany często za powolność jest przy nich demonem szybkości. Porównujesz po prostu gruszki z jabłkami.

    Zresztą, abstrahując nawet od nieuwzględnienia przez Ciebie kontekstu, Twoja krytyka jest od strony technicznej bardzo biedna. W dużej części postu wałkujesz to nieszczęsne xchg albo nadmiarowe xor/cmp, które nie zeżre nawet 1 cyklu CPU w większości przypadków. W innej części postu rozpaczasz nad dodatkową warstwą abstrakcji nad WinAPI i dodatkowym callem + kilkoma instrukcjami push/pop, co jest śmiesznie niskim narzutem na typowy czas wywołania funkcji WinAPI; nikt tego nie zauważy. Pozostałe części to tylko wywody nad tym, że ktoś użył instrukcji nieużywanej gdzieś indziej (ud2) i zmarnował kilka bajtów, co jest bez najmniejszego znaczenia w projektach, do których używa się Go. Oczywiście, z każdą z tych rzecz *masz jakąś tam rację*, tylko że to jest zpełnie bez znaczenia. Sprawia to ogólnie wrażenie, jakbyś chciał strasznie zaszpanować znajomością książki opcodów (czego nie kwestionuję).

    Jak już chcesz krytykować kompilator pod względem jakości generowanego kodu, to powinieneś skupić się na rzeczach, które *mają duże znaczenie* i przekładają się na wydajność: inlining kodu i danych, rozwijanie i wektoryzacja pętli, alokacja rejestrów, prefetching, aliasing, usuwanie null/range checków oraz optymalizacje związane z zagadnieniami wysokopoziomowymi np. lock-elision / biased-locking / unikanie alokacji dynamicznej itp. Ale tego nie zrobiłeś, bo to jednak wymaga znacznie większej wiedzy o kompilatorach, CPU, pamięci, językach programowania (zwłaszcza wysokopoziomowych) niż tylko znajomość zestawu instrukcji procesora oraz znacznie więcej czasu na przygotowanie.

    „Za wszystkim stoi Google z niewyobrażalnym potencjałem ludzkim i finansowym, a mimo tego takiego potworka wyprodukowali, dlatego w ogóle przysiadłem do tego tematu, bo wydało mi się to po prostu dziwne.”

    Wydało Ci się to dziwne, bo masz nikłe doświadczenie w zespołowych projektach komercyjnych, a tym bardziej w projektach tej skali, co robi Google. Podejrzewam też, że w życiu nie napisałeś kompilatora, a jeśli już to jedynie jako ćwiczenie, a nie kompilator działający w projekcie produkcyjnym, który ma realnych użytkowników.

    Ale skoro się dziwisz, to Ci troszkę przybliżę temat. Google traktuje Go jako projekt eksperymentalny, stworzony głównie na własne potrzeby (jeden z bardzo wielu zwariowanych projektów, obok samojeżdżących samochodów, internetu opartego na balonach i okularów z wbudowanym smartfonem). Wszystkie krytyczne systemy Google, na których Google zarabia pieniądze *nie są napisane w Go* i długo nie będą. Google jest świadom niskiej wydajności kodu produkowanego przez Go (w porównaniu z Javą i C++), nigdzie nie zaleca używania Go do projektów wymagających wysokiej wydajności i nigdy wydajność ani wielkość kodu wynikowego Go nie była priorytetem dla Google, bo Go do takich rzeczy nie służy. Google zarządzają pragmatycy, a nie idealiści, i nikt nie będzie pakował milionów dolarów w kompilator języka, tylko dlatego bo jeden koleś gdzieś na Internetach nie lubi instrukcji ud2 albo xchg, albo nawet dlatego, że to samo napisane w Javie/C++ wykonałoby się 10x szybciej. Po prostu, jak wydajność będzie problemem, użyją Javy/C++; a jeśli mimo wszystko ludzie będą bardzo chcieli mieć szybkie Go, to kompilator pozostawią społeczności (i tak się właśnie dzieje). Teraz kumasz?

    Podsumowując, Twoja krytyka wygląda mniej więcej tak: Pewna firma wyprodukowała samochód do jazdy po mieście, a Ty się czepiasz, że nie zrobili odpowiedniego spoilera a silnik nie ma turbo i nie da się przez to tym autem jechać 250 km/h na torze wyścigowym. W skrócie: bez sensu.

    Odpowiedz

    • @Piotr: tytuł wpisu mówi o kompilatorze, nie o języku. Drobne szczegóły *mają znaczenie* czy Ci się to podoba, czy nie. Dlaczego kompilatory Microsoft czy Intela nie produkują takiego badziewnego kodu, skoro jak mówisz 1 czy 2 cykle tu i tam „nie mają znaczenia”? Bo po prostu mają znaczenie i główni gracze na tym rynku doskonale o tym wiedzą. Z twojego komentarza wynika, że wydajność i jakość kodu nie liczą się, gdy jakiś język oferuje dodatkowe funkcje programiście. Tylko na co komu te funkcje jak kod będzie po prostu działał wolno, sam mówisz, że Google nie używa Go do żadnego poważnego projektu (!).

      „Książka” z opcodami to ciekawa lektura i jak widać niektórzy powinni jeszcze raz do niej zajrzeć, zwłaszcza jeśli komentują analizę kompilatora, nie mówiąc o twórcach kompilatorów.

      Skoro masz takie doświadczenie w komercyjnych projektach grupowych, proponuję abyś ze swoim akademickim dorobkiem 3 programów, zapukał do drzwi Intela lub Microsoft i przekonał ich o swojej genialnej teorii paru cykli bez znaczenia i że przez te wszystkie lata marnowali czas na dopracowywanie kompilatorów.

      Reasumując – mamy sobie język Go z zajebistymi funkcjami, wielowątkowością i nikt go nie używa do poważnych projektów. Gorszej rekomendacji chyba nie można mieć.

      Odpowiedz

17. > Dlaczego kompilatory Microsoft czy Intela nie produkują takiego badziewnego kodu, skoro jak mówisz 1 czy 2 cykle tu i tam “nie mają znaczenia”?

    1. Istnieją na rynku znacznie dłużej niż kompilator Go. Pierwsze wersje gcc też produkowały beznadziejny kod. Pamiętam czasy jak gcc regularnie dostawało bęcki od icc i to tak gdzieś 2x-3x. Teraz sytuacja się wyrównała, a nawet odwróciła. Zresztą, ostatnio widziałem jak gcc dostało bęcki na ponad 2x od JVM w wektoryzacji pętli… 😀 Więc gcc, też jeszcze daleko do optymalności.

    2. Język, który kompilują jest językiem znacznie niższego poziomu – kompilator ma znacznie mniej do optymalizowania i znacznie bardziej związane ręce; więc może się skupić na szczegółach takich jak pojedyncze instrukcje, bo „ciekawe” optymalizacje leżą niemalże całkowicie w gestii programisty.

    3. Mają inne priorytety – przedkładają jakość kodu wynikowego nad szybkość kompilacji.

    Poza tym 1 czy 2 cykle bardzo rzadko mają znaczenie – obecnie optymalizacja kodu to właściwie wyłącznie:
    a) optymalizacje algorytmiczne
    b) optymalizacje dostępu do dysku,
    c) optymalizacje dostępu do pamięci (cache awareness)
    d) współbieżność/równoległość i optymalizacja (unikanie) blokad

    Zły algorytm to mogą być miliony zmarnowanych cykli CPU, contended lock to setki tysięcy cykli mogą być, uncontended lock to 200-1000 cykli CPU, CAS to 50-200 cykli, cache L2 miss to 500-1000 cykli, cache L1 miss to 20-50 cykli, źle przewidziany skok to 7-15 cykli. A Ty się na jakimś głupim xchg skoncentrowałeś, które zajmie 0 cykli w większości sytuacji, bo poleci w równoległym potoku, albo instrukcjami, które w ogóle nie są wykonywane (ud2).

    „nikt go nie używa do poważnych projektów”
    Nadinterpretujesz to co napisałem. Nikt Go nie używa do projektów wymagających bardzo wysokiej wydajności np. obliczeń numerycznych. Tak jak nikt nie używa Pythona do projektów, gdzie liczy się równoległość (GIL). Nie zmienia to faktu, że są zastosowania w bardzo poważnych projektach, gdzie Go i Python sprawdzą się znacznie lepiej niż C/C++.

    A jakość produkowanego kodu to tylko jedno z bardzo wielu kryteriów; najczęściej nienajważniejsze. Większość projektów ma być wystarczająco szybka, a nie najszybsza, za wszelką cenę. Jakby było tak ważne jak piszesz, to wszyscy by programowali tylko w C, C++ i Fortranie, a inne języki by nie istniały.

    Odpowiedz

    • @Piotr: ty cały czas o algorytmach i języku, a mój wpis dotyczył niskopoziomowej struktury wygenerowanego kodu, która jest po prostu z lamusa w przypadku kompilatora Go w porównaniu do ICC, Intela, GCC czy LLVM. Ciekawie piszesz i masz rację co do tego, że algorytmy, cache czy dostęp do dysku to podstawa, ale co to ma wspólnego z generowanym kodem i jakością, twoje porównanie do auta jest jak najbardziej na miejscu, wyprodukowali auto, a ja się czepiam kątów frezowania elementów silnika, bez lepszych parametrów twoje auto pojedzie, ale szybko zostanie w tyle za całą resztą.

      Myślę, że np dla twórców gier, silników przeglądarek internetowych (gdzie toczy się bitwa o prędkość wykonywania JavaScript), kodeków wideo (SSE) jakość generowanego kodu jest bardzo ważna i sam na co dzień masz okazję korzystać z dobrodziejstw możliwie jak najszybszego kodu.

      Odpowiedz

18. Nie, ja nie o algorytmach i języku, a o kompilatorach. O algorytmach było tylko w kontekście tego na ile ważne są pojedyncze cykle CPU. Nikt obecnie nie optymalizuje kodu „pod pojedyncze instrukcje”, nawet w zastosowaniach o których piszesz (gry, kodeki, silniki JavaScript); a jeśli już, to taka optymalizacja jest jedną z ostatnich, mających najmniejsze znaczenie. W kompilatorze te optymalizacje o których Ty piszesz też mają jeden z najniższych priorytetów. Kod wymagający najwyższej wydajności optymalizuje się pod względem cache-misses, bo to one zwykle są wąskim gardłem. Przypominam, że 1 cache miss = duże kilkaset cykli; jedna instrukcja = ok. 0.5 cyklu.

    Innymi słowy – czepiasz się, że Cinquecento nie jest samochodem wyścigowym, argumentując, że ma źle wyprofilowany spoiler, pomijając zupełnie fakt, że silnik nie ma nawet turbo, a jego pojemność jest śmiesznie niska.

    Po prostu z Twojego postu wcale nie wynika, że kompilator Go jest słaby; a co najwyżej że Twórcy kompilatora pominęli parę kosmetycznych szczegółów w ostatnim przebiegu generacji kodu mających nikły wpływ na wydajność. Żeby sensownie pokazać, że kompilator jest słaby, powienieneś przeanalizować jak radzi sobie z inliningiem i dewirtualizacją metod*, jak radzi sobie z rozwijaniem i wektoryzacją pętli, eliminacją niepotrzebnego kodu (np. range-checków itp.) – jest całe multum optymalizacji, które mają potężny wpływ na wydajność; wielokrotnie większy niż nadmiarowe xchg czy test. Oczywiście bez kodu źródłowego też nie da się za bardzo ocenić, czy kompilator sobie dobrze poradził, czy nie.

    *) Tu jest mała niespodzianka GCC oraz ICC radzą sobie z dewirtualizacją znacznie słabiej niż np. Hotspot C2 JVM – więc jakbym się skupił tylko na tym jednym, to mógłbym wysnuć wniosek, że GCC jest technologicznie biedne. Z wektoryzacją pętli na SSE też nie zawsze radzą sobie dobrze.

    Odpowiedz

    • @Piotr: nie masz racji i z tego co mówisz chyba w ogóle rzadko zaglądasz do generowanego kodu przez różne kompilatory, mówiąc o kodekach i o tym, że nikt nie optymalizuje pod pojedyncze instrukcje widać, że chyba nie interesujesz się tym jak pisze się wysokowydajne algorytmy z wykorzystaniem najnowszych dobrodziejstw kompilatorów, gdzie pojedyncze instrukcje mają ogromne znacznie, biorąc pod uwagę wysoką specjalizację nowoczesnych instrukcji jak SSE4, AVX itp.

      „Żeby sensownie pokazać, że kompilator jest słaby, powienieneś przeanalizować jak radzi sobie z inliningiem” – pokazałem jak marnuje cykle na zbędną pracę, gdzie cały kod zapycha instrukcjami CLD i XCHG i to nie pojedyncze procedury, ale jeśli sam zajrzeć do wnętrzna programu po Go zobaczysz, że jest tego cała masa, ciekawa forma inlilingu 🙂

      „eliminacją niepotrzebnego kodu” – po prostu sobie nie radzi o czym świadczą niepotrzebnie powtarzane bloki kodu, błędnie generowane fragmenty z porównaniami, nadmiarowy kod do wywoływania funkcji systemowych i masa innych zapychaczy bez celu.

      Tu 5 cykli, tam 50 cykli * kilkadziesiąt tysięcy powtórzeń w całym kodzie * pętle i już z tych małych nieistotnych fragmentów robi się parę istotnych sekund.

      Jakbyś miał ochotę na głębszą analizę kompilatora Go nie widzę problemów żebyś sam sprawdził co siedzi w środku i jeśli masz rację i pokażesz, że naprawdę kompilator Go nie jest tak zły jak go przedstawiłem to uderzę się w pierś i opublikuję twoje własne analizy tutaj na SecNews. Kontakt w menu jakby co.

      Odpowiedz

19. Ale ja wcale nie twierdzę, że nie jest zły! Jest słaby, bo sam Google robił benchmarki i Go dostało solidne bęcki nie tylko od C++, ale też od Scali, Javy – Ameryki nie odkryłeś. Śmieszy mnie tylko sposób w jaki argumentujesz, bo w wielu sytuacjach wyciągnąłeś drobiazgi kosmetyczne (np. czepianie się narzutów na WinAPI). Poza Tym z Twojego posta ja nadal nie wiem, kiedy mogę się spodziewać po Go, że wstawi mi te bezsensowne xchg, bo pokazałeś tylko kod wynikowy, bez kodu źródłowego. Z tego co napisałeś mógłbym się spodziewać, że, zakładając wstawianie bezsensownych instrukcji nawet co drugą instrukcję, Go jest co najwyżej o 30-50% powolniejsze od zoptymalizowanego kodu w C i wielokrotnie szybsze od Pythona – byłby to rewelacyjny wynik jak na język do integracji systemów (gdzie wąskim gardłem jest niemal zawsze I/O).

    Co do SSE/AVX, itp: masz rację, że te optymalizacje mają znaczenie, ale raczej nie o nie rozchodziło się w Twoim poście. Poza tym krytycznych optymalizacji SIMD lepiej nie powierzać kompilatorom, ponieważ kompilatory są w nich nadal dość słabe i nieprzewidywalne (tak, czasem GCC zrobi coś 2x-4x lepiej od ICC, a czasem na odwrót; a czasem oba dostaną bęcki nawet od JVMa, który ma 10x mniej czasu na optymalizację, a czasem oczywiście na odwrót – ogólnie jest to loteria). No i kodeków nie pisze się w Go, ba, ostatnio nawet nie pisze się w C, tylko po prostu korzysta się z dedykowanych kodeków sprzętowych. I tu najlepsza wektoryzacja na zwykłym CPU nie ma szans tego przebić.

    Odpowiedz

20. „Tu 5 cykli, tam 50 cykli * kilkadziesiąt tysięcy powtórzeń w całym kodzie * pętle i już z tych małych nieistotnych fragmentów robi się parę istotnych sekund.”

    Zgoda, ale parę sekund nie musi być wcale istotne z punktu widzenia zastosowań do jakich służy Go. Python ma narzut >50x, a jakoś nie przeszkadzało mu to zdobyć popularności bliskiej C++.

    Podsumowując:
    1. mocno przeceniasz rolę wydajności generowanego kodu
    2. czepiasz się drobiazgów, pomijając rzeczy duże
    3. i tak Ameryki nie odkryłeś; wszyscy wiedzą od dawna, że Go super szybkie nie jest
    4. Go nie musi być tak szybkie jak C, z racji zastosowań do których służy; wystarczy że jest znacznie szybsze od Pythona; jeżeli będzie kiedyś szybsze, to miło, ale nikt z wielkiej radości skakać nie będzie
    5. jak ktoś chce mieć wysoką wydajność, to użyje Javy albo C albo C++

    Odpowiedz

21. Stary temat, a co mi tam:
    http://paste.wataha.net/7p

    Odpowiedz