Kíváncsi, milyen szűk keresztmetszeteket épít ki az AOSP projekt? Dan megosztja megállapításait – amelyek meglephetik az olvasókat, hogy mi okoz és mi nem okoz szűk keresztmetszetet.
Frissítés: 4/19, 12:00 CT: A pontosított felépítési idők a gyorsítótár felépítési idői.Frissítés: 4/20, 9:17 CT: A Build 3 egészen biztosan nem RAID 1 volt. Kijavította a hibát.
2012-ben elkezdtem kerneleket építeni – és a megbízható Core 2 Quad Q9550-emre támaszkodtam. Ha ez nem érdemelte meg a zsörtölődést, akkor az a tény, hogy a Windowson belüli virtuális gépben csináltam, valószínűleg ezt biztosítja a legtöbb olyan ember számára, aki az Androidot forrásból készíti.
A virtualizált Ubuntu környezet nem teljesít olyan jól, mint egy natív környezet, és ó, milyen fájdalmas ez nyilvánvalóvá vált, amikor egy kernel felépítése több mint 2 órát vett igénybe. Mivel a következő évben el akartam kezdeni az Android forrásból történő építését, tudtam, hogy a jelenlegi hardverem nem fog vágott bele -- és így kezdődött egy hosszú és még mindig folytatódó út, hogy megtalálják a módját az egyre növekvő építmény csökkentésének idő.
Az azóta eltelt években volt szerencsém többféle formai tényezőn és platformon tesztelni. Ez azért fontos, mert az összeállítási konfigurációk nem egyformák az Android esetében. Előfordulhat, hogy az alkalmazásfejlesztőnek nem kell ugyanazt a konfigurációt, mint a játékfejlesztőt. És valakinek, aki csak kerneleket készít, nem kell annyit költenie, mint annak, akinek egy teljes Android ROM-ot kell készítenie a forrásból nagyon rövid idő alatt. És mi a helyzet az operációs rendszer kiválasztásával -- mit lehet (és mit nem) használni most? Remélem, hogy ezt is jobban megvizsgálom, különösen A Windows és a Canonical azon dolgozik, hogy teljes értékű Bash-t hozzon a Windows 10 rendszerbe.
A sorozat megfelelő indításához meg kell találnunk, hol vannak a legnagyobb potenciális szűk keresztmetszetek az AOSP-projektek forrásból történő építésében. Nem gyakran megyünk úgy vásárolni számítógépet vagy frissítéseket, hogy ne tudnánk, hová tegyük a pénzt. Tehát 3 éves kutatás és számszerűsíthető eredmények alapján készen állok megosztani, amit találtam. Most a várható felelősségkizárás: ezek a megállapítások személyes tapasztalatokon alapulnak, és nem vehetik figyelembe az összes kombinációt. Azok, akik saját összeállítási konfigurációval rendelkeznek, hangosítsa el, és tudassa velünk, hogyan halad a buildje! Az idők olyan buildekre is utalnak, amelyeknél engedélyezve van és feltöltött ccache – ez általában kétszerese volt, amikor a ccache még nem volt feltöltve.
Lemez I/O: Kalaptippet kell adnom a Cyanogen Tom Marshall-nak - szintén a a Team Kang tagja - amiért tavaly ebbe az irányba mutatott. Őszintén szólva nem hittem neki, amikor azt mondta, hogy ez lesz a szűk keresztmetszet a CPU felett. De az elmúlt 6 hónapban ezt számszerűsíthető adatokkal tudtam alátámasztani. A felső kategóriás CPU-knál (például a legtöbb asztali Intel Core i7 modellnél) ez a legnagyobb szűk keresztmetszet, amellyel a rendszer szembesül.
Vegyünk 4 build konfigurációt, amelyeken ezt teszteltem. Itt kiemelem a CPU-t,
- A Build 1, a „frissítetlen” számítógépem egy Intel i7-4790K volt 32 GB DDR3-2400 RAM-mal, egy Samsung 840 Evo 250 GB az elsődleges meghajtómhoz és egy régebbi Micron P400E 100 GB.
- Build 2, amely a Build 1 frissített verziója volt. Most egy 4,0 GHz-re túlhajtható Intel i7-5960X, 32 GB DDR4-3200 RAM, Samsung SM951 512 GB AHCI m.2 SSD és a két korábbi SSD meghajtója található. A teljes build specifikáció a PCPartPicker oldalon található.
- A Build 3, egy nemrégiben készült felhasználói build, egy 4,2 GHz-re túlhajtható Intel i7-5820K-t, 16 GB DDR4-2400-at és 2 Samsung 840 EVO 120 GB-ot tartalmazott RAID0 (csíkos) konfigurációban.
- Build 4, egy nemrégiben készült kiszolgáló, amely normál sebességű Intel Xeon E3-1270 v5-öt, 32 GB DDR4-2133-at, Samsung 950 Pro 512 GB NVMe m.2-t és 4 SATA Samsung vállalati SSD-t tartalmaz RAID5 tömbben.
Ha csak ezeket néznéd meg, szerinted melyik érte el a legalacsonyabb építési időt? Mit szólnál a másodikhoz? Megdöbbenésemre nem a második konfiguráció vette igénybe a legkevesebb építési időt, hanem a harmadik konfiguráció volt alig 14 perc alatt elkészítheti a CyanogenMod 13.0-t. Tehát minden bizonnyal az uralkodó CPU lenne a második hely, jobb? Megint rossz. A 4-es build, amelynek tesztelését most fejeztem be, alig több mint 25 percig tartott! Csak itt áll a jelenlegi összeállításom, 2 perccel lassabb, mint egy olyan rendszer, amely feleannyi magot és szálat tartalmaz, de 3 SSD-ből álló SSD-tömböt tartalmaz, míg az SSD-k önállóak voltak. Az SM951-ről is köztudott, hogy gázproblémák vannak, ha túl meleg lesz, ami ebben az esetben nagyon is valós tényező lehet. Az első és leglassabb felépítés körülbelül 30 percig tartott, az egyik egyetlen alkalom, amikor CM 13.0-t készítettem; Hallottam hasonló build konfigurációkról, amelyek ezt csinálják 27-ben.
Az SSD-ket is nehéz volt beszerezni, így nagyon kevés vita folyt a témáról. Az árak azonban drámaian csökkentek az elmúlt évben mind a kiskereskedelmi, mind a használtcikk-piacokon. A 120 GB-os SSD-k jelenleg 50 dollár alatti áron nem jelentenek akadályt annak, hogy egy rendszert adjunk hozzá. A hagyományos merevlemezek is ellátják a feladatot, de a felhasználók nagyobb valószínűséggel érik el ezt a szűk keresztmetszetet mások előtt, ha nem használnak SSD-ket.
CPU: Amikor fentebb megemlítem, hogy a legfelső szűk keresztmetszet a lemez I/O, ez egy olyan feltételezésből fakad, amely nem mindig van így – az általam használt buildek mindegyike Intel Core i7-et tartalmazott. De amint azt a Xeon szervernél tapasztaltam, a lemez lépést tart, de ezután mind a 8 CPU-szálat magas kihasználtságon tartja a legnehezebb összeállítási folyamatok során. És bármennyire is próbálom, a fent talált RAID-tömb nélkül nem találom a Haswell-E-met a teljes építési folyamat nagy részében teljesen kihasználtnak. Tehát, ha a legjobb árat keresi az építőiparban, fontolja meg az Intel i7-5820K-t.
Igaz, X99-ről van szó, és így az alaplap drágább lehet, mint egy Z97-es alaplap; de még mindig az X99 ciklus első évében járunk. A Broadwell-E árai várhatóan hasonlóak maradnak a Haswell-E-hez a megjelenéskor, ami azt jelenti szinte ugyanolyan áron vásárolhat a lelkes szegmensbe, mint egy i7-4790K vagy i7-6700K.
Intelnél jelenleg nincs sok ok arra, hogy túllépjünk egy 5820K-n, mivel lenyűgöző építési időket érhetünk el vele. Legtöbbször minél magasabb az alábbi mag-/szálszám, valamint a processzorsebesség, az gyorsabb felépítési időt eredményez. Egy i7-4770R egy GIGABYTE Brixben tavaly átlagosan 42 percet épített fel. Bár nem a leggyorsabb, megfelelt az igényeimnek, és lehetővé tette egy dedikált alacsony fogyasztású konfigurációt. Ugyanezt tapasztalhatja az AMD APU-kkal is – bár lehet, hogy jelenleg nem teljesítenek olyan jól, mint Intel-társaik, könnyen elvégzik a munkát, és általában alacsonyabb áron, mint az Intel megvásárlása. Ez az a helyzet, amelyre nagyon figyelek, mert ha igazak a pletykák, akkor a Zen alapú APU-k jelentősen bezárhatják ezt a rést.
Van egy eredmény azoknak, akik úgy döntenek, hogy megszüntetik ezeket a szűk keresztmetszeteket, amely inkább az otthoni felhasználókra, mint az irodai felhasználókra vonatkozik. Ezen szűk keresztmetszetek megszüntetésével a rendszer általános teljesítménye javulni fog. A játékosok különösen azt fogják tapasztalni, hogy a szűk keresztmetszetek kiküszöbölésére irányuló frissítés szinte minden esetben növeli a játék teljesítményét. Bár lehet, hogy nem nyerte el a leggyorsabb felépítési időt, a második felépítés váratlan meglepetést okozott – 30 másodperces betöltési idő Csak ok 3 amikor sokan mások a percekben mért betöltési időkre panaszkodtak. Végül is ezek az építési idők nagyon magas színvonalúak, és sokak számára túlzásba eshetnek... de legalább most végre nyugvópontra került az az érv, hogy több mag gyorsabb felépítést jelent.
Mivel ez még csak a kezdet, reméljük, hogy az olvasók bekapcsolódnak és megosztják egymással tapasztalataikat a különféle konfigurációkkal kapcsolatban. Olvasóként szeretne több vitát látni az ilyen típusú témákról? Hallgassa meg az alábbi megjegyzésekben!