Link alla notizia: https://www.hwupgrade.it/news/apple/wwdc-2020-con-macos-big-sur-arriva-la-transizione-verso-arm-con-i-soc-apple-silicon_90290.html

Una nuova versione di macOS, Big Sur, prepara il terreno alla quarta major transition della storia della Mela: arriva l'era dei Mac con processori Apple Silicon

Click sul link per visualizzare la notizia.

Dove sono gli increduli di una settimana fa??

Comunque sono rimasto sbalordito dalle prestazioni di A12X. Sono contento di questa transizione

Ammetto che un po' rosico, il prossimo portatile lo vorrei fanless e i processori Apple dovrebbero essere una bella bestiolina in quello scenario di utilizzo, sono curioso di vedere i benchmark dei prossimi portatili, e la transizione dovrebbe essere molto più rapida rispetto a Windows on ARM, se Apple decide di migrare architettura i produttori di software sanno che si dovranno adeguare, e gli utenti possono comprarlo fiduciosi di non avere una macchina che potrebbe non venire mai supportata a dovere, come nel caso di un portatile con Snapdragon e Windows. Anche la possibilità di avere le app dell'ecosistema iOS non mi sembra affatto da buttare, Windows in questo (app "moderne" ) mi sembra stia un po' arrancando, secondo me se Apple abbassasse un po' i prezzi puntando sui ricavi dai servizi e dall'app store potrebbe guadagnare considerevoli quote di mercato a danno dei pc.
Mi pare che Apple pesasse sul fatturato di Intel per tipo il 5%, non così tanto, però resta un segnale abbastanza significativo, TMSC dovrebbe aver superato Intel come capitalizzazione, come fatturato arriva solo alla metà ma ha attività meno diversificate quindi dovrebbe aver maggior capacità di investire nello sviluppo dei processi, e nel prossimo futuro l'equilibrio dovrebbe spostarsi ulteriormente a suo favore tra la mossa di Apple e la ritrovata competitività di AMD, quindi sarà interessante vedere se Intel riuscirà a recuperare il terreno perso, o il ritardo nel processo produttivo diventerà fisiologico
(mi rendo conto che sembra un post che si presta a generare flames, specifico che non ho intenzione di comprare un prodotto Apple, non mi piace la chiusura, e che ho un PC con processore Intel, sono solo considerazioni libere dopo aver visto la WWDC)

Dove sono gli increduli di una settimana fa??

Comunque sono rimasto sbalordito dalle prestazioni di A12X. Sono contento di questa transizione

Concordo. Quell’A12Z sembrava davvero comportarsi mooolto bene, considerando che è ancora tutto in beta.
Impressionante anche Rosetta 2.

il funzionamento di applicazioni intel-based su sistemi con Apple Silicon sarà gestito tramite Rosetta 2 che si occuperà di tradurre l'applicazione al momento dell'installazione oppure, dove serve, effettuare traduzioni in tempo reale
Come fa Rosetta 2 a tradurre l'applicazione al momento dell'installazione? Ma con che tipo di applicazione e con che compromessi?

Il grafico mi sembra un po' ottimistico. Gli Apple Silicon dovrebbero avere prestazioni da x86-desktop e contemporaneamente consumi da x86-notebook?
Comunque vedremo.

Pazzesco, sarebbe bello saperne di più sul funzionamento di Rosetta
Le app iOS eseguibili su mac poi gran cosa

Ma nessuno ha parlato di bootcamp

Praticamente una rivoluzione. Impressionante che siano riusciti a portare a bordo Microsoft e Adobe dal day 1, e anche le prestazioni raggiungibili in emulazione con Rosetta.

Strana sensazione di dejavú... Non credo in questo passaggio. Felice di ricredermi (ma anche no). Per quanto mi riguarda ho smesso da anni di finanziare Apple e non credo che tornerò mai ad essere un suo cliente. Ps: curioso di vedere le prossime applicazioni per entrambi i sistemi quanto peseranno all'epoca della transizione Intel le app pesavano il doppio ma internet non era diffuso come oggi

Preferisco rimanere in ambito x86... arm potrà non essere male ma quando ci spostiamo da tablet e cellulari per arrivare alle workstation.. altra cosa

Dove sono gli increduli di una settimana fa??

Comunque sono rimasto sbalordito dalle prestazioni di A12X. Sono contento di questa transizione

Eccone uno... Anzi ecco uno scettico convinto su questa transizione di architettura.

Le belle parole di Cook su Apple Silicon, con tutti gli annessi e connessi, nascondono ancora troppe questioni, una tra tutte le prestazioni di queste CPU ( o SoC? ) in senso assoluto. Cook ha parlato solamente di prestazioni per watt, cosa accettabile per prodotti come MacBook Air e MacBook Pro da 13" ( base ), macchine destinate ad un uso molto " casual " da parte degli utenti . Le cose cambiano e parecchio se già si prendono in considerazione i MacBook Pro da 16" dotate di CPU Intel ben carrozzate e di GPU discrete di fascia media.
Idem, senza patate, per i desktop a partire dagli iMac di fascia medio/alta dove il problema dei consumi non si pone affatto e le prestazioni in assoluto diventano dominanti... per non parlare poi dei Mac Pro ( immagino la gioia di chi ha acquistato una di quelle grattugie lasciandoci magari più di 10000 cocuzze e si ritrova già con una macchina svalutata ).
Per Mac di questa categoria ci dovranno essere oltre a delle CPU degne di questo nome anche delle GPU di fascia avanzata, cosa che Apple con i suoi SoC AXX non è in grado di offrire... Certo potrà ricorrere ad AMD per le GPU, ma così sconfesserebbe la sua filosofia del controllo totale del silicio su Mac!

Vedremo che cosa uscirà effettivamente da Cupertino da qui a 24 mesi come prodotti di fascia medio/alta e con quali prestazioni nei confronti di X86, ben sapendo che non è tutto oro ciò che luccica.

tra un annetto si avranno i dati reali su quanto potrà peformare realmente un soc arm pompato da apple rispetto ad una cpu x86 in ambito desktop.
Il rischio grosso é che comunque confrontare i risultati prodotti da software di benchmark tra architetture e OS differenti non é mai affidabile.
La scelta comunque é sensata, cambiando piattaforma hardware si smarcano anche dal confronto diretto con la concorrenza e l'utente medio non dovrà piu' stare a confrontare l'hardware del suo mac con il portatile x della concorrenza che costa 500 euro di meno con piu' ram e piu' disco e poi per usare iMessaggi i memoji, navigare su safari e cambiare tre livelli su lightroom un soc del 2020 svolgerà sicuramente il carico senza problemi.
Hanno ancora una volta inquadrato per bene il loro target di utenza, per i carichi di lavoro seri continueranno probabilmente a proporre i mac pro ( che ormai non compra quasi piu' nessuno) con gli xeon o con le nuove cpu amd.
Curioso di vedere i prezzi dei prossimi portatili con arm.

Intel è ferma da 10 anni, 7 anni di ritardo ormai a passare pp più competitivi.

Un partner troppo lento ormai da un decennio in ambito cpu. Prima o poi l'abbandono di Intel e di x86 sarebbe successo, ma immagino che i catorci sovraprezzati a 14nm+++++++++++ che vende Intel prima o poi sarebbero stati tagliati dal mercato.

In più apple infila nelle sue cpu molte funzionalità ad hoc per ml/ai ed altro che voleva portare su macbook.

Sono molto molto curioso di cosa avverrà e come, non avrebbero fatto questo passaggio se non avessero dati alla mano che confermino che le prestazioni ci sono.

Forse inizierà una rivoluzione per l'ambiente desktop? Vedremo, mai dire mai.

Personalmente sono interessato a vedere cosa succederà, probabilmente vedremo dispositivi da 12 ore e più reali di autonomia ultrasottiletta con batteria tarata per fare quel tanto e non più, Apple come tutti i produttori non è una onlus e da le novità col contagocce, non credo vedremo tutto e subito.

Sui macbook air e pro 13 trovo questa scelta perfetta, sui mac 16 molto meno soprattutto dopo l'ottimo lavoro fatto con l'ultimo 16 che con la rx5600m ha dato un boost mica da ridere.

Sugli imac e soprattutto mac pro non credo che passeranno ad ARM... staremo a vedere, per il momento il mio air mi basta e avanza.

Eccone uno... Anzi ecco uno scettico convinto su questa transizione di architettura.

Le belle parole di Cook su Apple Silicon, con tutti gli annessi e connessi, nascondono ancora troppe questioni, una tra tutte le prestazioni di queste CPU ( o SoC? ) in senso assoluto. Cook ha parlato solamente di prestazioni per watt, cosa accettabile per prodotti come MacBook Air e MacBook Pro da 13" ( base ), macchine destinate ad un uso molto " casual " da parte degli utenti . Le cose cambiano e parecchio se già si prendono in considerazione i MacBook Pro da 16" dotate di CPU Intel ben carrozzate e di GPU discrete di fascia media.
Idem, senza patate, per i desktop a partire dagli iMac di fascia medio/alta dove il problema dei consumi non si pone affatto e le prestazioni in assoluto diventano dominanti... per non parlare poi dei Mac Pro ( immagino la gioia di chi ha acquistato una di quelle grattugie lasciandoci magari più di 10000 cocuzze e si ritrova già con una macchina svalutata ).
Per Mac di questa categoria ci dovranno essere oltre a delle CPU degne di questo nome anche delle GPU di fascia avanzata, cosa che Apple con i suoi SoC AXX non è in grado di offrire... Certo potrà ricorrere ad AMD per le GPU, ma così sconfesserebbe la sua filosofia del controllo totale del silicio su Mac!

Vedremo che cosa uscirà effettivamente da Cupertino da qui a 24 mesi come prodotti di fascia medio/alta e con quali prestazioni nei confronti di X86, ben sapendo che non è tutto oro ciò che luccica.

lungi dal voler essere dimostrazioni esaustive, ma il veder girare photoshop (nativo) e shadow of the tomb raider (emulazione) con quelle performance mi ha sinceramente impressionato.

SE quel che Apple ha mostrato è vero, SE è vero, già oggi con l'APU di iPad si raggiungono prestazioni paragonabili ad un i5 su MBPro.

Non prendete come riferimento i prodotti da smartphone e tablet.

P.s. per me sarebbe perfetto un iPad con MacOS.

( immagino la gioia di chi ha acquistato una di quelle grattugie lasciandoci magari più di 10000 cocuzze e si ritrova già con una macchina svalutata ).
E' chiaro che i mac x86 ormai sono fuori mercato

Vedremo che cosa uscirà effettivamente da Cupertino da qui a 24 mesi come prodotti di fascia medio/alta e con quali prestazioni nei confronti di X86, ben sapendo che non è tutto oro ciò che luccica.
Apple potrebbe anche abbandonare del tutto in fascia pro, già da tempo è una fascia abbastanza snobbata, con pochi prodotti e spesso neanche riuscitissimi ( tipo il portaombrelli )

Praticamente una rivoluzione. Impressionante che siano riusciti a portare a bordo Microsoft e Adobe dal day 1
Adobe e Microsoft sono partner totali di Apple, sono sempre presenti al day 1.
Il problema sono casomai le altre SW house

Concordo. Quell’A12Z sembrava davvero comportarsi mooolto bene, considerando che è ancora tutto in beta.
Impressionante anche Rosetta 2.
Sinceramente le prestazioni sbandierate su applicazioni selezionatissime e preparate appositamente lasciano abbastanza il tempo che trovano.

Non capisco questo entusiasmo per le cpu Apple perché ad ora non si può pensare di competere alla pari con Intel e Amd, con alle spalle decenni di esperienza e know how. E' logico che durante le presentazioni ti facciano vedere che tutto gira benissimo. Per Photoshop, speriamo non faccia la fine della app su iPad, con l'uscita tardata di un anno mi pare.

Dove sono gli increduli di una settimana fa??

Comunque sono rimasto sbalordito dalle prestazioni di A12X. Sono contento di questa transizione

non è detto che tutte le demo fossero con un A12Z comunque... può darsi che il gioco e Maya fossero con un prototipo di A14, impossibile saperlo...
è qualcosa che scopriremo tra pochi giorni comunque dato che il kit verrà spedito agli sviluppatori che potranno farci girare di tutto e daranno dei feedback più affidabili del loro keynote
credo ci saranno più dettagli su Rosetta2 in una delle sessioni di questa settimana dove si parla più nello specifico dei Mac ARM

sinceramente mi aspettavo una transizione un po' più lunga, mentre parlano di soli 2 anni quindi nel 2022 venderanno gli ultimi Mac Intel
comunque hanno garantito rilasci macOS Intel per anni a venire, ma non avevo dubbi a riguardo
certo comprare un Mac Intel il prossimo anno non so quanto valga la pena a questo punto (intendo nuovo a prezzo pieno) però il supporto sarà lungo quindi nessuna fretta di passare alla nuova architettura, almeno per me
tra 4-5 anni quando cambierò il mio vedremo a che punto saranno

SE quel che Apple ha mostrato è vero, SE è vero, già oggi con l'APU di iPad si raggiungono prestazioni paragonabili ad un i5 su MBPro.

Non prendete come riferimento i prodotti da smartphone e tablet.

P.s. per me sarebbe perfetto un iPad con MacOS.

Questa favola la ripeti ad ogni thread su apple e arm.
Di quale prestazioni parli? Come lo confronti un benchmark tra ipad os / arm e mac os / x86? Su quali applicazioni?
Certo che se fai vedere una demo dove il carico é 80% GPU 10% ram e 10% cpu allora pure uno snapdragon mid range puo' sostituire un i7 in certi ambiti specifici.
Il metro di giudizio lo si avrà quando i sw general purpose e quelli da intenso carico di lavoro saranno tutti portati su arm, a quel punto potrai essere certificato o smentito.
La vera differenza la puo' fare effettivamente l'ottimizzazione di un sistema chiuso, ma da qui a colmare il gap con una cpu destktop e workstation x86 ce ne passa.
La dimostrazione ce l'hai nel mondo console, una PS a parità di hardware é un po piu' performante di un pc, ma appena la configurazione sale di livello la differenza di potenza si nota.
In apple non sono certo scemi, sanno perfettamente cosa serve alla loro utenza e sanno perfettamente che quel carico li possono offrirlo con un soc proprietario ottimizzato che gli costa di meno e gli allunga pure la durata della batteria, inoltre non hanno il problema storico di microsoft o di linux di dover gestire decine di configurazioni hardware differenti e di dover garantire tutto lo stack dei driver nativi/proprietari.
Apple gestisce i suoi sistemi dalla linea 0 del firmware fino all'aggiornamento di safari, che se non fai cazzate ti dà certamente un vantaggio prestazionale rispetto ad altre piattaforme, ma non abbastanza per offrire le stesse performances in tutti gli scenari, né ora e né mai.

lungi dal voler essere dimostrazioni esaustive, ma il veder girare photoshop (nativo) e shadow of the tomb raider (emulazione) con quelle performance mi ha sinceramente impressionato.

Photoshop: è stata fatta vedere una immagine post prodotta da 50GB ancora da esportare tramite render definitivo, ovvero è stata fatta vedere solo una parte del workflow e su una sola immagine. Moltiplichiamo il tutto per una decina di immagini filtrate ed esportiamo in blocco in TIFF a max res o in Jpeg ad altissima qualità... ciò non è stato fatto vedere.
Da tenere conto che Photoshop come Lightroom esistono già per iPad ed usano Metal per l'accelerazione video e per qualche filtro.

Anche per quanto riguarda il giochino di Tomb Rider ci sarebbe da approfondire visto che è un porting ottimizzato con Metal di Feral Interactive per MacOS. La risoluzione a cui è stato fatto girare è a 1080p e gli effetti di rendering non erano al top. Insomma un " it just works ".

...
Sinceramente le prestazioni sbandierate su applicazioni selezionatissime e preparate appositamente lasciano abbastanza il tempo che trovano.

tutti avevano "paura" di Office (presentato già nativo), Adobe (presentato Photoshop nativo) e delle attuali applicazioni x86 per Mac (e ne hanno fatte vedere due di norma "pesanti" per CPU/GPU come Maya e un gioco).

per me, se è vero che stava girando su un A12Z con 16GB di RAM, con un OS ancora in beta, con Rosetta 2 ancora in beta, è stato un risultato piuttosto impressionante. :)

non è detto che tutte le demo fossero con un A12Z comunque... può darsi che il gioco e Maya fossero con un prototipo di A14, impossibile saperlo...
è qualcosa che scopriremo tra pochi giorni comunque dato che il kit verrà spedito agli sviluppatori che potranno farci girare di tutto e daranno dei feedback più affidabili del loro keynote
credo ci saranno più dettagli su Rosetta2 in una delle sessioni di questa settimana dove si parla più nello specifico dei Mac ARM

sinceramente mi aspettavo una transizione un po' più lunga, mentre parlano di soli 2 anni quindi nel 2022 venderanno gli ultimi Mac Intel
comunque hanno garantito rilasci macOS Intel per anni a venire, ma non avevo dubbi a riguardo
certo comprare un Mac Intel il prossimo anno non so quanto valga la pena a questo punto (intendo nuovo a prezzo pieno) però il supporto sarà lungo quindi nessuna fretta di passare alla nuova architettura, almeno per me
tra 4-5 anni quando cambierò il mio vedremo a che punto saranno

ti sei risposto da solo, tra una-due settimane sapremo.

non è detto che tutte le demo fossero con un A12Z comunque... può darsi che il gioco e Maya fossero con un prototipo di A14, impossibile saperlo...
è qualcosa che scopriremo tra pochi giorni comunque dato che il kit verrà spedito agli sviluppatori che potranno farci girare di tutto e daranno dei feedback più affidabili del loro keynote
credo ci saranno più dettagli su Rosetta2 in una delle sessioni di questa settimana dove si parla più nello specifico dei Mac ARM

sinceramente mi aspettavo una transizione un po' più lunga, mentre parlano di soli 2 anni quindi nel 2022 venderanno gli ultimi Mac Intel
comunque hanno garantito rilasci macOS Intel per anni a venire, ma non avevo dubbi a riguardo
certo comprare un Mac Intel il prossimo anno non so quanto valga la pena a questo punto (intendo nuovo a prezzo pieno) però il supporto sarà lungo quindi nessuna fretta di passare alla nuova architettura, almeno per me
tra 4-5 anni quando cambierò il mio vedremo a che punto saranno

il rumors uscito una settimana fa mi aveva convinto, un rumors prima della WWDC era abbastanza forte. Anche io stupito dei due anni, mi aspettavo di più e mi aspettavo fossero messi peggio, invece vedere già Adobe al day1, la stessa adobe che ancora non ha rilasciato un cavolo di suite che sfrutti Metal bene quanto cuda, mi ha sinceramente stupito

@insane74
diciamo che, visto che non l'hanno specificato, qualche dubbio viene, altrimenti un "questo che vedete è quello che succede sul devkit" potevano aggiungerlo, ovviamente sono sempre uno che si fida poco delle "presentazioni pubblicitarie", sia di Apple che di altri, quindi lieto di essere smentito

il rumors uscito una settimana fa mi aveva convinto, un rumors prima della WWDC era abbastanza forte. Anche io stupito dei due anni, mi aspettavo di più e mi aspettavo fossero messi peggio, invece vedere già Adobe al day1, la stessa adobe che ancora non ha rilasciato un cavolo di suite che sfrutti Metal bene quanto cuda, mi ha sinceramente stupito

direi che era impensabile lanciare un Mac ARM senza adeguato supporto software nativo, per cui Adobe e MS dovevano esserci "per forza"
sull'emulazione, non mi aspettavo l'idea della traduzione "una tantum" ma ci sta...
altra notizia è che c'è la virtualizzazione, per cui puoi mettere Docker e Parallels, non hanno detto niente di Bootcamp ma non penso sia un mercato che hanno paura di perdere, chi vuole il dual boot se ne farà una ragione e mollerà Apple

tra l'altro è passato più in sordina, ma a parte Catalyst le varie app di iPhone e iPad gireranno su Big Sur (a patto che il Mac sia ARM ovviamente...) e questo significa avere una suite di app gigantesca al day one, moltissime probabilmente inutili, ma nel mucchio ci sono anche ottime utility oltre a varie app che qualcuno potrebbe preferire al sito internet
credo che il redesign di macOS abbia a che fare soprattutto con questo fatto, per l'utente medio è facile che saranno più le app iOS/Catalyst che quelle veramente native mac per cui diventa una sorta di iPadOS con i menù, cosa che fa storcere il naso ai puristi ma che mi aspettavo vista la strada intrapresa

E' chiaro che i mac x86 ormai sono fuori mercato

Apple potrebbe anche abbandonare del tutto in fascia pro, già da tempo è una fascia abbastanza snobbata, con pochi prodotti e spesso neanche riuscitissimi ( tipo il portaombrelli )


Adobe e Microsoft sono partner totali di Apple, sono sempre presenti al day 1.
Il problema sono casomai le altre SW house


Sinceramente le prestazioni sbandierate su applicazioni selezionatissime e preparate appositamente lasciano abbastanza il tempo che trovano.

Fossero costati e costassero il giusto, ovvero senza i sovrapprezzi da taglieggiatore applicati da Apple, la cosa sarebbe " tollerabile ".
Ma Mac Pro a parte ( di nicchia si, ma riservata a chi ha deciso di investire pesantemente nella piattaforma nella previsione di un determinato ammortamento ) che sarà l'ultimo X86 a resistere nel tempo, la mia considerazione è su chi ha speso dei bei soldoni per MBP 15/16" o per un iMac Pro o un Mac Mini 2019 che ieri sera si è visto tagliare le gambe senza pietà.

Concordo con te su MS e Adobe, presenti già da tempo con versioni dei loro software di produttività per iOS. Sinceramente la meraviglia di Federighi nel. mostrare la fluidità nativa ( WOW ) di Word ed Excel l'ho trovata alquanto ridicola, per non scrivere infingarda!! E concordo sempre con te nell'aspettare e valutare la risposta delle altre software house ( una su tutte Phase One con C1 che ancora oggi non riesce a sfruttare Metal per i suoi algoritmi proprietari a causa delle carenze di documentazione di Apple e si appoggia alle istruzioni avanzate delle CPU X86 ).

Questa favola la ripeti ad ogni thread su apple e arm.
Di quale prestazioni parli? Come lo confronti un benchmark tra ipad os / arm e mac os / x86? Su quali applicazioni?
Certo che se fai vedere una demo dove il carico é 80% GPU 10% ram e 10% cpu allora pure uno snapdragon mid range puo' sostituire un i7 in certi ambiti specifici.
Il metro di giudizio lo si avrà quando i sw general purpose e quelli da intenso carico di lavoro saranno tutti portati su arm, a quel punto potrai essere certificato o smentito.
La vera differenza la puo' fare effettivamente l'ottimizzazione di un sistema chiuso, ma da qui a colmare il gap con una cpu destktop e workstation x86 ce ne passa.
La dimostrazione ce l'hai nel mondo console, una PS a parità di hardware é un po piu' performante di un pc, ma appena la configurazione sale di livello la differenza di potenza si nota.
In apple non sono certo scemi, sanno perfettamente cosa serve alla loro utenza e sanno perfettamente che quel carico li possono offrirlo con un soc proprietario ottimizzato che gli costa di meno e gli allunga pure la durata della batteria, inoltre non hanno il problema storico di microsoft o di linux di dover gestire decine di configurazioni hardware differenti e di dover garantire tutto lo stack dei driver nativi/proprietari.
Apple gestisce i suoi sistemi dalla linea 0 del firmware fino all'aggiornamento di safari, che se non fai cazzate ti dà certamente un vantaggio prestazionale rispetto ad altre piattaforme, ma non abbastanza per offrire le stesse performances in tutti gli scenari, né ora e né mai.Secondo quale principio esattamente Apple non sarebbe capace di offrire performance paragonabili alle CPU x86 di Intel?

Anandtech la pensa diversamente dopo aver condotto molteplici test sull'A13:

Overall, in terms of performance, the A13 and the Lightning cores are extremely fast. In the mobile space, there’s really no competition as the A13 posts almost double the performance of the next best non-Apple SoC. The difference is a little bit less in the floating-point suite, but again we’re not expecting any proper competition for at least another 2-3 years, and Apple isn’t standing still either.

Last year I’ve noted that the A12 was margins off the best desktop CPU cores. This year, the A13 has essentially matched best that AMD and Intel have to offer – in SPECint2006 at least. In SPECfp2006 the A13 is still roughly 15% behind.


https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/4

SPECint è un benchmark 100% CPU.
Il fatto che Apple usi ISA ARM non significa che un core "super" wide come Lightning non sia in grado di performare come una cpu Intel. Sarebbe ora di finirla con questa aria mitologica di x86 sinceramente.

Ma Mac Pro a parte ( di nicchia si, ma riservata a chi ha deciso di investire pesantemente nella piattaforma nella previsione di un determinato ammortamento ) che sarà l'ultimo X86 a resistere nel tempo, la mia considerazione è su chi ha speso dei bei soldoni per MBP 15/16" o per un iMac Pro o un Mac Mini 2019 che ieri sera si è visto tagliare le gambe senza pietà.


io non sono così pessimista, ho comprato il 16" a inizio lockdown ma ero praticamente certo della transizione verso ARM pur aspettandomela più lunga, ma in ogni caso sono tranquillo sul supporto macOS per le macchine vendute nel 2020 e 2021
smetteranno di ricevere major update (path di sicurezza a parte) quando inizieranno ad essere macchine abbastanza vecchie

il rischio che corrono adesso è che la gente rimandi gli acquisti dei Mac Intel aspettando le prime versioni ARM
io l'ho preso per necessità per via del lockdown, ma capisco che chi ha una macchina vecchia ma ancora utilizzabile ora aspetterà i primi benchmark per capire se rimanere un'ultima volta con Intel o se fare subito il salto

tutti avevano "paura" di Office (presentato già nativo), Adobe (presentato Photoshop nativo) e delle attuali applicazioni x86 per Mac (e ne hanno fatte vedere due di norma "pesanti" per CPU/GPU come Maya e un gioco).

per me, se è vero che stava girando su un A12Z con 16GB di RAM, con un OS ancora in beta, con Rosetta 2 ancora in beta, è stato un risultato piuttosto impressionante. :)

Macchè paura di Office.... esiste per iPad e iPhone da tempo!!
Pesante Maya in modalità wireframe e con un prerendering ( tra l'altro senza antialias e filtraggio delle texture )? Ma dai... La potenza di calcolo di CPU e GPU ( soprattutto ) si vede quando si comincia a fare ore e ore di rendering finali con tutti i filtri accesi e alla massima risoluzione, dove i pixel da lavorare al secondo si moltiplicano in maniera esponenziale.

io non sono così pessimista, ho comprato il 16" a inizio lockdown ma ero praticamente certo della transizione verso ARM pur aspettandomela più lunga, ma in ogni caso sono tranquillo sul supporto macOS per le macchine vendute nel 2020 e 2021
smetteranno di ricevere major update (path di sicurezza a parte) quando inizieranno ad essere macchine abbastanza vecchie

il rischio che corrono adesso è che la gente rimandi gli acquisti dei Mac Intel aspettando le prime versioni ARM
io l'ho preso per necessità per via del lockdown, ma capisco che chi ha una macchina vecchia ma ancora utilizzabile ora aspetterà i primi benchmark per capire se rimanere un'ultima volta con Intel o se fare subito il salto

Non credo che Apple dropperà il supporto ai mac intel cosi dall'oggi al domani, secondo me supporterà almeno 2 major release anche 3, fermo restando che bisognerà pure vedere i loro piani per l'imac pro e il mac pro.

Non credo che Apple dropperà il supporto ai mac intel cosi dall'oggi al domani, secondo me supporterà almeno 2 major release anche 3, fermo restando che bisognerà pure vedere i loro piani per l'imac pro e il mac pro.
Con i processori Motorola 680x0 / PowerPC fu un lampo.... non penso si faranno problemi, 1 o massimo 2 anni e non usciranno più modelli x86.

;46848098']Con i processori Motorola 680x0 / PowerPC fu un lampo.... non penso si faranno problemi, 1 o massimo 2 anni e non usciranno più modelli x86.

lo hanno proprio detto: 2 anni
ma un conto è non vendere più un nuovo Mac con processore Intel, un altro è smettere di supportare x86
secondo me almeno per 4 anni avremo supporto di major release macOS per entrambe le piattaforme, ieri non hanno parlato di date ma genericamente di "diversi anni" per questo direi almeno 4

Sinceramente le prestazioni sbandierate su applicazioni selezionatissime e preparate appositamente lasciano abbastanza il tempo che trovano.

calcolando che tra una settimana tutti avranno in mano ste macchine, non vedo perché tirarsi la zappa sui piedi e raccontare fregnacce.

lo hanno proprio detto: 2 anni
ma un conto è non vendere più un nuovo Mac con processore Intel, un altro è smettere di supportare x86
secondo me almeno per 4 anni avremo supporto di major release macOS per entrambe le piattaforme, ieri non hanno parlato di date ma genericamente di "diversi anni" per questo direi almeno 4

Anche secondo me, tempo di far risultare l'attuale macbookpro 16 "vintage"

Secondo quale principio esattamente Apple non sarebbe capace di offrire performance paragonabili alle CPU x86 di Intel?

Anandtech la pensa diversamente dopo aver condotto molteplici test sull'A13:

https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/4

SPECint è un benchmark 100% CPU.
Il fatto che Apple usi ISA ARM non significa che un core "super" wide come Lightning non sia in grado di performare come una cpu Intel. Sarebbe ora di finirla con questa aria mitologica di x86 sinceramente.

perchè le performance/watt danno un indicazione di consumo, ma a parità di rapporto non è detto che si riesca a scalare:

certo una moto ha performance/l migliori di un camion, ma non puoi attaccare un rimorchio a 100 moto per pareggiare, o almeno puoi farlo per sfida o per ridere, ma poi non lo puoi usare "per lavorare", anche in un ambito di standard stradali etc etc...

percarità, questa è stata una verità SEMPRE vera da che esiste ARM e x86, claro che le richieste di computazione parallela e consumi ridotti sui server ha portato fior di milioni sul settore per sviluppare le capacità di ARM.
Il gap si sta colmando e di molto, certamente 50 anni quasi di egemonia non si cancellano in 5 minuti, sicuramente questa mossa di Apple potrebbe però dare la spintarella per far crollare il castello Intel con delle reazioni a catena, ma anche no.

alla fine i consumi sono importanti ma c'è interesse su portatili e datacenter, per il resto del mondo pc è ininfluente

Secondo me dovremo tornare su questo thread tra sei mesi o giù di lì, quando Apple presenterà il primo iMac con A14 o come lo chiamerà, e vedremo quanto più veloce sarà (o meno) rispetto a quello attuale. Io scommetto che ci sarà un balzo spaventoso… già oggi gli ultimi processori Apple rivaleggiano con cpu mobile intel/amd… con la differenza che i chip Apple non hanno manco una ventola di raffreddamento. Se vengono meno alcune restrizioni sulle dimensioni del chip e i suoi consumi, e se si raffredda il chip allora mi sa che le prestazioni saranno più che competitive. Ma vedremo, manca poco ormai.

Il kit sviluppatori sarà utile per farsi una prima idea, ma non usa i processori che saranno abbinati ai primi Mac ARM.

lessi un bell'articolo "sull'esperimento" di server ARM che non hanno dato i frutti sperati... ora non lo trovo :(

https://www.hwupgrade.it/news/sistemi/supercomputer-c-e-un-nuovo-numero-uno-nella-top-10-anche-due-sistemi-italiani_90292.html

https://www.anandtech.com/show/15169/a-success-on-arm-for-hpc-we-found-a-fujitsu-a64fx-wafer

Il nuovo supercomputer Fugaku, primo in classifica, usa soc ARM :)

alla fine i consumi sono importanti ma c'è interesse su portatili e datacenter, per il resto del mondo pc è ininfluente

Aggingi che questa cpu va anche sugli smartphone, in pratica abbiamo tutto il grosso del mercato dove si fanno i soldi :D

lo hanno proprio detto: 2 anni
ma un conto è non vendere più un nuovo Mac con processore Intel, un altro è smettere di supportare x86
secondo me almeno per 4 anni avremo supporto di major release macOS per entrambe le piattaforme, ieri non hanno parlato di date ma genericamente di "diversi anni" per questo direi almeno 4

Diversi anni di sicuro ma penso che il mercato dell’usato Intel avrà uno bello scossone al ribasso

Secondo quale principio esattamente Apple non sarebbe capace di offrire performance paragonabili alle CPU x86 di Intel?

Anandtech la pensa diversamente dopo aver condotto molteplici test sull'A13:



https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/4

SPECint è un benchmark 100% CPU.
Il fatto che Apple usi ISA ARM non significa che un core "super" wide come Lightning non sia in grado di performare come una cpu Intel. Sarebbe ora di finirla con questa aria mitologica di x86 sinceramente.

SPECint è un test che riguarda solo il set di istruzioni intere ( che interessa a ben pochi ) ed è rigorosamente monocore ;)

Diversi anni di sicuro ma penso che il mercato dell’usato Intel avrà uno bello scossone al ribasso
Ma anche quello del nuovo
Voglio dire, i mac Intel sono ufficialmente su un binario morto

Diversi anni di sicuro ma penso che il mercato dell’usato Intel avrà uno bello scossone al ribasso

ah quello sicuro
infatti oggi non comprerei assolutamente un Mac Intel a prezzo pieno, proprio perché al momento di rivenderlo il valore sarà decisamente più basso del solito

Il kit sviluppatori sarà utile per farsi una prima idea, ma non usa i processori che saranno abbinati ai primi Mac ARM.

e quando richiedi il kit di fatto ti proibiscono di condividere benchmark, proprio perché usa un SoC che non sarà quello dei primi Mac disponibili sul mercato
ottimo per farsi un'idea di massima, ma parliamo di un processore nato per iPad e basato su un'architettura che ha quasi 2 anni, sul mercato arriverà ben altro

si ma questi sono campi specifici, dove le CPU fanno solo quello ... io mi riferivo ad un uso nel mondo reale Server, non si e' rilevato meglio di un x86 alla fine

In ambito General purpose X86 è difficile da battere per sua stessa natura, il punto di forza dell'architettura CISC è proprio quello, fare di tutto un po... mettiamoci pure l'innalzamento dei core visto negli ultimi anni e il probabile passaggio di intel ad architettura modulare, se i programmi scaleranno linearmente all'aumentare dei core le prestazioni saliranno velocemente.

SPECint è un test che riguarda solo il set di istruzioni intere ( che interessa a ben pochi ) ed è rigorosamente monocore ;)
Ma anche quello del nuovo
Voglio dire, i mac Intel sono ufficialmente su un binario morto

Appunto, difficile eguagliare un 3950X in MT senza andare a scomodare un 3990X o un epyc.

Ripeto, a me l'idea di un mac ARM non dispiace dato che, e questo è innegabile, Apple è sempre stata attenta a sviluppare SO su misura rispetto all'hardware, sono curioso di vedere cosa faranno con la fascia "PRO" dove ora usano gli XEON, ram ECC e GPU AMD professionali :)

Non capisco questo entusiasmo per le cpu Apple perché ad ora non si può pensare di competere alla pari con Intel e Amd, con alle spalle decenni di esperienza e know how. E' logico che durante le presentazioni ti facciano vedere che tutto gira benissimo. Per Photoshop, speriamo non faccia la fine della app su iPad, con l'uscita tardata di un anno mi pare.

Guarda che ipad pro è generalmente 3 volte piu veloce del macbook air con i3.

In verità anche dell'i7 in tantissimi benchmark (geekbench o specint).

I render sono fino a 3 volte piu veloci sull'ipad che sul macbook.

Le prestazioni ARM le ha da tempo, x86 non sparirà di certo, ma mi aspetto una transizione verso arm anche al di fuori di macos.

Alla fine inutile girarci intorno. Una soc arm sembra raddoppiare le performance ogni 2 anni, x86 sembra farlo ogni 10 e il tutto consumando immensamente di piu.

E' senz'altro verso che su istruzioni specifiche il boost su x86 è netto, vedi avx, ma quando in tanti altri ambiti un core arm va il doppio/triplo di un core x86 clockato il doppio è evidente che qualcosa non va.

Macchè paura di Office.... esiste per iPad e iPhone da tempo!!
Pesante Maya in modalità wireframe e con un prerendering ( tra l'altro senza antialias e filtraggio delle texture )? Ma dai... La potenza di calcolo di CPU e GPU ( soprattutto ) si vede quando si comincia a fare ore e ore di rendering finali con tutti i filtri accesi e alla massima risoluzione, dove i pixel da lavorare al secondo si moltiplicano in maniera esponenziale.

su iPad c'è Office ma non è certo lo stesso che c'è sul desktop. Che Office ci sarebbe stato su ARM era scontato, che ci fosse al day one (come pare) meno.

l'A12Z è una CPU per tablet. ha la GPU integrata. Maya stava girando tramite Rosetta 2 (quindi codice x86 su ARM), non direi che sia "scontato" che l'applicativo girasse fluido con 6 milioni di poligoni e poi con le texture.
capisco fosse stata nativa ARM, ma tramite Rosetta 2 mi sembra un bel risultato.
poi ovvio che tutti vogliamo vedere quanto tempo ci impiega un rendering rispetto ad un i7, ma lo scopriremo nei prossimi mesi.

se prendiamo la stessa pesantissima foto in photoshop e applichiamo gli stessi pesantissimi filtri... ipad e' 3 volte piu' veloce?

l'iPad ha quanto? 4GB di RAM? te credo che oltre un certo punto non può andare.
l'interessante è vedere questi ARM con una dotazione di RAM da desktop, frequenze più alte (grazie alla dissipazione attiva), e vedere che numeri riusciranno a tirar fuori.
possiamo solo stare alla finestra e aspettare.
non tarderanno certo i primi bench. :D

se prendiamo la stessa pesantissima foto in photoshop e applichiamo gli stessi pesantissimi filtri... ipad e' 3 volte piu' veloce?

Non ho dati alla mano ma non vedo perchè non dovrebbe esserlo (non metto mano sul fuoco sul quanto piu veloce).

La pipeline grafica è ottimizzata per le gpu Apple e non è solo cpu come su x86.

su iPad c'è Office ma non è certo lo stesso che c'è sul desktop. Che Office ci sarebbe stato su ARM era scontato, che ci fosse al day one (come pare) meno.

l'A12Z è una CPU per tablet. ha la GPU integrata. Maya stava girando tramite Rosetta 2 (quindi codice x86 su ARM), non direi che sia "scontato" che l'applicativo girasse fluido con 6 milioni di poligoni e poi con le texture.
capisco fosse stata nativa ARM, ma tramite Rosetta 2 mi sembra un bel risultato.
poi ovvio che tutti vogliamo vedere quanto tempo ci impiega un rendering rispetto ad un i7, ma lo scopriremo nei prossimi mesi.

un render di un video 4k esportato da iMovie è molto piu veloce su ipad pro che su mackbook i7:

https://photos5.appleinsider.com/gallery/35253-64536-Video-Export-Test-for-iPad-and-Mac-xl.jpg

pero' voglio prove sul campo di utilizzo reale, non il benchmark di antutucoso

ovvio, anche perché bench su archietture diverse sono sempre rognosi. ma cronometro alla mano per rendering, applicazione filtiri e simili ci diranno di più.

un render di un video 4k esportato da iMovie è molto piu veloce su ipad pro che su mackbook i7:

https://photos5.appleinsider.com/gallery/35253-64536-Video-Export-Test-for-iPad-and-Mac-xl.jpg

non discuto, ma siamo sempre su:
- lo dice Apple
- sono tempi su un singolo task

l'uso reale è: mentre faccio l'export da iMovie sul nuovo Mac ARM-based leggo la posta, navigo con Safari, ascolto musica, ritocco un documento in Excel. vedremo in QUEL caso che tempi tirerà fuori.

PS: io sono uno degli ottimisti, ma finché non ci saranno prove sul campo fatte da terzi, si parla solo di fuffa.

ovvio, anche perché bench su archietture diverse sono sempre rognosi. ma cronometro alla mano per rendering, applicazione filtiri e simili ci diranno di più.



non discuto, ma siamo sempre su:
- lo dice Apple
- sono tempi su un singolo task

l'uso reale è: mentre faccio l'export da iMovie sul nuovo Mac ARM-based leggo la posta, navigo con Safari, ascolto musica, ritocco un documento in Excel. vedremo in QUEL caso che tempi tirerà fuori.

PS: io sono uno degli ottimisti, ma finché non ci saranno prove sul campo fatte da terzi, si parla solo di fuffa.

Non è una slide Apple, è preso da una recensione di terzi:

https://appleinsider.com/articles/20/04/06/ipad-pro-2020-versus-macbook-air-2020-performance-features

Di recensioni delle soc apple ne trovi a iosa, l'A11 raggiungeva prestazioni da top cpu intel in svariati benchmark.

Per il resto del tuo commento...tanto piu dovrebbe essere avvantaggiato arm avendo più core.

Non è una slide Apple, è preso da una recensione di terzi:

https://appleinsider.com/articles/20/04/06/ipad-pro-2020-versus-macbook-air-2020-performance-features

Di recensioni delle soc apple ne trovi a iosa, l'A11 raggiungeva prestazioni da top cpu intel in svariati benchmark.

Per il resto del tuo commento...tanto piu dovrebbe essere avvantaggiato arm avendo più core.

solo il tempo lo dirà.
ripeto, io sono uno degli ottimisti, e vedere che la demo del prossimo OSX girava già su un ARM con le app Apple già tutte native e girava in quel modo, fa ben sperare che almeno per un uso classico del PC il comportamento sia più che buono.

bisognerà però aspettare di avere l'hw in mano e gente che ci faccia girare su di tutto (nativo e non) per rendersi conto davvero di come si comporta nell'uso quotidiano.
tutto il resto sono speculazioni, speranze e paure (niente più bootcamp? virtualizzazione solo di OS ARM-based?, ecc)

su iPad c'è Office ma non è certo lo stesso che c'è sul desktop. Che Office ci sarebbe stato su ARM era scontato, che ci fosse al day one (come pare) meno.

l'A12Z è una CPU per tablet. ha la GPU integrata. Maya stava girando tramite Rosetta 2 (quindi codice x86 su ARM), non direi che sia "scontato" che l'applicativo girasse fluido con 6 milioni di poligoni e poi con le texture.
capisco fosse stata nativa ARM, ma tramite Rosetta 2 mi sembra un bel risultato.
poi ovvio che tutti vogliamo vedere quanto tempo ci impiega un rendering rispetto ad un i7, ma lo scopriremo nei prossimi mesi.

Office: poco cambia tra i Pad e desktop a livello di codice. L'impianto è quello.

Maya: c'è da premettere che non si sa bene quale versione abbiano usato per la demo, soprattutto per la GPU visto che per macOS il supporto è abbastanza limitato ( come da info Autodesk ). Ho il sospetto che abbiano usato una versione rimaneggiata o con il rendering limitato alla sola CPU. Detto ciò, che un un SoC AXX di ultima generazione non riesca a gestire 6 Mln di poligoni ( a quale risoluzione? ) in wireframe sarebbe davvero troppo. Inoltre Maya non così esoso di risorse come possa sembrare visto che richiede da 8GB in su di memoria e l'eseguibile è da 4GB.

Interessante quella slide, bisogna vedere se l'air ha usato l'encode software o il Quick Sync, molto probabilmente l'ipad pro ha usato la GPU con Metal che da un bel boost.

Interessante quella slide, bisogna vedere se l'air ha usato l'encode software o il Quick Sync, molto probabilmente l'ipad pro ha usato la GPU con Metal che da un bel boost.

Boh
Solo io ho notato a che frequenze girano quelle cpu Intel ?
No perché a 1.1-1.2 Ghz consumeranno poco ma ho come l' impressione che non vadano poi così veloci :mc:
Perché se parliamo di cpu a basso consumo gli ARM possono sicuramente dire la loro
Il problema è sostituire le cpu desktop o professionali

Boh
Solo io ho notato a che frequenze girano quelle cpu Intel ?
No perché a 1.1-1.2 Ghz consumeranno poco ma ho come l' impressione che non vadano poi così veloci :mc:
Perché se parliamo di cpu a basso consumo gli ARM possono sicuramente dire la loro
Il problema è sostituire le cpu desktop o professionali

Sono cpu ULV da 10W di TDP raffreddate semi passivamente ma a occhio non hanno usato il Quick Sync, non so se imovie lo supporta.

Mi piacerebbe la stessa cura nel design dell'interfaccia e nella coerenza della stessa anche in ambito Windows. Chissà se prima o dopo, a furia di may/october/xyz update, riusciremo ad averla.

Per quel che riguarda ARM... beh, era ovvio e si sapeva da tempo.
Unica cosa a favore di Apple è che generalmente -non sempre- quando sceglie una strada poi il mondo le va dietro e quindi le applicazioni ci saranno, gireranno bene etc etc etc. Questo dovrebbe portare vantaggi anche per Windows on Arm o sbaglio?

si ma questi sono campi specifici, dove le CPU fanno solo quello ... io mi riferivo ad un uso nel mondo reale Server, non si e' rilevato meglio di un x86 alla fine

Su Fugaku le cpu fanno di tutto e di più, uno dei punti di forza che ha è un enorme banda di I/O (che crescerà ancora di più nelle versioni di successive di A64FX) ed una versatilità maggiore (eccelle sia nei carichi "da gpu" che in quelli "da cpu").
Il rapporto prestazioni/watt è 3 volte superiore agli Xeon attualmente sul mercato, che è un bel vantaggio anche per quel che riguarda i costi operativi (Fugaku si ciuccia più di 22MWatt, una soluzione con potenza di calcolo equivalente basata du Xeon richiederebbe più di 60MWatt).
Inoltre gli ARM di punta possono permettersi di implementare solo AArch64+SVE senza avere requisiti di retrocompatibilità ... e guadagnando pure "compatibilità in avanti" a livello di software applicativo.
L'implementazione di SVE su A64FX usa registri a 512bit, ma lo stesso software fatto girare su un hardware futuro con SVE a 2048bit sfrutterebbe al massimo anche tale architettura.
Quindi ad esempio si potrebbero pure realizzare sistemi big.LITTLE dove i core "big" hanno SVE a 2048bit mentre i "little" delle SVE a 128bit e lo stesso codice girerebbe su entrambi senza modifiche).
Insomma, considerando che ARM stessa ha collaborato con Fujitsu nella progettazione ed ottimizzazione architetturale degli A64FX, non mi stupirei se i frutti di tale collaborazione apparissero anche su cpu di fascie più basse.

Sono cpu ULV da 10W di TDP raffreddate semi passivamente ma a occhio non hanno usato il Quick Sync, non so se imovie lo supporta.

Quick Sync è supportato almeno dal 2014 in macOS ma il suo uso sembra ristretto solamente ad alcune applicazioni tra cui iMovie ( non so se la versione attuale abbia rimpiazzato Quicksync con Metal ). Il problema con Quick Sync è che viene usato solamente per la codifica base in single pass e per Mpeg 4, altrimenti il sistema passa il compito alla GPU usando OpenCL/Metal.

Bisognerebbe conoscere quindi le impostazioni di rendering del video usato per il benchmark.

un render di un video 4k esportato da iMovie è molto piu veloce su ipad pro che su mackbook i7:

https://photos5.appleinsider.com/gallery/35253-64536-Video-Export-Test-for-iPad-and-Mac-xl.jpg

si ma il benchmark si spera non sia la pessima implementazione intel dell'air, che è un chiodo dissipato malissimo e pesantemente limitato in quanto assorbimento energetico

Quick Sync è supportato almeno dal 2014 in macOS ma il suo uso sembra ristretto solamente ad alcune applicazioni tra cui iMovie ( non so se la versione attuale abbia rimpiazzato Quicksync con Metal ). Il problema con Quick Sync è che viene usato solamente per la codifica base in single pass e per Mpeg 4, altrimenti il sistema passa il compito alla GPU usando OpenCL/Metal.

Bisognerebbe conoscere quindi le impostazioni di rendering del video usato per il benchmark.

Precisamente. Se hanno usato metal per entrambi il vantaggio di ipad pro è indiscutibile ma senza impostazioni fare un confronto non è facile.
Ciò non toglie che gli ipad stanno diventando, anzi sono diventati, delle ottime macchina da lavoro da usare INSIEME, al bisogno, a sistemi più performanti

si ma il benchmark si spera non sia la pessima implementazione intel dell'air, che è un chiodo dissipato malissimo e pesantemente limitato in quanto assorbimento energetico

Si è proprio su quell'air che arriva a 100 gradi come niente infatti la differenza tra i3 e i7 non è molta.

nessuno ha notato che le interfacce si sono "ingrandite"? quasi come se volessero implementare il touch in futuro

sì l'ho notato e secondo me è molto probabile che vedremo un Mac touchscreen, se no che senso avrebbe snaturare così tanto la UI per aumentare i touch target?
fino a settimana scorsa avrei detto di no, ma vista la nuova UI...

dopotutto iPad Pro cosa fa? lo attacchi alla tastiera usandolo come un portatile con anche il cursore ma puoi sollevare la mano e usarlo touch, cosa che loro hanno sempre sostenuto essere scomodissima a livello ergonomico
bene, se lo hanno sdoganato su iPad non c'è motivo perché non arrivi sul Mac, magari non subito e sicuramente non su tutti i modelli ma può darsi che l'ibrido prima o poi arrivi, con touch screen come funzionalità in più, non pensata come interazione primaria, un po' come la tastiera è un di più su iPad

l'altra possibile spiegazione è uniformità considerando che molte app iPad gireranno su macOS, ma non è che se ne sentisse per forza la necessità quindi ci deve essere qualcosa sotto...

Mah, l’importante è che non mi fanno un IMac Touch, tanti soldi in più per una cosa veramente di nicchia su IMac...che è già di nicchia di suo

nessuno ha notato che le interfacce si sono "ingrandite"? quasi come se volessero implementare il touch in futuro

Fosse vero non mi stupirei... Big Sur, alias macOS 11 ( bye bye OS X/macOS 10 ), è il primo passo verso una nuova generazione di Macintosh che per certi aspetti assomiglieranno più a degli iPad agli steroidi che a dei veri e propri PC.
Ovviamente i bei discorsi di Tim Cook pronunciati nemmeno tanto tempo fa sulla distinzione tra Mac e iOS Devices sono andati a farsi benedire... Ah la coerenza!! :rolleyes: :rolleyes:

Fosse vero non mi stupirei... Big Sur, alias macOS 11 ( bye bye OS X/macOS 10 ), è il primo passo verso una nuova generazione di Macintosh che per certi aspetti assomiglieranno più a degli iPad agli steroidi che a dei veri e propri PC.
Ovviamente i bei discorsi di Tim Cook pronunciati nemmeno tanto tempo fa sulla distinzione tra Mac e iOS Devices sono andati a farsi benedire... Ah la coerenza!! :rolleyes: :rolleyes:

per me la cosa fondamentale è che il Mac rimanga tale nel senso che ho libertà di accesso al file system, possibilità di bypassare lo store, organizzazione finestre e così via
in questo senso macOS è profondamente diverso da iPadOS

se uno dei laptop sarà touch screen però con macOS sarà un metodo di input in più che a me può anche stare bene, non mi interessa e non lo compro ma non mi toglie niente come mac user
l'importante è che rimanga la distinzione sotto il cofano, non ho certo voglia di usare una sorta di iPadOS anche su un desktop...

Secondo voi sarà possibile far girare MacOS su iPad Pro?

Ovviamente non “ufficialmente” ma con Jailbreak e qualche truschino vario

Se A12Z permette di far girare MacOS, why not su un iPad Pro

Secondo voi sarà possibile far girare MacOS su iPad Pro?

Ovviamente non “ufficialmente” ma con Jailbreak e qualche truschino vario

Se A12Z permette di far girare MacOS, why not su un iPad Pro

a riguardo qualcuno aveva ipotizzato che iPad Pro potesse essere il dispositivo usato per il kit, ma era ovvio che il Mini fosse la soluzione anche per una questione di costi

io non escluderei a priori quello che dici, però il kit non è semplicemente un A12Z bisogna vedere come ti interfacci con SSD e cosa altro c'è a livello di I/O da configurare e sicuramente serve un JB perché chissà quante altre restrizioni ci sono...
qualche "malato" ci proverà senza dubbio e spero ci riescano :D

a riguardo qualcuno aveva ipotizzato che iPad Pro potesse essere il dispositivo usato per il kit, ma era ovvio che il Mini fosse la soluzione anche per una questione di costi

io non escluderei a priori quello che dici, però il kit non è semplicemente un A12Z bisogna vedere come ti interfacci con SSD e cosa altro c'è a livello di I/O da configurare e sicuramente serve un JB perché chissà quante altre restrizioni ci sono...
qualche "malato" ci proverà senza dubbio e spero ci riescano :D

Io possiedo un Pro con A12X, quindi cambia davvero quasi nulla a livello di potenza

Speriamo direi!!

per me la cosa fondamentale è che il Mac rimanga tale nel senso che ho libertà di accesso al file system, possibilità di bypassare lo store, organizzazione finestre e così via
in questo senso macOS è profondamente diverso da iPadOS

se uno dei laptop sarà touch screen però con macOS sarà un metodo di input in più che a me può anche stare bene, non mi interessa e non lo compro ma non mi toglie niente come mac user
l'importante è che rimanga la distinzione sotto il cofano, non ho certo voglia di usare una sorta di iPadOS anche su un desktop...

quoto tutto, se fanno il mac touch, ma non mi obbligano a pagare di più (lo mettono allo stesso prezzo dei vecchi modelli o lo mettono come upgrade a pagamento a parte), non me ne può fregare di meno.
Discorso limiti, spero che MacOS mantenga queste differenze da iPadOS o che al limite potenzino/elimino iPadOS. Limitare macOS secondo me relegherebbe Apple ai modaioli, perchè nessuno potrebbe più lavorarci comodamente

Io volendo passare a macbook pro (programmazione js, typescript ecc) posso prendere un x86 o meglio aspettare (ma quanto:confused: ) ARM? Mi hanno sconvolto i piani con sti annunci, stavo già per prendere un macbook pro 13 pollici con intel decima generazione :muro:

Se non hai fretta potresti attendere ma non credo, cosi a naso, che gli intel saranno abbandonati dall'oggi al domani, se c'è una cosa che Apple non fa è lasciare appesi i loro device sul fronte del software. Correggetemi se sbaglio.

Ma di quanto tempo si parla più o meno? Tanto io non facendo montaggio video (se non il filmino delle vacanze o qualche viaggio) della gpu dedicata non me ne faccio assolutamente nulla e su questo tipo di macchine ARM potrebbe essere una bella soluzione e la cosa mi fa propendere per aspettare. D'altra parte però credo che un'installazione di windows mi servirà per qualche esigenza particolare, e su questo o più di qualche timore su ARM. Insomma un bel dilemma per quanto mi riguarda :confused:

hanno già detto niente più Bootcamp (quindi niente più dual boot) e niente virtualizzazione di OS x86 (quindi al max si potrà virtualizzare Windows 10 ARM, non Windows 10 x86).

pure io stavo pensando di prendere un Mac in questo periodo e dopo aver visto la presentazione mi sono detto: "meglio aspettare i nuovi ARM! promettono bene e sono il futuro dei Mac!", ma se hanno questa "limitazione" (per carità, comprensibile visto il cambio di architettura) è un bel salto nel buio.
prima almeno se uno aveva necessità poteva sempre farsi un dual boot o alla peggio virtualizzare, ma così...

Io volendo passare a macbook pro (programmazione js, typescript ecc) posso prendere un x86 o meglio aspettare (ma quanto:confused: ) ARM? Mi hanno sconvolto i piani con sti annunci, stavo già per prendere un macbook pro 13 pollici con intel decima generazione :muro:

No evita, macbook pro 2018 in avanti scaldano come dei forni.

Se usi il pc intensivamente ti si scalda fai fatica anche solo a toccare il trackpad.

Gli ultimi 3 macbook hanno tutti lo stesso problema e fanno un sacco di rumore.

Aspetta la versione arm dopo che se ne saranno viste le recensioni o acquista un notebook ryzen 4000 o rischi anche di avere un prodotto che verrà supportato molto meno.

Per quel che riguarda l'os per sviluppo, io uso Windows come macchina di sviluppo principale (scrivo principalmente typescript ed haskell) e non ho alcun problema, in particolare con WSL 2 che ti fa girare linux in maniera completa all'interno di windows.

Ora docker va una bomba, e anche molto meglio di come funzioni su osx se è per questo.

https://ubuntu.com/blog/ubuntu-on-wsl-2-is-generally-available

Hanno anche lanciato il Windows Terminal che è fantastico:
https://www.youtube.com/watch?v=8gw0rXPMMPE

Ho editato il mio commento e aggiunto altre info.

TL;DR: In Windows ora puoi usare Linux senza problemi.

Personalmente non tornerei ad usare MacOS e Linux per sviluppo non avrebbe piu senso essendo integrato in Windows.

Mi mancano alcune applicazioni di MacOS (Sketch e poco altro), ma finisce lì.

P.S. I ryzen 4000 sono treni rispetto ai portatili Intel e costano bene. Con nemmeno 1000 euro ti porti a casa 6c/12thread, 16gb ram, ssd in un bel case di alluminio con monitor decenti.

per me la cosa fondamentale è che il Mac rimanga tale nel senso che ho libertà di accesso al file system, possibilità di bypassare lo store, organizzazione finestre e così via
in questo senso macOS è profondamente diverso da iPadOS

se uno dei laptop sarà touch screen però con macOS sarà un metodo di input in più che a me può anche stare bene, non mi interessa e non lo compro ma non mi toglie niente come mac user
l'importante è che rimanga la distinzione sotto il cofano, non ho certo voglia di usare una sorta di iPadOS anche su un desktop...

Ciò lo vedremo con le future versioni di macOS 11... Ma, a mio parere, visto l'andazzo in Apple, non è detto che mettano delle limitazioni anche lì, soprattutto per lo Store.

Intanto con Big Sur cominciano a scomparire certi elementi da sempre presenti in OS X/macOS come Network Utility! :rolleyes:

Il mio problema è che non sopporto la politica ms per la gestione degli aggiornamenti di sto cavolo di windows 10, e poi ha un'incoerenza grafica che davvero mi da sui nervi:muro: Ma quest'ultimo punto diciamo che è un problema mio:D . Avevo provato qualche mese con linux ma poi tra file office che mi passavano, la totale mancanza della suite adobe ecc mi ha fatto ritornare su windows forzatamente. Diciamo che ho visto in macos il perfetto equilibrio che cerco. Ma con sta storia di ARM adesso mi hanno messo in crisi. Perché se davvero la virtualizzazione di os x86 è impossibile se li tengono.

Anche MacOS soffre della problematica degli aggiornamenti, a volte forzati. Quante volte non ho riavviato il mac per mesi per evitare aggiornamenti, figurati :D

Linux in WSL lo usi per sviluppo, il resto lo fai in Windows.

Per l'incoerenza grafica non so che dirti, a me l'ui e il design di Win 10 piace, ci sono sempre i temi poi, anche custom, anche per renderlo praticamente uguale a macos.

Comunque è improbabile non si possano installare software terzi su MacOS 11, come faresti a sviluppare altrimenti..?

Ciò lo vedremo con le future versioni di macOS 11... Ma, a mio parere, visto l'andazzo in Apple, non è detto che mettano delle limitazioni anche lì, soprattutto per lo Store.

Intanto con Big Sur cominciano a scomparire certi elementi da sempre presenti in OS X/macOS come Network Utility! :rolleyes:

Come è scomparsa network utility!!! ma che sono matti?

Come è scomparsa network utility!!! ma che sono matti?

Nella prima Beta di Big Sur l'app Network Utility è stata completamente rimossa.
Chi avesse bisogno dei suoi strumenti può usare i comandi diretti tramite Terminale, altrimenti affidarsi ad programmi di terze parti.
Comunque già in Mojave e Catalina Network Utility è stata rimossa dal folder Applicazioni e tumulata nella libreria di sistema.

Nella prima Beta di Big Sur l'app Network Utility è stata completamente rimossa.
Chi avesse bisogno dei suoi strumenti può usare i comandi diretti tramite Terminale, altrimenti affidarsi ad programmi di terze parti.
Comunque già in Mojave e Catalina Network Utility è stata rimossa dal folder Applicazioni e tumulata nella libreria di sistema.

Ma perchè!? Vogliono ipadizzare OSX?
Per fortuna non ho bisogno di un mac per lavorare faccio tutt'altro...

Ma perchè!? Vogliono ipadizzare OSX?
Per fortuna non ho bisogno di un mac per lavorare faccio tutt'altro...

Probabile... magari il fine ultimo di tutto ciò è proprio far convergere iPad e Macintosh visto il totale annullamento di architettura hardware. Vedremo tra un paio di anni.... :rolleyes:

però dai, si sta parlando di una Beta, la 1 e per quello che gli sviluppatori stanno vedendo in questi due giorni non va neanche così male anzi

Per l'incoerenza grafica non so che dirti, a me l'ui e il design di Win 10 piace, ci sono sempre i temi poi, anche custom, anche per renderlo praticamente uguale a macos.

Uso Windows, ho avuto OSX, uso tutt'ora Windows. Che l'interfaccia ti piaccia posso capirlo, nemmeno a me dispiace... ma che sia incoerente, a tratti vecchia e a tratti poco curata è un dato di fatto. Basta anche solo affiancare la schermata delle impostazioni con una finestra qualunque di Explorer, sembra di vedere una Fiat Panda 30 di fianco all'ultimo modello. Può anche piacerti la vecchia ma è appunto vecchia. Windows è così.
MacOS a livello di animazioni, trasparenze, ombre, cura dei particolari, sfondi preinstallati, rendering dei caratteri etc, è anni luce avanti.
So che sono tutte cose modificabili, anche facilmente... ma è da fare, esteticamente MacOS è già bello e pronto.

Io volendo passare a macbook pro (programmazione js, typescript ecc) posso prendere un x86 o meglio aspettare (ma quanto:confused: ) ARM? Mi hanno sconvolto i piani con sti annunci, stavo già per prendere un macbook pro 13 pollici con intel decima generazione :muro:

compra e non ci pensare, si parla di due anni prima di sostituire tutta la lineup
Non si sa quando usciranno MacBook Air o Pro con la nuova architettura

compra e non ci pensare, si parla di due anni prima di sostituire tutta la lineup
Non si sa quando usciranno MacBook Air o Pro con la nuova architettura

nel 2021 sicuramente saranno sul mercato almeno gli Air ma presumo anche i Pro 13 almeno i base senza GPU discreta
io oggi comprerei Intel, ma solo a prezzo vantaggioso se no non ne vale la pena, al momento di venderli usati avranno un valore molto ridotto a differenza del passato

una considerazione sui Mac touchscreen: sui Mac ARM gireranno nativamente le app per iPad e iPhone, ovviamente pensate per il touchscreen
in alcuni casi si può usare il mouse, ma le gesture con più dita come fai a farle? potrebbero usare il trackpad, ma sembra un compromesso, mentre un Mac touchscreen ti darebbe la stessa esperienza d'uso del iPad
lo sviluppatore può evitarlo, ma è chiaro che se la tua app gira bene hai tutto l'interesse a fornirla su un'altra piattaforma, senza fare niente nemmeno il giro di Catalyst
pensate ai giochini o a certe utility, l'app store di iOS è pieno di quella roba e la gente la scarica
magari ti serve il Mac perché lo preferisci a un iPad, ma quando usi quelle app lo vuoi fare con il touchscreen

Secondo quale principio esattamente Apple non sarebbe capace di offrire performance paragonabili alle CPU x86 di Intel?

Anandtech la pensa diversamente dopo aver condotto molteplici test sull'A13:

https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/4

SPECint è un benchmark 100% CPU.
Il fatto che Apple usi ISA ARM non significa che un core "super" wide come Lightning non sia in grado di performare come una cpu Intel. Sarebbe ora di finirla con questa aria mitologica di x86 sinceramente.
Intanto:
- non c'è ancora arrivata sugli interi, ed è indietro sulle prestazioni FP;
- è dietro una micro-architettura x86 vecchia di 5 anni (Skylake);
- Apple usa un design estremamente aggressivo (basti confrontare i diagrammi delle micro-architetture) con una spaventosa quantità di risorse a disposizione (anche qui basti confrontare gli elementi micro-architetturali: numero di istruzioni decodificate per ciclo di clock, numero di istruzioni eseguite per ciclo di clock, numero di porte d'esecuzione, dimensioni delle cache L1, L2, branch predictor, reservation station, etc.), tant'è che i suoi core ad alte prestazioni sono enormi.

Negli anni a venire Apple potrà limare un po' le prestazioni, e affidarsi per lo più ai progressi del processo produttivo di TSMC, mentre Intel ha in programma l'arrivo di nuove micro-architetture che, per il solo IPC, da Skylake arriveranno a un incremento dell'80%. Questo perché ha ancora parecchio da giocarsi (vedi ultimo punto del precedente elenco).
Boh
Solo io ho notato a che frequenze girano quelle cpu Intel ?
No perché a 1.1-1.2 Ghz consumeranno poco ma ho come l' impressione che non vadano poi così veloci :mc:
Perché se parliamo di cpu a basso consumo gli ARM possono sicuramente dire la loro
Il problema è sostituire le cpu desktop o professionali
Esattamente.
Su Fugaku le cpu fanno di tutto e di più, uno dei punti di forza che ha è un enorme banda di I/O (che crescerà ancora di più nelle versioni di successive di A64FX) ed una versatilità maggiore (eccelle sia nei carichi "da gpu" che in quelli "da cpu").
Il rapporto prestazioni/watt è 3 volte superiore agli Xeon attualmente sul mercato, che è un bel vantaggio anche per quel che riguarda i costi operativi (Fugaku si ciuccia più di 22MWatt, una soluzione con potenza di calcolo equivalente basata du Xeon richiederebbe più di 60MWatt).
Inoltre gli ARM di punta possono permettersi di implementare solo AArch64+SVE senza avere requisiti di retrocompatibilità ... e guadagnando pure "compatibilità in avanti" a livello di software applicativo.
L'implementazione di SVE su A64FX usa registri a 512bit, ma lo stesso software fatto girare su un hardware futuro con SVE a 2048bit sfrutterebbe al massimo anche tale architettura.
Quindi ad esempio si potrebbero pure realizzare sistemi big.LITTLE dove i core "big" hanno SVE a 2048bit mentre i "little" delle SVE a 128bit e lo stesso codice girerebbe su entrambi senza modifiche).
Insomma, considerando che ARM stessa ha collaborato con Fujitsu nella progettazione ed ottimizzazione architetturale degli A64FX, non mi stupirei se i frutti di tale collaborazione apparissero anche su cpu di fascie più basse.
Voglio proprio vedere le SVE a 2048, coi problemi di clock skew che ne derivano.
Intel ha già problemi con le AVX-512, che devono girare a clock decisamente più bassi persino delle AVX a 256 bit.

Per il resto è vero: Intel si porta dietro il legacy di più 40 anni, mentre chi usa ARM può ritagliarsi l'ISA come vuole.

Per il resto e come qualcuno ha già detto, i benchmark effettuati lasciano il tempo che trovano.
Quando Apple passò dai PowerPC agli x86, sbandierò prestazioni fino a 4 volte superiori rispetto ai G5 (quando il giorno prima sbandierava prestazioni fino al doppio più veloce rispetto ai PC).
Qui non c'è nulla del genere: il silenzio. Soltanto un generico "migliori prestazioni per watt". Che vuol dire tanto per dispositivi mobili, ma non per desktop e server (vabbé che Apple ne è uscita da un bel pezzo ormai)...

Io ho paura per l'obsolescenza software.

Esempio: ho un mac con High Sierra, sistema che mi risulta ancora supportato fino a che non esce Big Sur.

Stamattina volevo provare Parallels Desktop da App Store. Non me lo fa installare perché vuole almeno Mac OSX 10.14.6.

Se vado sul sito Parallels posso comprarlo e usaro anche su High Sierra.

Morale, se fanno tutto su ARM e spostano su AppStore tante applicazioni, e già oggi imac App Store non permette di scaricare versioni precedenti di una applicazione, che impatto avremo noi acquirenti ? Saremo costretti ad aggiornare più spesso i computer per obsolescenza programmata?

Io ho paura per l'obsolescenza software.

Esempio: ho un mac con High Sierra, sistema che mi risulta ancora supportato fino a che non esce Big Sur.

Stamattina volevo provare Parallels Desktop da App Store. Non me lo fa installare perché vuole almeno Mac OSX 10.14.6.

Se vado sul sito Parallels posso comprarlo e usaro anche su High Sierra.

Morale, se fanno tutto su ARM e spostano su AppStore tante applicazioni, e già oggi imac App Store non permette di scaricare versioni precedenti di una applicazione, che impatto avremo noi acquirenti ? Saremo costretti ad aggiornare più spesso i computer per obsolescenza programmata?
Ad apple non dispiacerebbe, già ora come ora con il fatto che i mac sono sostanzialmente non riparabili con tutto saldato pare proprio abbiano preso quella direzione.

Bah io non so come andrà a finire ma io entro fine estate devo acquistare il portatile. Andrò di x86 tanto per sviluppo web penso andrà bene almeno un 5/6 anni tutti. Poi si vedrà. Anche perché sono proprio a piedi adesso.

Sei obbligato a comprare Apple per via di qualche tool specifico?

Se office e adobe sbarcano su linux secondo me ci sarà un'impennata di adozione del pinguino :)

Idem, al momento uso prevalentemente windows per i giochi, i programmi e perché il portatile non gestisce al meglio l'autonomia.

Potrei affidarmi a wine ma non ho voglia poi se voglio usare linux ho sempre il Lenovo da combattimento con kali :)

Ora come ora tutti abbiamo l'ssd ma win10 su disco meccanico è un disastro eh, lentissimo

Obbligato non sono obbligato. Voglio levarni di torno Windows per tante ragioni maturate negli ultimi anni sopratutto per problemi con l'ultimo thinkpad che ho avuto tutti derivati da Windows. Ho provato con Linux ma non è fattibile ancora per le mie esigenze. Voglio un OS unix-like con tutti quei software commerciali (Adobe, office ecc) che all'occorrenza posso utilizzare senza problemi che Linux purtroppo non mi fornisce.
Hai provato Windows 10 con WSL2?

Capito. E sui gusti non si discute. :)

Obbligato non sono obbligato. Voglio levarni di torno Windows per tante ragioni maturate negli ultimi anni sopratutto per problemi con l'ultimo thinkpad che ho avuto tutti derivati da Windows. Ho provato con Linux ma non è fattibile ancora per le mie esigenze. Voglio un OS unix-like con tutti quei software commerciali (Adobe, office ecc) che all'occorrenza posso utilizzare senza problemi che Linux purtroppo non mi fornisce.

Strano, in azienda sono anni che abbiano thinkpad serie T e mai un problema

Comunque ti ribadisco che i macbook pro 2018 in poi sono dei forni su cui è difficile mettere le mani sopra.

https://lmgtfy.com/?q=macbook+pro+hot

Aspettati:

- brew cask install macs-fan-control
il controller delle ventole del macbook da svariati problemi e a volte le ventole non partono nemmeno, vanno controllate via terminale.
Altrimenti http://tbswitcher.rugarciap.com/

- rumore di ventole perenne se programmi, specialmente d'estate, fisso con docker

- multi monitor = calore, tanto calore, specie se li attacchi a sx

- prestazioni basse e quantità di memoria bassa. Il mbp ha di base la stessa memoria di un raspberry pi da 70 euro. Fai tu. Per 8 gb in piu paghi circa 200 euro in piu. Inutile dire che salire di frequenze e modelli di cpu è un problema per il calore.

Cioè non riesco a capire questa tua incomprensibile fissa per "ommioddio non mi piace la grafica windows", quando qualsiasi macbook pro skylake in su è una immensa fonte di problemi.

Altre cose a caso:

- caricare dal lato sinistro del macbook, via adattatore, può portare al bruciare la componentistica, usa sempre la parte dx (idem per monitor) (ah, se hai il macbook non stra carrozzato non hai due usb-c a dx, quindi devi per forza farlo a sx)

- stai comprando roba che è già programmata per essere obsoleta tra qualche anno

O ti prendi un notebook e ci metti linux/windows o aspetti arm (ma lì puoi dire addio al dual boot, potrebbe essere importante, anche se io non l'ho mai usato).

Comprare un mbp skylake in poi è un disastro di acquisto sotto tutti i punti di vista.

Io non so quanto tu abbia usato un mbp in vita tua, ma il case in alluminio diventa davvero bollente anche con i modelli vecchi, con quelli degli ultimi anni è inutilizzabile.

Questa tua fissa per il mbp mi sa tanto, onestamente, di una persona che un macbook non l'ha mai usato a sufficienza.

Io lo faccio per lavoro e ringrazio dio di avere un fisso a casa e un altro portatile win.

Sia chiaro, non ho nulla in contrario ad Apple, non vedo l'ora esca il nuovo ipad pro per comprarlo ad esempio e ho avuto 4 mbp in vita mia, ma poichè hai detto che fai il dev ti stai fissando con roba che non serve e che andrà a influire molto piu negativamente sul tuo lavoro del quanto lo faccia l'aspetto dell'UI che tanto ti interessa.

In compenso, però, macos è d'obbligo se devi compilare per iOS e molto utile per testare roba su safari (che è l'internet explorer dei browser).

Dammi retta, non ha senso prendere un mbp ora, (tra l'altro se fai il dev non te lo dovrebbe dare il tuo datore di lavoro...?) quando tra qualche mese escono le versioni arm che risolveranno il 90% dei problemi attuali dei mbp.

Voglio proprio vedere le SVE a 2048, coi problemi di clock skew che ne derivano.
Intel ha già problemi con le AVX-512, che devono girare a clock decisamente più bassi persino delle AVX a 256 bit.
I tipi di ARM hanno ben chiaro il problema, infatti il set di istruzioni è stato pensato per porre il minor numero di vincoli possibile per quel che riguarda l'implementazione.
Invece di visualizzare l'implementazione in termini di "registri a 2048bit", visualizzala come "gruppo di 16 registri a 128bit" e relative ALU a 128bit che in base all'implementazione vanno da 1 a 16, con tutte le possibili varianti (es: solo 8 ALU ma a frequenza di clock doppia).


Per il resto è vero: Intel si porta dietro il legacy di più 40 anni, mentre chi usa ARM può ritagliarsi l'ISA come vuole.

Si,
ARM Ltd. ha creato nel tempo una famiglia di set di istruzioni che viene incontro un po' a tutte le esigenze, con il passaggio ai 64bit hanno creato un nuovo set di istruzioni "da zero" con tutti i vantaggi che ne derivano, ma secondo me Risc-V è ancora più interessante in termini di versatilità e potenziale di crescita.

I tipi di ARM hanno ben chiaro il problema, infatti il set di istruzioni è stato pensato per porre il minor numero di vincoli possibile per quel che riguarda l'implementazione.
Invece di visualizzare l'implementazione in termini di "registri a 2048bit", visualizzala come "gruppo di 16 registri a 128bit" e relative ALU a 128bit che in base all'implementazione vanno da 1 a 16, con tutte le possibili varianti (es: solo 8 ALU ma a frequenza di clock doppia).
Questo discorso lo si può applicare a qualunque architettura, però, ed è stato già fatto in passato.

Ad esempio la prima implementazione delle SSE (con vettori a 128 bit) arrivò col Pentium III, che però "spezzava" tali istruzioni in coppie di uop ognuna in grado di gestire 64 bit dei 128 bit.

Il problema con queste implementazioni è che ti serve un backend in grado di eseguire il doppio delle uop per ciclo di clock, se vuoi mantenere lo stesso data rate, il che non è affatto possibile (i costi esplodono all'aumentare del numero di porte d'esecuzione).
Si,
ARM Ltd. ha creato nel tempo una famiglia di set di istruzioni che viene incontro un po' a tutte le esigenze, con il passaggio ai 64bit hanno creato un nuovo set di istruzioni "da zero" con tutti i vantaggi che ne derivano, ma secondo me Risc-V è ancora più interessante in termini di versatilità e potenziale di crescita.
Sulla potenzialità di crescita concordo, perché la stanno abbracciando praticamente tutti i produttori di processori, e principalmente perché non ci sono royalty da pagare.

Non concordo affatto sulla versatilità, perché è un'ISA progettata da accademici, e se ne vedono tutti i limiti.

Hanno cercato a tutti i costi la "purezza" nella struttura degli opcode, che li hanno costretti a notevoli compromessi. Salvo poi calare le braghe quando hanno sbattuto le corna sul design dell'estensione SIMD (che doveva essere pronta almeno un paio d'anni fa, se non ricordo male, e ci stanno ancora lavorando), che li ha sostanzialmente obbligati a sfornare parecchi formati per gli opcode.

Per non parlare dei proclami sulle estensioni immodificabili (una volta finalizzati), salvo poi essersi accorti della colossale sciocchezza di aver obbligato a implementare anche le divisioni in hardware anche se ti servono soltanto le moltiplicazioni, visto che l'estensione standardizzata li prevedeva obbligatoriamente entrambi. Per risolvere il problema hanno nuovamente calato le braghe e tirato fuori le "sottoestensioni", dove puoi avere soltanto le moltiplicazioni. Ma è soltanto un esempio, perché di questi errori ne hanno commessi diversi, e creato apposite sottoestensioni per metterci una pezza.
Il bello è che hanno ancora la faccia di bronzo di affermare che non c'è frammentazione nell'ISA...

Dulcis in fundo, hanno voluto mantenere il set d'istruzione di base ridotto all'osso per salvaguardare la purezza (RISC -> set d'istruzioni ridotto), ma si sono scontrati sia con la scarsa densità di codice (risolto, in parte, con l'estensione "compressa", C) sia con problemi prestazionali (dovuti al fatto di dover eseguire più istruzioni rispetto ad altre architettura, per eseguire gli stessi compiti).
Per cercare di metterci una pezza hanno suggerito (nonché pubblicato entusiastici paper per evangelizzare la trovata "geniale") di implementare nel frontend il macro-op fusion (roba che Intel fa da una vita. E meno male che tanti esperti di questo forum dicono che non innovi) per convertire una coppia di istruzioni a 16-bit compresse in una sola istruzione a 32 bit, in modo da risolvere almeno il problema delle prestazioni (ma dovendo far ricorso sia al set d'istruzioni compresso, sia snaturando la semplicità del frontend di cui andavano fieri, implementando un meccanismo di pattern-matching delle istruzioni che costringe pure ad allungare la pipeline).

E sempre su quest'onda la ciliegina sulla torta è rappresentata da una sola modalità d'indirizzamento per referenziare la memoria. Il che costringe i compilatori a generare codice apposito quando serve referenziare array di elementi (operazione tutt'altro che rara, come sappiamo), quando altre architetture risolvono il problema con l'apposita modalità d'indirizzamento [registro base + registro indice scalato + offset].

Mi fermo qui, che è meglio.

Aggiungo soltanto che ARM con ARMv8/ARM64 ha fatto un ottimo lavoro, e pur avendo commesso l'errore di non implementare un set d'istruzioni compresso / a 16-bit (come Thumb, insomma), ha dato una bella lezione di come si progetta un'ISA che tenga conto di come funziona il mondo reale e delle esigenze degli sviluppatori.

Sulla potenzialità di crescita concordo, perché la stanno abbracciando praticamente tutti i produttori di processori, e principalmente perché non ci sono royalty da pagare.

Fossero solo le royalties il problema allora OpenRisc (https://openrisc.io/), Amber (https://opencores.org/projects/amber) (core ARMv2, set d'istruzioni non coperto da brevetti), J2/J4/J6 (http://0pf.org/j-core.html) (reimplementazioni di Hitachi SH-2, SH-4 ed SH4 a 64bit di cui sono scaduti i brevetti) sarebbero già ovunque (specialmente AMBER e J2 visto che hanno un ecosistema software completo).


Non concordo affatto sulla versatilità, perché è un'ISA progettata da accademici, e se ne vedono tutti i limiti.

A parte che allo sviluppo delle attuali specifiche di Risc-V concorrono anche aziende, gli accademici coinvolti avevano già una certa esperienza pratica nella progettazione di processori ed hanno attinto da quanto sviluppato sia a livello accademico che commerciale.

Inoltre non si parla di un ISA, ma di una famiglia di ISA per cui si può sviluppare un ecosistema software ed hardware comune.
Attualmente i "set di istruzioni base" sono RV32I, RV32E, RV64I con inoltre "predisposizioni" per un eventuale RV128I.
Ed oltre a questo l'idea di base è di lasciare il più libera possibile l'implementazione architetturale mantenendo comunque buona compatibilità a livello software.

I limiti mi sembrano più che altro dei compromessi tra requisiti contrastanti, ma quelli ci sono in tutte le architetture (dagli x86 agli ARM).


Hanno cercato a tutti i costi la "purezza" nella struttura degli opcode, che li hanno costretti a notevoli compromessi. Salvo poi calare le braghe quando hanno sbattuto le corna sul design dell'estensione SIMD (che doveva essere pronta almeno un paio d'anni fa, se non ricordo male, e ci stanno ancora lavorando), che li ha sostanzialmente obbligati a sfornare parecchi formati per gli opcode.

Attualmente Risc-V come famiglia di architetture è ancora in evoluzione ed alcune delle estensioni sono ancora in fase di definizione, specialmente quelle su cui ci sono punti di vista molto diversi.
Nel caso delle SIMD sono state "bloccate" perche non c'era un bisogno pressante di averle subito e perchè si volevano valutare bene le questioni sia teoriche che pratiche e commerciali a riguardo.
Se non sbaglio ora l'idea di massima è avere delle estensioni "P" (Packed SIMD) che usano i GPR e delle estensioni "V" che introducono un set di registri vettoriali con istruzioni simili alle SVE di Arm Ltd. come concetto.


Per non parlare dei proclami sulle estensioni immodificabili (una volta finalizzati), salvo poi essersi accorti della colossale sciocchezza di aver obbligato a implementare anche le divisioni in hardware anche se ti servono soltanto le moltiplicazioni, visto che l'estensione standardizzata li prevedeva obbligatoriamente entrambi. Per risolvere il problema hanno nuovamente calato le braghe e tirato fuori le "sottoestensioni", dove puoi avere soltanto le moltiplicazioni. Ma è soltanto un esempio, perché di questi errori ne hanno commessi diversi, e creato apposite sottoestensioni per metterci una pezza.
Il bello è che hanno ancora la faccia di bronzo di affermare che non c'è frammentazione nell'ISA...

Uhm! Sei sicuro della faccenda della divisione ? Per quanto ne so se si dichiara che una cpu Risc-V supporta l'estensione M, deve avere sia moltiplicazioni che divisioni, solo che l'implementazione viene lasciata libera (quindi ad esempio si può decidere di implementare la divisione in modo "economico", mica è obbligatorio che le divisioni siano eseguite in un singolo ciclo).

Poi, devo aggiungere che in 35 anni e passa di sviluppo software con ogni tipo di microprocessore e qualche DSP tanto per non farmi mancare niente, se hai bisogno della moltiplicazione in hardware, il 99% delle volte torna utile anche la divisione in hardware (magari lentissima, ma sempre meglio di doverla fare in software) oppure la complessità aggiuntiva del divisore è trascurabile rispetto al core nel suo complesso.


Dulcis in fundo, hanno voluto mantenere il set d'istruzione di base ridotto all'osso per salvaguardare la purezza (RISC -> set d'istruzioni ridotto), ma si sono scontrati sia con la scarsa densità di codice (risolto, in parte, con l'estensione "compressa", C) sia con problemi prestazionali (dovuti al fatto di dover eseguire più istruzioni rispetto ad altre architettura, per eseguire gli stessi compiti).

Non è che sia il problema che pensi, c'è ancora spazio nei set di istruzioni per aggiungere ulteriori estensioni utili.
Inoltre le estensioni C erano previste praticamente dall'inizio del progetto, non è che sono state aggiunte dopo come ad esempio è avvenuto con ARM, MIPS ed altre architetture.


Per cercare di metterci una pezza hanno suggerito (nonché pubblicato entusiastici paper per evangelizzare la trovata "geniale") di implementare nel frontend il macro-op fusion (roba che Intel fa da una vita. E meno male che tanti esperti di questo forum dicono che non innovi) per convertire una coppia di istruzioni a 16-bit compresse in una sola istruzione a 32 bit, in modo da risolvere almeno il problema delle prestazioni (ma dovendo far ricorso sia al set d'istruzioni compresso, sia snaturando la semplicità del frontend di cui andavano fieri, implementando un meccanismo di pattern-matching delle istruzioni che costringe pure ad allungare la pipeline).


Veramente la macro-op fusion era prevista fin dall'inizio, in particolare per ottimizzare l'esecuzione di jump brevi "in avanti" producendo una sequenza di micro-op condizionali e senza dover eseguire una jump prediction, come pure per ottimizzare le moltiplicazioni da XLEN bit con risultato a 2*XLEN bit, le divisioni+resto e le divisioni con check del caso di divisione per zero "senza usare eccezioni/trap".
E' solo una questione di implementazione.
Se serve giusto un processore senza tante pretese è possibile farne un implementazione economica in-order, senza jump-prediction, senza macro-op-fusion e pure senza istruzioni compatte.
Se invece vuoi qualcosa di più potente sono già previste un sacco di possibilità ed i compilatori possono generare codice che sfrutta bene l'hardware in entrambi i casi senza dover ricompilare (nel caso in cui ci sia il supporto dell' estensione C, in caso contrario basta ricompilare cambiando un flag, come si fa con gli ARM)


E sempre su quest'onda la ciliegina sulla torta è rappresentata da una sola modalità d'indirizzamento per referenziare la memoria. Il che costringe i compilatori a generare codice apposito quando serve referenziare array di elementi (operazione tutt'altro che rara, come sappiamo), quando altre architetture risolvono il problema con l'apposita modalità d'indirizzamento [registro base + registro indice scalato + offset].


Nel caso dei Risc-V il problema non è così grave come lo sarebbe su un architettura con meno registri e con set di istruzioni meno regolari.
In primo luogo, con le estensioni C diventa possibile generare sequenze di istruzioni "facili da fondere" che implementano [registro base + registro indice scalato + offset], in secondo luogo se si deve "scorrere" un array spesso si usa preincremento/postincremento (o a livello di codice sorgente o come ottimizzazione fatta dal compilatore quando identifica indicizzazioni "sequenziali") ed anche quel tipo di sequenza si presta bene ad essere fusa.


Aggiungo soltanto che ARM con ARMv8/ARM64 ha fatto un ottimo lavoro, e pur avendo commesso l'errore di non implementare un set d'istruzioni compresso / a 16-bit (come Thumb, insomma), ha dato una bella lezione di come si progetta un'ISA che tenga conto di come funziona il mondo reale e delle esigenze degli sviluppatori.

Risc-V non è che sia tanto da meno, permette di implementare le istruzioni "compresse" per risparmiare memoria e banda di I/O nel fetch di istruzioni ed al tempo stesso di macro-fonderle (tra loro o con istruzioni più "lunghe") se serve un architettura ad alte prestazioni tenendo conto delle esigenze di sviluppatori di software e progettisti di hardware.
Aggiungi il margine di crescita che ha a livello di "istruzioni ancora da assegnare" e ne vien fuori una famiglia di set di istruzioni mica male.

Per ora sono in commercio imlementazioni di Risc-V "per applicazioni embedded a basso costo", ma man mano che si finalizzano le varie estensioni mi sa che ne vedremo delle belle.
Poi non è da trascurare il fatto che Risc-V non ha bisogno di essere "il più potente di tutti" per avere successo e fare le scarpe ad ARM ed x86, gli basta avere prestazioni sufficienti ed avere un buon ecosistema software, senza contare che il fatto di essere libero da brevetti e già ora molto flessibile come possibili implementazioni lo rende estremamene interessante in settori in cui servono fornitori indipendenti per mettersi al riparo da brutte sorprese oppure chip "speciali" che devono avere implementazioni molto particolari ed al tempo stesso un buon ecosistema software già disponibile.

Non è un caso se ad esempio OrzakIC stia sviluppando una "cpu venusiana (https://www.ozarkic.com/2020/05/26/ozark-ic-to-continue-ultra-high-temperature-processor-development-for-nasa/)" per conto della NASA basandola proprio su Risc-V.
cpu venusiana = cpu realizzata su substrato di SiC (carburo di silicio) capace di funzionare a 500°C di temperatura senza sistemi di raffreddamento (la temperatura al suolo su Venere sta sui 460°C).

Fossero solo le royalties il problema allora OpenRisc (https://openrisc.io/), Amber (https://opencores.org/projects/amber) (core ARMv2, set d'istruzioni non coperto da brevetti), J2/J4/J6 (http://0pf.org/j-core.html) (reimplementazioni di Hitachi SH-2, SH-4 ed SH4 a 64bit di cui sono scaduti i brevetti) sarebbero già ovunque (specialmente AMBER e J2 visto che hanno un ecosistema software completo).
No, non sono soltanto le royalty chiaramente, anche se è il fattore più importante.

Le ISA che hai citato sono troppe legate all'embedded, mentre RISC-V s'è prefisso di essere utilizzata dall'embedded low-cost/resource all'HPC.
A parte che allo sviluppo delle attuali specifiche di Risc-V concorrono anche aziende, gli accademici coinvolti avevano già una certa esperienza pratica nella progettazione di processori ed hanno attinto da quanto sviluppato sia a livello accademico che commerciale.
No, è partito tutto come progetto accademico (per rimpiazzare l'ISA studiata nei corsi universitari con una più moderna), e il core dell'ISA più altre estensioni base/comuni sono state sviluppate lì.

Soltanto successivamente (e da un po' di anni) si sono unite delle aziende, una volta che il progetto ha cominciato a prendere con delle implementazioni (le prime realizzate sempre nelle università) e il supporto software.

Poi che gli accademici avessero esperienza non ha impedito loro di commettere degli errori, per l'appunto.
Inoltre non si parla di un ISA, ma di una famiglia di ISA per cui si può sviluppare un ecosistema software ed hardware comune.
Attualmente i "set di istruzioni base" sono RV32I, RV32E, RV64I con inoltre "predisposizioni" per un eventuale RV128I.
Ed oltre a questo l'idea di base è di lasciare il più libera possibile l'implementazione architetturale mantenendo comunque buona compatibilità a livello software.
RV32E è soltanto una castrazione di RV32I, che peraltro vorrebbero pure cambiare visto che si sono accorti di alcune scelte sbagliate (tanto per cambiare) proprio nell'estensione C del set compresso, che per questa versione embedded sono non sono inutili (occupano opcode inutilizzabili in quest'ambito) ma che potrebbero essere usate per aggiungere altre preziose (nonché ben più utili) istruzioni.
I limiti mi sembrano più che altro dei compromessi tra requisiti contrastanti, ma quelli ci sono in tutte le architetture (dagli x86 agli ARM).
Sì, ci sono in tutte le architetture, ma quelle che citi si portano dietro decenni di legacy.

Qui parliamo di un'ISA completamente nuova. Di pacca. E, con tutti gli use-case ed errori del passato da tenere bene a mente, avrebbero dovuto tirarla fuori senza gli errori madornali che ho citato.
Attualmente Risc-V come famiglia di architetture è ancora in evoluzione ed alcune delle estensioni sono ancora in fase di definizione, specialmente quelle su cui ci sono punti di vista molto diversi.
Dovrebbero darsi una mossa, specialmente considerando quanti hanno abbracciato quest'ISA, e quante "teste pregiate" ci siano dietro ormai (provenienti da tante università e aziende).

Il progetto è nato nel 2011, e di tempo ne hanno avuto abbastanza.
Nel caso delle SIMD sono state "bloccate" perche non c'era un bisogno pressante di averle subito e perchè si volevano valutare bene le questioni sia teoriche che pratiche e commerciali a riguardo.
Se non sbaglio ora l'idea di massima è avere delle estensioni "P" (Packed SIMD) che usano i GPR e delle estensioni "V" che introducono un set di registri vettoriali con istruzioni simili alle SVE di Arm Ltd. come concetto.
No, è successo di peggio, invece. Sono partiti con un'estensione SIMD spaziale che sarebbe stata flessibilissima e fichissima, facendo un'immensa propaganda e con profusioni d'incenso (basti vedere i talk e le presentazioni di un po' di anni fa).

Salvo poi dover togliere di mezzo il cavallo di battaglia, la punta di diamante di questa estensione (il polimorfismo dei tipi di dati), perché chi realizza microarchitetture ha fatto notare che l'implementazione sarebbe stato parecchio complicata (e probabilmente le prestazioni ne avrebbero risentite).
E non è che ci volesse un'arca di scienze per capirlo, eh!

Inoltre avrebbero voluto mantenere la struttura base degli opcode, in modo a rendere semplice la decodifica. Invece anche qui hanno dovuto fare retromarcia perché per le istruzioni SIMD tale struttura è troppo limitata e castrante, specialmente perché hanno voluto anche aggiungere delle caratteristiche sono molto utili in quest'ambito (primo fra tutti le "maschere". Già introdotte da Intel con Larrabee prima, Xeon Phi poi, e con AVX-512).
Questo li ha costretti a tirare fuori parecchi opcode per compattare al meglio lo spazio a disposizione per infilarci i campi addizionali che servivano allo scopo.
Altrimenti avrebbero dovuto utilizzare opcode a 48 bit, mandando in frantumi la semplicità dell'ISA "base".

Nel frattempo, visto che le estensioni SIMD vettoriali a lunghezza variabile dei vettori (come SVE di ARM, appunto) sono overkill in ambito embedded, hanno dovuto aggiungere le estensioni SIMD "packed" classiche (come quelle che conosciamo), che tanto le aziende avevano già deciso per conto loro di implementare, visto che erano e rimangono utili (specialmente in ambito embedded. Dove peraltro usano i registri GP per risparmiare sull'implementazione dell'ISA).
Uhm! Sei sicuro della faccenda della divisione ? Per quanto ne so se si dichiara che una cpu Risc-V supporta l'estensione M, deve avere sia moltiplicazioni che divisioni, solo che l'implementazione viene lasciata libera (quindi ad esempio si può decidere di implementare la divisione in modo "economico", mica è obbligatorio che le divisioni siano eseguite in un singolo ciclo).
Sono assolutamente sicuro (anche perché seguo RISC-V da parecchio tempo ormai). :)

Infatti se vai prendere una vecchia versione del PDF con le specifiche dell'ISA trovi soltanto l'estensione M, per l'appunto (e che ti obbliga a implementare tutti i tipi di moltiplicazione e divisione definiti), mentre le più recenti riportano delle sotto-estensioni in cui sono definite soltanto le moltiplicazioni.
Poi, devo aggiungere che in 35 anni e passa di sviluppo software con ogni tipo di microprocessore e qualche DSP tanto per non farmi mancare niente, se hai bisogno della moltiplicazione in hardware, il 99% delle volte torna utile anche la divisione in hardware (magari lentissima, ma sempre meglio di doverla fare in software) oppure la complessità aggiuntiva del divisore è trascurabile rispetto al core nel suo complesso.
No, invece non è trascurabile, e sono state le aziende che lavorano in ambito embedded a fare pressioni per introdurre le sotto-estensioni, e liberarsi della divisione in hardware.

Spesso a loro serve soltanto la moltiplicazione, che tante volte consente di evitare la divisione moltiplicando opportunamente il registro con un determinato valore e scalando (shiftando) poi il risultato. Roba ordinaria, comunque: lo fanno già alcuni compilatori.
Non è che sia il problema che pensi, c'è ancora spazio nei set di istruzioni per aggiungere ulteriori estensioni utili.
Eh... no! L'ISA base più altre estensioni sono ormai finalizzate e non si possono toccare (hanno fatto questa promessa proprio per avere un'ISA stabile, e adesso la devono mantenere).

Per cui di aggiunte non se ne parla. Ma per risolvere le rogne saranno costretti ad aggiungere delle apposite estensioni, appunto. Che poi è la stessa cosa, anche se così salvano formalmente l faccia.

Ma tanto così facendo aumenteranno la frammentazione.
Inoltre le estensioni C erano previste praticamente dall'inizio del progetto, non è che sono state aggiunte dopo come ad esempio è avvenuto con ARM, MIPS ed altre architetture.
Non è così. Nel progetto iniziale avevano previsto una futura estensione compressa, perché sapevano già che sarebbe servita, visto che l'ISA "base" avrebbe sicuramente sofferto di problemi di scarsa densità di codice (non che ci volesse molto a capirlo, guardando le istruzioni).

Ma non l'avevano definita. Questo è avvenuto dopo e in parallelo, con uno dei progettisti di RISC-V che ha proposto l'estensione C. Come puoi vedere dalla sua tesi. (https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-63.pdf)
Veramente la macro-op fusion era prevista fin dall'inizio, in particolare per ottimizzare l'esecuzione di jump brevi "in avanti" producendo una sequenza di micro-op condizionali e senza dover eseguire una jump prediction, come pure per ottimizzare le moltiplicazioni da XLEN bit con risultato a 2*XLEN bit, le divisioni+resto e le divisioni con check del caso di divisione per zero "senza usare eccezioni/trap".
Ancora una volta no. Mi spiace, ma è evidente che tu non segui attivamente lo sviluppo e il mondo di RISC-V in generale (lo seguo da anni e mi spazzo puntualmente tutta la documentazione prodotta, inclusi i video su YT dei talk su RISC-V nelle varie conferenze).

Adesso non lo trovo, ma il paper di Patterson & co., presentato qualche anno fa, nasce come proposta per risolvere quei problemi. Dunque una soluzione postuma.
E' solo una questione di implementazione.
Se serve giusto un processore senza tante pretese è possibile farne un implementazione economica in-order, senza jump-prediction, senza macro-op-fusion e pure senza istruzioni compatte.
Se invece vuoi qualcosa di più potente sono già previste un sacco di possibilità ed i compilatori possono generare codice che sfrutta bene l'hardware in entrambi i casi senza dover ricompilare (nel caso in cui ci sia il supporto dell' estensione C, in caso contrario basta ricompilare cambiando un flag, come si fa con gli ARM)
Che sia una questione di pura implementazione è pacifico. Ma, come dicevo, sono costretti ad aggiungere qualche stadio di pipeline per implementarlo. Soprattutto sono costretti a stravolgere il modello di semplicità di RISC-V, visto che tale implementazione ti costringe, ad esempio, a dover scrivere su 2 registri per "macro-op"/istruzione eseguita.

In ogni caso il macro-op fusion funziona soltanto con l'estensione C, che quindi diviene obbligatoria.
Nel caso dei Risc-V il problema non è così grave come lo sarebbe su un architettura con meno registri e con set di istruzioni meno regolari.
In primo luogo, con le estensioni C diventa possibile generare sequenze di istruzioni "facili da fondere" che implementano [registro base + registro indice scalato + offset], in secondo luogo se si deve "scorrere" un array spesso si usa preincremento/postincremento (o a livello di codice sorgente o come ottimizzazione fatta dal compilatore quando identifica indicizzazioni "sequenziali") ed anche quel tipo di sequenza si presta bene ad essere fusa.
Sì, ma rimane una pecca dell'ISA che hanno dovuto ammettere anche i progettisti dell'ISA davanti ad alcuni benchmark SPEC in cui il netto calo prestazionale (rispetto alle altre architetture) è dovuto proprio alla mancanza di modalità d'indirizzamento più complesse.

Cosa che, invece, ARM ha saputo ben prevedere e risolvere con ARMv8, che mette a disposizione diverse modalità d'indirizzamento complicate, molti utili in tanti casi comuni come quelli citati.

Reduced and Simple isn't always better. :O
Risc-V non è che sia tanto da meno, permette di implementare le istruzioni "compresse" per risparmiare memoria e banda di I/O nel fetch di istruzioni ed al tempo stesso di macro-fonderle (tra loro o con istruzioni più "lunghe") se serve un architettura ad alte prestazioni tenendo conto delle esigenze di sviluppatori di software e progettisti di hardware.
Sono tutte complicazioni che con un'ISA progettata meglio non ci sarebbero state.
Aggiungi il margine di crescita che ha a livello di "istruzioni ancora da assegnare" e ne vien fuori una famiglia di set di istruzioni mica male.
Ehm... no! Per quanto detto sopra, l'ISA base e diverse estensioni sono già state ratificate e sono intoccabili.

Aggiungere singole istruzioni per risolvere i problemi comuni di cui sopra richiederebbe la realizzazione di tante micro-estensioni, che farebbe aumentare ancora di più la frammentazione.

Certa roba sarebbe dovuta arrivare già nell'ISA base, anziché ridursi all'osso.

Che poi il paradosso è che tante estensioni SIMD sono farcite di istruzioni (alla faccia del set ridotto). Ad esempio quella per l'FPU ha persino istruzioni di minimo e massimo!

Ma si sono persi per strada tanta roba utile.
Per ora sono in commercio imlementazioni di Risc-V "per applicazioni embedded a basso costo", ma man mano che si finalizzano le varie estensioni mi sa che ne vedremo delle belle.
Non è così. Vedi sopra.

E non è un caso che una delle estensioni & implementazioni RISC-V più comuni e utilizzate è quella PULP dell'università di Zurigo, che di base aggiunge diverse estensioni custom che consentono di implementare loop in hardware, come pure istruzioni di load/store con pre/post-incremento del registro base. Quindi di fatto hanno colmato alcune di quelle lacune.
Ma PULP rimane un'estensione custom...
Poi non è da trascurare il fatto che Risc-V non ha bisogno di essere "il più potente di tutti" per avere successo e fare le scarpe ad ARM ed x86, gli basta avere prestazioni sufficienti ed avere un buon ecosistema software, senza contare che il fatto di essere libero da brevetti e già ora molto flessibile come possibili implementazioni lo rende estremamene interessante in settori in cui servono fornitori indipendenti per mettersi al riparo da brutte sorprese oppure chip "speciali" che devono avere implementazioni molto particolari ed al tempo stesso un buon ecosistema software già disponibile.
E su questo mi pare che ho avuto nulla da dire. Anzi, l'ho detto pure io che è un vantaggio.
Non è un caso se ad esempio OrzakIC stia sviluppando una "cpu venusiana (https://www.ozarkic.com/2020/05/26/ozark-ic-to-continue-ultra-high-temperature-processor-development-for-nasa/)" per conto della NASA basandola proprio su Risc-V.
cpu venusiana = cpu realizzata su substrato di SiC (carburo di silicio) capace di funzionare a 500°C di temperatura senza sistemi di raffreddamento (la temperatura al suolo su Venere sta sui 460°C).
Interessante. :)