Ragazzi volevo domandarvi che differenza c'é tra i due tipo di processore?
Su uno smartphone sarebbe utile un 64 bit? Perché?
Processori 32 e 64 bit
Visualizzazione stampabile
-
04-10-14, 20:07xjasonxl10lProcessori 32 e 64 bit
-
05-10-14, 05:58ArrowbreakerPotenza elaborativa pura e quantità di memoria RAM indirizzabile (tecnicamente massimo 4Gb su un 32bit anche se poi effettivamente solo 3Gb possono essere usati, diversi Terabyte su un 64bit).Quote:
Originariamente inviato da xjasonxl10l
Bella domanda. Perché?Quote:
Originariamente inviato da xjasonxl10l
Belle risposte non ne ho, anche se immagino ci sia sempre quello che "lo vuole più grosso", forse a compensare qualche altra deficienza. Nel campo dei computer, i 64bit sono una necessità, con i software odierni e la loro fame insaziabile di memoria RAM e potenza elaborativa... e questo SOLO PER FAR GIRARE IL SISTEMA OPERATIVO... ma sui cellulari... ALMENO AL MOMENTO è un po come voler mettere il turbo ad un... giocattolo erotico.
Col tempo NON HO DUBBI il mercato degli smartphone si troverà faccia a faccia con la stessa necessità che i PC fronteggiano oggi, necessità di ram e tutto il resto, ma al momento è DI PARECCHIO un discorso pleonastico. -
05-10-14, 12:10xjasonxl10l
Incredibile però, si approfittano di queste "nuove" caratteristiche per fregare i pollo. Effettivamente su android 2 gb di ram bastano e avanzano quindi non capisco come potrebbero essere implementati.
Io tra un pò cambierò smartphone. Sono indeciso se buttarmi sul solito top di gamma con snapdragon 801 oppure un bell'octa core. Questi octa core non mi sembrano male e penso consumino di meno visto che il secondo quadcore si attiva in base alle necessità del sistema.
Inviato dal mio HUAWEI P6-U06 usando Androidiani App -
05-10-14, 18:26Ma5t3rI processori a 64 bit funzionano con istruzioni, appunto, lunghe 64 bit invece di 32.Quote:
Originariamente inviato da xjasonxl10l
Questo significa che nella singola istruzione, più lunga, puoi mettere più parametri (esempio stupido: se un'istruzione ADD prende tre operandi, destinazione e due addendi, a 64 bit hai lo spazio per metterci più operandi e sommare più valori) o che puoi utilizzare parametri più lunghi (ad esempio, puoi indirizzare molta più memoria).
Questo NON significa che il processore vada il doppio più veloce di uno a 32 bit, ma significa che chi progetta un processore può prevedere delle istruzioni che, ad esempio prevedendo più operandi, risultino più efficienti in alcuni contesti rispetto a quelle a 32 bit.
In pratica, già su PC, con processori CISC (processori con set di istruzioni Complesse, in una sola istruzione fai "tanto"), è difficile usare programmi che sfruttino le istruzioni più lunghe per aumentare l'efficienza; si tratta di programmi che fanno elaborazioni pesanti (Photoshop, Autocad) o che usano le istruzioni più lunghe per svolgere meglio le istruzioni legate alla sicurezza (Chrome).
Su smartphone i processori appartengono alla famiglia RISC (processori con set di istruzioni Ridotte, "semplici") e sono pensati per elaborare un gran numero di istruzioni semplici in maniera veloce, quindi, secondo me:
-) lo scenario di utilizzo tipico, ovvero applicazioni "leggere" pare benificiare poco di un set di istruzioni a 64 bit;
-) dato che i processori RISC lavorano con istruzioni semplici, una singola istruzione a 64 bit è comunque un'istruzione "semplice", e se è semplice quanto mai potrà beneficiare del poter essere più lunga (e.g. avere più argomenti in ingresso)?
Inoltre lavorare con istruzioni lunghe non porta solo potenziali benefici: dimezzi il numero di istruzioni che ci stanno nella I-cache, raddoppi i tempi di lettura delle istruzioni dalla memoria e via dicendo.
Se utilizzi il set di istruzioni a 64 bit per operazioni semplici, oltre a non ottenere vantaggi, ti ritrovi con un programma che gira più lentamente che su una CPU equivalente a 32 bit.
Non è un caso che le CPU ARM a 32 bit offrano anche la modalità Thumb per lavorare a 16 bit: a volte è semplicemente meglio :p.
Per la cronaca, mi pare che ARMv7 supporti PAE, per cui la memoria indirizzabile a 32 bit è in totale di 64GB (anche se la singola applicazione non può vedere più di 3.3GB, se non ricordo male), quindi il passaggio a 64bit per poter avere più RAM è un po' una fuffa.
Al contrario, il passaggio da ARMv7 a ARMv8 porta a un'architettura che sembra funzionare notevolmente meglio della precedente, anche a 32 bit. -
06-10-14, 00:42xjasonxl10l
E degli octa-core cosa ne pensi? Comunque risposta perfetta, mi hai schiarito le idee :)
Inviato dal mio HUAWEI P6-U06 usando Androidiani App -
06-10-14, 17:28Ma5t3rScusa ma in questi giorni sono un po' occupato, le risposte arriveranno in ritardo e/o a singhiozzo ;).Quote:
Originariamente inviato da xjasonxl10l
Aumentare il numero dei core non porta a svantaggi significativi, ma i benefici sono limitati da alcuni fattori importanti.
Per poterli capire facciamo una precisazione: non si programma a core, ma a thread.
Un thread è un filo del codice distaccato il più possibile, meglio se completamente indipendente da altri thread.
Lo scheduler del sistema operativo decide, in base a diversi fattori (accendere i core costa energia!), se far girare più thread su un solo core o accenderne altri e dividere il lavoro.
Quindi, tornando ai fattori che limitano i benefici di più core:
-) scrivere codice che giri parallelamente su molti thread non è sempre fattibile (ogni thread dovrebbe operare su dati indipendenti) e, quando lo è, di solito è molto più complicato che scrivere lo stesso codice nella versione a un solo thread;
-) il codice che gira su molti thread ottiene miglioramenti sensibili solo su insiemi di dati "grandi": se devo ordinare 100 numeri, creare 4 thread avrebbe un costo superiore all'ordinamento in sé;
-) le operazioni compiute da uno smartphone sono tendenzialmente semplici e operano su pochi dati;
-) anche avendo N thread, con N core disponibili, e un numero elevato di dati da trattare, il guadagno di tempo non è di N volte: oltre a creare i thread, può essere necessario usare barriere per gestire l'ordine con cui i thread trattano i dati, con costi assolutamente non trascurabili;
-) sviluppare codice parallelo diviso in tanti thread costa tanto tempo, e per molte app la spesa non vale semplicemente la candela (più tempo speso per benefici trascurabili non è mai una bella cosa!).
Orientativamente, è molto facile usare due thread quando si programma (uno per l'interfaccia grafica e uno che svolge operazioni); anche tre o quattro thread qualcosa da fargli fare lo si trova, ma si tratta di solito di cose che non avvengono in contemporanea, o che comunque non richiedono il 100% di un core, quindi il sistema probabilmente preferisce far andare tutto su solo uno o due core, invece di accenderne altri.
La parallelizzazione del codice "vera", quella in cui progetti e utilizzi algoritmi dividendo il lavoro equamente in più thread, che porterebbe a usare tutti e gli 8 core, ha poco senso in ambito mobile.
Naturalmente poi ci sono applicazioni particolari, come applicazione di filtri a foto o giochi, in cui 8 core potrebbero essere sfruttati molto bene, ma nell'uso del terminale per navigazione internet e app normali, secondo me, gran parte degli 8 core rimarrebbero sempre spenti :p.
Sarebbe interessante fare o trovare delle statistiche sul numero di cpu accese, durante il tempo di utilizzo (display on), di un quad core e/o di un 4+4 core per fare delle congetture migliori su quanto aumentare i core, in contesto mobile, porti a benefici.
