Różnica w wydajności między skompilowanymi i binarnymi dystrybucjami / pakietami Linux

Dużo szukałem w Internecie i nie mogłem znaleźć dokładnej odpowiedzi.

Istnieją takie dystrybucje jak Gentoo (lub FreeBSD), które nie są dostarczane z plikami binarnymi, ale tylko z kodem źródłowym dla pakietów (portów).

Większość dystrybucji używa kopii binarnych (debian itp.).

Pierwsze pytanie: Jakiego wzrostu prędkości mogę oczekiwać od skompilowanego pakietu? Ile wzrostu prędkości mogę uzyskać z pakietów rzeczywistych, takich jak apache lub mysql? tj. zapytania na sekundę?

Drugie pytanie: czy pakiet binarny oznacza, że ​​nie używa instrukcji procesora, które zostały wprowadzone po pierwszym 64-bitowym procesorze AMD? W przypadku pakietów 32-bitowych oznacza to, że pakiet będzie działał na 386 i zasadniczo nie korzysta z większości nowoczesnych instrukcji procesora?

Dodatkowe informacje:

• Nie mówię o komputerze stacjonarnym, ale środowisku serwera.
• Nie dbam o czas kompilacji
• Mam więcej serwerów, więc warto korzystać z pakietów kodu źródłowego, aby zwiększyć prędkość o ponad 15%
• Proszę, nie flamewars.

Różnica wydajności będzie w prawie wszystkich przypadkach minimalna i nie opłacalna. Dobre powody do korzystania z dystrybucji źródeł (podczas rozwijania własnych pakietów binarnych, na co pozwala system bindist gentoo) obejmują:

• Wdrażanie własnych poprawek
• Łatwe dostosowywanie jądra
• Pakowanie własnych aktualizacji

Jeśli nie robisz żadnej z tych rzeczy, nie potrzebujesz dystrybucji źródła. Na użytek osobisty są bardzo wygodne, ponieważ pozwalają na stopniowe uaktualnianie rzeczy bez martwienia się zbytnio o zgodność binarną, co nie jest problemem, który często widzę w środowisku korporacyjnym.

Warto zauważyć, że możesz robić te rzeczy również z dystrybucją binarną, tworząc własne pakiety RPM lub cokolwiek innego. Koszty ogólne zarządzania są podobne.

Zasadniczo nie zobaczysz 15% wzrostu prędkości, kompilując ze źródła. Nie chciałbym tego szacować nawet na 5% w każdym uzasadnionym przypadku. Kompilacja ze źródła daje ci kilka rzeczy:

• Możesz użyć preferowanej wersji kompilatora
• Możesz skierować kompilator do generowania instrukcji z rozszerzeń ISA nieużywanych w pakietach binarnych, takich jak AESNI i AVX

Jednak kompilator bardzo rzadko generuje je i tak, a ogólne oszczędności z ich używania są na ogół bardzo małe, gdy wydajność aplikacji jest traktowana jako całość. Rzeczy takie jak dostęp do pamięci RAM (i opóźnienie) oraz opóźnienie dysku i urządzenia są znacznie większymi czynnikami i naprawdę powinieneś zacząć od tego.

Aplikacje, które mogą skorzystać z niestandardowej kompilacji, która będzie działała tylko na stosunkowo niedawnych procesorach Intel Core i7 lub i5, obejmują takie, które wykonują dużo matematyki wektorowej oraz te, które wykonują dużo szyfrowania i deszyfrowania AES lub wymagają wielu losowych liczb. Jeśli chcesz korzystać z Intel DRBG, musisz to zrobić również obecnie.

Jeśli żadne z nich nie dotyczy ciebie, będziesz całkiem zadowolony z dowolnej dystrybucji opartej na Debianie lub Red Hat i będziesz miał znacznie mniej kosztów utrzymania.

Krótka odpowiedź ... Wiele aplikacji na dużą skalę i wrażliwych na szybkość / opóźnienie działa w standardowych dystrybucjach Linuksa. Red Hat, CentOS, Debian, Ubuntu ... Wszystkie działają dobrze w większości przypadków. Większość korzyści pochodzi z dostrajania aplikacji, standardowych optymalizacji jądra i systemu operacyjnego oraz infrastruktury.

Gentoo może oferować pewne optymalizacje, ale otwiera drzwi do większej liczby problemów związanych z zarządzaniem, mniejszym umysłem, zmniejszonym wsparciem dla dostawców i sterowników, problemami ze stabilnością, ośmieszeniem i potencjalnymi obawami dotyczącymi bezpieczeństwa.

Zarządzałem serwerami opartymi na Gentoo w środowisku transakcji finansowych o wysokiej częstotliwości. Mimo niewielkich korzyści w zakresie wydajności Gentoo, nadal przeprowadziłem się do Red Hat i CentOS. Zalety Gentoo na papierze zostały łatwo pokonane dzięki mądrzejszemu doborowi sprzętu, lepszemu wsparciu producenta serwera / integracji sprzętu, inteligentniejszemu łataniu przez inżynierów Red Hat i bardziej ezoterycznym technologiom, takim jak obejście jądra ...

Jeśli jesteś w punkcie, w którym wydajność popularnych stosów aplikacji (LAMP) stanowi problem, upewnij się, że zoptymalizowałeś sprzęt serwera (typ procesora, układ pamięci RAM), infrastrukturę sieciową, system monitorowania i potrafiłeś zidentyfikować wąskie gardła systemu przed idąc tą ścieżką.

Czy osiągasz teraz ograniczenie wydajności ?

Wszystkie przedstawione punkty są oczywiście poprawne. Chciałbym tylko rozwiązać problem z tym, że wzrost wydajności o 5–15% jest nieosiągalny, zwłaszcza w przypadku nowoczesnych wersji GCC, tak naprawdę zależy to od architektury procesora i tego, jak blisko linii bazowej użytej jako cel dla dystrybucji binarnych. GCC -march = natywna będzie, oprócz korzystania z rozszerzeń ISA, również zoptymalizować pod kątem wielkości pamięci podręcznej / linii L1 i L2. Prawidłowo wyrównany kod (dla twojego procesora) może być znacznie szybszy, szczególnie gdy -flto jest również używany, aby kompilator mógł wiedzieć wszystko, co musi wziąć pod uwagę. [niektóre pakiety są obecnie zepsute LTO, niestety]

Dodatkowo, kompilacja wybranych pakietów z opcją -Ofast, oprócz march = native i LTO może mieć znaczącą różnicę.

W przyszłości, jeśli infrastruktura grafitowa GCC kiedykolwiek się ustabilizuje, będzie miał potencjał do jeszcze większych zysków.

To zależy od tego, czego chcesz w swoim systemie, a tak naprawdę są tutaj trzy szkoły myślenia (dotyczy to zarówno sprzętu, jak i oprogramowania)

Po pierwsze, główny nurt, o ile chodzi o większość ludzi na SF - chcesz czegoś, o czym wiesz, że zadziała, chcesz wsparcia i chcesz go teraz . W tym przypadku przejście na systemy oparte na redhat (RHEL zapewnia doskonałe wsparcie, a centos to społeczna odbudowa dobrze przetestowanej dystrybucji RHEL). Nie dostaniesz jednak najnowszego i najlepszego. W wielu przypadkach dotyczy to również sprzętu.

Drugi to punkt widzenia „na środku drogi”, który jest środkiem - idąc z czymś w rodzaju ubuntu. Chcesz nowych pakietów (niewielkim kosztem solidnej stabilności), instalatora i ładnych rzeczy .

W niektórych przypadkach ludzie wpadają w kłopoty, ale masz nowsze pakiety i wszystko jest odpowiednio testowane . Chociaż tutaj jest wiele nienawiści do Ubuntu, jest to dobry kompromis między łatwością instalacji a stosunkowo nowymi pakietami. Debian jest prawdopodobnie nieco bardziej konserwatywnym wyborem. W dzisiejszych czasach możesz nawet zainstalować system Ubuntu z jądrem o niskim opóźnieniu. Czuję, że Ubuntu i Debian pracują dla mnie, ale ymmv. Wiele miejsc, w których wdrożono wiele serwerów, takich jak Facebook i Google, wybiera tę opcję.

Wreszcie istnieją dystrybucje oparte na źródłach. Wstępna konfiguracja w większości przypadków jest całkowitym bólem z tyłu. Popełniasz błąd podczas konfigurowania jądra? Ups, poświęć kilka godzin na rekompilację. Nie dostajesz też instalatora - to znaczy dla n00bs. Często dostajesz najnowocześniejsze aplikacje i opcję ich kompilacji według potrzeb (co obejmuje na przykład możliwość optymalizacji pod kątem prędkości lub wykorzystania pamięci), a także wersję aktualizacyjną. Jeśli masz bardzo konkretne, ezoteryczne potrzeby, Gentoo jest świetne. Jeśli potrzebujesz wdrożyć kilkadziesiąt systemów i chcesz to zautomatyzować ... powodzenia. Dystrybucje oparte na źródłach po prostu również nie skalują się. Dostajesz dużą elastyczność, * trochę ** dodatkowej prędkości, ale nie daje się utrzymać na tym samym poziomie, co IMO dystrybucji opartej na pakietach. Jesteś nieprawdopodobnie uzyskasz 15% dodatkowej prędkości, a prawdopodobnie skończysz marnowaniem czasu, próbując dostroić flagę kompilacji twojego sprzętu, a jeśli coś zepsujesz, poświęć czas na rozpracowanie, co dokładnie nie powiodło się.

BSD to osobna rodzina systemów operacyjnych. Niektórzy ludzie przysięgają przez nich (co najmniej jeden zwykły pokój komunikacyjny jest użytkownikiem freebsd), a różne BSD mają różne cele - na przykład openbsd ma obsesję na punkcie bezpieczeństwa, a freebsd to „główny nurt”. Mogą nie mieć, w niektórych przypadkach, tego samego rodzaju wsparcia sprzętowego, co Linux, ale zależy to od kilku czynników.