Raspbian passa alla modalità a 64 bit

In questa pagina , l'annuncio ufficiale di RPi3 afferma:

Avrai bisogno di un'immagine recente di NOOBS o Raspbian dalla nostra pagina di download. Al momento del lancio, stiamo utilizzando la stessa area utente Raspbian a 32 bit che utilizziamo su altri dispositivi Raspberry Pi; nei prossimi mesi esamineremo se è utile passare alla modalità a 64 bit.

La mia domanda è, dato che il processore è a 64 bit, non è ovvio che l'esecuzione del sistema operativo a 64 bit sarà migliore in ogni modo? Cosa mi sto perdendo?

dato che il processore è a 64 bit, non è ovvio che l'esecuzione del sistema operativo a 64 bit sarà migliore in tutti i modi?

No in realtà, non lo è. In un certo senso, l'esecuzione di un sistema operativo a 64 bit potrebbe deteriorare le prestazioni del Raspberry Pi.

Vantaggi di 64 bit :

I due principali vantaggi dell'utilizzo di un processore / sistema operativo a 64 bit è che il dispositivo può gestire più di 4 GB di RAM e gestire in modo nativo numeri interi più grandi che 2^32senza la necessità di una libreria bignum.

Il Raspberry Pi non ha più di 4 GB di RAM. Con 1 GB di RAM, hai perso completamente il primo dei due vantaggi principali. Per quanto riguarda il secondo vantaggio, quale percentuale di persone sta effettivamente utilizzando un numero sufficiente di numeri giganti che ha senso per la fondazione supportare un intero secondo sistema operativo? Così com'è, l'RPi può usare numeri enormi attraverso metodi software, ma sembra che se vuoi essere costantemente in quel regno, devi comunque usare hardware migliore.

Problemi con 64 bit :

La capacità di memorizzare un numero maggiore non è garantita dalla magia. Piuttosto, la dimensione degli oggetti di memoria deve essere aumentata. In C (e C ++) questo significa cambiare un intin int64_t. Questo non viene fatto automaticamente, quindi i commenti sulla fondazione non vogliono mantenere due rami.

Inoltre, molte applicazioni semplicemente non offrono vantaggi (per la maggior parte degli utenti) quando vengono eseguite in modalità 64 bit. Si noti che la maggior parte dei browser Web, MS Office e tutta una serie di altri software popolari sono ancora spediti e gestiti in modo a 32 bit. Sicuramente puoi mettere le mani su una versione a 64 bit di MS Office, ma è usata raramente.

Se l'applicazione / il sistema operativo è scritto per sfruttare un'architettura a 64 bit, l'applicazione utilizzerà più memoria, semplicemente perché variabili e puntatori occupano più spazio. Di solito si tratta di un compromesso relativamente piccolo per le macchine che trarranno vantaggio dai vantaggi. Nel nostro caso, abbiamo pochissimi vantaggi e pochissima RAM.

Da notare anche :

Solo perché sei in esecuzione su un computer a 64 bit, non significa che l'applicazione non sia in esecuzione a 32 bit. Windows lo rende molto chiaro avendo due diversi percorsi di installazione C:\Program Filese C:\Program Files (x86).

Quindi, la fondazione probabilmente fornirà supporto a 64 bit? :

Siamo tornati allo stesso punto di "Alcune persone potrebbero vedere benefici, ma la maggior parte no". Vedrai sicuramente altri progetti che offrono build a 64 bit, ma a meno che la fondazione non abbia un sacco di flack immeritato (imo), probabilmente non lo faranno e non dovrebbero (imo). Creare e mantenere un ramo separato a 64 bit non è un piccolo sforzo e, onestamente, non sembra valerne la pena.

Vale la pena notare che la situazione è diversa per ARM e Intel / AMD. Questo perché il passaggio a x86_64 è stato anche usato come un'opportunità per aggiornare l'architettura gravemente obsoleta, sostanzialmente paralizzata dal fatto di avere solo 8 registri di uso generale - e raddoppiata in modalità a 64 bit. Quindi, passare da un sistema Intel / AMD alla modalità a 64 bit significa anche abilitare funzionalità reali che fanno una differenza significativa nelle prestazioni.

ARM non ha questo problema per cominciare (sebbene AArch64 aggiunga i registri, le architetture a 32 bit non erano affamate per loro), quindi i vantaggi sono fondamentalmente memoria più indirizzabile e supporto nativo per numeri interi di grandi dimensioni - molto meno di un grande affare, e forse contrastato dal rovescio della medaglia (più memoria utilizzata per tutto).

(A parte questo, per questo motivo, c'è stato del lavoro nella creazione di un abi "x32" per Intel / AMD Linux , mantenendo i miglioramenti della CPU ma usando i puntatori a 32 bit.)

Sono sicuro che ci sono già persone che eseguono Debian Aarch64 (ARMv8) su Pi 3; non sarebbe certamente così difficile per molte persone ( vedi qui per alcuni indizi su ciò potrebbe funzionare) ¹ sebbene per la maggior parte degli utenti sia probabilmente un po 'allungato.

Tuttavia, se Raspbian e / o la Foundation non escono con una versione a 64 bit, vedrai sempre più persone con blog, ecc., Che spiegano come gestirne uno e ottenere comunque le chicche di cui hai bisogno.

Ora c'è una versione Fedora aarch64 per Pi 3.

^{1. Ci saranno alcune complicazioni con le /opt/vccose a 32 bit , non sono sicuro di quanto sia sormontabile; c'erano le librerie compatibili a 32 bit per x86-64 ma Aarch64 ... forse no.}

Come parte della pubblicità di lancio, ho visto che una preoccupazione riguarda lo sforzo richiesto per mantenere due basi di codice separate (32 e 64 bit). il video di lancio di Adafruit PI3 menzionava anche che il passaggio a un processore a 64 bit riguardava più la velocità di clock che aumentava il nuovo chip fornito che l'uso della modalità a 64 bit.

Affrontando l'affermazione che i programmi nativi a 64 bit sono più grandi (più memoria per dati e puntatori) e che non ci sono vantaggi evidenti per un sistema operativo a 64 vs 32 bit su ARMv8 con meno di 4 GB di RAM, desidero aumentare alcuni punti.

Ci sono alcune differenze significative nel modo in cui le cose vengono fatte in ARMv7 (e prima) e ARMv8, dal punto di vista architettonico, che rendono l'esecuzione ARMv8 più efficiente. Alcuni di questi provengono da percorsi di dati interni più ampi, altri dall'eliminazione di casi speciali e da una pipeline molto più profonda). Queste stesse modifiche rendono ARMv8 migliore nell'esecuzione del codice ARMv7 (32 bit).

Le applicazioni native a 64 bit usano puntatori a 64 bit e 'size_t' è 64 bit, quindi gli elementi che usano quelle diventano più grandi. Il resto dei dati tenderà a rimanere della stessa dimensione. Il significato di questo è minore, tuttavia, per la dimensione delle immagini eseguibili.

Dove il nativo a 64 bit brilla davvero (se non ti interessano cose di grandi numeri interi e in virgola mobile) sta avendo uno spazio di indirizzi virtuale più grande:

• Il sistema operativo è in grado di dividere lo spazio degli indirizzi virtuali in sezioni sempre più grandi, consentendo una gestione più semplice delle risorse condivise, cambi di contesto più snelli tra diversi livelli di privilegi e così via.
• Se hai abilitato lo scambio, puoi eseguire processi sempre più grandi, superando i limiti di memoria fisica (questo è vero anche a 32 bit, ma sei meno limitato a 64 bit)

Indipendentemente dal fatto che il sistema operativo ne approfitti attualmente, farà la differenza quando il mainstream si allontana da 32 bit.

Penso che l'argomento migliore per passare a un kernel AArch64 nativo a 64 bit sia la portabilità: il desktop mainstream si è spostato principalmente su processori a 64 bit e sto vedendo più pacchetti che assumono 64 bit e il porting di tale codice su 32 bit è più difficile rispetto al porting da 32 a 64 bit. Nello spazio utente, sei in grado di eseguire applicazioni a 32 bit e applicazioni a 64 bit fianco a fianco, supponendo che tu abbia installato le librerie multi-arch, quindi non è necessario eseguire il porting da 32 a 64 bit dove non importa. Un sistema operativo a 64 bit ti offrirà semplicemente la più ampia selezione di software.

Non sto dicendo che produrre un kernel a 64 bit per Raspberry PI 3 sia facile: ci sono differenze significative che richiedono modifiche a basso livello, non tutti i driver di dispositivo sono puliti a 64 bit (in particolare i driver per GPU specifiche ARM). È possibile che Raspberian rimanga un sistema operativo a 32 bit, ma credo che (a lungo raggio) sia miope.

Un singolo supporto di avvio (scheda SD, ad esempio) può contenere entrambe le versioni del sistema operativo a 64 e 32 bit e il software di avvio secondario (u-boot, arm-boot e altri) può determinare quale caricare. La parte più difficile è userland - il file system dovrebbe essere multi-arch, anche su sistemi a 32 bit in cui le cose a 64 bit saranno inutili. Lo affronterei con uno script o un'utilità che potrebbe essere eseguita dopo l'avvio iniziale per rimuovere le librerie e gli eseguibili di programma non necessari solo su sistemi a 32 bit.

L'indirizzamento a 64 bit può essere utile anche se non si dispone di più di 1 GB di memoria.

Ti consente di mappare in memoria file di grandi dimensioni, quindi hai un puntatore e lascia che il sistema operativo esegua l'I / O in modo trasparente. Solo un altro modo di fare I / O. Per eseguire questa operazione su file di grandi dimensioni è necessario un indirizzamento a 64 bit.

Un altro esempio in cui vedo che può essere utile è consentire ai processi di avere più di 2 GB di spazio degli indirizzi, utilizzando lo spazio di swap. Di recente ho avuto un problema su un NAS a 32 bit con molta memoria e un filesystem danneggiato. Il processo fsck ha esaurito la memoria, anche con le opzioni di memorizzazione nella cache attivate. L'aggiunta di spazio di swap non ha potuto risolvere il problema, lo spazio degli indirizzi a 32 bit era il limite rigido lì. Quindi non c'era proprio modo di eseguire fsck su questo grande filesystem danneggiato con un binario a 32 bit. Con un binario a 64 bit e un po 'di spazio di swap, sarebbe stato eseguito.

Le risposte esistenti coprono molto bene i problemi di un arco a 64 bit, ma non vedo molti vantaggi dichiarati dell'aggiornamento. Quindi, ecco due che ho scoperto di recente:

• Quando PHP gestisce i timestamp Unix, la dimensione intera in un arco a 32 bit imposta un limite superiore per le date, in modo tale che non possano andare oltre un determinato giorno nel 2038 . Mi aspetto che questo sia un problema per tutte le lingue che gestiscono i timestamp. (Per fortuna, la maggior parte dei sottosistemi di gestione delle date che non utilizzano i timestamp di Unix, come DateTime di PHP, sono progettati specificamente per non essere limitati da questo problema anche su CPU meno recenti).

• Mongo è limitato a database di dimensioni inferiori a 2G su questo arco e le build a 32 bit saranno presto deprecate. Dal manuale :

  A partire da MongoDB 3.2, i binari a 32 bit sono obsoleti e non saranno disponibili nelle versioni future.

  Sebbene le build a 32 bit esistano per Linux e Windows, non sono adatte per le distribuzioni di produzione. Le build a 32 bit inoltre non supportano il motore di archiviazione WiredTiger.

I miei pensieri su questo: anche se non so esattamente come un processore ARM affronti la memoria, posso dirti questo dalle precedenti architetture multiple della CPU che ho programmato su (SPARC / Alpha / i386 / AMD64 / X86_64): quando uso memoria condivisa e indirizzamento con il suo "reale" puntatore di indirizzo virtuale, il passaggio a 64 bit non è banale. Sebbene memcpy faccia quello che dovrebbe fare, devi considerare che in 64 bit i dati sono memorizzati in questo modo (bit all'indietro):

HGFEDCBA
HGFEDCBA
HGFEDCBA

ma a 32 bit sembra così:

ABCD
ABCD
ABCD

Quindi, a 32 bit quando memorizzi un jpeg nella RAM, puoi leggere i suoi byte di intestazione o eseguire il rilevamento dei bordi, senza alcun problema in modo lineare * dire andando avanti byte per byte. Ma in un'architettura a 64 bit questo cambia:

32bit:

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) 
    } 
}