Link alla notizia: https://www.hwupgrade.it/news/apple/apple-i-mac-mini-arm-nelle-mani-degli-sviluppatori-i-primi-test-fanno-sfigurare-microsoft-e-qualcomm_90455.html

Gli sviluppatori di software per macOS stanno ricevendo i primi Mac mini sperimentali con chip A12Z. I primi test, seppur svolti in emulazione, rivelano una buona potenza del chip e mettono in cattiva luce il Surface Pro X, basato su chip Microsoft SQ1 derivato dallo Snapdragon 8cx.

Click sul link per visualizzare la notizia.

Forse in molti ancora non si rendono conto della portata dell'annuncio e dei risvolti nei prossimi anni. La resilienza e la strategia portata avanti negli anni da Apple ha veramente dell'invidiabile.. Sono partiti oltre 10 anni fa, ed ora sono in grado di realizzarsi tantissimi sistemi e sottosistemi in casa completamente custom fino ad approdare nel mac. Non a caso il primo chip mobile a 64bit è arrivato prima degli altri in iPhone, e gia anni fa la stessa azienda parlava di "Desktop class architecture".
Questo mac mini monta un chip da oltre 10 miliardi di transistor (A12X è stato presentato con questi numeri), vedremo i primi chip a 5nm pensati per Mac. Intel ha perso molto in termini di immagine..E' ferma al palo da anni..

Senza parlare del fatto che il developer kit al momento usa solo 4 degli 8 core disponibili, che che molto probabilmente i modelli che commercializzeranno saranno basati non su un chip per iPad ma si qualcosa con meno limiti termici.

In che senso gira nativamente sul surface pro x? :mbe: non mi pare esista geekbench nativo per windows on arm.
Certo sono estremamente curioso di vedere le prestazioni dei primi macbook con ARM, già sembrano competitive con un chip per tablet di due anni fa, figuriamoci con core da A14 a 5nm, vista così non ci scommetterei soldi che non andranno più veloci degli intel consumando meno emulando l'x64, sarebbe una bella scossa al mercato, pur essendo io tendenzialmente anti apple per la chiusura mi farebbe gola una cosa tipo un ipad pro con macos, dockabile ad una postazione fissa

Va bene che l'A12 è un gran bel chip e che Geekbench girava in emulazione però confrontarlo con un misero Intel Core i3-1000NG4 dual core non ha molto senso. Un top di gamma Arm va confrontato con un top di gamma x86 altrimenti non si capisce niente di quale sia la piattaforma migliore.

Senza parlare del fatto che il developer kit al momento usa solo 4 degli 8 core disponibili, che che molto probabilmente i modelli che commercializzeranno saranno basati non su un chip per iPad ma si qualcosa con meno limiti termici.

ho letto che ha anche un clock più basso rispetto al A12 originale che c'era su iPad Pro
i SoC che vedremo sui Mac comunque saranno ben diversi, chiaramente non è che siccome c'è più dissipazione automaticamente fanno il miracolo ma ragionevolmente ci si può aspettare qualcosa in più, senza contare che questo è un processore presentato nel 2018

mi sarei aspettato di peggio, però non so quanto senso abbiano questi benchmark adesso
come già dicevo altrove se completano la transizione a ARM in 2 anni o sono fuori di testa o hanno qualcosa di molto performante in serbo per i Mac e quindi si sentono tranquilli, anche se molto dipende dagli sviluppatori perché le prestazioni top le avranno solo sulle app ricompilate e lì devono solo sperare che le sw house ci si buttino a capofitto

Va bene che l'A12 è un gran bel chip e che Geekbench girava in emulazione però confrontarlo con un misero Intel Core i3-1000NG4 dual core non ha molto senso. Un top di gamma Arm va confrontato con un top di gamma x86 altrimenti non si capisce niente di quale sia la piattaforma migliore.

Quello presente nel devkit non è di sicuro il top di gamma. E' solo il SoC di un iPad, buttato lì per cominciare a dare qualcosa agli sviluppatori.

Difficile che troveremo quel chip nei macbook pro. Forse negli air, ma nemmeno è detto.

Inoltre quel test è stato fatto con 4 degli 8 core attivi. Quindi quasi la metà della potenza effettiva del SoC.

Ma comunque, ripeto, che non sono quelli i chip che vedremo nei pc Apple.

Quello presente nel devkit non è di sicuro il top di gamma. E' solo il SoC di un iPad, buttato lì per cominciare a dare qualcosa agli sviluppatori.

Difficile che troveremo quel chip nei macbook pro. Forse negli air, ma nemmeno è detto.

Inoltre quel test è stato fatto con 4 degli 8 core attivi. Quindi quasi la metà della potenza effettiva del SoC.

Ma comunque, ripeto, che non sono quelli i chip che vedremo nei pc Apple.
D'accordo, ma l'A12Z non è certo un basso gamma come l'Intel Core i3-1000NG4 con 2 core. Se non è un top gamma allora è un quasi top gamma. Inoltre Geekbench non è il più affidabile dei benchmark. Con gli iPhone è sempre abbastanza generoso, poi facendo real world test la differenza con gli Android è molto inferiore.
Sicuramente i chip Apple saranno potenti ma i confronti vanno fatti tra top di gamma e usando real world test altrimenti non si capisce niente. Poi se veramente questi Arm riusciranno a competere con gli x86 top di gamma allora ben venga. Più concorrenza c'è e meglio è per noi.

Umh...sarà interessante e curioso vedere qualcosa di definitivo all'opera.
Ma per ora, i rumors lasciano trapelare che la Apple con questo ARM faccia il botto.
La mia preoccupazione è che l' hype aumenta, e con esso aumenteranno esponenzialmente anche i prezzi...:mad:

A me al di là della potenza bruta, interessa conoscere COSA si potrà far girare.
Se non vi sarà particolare interesse a ricompilare tutto per ARM, si rischia di avere un bel prodotto... che però rimarrà solo a fare polvere...

il punto non è quanto riesce a fare apple (che ci lavora da parecchio, brava ecc. ecc.) ma quanto fa schifo windows on arm :asd:

bisognerebbe fare il confronto con le cpu intel, sono quelle il pomo della discordia

il punto non è quanto riesce a fare apple (che ci lavora da parecchio, brava ecc. ecc.) ma quanto fa schifo windows on arm :asd:

bisognerebbe fare il confronto con le cpu intel, sono quelle il pomo della discordia

E' anche vero però che MS non potrà mai ottimizzare a fondo come Apple che ora fa sia l'OS e sia il processore che quindi sono scritti/progettati e ottimizzati l'uno in funzione dell'altro. Il processore del Surface Pro X è un Qualcomm un po' customizzato ma non certamente progettato apposta per Windows. E anche Windows non è certo progettato per Arm dato che deve girare anche su x86 Intel e pure AMD.
Poi per carità, è anche vero che questo kit di Apple non è un prodotto definitivo.

Apple ora ha la possibilità unica di ottimizzare al massimo OS e processore, l'uno in funzione dell'altro a differenza di MS/Google/Intel/AMD/Qualcomm che fanno prodotti general purpose. Ciò aiuterà molto le prestazioni. E pure gli sviluppatori di software Apple potranno migliorare le prestazioni dovendo ottimizzare solo per Arm (già prima per Mac OS si dovevano preoccupare solo degli Intel e non degli AMD). Basterà per competere con i top di gamma x86? Speriamo, sicuramente è molto promettente. Comunque lo scopriremo con certezza solo quando ci saranno real world test con top di gamma x86.

E' anche vero però che MS non potrà mai ottimizzare a fondo come Apple che ora fa sia l'OS e sia il processore che quindi sono scritti/progettati e ottimizzati l'uno in funzione dell'altro. Il processore del Surface Pro X è un Qualcomm un po' customizzato ma non certamente progettato apposta per Windows. E anche Windows non è certo progettato per Arm dato che deve girare anche su x86 Intel e pure AMD.
Poi per carità, è anche vero che questo kit di Apple non è un prodotto definitivo.

Apple ora ha la possibilità unica di ottimizzare al massimo OS e processore, l'uno in funzione dell'altro a differenza di MS/Intel/AMD/Qualcomm che fanno prodotti general purpose. Ciò aiuterà molto le prestazioni. E pure gli sviluppatori di software Apple potranno migliorare le prestazioni dovendo ottimizzare solo per Arm (già prima per Mac OS si dovevano preoccupare solo degli Intel e non degli AMD). Basterà per competere con i top di gamma x86? Speriamo, sicuramente è molto promettente. Comunque lo scopriremo con certezza solo quando ci saranno real world test con top di gamma x86.
infatti è quello che ho sempre detto, apple riesce ad essere affidabile perchè a differenza di microsoft (e google con android), ha quattro prodotti messi in croce; come dicevi poi si fa tutto in casa quindi è normale essere meglio della concorrenza, ma il punto su cui battevo io è che i confronti devono farli tra arm e intel, sempre con osx. si prendono due macchine di pari caratteristiche e si paragonano, poi vediamo quale risulta migliore. vincere contro windows on arm è troppo facile :D

D'accordo, ma l'A12Z non è certo un basso gamma come l'Intel Core i3-1000NG4 con 2 core.


E' ancora inferiore, visti i limiti termini entro cui deve stare. Parliamo di 9W per l'i3 contro i max 4W ( tipici di questi SoC mobile ) dell'A12Z.


Con gli iPhone è sempre abbastanza generoso, poi facendo real world test la differenza con gli Android è molto inferiore.

Si ok. Ma stiamo parlando di software x86 che gira in emulazione. Non è chiaro quanto pesa quest'emulazione. Per cui, quei numeri sono da prendere molto alla leggera. Perchè poi stiamo parlando del devkit e non è minimamente quello il SoC che sarà presente nei Mac.


Poi se veramente questi Arm riusciranno a competere con gli x86 top di gamma allora ben venga. Più concorrenza c'è e meglio è per noi.

Limiti tecnici non ce ne sono. Ci sono SoC ARM per server con 64-128 core che competono senza difficoltà. Tant'è ( notizia di qualche settimana fa ) che un supercomputer ARM è arrivato in testa alla top500.

Poi, non per idolatrarli, ma Apple ha mai fatto cazzate? Li si può accusare di tutto, tranne che essere degli incompetenti. Penso sappiano benissimo di non potersi permettere il lusso di vendere computer ARM che abbiano una frazione della potenza di quelli x86.

vincere contro windows on arm è troppo facile :D

beh pure contro Windows x86 non è così difficile :D

A me al di là della potenza bruta, interessa conoscere COSA si potrà far girare.
Se non vi sarà particolare interesse a ricompilare tutto per ARM, si rischia di avere un bel prodotto... che però rimarrà solo a fare polvere...

Esatto.
Siamo nel 2020 ed è abbastanza ovvio che una compagnia come Apple tiri fuori un processore che va forte... Tutti a modo loro vanno forte, ed è anche vero che nei sistemi moderni la potenza della CPU ha una rilevanza diversa a quella che aveva 10 anni fa.
E se si vuol rimanere a parlare di potenza pura, rimango scettico sul fatto che questi ARM, potranno contrastare le CPU x86 top di gamma nel momento in cui usciranno. Sia in potenza che in versabilità. Con una CPU Intel o AMD ci fati TUTTO. Con questi ARM non so.

il punto non è quanto riesce a fare apple (che ci lavora da parecchio, brava ecc. ecc.) ma quanto fa schifo windows on arm :asd:

bisognerebbe fare il confronto con le cpu intel, sono quelle il pomo della discordia

Verissimo. La questione è solo Apple vs Intel.
Non Apple vs Windows on ARM...

E' come se a me danno una Lamborghini e a Charles Leclerc una Panda. Vinco io garantito, mi bastano 500 metri di rettilineo... che test è? A prescindere dalla bravura del pilota.

Apple avrà dimostrato di aver fatto la scelta giusto quando, a piattaforma ultimata, avrà sverniciato i top gamma Intel. Io è quello che voglio vedere.
Windows on ARM non dovrebbe neanche esistere, quindi non è un test tanto probante :D

E' ancora inferiore, visti i limiti termini entro cui deve stare. Parliamo di 9W per l'i3 contro i max 4W ( tipici di questi SoC mobile ) dell'A12Z.



Si ok. Ma stiamo parlando di software x86 che gira in emulazione. Non è chiaro quanto pesa quest'emulazione. Per cui, quei numeri sono da prendere molto alla leggera. Perchè poi stiamo parlando del devkit e non è minimamente quello il SoC che sarà presente nei Mac.



Limiti tecnici non ce ne sono. Ci sono SoC ARM per server con 64-128 core che competono senza difficoltà. Tant'è ( notizia di qualche settimana fa ) che un supercomputer ARM è arrivato in testa alla top500.

Poi, non per idolatrarli, ma Apple ha mai fatto cazzate? Li si può accusare di tutto, tranne che essere degli incompetenti. Penso sappiano benissimo di non potersi permettere il lusso di vendere computer ARM che abbiano una frazione della potenza di quelli x86.

L'emulazione via Rosetta2 pesa... basta andarsi a vedere i risultati dei vari test soprattutto quelli che usano le istruzioni SSE2, SSE4 e la famiglia AVX. Il Pay off nei confronti di ARM è più che sensibile.

I SoC Apple Silicon sono differenti dalle CPU/SoC ARM per server/supercomputer. Intorno ai Core della CPU Apple ha inserito tutta una serie di coprocessori specializzati in determinate funzioni ( encoding/decoding video, machine learning, etc. ). Cosa che i secondi non hanno, rendendoli meno complessi rispetto alle soluzioni Apple.

Oh si che ne ha fatte... basti pensare all'imperante design sottiletta dei suoi Mac Intel dal 2010/2012 in poi.

Non credo bisogni confrontare i processori ‘Apple silicon’ con i top di gamma Intel, ma con i processori Intel che vanno a sostituire. A fine anno si dice uscirà un mabbook pro arm. Si spera sia più veloce del MacBook Pro do pari fascia che sostituisce, ma non credo potrà competere con gli Xeon nel Mac Pro. La transizione durerà due anni, ed è tra due anni che potremo aspettarci processori che comperano con i top di gamma Intel. Per il momento però vedremo processori che molto probabilmente stracceranno i processori Intel attualmente usati nei portatili Apple.

E' ancora inferiore, visti i limiti termini entro cui deve stare. Parliamo di 9W per l'i3 contro i max 4W ( tipici di questi SoC mobile ) dell'A12Z.
Gli Arm hanno sempre TDP inferiori agli x86 essendo pensati per dispositivi mobili quindi non so che senso abbia un confronto tra TDP.



Limiti tecnici non ce ne sono. Ci sono SoC ARM per server con 64-128 core che competono senza difficoltà. Tant'è ( notizia di qualche settimana fa ) che un supercomputer ARM è arrivato in testa alla top500.
Sì ma anche per x86 non ci sono limiti tecnici e la stragrandemaggioranza dei supercomputer gira su x86. Inoltre su alcuni server e supercomputer a volte si privilegiano i consumi dove Arm ovviamente vince.
E' da vedere chi migliorerà di più nei prossimi anni. Anche negli anni 90 i PowerPC avevano una architettura più moderna e prestante poi però gli x86 prevalsero per vari fattori. Certo, oggi la situazione con Apple Silicon è diversa ma il fatto è che le prestazioni non dipendono solo dalla bontà di una architettura ma da vari fattori.


Poi, non per idolatrarli, ma Apple ha mai fatto cazzate? Li si può accusare di tutto, tranne che essere degli incompetenti. Penso sappiano benissimo di non potersi permettere il lusso di vendere computer ARM che abbiano una frazione della potenza di quelli x86.
Scusa ma dove hai vissuto negli ultimi anni? Parliamo dei Mac Pro portaombrelli? Di problemi di thermal throttling su vari modelli? Delle tastiere degli ultimi macbook? Dell'antennagate dell'iPhone 4? Del batterygate degli iPhone? Etc. etc. Tutte le aziende fanno cazzate. Alla Apple non sono incompetenti. In colossi come Apple, MS, Google etc. non mancano le persone capaci né i soldi per assumerne altre. Il problema è che Apple a volte ha sacrificato la qualità dei prodotti sull'altare del design (come gli esempi sopra) o per motivi commerciali.


beh pure contro Windows x86 non è così difficile :D
Dipende. Ci sono programmi che girano più velocemente su MacOS x86 mentre altri sono più veloci su Windows x86. Le prestazioni di un computer non dipendono solo dalle prestazioni dell'OS in sè (e comunque non sempre MacOS è più veloce) ma anche dal supporto hardware e software dei produttori che su Windows è di solito migliore. Ci sono programmi che vengono portati su MacOS a malapena causa piccola quota di mercato di MacOS e che non vengono quindi ottimizzati perché antieconomico. Anni fa lessi una recensione secondo cui i giochi su MacOS erano almeno un 30% più lenti rispetto a Windows probabilmente perché su MacOS c'è poco interesse a ottimizzarli nonostante sia anche più facile dato che gira su poche configurazioni hardware e solo su cpu Intel. Simile per certi programmi professionali. Vedi anche flash player che era lento su Windows ma su Mac era ancora più lento. Altro discorso invece i programmi molto usati su Mac come quelli di elaborazione grafica/video dove i Mac sono molto usati.
Insomma la questione è complessa.

Possono raccontare quello che vogliono, ma il confronto secondo me va fatto prezzo prestazioni sul panorama generale. Non è che mi metti un i3 infimo (e me lo fai stra pagare) e poi lo paragoni con una Arm e dici "beh va meglio, è una svolta storica". La svolta storica sarebbe proporre un Mac book pro 13 powered by arm che a parità di prezzo stracciasse o quantomeno potesse competere con un Asus g14 con un amd 4900 hs e una rtx2060. Il resto sono chiacchiere

A me al di là della potenza bruta, interessa conoscere COSA si potrà far girare.
Se non vi sarà particolare interesse a ricompilare tutto per ARM, si rischia di avere un bel prodotto... che però rimarrà solo a fare polvere...
Quoto. Bisogna che Apple sia brava a convincere gli sviluppatori a passare su Arm. La difficoltà potrebbe esserci per quei programmi per cui già ora c'è poco interesse per fare un porting su MacOS nonostante usino le stesse cpu x86 di Windows. E non sempre basta schiacciare un tasto di ricompilazione per fare un buon porting di qualità.
Quello che non ho ancora capito è se il passaggio ad Apple Silicono è dovuta solo a motivi tecnici oppure se ci sono anche motivi commerciali/marketing.

Non credo bisogni confrontare i processori ‘Apple silicon’ con i top di gamma Intel, ma con i processori Intel che vanno a sostituire. A fine anno si dice uscirà un mabbook pro arm. Si spera sia più veloce del MacBook Pro do pari fascia che sostituisce, ma non credo potrà competere con gli Xeon nel Mac Pro. La transizione durerà due anni, ed è tra due anni che potremo aspettarci processori che comperano con i top di gamma Intel. Per il momento però vedremo processori che molto probabilmente stracceranno i processori Intel attualmente usati nei portatili Apple.
Sono d'accordo che sui Mac base gli Apple Silicon competeranno con gli x86 perché gli A12 sono delle gran belle cpu. Il dubbio rimane sulla fascia alta anche perché pure gli Intel miglioreranno tra due anni, soprattutto ora che si è riaccesa la competizione con la rinata AMD. Forse stiamo per vivere un nuovo "fine anni novanta" tra Intel e AMD?

ammetto la pigrizia di cercare piu' informazioni, ma di fatto di cosa stiamo parlando esattamente, sono performances paragonabili a quale cpu x86 desktop?

Quello che non ho ancora capito è se il passaggio ad Apple Silicono è dovuta solo a motivi tecnici oppure se ci sono anche motivi commerciali/marketing.


entrambi
immagino che vorranno sfruttare la maggiore efficienza energetica per avere una linea di portatili nuova, che potrebbe avere una durata di batteria molto superiore agli attuali o un form factor diverso essendo fanless

dal punto di vista tecnico il discorso sta in piedi, architettura unica su tutta la linea e possibilità di far girare le applicazioni ovunque con adattamenti minimi o addirittura in modo del tutto trasparente (app iOS che gireranno as is sul Mac ARM)
mettiamoci anche il discorso puramente economico, non sappiamo che prezzi adotteranno ma oggi le CPU Intel le pagano, non quanto le paghiamo noi il singolo pezzo ma non sono gratis
non è nemmeno a costo zero adattare un SoC di iPad per il Mac, ma buona parte del R&D è condiviso e inoltre si sganciano completamente dalla roadmap di un'azienda esterna

è chiaro che non ci sono zero rischi perché se gli sviluppatori non seguono Apple e c'è carenza di sw riscritto per ARM non basterà Rosetta, che va bene ma non darà mai le prestazioni di una CPU Intel ovviamente
secondo me è un momento giusto per prendersi un rischio del genere, primo perché sono pieni di soldi e secondo perché il Mac non è la loro fonte principale di guadagno, per cui se perdono per strada qualche utente pro (cosa direi certa) e non recuperano sul consumer, non è una tragedia
se invece le sw house seguono Apple e riscrivono per ARM diventa una scommessa vinta e sono altri soldi a palate

A me al di là della potenza bruta, interessa conoscere COSA si potrà far girare.
Se non vi sarà particolare interesse a ricompilare tutto per ARM, si rischia di avere un bel prodotto... che però rimarrà solo a fare polvere...

Be', devi tenere in considerazione che Apple ha già strumenti che facilitano il porting delle app di che girano correntemente sul mobile, per cui la base di partenza, con qualche milione di app, è già potenzialmente enorme. Ovviamente non sarà una cosa automatica ma se la piattaforma diventa un minimo interessante è possibile che si sviluppi, come è stato per il mobile, un circolo virtuoso per cui più app ci sono e più sviluppatori ci si buttano, con la differenza che in questo caso non partono da zero.
Apple se la deve giocare bene, ma potrebbe anche darsi che sia uno sgambetto mica male al desktop: sarà interessante vedere come si sviluppano le cose.

Non vedo per quale motivo non debba essere possibile per Apple fare un processore desktop competitivo, come prestazioni in single core ci siamo, anche considerato che già un A13 dovrebbe avere circa un 20% di prestazioni in più, poi potrebbero tirare di più sul clock, per quanto riguarda il multicore alla fine il limite è principalmente dettato dal consumo e dalla dimensione del die, come dimensione del die un A13 dovrebbe essere un pò sotto i 100mm^2, un ice lake quad core dovrebbe essere sui 120mm^2 di soc + 50mm^2 di pch, quindi non dovrebbe essere problematico per Apple aggiungere altri core.
Come efficienza energetica penso ci siano pochi dubbi che gli Apple silicon siano messi molto bene rispetto agli x86.
Resta un po' il dubbio su quanto apple voglia investire per sviluppare un processore tutto sommato di nicchia nella sua offerta di prodotti (ad esempio sviluppando un processore a chiplet per migliorare le rese di produzione), a meno che non riescano a fare una cpu con prestazioni velocistiche assolute migliori rispetto agli x86, e quindi puntando a guadagnare quote di mercato negli ambiti in cui la potenza è un fattore critico, tipo rendering, dove attualmente non hanno un vero valore aggiunto dovendo usare gli stessi processori dei pc

Be', devi tenere in considerazione che Apple ha già strumenti che facilitano il porting delle app di che girano correntemente sul mobile, per cui la base di partenza, con qualche milione di app, è già potenzialmente enorme. Ovviamente non sarà una cosa automatica

ti correggo: è automatica
i Mac ARM (non gli Intel) faranno girare app iOS scaricandole dallo store
lo sviluppatore non dovrà fare niente, a patto che l'app sia compatibile (ad esempio non deve dipendere da sensori che ci sono su iPhone ma non sul Mac) ma potrà rifiutare di rendere disponibile la sua app sul Mac

se invece vuoi avere la tua app anche sui Mac Intel, devi usare Catalyst e creare esplicitamente una versione macOS, cosa che molti non faranno per disinteresse/pigrizia/altri motivi

mmm io una cosa che non capisco (da Analista programmatore poi è un pò brutto :D almeno è in ambiti diversi... usiamo questa scusa :D)

Che tipo di linguaggio viene usato per fare le app sul Mac? Sempre Swift dell'iOS oppure un altro tipo di linguaggio?

Perchè se è un linguaggio ad alto livello, quindi con istruzioni classiche, perchè devo cambiare il codice, quando sarà il compilatore della CPU adeguata a compilare nel codice a basso livello che gli serve?

Immagino che ci saranno delle istruzioni che vengono usate sulle app per MacOS specifiche per Intel e quindi vanno cambiate queste per la nuova CPU Apple?

L'emulazione via Rosetta2 pesa... basta andarsi a vedere i risultati dei vari test soprattutto quelli che usano le istruzioni SSE2, SSE4 e la famiglia AVX. Il Pay off nei confronti di ARM è più che sensibile.

Dipende da quali set d'istruzione supporta la CPU target. Penso a Neon, ma nel mondo ARM la variabilità è enorme.


I SoC Apple Silicon sono differenti dalle CPU/SoC ARM per server/supercomputer.

Sono pure diversi dai SoC ARM che aderiscono strettamente all'IP di ARM. Anzi i SoC per server e hpc sono più aderenti all'originale.


Intorno ai Core della CPU Apple ha inserito tutta una serie di coprocessori specializzati in determinate funzioni ( encoding/decoding video, machine learning, etc. ). Cosa che i secondi non hanno, rendendoli meno complessi rispetto alle soluzioni Apple.


Apple ha fatto di tutto. Introdotto la superscalarità quando nel mondo ARM non era praticamente usata. Allungato e allargato le pipeline. E Dio solo sa che altro hanno combinato. Fatto sta che un SoC ARM della Apple è un processore che implementa l'ISA ARM e poco più.


Oh si che ne ha fatte... basti pensare all'imperante design sottiletta dei suoi Mac Intel dal 2010/2012 in poi.

Ragione che forse li ha spinti ad allontanarsi da x86.

mmm io una cosa che non capisco (da Analista programmatore poi è un pò brutto :D almeno è in ambiti diversi... usiamo questa scusa :D)

Che tipo di linguaggio viene usato per fare le app sul Mac? Sempre Swift dell'iOS oppure un altro tipo di linguaggio?

Perchè se è un linguaggio ad alto livello, quindi con istruzioni classiche, perchè devo cambiare il codice, quando sarà il compilatore della CPU adeguata a compilare nel codice a basso livello che gli serve?

Immagino che ci saranno delle istruzioni che vengono usate sulle app per MacOS specifiche per Intel e quindi vanno cambiate queste per la nuova CPU Apple?

diciamo pure vari linguaggi

ad esempio su iOS usi Swift o Objective-C, ma puoi benissimo tirare dentro una libreria che è stata fatta in C e compilata per x86 e ARM
su macOS stessa roba, hai AppKit come framework sempre Objective-C o Swift come linguaggio ma anche altro
il problema ce l'hai più che altro se la tua app tira dentro una libreria di cui tu possiedi solo la versione x86 e non hai i sorgenti
se non puoi procurartela in versione ARM, ti attacchi (o usi Rosetta in questo caso)
poi c'è anche chi scrive più a basso livello e usa istruzioni particolari che ci sono sugli x86 e che non hai su ARM (o se c'è roba simile, è comunque un'altra istruzione)

chiaro che le classiche utility che fai in Xcode (tipo app che faresti su iOS) si portano in un attimo, ricompili e sei a posto, ma non sarà così per tutti ed è probabile che le app più ottimizzate siano proprio quelle per i professionisti, che sono i più colpiti da transizioni come questa
per il mercato consumer, ovvero il classico utente da navigazione web, utility, mail, office cambia niente, si troverà già tutto compilato ARM e quello che girerà in Rosetta non sarà certo "mission critical" per cui non si accorgerà nemmeno che va in emulazione

diciamo pure vari linguaggi

ad esempio su iOS usi Swift o Objective-C, ma puoi benissimo tirare dentro una libreria che è stata fatta in C e compilata per x86 e ARM
su macOS stessa roba, hai AppKit come framework sempre Objective-C o Swift come linguaggio ma anche altro
il problema ce l'hai più che altro se la tua app tira dentro una libreria di cui tu possiedi solo la versione x86 e non hai i sorgenti
se non puoi procurartela in versione ARM, ti attacchi (o usi Rosetta in questo caso)
poi c'è anche chi scrive più a basso livello e usa istruzioni particolari che ci sono sugli x86 e che non hai su ARM (o se c'è roba simile, è comunque un'altra istruzione)

chiaro che le classiche utility che fai in Xcode (tipo app che faresti su iOS) si portano in un attimo, ricompili e sei a posto, ma non sarà così per tutti

ah ok... si infatti cosi mi torna tutto :) grazie ;)

Gli Arm hanno sempre TDP inferiori agli x86 essendo pensati per dispositivi mobili quindi non so che senso abbia un confronto tra TDP.


I SoC ARM per mobile sono così. Ma i SoC ARM per server ha TDP molto molto più alti.

Per esempio questi arrivano a 35W http://linuxgizmos.com/fanless-edge-server-has-24-core-arm-soc-and-3-tops-per-watt-npu/


Sì ma anche per x86 non ci sono limiti tecnici


Questo non impedisce ad Apple di passare ad ARM.


Inoltre su alcuni server e supercomputer a volte si privilegiano i consumi dove Arm ovviamente vince.


Non è strettamente così. Cdimauro tempo fa pubblicò un'analisi dell'ISA x86, con tutti il suo bagaglio legacy, e la conclusione era che non solo quel bagaglio non pesava sul chip e relativi consumi, ma che nemmeno rendeva più complicato o inefficienti il design di questi chip.

Bisogna capire che gli x86 non sono x86. Sono CPU che implementano tutt'altro, con sopra tanti bei microprogrammi che implementano l'ISA x86.

Un tempo la differenza tra ARM e x86 si giocava sui processi produttivi. I SoC ARM hanno sempre privilegiati processi produttivi obsoleti, per risparmiare. Ma oggi non è più questo il caso. Ce la vedi Apple risparmiare sulle fonderie?


Anche negli anni 90 i PowerPC avevano una architettura più moderna e prestante poi però gli x86 prevalsero per vari fattori.


Ci sono pure fattori commerciali, giochini al limite della legge, ecc... Sappiamo come vanno queste cose.

I Power ( non i PowerPC ) ancora oggi hanno un'architettura mostruosa, che riesce a competere senza sforzo con x86.


Certo, oggi la situazione con Apple Silicon è diversa ma il fatto è che le prestazioni non dipendono solo dalla bontà di una architettura ma da vari fattori.


I processori sono complessi, ovvio che ci siamo migliaia di variabili in gioco. Ma il punto rimane, ovvero che ARM non è sinonimo di processore per lavatrici o orologi da polso. ARM è anche sinonimo di server, hpc, ecc... Il fatto che l'azienda abbia, per ragioni commerciali, operato per quasi 40 anni nei soli settori "di nicchia", non vuol dire che i suoi design non scalano. Anzi, si è dimostrato che scalano eccome.


Scusa ma dove hai vissuto negli ultimi anni? Parliamo dei Mac Pro portaombrelli? Di problemi di thermal throttling su vari modelli? Delle tastiere degli ultimi macbook? Dell'antennagate dell'iPhone 4? Del batterygate degli iPhone?

Certo, problemi dovuti a carenti procedure di QA. Quello che sta succedendo a tutti ormai. Sembra che i prodotti nemmeno li testino.

Ma sulle scelte strategiche, non mi pare che Apple abbia sbagliato. Il MacPro, poi, è proprio l'esempio lampante del perchè Apple ha bisogno di allontanarsi da x86. Il sistema di raffredamento fa schifo, ma è quello che si può ottenere con quel design. Ci vorrebbe una CPU che produca meno calore, cosa che Apple potrà fare con le sue CPU in-house.



Dipende. Ci sono programmi che girano più velocemente su MacOS x86 mentre altri sono più veloci su Windows x86.


Parlo di benchmark. In genere Linux > macOS > Windows in molti benchmark. Con l'eccezione dei giochi ovviamente.


ma anche dal supporto hardware e software dei produttori che su Windows è di solito migliore.


In realtà il supporto di terze parti è migliori su macOS. Le schermate blu di Windows non sono rare. Molto più rari i panic su macOS.


Ci sono programmi che vengono portati su MacOS a malapena causa piccola quota di mercato di MacOS e che non vengono quindi ottimizzati perché antieconomico.


I software più famosi sono ottimizzati e sicuramente non semplicemente portati su macOS. Adobe, Autodesk e compagnia non vendono prodotti inferiori su macOS, perchè sanno che buona parte della loro utenza professionale, si trova lì.


Anni fa lessi una recensione secondo cui i giochi su MacOS erano almeno un 30% più lenti rispetto a Windows probabilmente perché su MacOS c'è poco interesse a ottimizzarli


30% è un'esagerazione. E poi parliamo di giochi. Per i software professionali, la musica è totalmente diversa.

ti correggo: è automatica
i Mac ARM (non gli Intel) faranno girare app iOS scaricandole dallo store
lo sviluppatore non dovrà fare niente, a patto che l'app sia compatibile (ad esempio non deve dipendere da sensori che ci sono su iPhone ma non sul Mac) ma potrà rifiutare di rendere disponibile la sua app sul Mac


In realtà pensavo all'ottimizzazione per il desktop: anche se l'app gira così com'è, immagino scenari in cui sarà necessario fare cambiamenti anche rilevanti per adattarne l'usabilità.

In realtà pensavo all'ottimizzazione per il desktop: anche se l'app gira così com'è, immagino scenari in cui sarà necessario fare cambiamenti anche rilevanti per adattarne l'usabilità.

sì, quelli si fanno in Catalyst, ma è comunque una soluzione "ibrida" oppure si scrive direttamente l'app in SwiftUI che è il nuovo framework presentato nel 2019
il vantaggio di SwiftUI è che tu usi sempre lo stesso componente (tipo date picker, dropdown ecc.), che però su iOS si vede in un modo e su macOS viene diverso, adatto all'interazione con il mouse e tastiera e non solo touch
poi chiaro avrai delle finestre dell'app che vorrai scrivere diversamente per il mac ma quello ci sta
siamo solo agli albori, settimana scorsa hanno presentato un po' di novità che non ho ancora visto nel dettaglio e penso che nel giro di un altro paio d'anni sarà abbastanza maturo per essere usato in produzione multi piattaforma, mentre ad oggi se avessi un'app esistente iPad userei senza dubbio Catalyst per portarla sul Mac
ad oggi nessuno me lo ha chiesto e comunque non è così automatico che un cliente con iPad abbia anche il Mac, se ha Windows sono fregato comunque... :D

diciamo che Catalyst è la soluzione a breve termine, SwiftUI da qui a qualche anno sarà il modo per scrivere app che andranno bene su tutte le piattaforme Apple (compreso Watch) con le dovute eccezioni, nel senso che c'è chi continuerà ad usare AppKit e fare cose custom ma lo sviluppatore indie e la sw house piccola sicuramente staranno su SwiftUI e non escludo componenti Web, che non significa farsi l'app Electron ma proprio avere delle parti di UI rappresentate da web view, cosa che fa Apple stessa

Stiamo veramente confrontando un pc small form factor con un tablet/laptop ibrido?

Il Mac Mini non ha gli stessi problemi di dissipazione di un tablet e per di più non ha particolari vincoli in termini di consumo energetico.

A questo punto confrontiamo il Mac Mini con un pc da stesso form factor e vediamo chi vince.

Dipende da quali set d'istruzione supporta la CPU target. Penso a Neon, ma nel mondo ARM la variabilità è enorme.



Sono pure diversi dai SoC ARM che aderiscono strettamente all'IP di ARM. Anzi i SoC per server e hpc sono più aderenti all'originale.



Apple ha fatto di tutto. Introdotto la superscalarità quando nel mondo ARM non era praticamente usata. Allungato e allargato le pipeline. E Dio solo sa che altro hanno combinato. Fatto sta che un SoC ARM della Apple è un processore che implementa l'ISA ARM e poco più.



Ragione che forse li ha spinti ad allontanarsi da x86.

Infatti non è detto a priori che la tecnologia Apple Silicon possa scalare in maniera lineare senza intoppi ( penso i SoC per desktop e per i futuri MacBook Pro top di gamma ). Dimostrazione è data dal fatto che Rosetta2 in macOS 11 sfrutta solamente i 4 core Vortex ad alte prestazioni e non anche gli altri 4 ad alta efficienza Tempest.

I SoC ARM per mobile sono così. Ma i SoC ARM per server ha TDP molto molto più alti.
Sì ma tu prima parlavi di soc mobile i3 vs A12.


Questo non impedisce ad Apple di passare ad ARM.
Ovvio.



Non è strettamente così. Cdimauro tempo fa pubblicò un'analisi dell'ISA x86, con tutti il suo bagaglio legacy, e la conclusione era che non solo quel bagaglio non pesava sul chip e relativi consumi, ma che nemmeno rendeva più complicato o inefficienti il design di questi chip.

Bisogna capire che gli x86 non sono x86. Sono CPU che implementano tutt'altro, con sopra tanti bei microprogrammi che implementano l'ISA x86.
Va bene ma resta il fatto che gli Arm di solito consumano meno. Che poi sia per un motivo o l'altro non importa. Magari poi gli Apple Silicon per Mac Pro consumeranno come gli x86 o meno. Solo il tempo ce lo dirà.



Ci sono pure fattori commerciali, giochini al limite della legge, ecc... Sappiamo come vanno queste cose.
Gli unici motivi è che la competizione sfrenata tra Intel e AMD dalla fine degli anni novanta ha spinto molto i miglioramenti negli x86 e pure l'abbassamento dei prezzi. E l'enorme economia di scala e i grandi investimenti di cui godevano gli x86 grazie alla loro quota di mercato che arrivò anche al 95% nel mondo desktop/portatili.
I PowerPC invece non hanno potuto usufruire di questi aiuti.



I processori sono complessi, ovvio che ci siamo migliaia di variabili in gioco. Ma il punto rimane, ovvero che ARM non è sinonimo di processore per lavatrici o orologi da polso. ARM è anche sinonimo di server, hpc, ecc... Il fatto che l'azienda abbia, per ragioni commerciali, operato per quasi 40 anni nei soli settori "di nicchia", non vuol dire che i suoi design non scalano. Anzi, si è dimostrato che scalano eccome.
D'accordo, mai pensato che siano cpu inferiori. Ci mancherebbe.



Certo, problemi dovuti a carenti procedure di QA. Quello che sta succedendo a tutti ormai. Sembra che i prodotti nemmeno li testino.
Non scherziamo. Il QA non c'entra nulla. Gli esempi riportati riguardavano errori di progettazione, anche grossolani, di Apple dovuti a scelte sbagliate per privilegiare design, estetica e manie varie come quelle degli spessori.
Di cazzate dovute a scelte errate per motivi di design, estetica, fanboysmo, manie varie che cozzano contro le leggi dell'ingegneria è pieno il mondo. E non solo nell'informatica. Basta vedere cosa fanno certi architetti in nome dell'estetica...


Ma sulle scelte strategiche, non mi pare che Apple abbia sbagliato. Il MacPro, poi, è proprio l'esempio lampante del perchè Apple ha bisogno di allontanarsi da x86. Il sistema di raffredamento fa schifo, ma è quello che si può ottenere con quel design. Ci vorrebbe una CPU che produca meno calore, cosa che Apple potrà fare con le sue CPU in-house.
Appunto: è un problema di design. Infatti in workstation di altri produttori non c'erano questi problemi. E la stessa Apple negli ultimi Mac Pro è tornata a un design più classico.
Puoi metterci anche delle cpu Arm che scaldano metà ma se poi per manie di design ci metti un dissipatore che è la metà e sei punto e a capo allora di chi è la colpa? Di Intel no di sicuro...




Parlo di benchmark. In genere Linux > macOS > Windows in molti benchmark. Con l'eccezione dei giochi ovviamente.
Anch'io parlavo di benchmark. In genere Linux è più veloce in programmi più da server e workstation, mentre Windows in programmi più da desktop come i browser web o in programmi che sfruttano driver ottimizzati.
Linux è di per sé più veloce ma il Windows gode di un miglior supporto dei produttori hardware e software. Ovviamente parlo solo del mondo desktop. Server e supercomputer sono un altro mondo.
Comunque i risultati sono molto vari anche se Linux è mediamente più veloce e se ne potrebbe discutere per ore anche perché di Linux esistono mille distribuzioni. Ma qui si va OT quindi lasciamo perdere.



In realtà il supporto di terze parti è migliori su macOS. Le schermate blu di Windows non sono rare. Molto più rari i panic su macOS.
Non so così intendi tu per "supporto di terze parti" ma il supporto di produttori hardware e software è migliore su Windows dato che quest'ultimo ha quote di mercato molto maggiori di MacOS.
A volte le schermate blu dipendono solo dall'OS. Per esempio su Windows 7 erano rarissime mentre su W10 più frequenti. Su XP poi era peggio. E su W95/98/Me lasciamo perdere... Considera anche che con le poche configurazioni hardware che hanno i Mac è molto più facile testare l'OS e i programmi a differenza di Windows e Linux dove le configurazioni sono infinite.



I software più famosi sono ottimizzati e sicuramente non semplicemente portati su macOS. Adobe, Autodesk e compagnia non vendono prodotti inferiori su macOS, perchè sanno che buona parte della loro utenza professionale, si trova lì.
Appunto, quelli più famosi. Ma ci sono molti software professionali e non che a malapena vengono portati su Mac x86 quindi non ci si può aspettare che un'azienda spenda mesi per ottimizzarlo per benino se poi è antieconomico perché non ne vende abbastanza. Se invece fa un porting in fretta e furia allora può diventare profittevole. Dipende molto dal tipo di software e da quanto a basso livello si deve andare.
Per esempio anche Autodesk non fa il porting di tutte le sue applicazioni per Mac.



30% è un'esagerazione. E poi parliamo di giochi. Per i software professionali, la musica è totalmente diversa.
Non ho mai fatto test personali perché non mi interessa ma non vedo perché dovrebbe essere un'esagerazione. Sui giochi il 95% degli utenti usa Windows (statistiche Steam). Di sicuro i programmatori non si fanno il mazzo per ottimizzare una valanga di righe di codice per MacOS che ha un mercato così piccolo. Il porting da DirectX a OpenGL/Vulkan non penso sia immediato.
Per i software professionali probabilmente è simile ma molto dipende dal tipo. Quelli usati molto su Mac (grafica/video/audio) sono sicuramente ben ottimizzati. Su quelli meno usati (come quelli ingegneristici) e molto complessi e magari poco costosi ho dei dubbi.

Stiamo veramente confrontando un pc small form factor con un tablet/laptop ibrido?

Il Mac Mini non ha gli stessi problemi di dissipazione di un tablet e per di più non ha particolari vincoli in termini di consumo energetico.

A questo punto confrontiamo il Mac Mini con un pc da stesso form factor e vediamo chi vince.
Anche questa sui form factor è una giusta considerazione.

Alla fine è un confronto più da click-bait che altro. E infatti noi abbiamo cliccato e pure commentato! :muro:

Infatti non è detto a priori che la tecnologia Apple Silicon possa scalare in maniera lineare senza intoppi ( penso i SoC per desktop e per i futuri MacBook Pro top di gamma ). Dimostrazione è data dal fatto che Rosetta2 in macOS 11 sfrutta solamente i 4 core Vortex ad alte prestazioni e non anche gli altri 4 ad alta efficienza Tempest.

Tutto questo si vedrà poi. Noi non sappiamo che processore sta sviluppando Apple. Si sta ragionando completamente alla cieca.

I 4 core "little" Tempest come sono fatti? Che c'è dentro? Perchè Rosetta non li usa? Non li può usare? Ci sono altre ragioni? Boh!

Sì ma tu prima parlavi di soc mobile i3 vs A12.


Mobile nel senso di smartphone e tablet. Gli i3-1000NG4 non fanno parte di questa categoria.


Va bene ma resta il fatto che gli Arm di solito consumano meno.


Quelli in commercio sono prodotti per consumare di meno. Ma in quanto ad istruzioni/watt non c'è chissà che differenza https://en.wikipedia.org/wiki/Performance_per_watt


Che poi sia per un motivo o l'altro non importa. Magari poi gli Apple Silicon per Mac Pro consumeranno come gli x86 o meno. Solo il tempo ce lo dirà.


E questo dipende da Apple. Perchè se c'è un vantaggio di ARM, è il potere includere arbitrariamente ogni sorta di coprocessore o unità di calcolo che si ripeti utile, nel SoC. Intel è molto rigida su questo punto. Cioè prendi quello che loro ti danno, tranne per alcuni modelli che sono "parzialmente personalizzabili".


I PowerPC invece non hanno potuto usufruire di questi aiuti.


IBM non era e non è interessata a produrre per vendere. PowerPC divenne presto abandonware.




Gli esempi riportati riguardavano errori di progettazione, anche grossolani, di Apple dovuti a scelte sbagliate per privilegiare design, estetica e manie varie come quelle degli spessori.

Appunto. Se li avessero testati, si sarebbero rotti nei loro laboratori. E non credo che avrebbero deciso di venderli lo stesso.

Ovviamente Apple non rinuncerà all'estetica. Mettiamoci l'anima in pace. E può essere questa una delle regioni dell'abbandono di x86.


Puoi metterci anche delle cpu Arm che scaldano metà ma se poi per manie di design ci metti un dissipatore che è la metà e sei punto e a capo allora di chi è la colpa? Di Intel no di sicuro...

Ma in quel caso tutto sarebbe progettato per funzionare, magari a costo di sacrificare le prestazioni per una migliore estetica. Sempre che non assemblino pezzi a casaccio. Ma non penso.



In genere Linux è più veloce in programmi più da server e workstation, mentre Windows in programmi più da desktop come i browser web o in programmi che sfruttano driver ottimizzati.

E nemmeno. Su Phoronix ci sono parecchi benchmark e Linux la spunta molte volte. Solo con le ultime versioni di Windows 10 si vede una ripresa di Windows.

Sui filesystem, il confronto continua ad essere impietoso.


Linux è di per sé più veloce ma il Windows gode di un miglior supporto dei produttori hardware e software.


Dipende dal settore. Se vai nel mondo embedded, è difficile trovare un supporto Windows decente.



Non so così intendi tu per "supporto di terze parti" ma il supporto di produttori hardware e software è migliore su Windows dato che quest'ultimo ha quote di mercato molto maggiori di MacOS.

Come quantità di software. Ma i software professionali e meno professionali, sono perfettamente ottimizzati su macOS.


A volte le schermate blu dipendono solo dall'OS. Per esempio su Windows 7 erano rarissime mentre su W10 più frequenti.


Boh. A leggere certi fan, le schermate blu sono sempre colpa di driver buggati. Onestamente non sono più nel giro Windows da un bel pò di anni.



Ma ci sono molti software professionali e non che a malapena vengono portati su Mac


Laddove non conviene economicamente, non li portano. Per quelli dove conviene, è la stessa Apple ad offrire supporto, anche finanziario se necessario.


x86 quindi non ci si può aspettare che un'azienda spenda mesi per ottimizzarlo per benino se poi è antieconomico perché non ne vende abbastanza.


Ed è quello che vuole Apple. Chi vuole stare nel suo ecosistema, deve lavorare per bene, non portare software per altre piattaforme.


Di sicuro i programmatori non si fanno il mazzo per ottimizzare una valanga di righe di codice per MacOS


Ma i giochi risentono poco dell'implementazione della piattaforma. Per questo dicevo che quel 30% è il caso peggiore e raro.

Il gioco fa il lavoro pesante su GPU. Lontano dal sistema operativo.

Il porting di molti giochi semplicemente non c'è, proprio perchè non immediato da Direct3D ad OpenGL. Su Vulkan si vedrà. Potrebbe far rinunciare a Direct3D pure su Windows.

Gli altri giochi si appoggiano semplicemente al supporto OpenGL offerto dai relativi motori grafici. E ovviamente fanno poco sforzo. Producendo inefficienze, ma comunque inferiori al 30%, che è tantissimo.

Ricordo che ARM (e parzialmente anche AMD) al contrario di Intel non ha tutti i core "uguali", cosa che permette, ottimizzando, di ottenere risultati superiori, ma che, senza ottimizzazione, sfrutti molto peggio. Una cosa simile, immagino, sia quello che è avvenuto con rosetta2, non tutti i core hanno le "funzionalità" necessarie

Non so se ricordate che tempo fa con AMD si ottenevano risultati disastrosi su win fino a un aggiornamento che migliorava l'utilizzo dei core "diversificati"

Tutto questo si vedrà poi. Noi non sappiamo che processore sta sviluppando Apple. Si sta ragionando completamente alla cieca.

I 4 core "little" Tempest come sono fatti? Che c'è dentro? Perchè Rosetta non li usa? Non li può usare? Ci sono altre ragioni? Boh!

Rosetta non li usa, almeno nel far girare Geekbench 5, semplicemente perchè non soddisfano il carico di lavoro richiesto. I core Tempest, rispetto ai Vortex, non hanno unità per le istruzioni vettoriali e la loro architettura è derivata da quella del SoC A6 aggiornata ai 64 bit.
In questo articolo una analisi del core Tempest del SoC A12:
https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-review-unveiling-the-silicon-secrets/5

Forse in molti ancora non si rendono conto della portata dell'annuncio e dei risvolti nei prossimi anni. La resilienza e la strategia portata avanti negli anni da Apple ha veramente dell'invidiabile.. Sono partiti oltre 10 anni fa, ed ora sono in grado di realizzarsi tantissimi sistemi e sottosistemi in casa completamente custom fino ad approdare nel mac. Non a caso il primo chip mobile a 64bit è arrivato prima degli altri in iPhone, e gia anni fa la stessa azienda parlava di "Desktop class architecture".
Questo mac mini monta un chip da oltre 10 miliardi di transistor (A12X è stato presentato con questi numeri), vedremo i primi chip a 5nm pensati per Mac. Intel ha perso molto in termini di immagine..E' ferma al palo da anni..
Intel è rimasta bloccata dai problemi col suo nuovo processo produttivo.

Apple non ha fonderie, e si rivolge a terzi. E se un processo va male per una fonderia, si può rivolgere a un'altra.
Va bene che l'A12 è un gran bel chip e che Geekbench girava in emulazione però confrontarlo con un misero Intel Core i3-1000NG4 dual core non ha molto senso. Un top di gamma Arm va confrontato con un top di gamma x86 altrimenti non si capisce niente di quale sia la piattaforma migliore.
A parte questo, Geekbench è un benchmark sintetico ed è pura spazzatura, come amo ripetere da anni.

I test andrebbero fatto con un bouquet di applicazioni, e nelle stesse condizioni (senza usare appositi acceleratori hardware: il codice dovrebbe girare soltanto nei core del processore).
Poi, non per idolatrarli, ma Apple ha mai fatto cazzate?
Parecchie. Ti dice nulla l'Apple III? Ed è soltanto un esempio.
Li si può accusare di tutto, tranne che essere degli incompetenti.
Lo sono anche stati. MacOS era ottimizzato da cani, ad esempio, e ci sono vecchi articoli di ArsTechnica dove hanno anche misurato le prestazioni delle API grafiche, che a un certo punto Apple decise finalmente a ottimizzare, e la differenza con la versione precedente del s.o. erano scandalose.

Anche qui, è un esempio.
Penso sappiano benissimo di non potersi permettere il lusso di vendere computer ARM che abbiano una frazione della potenza di quelli x86.
A loro interessa avere tutto fatto in casa in primis, controllando ogni singolo dettaglio, e risparmiando sui costi.

Le prestazioni sono e saranno buone (hanno il miglior core ARM, e gli altri possono soltanto imparare da loro), ed eccellenti in rapporto ai consumi (e siccome vendono dispositivi mobile...).
Non è strettamente così. Cdimauro tempo fa pubblicò un'analisi dell'ISA x86, con tutti il suo bagaglio legacy, e la conclusione era che non solo quel bagaglio non pesava sul chip e relativi consumi, ma che nemmeno rendeva più complicato o inefficienti il design di questi chip.
Il discorso è un po' più complicato, perché ho scritto un articolo (il più vecchio) su prestazioni e consumi, e ben 9 riguardo al legacy, per cui sintetizzare qui i risultati è difficile (e poi devo correre a lavoro).

Diciamo che più i core sono piccoli, e più il legacy di x86 si fa sentire. Più transistor si usano, e meno il legacy si fa sentire.
Questo perché la parte legacy rimane sostanzialmente costante da tanti anni, per cui ha un costo fisso sia sui transistor impiegati sia su prestazioni e consumi.
Ci sono pure fattori commerciali, giochini al limite della legge, ecc... Sappiamo come vanno queste cose.
Niente giochi: Intel è sorvegliata speciale dalle autorità antitrust.
I Power ( non i PowerPC ) ancora oggi hanno un'architettura mostruosa, che riesce a competere senza sforzo con x86.
Assolutamente no, e i test di Phoronix sono impietosi.
I processori sono complessi, ovvio che ci siamo migliaia di variabili in gioco. Ma il punto rimane, ovvero che ARM non è sinonimo di processore per lavatrici o orologi da polso. ARM è anche sinonimo di server, hpc, ecc... Il fatto che l'azienda abbia, per ragioni commerciali, operato per quasi 40 anni nei soli settori "di nicchia", non vuol dire che i suoi design non scalano. Anzi, si è dimostrato che scalano eccome.
Assolutamente vero.
Certo, problemi dovuti a carenti procedure di QA. Quello che sta succedendo a tutti ormai. Sembra che i prodotti nemmeno li testino.
Non è affatto un problema di QA, ma di cattiva progettazione.
Parlo di benchmark. In genere Linux > macOS > Windows in molti benchmark. Con l'eccezione dei giochi ovviamente.
MacOS X dovrebbe essere quello messo peggio. Ha sempre avuto prestazioni inferiori, in media, a causa dell'impiego del micro kernel + kernel classico.

Difatti a livello server è durato un po' di anni, e poi è sparito.
In realtà il supporto di terze parti è migliori su macOS. Le schermate blu di Windows non sono rare. Molto più rari i panic su macOS.
Windows deve girare su miliardi di configurazioni...

Quelli in commercio sono prodotti per consumare di meno. Ma in quanto ad istruzioni/watt non c'è chissà che differenza https://en.wikipedia.org/wiki/Performance_per_watt

Aehm! Se fai attenzione ai dati performance/watt del 2019 nel link che hai fornito, si vede che IL PROTOTIPO di Fugaku (basato solo su CPU A64FX e non ancora nella versione definitiva)
sta "leggermente avanti" ad altri supercomputer basati su architetture ibride con CPU Xeon oppure Power insieme a GPU Nvidia oppure con acceleratori many-core PEZY-SC.

In altre parole se il confronto fosse CPU contro CPU sia Xeon che PowerPC ne uscirebbero con le ossa rotte (le GPU sono estremamente efficienti in termini di performance/watt ).
Gli A64FX sono dei veri mostri e sono solo le prime CPU di fascia alta basate su Aarch64+SVE.

Gli A64FX sono dei veri mostri e sono solo le prime CPU di fascia alta basate su Aarch64+SVE.

Non avendo dati precisi su quel computer, ho estrapolato da qui https://www.cray.com/sites/default/files/resources/Cray-CS500-Brochure.pdf

Come si nota, il CS500 esiste anche con CPU Intel e AMD e può montare vari acceleratori di Nvidia.

Praticamente ho supposto che pure quel supercomputer sia equipaggiato con un certo numero di GPU Nvidia.

Chiaro che senza sapere esattamente che c'è dentro, si può solo supporre grossolanamente.

Poi ci sono vari benchmark che sono stati fatti da quando ARM ha fatto il boot con gli smartphone e il vantaggio in termini di performance/watt non è tanto superiore ad x86.

L'incognita è sempre il numero e la tipologia dei coprocessori che possono finire in un SoC ARM. Flessibilità che nè Intel nè AMD ti danno.

E sappiamo che non c'è niente al mondo che batta hardware specializzato sia come prestazioni brute che performance/watt.

Non avendo dati precisi su quel computer, ho estrapolato da qui https://www.cray.com/sites/default/files/resources/Cray-CS500-Brochure.pdf

Come si nota, il CS500 esiste anche con CPU Intel e AMD e può montare vari acceleratori di Nvidia.

Praticamente ho supposto che pure quel supercomputer sia equipaggiato con un certo numero di GPU Nvidia.

Chiaro che senza sapere esattamente che c'è dentro, si può solo supporre grossolanamente.

Poi ci sono vari benchmark che sono stati fatti da quando ARM ha fatto il boot con gli smartphone e il vantaggio in termini di performance/watt non è tanto superiore ad x86.

L'incognita è sempre il numero e la tipologia dei coprocessori che possono finire in un SoC ARM. Flessibilità che nè Intel nè AMD ti danno.

E sappiamo che non c'è niente al mondo che batta hardware specializzato sia come prestazioni brute che performance/watt.
Nel tempo anche nei processori x86 sono state implementate in hardware molte istruzioni per velocizzare diversi tipi di calcoli...
È tutto ancora da vedere ed è bene che qualcosa di nuovo si muova, che poi a noi consumatori cosa ci importa se nel PC del 2030 ci sarà un arm o un x86 o se ci sarà Windows o Linux, quello che conta è che vadano bene per quello che dobbiamo fare...

Non avendo dati precisi su quel computer, ho estrapolato da qui https://www.cray.com/sites/default/files/resources/Cray-CS500-Brochure.pdf

Come si nota, il CS500 esiste anche con CPU Intel e AMD e può montare vari acceleratori di Nvidia.

Praticamente ho supposto che pure quel supercomputer sia equipaggiato con un certo numero di GPU Nvidia.

Chiaro che senza sapere esattamente che c'è dentro, si può solo supporre grossolanamente.

Poi ci sono vari benchmark che sono stati fatti da quando ARM ha fatto il boot con gli smartphone e il vantaggio in termini di performance/watt non è tanto superiore ad x86.

L'incognita è sempre il numero e la tipologia dei coprocessori che possono finire in un SoC ARM. Flessibilità che nè Intel nè AMD ti danno.

E sappiamo che non c'è niente al mondo che batta hardware specializzato sia come prestazioni brute che performance/watt.

D'altronde, il motivo per cui Apple ha deciso di percorrere questa strada è questo. Ha i soldi e il know-how per realizzare SoC ARM per farci ciò che vuole. Noi qui stiamo ancora a pensare a fare il confronto tra quale core sia più potente, cosa del tutto irrilevante.

Ricordiamo anche che x86 è come Windows: deve mantenere la retrocompatibilità per far girare software scritto magari 30 anni fa. Quindi si va di estensioni e reingegnerizzazioni della micro-architettura. Ricordiamo che gli stessi 64 bit sono un'estensione introdotta da AMD. E che Itanium fu affossato anche perché l'emulazione di x86 faceva pena.

Insomma, la veritá è che finché Apple non presenterá qualcosa di concreto, nessuno potrá davvero sapere fin dove si possa arrivare.

Nel tempo anche nei processori x86 sono state implementate in hardware molte istruzioni per velocizzare diversi tipi di calcoli...
È tutto ancora da vedere ed è bene che qualcosa di nuovo si muova, che poi a noi consumatori cosa ci importa se nel PC del 2030 ci sarà un arm o un x86 o se ci sarà Windows o Linux, quello che conta è che vadano bene per quello che dobbiamo fare...

Le AVX sono state introdotte un casino di tempo fa, eppure per anni i software non le hanno sfruttate. Che poi è il secondo dei problemi: puoi estendere e aggiungere istruzioni, ma poi i software vanno ricompilati (quando basta) con le opzioni per sfruttarle.

Le AVX sono state introdotte un casino di tempo fa, eppure per anni i software non le hanno sfruttate. Che poi è il secondo dei problemi: puoi estendere e aggiungere istruzioni, ma poi i software vanno ricompilati (quando basta) con le opzioni per sfruttarle.

Certo e passare a processori completamente diversi è ancora più complicato.

Certo e passare a processori completamente diversi è ancora più complicato.

Dipende da cosa devi portare. Diciamoci la veritá. Oggi la maggior parte dei nuovi software è un accrocchio scritto in JavaScript che gira su Chrome. Mentre il software professionale verrá portato senza problemi perché le risorse non mancano.

Ad Apple, inoltre, nessuno chiede la compatibilitá con il gestionale del supermercato scritto in BASIC 40 anni fa.

D'altronde, il motivo per cui Apple ha deciso di percorrere questa strada è questo. Ha i soldi e il know-how per realizzare SoC ARM per farci ciò che vuole.


E visto l'andazzo, le prime cose che vedremo nei SoC Apple, saranno unità neurali e fpga.


E che Itanium fu affossato anche perché l'emulazione di x86 faceva pena.


E' simpatico quando un'azienda distrugge un suo prodotto. Itanium era uno di quei progetti, che avrebbero potuto cambiare il futuro del computing. Ma furono affossati da quello che è stato il fulcro della strategia Intel, ovvero la retrocompatibilità. Unita ad un lavoro moscio sui compilatori. Che saranno più complicati per le architetture VLIW, ma non sono impossibili da realizzare.

E visto l'andazzo, le prime cose che vedremo nei SoC Apple, saranno unità neurali e fpga.

Esattamente.


E' simpatico quando un'azienda distrugge un suo prodotto. Itanium era uno di quei progetti, che avrebbero potuto cambiare il futuro del computing. Ma furono affossati da quello che è stato il fulcro della strategia Intel, ovvero la retrocompatibilità. Unita ad un lavoro moscio sui compilatori. Che saranno più complicati per le architetture VLIW, ma non sono impossibili da realizzare.

È così anche per Microsoft con Windows. Infatti ancora si vuole Win32 perché, altrimenti, apriti cielo.

I compilatori sono il meno. Se la tua CPU deve comunque far girare software scritto per x86 e non riadattabile (per n motivi) anche se ti chiami Intel non puoi far molto. Infatti aggiunsero una sorta di emulazione in hardware ma, ripeto, non è che fosse una scheggia...

Aehm! Se fai attenzione ai dati performance/watt del 2019 nel link che hai fornito, si vede che IL PROTOTIPO di Fugaku (basato solo su CPU A64FX e non ancora nella versione definitiva)
sta "leggermente avanti" ad altri supercomputer basati su architetture ibride con CPU Xeon oppure Power insieme a GPU Nvidia oppure con acceleratori many-core PEZY-SC.

In altre parole se il confronto fosse CPU contro CPU sia Xeon che PowerPC ne uscirebbero con le ossa rotte (le GPU sono estremamente efficienti in termini di performance/watt ).
Gli A64FX sono dei veri mostri e sono solo le prime CPU di fascia alta basate su Aarch64+SVE.
Mancano i risultati di benchmark "standard" su applicazioni comuni e di vario genere...
L'incognita è sempre il numero e la tipologia dei coprocessori che possono finire in un SoC ARM. Flessibilità che nè Intel nè AMD ti danno.
Non è corretto: possono farlo anche loro.

Intel ha pure sviluppato un core x86 sintetico per Rockchip...
E sappiamo che non c'è niente al mondo che batta hardware specializzato sia come prestazioni brute che performance/watt.
Esattamente.
E visto l'andazzo, le prime cose che vedremo nei SoC Apple, saranno unità neurali e fpga.
Che Intel ha già introdotto da tempo (in particolare le FPGA, che erano presenti in alcuni Xeon già da prima che acquisisse Altera).
E' simpatico quando un'azienda distrugge un suo prodotto. Itanium era uno di quei progetti, che avrebbero potuto cambiare il futuro del computing. Ma furono affossati da quello che è stato il fulcro della strategia Intel, ovvero la retrocompatibilità.
Quindi non è Intel che l'ha affossato, ma il mercato che ha deciso di rimanere sul vecchio legacy.

Intel ha provato almeno 3 volte (iAPX, 80860, Itanium) a togliere di mezzo x86, ma non c'è riuscita a causa dell'enorme base di software che è stato scritto per quest'ultimo.
Unita ad un lavoro moscio sui compilatori.
Qui l'hai veramente sparata grossa. E' da anni che Intel sviluppa fra i migliori compilatori C/C++ e Fortran al mondo, per cui le conoscenze per realizzarne uno in grado di ottimizzare al meglio possibile per Itanium le aveva tutte, e le ha usate. Tant'è che Itanium è arrivato ad avere le migliori prestazioni floating point al mondo, che erano importanti in ambito server/HPC; il problema erano le prestazioni "intere", e qui non puoi farci proprio niente con un'architettura VLIW.

Il mio primo manager che ho avuto alla Intel è stato un ingegnere che ha lavorato per anni al compilatore Intel e proprio per Itanium, e nelle nostre lunghe discussioni (è l'unico manager con un mostruoso background tecnico col quale potevo parlare di certi argomenti) abbiamo toccato anche il tema, ovviamente. Intel non si è affatto risparmiata sul compilatore (cosa confermata da qualche altro collega che c'ha lavorato anche lui), com'era lecito aspettarsi. Punto.

Tra l'altro il mio manager era convinto che Itanium fosse una buona soluzione, ma lì le nostre opinioni erano divergenti (non ho mai amato le architetture VLIW perché non sono general-purpose e hanno problemi con tanto codice che non può girarci bene).
Che saranno più complicati per le architetture VLIW, ma non sono impossibili da realizzare.
Spiegami allora come mai i VLIW non hanno mai preso piede in tutti questi anni, anche soltanto a livello interno (micro-architetturale)...
I compilatori sono il meno. Se la tua CPU deve comunque far girare software scritto per x86 e non riadattabile (per n motivi) anche se ti chiami Intel non puoi far molto. Infatti aggiunsero una sorta di emulazione in hardware ma, ripeto, non è che fosse una scheggia...
L'emulazione x86 implementata in hardware su Itanium faceva pena, tanto che successivamente fu sostituita da una software che funzionava molto meglio.

Mancano i risultati di benchmark "standard" su applicazioni comuni e di vario genere...

Tipo quelli descritti qui (https://spectrum.ieee.org/tech-talk/computing/hardware/japans-fugaku-supercomputer-is-first-in-the-world-to-simultaneously-top-all-high-performance-benchmarks) ?


Intel ha pure sviluppato un core x86 sintetico per Rockchip...


Quello degli Atom X3, ma poi è andato in produzione ? Mi ricordo che era stato annunciato per degli smartphone ma poi non so che fine abbia fatto.


Intel ha provato almeno 3 volte (iAPX, 80860, Itanium) a togliere di mezzo x86, ma non c'è riuscita a causa dell'enorme base di software che è stato scritto per quest'ultimo.

A causa dell'enorme base di software DIFFICILE DA PORTARE SU ALTRE ARCHITETTURE (ora le cose sono un tantino cambiate) e sopratutto per errori madornali fatti da Intel (nel caso di iAPX32 ed i80860) e per la concorrenza di AMD (nel caso di Itanium).

Mi ricordo benissimo come nel 1995 quando iniziarono ad uscire le prime notizie ufficiali su Itanium (inizialmente "architettura EPIC") sembrava che avrebbe spaccato il mondo.
Poi quando uscì la prima generazione nel 2001 (Merced) emersero tutte le magagne su cui Intel "aveva posto poca enfasi".

Nonostante questo, Itanium ce l'avrebbe potuta fare se Intel avesse limitato gli x86 ai 32bit e se la fosse presa con calma nello spingerli a livello di prestazioni (e c'era pure riuscita ampiamente con i Pentium 4 di prima generazione).

Invece proprio in quegli anni AMD infilo una doppietta con il K7 (Athlon, Duron) a 32bit che la riportò in competizione a livello di prestazioni, seguito dal K8 (Opteron, Athlon64, Phenom, ecc.) che introdusse pure un set d'istruzioni a 64bit "decente" (aumento del numero di registri interi, ecc. ecc.).

Intel negli anni ha cambiato versione, ma mi ricordo benissimo che inizialmente veniva spinta l'idea che la cpu a 64bit di Intel era solo l'Itanium mentre gli x86 non sarebbero andati oltre i 32bit.

Non a caso quando Intel se ne uscì con i suoi "x86 a 64bit" (set d'istruzioni EMT64) inizialmente era intenzionata ad uscire con qualcosa compatibile con gli x86 a 32bit ma "molto diverso da x86-64", poi circolarono voci che fu pressata da Microsoft nel non fare caXXate e restare compatibile con lo "standard x86-64" fissato da AMD, in ogni caso si nota che nella prima implementazione di EMT64 varie cose erano "limitate a 32bit" (tipo il dover usare i bounce buffers perchè sugli Intel si potevano eseguire trasferimenti in DMA solo nei primi 4GB di spazio di indirizzamento, alcune istruzioni non supportate in modalità a 64bit ecc.).

C'e' comunque da dire che Itanium ha aiutato Intel a far fuori un sacco di concorrenti nella fascia alta :Perfido: (HP PA-RISC, DEC/Compaq Alpha, MIPS "da server" di Silicon Graphics), Itanium in origine era "il successore di PA-RISC" che HP traghetto' ad Intel :mano: quando si rese conto che da sola non aveva le risorse per svilupparlo, Alpha fu di fatto "rimosso dal mercato" quando Compaq (che aveva acquisito quel che restava di DEC) fu assorbita da HP :banned: , Silicon Graphics a quel punto decise di puntare su Itanium perchè a sua volta non aveva le risorse per fronteggiare HP+Intel e decise di unirsi a loro :vicini: .

Tipo quelli descritti qui (https://spectrum.ieee.org/tech-talk/computing/hardware/japans-fugaku-supercomputer-is-first-in-the-world-to-simultaneously-top-all-high-performance-benchmarks) ?
Dal tuo link:
"It earned the top spot with an extraordinary performance of 415 Linpack petaflops.
[...]
Fugaku beat the competition in the High Performance Conjugate Gradients (HPCG) benchmark used to test real-world application performance; the Graph500, a rating for data-intensive loads; and HPL-AI, a benchmark for rating artificial-intelligence workloads"
Quindi direi proprio di no: si tratta sempre di ambiti specifici / HPC.
Quello degli Atom X3, ma poi è andato in produzione ? Mi ricordo che era stato annunciato per degli smartphone ma poi non so che fine abbia fatto.
No, non è andato in produzione: è stato cassato causa ritiro di Intel dal settore mobile.
A causa dell'enorme base di software DIFFICILE DA PORTARE SU ALTRE ARCHITETTURE
Questo non è affatto vero. :cool:
(ora le cose sono un tantino cambiate)
Ti riferisci al fatto che c'è più supporto per altre architetture?
e sopratutto per errori madornali fatti da Intel (nel caso di iAPX32 ed i80860)
iAPX32 era un mostro su cui Intel aveva basato molto riguardo allo sviluppo dei linguaggi OOP.

Questi sono stati i suoi due problemi: un progetto troppo grande (se non ricordo male fu necessario realizzare 3 chip), e soprattutto specializzato in un ambito che ha richiesto tanti anni per cominciare ad avere una solida base d'utenza (e applicazioni).

Ma per l'i80860, invece, quali errori avrebbe commesso? Perché quel processore era un gioiello. Infatti non a caso è stato poi utilizzato in diverse schede grafiche professionali come acceleratore grafico.
e per la concorrenza di AMD (nel caso di Itanium).
Esattamente.
Mi ricordo benissimo come nel 1995 quando iniziarono ad uscire le prime notizie ufficiali su Itanium (inizialmente "architettura EPIC") sembrava che avrebbe spaccato il mondo.
Poi quando uscì la prima generazione nel 2001 (Merced) emersero tutte le magagne su cui Intel "aveva posto poca enfasi".
Non solo Intel: anche HP aveva riposto troppa fiducia nel modello EPIC (che è un VLIW), ma questa macro-famiglia di architetture non è adatta a scopi general purpose, e nessun compilatore al mondo avrebbe potuto fare miracoli (specialmente nei confronti dell'esecuzione out-of-order).
Nonostante questo, Itanium ce l'avrebbe potuta fare se Intel avesse limitato gli x86 ai 32bit
Veramente è proprio quello che ha provato a fare. Infatti Itanium era l'architettura a 64 bit Intel, e non c'era futuro nei IA-32/x86 nei suoi piani di lungo termine.

Intel è stata costretta ad abbracciare x86-64/x64 a causa del successo di questa, unita a tutti i problemi di Itanium. Continuare coi suoi piani l'avrebbe sicuramente affossata.
e se la fosse presa con calma nello spingerli a livello di prestazioni (e c'era pure riuscita ampiamente con i Pentium 4 di prima generazione).
Non poteva, causa concorrenza di AMD, per l'appunto.
Invece proprio in quegli anni AMD infilo una doppietta con il K7 (Athlon, Duron) a 32bit che la riportò in competizione a livello di prestazioni, seguito dal K8 (Opteron, Athlon64, Phenom, ecc.) che introdusse pure un set d'istruzioni a 64bit "decente" (aumento del numero di registri interi, ecc. ecc.).
No, per favore: almeno il "decente" a x86-64/x64 evitalo. Si tratta di un'orribile pezza a IA-32/x86, che ha soltanto peggiorato frontend e backend del processore, aumentando i problemi di quest'ISA.

x86-64 è stato realizzato in fretta e furia (visto che Itanium incalzava), e con l'obiettivo di ridurre al minimo le modifiche a IA-32 per ottenere un'ISA a 64 bit. Infatti la sua implementazione richiedeva soltanto il 5% in più di transistor (rispetto a un'Athlon dell'epoca).
Intel negli anni ha cambiato versione, ma mi ricordo benissimo che inizialmente veniva spinta l'idea che la cpu a 64bit di Intel era solo l'Itanium mentre gli x86 non sarebbero andati oltre i 32bit.
Esattamente.
Non a caso quando Intel se ne uscì con i suoi "x86 a 64bit" (set d'istruzioni EMT64) inizialmente era intenzionata ad uscire con qualcosa compatibile con gli x86 a 32bit ma "molto diverso da x86-64",
Mi pare che il progetto dell'estensione a 64 bit di Intel a IA-32/x86 si chiamasse Yahmill, o qualcosa del genere.
poi circolarono voci che fu pressata da Microsoft nel non fare caXXate e restare compatibile con lo "standard x86-64" fissato da AMD,
Sì, queste erano le voci.
in ogni caso si nota che nella prima implementazione di EMT64 varie cose erano "limitate a 32bit" (tipo il dover usare i bounce buffers perchè sugli Intel si potevano eseguire trasferimenti in DMA solo nei primi 4GB di spazio di indirizzamento, alcune istruzioni non supportate in modalità a 64bit ecc.).
Già. Era la prima implementazione, e anche questa realizzata in fretta e furia per contrastare AMD.
C'e' comunque da dire che Itanium ha aiutato Intel a far fuori un sacco di concorrenti nella fascia alta :Perfido: (HP PA-RISC, DEC/Compaq Alpha, MIPS "da server" di Silicon Graphics), Itanium in origine era "il successore di PA-RISC" che HP traghetto' ad Intel :mano: quando si rese conto che da sola non aveva le risorse per svilupparlo, Alpha fu di fatto "rimosso dal mercato" quando Compaq (che aveva acquisito quel che restava di DEC) fu assorbita da HP :banned: , Silicon Graphics a quel punto decise di puntare su Itanium perchè a sua volta non aveva le risorse per fronteggiare HP+Intel e decise di unirsi a loro :vicini: .
Sì, esatto.

Non so come sara' il futuro se ARM o no, ma a "ieri" direi che i "watt x86/64" come dimensione di potenza bruta erano ancora vincenti nel mondo reale. Con diverse SBC provate, prendendo un qualsiasi Athlon 64 X2 ma perche' no' anche uno degli ultimi Pentium 4 Prescott con DDR2/3 a livello di singole core e tralasciando benchmark sintetici, la percezione di potenza bruta pare venire sempre dal processore che "consuma" di piu' e che ad oggi sarebbe da discarica se paragonato a quelli moderni. Per dire, non e' che gli altri staranno a guardare il proprio mondo sgretolarsi.
Poi il concetto del minor consumo di energia vale appunto fin tanto che non ci si compete direttamente con i top di gamma perche' se per farlo si arrivasse ipoteticamente anche a consumare il 70% delle alternative classiche, beh ci saranno pur anche lati negativi o l'unica giustificazione sara' quel 30% di energia salvata?
Poi come gia' pensavo in passato, il problema oggigiorno e' forse piu' il codice e il peso dei singoli software totalmente "incomprensibile" se confrontato con lo scopo del software stesso che non la palma di chi e' piu' potente sulla carta.

Dimentichi che da parecchi anni ormai ci sono sistemi di gestione del consumo energetico integrati nei processori, per cui i consumi sono di gran lunga più ridotti rispetto ai processori del passato che invece andavano a pieno regime anche quando erano senza far nulla (idle) o con bassissimi carichi di lavoro.

Dimentichi che da parecchi anni ormai ci sono sistemi di gestione del consumo energetico integrati nei processori, per cui i consumi sono di gran lunga più ridotti rispetto ai processori del passato che invece andavano a pieno regime anche quando erano senza far nulla (idle) o con bassissimi carichi di lavoro.
Certamente, dall' Athlon XP che praticamente consumava sempre il suo quasi massimo assorbimento se ne e' fatta strada e infatti spezzo una lancia a favore delle molte innovazioni successive sebbene la riduzione (non ho esperienze di cpu moderne veramente tipo post AM3) sia sempre piuttosto limitata non come "delta" ma come valore minimo. (tra l'altro non ho mai capito come mai disegnarono l'Athlon in quel modo.. il K62+/3+ e il Geode avevano gia' sistemi di controllo di frequenza/voltaggi in tempo reale... non capisco perche' non vennero integrati sul massacrante (per la linea +5V del PSU) XP fino al 3200+ processore che piegherebbe ai suoi piedi molte PSU moderne.. :p )
Ma comunque preferisco i dispositivi "desktop" se parliamo di prodotti consumer, non oso inoltrarmi nel discorso server/workstation non conosco bene, ancora preferisco appunto una vecchia macchina che macina watt come i vecchi trattori del secolo scorso, rispetto a soluzioni che poi a conti fatti sono interessanti e potenti ma sempre per quel che consumano. Per dire, gli Atom come si disse gia' altre volte non e' che consumavano poi' cosi' tanto di piu' e se confrontiamo le espandibilita' di una qualsiasi mini-itx sia hardware che software con una qualsiasi SBC, preferisco l' Atom. Non a caso e' il mio computer primario. 5W di cpu, 2W di gpu integrata, forse altre 7W tra assorbimenti vari PSU, chipset, disco e periferiche usb.. ma SSD di qualsiasi tipo, DDR3, volendo un blue-ray sata, qualsiasi o.s. possibile da win a linux.. ;)
In piu' sono riuscito anche finalmente a vedere quanto "potente" era quella "famosa" gpu GMA3600/SGX545 forzando i pochi drivers disponibili.. :D

Il problema con gli Atom (quelli vecchi in particolare) è che... apri una pagina web e piangi (nell'attesa)...

Il problema con gli Atom (quelli vecchi in particolare) è che... apri una pagina web e piangi (nell'attesa)...

Ricordo che l'esperienza con l' N270 e successivamente l'N450 non fu poi male, certo erano altri tempi e il web stesso non era "piu' pesante del gioco Crysis" come sembra essere adesso. Ma devo dire che soluzioni successive come i Cedarview N2x00 a 32nm mi hanno ben stupito pur con le dovute premesse. Erano x64, ci gira Windows 8.1 e con un po' di fortuna si riesce a far funzionare anche la GPU, se no su Linux si sceglie una gui LXDE/LXQT con X renderer (non Opengl) e disabilitando l'accelerazione grafica nel browser imho il dual core piu' l' SSSE3, l'SSD e i 4GB di DDR3 riescono a rendere una magari non velocissima ma accettabilissima esperienza web.
Video Youtube a 480p, solo qualche inpuntamento con troppa pubblicita' o javascript ma qui si ritorna al discorso iniziale, le cpu devono compensare l'andazzo preso dal software moderno? E' possibile che un gioco appunto 3D sia piu' leggero di una pagina web? O che un software di text processing debba pesare come se fosse un CAD? E quest'ultimo non immagino quanto sia pesante a sua volta?

Per quei tempi gli Atom andavano benissimo. Purtroppo se cerchi di usarli oggi, pur con tutte le accortezze del caso, coi moderni browser e Javascript ti fanno venire il latte alle ginocchia... :mad:

Per quei tempi gli Atom andavano benissimo. Purtroppo se cerchi di usarli oggi, pur con tutte le accortezze del caso, coi moderni browser e Javascript ti fanno venire il latte alle ginocchia... :mad:

Eh gia', ricordo bene ho perfino nostalgia dell' Asus 1005PE che gran netbook che era comprai nuovo ed era stupendo sia esteticamente che come girava.
Oggigiorno chissa' come andrebbe anche se sarei curioso di vedere con Linux e LXDE se qualche speranza la darebbe.
Certo gli Atom D2x00 erano un'altro mondo e molte generazioni dopo. In piu' DDR3, perfino con SSSE3 e dual core che credo facesse la differenza maggiore qui.
Poi certo non fa miracoli ma per essere gli ultimi Atom di vecchia generazione (prima di quelli da tablet o PC stick) sono ancora accettabili.
Se ci si installa Windows 7 32bit o Windows 8.x 32bit la gpu non dovrebbe essere un problema anche se con quest'ultimo si possono notare rarissimi crash imho dovuti proprio ai drivers non nati per questo o.s. Pero' gi ho fatto girare perfino 3DMark2005, non certo un bench leggero e frame rate a parte del tutto compatibile graficamente. A suo tempo ero quasi curioso di installarci una vga tipo GT610 in PCI e vedere come girasse. :)
Comunque come dicevi i primi invece sono invecchiati male. Comunque tempo fa provai un Athlon XP 3200+ con SSD e una vga DX10 con linux e sebbene qualsiasi pagina web caricava la cpu al 100% con l'aiuto del rendering Opengl per lo scrolling devo dire che il risultato non fu poi cosi' malvagio (mancanza di SSE2 a parte). Quasi quasi si riusciva ad arrivare in alcuni video Youtube forse H264 a 720p quasi.. peccato che poi parti' la scheda madre che meritava perche' aveva le porte SATA (KT600).

Infatti su queste vecchie macchine è meglio metterci qualche s.o. leggero e senza tanti fronzoli. Per me l'ideale è AROS.

Infatti su queste vecchie macchine è meglio metterci qualche s.o. leggero e senza tanti fronzoli. Per me l'ideale è AROS.

Mi sono sempre trovato bene in questi anni con Linux per la variegata scelta di app preinstallate e di GUI diversificate e LXDE era c'ertamente la mia preferita per leggerezza su cpu e memoria e senza bisogno di chissa' quale pixel shading o assurdità simili per disegnare GUI che su Windows 3.1 giravano bene su una Cirrus Logic GD542x che avevano gia' l'accelerazione BitBLT 25 anni fa.
Perfino un Pentium III puo' far girare una versione piuttosto aggiornata del kernel linux se con la giusta configurazione a prescindere dal web e dalla sua usabilita' (che comunque ram permettendo prima o dopo la pagina la renderizza anch'esso :p).
Poi certo il limite resta il web che fa rimpiangere i tempi e l'hardware dei modem 56K per quanto sembrassero leggeri allora seppur con i limiti analogici di quei tempi rispetto ad oggi.

Il limite di queste distro "light" è che purtroppo stanno passando tutte a 64 bit, e già solo per questo non sono più tanto leggere né a livello di storage né di risorse utilizzate.
Visto che l'obiettivo è la leggerezza, avrebbe dovuto mantenere almeno le versioni a 32 bit. Non foss'altro per coerenza.
Invece con questa mossa ormai stanno tagliando fuori tante piattaforme che potrebbero ancora essere utilizzate...

Gia', di recente ho notato che le compilazioni dei nuovi kernel a 32bit non vengono piu' fatte a parte aggiornamenti di versioni precedenti. E' davvero un peccato perche' sebbene anche linux imho sia diventato pesantuccio anch'esso (ora non so se uno si compila il proprio specifico kernel con i soli moduli necessari etc..) almeno si compensa con tutto il resto, GUI leggere, software solo indispensabili e comunque gratuiti anche quando impressionanti come capacita' (Audacity per l'audio, GIMP per l'editing di immagini etc..per non parlare di Wine per far partire applicazioni o giochi (almeno quelli vecchi).
E' vero che se si guarda alle prime cpu 64bit si va indietro di piu' di una decade e forse capisco anche il concetto che prima o dopo qualcosa vada lasciato indietro ma la potenza bruta non mancava. Per dire, un Pentium4 Northwood a 3,2Ghz su DDR1 sarebbe ancora capace di dire la sua imho forse meno di un 775 Prescott a maggior frequenza, ma i muscoli per un pc "d'emergenza" in assenza di config moderne ce li avrebbe ancora, l'esempio del trattore stile scorso secolo calza bene. :p