I 64bit negli smartphone non sono poi inutili: retromarcia di Qualcomm

[gd350turbo]

Originariamente inviato da dwfgerw

Si certo perchè pensi che a Cook e company interessi qualcosa di quello che dichiara il CEO di Qualcomm ? Mah..

Non so, può essere...

Ma sicuramente gli interessa di più che quello che interessa a me di avere un telefono a 64 bit per la convoluzione dei flussi audio !

[san80d]

certo che il reparto "comunicazione" delle varie società negli ultimi tempi ne sta facendo di mere figure

[san80d]

Originariamente inviato da El Korki

il senso della dichiarazione di chandrasekher secondo me è che sicuramente gli smartphone evolveranno nei prossimi mesi/anni, quindi è ora di cominciare a lavorare su soc a 64bit...

e' quello che si e' sempre pensato dei 64bit

[sbaffo]

il senso della correzione è: l'anno prossimo usciremo anche noi (Qualcomm) con un chip a 64bit, se ora diciamo che è una cagata l'anno prossimo cosa diciamo? meglio smentirsi ora che fare una magra figura al lancio.

Per quanto riguarda la reale utilità, non teorica, dei 64bit sugli smartphone, non sono un esperto di software ma visto che sui desktop dopo 10 anni dall'introduzione sono ancora confinati ad applicazioni di nicchia (che non si usano sui cell), e solo i prossimi giochi porteranno i 64bit alle masse, dubito che le applicazioni per smartphone li useranno presto. Discorso forse diverso per Apple che aggiorna ancora i vecchi iphone e dovrà aggiornare per anni il 5 quindi si prepara al futuro anche piuttosto lontano.
Detto questo certamente c'è un po' di marketing, ma qualcuno doveva pur iniziare, altrimenti se anche AMD non avesse iniziato 10 anni fa ora non li avremmo neanche sui desktop.

[Aegon]

Originariamente inviato da gilles17871

Vero, ma lo stesso eseguibile "scritto" a 32 bit occupa meno spazio in ram, quindi se da un lato hai vantaggi nell'eseguire applicazioni a 64 bit dall'altro hai uno svantaggio saturando prima la ram se non sufficentemente capiente e costringendo il sistema allo swap.

In realtà l'incremento dell'utilizzo della memoria è relativo. Con registri a 32bit tutte le operazioni che necessitano di maggior spazio (che siano word lenghts o lunghi cicli iterativi) in essi finiscono in cache o in memoria; se, invece, hai operazioni direttamente computabili perché i registri lo permettono queste vengono eseguite immediatamente e l'utilizzo di memoria è ridotto, oltre al tempo di esecuzione. Guadagni due volte.

Il guadagno è marginale, ma c'è. Oltretutto in una CPU ARMv8 la codifica/decodifica AES e l'hashing SHA-1 / SHA-256 godono di accelerazione hw.

I media e gli ignoranti pensano solo alla Apple di turno ma ARM punta a diversi settori... di sicuro, con quello che costa, non sviluppa un'architettura per ognuno di essi! Loro pensano al futuro, non a quello che dicono Apple, Qualcomm o Samsung...

[JackZR]

Non mi pare che sia stato smentito e al momento attuale son d'accordo con lui, si è solo detto che si sta andando in quella direzione e che più avanti ci si saranno reali benefici.

[II ARROWS]

Originariamente inviato da sbaffo

il senso della correzione è: l'anno prossimo usciremo anche noi (Qualcomm) con un chip a 64bit, se ora diciamo che è una cagata l'anno prossimo cosa diciamo? meglio smentirsi ora che fare una magra figura al lancio.

Ma guarda che la stessa cosa la aveva detta nell'intervista originale!
Aveva detto che stavano lavorando ai prossimi prodotti, ma anche che il comportamento di Apple era completamente di marketing perché allo stato attuale non ci sono reali differenze per l'utente.

[Marino5]

http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html

[Duncan]

Originariamente inviato da II ARROWS

Ma guarda che la stessa cosa la aveva detta nell'intervista originale!
Aveva detto che stavano lavorando ai prossimi prodotti, ma anche che il comportamento di Apple era completamente di marketing perché allo stato attuale non ci sono reali differenze per l'utente.

PArtiamo dal presupposto che Apple voleva aumentare le prestazioni del nuovo iPhone.

Le strade erano due, aumentare core e frequenze, con consistente aumento dei consumi; oppure cambiare architettura con una più efficente; mi pare chiara la strada scelta, non è che potesse fare molto altro in un dispositivo così compatto senza andare ad impattare in modo significativo sui consumi.

Utile o non utile ad Apple al momento passare ad ARMv8 è servito a questo, vedremo il prossimo anno cosa riusciranno a fare per avere un significativo boost prestazionale.

Originariamente inviato da Marino5

http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html

Proprio l'articolo che ho letto che spega molto bene tutto il lavoro fatto da Apple per ottimizzare iOS7 a 64 bit.

[CrapaDiLegno]

Ma un pò di studio no?

L'architettura a 64 bit non è solo indirizzare più RAM, ma è una nuova microarchitettura con più registri e varie altre ottimizzazioni, quindi è o può essere utile anche a chi non usa più di 4GB di ram. Ma invece di sparare sentenze basate sul nulla studiare no?

Allora meglio parlare di cache più grandi e numero di registri superiore che di ALU a 64 bit, no?
Che la nuova a rchitettura ARM sia decisamente migliore della precedente nessuno lo mette in dubbio, ma che queste migliorie siano dovute al fatto che ora si dispone di ALU a 64 bit non è vero.

Se vogliamo semplificare mettendo sotto il cappello 64bit tutte le modifiche apportate e fare i professori di Novella 2000 dicendo inesattezze giusto per fare marketing, si può anche fare.
Ma se pensi che mantenendo l'architettura a 32bit e portando solo le ALU a 64bit il miglioramento sarebbe stato uguale allora chi deve studiare un po' di più sei tu.

In un applicativo normale i calcoli a 64 bit sono ridotti all'osso e una CPU a 32 bit riesce ad eseguirli senza particolari problemi. In teoria costruire una CPU a 64 bit per il semplice scopo di migliorare questo tipo di calcoli nel mondo consumer è inutile. Meglio sarebbe usare quei transistor per migliorare il contorno (o raddoppiare le ALU a 32bit). Quello che invece non si può assolutamente fare senza perdere parecchio in efficienza, è andare oltre all'indirizzamento a 32bit, ed è solo per questo che i 64 bit sono diventati importanti
Guardate quanti anni sono trascorsi dall'introduzione di una CPU a 64 bit e l'adozione di massa di un OS a 64 bit (XP64 e Vista quindi esclusi). Guarda caso il boom è avvenuto proprio quando i limiti dei 4GB sono cominciati a diventare stretti anche per il PC di casa (cosa che trovo assurda, ma tant'è, questo è il mondo che abbiamo creato).

A parte chi fa processing di dati a manetta tutti i giorni, per gli altri l'uso di calcoli a 32 o 64 bit non cambia nulla. Tanto più che ancora oggi ci sono milioni di computer che vanno a felicemente a 32bit e non si capisce quale sia il motivo per cui un dispositivo mobile (e sottolineo mobile) debba avere più necessità di processing di questi.

[FedNat]

Originariamente inviato da Marino5

http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html

Dal tuo link

Conclusion
The "64-bit" A7 is not just a marketing gimmic, but neither is it an amazing breakthrough that enables a new class of applications. The truth, as happens often, lies in between.

The simple fact of moving to 64-bit does little. It makes for slightly faster computations in some cases, somewhat higher memory usage for most programs, and makes certain programming techniques more viable. Overall, it's not hugely significant.

The ARM architecture changed a bunch of other things in its transition to 64-bit. An increased number of registers and a revised, streamlined instruction set make for a nice performance gain over 32-bit ARM.

Che conferma quello che si stà dicendo da tempo su questi thread:

• I 64 bit di per se al momento servono a poco
• Le migliorie architetturali introdotte da ARM con il set di istruzioni ARMv8 portano alcuni miglioramenti prestazionali

Confermando quindi quanto detto da Chandrasekher

Edit: che poi è quanto detto anche da CrapaDiLegno un post sopra

[CrapaDiLegno]

Utile o non utile ad Apple al momento passare ad ARMv8 è servito a questo, vedremo il prossimo anno cosa riusciranno a fare per avere un significativo boost prestazionale.

Die shrink, innalzamento frequenze, come tutti.
Non è tanto difficile.

E' che loro possono permettersi die enormi visto che vendono direttamente e a prezzo spropositato, mentre tutta la concorrenza deve stare attenta alle dimensioni del die e deve aspettare ad introdurre le nuove architetture o poterci mettere mezzo chilometro quadro di GPU.
Non è che Apple usi tecnologia aliena e gli altri sono all'età della pietra. Lei semplicemente usa prima e in quantità maggiore la tecnologia che agli altri tocca usare dopo per semplici questioni di marketing.

[Duncan]

Originariamente inviato da FedNat

Dal tuo link



Che conferma quello che si stà dicendo da tempo su questi thread:

• I 64 bit di per se al momento servono a poco
• Le migliorie architetturali introdotte da ARM con il set di istruzioni ARMv8 portano alcuni miglioramenti prestazionali

Confermando quindi quanto detto da Chandrasekher

Edit: che poi è quanto detto anche da CrapaDiLegno un post sopra

Però riporta anche quello che c'è scritto dopo:

Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.

ARM64 is a welcome addition to Apple's hardware. We all knew it would happen eventually, but few expected it this soon. It's here now, and it's great.


Cioè che Apple ha ottimizzato molto il runtime per ottimizzare alcune operazioni...

Originariamente inviato da CrapaDiLegno

Die shrink, innalzamento frequenze, come tutti.
Non è tanto difficile.

Si, ma lo farà il prossimo anno, al momento non mi pare che ci siano processori costruiti ad esempio a 16 nm come dovrebbero esser prodotti i cortex A57 di ARM e se si vedono i SOC concorrenti attuali di A7 (snapdragon ed exynos) son tutti costruiti a 28 nm...

[FedNat]

Originariamente inviato da Duncan

Però riporta anche quello che c'è scritto dopo:

Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.

ARM64 is a welcome addition to Apple's hardware. We all knew it would happen eventually, but few expected it this soon. It's here now, and it's great.

Non lo ho volutamente riportato perché non inerente all'argomento in discussione.

Quì si sta discutendo dei vantaggi dovuti al passaggio ai 64 bit, quel pezzo parla di ottimizzazioni software relative a peculiarità di Objective-C.
Tali ottimizzazioni non dipendono minimamente dai 64 bit, al massimo dai miglioramenti architetturali. Questo è quello che stiamo dicendo da tempo e che sembrate non voler capire.

[Duncan]

Quelle ottimizzazioni software son state possibili proprio grazie al passaggio ai 64 bit... forse non hai letto tutto l'articolo... il reference counting ad esempio è adesso memorizzato nel puntatore a 64 bit invece che in una struttura dati esterna, come altri flag

[floc]

hanno semplicemente detto quello che era emerso nelle nostre 470 pagine di discussione: sono inutili adesso su smartphone, sara' la via del futuro per desktop/server.

[II ARROWS]

No Duncan, non hai capito... non è quello che ha permesso queste cose. Quei flag semplicemente sono stati inglobati nel puntatore (brrr, spero abbiano lasciato più di 34 bit a disposizione) ma non è che così facendo abbiano guadagnato spazio... quello spazio lo usavano comunque prima.

Adesso per leggerli invece di fare un accesso alla cella dovranno fare una serie di spostamenti di bit...

[FedNat]

Originariamente inviato da Duncan

Quelle ottimizzazioni software son state possibili proprio grazie al passaggio ai 64 bit... forse non hai letto tutto l'articolo... il reference counting ad esempio è adesso memorizzato nel puntatore a 64 bit invece che in una struttura dati esterna, come altri flag

Come detto da II ARROWS hanno semplicemente inserito un nuovo campo di bit all'interno del puntatore. Questo campo poteva essere inserito accanto al puntatore a 32 bit, sarebbe stato un pelo meno efficente e, probabilmente avrebbe creato più problemi di retrocompatibilità, ma redo che sarebbe stato fattibile.

In ogni caso il trucco è reso possibile dal fatto che i 64 bit sono "inutili" in quanto non c'è necessità di indirizzare 16 exabyte di memoria e quindi è possibile riciclare dei bit

[Duncan]

Come no? Prima usavano una hashtable per tenere il reference counting, un oggetto in più in memoria che richiede per ogni nuovo oggetto allocato un hash ed un valore che come minimo occupano atri 32 bit per oggetto allocato, quindi nel peggiore dei casi hanno recuperato lo spazio perso con il apssaggio aai 64 bit, inoltre ora fanno solo masking dei valori direttamente sui registri senza dover fare accessi ad oggetti esterni, in ram ad esempio,per aggiornare queste strutture dati, e sono cicli di clock, uno shift è una operazione che costa pochissimo ad una CPU.

E comunque si per ora hanno limitato lo spazio di indirizzamento a 34 bit.

[II ARROWS]

Duncan... sei un programmatore? Hai mai programmato qualcosa?
Giusto per capire come mi devo rivolgere a te...