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

[Duncan]

Si programmatore...

[FedNat]

Originariamente inviato da 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.

Ma tutto questo dipende unicamente da come Apple ha deciso di implementare il runtime di Objective-C.

Prima utilizzavano una hashtable, adesso hanno inserito il counter all'interno dell'oggetto. Cosa c'entra il passaggio ai 64 bit?? Potevano farlo anche sui sistemi a 32 bit, probabilmente avrebbero avuto problemi di retrocompatibilità.

In questo caso hanno deciso di sfruttare dei bit inutilizzati del puntatore per inserire il campo e mantenere la retrocompatibilità, ma è semplicemente un trucco implementativo. I 64 bit hanno reso possibile il trucco, non l'implementazione in se.

P.S. io non sono un esperto sw, ma personalmente avrei scelto di includere il reference count nell'oggetto fin dall'inizio evitando le hashtable.

[Duncan]

Non potevano farlo con i 32 bit semplicemente perchè il puntatore non era abbastanza grande rispetto alla memoria correntemente in uso, visto che iPhone 5 e 5s hanno 1GB di ram, quindi 30 bit, avanzavano 2bit per un massimo di 4 per il reference counting, decisamente troppo poco.

Al massimo dall'inizio sia per 32 e 64 bit potevano avere una variabile gestita dal runtime nascota all'interno di ogni oggetto per mantenere il reference counting, ma credo che ai tempi del 32 bit sia stata preferita l'hashtable per problemi di performarce.

[FedNat]

Originariamente inviato da Duncan

Non potevano farlo con i 32 bit semplicemente perchè il puntatore non era abbastanza grande rispetto alla memoria correntemente in uso, visto che iPhone 5 e 5s hanno 1GB di ram, quindi 30 bit, avanzavano 2bit per un massimo di 4 per il reference counting, decisamente troppo poco.

Al massimo dall'inizio sia per 32 e 64 bit potevano avere una variabile gestita dal runtime nascota all'interno di ogni oggetto per mantenere il reference counting, ma credo che ai tempi del 32 bit sia stata preferita l'hashtable per problemi di performarce.

Ovviamente non consideravo la possibilità di inserire il campo all'interno del puntatore a 32 bit, non c'è abbastanza spazio come giustamente fai notare.
Io stavo pensando alla seconda soluzione da te prospettata: aggiungere un campo nuovo (16 bit? 32bit? a scelta) all'interno dell'oggetto e questo è fattibile sempre, sia con processori a 32 bit che con processori a 64 bit.

Tra parentesi la suddetta soluzione è decisamente più pulita e future proof rispetto a quanto fatto da Apple (prima o poi i bit adesso inutilizzati del puntatore serviranno). Di contro la soluzione di Apple semplifica la retrocompatibilità.

Comunque tornando all'argomento della news: le migliori performance non dipendono dall'avere un processore a 64 bit

[Duncan]

Verò è più future proof, ma il runtime è completamente sotto controllo di Apple e se decide di aumentare a più di 34 bit lo spazio di indirizzamento del puntatore a 64 bit lo può fare senza problemi, avranno problemi solo chi ha scritto codice di bassissimo livello che fa assunzioni su come sono fatti realmente i puntatori e come sono gestiti dal runtime, cosa che si fa assai raramente ed è deprecata dai più.

Avere invece il contatore e flag dentro l'oggetto è comodo ed elegante, ma poco efficente, è molto più veloce avere un hashtable con questi valori visto che è una struttura dati a cui si accede probabilmente assi spesso e quindi probabilmente avendola centralizzata è più facile ottimizzarla anche per le cache del processore rispetto ad averla distribuita in ogni oggetto.

[II ARROWS]

"Verò"...

Duncan, in parte ha già scritto FedNat.
La scelta di un'hashtable è stata una scelta loro, sbagliata e tutto quanto, alla fine. Non costa tanto accedere alla memoria del puntatore, dedicando ai primi 4 B delle struttura ai flag e tutto il resto. Oppure gestire i puntatori come una struttura da 4+4 B, esattamente come è adesso: i primi 32 bit dedicati all'indirizzo e il resto ai vari flag. In questo modo è anche più flessibile perché puoi anche aumentare quanto ti pare la struttura dei dati, usando 5, 6, 10 B!

Il tutto è solo un errore di apple precedentemente, non una genialata quello che hanno fatto loro.
Fra 6 anni ci saranno 16 GiB di RAM... i 34 bit non basteranno più. Devono rimettere mano alla struttura dei "superpuntatori" perché devono fare spazio al reindirizzamento.

[Duncan]

Concordò , devono mettere mano al runtime per aumentare lo spazio indirizzabile dal puntatore e vedere come gestire il reference counting, ma son tutte problematiche che dovranno risolvere loro in un ecosostema chiuso su cui hanno completo controllo ed è in gran parte totalmente trasparente al programma, a meno che non si usate pratiche poco belle sui puntatori.

Dove vedi l'errore non lo capisco, è una scelta di implementazione come altre...

[CrapaDiLegno]

Non potevano farlo con i 32 bit semplicemente perchè il puntatore non era abbastanza grande rispetto alla memoria correntemente in uso, visto che iPhone 5 e 5s hanno 1GB di ram, quindi 30 bit, avanzavano 2bit per un massimo di 4 per il reference counting, decisamente troppo poco.

Le strutture, queste cose misteriose....
Costa uguale uguale a fare una struttura in cui hai 32bit di puntatore e 32 bit come reference counter + tutto quello che ti serve. In un sistema 32bit ci accedi in 2 "colpi", a 64 bit in uno solo.
Se tieni conto che il memory controller non accede ad un sola word alla volta ma a linee per riempire una linea di cache, il tempo per accedere a questa struttura 32+32bit costa un accesso in più alla cache di primo livello, quindi pochissimo.
Se poi loro per qualche "brillante" ragione hanno scelto di mettere tutto in una hash table che richiede continuamente accessi a tabelle grandi che non ci stanno in una singola linea cache con tutti i nessi e connessi della cosa, allora il problema è a monte, non è che la nuova architettura è più efficiente in sè perché insieme ai 34 bit del puntatore Apple h a deciso di mandarti anche una serie di flag incorporate.

Cerchiamo di non fare falsa propaganda cadendo scioccamente nel tranello di quel che viene detto dal reparto di marketing.
La computazione a 64bit in un sistema mobile non serve. Serve già poco su un PC normale. Vorrei sapere a casa tua quando mai fai calcoli usando valori più grandi di 4 miliardi. Se invece parliamo di superare la barriera dei 4GB allora il discorso cambia. Ma per ora gli unici interessati a questo limite è Samsung che già oggi propone telefoni con 3GB di memoria a bordo.
E l'indirizzamento oltre i 32bit è comunuqe possibile tramite altre tecniche (meno efficienti, certo) oltre che all'ampliamento della dimensione delle istruzioni.
Tutti i vantaggi prestazionali dell'A7 derivano principalmente per la nuova architettura costruita intorno alle ALU, che fossero anche a 32bit, godrebbero degli stessi vantaggi.

[Duncan]

In generale concordo che l'aumento delle prestazioni è dovuto dalla nuova architettura.

Il problema è che l'architettura ed il licencing della stessa è controllato da ARM, non credo che Apple possa modificare completamente tutto, nel senso può farsi una ALUcustom compatibile con ARMv7 ed ARMv8 senza usare i core ARM, ma non credo che possa estendere e modificare l'instruction set come gli pare, poi visto che c'è già un architettura che risolve i problemi che ho, è più comodo usare quella che estendere la vecchia. Anche per l'indirizzamente stesso discorso, perchè complicarsi la vita come ha fatto Intel con PAE se non ne ho bisogno, ho già un architettura migliore compatibile con la vecchia, che mi risolve in un colpo i problemi di prestazioni, consumi e già pronta per futuri sviluppi.

Poi ti vorrei far notare che 2 accessi rispetto ad 1 è il doppio, non poco più e quando c'è da macinare dati fa abbastanza differenza, anche se si parla di accessi alla cache.

P.S.: e 9000 in soli... 14 anni... quasi

[II ARROWS]

Non devi accedere per forza come 2 accessi... puoi leggere un'area di memoria 4+4 come una singola da 8.
4 per accedere al puntatore, 4 per accedere ai dati. Ovviamente può essere che quando vuoi accedere ai dati non ti serva accedere al puntatore, quindi il problema non si pone.

In ogni caso accedere ai dati del puntatore vuol dire comunque fare dei calcoli bit-bit, sia usando maschere a 64 bit che spostamenti di bit.

[FedNat]

Originariamente inviato da Duncan

In generale concordo che l'aumento delle prestazioni è dovuto dalla nuova architettura.

Il problema è che l'architettura ed il licencing della stessa è controllato da ARM, non credo che Apple possa modificare completamente tutto, nel senso può farsi una ALUcustom compatibile con ARMv7 ed ARMv8 senza usare i core ARM, ma non credo che possa estendere e modificare l'instruction set come gli pare, poi visto che c'è già un architettura che risolve i problemi che ho, è più comodo usare quella che estendere la vecchia.

Per quanto mi riguarda questo è il punto a cui volevo arrivare: "Non sono tanto i 64 bit a migliorare le prestazioni quanto i miglioramenti architetturali"
Che è poi quanto affermava Qualcomm.

Comunque a memoria credo che Apple abbia una licenza full sull'ISA ARM e quindi possa customizzarsi il processore come vuole. Non credo le sarebbe comunque convenuto portare la nuova architettura mantenendo i 32 bit, anche io concordo che il passaggio ai 64 sia inevitabile. Quello che contesto è il marketing eccessivo

[CrapaDiLegno]

La località dei dati in questo caso aiuta a rendere i tempi di latenza minimi.
La cache è nata per quello. L'accesso alla cache di livello 1 richiede pochi cicli di clock (1 se l'indirizzo è continuo rispetto al precedente), che rispetto alle decine (o centinaia) richiesti per l'accesso a un dato quando non è in memoria sono una inezia.
Sembra che prima dell'avvento dei 64 bit i processori a 32bit non potessero essere sfruttati al 100% perché incapaci di accedere velocemente ai dati nella cache.

Non è il fetch dei dati a 64bit in particolari casi il merito delle migliori performance. Se così fosse oggi avremmo CPU con ALU a 128bit e i 64bit sarebbero già in uso da 20 anni... opss, aspetta, ma i 64 bit esistono da 20 anni e nessuno se ne è mai accorto prima che si arrivasse alla barriera dei 4GB!

[Duncan]

Originariamente inviato da II ARROWS

Non devi accedere per forza come 2 accessi... puoi leggere un'area di memoria 4+4 come una singola da 8.
4 per accedere al puntatore, 4 per accedere ai dati. Ovviamente può essere che quando vuoi accedere ai dati non ti serva accedere al puntatore, quindi il problema non si pone.

In ogni caso accedere ai dati del puntatore vuol dire comunque fare dei calcoli bit-bit, sia usando maschere a 64 bit che spostamenti di bit.

più o meno i soliti che dovresti fare anche se usi un intero a 32 Bit per memorizzare reference counting ed altri flag come nel caso in oggetto

Originariamente inviato da FedNat

Per quanto mi riguarda questo è il punto a cui volevo arrivare: "Non sono tanto i 64 bit a migliorare le prestazioni quanto i miglioramenti architetturali"
Che è poi quanto affermava Qualcomm.

Comunque a memoria credo che Apple abbia una licenza full sull'ISA ARM e quindi possa customizzarsi il processore come vuole. Non credo le sarebbe comunque convenuto portare la nuova architettura mantenendo i 32 bit, anche io concordo che il passaggio ai 64 sia inevitabile. Quello che contesto è il marketing eccessivo

Si, dovrebbe essere quello che era P.A. Semi prima dell'acquisizione da parte di Apple a procettare i chip.

Originariamente inviato da CrapaDiLegno

La località dei dati in questo caso aiuta a rendere i tempi di latenza minimi.
La cache è nata per quello. L'accesso alla cache di livello 1 richiede pochi cicli di clock (1 se l'indirizzo è continuo rispetto al precedente), che rispetto alle decine (o centinaia) richiesti per l'accesso a un dato quando non è in memoria sono una inezia.
Sembra che prima dell'avvento dei 64 bit i processori a 32bit non potessero essere sfruttati al 100% perché incapaci di accedere velocemente ai dati nella cache.

Non è il fetch dei dati a 64bit in particolari casi il merito delle migliori performance. Se così fosse oggi avremmo CPU con ALU a 128bit e i 64bit sarebbero già in uso da 20 anni... opss, aspetta, ma i 64 bit esistono da 20 anni e nessuno se ne è mai accorto prima che si arrivasse alla barriera dei 4GB!

Non ho mai che prima i 32 bit non potevano essere sfruttati, ho scritto che con i 64 bit Apple ha potuto fare delle ottimizzazioni importanti anche per la maggior lunghezza della parola.

Che poi il mondo windows ci ha messo una vita nel passaggio è un'altro discorso.

Poi nel mondo consumer son arrivati nel 2003...

[Boscagoo]

Hanno detto una stronzata e hanno stronzato la stronzata. Wow!