W mgnieniu oka

Witaj na prywatnej stronie blinkkina. Zapoznaj się z informacjami na temat bloga i autora. Subskrybuj witrynę przez kanał atom lub zobacz ostatnie komentarze. W wolnej chwili odwiedź mojego mikrobloga na identi.ca.


LLVM i GCC – wiwerna zeżre antylopę?

· artykuły · skomentuj

Ostatnio ciekawie wygląda rynek otwarto źródłowych kompilatorów. Artykuły dotyczące GCC i Clang/LLVM pojawiają się coraz częściej. Niektóre z nich to porównania wydajności tych rozwiązań tzw. benchmarki. Nie mniej interesująco wygląda sprawa promocji i kierunku rozwoju tych projektów, na której postanowiłem się skupić.

Logo GCC - anytlopa i logo LLVM - wiwerna

Porównanie zacznę od tak prozaicznego szczegółu, jakim jest logo. Logo GCC jest takie jak każdy widzi, jednak zabawnie wygląda w zestawieniu z LLVM. Czy tylko ja odniosłem wrażenie, że za chwilę wiwerna zeżre biedną antylopę? Nie wiem czy taka charakteryzacja logo LLVM została wybrana celowo. W każdym bądź razie chciałem wyjaśnić, skąd wziął się tytuł tego artykułu, warto jednak przejść do konkretów.

Jakiś czas temu dosyć głośno było o dopuszczeniu języka C++ w rozwoju GCC. Poszukując dalszych informacji, trafiłem na stronę jednego z deweloperów GCC – Iana Taylora. Znalazłem tam ciekawy artykuł z ogólnymi przemyśleniami na temat tego projektu. Lance poruszył kilka problemów, które obecnie nękają GCC. Postaram się je opisać i porównać na tle LLVM – zrobię to zaczynając od końca.

„Trzeci problem jest taki, że GCC nie posiada praktycznie żadnego PR. Strona projektu mówi czym jest GCC, jednak brak tam wiadomości o postępach rozwoju i porównań z innymi kompilatorami. Krytyka GCC jest wszechobecna, panuje powszechne przekonanie, że GCC jest znacznie gorsze niż własnościowe kompilatory lub też, że projekt powoli umiera. Nikt nie próbuje jednak tego zmienić.”

Trudno z tym się nie zgodzić, w szczególności patrząc na konkurencję. O Clangu piszę się być może nawet więcej niż na to zasługuje. Informacje o rozwoju tego projektu można znaleźć na oficjalnej stronie, jednak nie ma takiej potrzeby. Większość stron o tematyce IT opublikowało nowości na temat tego, że Clang/LLVM jest „self-hosted” czy, że możliwa jest kompilacja biblioteki Boost.

Tematy były zazwyczaj gorąco komentowane. Dyskusja często dotyczyła krytyki GCC i pochwał LLVM. Benchmarki i porównania Clanga z innymi rozwiązaniami też łatwo znaleźć. W tej dziedzinie chyba więcej nie da się zrobić. Nie zapowiada się też, żeby trend ten osłabł, wręcz przeciwnie.

„Inny problem to brak osoby lub grupy, która posiada możliwości i chęci do podjęcia decyzji o jasnym kierunku rozwoju projektu. W przeszłości taką rolę pełnili Richard Stallman, Richard Kenner, Jeff Law czy Richard Henderson. Obecnie nikt tego nie robi, czego efektem jest brak pewności czy poważniejsze zmiany, powinny zostać przyjęte. Prowadzi często to do bezsensownej dyskusji i niesprawdzonych poprawek. Osoby chcące wspomóc projekt zostały pozostawione bez wyraźne wyznaczonych celów.”

Znowu w przypadku LLVM wygląda to zupełnie inaczej. Obecnie nawet lider z silnym poparciem nie jest potrzebny, ponieważ założenia są tak jasne. Ostateczny cel to zastąpienie GCC, które jest realizowane przez małe-duże kroki, o których już wspominałem. Następne w kolejce jest Qt i jego kompilacja, będąca sporym wyzwaniem.

„Większość osób zaangażowana w rozwój GCC jest opłacana. Oznacza to, że mają ogromną ilość czasu i zasoby, aby usprawnić kompilator. Sprawia to jednak, że nowi ochotnicy mogą mieć problem z dołączeniem do społeczności. Ciężko poznać kod i zarazem nadążyć za zmianami. Ciężko poznać używane konwencje, jednocześnie spotykając się z małą pomocą przy dodawaniu swoich poprawek. Większość deweloperów poznało na tyle dobrze kod, że nie korzysta już z wewnętrznej dokumentacji. Przełożyło się na słabe udokumentowanie pewnych fragmentów i nikt nie jest na tyle zmotywowany by to zmienić.”

Clang pomimo dużego sponsoringu, nadal jest silnie związany ze środowiskiem akademickim, z którego się wywodzi. Kompilatorem zainteresowane jest także środowisko BSD (m.in. ze względów licencyjnych), w szczególności osoby związane z systemem FreeBSD.

Tradycje BSD to m.in. małe poprawki, które są dodawane często i bardzo rygorystyczne podejście do dokumentacji. Jeśli nawet dokumentacja nie jest do końca precyzyjna, łatwiej zrozumieć kod, patrząc na komentarze do wprowadzonych poprawek. Filozofia „stfu and hack” przekłada się natomiast na bardzo mile widziane patche z zewnątrz.

Czas na jakieś wnioski. Jasne jest, że wyraźnie określone cele przekładają się zazwyczaj na szybszy rozwój. Szybszy rozwój daje większe pole do promocji – wspomniane wcześniej artykuły. Promocja natomiast pozwala na przyciągnięcie nowych deweloperów i kółko się zamyka.

Deweloperzy GCC dobrze to rozumieją. Umożliwienie użycia C++, być może jest pierwszą oznaką zmian. Być może pozwoli to na przyciągnięcie nowych współpracowników. Z pewnością przyniosło to już efekt medialnego szumu, którego brakowało. Jednak czy nie jest to zbyt mało?

Należy mieć na uwadze, że Clang może tylko zyskać. W najgorszym przypadku LLVM będzie używane tylko przez osoby związane ze środowiskiem BSD, o czym wspomniałem wcześniej. Znacznie więcej do stracenia ma GCC, którego rozwój opiera się nie na wolontariacie, a pieniądzach.

Prawdziwa bitwa jeszcze się nie rozpoczęła, a GCC być może już ją przegrało. LLVM nie musi być znacznie lepsze, musi być wystarczająco dobre, resztę zrobi marketing. Spadek komercyjnego zainteresowania w przypadku GCC może oznaczać powolny odpływ sponsorów, co może przynieść bardzo negatywne efekty.

Osobiście uważam, że GCC powinno mieć godnego konkurenta, na którego Clang/LLVM się zapowiada. Jednak nie chcę całkowitego unicestwienia projektu GNU. Likwidacja kilkunastoletniego monopolu i zastąpienie go kolejnym, niczego dobrego nie przyniesie. Zdrowa konkurencja jest znacznie lepszą alternatywą – wystarczy, że tytułowa wiwerna lekko nadgryzie antylopę.

Spolszczone fragmenty są autorstwa Iana Lance Taylora i pochodzą z jego prywatnej strony. Wykorzystałem je korzystając z przysługującego mi prawa cytatu. Wykorzystane logo LLVM i GCC nie są moją własnością.