Największe wąskie gardła podczas tworzenia systemu Android ze źródła

Aktualizacja 4/19, 12:00 czasu polskiego: Wyjaśnione czasy kompilacji to czasy kompilacji ccache.Aktualizacja 4/20, 9:17 czasu CT: Kompilacja 3 z pewnością nie była RAID 1. Poprawiłem ten błąd.

W 2012 roku zacząłem budować jądra i polegałem na moim sprawdzonym procesorze Core 2 Quad Q9550. Gdyby to nie było godne pożałowania, fakt, że zrobiłem to na maszynie wirtualnej w systemie Windows, prawdopodobnie zapewni to większości ludzi, którzy budują Androida ze źródeł.

Zwirtualizowane środowisko Ubuntu nie działa tak dobrze, jak środowisko natywne i och, jak bolesne było to widoczne, gdy budowanie jądra trwało ponad 2 godziny. Ponieważ w następnym roku chciałem rozpocząć tworzenie systemu Android ze źródeł, wiedziałem, że mój obecny sprzęt tego nie zrobi wytnij go — i tak rozpoczęła się długa i wciąż trwająca podróż w celu znalezienia sposobu na zmniejszenie tej stale rosnącej kompilacji czas.

Od tego czasu miałem szczęście testować na wielu obudowach i platformach. Jest to ważne, ponieważ konfiguracje kompilacji nie są uniwersalną sytuacją w przypadku systemu Android. Twórca aplikacji może nie potrzebować takiej samej konfiguracji jak twórca gier. A ktoś, kto buduje tylko jądra, może nie musieć wydawać tak dużo, jak ktoś, kto musi zbudować pełną pamięć ROM Androida ze źródła w bardzo krótkim czasie. A co z wyborem systemu operacyjnego — czego można (a czego nie można) teraz używać? Mam nadzieję zbadać to również bardziej, zwłaszcza z Windows i Canonical pracują nad wprowadzeniem pełnoprawnego Bash do systemu Windows 10.

Aby dobrze rozpocząć tę serię, musimy znaleźć miejsca, w których znajdują się największe potencjalne wąskie gardła w budowaniu projektów AOSP ze źródła. Nieczęsto kupujemy komputer lub ulepszenia, nie wiedząc, gdzie ulokować pieniądze. Bazując na 3 latach badań i wymiernych wynikach, jestem gotowy podzielić się tym, co odkryłem. A teraz oczekiwane zastrzeżenie: ustalenia te opierają się na osobistych doświadczeniach i nie mogą uwzględniać wszystkich kombinacji. Ci z Was, którzy mają własną konfigurację kompilacji, zagłosujcie i dajcie nam znać, jak sobie radzą Wasze kompilacje! Czasy odnoszą się również do kompilacji z włączoną i zapełnioną pamięcią ccache - zwykle była ona dwukrotnie większa, gdy pamięć ccache nie była jeszcze zapełniona.

We/wy dysku: Muszę ukłonić się Tomowi Marshallowi z Cyanogen – także członek Zespołu Kanga - za wskazanie mi tego kierunku w zeszłym roku. Szczerze mówiąc, nie wierzyłem mu, kiedy mi mówił, że tak będzie the wąskie gardło na procesorze. Ale w ciągu ostatnich 6 miesięcy udało mi się to poprzeć wymiernymi danymi. W przypadku procesorów wyższej klasy (takich jak większość modeli Intel Core i7 do komputerów stacjonarnych) jest to największe wąskie gardło, jakiego doświadcza Twój system.

Weźmy 4 konfiguracje kompilacji, na których to testowałem. Podkreślę tutaj procesor,

• Wersja 1, mój „niemodernizowany” komputer, to Intel i7-4790K z 32 GB pamięci RAM DDR3-2400, Samsung 840 Evo 250 GB jako mój główny dysk i starszy Micron P400E 100 GB.
• Build 2, który był ulepszoną wersją Build 1. Teraz jest wyposażony w procesor Intel i7-5960X podkręcony do 4,0 GHz, 32 GB pamięci RAM DDR4-3200, dysk SSD Samsung SM951 512 GB AHCI m.2 oraz dwa poprzednie dyski SSD. Pełne specyfikacje kompilacji znajdują się na PCPartPicker.
• Wersja 3, najnowsza wersja użytkownika, zawierała procesor Intel i7-5820K podkręcony do 4,2 GHz, 16 GB pamięci DDR4-2400 i 2 karty Samsung 840 EVO 120 GB w konfiguracji RAID0 (paski).
• Build 4, najnowsza wersja serwera z procesorem Intel Xeon E3-1270 v5 przy normalnych prędkościach, 32 GB pamięci DDR4-2133, dyskiem Samsung 950 Pro 512 GB NVMe m.2 oraz 4 dyskami SSD SATA dla przedsiębiorstw Samsung w macierzy RAID5.

Gdybyś tylko na nie spojrzał, który z nich Twoim zdaniem osiągnął najkrótszy czas budowy? A co powiesz na drugie? Ku mojemu zaskoczeniu, to nie druga konfiguracja trwała najkrócej, lecz trzecia konfiguracja, o godz niecałe 14 minut na zbudowanie CyanogenMod 13.0. Zatem z pewnością dominujący procesor zająłby drugie miejsce, Prawidłowy? Znowu źle. Wersja 4, którą właśnie skończyłem testować, zajęła nieco ponad 25 minut! Tylko tutaj znajduje się moja obecna wersja, 2 minuty wolniejsza niż system z połową rdzeni i wątków, ale z macierzą SSD składającą się z 3 dysków SSD, podczas gdy moje dyski SSD były samodzielne. Wiadomo również, że SM951 ma problemy z dławieniem, jeśli robi się zbyt gorąco, co może być bardzo realnym czynnikiem w tym przypadku. Pierwsza i najwolniejsza kompilacja zajęła około 30 minut i był to jeden z niewielu razy, kiedy zbudowałem CM 13.0; Słyszałem o podobnych konfiguracjach kompilacji, które robiły to w 27.

Dyski SSD również były przedmiotem trudnym do zdobycia, dlatego było bardzo mało dyskusji na ten temat. Jednak w ciągu ostatniego roku ceny drastycznie spadły zarówno na rynku detalicznym, jak i na rynku używanym. Ponieważ dyski SSD o pojemności 120 GB obecnie kosztują mniej niż 50 USD, nie stanowi to już bariery, jaką kiedyś było dodanie jednego do systemu. Tradycyjne dyski twarde również poradzą sobie z tym zadaniem, ale użytkownicy, którzy nie korzystają z dysków SSD, dotrą do tego wąskiego gardła szybciej niż inni.

PROCESOR: Kiedy wspomniałem powyżej, że głównym wąskim gardłem są wejścia/wyjścia dysku, opieram się na założeniu, które nie zawsze musi mieć rację — każda z tych kompilacji, z których korzystałem, zawierała procesor Intel Core i7. Ale jak zauważyłem w przypadku serwera Xeon, dysk działa, ale jednocześnie utrzymuje wysokie wykorzystanie wszystkich 8 wątków procesora podczas najcięższych procesów kompilacji. I choć próbuję, bez macierzy RAID, którą znaleźliśmy powyżej, nie uważam, że mój Haswell-E jest nawet blisko pełnego wykorzystania przez większość procesu kompilacji. Jeśli więc szukasz najlepszego rozwiązania za wydane pieniądze, rozważ procesor Intel i7-5820K.

To prawda, jest to X99, więc płyta główna może być droższa niż płyta główna Z97; ale wciąż jesteśmy w pierwszym roku cyklu X99. Oczekuje się, że ceny Broadwell-E po premierze pozostaną podobne do cen Haswell-E, co oznacza, że powinieneś być w stanie kupić w segmencie entuzjastów za prawie tę samą cenę, co i7-4790K lub i7-6700K.

W przypadku Intela nie ma obecnie większego powodu, aby wykraczać poza 5820K, ponieważ można na nim uzyskać imponujące czasy kompilacji. W przeważającej części im wyższa liczba rdzeni/wątków poniżej, wraz z szybkością procesora, zapewni krótszy czas kompilacji. W zeszłym roku i7-4770R na GIGABYTE Brix dał mi średnio 42 minuty pracy. Chociaż nie był najszybszy, odpowiadał moim potrzebom i pozwolił mi mieć dedykowaną konfigurację o niskim poborze mocy. To samo znajdziesz w przypadku procesorów APU AMD – chociaż mogą one obecnie nie działać tak dobrze, jak ich odpowiedniki Intela, z łatwością wykonają swoje zadanie i zwykle po niższej cenie niż zakup Intela. Przyglądam się tej sytuacji uważnie, bo jeśli pogłoski okażą się prawdziwe, to APU oparte na Zen mogą znacząco wypełnić tę lukę.

Ci z Was, którzy zdecydują się usunąć te wąskie gardła, będą mieli korzyści, które dotyczą bardziej użytkowników domowych niż biurowych. Ogólna wydajność systemu wzrośnie po usunięciu tych wąskich gardeł. Zwłaszcza gracze odkryją, że aktualizacja mająca na celu usunięcie tych wąskich gardeł w prawie wszystkich przypadkach zwiększy również wydajność gry. Choć być może nie uzyskała najszybszego czasu kompilacji, ta druga kompilacja przyniosła nieoczekiwaną niespodziankę — ładowanie trwało 30 sekund Tylko powód 3 gdy wielu innych narzekało na czas ładowania w minutach. Ostatecznie czasy kompilacji są naprawdę wysokie i dla wielu mogą być przesadą… ale przynajmniej teraz argument, że więcej rdzeni oznacza szybsze kompilacje, został ostatecznie obalony.

Ponieważ to dopiero początek, mamy nadzieję, że czytelnicy odezwą się i podzielą się swoimi doświadczeniami z kompilacji w różnych konfiguracjach. Czy jako czytelnik chcesz widzieć więcej dyskusji na tego typu tematy? Zagłosuj w komentarzach poniżej!