I Mac con processori ARM forse in arrivo già dal prossimo anno

[cdimauro]

Ah, ok. Concordo. Ma Apple ha un certo peso, e non penso che gli sviluppatori le negherebbero delle ottimizzazioni. Anche quando occupava il 2% di mercato coi suoi Mac basati su PowerPC, gli sviluppatori hanno realizzato codice ottimizzato per Altivec.

[pabloski]

Originariamente inviato da the_joe

chip dedicate a particolari compiti gli arm di Apple saranno velocissimi anche con Photoshop che magari sarà ottimizzato per sfruttarli

La chiave è sempre l'ottimizzazione del software. Se io faccio girare una rete MTCNN per l'identificazione facciale ( 15 frame per secondo, non tantissimo ma adeguato ) su un Rockchip RK3288, ci possono girare pure i filtri di Photoshop in maniera decente.

Originariamente inviato da the_joe

poi però potrebbero essere lentissimi in altri compiti per i quali non sono ottimizzati.

Non nel caso degli Ax di Apple. Sono design molto aggressivi, con pipeline molto profonde, molto più simili ai chip x86 che ai vecchi ARM. E le prestazioni ne guadagnano moltissimo

https://www.reddit.com/r/apple/comme...pu_its_almost/

https://www.anandtech.com/show/13392...icon-secrets/2

Ed Apple non è l'unica https://www.extremetech.com/mobile/2...mobile-monster

Questo ho sempre sostenuto quando dicevo che l'equazione ARM = calcolatrice è completamente fallata.

[the_joe]

Originariamente inviato da pabloski

La chiave è sempre l'ottimizzazione del software. Se io faccio girare una rete MTCNN per l'identificazione facciale ( 15 frame per secondo, non tantissimo ma adeguato ) su un Rockchip RK3288, ci possono girare pure i filtri di Photoshop in maniera decente.

Non è affatto detto perchè gli algoritmi sono diversi e quindi sfruttano istruzioni diverse per cui se sul chip non sono presenti le parti dedicate a quel particolare set di istruzioni, dovranno essere emulate da parti general purpose con netto calo di prestazioni, e se sul chip saranno presenti le parti dedicate anche a quelle istruzioni, i chip non sarà più tanto piccolo...

Non nel caso degli Ax di Apple. Sono design molto aggressivi, con pipeline molto profonde, molto più simili ai chip x86 che ai vecchi ARM. E le prestazioni ne guadagnano moltissimo

https://www.reddit.com/r/apple/comme...pu_its_almost/

https://www.anandtech.com/show/13392...icon-secrets/2

Ed Apple non è l'unica https://www.extremetech.com/mobile/2...mobile-monster

Questo ho sempre sostenuto quando dicevo che l'equazione ARM = calcolatrice è completamente fallata.

Nessuno dice che ARM= poca potenza, ma non è nemmeno realistico pensare che chip da meno di 15W possano competere con chip che consumano (anche) 150W

[pabloski]

Originariamente inviato da the_joe

Non è affatto detto perchè gli algoritmi sono diversi e quindi sfruttano istruzioni diverse per cui se sul chip non sono presenti le parti dedicate a quel particolare set di istruzioni, dovranno essere emulate da parti general purpose con netto calo di prestazioni, e se sul chip saranno presenti le parti dedicate anche a quelle istruzioni, i chip non sarà più tanto piccolo...

Questo però vuol dire che il software non è stato portato e/o ottimizzato per quella piattaforma. E trattandosi di Apple, la vedo assai difficile.

Originariamente inviato da the_joe

Nessuno dice che ARM= poca potenza, ma non è nemmeno realistico pensare che chip da meno di 15W possano competere con chip che consumano (anche) 150W

Ovviamente no. Ma 150W li consuma un Threadripper. E resta il fatto che ARM, in genere, usa meno transistor rispetto ai concorrenti ( cioè per fare le stesse cose ). Il grosso dei consumi è poi legato alle cache. Infine dipende da quali e quante unità funzionali specializzate vengono implementate.

Tanto per dire, un processore vettoriale come quello che implementa le operazioni AVX, consuma molto meno di una fpu a parità di operazioni eseguite.

Esempio banalissimo sono le unità neurali dei chip Qualcomm. Con quelle implementi algoritmi di deep learning ad una frazione del costo energetico di una cpu. Ma ovviamente il software deve usarle e allora si ritorna al primato del software sull'hardware e all'importanza dell'ottimizzazione.

[the_joe]

Originariamente inviato da pabloski

Esempio banalissimo sono le unità neurali dei chip Qualcomm. Con quelle implementi algoritmi di deep learning ad una frazione del costo energetico di una cpu. Ma ovviamente il software deve usarle e allora si ritorna al primato del software sull'hardware e all'importanza dell'ottimizzazione.

Appunto, quello che intendo dire è che Qualcomm ha implementato le unità neurali e questo permette di eseguire quel tipo di calcoli più efficientemente rispetto alle unità non specializzate, ma lo stesso chip per eseguire i calcoli dei filtri di Photoshop dovrà integrare le unità specifiche per quei calcoli e così via per ogni algoritmo esistente, pena un crollo nelle prestazioni quando dovessero essere emulate dalle unità non specializzate.

[pabloski]

Originariamente inviato da the_joe

Appunto, quello che intendo dire è che Qualcomm ha implementato le unità neurali e questo permette di eseguire quel tipo di calcoli più efficientemente rispetto alle unità non specializzate, ma lo stesso chip per eseguire i calcoli dei filtri di Photoshop dovrà integrare le unità specifiche per quei calcoli e così via per ogni algoritmo esistente, pena un crollo nelle prestazioni quando dovessero essere emulate dalle unità non specializzate.

Beh no. Deve possedere acceleratori per determinate classi di problemi. Voglio dire, le GPU accelerano i filtri di Photoshop e pure le reti neurali. Tanto entrambi i casi implicano l'esecuzione di miliardi di operazioni su elementi di matrici gigantesche.

Cioè la classe è "calcoli su matrici gigantesche". E la GPU è un acceleratore adeguato. Altra necessità per questo tipo di operazioni è la larghezza di banda. I 30-35 GB/s miseri di una cpu x86 consumer non vanno bene. I 300+ GB/s di una gpu sono decisamente meglio.

Per esempio le TPU di Google sono agglomerati di processori vettoriali con precisione a 8 bit. A parte gli 8 bit ( che non andrebbero bene per Photoshop ), il resto è adatto ad accelerare pure le operazioni di flitraggio di Photoshop.

[AlexSwitch]

Originariamente inviato da the_joe

Appunto, quello che intendo dire è che Qualcomm ha implementato le unità neurali e questo permette di eseguire quel tipo di calcoli più efficientemente rispetto alle unità non specializzate, ma lo stesso chip per eseguire i calcoli dei filtri di Photoshop dovrà integrare le unità specifiche per quei calcoli e così via per ogni algoritmo esistente, pena un crollo nelle prestazioni quando dovessero essere emulate dalle unità non specializzate.

Però ci sono le GPU... Apple, indipendentemente dall'efficienza delle sue CPU ARM, ha investito parecchio sullo sfruttamento di queste con le API Metal/Metal 2. Infatti dall'attuale versione di macOS, Mojave, OpenGL e OpenCL sono state deprecate e molto probabilmente già dalla prossima versione verranno eliminate.

Una architettura dei futuri Macintosh basata su CPU ARM a basso consumo ( 15/20 W ), per uso generico, affiancate da GPU ( magari proprietarie visto che Apple le ha già sviluppate ) più potenti, per i calcoli più intensivi, non mi sembra così inverosimile.

[pabloski]

Originariamente inviato da AlexSwitch

Una architettura dei futuri Macintosh basata su CPU ARM a basso consumo ( 15/20 W ), per uso generico, affiancate da GPU ( magari proprietarie visto che Apple le ha già sviluppate ) più potenti, per i calcoli più intensivi, non mi sembra così inverosimile.

Per Apple è tutto possibile, perchè è in grado di comandare i programmatori che lavorano nel suo recinto a piacimento.

Ovviamente sanno pure il fatto loro e conoscono l'uso che gli utenti fanno delle loro macchine. Per cui lanceranno un Mac con ARM solo quando saranno sicuri che possa garantire prestazioni almeno pari alle controparti x86.

[NewEconomy]

Originariamente inviato da pabloski

Per Apple è tutto possibile, perchè è in grado di comandare i programmatori che lavorano nel suo recinto a piacimento.

Ovviamente sanno pure il fatto loro e conoscono l'uso che gli utenti fanno delle loro macchine. Per cui lanceranno un Mac con ARM solo quando saranno sicuri che possa garantire prestazioni almeno pari alle controparti x86.

Non è detto che non vengano montati sul successore del MacBook fanless ad esempio, sarebbero perfette lì!

[cdimauro]

Originariamente inviato da the_joe

Non è affatto detto perchè gli algoritmi sono diversi e quindi sfruttano istruzioni diverse per cui se sul chip non sono presenti le parti dedicate a quel particolare set di istruzioni, dovranno essere emulate da parti general purpose con netto calo di prestazioni, e se sul chip saranno presenti le parti dedicate anche a quelle istruzioni, i chip non sarà più tanto piccolo...

Esattamente. E qui NON stiamo parlando di apposite unità (esterne al core) dedicate, ma a come funziona il core di per sé.

Come già detto prima, l'ISA FA la differenza. E idem la microarchitettura.

[omerook]

Originariamente inviato da the_joe

Certo, anche qualsiasi altro soc da cellulare va bene difatti li usiamo tutti i giorni per questi compiti, quello che volevo dire è che magari grazie alle parti di chip dedicate a particolari compiti gli arm di Apple saranno velocissimi anche con Photoshop che magari sarà ottimizzato per sfruttarli, poi però potrebbero essere lentissimi in altri compiti per i quali non sono ottimizzati.
Così come il mio box TV è velocissimo a decodificare i flussi video 4k con un chip da 1€ che è più veloce di un i7 per quel compito, ma poi naufraga in ogni altro utilizzo.

io mi chiedo perché Adobe o chiunque puduce foftware di un certo livello non si fa realizzare chip dedicati per loro suite da aggiungere ai sistemi. non credo che al professionista cambi la vita spendere 200 euro in più dopo aver acquistato un software sicuramente esoso.

[Piedone1113]

Originariamente inviato da cdimauro

Come già detto anche altre volte, VLIM è un modello fallimentare in ambito general-computing. Va benissimo, invece, in particolari nicchie di mercato.

Non stavo parlando di core vlim, Ma di core x86new senza la retrocompatibilità arcaica ( x87 etc) affiancati da un core vlim ottimizzato per codice retrocompatibile.
Credo che sia possibile, in fondo i nuovi ryzen hanno gia la predisposizione per utilizzare unità di calcolo eterogenei in modo trasparente per l'os.
Sicuramente ci sarà un consumo di silicio superiore rispetto al solo path software, ma nei primi tempi si avrebbe una perdita minima sui path non più implementati in hardware nei core x86.
Ps credo che molte funzioni possano in futuro essere spostati agevolmente dai core x86 alle cu ( apu amd) aumentando al tempo stesso efficienza energetica per secondo e velocità di esecuzione

[cdimauro]

Originariamente inviato da Piedone1113

Non stavo parlando di core vlim, Ma di core x86new senza la retrocompatibilità arcaica ( x87 etc) affiancati da un core vlim ottimizzato per codice retrocompatibile.

Non è mi chiaro cosa vorresti avere.

"x86new" è una nuova ISA privata di parti di x86/x64, e questo è chiaro, ma è incompatibile a livello binario? Ha, cioé, un nuovo formato per le istruzioni?

Il core VLIW, invece, dovrebbe avere tutte le parti di x86/x64, ma anche qui non è chiaro se anche lui sarebbe incompatibile a livello binario.

Credo che sia possibile, in fondo i nuovi ryzen hanno gia la predisposizione per utilizzare unità di calcolo eterogenei in modo trasparente per l'os.

Ti dico già subito che non si può fare perché i binari non hanno informazioni su quale tipo di funzionalità vengano usati, e quindi il s.o. non sa su quali core smistare i processi.

Sicuramente ci sarà un consumo di silicio superiore rispetto al solo path software, ma nei primi tempi si avrebbe una perdita minima sui path non più implementati in hardware nei core x86.

Sì. Ma anche una nuova ISA potrebbe emulare x86/x64 con impatti minimi sulle prestazioni, e spostando quasi tutto il legacy in emulazione software.

Ps credo che molte funzioni possano in futuro essere spostati agevolmente dai core x86 alle cu ( apu amd) aumentando al tempo stesso efficienza energetica per secondo e velocità di esecuzione

Le CU sono ben diverse. Non funzionerebbe. Per lo meno non sarebbe efficiente.