Kemacetan Terbesar Saat Membangun Android Dari Sumber

click fraud protection

Penasaran apa saja hambatan yang dibangun proyek AOSP? Dan membagikan temuannya -- yang mungkin mengejutkan pembaca tentang apa yang menyebabkan dan tidak menyebabkan kemacetan.

Pembaruan 19/4 12 siang CT: Waktu pembuatan yang diklarifikasi adalah waktu pembuatan ccache.Pembaruan 20/4 09:17 CT: Build 3 jelas bukan RAID 1. Memperbaiki kesalahan itu.

Pada tahun 2012 saya mulai membuat kernel -- dan mengandalkan Core 2 Quad Q9550 saya yang terpercaya untuk membuatnya. Jika itu tidak membuat ngeri maka fakta bahwa saya melakukannya di VM di dalam Windows mungkin akan memastikan hal itu bagi kebanyakan orang yang membangun Android dari sumber.

Lingkungan Ubuntu yang tervirtualisasi tidak berfungsi sebaik lingkungan asli dan oh, betapa menyakitkannya hal itu terlihat ketika sebuah kernel membutuhkan waktu lebih dari 2 jam untuk dibangun. Karena saya ingin mulai membangun Android dari sumbernya pada tahun berikutnya, saya tahu perangkat keras saya saat ini tidak akan mampu melakukannya hentikan -- dan dimulailah perjalanan yang panjang dan terus berlanjut untuk menemukan cara mengurangi pertumbuhan yang terus meningkat tersebut waktu.

Bertahun-tahun setelah itu, saya cukup beruntung bisa menguji berbagai faktor bentuk dan platform. Hal ini penting karena konfigurasi build bukanlah situasi yang bisa diterapkan pada Android. Pengembang aplikasi mungkin tidak memerlukan konfigurasi yang sama seperti pengembang game. Dan seseorang yang hanya membuat kernel mungkin tidak perlu mengeluarkan uang sebanyak seseorang yang perlu membuat ROM Android lengkap dari sumbernya dalam waktu yang sangat singkat. Lalu bagaimana dengan pemilihan OS -- apa yang bisa (dan tidak bisa) digunakan saat ini? Saya berharap untuk mengeksplorasi ini lebih jauh juga, terutama dengan Windows dan Canonical berupaya menghadirkan Bash yang lengkap ke Windows 10.

Untuk memulai rangkaian ini dengan benar, kita harus menemukan potensi hambatan terbesar dalam membangun proyek AOSP dari sumbernya. Kita tidak sering berbelanja PC atau upgrade tanpa mengetahui di mana harus menaruh uang Anda. Jadi berdasarkan penelitian selama 3 tahun dan hasil yang dapat diukur, saya siap membagikan apa yang saya temukan. Kini penafian yang diharapkan: Temuan ini didasarkan pada pengalaman pribadi dan tidak mungkin memperhitungkan semua kombinasi. Bagi Anda yang memiliki konfigurasi build Anda sendiri, bersuaralah dan beri tahu kami bagaimana kinerja build Anda! Times juga mengacu pada build dengan ccache diaktifkan dan diisi - biasanya dua kali lipat ketika ccache belum diisi.

Disk I/O: Saya harus memberikan tip topi kepada Tom Marshall dari Cyanogen - juga a anggota Tim Kang - karena mengarahkan saya ke arah ini tahun lalu. Sejujurnya aku tidak percaya padanya ketika dia memberitahuku bahwa ini akan terjadi itu kemacetan pada CPU. Namun selama 6 bulan terakhir saya dapat mendukungnya dengan data yang dapat diukur. Pada CPU kelas atas (seperti sebagian besar model desktop Intel Core i7), hal ini merupakan hambatan terbesar yang akan dialami sistem Anda.

Mari kita ambil 4 konfigurasi build yang telah saya uji. Saya akan menyorot di sini CPU,

  • Build 1, PC saya yang "belum ditingkatkan", adalah Intel i7-4790K dengan RAM DDR3-2400 32GB, Samsung 840 Evo 250GB untuk drive utama saya dan Micron P400E 100GB yang lebih lama.
  • Build 2, yang merupakan versi upgrade dari Build 1. Sekarang menggunakan Intel i7-5960X yang di-overclock hingga 4,0 GHz, RAM DDR4-3200 32 GB, SSD Samsung SM951 512 GB AHCI m.2 bersama dengan dua SSD sebelumnya. Spesifikasi build lengkap untuk ini ada di PCPartPicker.
  • Build 3, build pengguna terbaru, menampilkan Intel i7-5820K yang di-overclock hingga 4,2 GHz, DDR4-2400 16 GB, dan 2 Samsung 840 EVO 120 GB dalam konfigurasi RAID0 (bergaris).
  • Build 4, build server terbaru yang menampilkan Intel Xeon E3-1270 v5 dengan kecepatan normal, 32 GB DDR4-2133, Samsung 950 Pro 512GB NVMe m.2 serta 4 SSD perusahaan Samsung SATA dalam susunan RAID5.

Jika Anda hanya melihatnya, menurut Anda mana yang memiliki waktu pembuatan paling singkat? Bagaimana dengan yang kedua? Yang mengejutkan saya, bukan konfigurasi kedua yang membutuhkan waktu pembuatan terendah - melainkan konfigurasi ketiga hanya kurang dari 14 menit untuk membangun CyanogenMod 13.0. Jadi pastinya CPU yang mendominasi akan menempati posisi kedua, Kanan? Salah lagi. Build 4, yang baru saja saya selesaikan pengujiannya, hanya membutuhkan waktu 25 menit! Hanya di sinilah build saya saat ini berdiri, 2 menit lebih lambat dibandingkan sistem dengan setengah inti dan thread tetapi rangkaian SSD yang terdiri dari 3 SSD, sedangkan SSD saya berdiri sendiri. SM951 juga diketahui memiliki masalah pelambatan jika terlalu panas, sesuatu yang bisa menjadi faktor nyata dalam kasus ini. Pembuatan pertama dan paling lambat memakan waktu sekitar 30 menit, satu-satunya saat saya membuat CM 13.0; Saya pernah mendengar konfigurasi build serupa melakukannya di 27.

SSD juga dulunya merupakan barang yang sulit didapat sehingga sangat sedikit diskusi mengenai topik tersebut. Namun, harga telah turun drastis baik di pasar eceran maupun barang bekas selama setahun terakhir. Dengan SSD 120GB yang kini berada di bawah $50, menambahkan SSD ke dalam sistem bukanlah halangan lagi. Hard drive tradisional juga bisa melakukan pekerjaan ini, namun pengguna lebih mungkin mencapai hambatan ini dibandingkan pengguna lain jika tidak menggunakan SSD.

CPU TidurCPU: Ketika saya menyebutkan di atas bahwa hambatan teratas adalah I/O disk, hal ini menimbulkan asumsi yang mungkin tidak selalu terjadi - setiap build yang saya gunakan menampilkan Intel Core i7. Tapi seperti yang saya temukan dengan server Xeon, disk tetap bertahan tetapi kemudian mempertahankan semua 8 thread CPU pada pemanfaatan tinggi melalui proses pembangunan terberat. Dan berusaha sekuat tenaga, tanpa susunan RAID yang kami temukan di atas, saya tidak menemukan Haswell-E saya hampir digunakan sepenuhnya untuk sebagian besar proses pembangunan. Jadi, jika Anda mencari yang terbaik untuk uang bangunan Anda, pertimbangkan Intel i7-5820K.

Benar, ini adalah X99 sehingga motherboardnya mungkin lebih mahal daripada motherboard Z97; tapi kita juga masih berada di tahun pertama siklus X99. Harga Broadwell-E juga diperkirakan akan tetap sama dengan Haswell-E saat dirilis, artinya Anda seharusnya bisa membeli segmen antusias dengan harga yang hampir sama dengan i7-4790K atau i7-6700K.

Di Intel, tidak banyak alasan untuk melampaui 5820K saat ini karena Anda bisa mendapatkan waktu pembuatan yang mengesankan dengannya. Secara umum, semakin tinggi jumlah inti/thread di bawah ini, bersama dengan kecepatan prosesor, akan memberi Anda waktu pembuatan yang lebih cepat. Sebuah i7-4770R di GIGABYTE Brix tahun lalu membuat rata-rata waktu pembuatan saya menjadi 42 menit. Meskipun bukan yang tercepat, ini sesuai dengan kebutuhan saya dan memungkinkan saya memiliki konfigurasi khusus berdaya rendah. Anda akan menemukan hal yang sama dengan APU AMD - meskipun kinerjanya saat ini mungkin tidak sebaik rekan Intelnya, mereka dapat menyelesaikan pekerjaannya dengan mudah dan biasanya dengan harga yang lebih rendah daripada membeli Intel. Ini adalah situasi yang saya perhatikan dengan cermat karena jika rumor tersebut benar maka APU berbasis Zen dapat menutup kesenjangan tersebut secara signifikan.

Ada hasil bagi Anda yang ingin menghilangkan hambatan tersebut, yang lebih banyak terjadi pada pengguna rumahan dibandingkan kantor. Performa umum suatu sistem akan meningkat dengan menghilangkan hambatan-hambatan ini. Para gamer khususnya akan mendapati bahwa melakukan upgrade untuk mengatasi hambatan ini di hampir semua kasus juga akan meningkatkan performa game. Meskipun mungkin bukan waktu build tercepat, build kedua tersebut memberikan kejutan tak terduga -- waktu muat aktif 30 detik Hanya Penyebab 3 ketika banyak orang lain yang mengeluh tentang waktu muat dalam hitungan menit. Pada akhirnya, waktu pembuatan ini sangat canggih dan mungkin berlebihan bagi banyak orang... tapi setidaknya sekarang argumen bahwa lebih banyak inti berarti pembangunan lebih cepat akhirnya dikesampingkan.

Karena ini hanyalah permulaan, kami berharap pembaca akan ikut serta dan berbagi pengalaman membangun mereka pada berbagai konfigurasi. Sebagai pembaca, apakah Anda ingin melihat lebih banyak diskusi tentang topik seperti ini? Suarakan di komentar di bawah!