Interesanti, kādas vājās vietas rada AOSP projekts? Dens dalās ar saviem atklājumiem, kas varētu pārsteigt lasītājus par to, kas rada un neizraisa sašaurinājumu.
Atjauninājums 19.04.12.00 CT: Noskaidrotie izveides laiki ir kešatmiņas veidošanas laiki.Atjauninājums 20.04.09.17 CT: 3. būvējums noteikti nebija RAID 1. Izlaboja šo kļūdu.
2012. gadā es sāku veidot kodolus un paļāvos uz savu uzticamo Core 2 Quad Q9550, lai to izveidotu. Ja tas nebija satraukuma vērts, fakts, ka es to izdarīju virtuālajā datorā operētājsistēmas Windows iekšienē, droši vien nodrošinās to lielākajai daļai cilvēku, kuri veido Android no avota.
Virtualizēta Ubuntu vide nedarbojas tik labi kā vietējā vide, un ak, cik sāpīgi tas kļuva acīmredzams, kad kodola izveide aizņēma vairāk nekā 2 stundas. Tā kā nākamajā gadā vēlējos sākt veidot Android no avota, es zināju, ka mana pašreizējā aparatūra to nedarīs samazināja to — un tā sākās garš un joprojām nepārtraukts ceļojums, lai atrastu veidu, kā samazināt arvien pieaugošo būvniecību laiks.
Kopš tā laika man ir paveicies testēt uz vairākiem formas faktoriem un platformām. Tas ir svarīgi, jo operētājsistēmas Android versijas izveides konfigurācijas nav piemērotas visiem. Lietojumprogrammu izstrādātājam var nebūt vajadzīga tāda pati konfigurācija kā spēļu izstrādātājam. Un kādam, kurš veido tikai kodolus, iespējams, nevajadzēs tērēt tik daudz kā kādam, kuram ļoti īsā laikā ir jāizveido pilna Android ROM no avota. Un kā ir ar operētājsistēmas izvēli — ko šobrīd var (un nevar) izmantot? Es ceru izpētīt šo arī vairāk, jo īpaši ar Windows un Canonical strādā, lai ieviestu pilnvērtīgu Bash operētājsistēmā Windows 10.
Lai šo sēriju sāktu pareizi, mums ir jāatrod lielākās iespējamās vājās vietas, veidojot AOSP projektus no pirmavota. Mēs bieži nepērkam datoru vai jauninājumus, nezinot, kur likt naudu. Tāpēc, pamatojoties uz 3 gadu pētījumiem un kvantitatīvi nosakāmiem rezultātiem, esmu gatavs dalīties ar to, ko esmu atradis. Tagad gaidāmā atruna: šie atklājumi ir balstīti uz personīgo pieredzi un, iespējams, nevar ņemt vērā visas kombinācijas. Tie no jums, kuriem ir sava būvējuma konfigurācija, klusējiet un dariet mums zināmu, kā veicas jūsu būvēm! Laiks attiecas arī uz būvēm ar iespējotu un aizpildītu kešatmiņu — parasti tas bija divreiz, kad kešatmiņa vēl nebija aizpildīta.
Diska I/O: Jādod cepures gals Cyanogen Tomam Māršalam - arī a komandas Kang dalībnieks - par to, ka pagājušajā gadā norādīju mani šajā virzienā. Godīgi sakot, es viņam neticēju, kad viņš man teica, ka tā būs uz sašaurinājums pār CPU. Taču pēdējo 6 mēnešu laikā esmu varējis to apstiprināt ar kvantitatīviem datiem. Augstākās klases centrālajos procesoros (piemēram, lielākajā daļā galddatoru Intel Core i7 modeļu) šī ir lielākā vājā vieta, ar kuru saskarsies jūsu sistēma.
Ņemsim 4 būvējuma konfigurācijas, kurās esmu to pārbaudījis. Es šeit izcelšu centrālo procesoru,
- Build 1, mans "nejauninātais" dators, bija Intel i7-4790K ar 32 GB DDR3-2400 RAM, Samsung 840 Evo 250 GB manam primārajam diskam un vecāks Micron P400E 100 GB.
- Build 2, kas bija 1. būvējuma jauninātā versija. Tagad piedāvā Intel i7-5960X, kas pārspīlēts līdz 4,0 GHz, 32 GB DDR4-3200 RAM, Samsung SM951 512 GB AHCI m.2 SSD kopā ar diviem iepriekšējiem SSD. Pilnas būvēšanas specifikācijas ir pieejamas vietnē PCPartPicker.
- Build 3 — nesen izveidots lietotājs, kurā bija Intel i7-5820K, kas pārspīlēts līdz 4,2 GHz, 16 GB DDR4-2400 un 2 Samsung 840 EVO 120 GB RAID0 (svītrainā) konfigurācijā.
- Būvējums 4 — nesen izveidots servera komplekts ar Intel Xeon E3-1270 v5 normālu ātrumu, 32 GB DDR4-2133, Samsung 950 Pro 512 GB NVMe m.2, kā arī 4 SATA Samsung uzņēmuma SSD RAID5 masīvā.
Ja jūs tikai skatītos uz tiem, kurš no tiem, jūsuprāt, sasniedzis vismazāko izveides laiku? Kā ar otro? Man par šoku tā nebija otrā konfigurācija, kas prasīja vismazāko izveides laiku – tā bija trešā konfigurācija plkst nedaudz mazāk par 14 minūtēm, lai izveidotu CyanogenMod 13.0. Tātad dominējošais CPU noteikti ieņems otro vietu, pa labi? Atkal nepareizi. 4. būvējums, kuru tikko pabeidzu testēt, aizņēma nedaudz vairāk par 25 minūtēm! Tikai šeit ir mana pašreizējā versija, kas ir 2 minūtes lēnāka nekā sistēma ar pusi kodoliem un pavedieniem, bet SSD masīvu, kurā ir 3 SSD, savukārt mani SSD bija atsevišķi. Ir zināms, ka SM951 ir arī problēmas ar droseles darbību, ja tas kļūst pārāk karsts, kas šajā gadījumā varētu būt ļoti reāls faktors. Pirmā un lēnākā uzbūve aizņēma apmēram 30 minūtes, viena no vienīgajām reizēm, kad biju uzbūvējis CM 13.0; Esmu dzirdējis par līdzīgām konfigurācijām, kas to dara 27. gadā.
SSD diskus arī agrāk bija grūti iegūt, tāpēc par šo tēmu diskusiju bija ļoti maz. Tomēr cenas pēdējā gada laikā ir dramatiski samazinājušās gan mazumtirdzniecības, gan lietotu preču tirgos. Tā kā 120 GB SSD tagad maksā zem 50 ASV dolāriem, tas agrāk nebija šķērslis, lai to pievienotu sistēmai. Šo darbu paveiks arī tradicionālie cietie diski, taču lietotāji, visticamāk, sasniegs šo sašaurinājumu pirms citiem, ja neizmantos SSD.
PROCESORS: Kad es minēju iepriekš, ka galvenais šķērslis ir diska ievade/izvade, tas ir iespējams, pieņemot, ka ne vienmēr tā ir — katrā no šīm versijām, ko izmantoju, bija Intel Core i7. Bet, kā es atklāju ar Xeon serveri, disks neatpaliek, bet pēc tam saglabā visus 8 CPU pavedienus augstā noslogojumā, izmantojot vissmagākos veidošanas procesus. Un mēģiniet, kā es varu, bez RAID masīva, ko mēs atradām iepriekš, es neuzskatu, ka mans Haswell-E būtu gandrīz pilnībā izmantots lielākajā daļā veidošanas procesa. Tātad, ja jūs meklējat vislabāko risinājumu savai celtniecībai, apsveriet Intel i7-5820K.
Tiesa, tas ir X99 un tāpēc mātesplate var būt dārgāka nekā Z97 mātesplate; bet mēs joprojām esam X99 cikla pirmajā gadā. Paredzams, ka Broadwell-E cenas arī pēc izlaišanas paliks līdzīgas Haswell-E cenām, kas nozīmē, ka jums vajadzētu būt iespējai iegādāties entuziastu segmentu par gandrīz tādu pašu cenu kā i7-4790K vai i7-6700K.
Intel pašlaik nav daudz iemesla pārsniegt 5820 K, jo ar to jūs varat iegūt iespaidīgus izveides laikus. Lielākoties augstāks kodolu/pavedienu skaits, kā arī procesora ātrums nodrošinās ātrāku izveides laiku. i7-4770R ar GIGABYTE Brix pagājušajā gadā man vidēji ilga 42 minūtes. Lai gan tas nebija ātrākais, tas atbilda manām vajadzībām un ļāva man izveidot īpašu mazjaudas konfigurāciju. Jūs atradīsiet to pašu ar AMD APU — lai gan tie pašlaik var nedarboties tik labi kā to Intel kolēģi, tie viegli paveiks darbu un parasti par zemāku cenu nekā pērkot Intel. Šī ir situācija, kuru es uzmanīgi vēroju, jo, ja baumas ir patiesas, Zen balstīti APU var ievērojami novērst šo plaisu.
Tiem no jums, kas izvēlētos novērst šos vājos punktus, ir skaidrs rezultāts, kas vairāk attiecas uz mājas lietotājiem, nevis uz biroju. Novēršot šīs vājās vietas, sistēmas vispārējā veiktspēja palielināsies. Jo īpaši spēlētāji atklās, ka jaunināšana, lai novērstu šīs vājās vietas, gandrīz visos gadījumos palielinās arī spēļu veiktspēju. Lai gan tas, iespējams, nav ieguvis ātrāko izveides laiku, šī otrā versija radīja negaidītu pārsteigumu — ielādes laiks bija 30 sekundes. Tikai iemesls 3 kad daudzi citi sūdzējās par ielādes laiku minūtēs. Galu galā šie izveides laiki ir patiešām augstākās klases un daudziem var būt pārspīlēti... bet vismaz tagad beidzot ir apturēts arguments, ka vairāk kodolu nozīmēs ātrāku būvniecību.
Tā kā šis ir tikai sākums, mēs ceram, ka lasītāji piebalsos un dalīsies pieredzē par dažādām konfigurācijām. Vai kā lasītājs vēlaties redzēt vairāk diskusiju par šāda veida tēmām? Izklausieties komentāros zemāk!