Raspbian pindah ke mode 64-bit

Di halaman ini , pengumuman resmi RPi3 menyatakan:

Anda memerlukan gambar NOOBS atau Raspbian terbaru dari halaman unduhan kami. Saat diluncurkan, kami menggunakan 32-bit Raspbian userland yang sama yang kami gunakan pada perangkat Raspberry Pi lainnya; selama beberapa bulan ke depan kami akan menyelidiki apakah ada nilai dalam pindah ke mode 64-bit.

Pertanyaan saya adalah, mengingat bahwa prosesornya 64 bit, bukankah sudah jelas bahwa menjalankan OS dalam 64 bit akan lebih baik dalam segala hal? Apa yang saya lewatkan?

mengingat bahwa prosesor 64 bit, bukankah sudah jelas menjalankan OS dalam 64 bit akan lebih baik dalam segala hal?

Sebenarnya tidak. Dalam beberapa hal, menjalankan sistem operasi 64 bit dapat menurunkan kinerja Raspberry Pi.

Manfaat 64 bit :

Dua manfaat utama menggunakan prosesor 64 bit / sistem operasi adalah bahwa perangkat dapat menangani lebih dari 4 GB RAM, dan secara asli menangani bilangan bulat yang lebih besar daripada 2^32tanpa memerlukan perpustakaan bignum.

Raspberry Pi tidak memiliki lebih dari 4 GB RAM. Dengan RAM 1 GB, Anda benar-benar kehilangan yang pertama dari dua manfaat utama. Adapun manfaat kedua, berapa persen orang yang benar-benar menggunakan angka raksasa yang cukup sehingga masuk akal bagi yayasan untuk mendukung sistem operasi seluruh detik? Seperti halnya, RPi dapat menggunakan angka besar melalui metode perangkat lunak, tetapi sepertinya jika Anda akan konsisten di bidang itu, Anda harus tetap menggunakan perangkat keras yang lebih baik.

Masalah dengan 64 bit :

Kemampuan untuk menyimpan jumlah yang lebih besar tidak diberikan oleh sihir. Sebaliknya, ukuran objek memori perlu ditingkatkan. Dalam C (dan C ++) ini berarti mengubah intke int64_t. Ini tidak dilakukan secara otomatis, maka komentar tentang yayasan tidak ingin mempertahankan dua cabang.

Selain itu, banyak aplikasi tidak memberikan manfaat (untuk sebagian besar pengguna) saat dijalankan dalam mode 64 bit. Perhatikan bahwa sebagian besar peramban web, MS Office, dan sejumlah besar peranti lunak populer lainnya semuanya masih dikirimkan dan dirawat dengan cara 32 bit. Tentu Anda bisa mendapatkan rilis MS Office 64 bit, tetapi ini jarang digunakan.

Jika aplikasi / sistem operasi ditulis untuk memanfaatkan arsitektur 64 bit, aplikasi Anda akan menggunakan lebih banyak memori, hanya karena variabel dan pointer mengambil lebih banyak ruang. Biasanya ini adalah trade off yang relatif kecil untuk mesin yang akan mendapat manfaat dari manfaatnya. Dalam kasus kami, kami memiliki sangat sedikit fasilitas, dan sangat sedikit RAM.

Juga dari catatan :

Hanya karena Anda menjalankan mesin 64 bit, bukan berarti aplikasi tidak berjalan sebagai 32 bit. Windows membuat ini sangat jelas dengan memiliki dua jalur instalasi berbeda, C:\Program Filesdan C:\Program Files (x86).

Jadi, akankah yayasan kemungkinan memberikan dukungan 64 bit? :

Kami kembali pada titik yang sama, "Beberapa orang mungkin melihat manfaat, tetapi sebagian besar tidak." Anda tentu akan melihat proyek lain menawarkan build 64 bit, tetapi kecuali jika yayasan mendapatkan banyak kekurangan (imo) yang tidak layak, mereka mungkin tidak akan dan tidak seharusnya (imo). Membuat dan memelihara cabang 64 bit yang terpisah bukanlah usaha kecil, dan jujur, sepertinya tidak sepadan.

Perlu dicatat bahwa situasinya berbeda untuk ARM dan Intel / AMD. Itu karena beralih ke x86_64 juga digunakan sebagai kesempatan untuk memperbarui arsitektur yang sangat tua, pada dasarnya lumpuh dengan hanya memiliki 8 register tujuan umum - dan dua kali lipat dalam mode 64-bit. Jadi, mengalihkan sistem Intel / AMD ke mode 64-bit juga berarti mengaktifkan fitur nyata yang membuat perbedaan signifikan dalam kinerja.

Awalnya ARM tidak memiliki masalah ini (meskipun AArch64 menambahkan register, arsitektur 32-bit tidak kelaparan untuk mereka), jadi manfaatnya pada dasarnya lebih langsung dialamatkan memori dan dukungan bilangan bulat besar asli - jauh lebih kecil dari yang besar berurusan, dan mungkin dinetralkan oleh sisi negatifnya (lebih banyak memori digunakan untuk semuanya).

(Sebagai tambahan, untuk alasan ini, ada beberapa pekerjaan dalam menciptakan abi "x32" untuk Intel / AMD Linux , menjaga peningkatan CPU tetapi menggunakan pointer 32-bit.)

Saya yakin sudah ada orang yang menjalankan Debian Aarch64 (ARMv8) di Pi 3; itu tentu tidak akan terlalu sulit bagi banyak orang ( lihat di sini untuk mengetahui beberapa petunjuk tentang hal itu mungkin berhasil) ¹ walaupun bagi sebagian besar pengguna mungkin sedikit sulit.

Namun, jika Raspbian dan / atau Foundation tidak mengeluarkan versi 64-bit, Anda akan semakin melihat orang-orang dengan blog, dll., Menjelaskan cara menjalankannya dan masih mendapatkan barang yang Anda butuhkan.

Sekarang ada rilis Fedora aarch64 untuk Pi 3.

^{1. Akan ada beberapa komplikasi dengan hal- /opt/vchal 32-bit , saya tidak yakin bagaimana bisa diatasi itu; dulu ada 32-bit compat libs untuk x86-64 tapi Aarch64 ... mungkin tidak.}

Sebagai bagian dari publisitas peluncuran, saya melihatnya menyebutkan bahwa satu perhatian adalah upaya yang diperlukan untuk mempertahankan dua basis kode yang terpisah (32 dan 64 bit). video Peluncuran Adafruit PI3 juga menyebutkan bahwa perpindahan ke prosesor 64bit lebih banyak tentang peningkatan kecepatan clock chip baru yang disediakan daripada tentang menggunakan mode 64bit.

Mengatasi pernyataan bahwa program asli 64 bit lebih besar (lebih banyak memori untuk data dan petunjuk), dan bahwa tidak ada manfaat nyata untuk OS 64 vs 32 bit pada ARMv8 dengan RAM kurang dari 4GB, saya ingin menambah beberapa poin.

Ada beberapa perbedaan yang signifikan dalam hal-hal yang dilakukan di ARMv7 (dan sebelumnya) dan ARMv8, secara arsitektur, yang membuat eksekusi ARMv8 lebih efisien. Beberapa di antaranya adalah dari jalur data internal yang lebih luas, beberapa adalah penghapusan kasus khusus, dan saluran pipa yang jauh lebih dalam). Perubahan yang sama ini membuat ARMv8 lebih baik dalam menjalankan kode ARMv7 (32 bit).

Aplikasi 64 bit asli memang menggunakan pointer 64 bit dan 'size_t' adalah 64 bit, sehingga elemen yang menggunakannya menjadi lebih besar. Sisa data akan cenderung berukuran sama. Namun, signifikansi ini kecil untuk ukuran gambar yang dapat dieksekusi.

Di mana 64 bit asli benar-benar bersinar (jika Anda tidak peduli tentang hal-hal integer dan floating point besar) memiliki ruang alamat virtual yang lebih besar:

• OS mampu membagi ruang alamat virtual menjadi bagian yang lebih banyak dan lebih besar, memungkinkan pengelolaan sumber daya bersama yang lebih mudah, konteks yang lebih ramping, beralih di antara berbagai tingkat hak istimewa, dan sebagainya.
• Jika Anda telah mengaktifkan swapping, Anda dapat menjalankan proses yang lebih banyak dan lebih besar, melebihi batas memori fisik (ini sebenarnya berlaku di 32 bit juga, tetapi Anda kurang terbatas dalam 64 bit)

Apakah OS saat ini mengambil keuntungan dari ini atau tidak, itu akan membuat perbedaan ketika arus utama menjauh dari 32 bit.

Saya pikir argumen terbaik untuk pindah ke kernel AArch64 64 bit asli adalah portabilitas: Desktop mainstream sebagian besar telah pindah ke prosesor 64 bit, dan saya melihat lebih banyak paket yang mengasumsikan 64 bit, dan porting kode tersebut kembali ke 32 bit lebih sulit dari porting dari 32 hingga 64 bit. Di ruang pengguna, Anda dapat menjalankan aplikasi 32 bit dan aplikasi 64 bit secara berdampingan, dengan asumsi Anda telah menginstal pustaka multi-lengkungan, sehingga tidak perlu untuk port 32 hingga 64 bit di mana ia tidak masalah. OS 64 bit hanya akan memberi Anda pilihan perangkat lunak yang lebih besar.

Saya tidak mengatakan bahwa memproduksi kernel 64 bit untuk Raspberry PI 3 mudah - ada perbedaan signifikan yang memerlukan perubahan pada level rendah, tidak semua driver perangkat 64 bit bersih (terutama driver untuk GPU spesifik ARM). Mungkin Raspberian akan tetap menjadi OS 32 bit, tapi saya percaya bahwa (dalam jangka panjang) itu picik.

Media boot tunggal (kartu SD, misalnya) dapat memuat versi OS 64 dan 32 bit, dan perangkat lunak boot sekunder (u-boot, arm-boot, dan lainnya) dapat menentukan yang mana yang akan dimuat. Bagian yang lebih sulit adalah userland - sistem file harus multi-lengkungan, bahkan pada sistem 32 bit di mana hal 64 bit tidak akan berguna. Saya akan membahas ini dengan skrip atau utilitas yang dapat dijalankan setelah boot awal untuk menghapus pustaka yang tidak dibutuhkan dan program yang dapat dieksekusi pada sistem 32 bit saja.

Pengalamatan 64-bit dapat berguna bahkan jika Anda tidak memiliki lebih dari 1GB memori.

Ini memungkinkan Anda memetakan file-file besar dengan memori, sehingga Anda memiliki sebuah pointer dan membiarkan OS melakukan I / O secara transparan. Hanya cara lain untuk melakukan I / O. Anda perlu pengalamatan 64-bit untuk melakukan ini pada file besar.

Contoh lain di mana saya melihatnya berguna adalah untuk memungkinkan proses memiliki lebih dari 2GB ruang alamat, menggunakan ruang swap. Saya baru-baru ini memiliki masalah pada NAS 32-bit dengan banyak penyimpanan, dan sistem file yang rusak. Proses fsck kehabisan memori, bahkan dengan opsi caching dihidupkan. Menambahkan ruang swap tidak dapat menyelesaikan masalah, ruang alamat 32-bit adalah batas yang sulit di sana. Jadi tidak ada cara untuk menjalankan fsck pada sistem file besar yang rusak ini dengan biner 32-bit. Dengan biner 64-bit dan beberapa ruang swap, itu akan berjalan.

Jawaban yang ada mencakup masalah lengkungan 64-bit dengan sangat baik, tapi saya tidak melihat banyak keuntungan lain dari peningkatan. Jadi, inilah dua yang baru-baru ini saya temukan:

• Ketika PHP menangani cap waktu Unix, ukuran integer dalam lengkungan 32-bit menetapkan batas atas pada tanggal, sehingga mereka tidak bisa melampaui hari tertentu pada tahun 2038 . Saya berharap ini adalah masalah untuk semua bahasa yang menangani stempel waktu. (Untungnya, sebagian besar subsistem penanganan tanggal yang tidak menggunakan cap waktu Unix, seperti DateTime PHP, dirancang secara khusus untuk tidak dibatasi oleh masalah ini bahkan pada CPU yang lebih tua).

• Mongo terbatas pada basis data di bawah 2G pada lengkungan ini, dan build 32-bit akan segera ditinggalkan. Dari manual :

  Mulai dalam MongoDB 3.2, binari 32-bit sudah usang dan tidak akan tersedia di rilis mendatang.

  Meskipun 32-bit build ada untuk Linux dan Windows, mereka tidak cocok untuk penyebaran produksi. Build 32-bit juga tidak mendukung mesin penyimpanan WiredTiger.

Pikiran saya tentang ini: Meskipun saya tidak tahu persis bagaimana prosesor ARM menangani memori, saya dapat memberitahu Anda ini dari beberapa arsitektur CPU sebelumnya yang saya programkan (SPARC / Alpha / i386 / AMD64 / X86_64): ketika menggunakan memori bersama dan menangani oleh penunjuk alamat virtual "nyata" nya, perpindahan ke 64bit bukanlah hal sepele. Meskipun memcpy melakukan apa yang seharusnya dilakukan, Anda perlu mempertimbangkan bahwa dalam 64 bit data disimpan seperti ini (bit mundur):

HGFEDCBA
HGFEDCBA
HGFEDCBA

namun dalam 32 bit terlihat seperti ini:

ABCD
ABCD
ABCD

Jadi, dalam 32 bit ketika Anda menyimpan katakan jpeg dalam RAM, Anda dapat membaca byte header-nya, atau melakukan deteksi tepi, tanpa masalah secara linear * katakan dengan meneruskan byte demi byte ke depan. Tetapi dalam arsitektur 64bit perubahan ini:

32 bit:

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64bit:

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}