Dlaczego FreeBSD wycofuje GCC na korzyść Clang / LLVM?

Więc surfowałem po sieci i natknąłem się na ten artykuł . Zasadniczo stwierdza, że FreeBSD , począwszy od wersji 10 i nowszych, przestanie używać GCC na rzecz Clang / LLVM .

Z tego, co widziałem do tej pory w sieci, Clang / LLVM jest dość ambitnym projektem, ale pod względem niezawodności nie może się równać z GCC .

Czy są jakieś techniczne powody, dla których FreeBSD wybiera LLVM jako infrastrukturę kompilatora, czy też cała sprawa sprowadza się do wiecznych licencji GNU / GPL vs. BSD?

To pytanie ma (jakoś) istotne informacje na temat korzystania z GCC we FreeBSD

Podsumowanie: Głównym powodem przejścia z GCC na Clang jest niezgodność licencji GCC GPL v3 z celami projektu FreeBSD . Istnieją również kwestie polityczne związane z inwestycjami korporacyjnymi, a także wymagania bazy użytkowników. Wreszcie oczekuje się technicznych korzyści związanych ze zgodnością ze standardami i łatwością debugowania. Rzeczywiste ulepszenia wydajności w zakresie kompilacji i wykonywania są specyficzne dla kodu i mogą być przedmiotem dyskusji; przypadki mogą być wykonane dla obu kompilatorów.

FreeBSD i GPL: FreeBSD ma niełatwe relacje z GPL. Zwolennicy licencji BSD uważają, że prawdziwie wolne oprogramowanie nie ma ograniczeń użytkowania . Zwolennicy GPL uważają, że ograniczenia są konieczne w celu ochrony wolności oprogramowania, a zwłaszcza, że ​​możliwość tworzenia niewolnego oprogramowania z wolnego oprogramowania jest niesprawiedliwą formą władzy, a nie wolności. Projekt FreeBSD, tam gdzie to możliwe, stara się unikać korzystania z GPL :

Ze względu na dodatkowe złożoności, które mogą ewoluować w komercyjnym użyciu oprogramowania GPL, staramy się jednak zastępować takie oprogramowanie zgłoszeniami w ramach łagodniejszej licencji FreeBSD, gdy tylko jest to możliwe.

FreeBSD i GPL v3: GPL v3 wyraźnie zakazuje tzw tiwoizacja kodu, lukę w GPL v2 co pozwoliło ograniczeń sprzętowych do zabrania modyfikowania oprogramowania inaczej prawnych przez użytkowników. Zamknięcie tej luki było niedopuszczalnym krokiem dla wielu członków społeczności FreeBSD:

W szczególności dostawcy urządzeń mogą najwięcej stracić, jeśli duża część oprogramowania obecnie licencjonowanego na podstawie GPLv2 migruje do nowej licencji. Nie będą już mieli możliwości korzystania z oprogramowania GPLv3 i ograniczania modyfikacji oprogramowania zainstalowanego na ich sprzęcie ... Krótko mówiąc, istnieje duża baza konsumentów OpenSource, którzy nagle są bardzo zainteresowani zrozumieniem alternatyw dla oprogramowania licencjonowanego GPL.

Z powodu przejścia GCC na GPL v3, FreeBSD zostało zmuszone do pozostania przy użyciu GCC 4.2.1 (GPL v2), które zostało wydane w 2007 roku i jest obecnie znacznie przestarzałe. Fakt, że FreeBSD nie przestawił się na używanie bardziej nowoczesnych wersji GCC, nawet z dodatkowymi problemami związanymi z utrzymaniem starego kompilatora i poprawek dotyczących backportowania, daje pewne wyobrażenie o sile wymogu unikania GPL v3. Kompilator C jest głównym składnikiem bazy FreeBSD, a „ jednym z (wstępnych) celów FreeBSD 10 jest system podstawowy wolny od GPL ”.

Inwestycje korporacyjne: Podobnie jak wiele dużych projektów open source, FreeBSD otrzymuje fundusze i prace rozwojowe od korporacji. Chociaż stopień, w jakim FreeBSD jest finansowany lub opracowywany przez Apple, nie jest łatwy do wykrycia, istnieje znaczny nakładanie się, ponieważ system operacyjny Darwin firmy Apple wykorzystuje znaczny kod jądra pochodzący z BSD . Ponadto sam Clang był pierwotnie wewnętrznym projektem Apple, zanim został otwarty w 2007 roku . Ponieważ zasoby korporacyjne są kluczowym czynnikiem umożliwiającym projekt FreeBSD, zaspokojenie potrzeb sponsorów jest prawdopodobnie znaczącym czynnikiem napędzającym rzeczywisty świat .

Baza użytkowników: FreeBSD jest atrakcyjną opcją typu open source dla wielu firm, ponieważ licencjonowanie jest proste, nieograniczone i raczej nie prowadzi do procesów sądowych. Wraz z pojawieniem się GPL v3 i nowymi przepisami anty-Tivoisation zasugerowano, że istnieje tendencja przyspieszająca, kierowana przez sprzedawców, w kierunku bardziej liberalnych licencji . Ponieważ postrzegana przewaga FreeBSD dla podmiotów komercyjnych polega na jego liberalnej licencji, narasta presja ze strony użytkowników korporacyjnych, aby odejść od GCC, a ogólnie GPL.

Problemy z GCC: Oprócz licencji korzystanie z GCC ma pewne dostrzegane problemy . GCC nie jest w pełni zgodny ze standardami i posiada wiele rozszerzeń, które nie występują w standardzie ISO C . Przy ponad 3 milionach linii kodu jest to także „ jeden z najbardziej złożonych i darmowych / otwartych programów ”. Ta złożoność sprawia, że ​​modyfikacja kodu poziomu dystrybucji jest trudnym zadaniem.

Korzyści techniczne: Clang ma pewne zalety techniczne w porównaniu do GCC . Najbardziej godne uwagi są znacznie bardziej pouczające komunikaty o błędach i specjalnie zaprojektowany interfejs API dla IDE, refaktoryzacji i narzędzi do analizy kodu źródłowego. Chociaż strona internetowa Clanga przedstawia wykresy wskazujące na znacznie bardziej wydajną kompilację i wykorzystanie pamięci, rzeczywiste wyniki są dość zmienne i zasadniczo zgodne z wydajnością GCC. Ogólnie rzecz biorąc, pliki binarne produkowane przez Clanga działają wolniej niż równoważne pliki binarne GCC:

Podczas gdy używanie LLVM jest szybsze w budowaniu kodu niż GCC ... w większości przypadków zbudowane pliki binarne GCC 4.5 działały lepiej niż LLVM-GCC lub Clang ... w pozostałych testach wydajność była zbliżona do GCC lub dobrze za. W niektórych testach wydajność plików binarnych generowanych przez Clanga była po prostu okropna.

Wniosek: Bardzo mało prawdopodobne jest, aby wydajność kompilacji była istotnym czynnikiem motywującym do podjęcia znacznego ryzyka przeniesienia dużego projektu, takiego jak FreeBSD, na zupełnie nowy zestaw narzędzi kompilatora, szczególnie w przypadku braku wydajności binarnej. Jednak sytuacja tak naprawdę nie do zniesienia. Biorąc pod uwagę wybór między 1) uruchomieniem przestarzałego GCC, 2) przejściem do nowoczesnego GCC i zmuszeniem do korzystania z licencji niezgodnej z celami projektu lub 3) przejściem do stabilnego kompilatora licencjonowanego BSD, decyzja było prawdopodobnie nieuniknione. Należy pamiętać, że dotyczy to tylko systemu podstawowego i wsparcia z dystrybucji; nic nie stoi na przeszkodzie, aby użytkownik sam zainstalował i używał nowoczesnego GCC na swoim urządzeniu FreeBSD.

Jedną z rzeczy, które warto wziąć pod uwagę, jest to, że FreeBSD obecnie korzysta z GCC 4.2.1, jak zauważono w odpowiedzi ire_and_curses, dlatego porównania wydajności nie wynoszą 4,5, a nawet 4,6 nie są tak naprawdę odpowiednie dla projektu. Dlatego pytania, które powinieneś zadać to:

1. Jakie są przyrosty wydajności nowego Clanga w porównaniu ze starszym GCC, którego używa projekt?

2. Jak te same pliki binarne skompilowane w GCC 4.2.1 różnią się od nowego Clanga?

Z powodu przejścia GCC na GPL v3, FreeBSD zostało zmuszone do pozostania przy użyciu GCC 4.2.1 (GPL v2), które zostało wydane w 2007 roku i jest obecnie znacznie przestarzałe.

Jeśli Clang pozostaje w tyle za obecnym GCC, ale wciąż jest o lata świetlne przed wdrożonym GCC w projekcie, ich decyzja o ewolucji jest dobrze uzasadniona i prawdziwie zainspirowana.

Mimo że GCC to GPLv3, wynikowe pliki binarne tworzone przez GCC nigdy nie miały żadnych ograniczeń licencyjnych. Oczywiste jest, że możesz używać GCC do tworzenia oprogramowania objętego odpowiednią licencją. Nawet biblioteka C dostarczana z GCC i zawarta w pliku binarnym jest wolna od licencji. http://www.gnu.org/licenses/gcc-exception-faq.html

Sekcja 2 GNU GPLv3:

Masz uprawnienia do propagowania pracy kodu docelowego utworzonego przez połączenie biblioteki wykonawczej z niezależnymi modułami, nawet jeśli takie rozpowszechnianie naruszałoby warunki GPLv3, pod warunkiem, że cały kod docelowy został wygenerowany przez kwalifikujące się procesy kompilacji. Następnie możesz przekazać taką kombinację na warunkach wybranych przez ciebie , zgodnie z licencjonowaniem niezależnych modułów.

„Kwalifikujący się” oznacza, że ​​kompilacja nie obejmuje zarówno oprogramowania GCC, jak i oprogramowania niezgodnego z GPL. To nie jest ograniczenie: oprogramowania licencjonowanego BSD można używać w procesie kompilacji z udziałem GNU GCC.

Jak widać, w przeciwieństwie do tego, co powiedziano powyżej, nie ma PRAWDZIWEGO powodu do odejścia od GCC, ponieważ nie ma niezgodności z używaniem GCC w FreeBSD.

Prawdziwy powód tej zmiany jest polityczny i oportunistyczny:

• BSD ma własną licencję, która filozoficznie konkuruje z licencją publiczną GNU (jak wyjaśniono powyżej * ire_and_curses *),
• CLANG to nowy kompilator inny niż GPL zainicjowany przez sponsora FreeBSD, który wydaje się technicznie równoważny licencjonowanemu GPL GCC (jak opisano powyżej w * ire_and_curses *).

Fakty te dają FreeBSD możliwość odejścia od GCC i pozbycia się go: w rzeczywistości nie są do tego prawnie zmuszone, ponieważ mogliby nadal używać GCC do tworzenia darmowego lub licencjonowanego oprogramowania BSD, ale chcą trzymać się filozofia „całego oprogramowania licencjonowanego BSD”.

Nie jestem ekspertem, ale rozumiem, że Clang / LLVM zużywa mniej zasobów niż GCC i jest szybszy.

http://clang.llvm.org/features.html#performance

Jeśli prowadzisz środowisko, w którym musisz budować wiele rzeczy, wiele razy taka wydajność może przełożyć się na rzeczywistą oszczędność kosztów energii i czasu. Jeśli to prawda.