Link alla notizia: http://www.hwupgrade.it/news/telefonia/i-64bit-negli-smartphone-non-sono-poi-inutili-retromarcia-di-qualcomm_49087.html

Le parole di Anand Chandrasekher, CMO di Qualcomm, avevano sminuito l'importanza del supporto ai 64-bit del chip A7 di Apple. L'azienda americana rivede la propria posizione smentendo quanto affermato dal proprio executive

Click sul link per visualizzare la notizia.

mi piacerebbere leggere i commenti di chi commentava l'altra notizia dicendo che i processori a 64 bit su smartphone con meno di 4 gb erano inutili :-)

Alcuni sviluppatori hanno effettivamente già dimostrato di aver ottenuto vantaggi dal passaggio ai 64 bit, in particolare con alcune app per l’audio. Il CEO di Smule, ha affermato ad esempio che ora è possibile supportare la convoluzione audio in tempo reale, funzionalità non attuabile sui precedenti processori di classe mobile. Test sull’A7 di Apple hanno dimostrato la possibilità di attivare modifiche come i riverberi in tempo reale, operazione non possibile sull’iPhone 5 o altri smartphone della stessa generazione.

Apple si è mossa per prima "semplicemente" perchè cura hw e sw, quindi questi salti è in grado di compierli prima di altri.

Sminuire un investimento ed uno sforzo tale riducendo solo al marketing mi sembra quanto meno riduttivo.

i 64bit sono quasi del tutto inutili su sistemi con meno di 4gb di ram, e questo è un dato, non un'opinione.

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...

Infatti i 64 bit nel mondo "consumer" non hanno apportato nulla se non il superamento della barriera dei 4GB di RAM. Non c'è nulla che un utente a casa possa fare con i 64 bit quello che non puòfare con i 32bit se si accontenta di usare meno di 4GB.
Per il consumo di così tanta memoria, va da sè, che lo sviluppo SW ha le sue responsabilità.

Il nocciolo della questione è questo:
oltre che permettere ai processori mobile e al software abbinato di poter essere utilizzati in nuove tipologie di dispositivi di elaborazione.
I 64 bit daranno ai core ARM la possibilità di entrare nel mondo server. Già i primi "esperimenti" con quelli a 32 bit danno interessanti risultati (ci sono test di server fatti con i chip Calxeda vs Xeon).
Il mercato quindi c'è. Ci si sta tutti mettendo sul nastro di partenza, e ovviamente chi prima arriva meglio accomoda. Ecco perché Qualcomm sicuramente farà SoC (e magari anche non SoC) con core ARM a 64-bit come tutti gli altri interessati alla partita.

Che si voglia a tutti i costi affermare che i 64bit su un sistema mobile (e sottolineo mobile) che usa 1GB di RAM siano utili è possibile, allo stesso modo di giustificare che per andare a fare la spesa al supermercato il SUV è indispensabile.
Ognuno è libero di sparare le migliori motiviazioni che riesce a reperire nel proprio bagaglio cultrtale per farlo. Non si meravigli delle reazioni però...

la questione dei 4 gb è relativa, secondo me sono più importanti le app a 64 bit
indipendentemente dalla quantità di ram.
es. la versione 64bit di cinebench, su s.o. a 64 bit, ha migliori prestazioni, rispetto
alla versione da 32, indipendentemente dalla quantità di ram installata. :)Cinebench è un caso particolare, fa parte di quella ristretta cerchia di applicazioni che muove una grande quantità di dati e quindi ottiene grandi vantaggi... ma non sono applicazioni che si usano sui cellulari.

Alcuni sviluppatori hanno effettivamente già dimostrato di aver ottenuto vantaggi dal passaggio ai 64 bit, in particolare con alcune app per l’audio. Il CEO di Smule, ha affermato ad esempio che ora è possibile supportare la convoluzione audio in tempo reale, funzionalità non attuabile sui precedenti processori di classe mobile. Test sull’A7 di Apple hanno dimostrato la possibilità di attivare modifiche come i riverberi in tempo reale, operazione non possibile sull’iPhone 5 o altri smartphone della stessa generazione.Neutron, lettore per Android e BlackBerry QNX supporta i calcoli a 64 bit... Anche se il processore è a 32 bit non significa che non sia possibile eseguire calcoli a 64bit, semplicemente sarà meno efficiente ma la capacità dei telefoni da qualche generazione è sufficiente per farlo senza particolari problemi.

Tralaltro è un programma che consiglio caldamente.

mi piacerebbere leggere i commenti di chi commentava l'altra notizia dicendo che i processori a 64 bit su smartphone con meno di 4 gb erano inutili :-)

non è che ora che qualcomm ha riveduto la sua posizione con un comunicato ufficiale, i 64-bit sono diventati utili..tra l'altro, secondo te sta più verità nel commento schietto di un "tecnico", o nel comunicato ufficiale scritto dal reparto di comunicazione e marketing?

qualcomm ovviamente e giustamente starà sviluppando SoC a 64-bit e in un certo senso anche lei lo vorrà presentare come un beneficio e le affermazioni di Chandrasekher sono dannose per il loro marketing.

riguardo alla questione audio, che io sappia non esistono app come iRig per android, perché l'architettura stessa di android (credo quindi nell'essere interpretato e non compilato, ma parlo grossolanamente) non permette un processing in tempo reale dell'audio.

in ogni caso, anche se fosse vera la questione del riverbero, vi sembra una funzionalità di largo utilizzo? è ovvio che i 64-bit hanno qualche vantaggio oltre al maggior indirizzamento, ma tanto in ambito desktop e a maggior ragione in ambito mobile, questi vantaggi sono per utenze specifiche.

"So che se ne parla tanto, perché Apple ha portato le istruzioni a 64-bit sul loro A7, ma penso che sia tutta una trovata di marketing. Il beneficio che il consumatore ottiene da questa feature è pari a zero."

Parole forti quelle di Chandrasekher, in un certo senso curiose in quanto denigratorie per il marketing di Apple e provenienti proprio dal Chief Marketing Officer di Qualcomm. L'azienda di San Diego non è rimasta indifferente alle reazioni che questa uscita ha suscitato: la posizione di Chandrasekher su A7 e il codice a 64-bit è stata radicalmente rivista attraverso il seguente comunicato rilasciato nella serata di ieri:

I commenti di Anand Chandrasekher, Qualcomm CMO, sui 64bit erano inaccurati. L'ecosistema hardware e quello software si stanno già muovendo nella direzione dei 64-bit; l'evoluzione verso i 64-bit sta portando capacità di elaborazione tipiche del mondo desktop e modalità d'uso all'interno dei dispositivi mobile, oltre che permettere ai processori mobile e al software abbinato di poter essere utilizzati in nuove tipologie di dispositivi di elaborazione.

Che sia stato quel tir con il marchio della mela parcheggiato davanti alla qualcomm a farli cambiare idea ? :D :D :D

Che sia stato quel tir con il marchio della mela parcheggiato davanti alla qualcomm a farli cambiare idea ? :D :D :D

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

Alcuni sviluppatori hanno effettivamente già dimostrato di aver ottenuto vantaggi dal passaggio ai 64 bit, in particolare con alcune app per l’audio. Il CEO di Smule, ha affermato ad esempio che ora è possibile supportare la convoluzione audio in tempo reale, funzionalità non attuabile sui precedenti processori di classe mobile. Test sull’A7 di Apple hanno dimostrato la possibilità di attivare modifiche come i riverberi in tempo reale, operazione non possibile sull’iPhone 5 o altri smartphone della stessa generazione.

Apple si è mossa per prima "semplicemente" perchè cura hw e sw, quindi questi salti è in grado di compierli prima di altri.

Sminuire un investimento ed uno sforzo tale riducendo solo al marketing mi sembra quanto meno riduttivo.
La parte in grassetto detta così significa tutto e niente:
è possibile supportare la convoluzione audio su a 7 solo usando funzionalità a 64bit, o questo è possibile perchè la cpu è il doppio più prestante rispetto alla passata generazione anche con codice a 32 bit?

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?

Cinebench è un caso particolare, fa parte di quella ristretta cerchia di applicazioni che muove una grande quantità di dati e quindi ottiene grandi vantaggi... ma non sono applicazioni che si usano sui cellulari.


Indubbiamente i 64 bit su software altamente parallelizzabile che utilizza grosse quantità di dati porta vantaggi, ma nel caso di cinebench quanto di esso è dovuto ai 64bit, e quanto alle maggior risorse spese per il 64 bit rispetto ai 32bit?

riguardo alla questione audio, che io sappia non esistono app come iRig per android, perché l'architettura stessa di android (credo quindi nell'essere interpretato e non compilato, ma parlo grossolanamente) non permette un processing in tempo reale dell'audio.Guarda che si può creare applicazioni Android native praticamente dalla versione 1.1... :stordita:

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?

esatto. A7 risulta più performante anche per il raddoppio dei registri interi per calcoli interi e virgola mobile.

E rieccoli a dire che con meno di 4GB di RAM non ha senso avere 64 bit... ok, l'abbiamo capito che lo avete letto dentro i biscottini della fortuna, ma almeno informarsi prima su cosa voglia dire avere processori a 64 bit, cosa comporta, quali sono i vantaggi del cabio architetturale ad ARMv8 e le ottimizzazioni fatte da Apple al runtime di Objective-C prima di ripetere le solite cose sentite e risentite... anche perchè siamo su un forum di tecnologià, mi aspetto un po' più di approfondimento anche dagli utenti, e se uno non è informato si informi prima di scrivere quello che scrive la massa... è veraemnte frustrante :rolleyes:

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?
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.

esatto. A7 risulta più performante anche per il raddoppio dei registri interi per calcoli interi e virgola mobile.
Ma questo solo per codice a 64 bit?

Indubbiamente i 64 bit su software altamente parallelizzabile che utilizza grosse quantità di dati porta vantaggi, ma nel caso di cinebench quanto di esso è dovuto ai 64bit, e quanto alle maggior risorse spese per il 64 bit rispetto ai 32bit?Non credere che dipende tutto dall'ottimizzazione... non so se ottimizzini più una o l'altra, anche se al giorno d'oggi ha senso, ma agli inizi le versioni a 64 bit erano al contrario poco ottimizzate.
Quando devi fare una compressione e puoi analizzare 8 byte alla volta, va da sé che sei più veloce rispetto a farlo con 4 byte.
L'ottimizzazione arriva con la disponibilità di nuove istruzioni che agevolano le operazioni e non perché hai a disposizione registri maggiori, quello è il minimo.

Non credere che dipende tutto dall'ottimizzazione... non so se ottimizzini più una o l'altra, anche se al giorno d'oggi ha senso, ma agli inizi le versioni a 64 bit erano al contrario poco ottimizzate.
Quando devi fare una compressione e puoi analizzare 8 byte alla volta, va da sé che sei più veloce rispetto a farlo con 4 byte.
L'ottimizzazione arriva con la disponibilità di nuove istruzioni che agevolano le operazioni e non perché hai a disposizione registri maggiori, quello è il minimo.
Tutti sappiamo che il software può essere ottimizato sia aggiungendo nuove funzionalità sia utilizzando algoritmi più efficenti.
Mi sembra logico pensare che con software di un certo livello, utilizzato per lo più su macchine con elevate capicità di calcolo sia maggiormente curato nella parte a 64 che a 32 bit.
Se non sbaglio all'inizio molti software (e se non ricordo male anche cinebench) offriva prestazioni leggermente migliori a 32bit che a 64bit, e non certo perchè i 32bit siano più effecienti

Ps non credo affatto che le differenze siano dovute solo all'ottimizzazione, ma tra il + 10% dovuto al 64bit al + 7% dovuto ai 64 bit e + 3% dovuto all'ottimizzazione software maggiore ci trovo un poco di differenza

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 generale è vero, ma Apple ha fatto diverse modifiche al runtime di Objective-C anche per ovviare a questo problema, ci sono diversi articoli che ne parlano, ho masso il link anche in diverse discussioni su questo forum...

Tipo dei 64 bit dei puntatori usa solo 34 Bit per gli indirizzi, il resto è per flag che marcano l'oggetto istanziato per specifiche funzionalità ed il reference counting, tutte cose che prima dovevano essere gestite in strutture separate con maggiore occumapzione di memoria e più accessi alla stessa, ora caricando il puntatore all'oggetto una volta tutte queste informazioni le posso contenere in un registro senza ulteriori accessi alla RAM.

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 !

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

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

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.

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...

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.

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.

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

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.


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.

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.

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

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.

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...


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...

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.

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

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.

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...

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

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.

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

Si programmatore...

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.

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.

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 :Prrr:

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.

"Verò"... :asd:

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.

Concordò :asd:, 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...

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.

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 :D

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.

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. :O :D

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

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

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. :O :D

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.

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...

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