Nysgerrig, hvilke flaskehalse AOSP-projekt bygger? Dan deler sine resultater - hvilket kan overraske læserne med hensyn til, hvad der gør og ikke forårsager en flaskehals.
Opdatering 19/4 kl. 12 CT: Afklarede byggetider er ccache-byggetider.Opdatering 20/4 09:17 CT: Build 3 var bestemt ikke RAID 1. Rettede den fejl.
I 2012 begyndte jeg at bygge kerner -- og stolede på min troværdige Core 2 Quad Q9550 til at bygge den. Hvis det ikke var værdigt til at bryde sig, så vil det faktum, at jeg gjorde det i en VM inde i Windows, nok sikre det for de fleste mennesker, der bygger Android fra kilden.
Et virtualiseret Ubuntu-miljø fungerer ikke så godt som et native miljø, og åh, hvor gjorde det smertefuldt det tydeligt, da en kerne tog over 2 timer at bygge. Da jeg ville begynde at bygge Android fra kilden året efter, vidste jeg, at min nuværende hardware ikke ville klippe det -- og så begyndte en lang og stadig vedvarende rejse for at finde en måde at reducere den stadigt voksende bygning tid.
I årene siden da har jeg været så heldig at teste på flere formfaktorer og platforme. Dette er vigtigt, da build-konfigurationer ikke er en ensartet situation med Android. En applikationsudvikler har muligvis ikke brug for den samme konfiguration som spiludvikler. Og nogen, der kun bygger kerner, behøver måske ikke at bruge så meget som en, der har brug for at bygge en fuld Android ROM fra kilden på meget kort tid. Og hvad med OS valg - hvad kan (og kan ikke) bruges lige nu? Jeg håber også at udforske dette mere, især med
Windows og Canonical arbejder på at bringe en fuldgyldig Bash til Windows 10.For at starte denne serie rigtigt skal vi finde ud af, hvor de største potentielle flaskehalse er i at bygge AOSP-projekter fra kilden. Vi handler ikke ofte efter en pc eller opgraderinger uden at vide, hvor vi skal lægge dine penge. Så baseret på 3 års forskning og kvantificerbare resultater er jeg klar til at dele, hvad jeg har fundet. Nu den forventede ansvarsfraskrivelse: Disse resultater er baseret på personlige erfaringer og kan umuligt tage højde for alle kombinationer. De af jer med din egen build-konfiguration, lyder af og lad os vide, hvordan det går med dine builds! Tider refererer også til builds med ccache aktiveret og udfyldt - var normalt det dobbelte, når ccachen ikke var udfyldt endnu.
Disk I/O: Jeg skal give et hattip til Cyanogens Tom Marshall - også en medlem af Team Kang - for at pege mig i denne retning sidste år. Jeg troede ærligt talt ikke på ham, da han fortalte mig, at det ville være det det flaskehals over CPU. Men i løbet af de sidste 6 måneder har jeg været i stand til at sikkerhedskopiere dette med kvantificerbare data. I avancerede CPU'er (såsom de fleste desktop Intel Core i7-modeller) er dette den største flaskehals, dit system vil opleve.
Lad os tage 4 build-konfigurationer, som jeg har testet dette på. Jeg vil her fremhæve CPU'en,
- Byg 1, min "ikke-opgraderede" pc, var en Intel i7-4790K med 32 GB DDR3-2400 RAM, en Samsung 840 Evo 250 GB til mit primære drev og en ældre Micron P400E 100 GB.
- Build 2, som var den opgraderede version af Build 1. Nu har en Intel i7-5960X overclocket til 4,0 GHz, 32 GB DDR4-3200 RAM, en Samsung SM951 512 GB AHCI m.2 SSD sammen med de to tidligere SSD'er. Fuld build-specifikationer for dette er på PCPartPicker.
- Build 3, en nylig bruger build, indeholdt en Intel i7-5820K overclocket til 4,2 GHz, 16 GB DDR4-2400 og 2 Samsung 840 EVO 120 GB i RAID0 (stribet) konfiguration.
- Build 4, en nylig serverbygning med en Intel Xeon E3-1270 v5 ved normale hastigheder, 32 GB DDR4-2133, en Samsung 950 Pro 512GB NVMe m.2 sammen med 4 SATA Samsung enterprise SSD'er i et RAID5-array.
Hvis du bare kiggede på dem, hvilken ville du så tro opnåede den laveste byggetid? Hvad med den anden? Til mit chok var det ikke den anden konfiguration, der tog den laveste byggetid - det var den tredje konfiguration, kl. knap 14 minutter til at bygge CyanogenMod 13.0. Så helt sikkert ville den dominerende CPU indtage andenpladsen, højre? Forkert igen. Build 4, som jeg lige er blevet færdig med at teste på, tog lidt over 25 minutter! Det er kun her, hvor min nuværende build står, 2 minutter langsommere end et system med halvdelen af kernerne og trådene, men et SSD-array på 3 SSD'er, hvorimod mine SSD'er var selvstændige. SM951 har også været kendt for at have problemer med gasspjældet, hvis det bliver for varmt, noget der kunne være en meget reel faktor i dette tilfælde. Den første og langsomste build tog omkring 30 minutter, en af de eneste gange, jeg havde bygget CM 13.0; Jeg har hørt om lignende byggekonfigurationer, der gør det i 27.
SSD'er plejede også at være en svær genstand at få, så der var meget lidt diskussion om emnet. Priserne er dog faldet dramatisk både i detail- og brugtmarkederne i løbet af det sidste år. Med 120 GB SSD'er nu under $50, er det ikke den barriere, det engang var at tilføje en til et system. Traditionelle harddiske vil også gøre jobbet, men brugere er mere tilbøjelige til at nå denne flaskehals før andre, hvis de ikke bruger SSD'er.
CPU: Når jeg nævner ovenfor, at den øverste flaskehals er disk I/O, er det en antagelse, som måske ikke altid er tilfældet - hver af de builds, jeg brugte, indeholdt en Intel Core i7. Men som jeg fandt med Xeon-serveren, holder disken med, men holder så alle 8 CPU-tråde ved høj udnyttelse gennem de tungeste byggeprocesser. Og prøv som jeg kunne, uden RAID-arrayet, som vi fandt ovenfor, finder jeg ikke, at min Haswell-E engang er tæt på fuldt ud udnyttet til det meste af byggeprocessen. Så hvis du leder efter det bedste valuta for din byggepenge, så overvej Intel i7-5820K.
Sandt nok er det X99, og så bundkortet kan være dyrere end et Z97 bundkort; men vi er også stadig i år et af X99-cyklussen. Priserne for Broadwell-E forventes også at forblive de samme som Haswell-E ved udgivelsen, hvilket betyder, at du burde kunne købe dig ind i entusiastsegmentet til næsten samme pris som en i7-4790K eller i7-6700K.
På Intel er der ikke meget grund til at gå ud over en 5820K i øjeblikket, da du kan få imponerende byggetider med den. For det meste vil jo højere core/tråd-antal nedenfor, sammen med processorhastigheder, give dig en hurtigere opbygningstid. En i7-4770R i en GIGABYTE Brix sidste år gav mig i gennemsnit en bygning på 42 minutter. Selvom det ikke var det hurtigste, passede det til mine behov og gav mig mulighed for at have en dedikeret lav-strøm konfiguration. Du finder det samme med AMD APU'er - selvom de måske ikke i øjeblikket yder så godt som deres Intel-modstykke, vil de nemt få arbejdet gjort og normalt til en lavere pris end at købe Intel. Dette er en situation, jeg har nøje øje med, for hvis rygterne er sande, kan Zen-baserede APU'er muligvis lukke det hul betydeligt.
Der er et resultat for dem af jer, der ville vælge at fjerne disse flaskehalse, en der gælder for hjemmebrugere mere end kontoret. Generel ydeevne vil øges på et system ved at fjerne disse flaskehalse. Især gamere vil opleve, at en opgradering for at løse disse flaskehalse i næsten alle tilfælde også vil øge spillets ydeevne. Selvom den måske ikke har vundet den hurtigste byggetid, gav den anden build en uventet overraskelse - en loadtid på 30 sekunder på Bare årsag 3 når mange andre klagede over indlæsningstider i minutter. I sidste ende er disse byggetider virkelig høje og kan være overkill for mange... men i det mindste nu er argumentet om, at flere kerner vil betyde hurtigere builds, endelig blevet sat til ro.
Da dette kun er begyndelsen, håber vi, at læserne vil kime ind og dele deres byggeoplevelser på forskellige konfigurationer. Vil du som læser se flere diskussioner om denne type emner? Lyd af i kommentarerne nedenfor!