Lurer du på hvilke flaskehalser AOSP-prosjektet bygger? Dan deler funnene sine - som kan overraske leserne om hva som forårsaker og ikke forårsaker en flaskehals.
Oppdatering 19/4 kl 12 CT: Klargjorte byggetider er ccache-byggetider.Oppdatering 20/4 09:17 CT: Bygg 3 var absolutt ikke RAID 1. Rettet den feilen.
I 2012 begynte jeg å bygge kjerner -- og stolte på min pålitelige Core 2 Quad Q9550 for å bygge den. Hvis det ikke var verdig til å nøle, vil det faktum at jeg gjorde det i en VM inne i Windows sannsynligvis sikre det for de fleste som bygger Android fra kilden.
Et virtualisert Ubuntu-miljø fungerer ikke så godt som et naturlig miljø, og åh, hvor smertefullt det ble gjort tydelig når en kjerne tok over 2 timer å bygge. Siden jeg ønsket å begynne å bygge Android fra kilden året etter, visste jeg at min nåværende maskinvare ikke ville det kuttet det -- og så begynte en lang og fortsatt pågående reise for å finne en måte å redusere den stadig voksende bygningen tid.
I årene siden da har jeg vært så heldig å teste på flere formfaktorer og plattformer. Dette er viktig siden byggekonfigurasjoner ikke er en situasjon som passer alle med Android. En applikasjonsutvikler trenger kanskje ikke samme konfigurasjon som spillutvikler. Og noen som bare bygger kjerner trenger kanskje ikke å bruke så mye som noen som trenger å bygge en full Android ROM fra kilden på veldig kort tid. Og hva med OS-valg -- hva kan (og kan ikke) brukes akkurat nå? Jeg håper å utforske dette mer også, spesielt med
Windows og Canonical jobber med å bringe en fullverdig Bash til Windows 10.For å starte denne serien riktig, må vi finne hvor de største potensielle flaskehalsene er i å bygge AOSP-prosjekter fra kilden. Det er ikke ofte vi handler etter en PC eller oppgraderer uten å vite hvor vi skal legge pengene dine. Så basert på 3 års forskning og kvantifiserbare resultater er jeg klar til å dele det jeg har funnet. Nå den forventede ansvarsfraskrivelsen: Disse funnene er basert på personlige erfaringer og kan umulig ta hensyn til alle kombinasjoner. De av dere med din egen byggekonfigurasjon, høres av og fortell oss hvordan det går med byggene dine! Tider refererer også til bygg med ccache aktivert og fylt - var vanligvis dobbelt når ccache ikke var fylt ennå.
Disk I/O: Jeg må gi et hattetips til Cyanogens Tom Marshall - også en medlem av Team Kang - for å peke meg i denne retningen i fjor. Jeg trodde ærlig talt ikke på ham da han fortalte meg at dette ville være de flaskehals over CPU. Men i løpet av de siste 6 månedene har jeg vært i stand til å sikkerhetskopiere dette med kvantifiserbare data. I avanserte CPUer (som de fleste stasjonære Intel Core i7-modeller) er dette den største flaskehalsen systemet ditt vil oppleve.
La oss ta 4 byggekonfigurasjoner som jeg har testet dette på. Jeg vil fremheve CPU her,
- Bygg 1, min "ikke-oppgraderte" PC, var en Intel i7-4790K med 32 GB DDR3-2400 RAM, en Samsung 840 Evo 250 GB for min primære stasjon og en eldre Micron P400E 100 GB.
- Build 2, som var den oppgraderte versjonen av Build 1. Nå har en Intel i7-5960X overklokket til 4,0 GHz, 32 GB DDR4-3200 RAM, en Samsung SM951 512 GB AHCI m.2 SSD sammen med de to tidligere SSD-ene. Full byggespesifikasjoner for dette er på PCPartPicker.
- Bygg 3, et nylig brukerbygg, inneholdt en Intel i7-5820K overklokket til 4,2 GHz, 16 GB DDR4-2400 og 2 Samsung 840 EVO 120 GB i RAID0 (stripet) konfigurasjon.
- Bygg 4, en nylig serverkonstruksjon med en Intel Xeon E3-1270 v5 ved normal hastighet, 32 GB DDR4-2133, en Samsung 950 Pro 512 GB NVMe m.2 sammen med 4 SATA Samsung enterprise SSD-er i en RAID5-array.
Hvis du bare så på disse, hvilken ville du tro oppnådde den laveste byggetiden? Hva med den andre? Til mitt sjokk var det ikke den andre konfigurasjonen som tok lavest byggetid - det var den tredje konfigurasjonen, kl. i underkant av 14 minutter for å bygge CyanogenMod 13.0. Så absolutt den dominerende CPU-en ville ta andreplassen, Ikke sant? Feil igjen. Bygg 4, som jeg nettopp var ferdig med å teste på, tok litt over 25 minutter! Bare her er den nåværende konstruksjonen min, 2 minutter langsommere enn et system med halvparten av kjernene og trådene, men en SSD-serie på 3 SSD-er, mens SSD-ene mine var frittstående. SM951 har også vært kjent for å ha gassproblemer hvis det blir for varmt, noe som kan være en veldig reell faktor i dette tilfellet. Det første og tregeste bygget tok omtrent 30 minutter, en av de eneste gangene jeg hadde bygget CM 13.0; Jeg har hørt om lignende byggekonfigurasjoner som gjør det i 27.
SSD-er pleide også å være en vanskelig gjenstand å få tak i, så det var veldig lite diskusjon om emnet. Prisene har imidlertid falt dramatisk både i detaljhandel og bruktmarked det siste året. Med 120 GB SSD-er nå under $50, er det ikke barrieren det en gang var å legge til en til et system. Tradisjonelle harddisker vil gjøre jobben også, men brukere er mer sannsynlig å nå denne flaskehalsen før andre hvis de ikke bruker SSD-er.
PROSESSOR: Når jeg nevner ovenfor at den øverste flaskehalsen er disk I/O, er det en antakelse som kanskje ikke alltid er tilfelle - hver av byggene jeg brukte inneholdt en Intel Core i7. Men som jeg fant med Xeon-serveren, holder disken opp, men holder deretter alle 8 CPU-tråder med høy utnyttelse gjennom de tyngste byggeprosessene. Og prøv som jeg kan, uten RAID-arrayet som vi fant ovenfor, finner jeg ikke at Haswell-E-en min er i nærheten av å være fullt utnyttet for det meste av byggeprosessen. Så hvis du leter etter det beste for byggepengene, bør du vurdere Intel i7-5820K.
Riktignok er det X99, og derfor kan hovedkortet være dyrere enn et Z97 hovedkort; men vi er også fortsatt i år ett av X99-syklusen. Prisene for Broadwell-E forventes også å forbli lik Haswell-E ved utgivelse, noe som betyr at du skal kunne kjøpe deg inn i entusiastsegmentet for nesten samme pris som en i7-4790K eller i7-6700K.
På Intel er det ikke mye grunn til å gå utover en 5820K for øyeblikket, da du kan få imponerende byggetider med den. For det meste vil jo høyere antall kjerne/tråder nedenfor, sammen med prosessorhastigheter, gi deg en raskere byggetid. En i7-4770R i en GIGABYTE Brix i fjor ga meg en gjennomsnittlig konstruksjon på 42 minutter. Selv om den ikke var den raskeste, passet den mine behov og tillot meg å ha en dedikert lavstrømkonfigurasjon. Du finner det samme med AMD APU-er - selv om de kanskje ikke for øyeblikket yter så godt som Intel-motparten, vil de enkelt få jobben gjort og vanligvis til en lavere pris enn å kjøpe Intel. Dette er en situasjon jeg har et godt øye med, for hvis ryktene er sanne, kan Zen-baserte APU-er lukke det gapet betydelig.
Det er et resultat for de av dere som ville valgt å fjerne disse flaskehalsene, en som gjelder hjemmebrukere mer enn kontoret. Generell ytelse vil øke på et system ved å fjerne disse flaskehalsene. Spesielt spillere vil oppleve at oppgradering for å løse disse flaskehalsene i nesten alle tilfeller også vil øke spillytelsen. Selv om den kanskje ikke har vunnet den raskeste byggetiden, ga den andre konstruksjonen en uventet overraskelse - en 30 sekunders lastetid på Bare årsak 3 når mange andre klaget på lastetider i minutter. Til syvende og sist er disse byggetidene veldig høye og kan være overkill for mange... men nå har i det minste nå endelig blitt lagt ned på argumentet om at flere kjerner vil bety raskere bygg.
Siden dette bare er begynnelsen, håper vi leserne vil kime inn og dele byggeerfaringene sine på forskjellige konfigurasjoner. Vil du som leser se flere diskusjoner om denne typen emner? Lyd av i kommentarfeltet nedenfor!