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

[pabloski]

Originariamente inviato da cdimauro

1) perché parli di SoC? Si stava confrontando soltanto il core.

Allora ti piace vincere facile

Originariamente inviato da cdimauro

2) impacchettare miriadi di core con un TDP "umano" a quanto pare non è servito per sfondare nel mondo dei server: chissà perché...

Perchè c'è gente che si ostina ad usare Node.js per il server-side.

Originariamente inviato da cdimauro

Vedi, l'errore di fondo sta proprio qui: "fanno le stesse cose". Sì, ma bisogna vedere COME le fanno!

Intanto lo fanno consumando meno e con meno transistor. Ovviamente il prezzo da pagare è un IPC inferiore.

Originariamente inviato da cdimauro

Se fosse semplicemente come dici tu, i processori VLIW avrebbero dovuto stradominare ovunque

E infatti il mese scorso leggevo un pò di cose su Itanium e sono rimasto a dir poco entusiasta. E l'autore concludeva che il problema grosso erano stati i signori del software, più precisamente i progettisti di compilatori.

Ma non sarà che alla fin fine il problema siamo noi che scriviamo software ancora utilizzando metodi e pattern degli anni '80?

Originariamente inviato da cdimauro

Adesso prova a immaginare lo sforzo necessario per usare HSA in altre applicazioni.

Si ok, ma così siamo condannati a restare fermi per sempre.

Originariamente inviato da cdimauro

quindi se ne valga realmente la pena. Cosa tutt'altro che scontata.

So che la questione è sempre il soldo. La stessa ragione per cui l'altra volta sminuivo l'ABI x32.

Però di legacy in legacy, la tecnologia ristagna. Comunque siamo d'accordo che il problema principale resta il software. Nel qual caso parlare di ARM su PC diventa inutile, visto che comunque ( anche se ARM dovesse sfornare l'uber architettura del 21° secolo ) questi SoC si ritroverebbero ad emulare x86 per poter eseguire software x86.

[Piedone1113]

Originariamente inviato da pabloski

Allora ti piace vincere facile





Intanto lo fanno consumando meno e con meno transistor. Ovviamente il prezzo da pagare è un IPC inferiore.



cut

Ognuno secondo le proprie convinzioni osanna una particolare architettura.
Se apple riuscisse a fare un 4x o 8x su arm con prestazioni simili a un 4x o 8x 386 bisogna guardare in ordine a :
Superfice.
Costo.
Consumo.

[pabloski]

Originariamente inviato da Piedone1113

Ognuno secondo le proprie convinzioni osanna una particolare architettura.
Se apple riuscisse a fare un 4x o 8x su arm con prestazioni simili a un 4x o 8x 386 bisogna guardare in ordine a :
Superfice.
Costo.
Consumo.

Il punto è questo. Si cerca di capire se può essere o meno. Per ora non esistono ARM intenzionalmente pensati per competere con gli x86 in quanto ad IPC. ARM è sinonimo di bassi consumi, nel senso che chi progetta quei SoC, pensa prima ai consumi e poi al resto.

Pure Apple, nonostante abbia fatto salti mortali per aumentare le prestazioni, ha posto come paletto consumi e calore prodotto. Ma pure per i laptop ARM si parla della stessa cosa. Infatti la prima caratteristica che viene pubblicizzata è l'autonomia.

In questo io vedo l'impossibilità di sostituire x86 in tutti gli ambiti. Perchè se Intel e AMD accettano di sforare i 100W, ARM e i suoi soci non l'accetteranno mai.

La questione è che per uso generalista, basta pure uno smartphone. Con la diffusione del cloud si sentirà sempre meno la necessità di terminali potenti. Ed in quest'ottica che s'introduce la possibilità adozione di ARM per i PC Apple.

[Piedone1113]

Originariamente inviato da pabloski

Il punto è questo. Si cerca di capire se può essere o meno. Per ora non esistono ARM intenzionalmente pensati per competere con gli x86 in quanto ad IPC. ARM è sinonimo di bassi consumi, nel senso che chi progetta quei SoC, pensa prima ai consumi e poi al resto.

Pure Apple, nonostante abbia fatto salti mortali per aumentare le prestazioni, ha posto come paletto consumi e calore prodotto. Ma pure per i laptop ARM si parla della stessa cosa. Infatti la prima caratteristica che viene pubblicizzata è l'autonomia.

In questo io vedo l'impossibilità di sostituire x86 in tutti gli ambiti. Perchè se Intel e AMD accettano di sforare i 100W, ARM e i suoi soci non l'accetteranno mai.

La questione è che per uso generalista, basta pure uno smartphone. Con la diffusione del cloud si sentirà sempre meno la necessità di terminali potenti. Ed in quest'ottica che s'introduce la possibilità adozione di ARM per i PC Apple.

Se per usarlo con programmi che lavorano in cloud basterebbe anche un Pentium 75 ( o un arm/mips di un router economico)

[cdimauro]

Originariamente inviato da pabloski

Allora ti piace vincere facile

Sono le vittorie più difficili e complicate che mi stimolano: con quelle facili non c'è gusto.

Perchè c'è gente che si ostina ad usare Node.js per il server-side.

Sai bene che server-side non esiste solo Node.js, che peraltro è una tecnologia piuttosto recente. E lo stesso Node.js mi pare sia ben ottimizzato anche per ARM.

Ci sono tantissime tipologie di codice che vengono eseguite server side, e se la soluzione fosse quella di scaricarle su piattaforme hardware che semplicemente consumino di meno, non staremmo nemmeno qui a parlare: processori come ARM vincerebbero a mani basse, e oggi dominerebbero il mercato.

Ovviamente non è affatto così perché anche la latenza è un parametro molto importante di cui tenere conto: non puoi sempre aspettare parecchio prima di ricevere il risultato di un'operazione. E qui entrano in gioco le famigerate prestazioni single core/thread.

Intanto lo fanno consumando meno e con meno transistor.

Non è affatto detto che si consumi meno: se riesci a portare a termine un'operazione in meno tempo, puoi anche consumare di meno.

C'è un interessante post del solito matthey sull'argomento che consiglio di studiare.

In particolare c'è uno studio/presentazione nel secondo link che ha fornito, e che riguarda un processore (il BA22 di CAST) che fa concorrenza ad ARM in ambito embedded.

Considerazioni similari si possono ovviamente fare anche a x86/x64. Ma leggiti per bene sia il post di matthey sia la presentazioni, e poi fai le tue valutazioni.

Ovviamente il prezzo da pagare è un IPC inferiore.

Beh, qui rientriamo sempre sul discorso ISA/Architetture e relativa micro-architettura, e ovviamente dipende dalla tipologia di codice eseguito.

Ci sono troppe variabili in gioco di cui tenere conto, e non si può arrivare a delle conclusioni sull'argomento.

E infatti il mese scorso leggevo un pò di cose su Itanium e sono rimasto a dir poco entusiasta. E l'autore concludeva che il problema grosso erano stati i signori del software, più precisamente i progettisti di compilatori.

Ma non sarà che alla fin fine il problema siamo noi che scriviamo software ancora utilizzando metodi e pattern degli anni '80?

No, l'errore di Intel e HP con Itanium è stato proprio quello di confidare troppo sulla bontà e sul miglioramento dei compilatori. Peraltro la qualità dei compilatori Intel è ben nota. Intel, quindi, aveva tutto l'interesse a progettare ottimi compilatori anche per Itanium.

Per tali ragioni quella tesi non è certo condivisibile.

Mentre la reale causa è dovuta al fatto che è impossibile per un compilatore generare codice che possa tenere conto delle esigenze che un processore ha istantaneamente, ciclo di clock per ciclo di clock. Mentre è proprio ciò che cercare di fare al meglio (che può) l'unità di esecuzione out-of-order, che in base all'occupazione delle risorse in quel preciso momento cerca di schedulare le istruzioni da inviare alle unità d'esecuzione libere (o alle loro code).

D'altra parte c'è da dire che le scelte di Intel e HP sono frutto delle conoscenze e delle previsioni dell'epoca. Erano convinti che sarebbe andata in un certo modo e hanno lavorato in tal senso. Purtroppo per loro, quelle assunzioni si sono rivelate sbagliate, e i processori OoO hanno fatto le scarpe a VLIW et similia, relegandoli a nicchie di mercato.

Per questo è ridicolo fare battute sull'argomento (non ce l'ho con te, sia chiaro: è un discorso generale): son tutti bravi ad aprire bocca col senno di poi.

Si ok, ma così siamo condannati a restare fermi per sempre.

Mai detto questo, mi pare, ma la questione è sempre la solita: i cambiamenti richiedono sforzi/sacrifici/risorse. Che possono non valere la pena.

Poi se uno ha tempo da buttare e sperimentare... che si accomodi pure.

So che la questione è sempre il soldo. La stessa ragione per cui l'altra volta sminuivo l'ABI x32.

Hum. x32 richiede(va) ben poche risorse SE le toolchain e le applicazioni fossero state scritte decentemente.

Una volta che l'ABI risulta ben definita, in linea teorica sarebbe sufficiente un parametro di compilazione per generare binari per essa.

Se così non è, vuol dire che ci sono ALTRI problemi. Che non attengono all'ABI, ovviamente.

Però di legacy in legacy, la tecnologia ristagna. Comunque siamo d'accordo che il problema principale resta il software. Nel qual caso parlare di ARM su PC diventa inutile, visto che comunque ( anche se ARM dovesse sfornare l'uber architettura del 21° secolo ) questi SoC si ritroverebbero ad emulare x86 per poter eseguire software x86.

Indubbiamente, ma non è quello lo scopo e non ciò che farà Apple, che può contare sul controllo assoluto delle sue piattaforme mobile e desktop. Infatti ha imposto l'uso dei nuovi universal binary, e quindi può tranquillamente generare codice ad hoc per i suoi futuri processori ARM "desktop".

Anche Linux non ha problemi del genere, visto che si basa sul modello open source (ed è il motivo per cui, di fatto, viene imposto il rilascio dei sorgenti se si vuole avere supporto. Poi che anche coi sorgenti a disposizione questo non sia garantito, è un altro paio di maniche).

Il problema rimane per Windows e, in generale, per tutti i sistemi che non hanno a disposizione sorgenti o codice IL (ma c'è .NET per questo). In questo caso c'è tanto codice legacy x86 o x64 che rimarrà disponibile sempre in tale forma.

Comunque anche in questo caso peggiore ci potrebbero essere soluzioni tecnologie più moderne in grado di far girare in emulazione software x86/x64, ma mantenendo ugualmente prestazioni molto elevate. Il tutto senza mantenere i costi del legacy, e offrendo innovazioni e miglioramenti.

Originariamente inviato da pabloski

Il punto è questo. Si cerca di capire se può essere o meno. Per ora non esistono ARM intenzionalmente pensati per competere con gli x86 in quanto ad IPC. ARM è sinonimo di bassi consumi, nel senso che chi progetta quei SoC, pensa prima ai consumi e poi al resto.

Pure Apple, nonostante abbia fatto salti mortali per aumentare le prestazioni, ha posto come paletto consumi e calore prodotto. Ma pure per i laptop ARM si parla della stessa cosa. Infatti la prima caratteristica che viene pubblicizzata è l'autonomia.

E invece proprio le soluzioni di Apple sono quanto di più simile a x86/x64 si possa trovare in giro. Anzi, hanno soluzioni micro-architetturali ben più aggressive.

Come già detto prima, basti fare un confronto fra i rispettivi frontend e backend, e si capisce quali soluzioni e risorse Apple abbia messo in gioco per sfornare eccellenti prestazioni in single core/thread.

In questo io vedo l'impossibilità di sostituire x86 in tutti gli ambiti. Perchè se Intel e AMD accettano di sforare i 100W, ARM e i suoi soci non l'accetteranno mai.

Non sono obbligati a farlo, infatti: anche gli ARM possono benissimo arrivare a superare i 100W.

La questione è che per uso generalista, basta pure uno smartphone. Con la diffusione del cloud si sentirà sempre meno la necessità di terminali potenti. Ed in quest'ottica che s'introduce la possibilità adozione di ARM per i PC Apple.

Infatti a livello generale i processori di Apple potrebbero benissimo essere impiegati per il "daily use" di cui si parlava prima.

Con le osservazioni e note del caso, che ho già elencato.

[Piedone1113]

Originariamente inviato da cdimauro

Non è affatto detto che si consumi meno: se riesci a portare a termine un'operazione in meno tempo, puoi anche consumare di meno.

C'è un interessante post del solito matthey sull'argomento che consiglio di studiare.

Quando usci il primo atom ci furono centinaia di test che confrontavano atom vs core.
Nei test potenza totale impiegata per quasi tutti gli scenari era sempre dietro ( con consumi maggiori dal 10 al 70%).

Una cpu che consuma poco non vuol dire nulla ( più giusto considerare i gFlop/Watt ) ma anche questo è poco veritiero: cosa succede se ci sono th concorrenti sullo stesso core?
Proprio in ambito server si è visto che tranne per rari casi i server su architettura arm hanno un efficienza totale molto inferiore rispetto a x86 ( ed i server in genere hanno ben poco di poco ottimizzato lato software)

[cdimauro]

Condivido il discorso generale, però dipende anche dal tipo di software, come già detto, e anche quello server viene ottimizzato. Python e PHP, ad esempio, sono continuamente alla ricerca di ottimizzazioni per velocizzare l'esecuzione. Nodejs ha subito un impulso ENORME da questo punto di vista, e Javascript oggi è il linguaggio "dinamico" che ha migliori prestazioni. Giusto per fare qualche esempio.

[Piedone1113]

Originariamente inviato da cdimauro

Condivido il discorso generale, però dipende anche dal tipo di software, come già detto, e anche quello server viene ottimizzato. Python e PHP, ad esempio, sono continuamente alla ricerca di ottimizzazioni per velocizzare l'esecuzione. Nodejs ha subito un impulso ENORME da questo punto di vista, e Javascript oggi è il linguaggio "dinamico" che ha migliori prestazioni. Giusto per fare qualche esempio.

Proprio li casca l'asino:
Se in ambiente server dove c'è una costante ricerca delle ottimizzazioni e prestazioni Arm a parità di carico di lavoro di un cluster x86 ha prestazioni per watt inferiori non vedo così scontato il presupposto AXX Apple votato alle prestazioni pure maggiore efficienza di x86.
Per il resto nell'attimo stesso che arm erode quote a x86 ci ritroveremo con una nuova architettura x86/64New dove tutte le caratteristiche magagne dovute alla compatibilità arcaica saranno trasferite da silicio a software ( o magari implementando un core vliw per la compatibilità di software che non se ne può fare proprio a meno).
In fondo la CU potrebbe gestire bene quest'alternativa e probabilmente il costo silicio sarebbe ben controbilanciato da core più piccoli e meno assetati di ampere

[cdimauro]

Originariamente inviato da Piedone1113

Proprio li casca l'asino:
Se in ambiente server dove c'è una costante ricerca delle ottimizzazioni e prestazioni Arm a parità di carico di lavoro di un cluster x86 ha prestazioni per watt inferiori non vedo così scontato il presupposto AXX Apple votato alle prestazioni pure maggiore efficienza di x86.

Ma mi pare che su questo sia d'accordo.

Per il resto nell'attimo stesso che arm erode quote a x86 ci ritroveremo con una nuova architettura x86/64New dove tutte le caratteristiche magagne dovute alla compatibilità arcaica saranno trasferite da silicio a software

Praticamente stai descrivendo la mia nuova architettura.

( o magari implementando un core vliw per la compatibilità di software che non se ne può fare proprio a meno).

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

In fondo la CU potrebbe gestire bene quest'alternativa e probabilmente il costo silicio sarebbe ben controbilanciato da core più piccoli e meno assetati di ampere

Ma molto meno efficienti.

[AlexSwitch]

Intanto da ieri stanno circolando in rete questi benchmark di ipotetiche CPU Arm di fascia desktop ( almeno dai risultati ottenuti ) di Apple:

https://appleinsider.com/articles/19...-chips-for-mac

[omerook]

mi chiedevo se esistono dei benchmark che girano su Java. cosi tanto per giocare a perdere un po' di tempo.

[NewEconomy]

Originariamente inviato da AlexSwitch

Intanto da ieri stanno circolando in rete questi benchmark di ipotetiche CPU Arm di fascia desktop ( almeno dai risultati ottenuti ) di Apple:

https://appleinsider.com/articles/19...-chips-for-mac

Mi sembrano abbastanza potenti..O sbaglio?

[pabloski]

Originariamente inviato da NewEconomy

Mi sembrano abbastanza potenti..O sbaglio?

Infatti. Poi mi pare che qui un pò tutti abbiano dimenticato il fattore essenziale, ovvero l'ottimizzazione del software.

Vi racconto una storia.

Un pò di tempo fa incappai in una serie di benchmark su Phoronix riguardanti una libreria per il deep learning https://www.phoronix.com/scan.php?pa...idia-amd&num=1

E le GPU AMD ne uscirono con le ossa rotte. Ma giustamente il buon Bridgman ( ingegnere AMD ) https://www.phoronix.com/forums/foru...75#post1073175

Ed è lo stesso canovaccio visto con HSA.

Alla fine della fiera, le ottimizzazioni del software arrivano a produrre risultati incredibili. Un esempio da far girare la testa di 360 gradi https://software.intel.com/en-us/art...burst-compiler

E cos'hanno fatto? Semplicemente riarrangiato i dati!

Per cui continuerò a ripetere che si sta facendo una caciara pazzesca, basandosi sul nulla. Ovvero mancano dati certi su questi SoC ARM che Apple presenterà ( forse ).

[cdimauro]

Originariamente inviato da AlexSwitch

Intanto da ieri stanno circolando in rete questi benchmark di ipotetiche CPU Arm di fascia desktop ( almeno dai risultati ottenuti ) di Apple:

https://appleinsider.com/articles/19...-chips-for-mac

Geekbench. Per cui non spendo nemmeno una parola.

[AlexSwitch]

Originariamente inviato da cdimauro

Geekbench. Per cui non spendo nemmeno una parola.

Sicuramente ci sono dei caveat su questi valori, in primis dal fatto che sono benchmark sintetici e, secundis, che non si sa bene che CPU o SoC siano quelli testati.
Ma è rilevante il fatto che Apple probabilmente ha quasi tutto pronto per un passaggio in grande stile su ARM, coprendo da subito più fasce di prodotti.
Vedremo in futuro cosa arriverà e come si comporterà....

[NewEconomy]

Originariamente inviato da emiliano84

sempre soliti discorsi triti e ritriti, i benchmark lasciano il tempo che trovano, come quelli di altre cpu ARM su android con punteggi superiori ad intel/amd... la bonta' di queste CPU la potremo verificare solo quando avremo lo stesso sw su entrambe le architettura da utilizzare, per esempio applicare un tot di filtri pesanti con photoshop su un'immagine enorme

Ma si, era indubbio quello...Poi i Benchmark non sappiamo nemmeno in che condizioni vengano fatti insomma....


Ad ogni modo, se non ho capito male già l’attuale A12X è predisposto fortemenete per lavori di grafica (Photoshop e roba simile). In teoria i Mac sarebbero più sbilanciati verso i lavori di grafica/editing quindi, potrebbe essere che Apple sviluppi ARM espressamente votati per queste funzioni?

[cdimauro]

Originariamente inviato da AlexSwitch

Sicuramente ci sono dei caveat su questi valori, in primis dal fatto che sono benchmark sintetici e, secundis, che non si sa bene che CPU o SoC siano quelli testati.
Ma è rilevante il fatto che Apple probabilmente ha quasi tutto pronto per un passaggio in grande stile su ARM, coprendo da subito più fasce di prodotti.
Vedremo in futuro cosa arriverà e come si comporterà....

Anch'io penso che Apple si stia già preparando. Ed è perfettamente naturale, dato il suo modus operandi.

Per il resto aspetto benchmark con applicazioni reali. E, come hai detto, che siano di certa provenienza.

[the_joe]

Dipenderà molto dai campi di applicazione e dall'ottimizzazione dei programmi però in ambiti generici secondo me saranno dietro e di molto dai proci desktop.
Ad esempio ho un TV box che riesce a decodificare agilmente i video in 4k, ma banalmente è lentissimo anche solo per la navigazione web...

[cdimauro]

Per questi ambiti, come pure molti di uso normale / comune / quotidiano, già da tempo i SoC Apple risultano adeguati.

[the_joe]

Originariamente inviato da cdimauro

Per questi ambiti, come pure molti di uso normale / comune / quotidiano, già da tempo i SoC Apple risultano adeguati.

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.