Nyfiken på vilka flaskhalsar som AOSP-projektet skapar? Dan delar med sig av sina upptäckter - vilket kan förvåna läsarna om vad som gör och inte orsakar en flaskhals.
Uppdatering 19/4 12:00 CT: Förtydligade byggtider är ccache-byggtider.Uppdatering 20/4 09:17 CT: Build 3 var absolut inte RAID 1. Rättade det felet.
2012 började jag bygga kärnor -- och förlitade mig på min pålitliga Core 2 Quad Q9550 för att bygga den. Om det inte var värt att krypa så kommer det faktum att jag gjorde det i en virtuell dator inuti Windows förmodligen att säkerställa det för de flesta som bygger Android från källan.
En virtualiserad Ubuntu-miljö fungerar inte lika bra som en inbyggd miljö och oj, vad smärtsamt det blev uppenbart när en kärna tog över 2 timmar att bygga. Eftersom jag ville börja bygga Android från källan året därpå visste jag att min nuvarande hårdvara inte skulle göra det klippte det -- och så började en lång och fortfarande pågående resa för att hitta ett sätt att minska den ständigt växande byggnaden tid.
Under åren sedan dess har jag haft turen att testa på flera formfaktorer och plattformar. Detta är viktigt eftersom byggkonfigurationer inte är en situation som passar alla med Android. En applikationsutvecklare kanske inte behöver samma konfiguration som spelutvecklare. Och någon som bara bygger kärnor behöver kanske inte spendera lika mycket som någon som behöver bygga en fullständig Android ROM från källan på mycket kort tid. Och hur är det med OS-val – vad kan (och inte) användas just nu? Jag hoppas kunna utforska detta mer också, särskilt med Windows och Canonical arbetar för att få en fullfjädrad Bash till Windows 10.
För att starta den här serien på rätt sätt måste vi ta reda på var de största potentiella flaskhalsarna finns i att bygga AOSP-projekt från källan. Vi går inte ofta och handlar efter en PC eller uppgraderar utan att veta var vi ska lägga dina pengar. Så baserat på 3 års forskning och kvantifierbara resultat är jag redo att dela med mig av vad jag har hittat. Nu den förväntade friskrivningen: Dessa fynd är baserade på personliga erfarenheter och kan omöjligt ta hänsyn till alla kombinationer. Ni som har en egen byggkonfiguration, låter avstängda och låt oss veta hur det går för era byggen! Tiderna hänvisar också till byggnader med ccache aktiverad och ifylld - var vanligtvis dubbel när ccachen inte fylldes i ännu.
Disk I/O: Jag måste ge ett hatttips till Cyanogens Tom Marshall - också en medlem av Team Kang - för att du pekade mig i denna riktning förra året. Jag trodde ärligt talat inte på honom när han sa till mig att det skulle bli så de flaskhals över CPU. Men under de senaste 6 månaderna har jag kunnat säkerhetskopiera detta med kvantifierbara data. I avancerade processorer (som de flesta stationära Intel Core i7-modeller) är detta den största flaskhalsen som ditt system kommer att uppleva.
Låt oss ta 4 byggkonfigurationer som jag har testat detta på. Jag ska här markera CPU,
- Bygg 1, min "ouppgraderade" PC, var en Intel i7-4790K med 32 GB DDR3-2400 RAM, en Samsung 840 Evo 250 GB för min primära enhet och en äldre Micron P400E 100 GB.
- Build 2, som var den uppgraderade versionen av Build 1. Nu har en Intel i7-5960X överklockad till 4,0 GHz, 32 GB DDR4-3200 RAM, en Samsung SM951 512 GB AHCI m.2 SSD tillsammans med de två tidigare SSD: erna. Fullständiga byggspecifikationer för detta finns på PCPartPicker.
- Build 3, en ny användarversion, innehöll en Intel i7-5820K överklockad till 4,2 GHz, 16 GB DDR4-2400 och 2 Samsung 840 EVO 120 GB i RAID0 (randig) konfiguration.
- Bygg 4, en nyligen uppdaterad serverbyggnad med en Intel Xeon E3-1270 v5 vid normala hastigheter, 32 GB DDR4-2133, en Samsung 950 Pro 512 GB NVMe m.2 tillsammans med 4 SATA Samsung-företags-SSD: er i en RAID5-array.
Om du bara tittade på dem, vilken skulle du tro hade den lägsta byggtiden? Vad sägs om den andra? Till min chock var det inte den andra konfigurationen som tog lägst byggtid - det var den tredje konfigurationen, kl. knappt 14 minuter för att bygga CyanogenMod 13.0. Så säkerligen skulle den dominerande CPU: n ta andraplatsen, höger? Fel igen. Bygg 4, som jag precis testat klart, tog drygt 25 minuter! Bara här är min nuvarande konstruktion, 2 minuter långsammare än ett system med hälften av kärnorna och trådarna men en SSD-uppsättning av 3 SSD-enheter, medan mina SSD-enheter var fristående. SM951 har också varit känt för att ha problem med strypning om det blir för varmt, något som kan vara en mycket verklig faktor i det här fallet. Det första och långsammaste bygget tog cirka 30 minuter, en av de enda gångerna jag hade byggt CM 13.0; Jag har hört talas om liknande byggkonfigurationer som gör det i 27.
SSD: er brukade också vara ett svårt föremål att få tag på så det var väldigt lite diskussion om ämnet. Priserna har dock sjunkit dramatiskt både på detaljhandeln och begagnade marknader under det senaste året. Med 120 GB SSD nu under 50 $ är det inte den barriär det en gång var att lägga till en till ett system. Traditionella hårddiskar kommer att göra jobbet också, men användare är mer benägna att nå denna flaskhals före andra om de inte använder SSD.
CPU: När jag nämner ovan att den översta flaskhalsen är disk-I/O, bygger det på ett antagande som kanske inte alltid är fallet - var och en av de byggnader jag använde innehöll en Intel Core i7. Men som jag hittade med Xeon-servern så hänger disken med men håller sedan alla 8 CPU-trådar vid högt utnyttjande genom de tyngsta byggprocesserna. Och försök som jag kan, utan RAID-arrayen som vi hittade ovan tycker jag inte att min Haswell-E ens är i närheten av fullt utnyttjad för större delen av byggprocessen. Så om du letar efter bästa valuta för din byggnad, överväg Intel i7-5820K.
Det är sant att det är X99 och så moderkortet kan vara dyrare än ett Z97-moderkort; men vi är också fortfarande i år ett av X99-cykeln. Priserna för Broadwell-E förväntas också förbli liknande Haswell-E vid release, vilket betyder att du borde kunna köpa in dig i entusiastsegmentet för nästan samma pris som en i7-4790K eller i7-6700K.
På Intel finns det inte mycket anledning att gå längre än en 5820K för tillfället eftersom du kan få imponerande byggtider med den. För det mesta, ju högre kärn-/trådantalet nedan, tillsammans med processorhastigheter, ger dig en snabbare byggtid. En i7-4770R i en GIGABYTE Brix förra året gav mig ett snitt på 42 minuter. Även om det inte var det snabbaste passade det mina behov och tillät mig att ha en dedikerad lågeffektskonfiguration. Du hittar samma sak med AMD APU: er - även om de för närvarande inte presterar lika bra som sin Intel-motsvarighet, kommer de lätt att få jobbet gjort och vanligtvis till ett lägre pris än att köpa Intel. Det här är en situation som jag har ett nära öga på, för om ryktena är sanna kan Zen-baserade APU: er minska det gapet avsevärt.
Det finns ett resultat för de av er som skulle välja att ta bort dessa flaskhalsar, en som gäller hemanvändare mer än kontoret. Generell prestanda kommer att öka på ett system genom att ta bort dessa flaskhalsar. Spelare i synnerhet kommer att upptäcka att uppgradering för att åtgärda dessa flaskhalsar i nästan alla fall också kommer att öka spelets prestanda. Även om det kanske inte har vunnit den snabbaste byggtiden, gav det andra bygget en oväntad överraskning - en laddningstid på 30 sekunder på Just Cause 3 när många andra klagade på laddningstider i minuter. I slutändan är dessa byggtider riktigt höga och kan vara överdrivna för många... men nu har åtminstone argumentet att fler kärnor kommer att innebära snabbare byggnationer äntligen lagts ner.
Eftersom detta bara är början hoppas vi att läsarna hör av sig och delar med sig av sina byggupplevelser på olika konfigurationer. Vill du som läsare se fler diskussioner om den här typen av ämnen? Ljud av i kommentarerna nedan!