Link alla notizia: https://www.hwupgrade.it/news/apple/apple-m1-sorprende-anche-in-emulazione-piu-veloce-di-tutti-gli-altri-mac-in-single-core-su-geekbench_93512.html

Stiamo assistendo a una vera e propria rivoluzione in campo informatico? Secondo i primi test su Geekbench le speranze ci sono, con Apple M1 che anche in emulazione è in grado di offrire qualche soddisfazione (soprattutto in single-core).

Click sul link per visualizzare la notizia.

Ok piedi per terra, però a questo punto evitiamo titoli click bait

Geekbench :asd:

Sono molto combattuto tra il nuovo air 16/512 ed il nuovo dell xps 2 in 1 16/512 con i7 evo, ballano meno di 100 euro di differenza in favore del Dell.
Il mac sarà ordinabile da domani, non credo molto a geekbench ma dubito che Apple sia cosi' stupida da abbandonare x86 se non avesse certezze che la sua soluzione non é altrettanto valida.
Sono certo che in termini di autonomia l'air sarà irraggiungibile, sulle performances resto scettico, ma ho la sensazione che ci sia qualcosa di buono.

Anche a me sembra un articolo clickbait. A parte l'affidabilità di Geekbench ma se veramente le prestazioni sono così stupefacenti che "il punteggio single-core di Rosetta 2 supera comunque qualsiasi altro Mac Intel, incluso l'iMac 2020 da 27 pollici con Intel Core i9-10910 a 3,6 GHz" (quindi figuriamoci in formato nativo Arm) allora non si capisce perché Apple non abbia presentato anche tutti gli iMac con l'M1 e magari anche dei Mac Pro versione base con l'M1... Non le mancano certamente le risorse per farlo.

Anche a me sembra un articolo clickbait. A parte l'affidabilità di Geekbench ma se veramente le prestazioni sono così stupefacenti che "il punteggio single-core di Rosetta 2 supera comunque qualsiasi altro Mac Intel, incluso l'iMac 2020 da 27 pollici con Intel Core i9-10910 a 3,6 GHz" (quindi figuriamoci in formato nativo Arm) allora non si capisce perché Apple non abbia presentato anche tutti gli iMac con l'M1 e magari anche dei Mac Pro versione base con l'M1... Non le mancano certamente le risorse per farlo.

hanno presentato 3 modelli.
gli altri due avranno un evento separato (se non due eventi).
e poi magari hanno un sacco di "scorte" di Intel da smaltire e vogliono prima far fuori quelle. :D

per acerbo:

ai Dell con cpu i7 ti suggerisco gli HP X360 con cpu Ryzen 4700U con batteria eterna e prestazioni da workstation con TDP da 15W, peccato solo che la GPU integrata non sia all'altezza una Nvidia Quadro altrimenti potevamo iniziare a buttare tutto.

Lo ripetiamo, però: prima di gridare al miracolo e strapparsi i capelli sarebbe opportuno aspettare le prime prove sul campo e i test in vari scenari d'utilizzo, verificando quella è che la reale esperienza d'uso con i nuovi dispositivi Apple con processori Apple Silicon.]

Ma infatti personalmente non grido certo al miracolo. C'è del potenziale per ora, molto interesse, vedremo poi i test su strada se daranno conferma o meno della bontà del prodotto. :)

per acerbo:

ai Dell con cpu i7 ti suggerisco gli HP X360 con cpu Ryzen 4700U con batteria eterna e prestazioni da workstation con TDP da 15W, peccato solo che la GPU integrata non sia all'altezza una Nvidia Quadro altrimenti potevamo iniziare a buttare tutto.

hp manco regalato, ho un elitebook aziendale e lo trovo pessimo

Anche a me sembra un articolo clickbait. A parte l'affidabilità di Geekbench ma se veramente le prestazioni sono così stupefacenti che "il punteggio single-core di Rosetta 2 supera comunque qualsiasi altro Mac Intel, incluso l'iMac 2020 da 27 pollici con Intel Core i9-10910 a 3,6 GHz" (quindi figuriamoci in formato nativo Arm) allora non si capisce perché Apple non abbia presentato anche tutti gli iMac con l'M1 e magari anche dei Mac Pro versione base con l'M1... Non le mancano certamente le risorse per farlo.

L'M1 è il chip "base" a basso consumo simile a quello del prossimo iPad, avrebbe poco senso metterlo su iMac o Mac Pro, per quelli probabilmente staranno preparando cpu con più core e a grafica discreta

Geekbench uhhh mecojoni !

hanno presentato 3 modelli.
gli altri due avranno un evento separato (se non due eventi).
e poi magari hanno un sacco di "scorte" di Intel da smaltire e vogliono prima far fuori quelle. :D
Se le prestazioni venissero confermate allora nessuno comprerebbe più iMac x86 che rimarrebbero sugli scaffali a meno di non venderli a metà prezzo... Né Apple, né i vari negozianti con scorte sarebbero molto contenti...

L'M1 è il chip "base" a basso consumo simile a quello del prossimo iPad, avrebbe poco senso metterlo su iMac o Mac Pro, per quelli probabilmente staranno preparando cpu con più core e a grafica discreta
Se fosse già più veloce di qualsiasi Mac x86 persino in emulazione allora avrebbe senso eccome anche perché come detto sopra gli iMac x86 non li comprerebbe più nessuno... Inoltre viene montato già sul Mac Mini che è un desktop anche quello.

Tra l'altro questa notizia contraddice almeno in parte quella dell'altro giorno in cui Office emulato impiagherebbe 20 secondi al primo avvio. Quindi la notizia di oggi sta dicendo che ai successivi avvii sarebbe addirittura più veloce dell'iMac 2020 da 27 pollici con Intel Core i9-10910 a 3,6 GHz?

O Geekbench è completamente inaffidabile oppure queste cpu sono pazzesche.
Boh...

A leggere le ultime news pare che questo M1 sia l'equivalente di un 5800X + GTX 1050 Ti racchiuso nello spazio di un'unghia e con i consumi di uno smartphone ..

Ora: o è l'uovo di Colombo, oppure qualcuno le sta sparando grosse

hp manco regalato, ho un elitebook aziendale e lo trovo pessimo

e nn hai Zbook G5
le docking poi :cry: :cry: :cry:

Se fosse già più veloce di qualsiasi Mac x86 persino in emulazione allora avrebbe senso eccome anche perché come detto sopra gli iMac x86 non li comprerebbe più nessuno... Inoltre viene montato già sul Mac Mini che è un desktop anche quello.

Tra l'altro questa notizia contraddice almeno in parte quella dell'altro giorno in cui Office emulato impiagherebbe 20 secondi al primo avvio. Quindi la notizia di oggi sta dicendo che ai successivi avvii sarebbe addirittura più veloce dell'iMac 2020 da 27 pollici con Intel Core i9-10910 a 3,6 GHz?

O Geekbench è completamente inaffidabile oppure queste cpu sono pazzesche.
Boh...

Vedremo, penso che se le cpu/gpu destinate all'imac arriveranno tra qualche mese non avrebbe molto senso usare le M1 come tappabuchi per poi sostituirle con le altre, a meno di non lasciare anche la versione base dell'iMac con le M1, è anche vero che se venissero confermate le prestazioni riuscirebbe a soddisfare le esigenze di buona parte dell'utenza...insomma vedremo, magari hanno già troppa carne al fuoco e devono semplicemente scaglionare :D La notizia di office non penso sia in contraddizione, l'avvio più lento di 20 secondi non è per la lentezza del processore, ma perché deve fare una serie di operazioni di traduzione iniziale che le x86 non devono fare

Anche a me sembra un articolo clickbait. A parte l'affidabilità di Geekbench ma se veramente le prestazioni sono così stupefacenti che "il punteggio single-core di Rosetta 2 supera comunque qualsiasi altro Mac Intel, incluso l'iMac 2020 da 27 pollici con Intel Core i9-10910 a 3,6 GHz" (quindi figuriamoci in formato nativo Arm) allora non si capisce perché Apple non abbia presentato anche tutti gli iMac con l'M1 e magari anche dei Mac Pro versione base con l'M1... Non le mancano certamente le risorse per farlo.

lato GPU ancora non sono ai livelli delle discrete amd/nvidia.

lato GPU ancora non sono ai livelli delle discrete amd/nvidia.

https://www.hwupgrade.it/news/cpu/apple-m1-le-prestazioni-della-gpu-integrata-meglio-di-geforce-gtx-1050ti_93487.html

La notizia di office non penso sia in contraddizione, l'avvio più lento di 20 secondi non è per la lentezza del processore, ma perché deve fare una serie di operazioni di traduzione iniziale che le x86 non devono fare
Per emulare deve tradurre le istruzioni x86 in istruzioni Arm. Se bastasse farlo solo una volta per tutte al primo avvio allora non si capisce perché non lo fanno tutti quando c'è da emulare un'architettura diversa o perché la stessa Apple non l'ha fatto in passato... O Apple ha trovato l'uovo di colombo dell'emulazione oppure la notizia è almeno in parte in contraddizione.

perché lato GPU ancora non sono ai livelli delle discrete amd/nvidia.
In una notizia dell'altro giorno l'M1 avrebbe le prestazioni di una 1050 che se non erro ha circa le prestazioni della Radeon 5300 degli iMac base. Di sicuro non c'è una 2080 o 3080 sugli iMac.

Comunque al momento è troppo difficile dare giudizi. Tra qualche settimana avremo più certezze.

o geekbench fa più schifo di quello che pensavo o siamo veramente davanti a una rivoluzione

https://www.hwupgrade.it/news/cpu/apple-m1-le-prestazioni-della-gpu-integrata-meglio-di-geforce-gtx-1050ti_93487.html

si lo so, commento anch'io quel thread :D

da lì (gpu di 4 anni fa) a dire che competano con le discrete attuali e possano rimpiazzare un mac pro, direi che ce ne passa.

Per emulare deve tradurre le istruzioni x86 in istruzioni Arm. Se bastasse farlo solo una volta per tutte al primo avvio allora non si capisce perché non lo fanno tutti quando c'è da emulare un'architettura diversa o perché la stessa Apple non l'ha fatto in passato... O Apple ha trovato l'uovo di colombo dell'emulazione oppure la notizia è almeno in parte in contraddizione.


In una notizia dell'altro giorno l'M1 avrebbe le prestazioni di una 1050 che se non erro ha circa le prestazioni della Radeon 5300 degli iMac base. Di sicuro non c'è una 2080 o 3080 sugli iMac.

Comunque al momento è troppo difficile dare giudizi. Tra qualche settimana avremo più certezze.

c'è anche da dire che han già presentato 3 linee di prodotti in questo evento, fors anche lato marketing non ha senso eccedere con la carne sul fuoco, anche perché alcuni modelli sono appena stati presentati e uscire con un rimpiazzo a pochi mesi ...

si lo so, commento anch'io quel thread :D

da lì (gpu di 4 anni fa) a dire che competano con le discrete attuali e possano rimpiazzare un mac pro, direi che ce ne passa.

un mac pro no, un iMac ni

A leggere le ultime news pare che questo M1 sia l'equivalente di un 5800X + GTX 1050 Ti racchiuso nello spazio di un'unghia e con i consumi di uno smartphone ..

Ora: o è l'uovo di Colombo, oppure qualcuno le sta sparando grosse

credo che come in un tutte le cose la verità stia nel mezzo e sarebbe già una gran cosa a mio avviso

lato GPU ancora non sono ai livelli delle discrete amd/nvidia.

il punto è questo
il MBP 16" e gli iMac hanno GPU discrete e Apple con M1 è andata a rimpiazzare modelli che avevano le integrate Intel

è probabile che in primavera esca qualcosa, ad esempio un iMac, con una variante di M1 (M1X o come cavolo vorranno chiamarlo...) con un comparto GPU migliore e aggiungerei il supporto a un quantitativo di RAM di almeno 32GB ma immagino pure 64
può anche darsi che per gli iMac rivedano la parte CPU dove ora ci sono 4 core veloci e 4 efficienti, può avere senso sul MBP ma meno su un desktop che può consumare e dissipare maggiormente

secondo me quello che abbiamo visto ora è il chip più "noioso" che somiglia moltissimo a quello che sarebbe stato (e probabilmente sarà) A14X per gli iPad Pro
la velocità era sufficiente per i 3 prodotti che hanno presentato, compreso il Mini che non ha batteria ma anche in precedenza non era particolarmente spinto come prestazioni e quindi hanno iniziato con quelli, ma la parte più interessante deve ancora venire

Odio geekbench e lo ritengo fuffa totale, ma la notizia va letta, secondo me, in questo modo:

Geekbench nativo fa X, geekbench eseguito da Rosetta 2 fa X-20%: i 2 punteggi, ancorché fuffa, sono tra di loro confrontabili per cui danno UN ASSAGGIO dell'IPOTETICA perdita di performance usando un programma in emulazione.

Ovviamente, tutte ste notizie col contagocce non fanno altro che creare hype, noi siamo con i piedi per terra ma sono STRACONVINTO che ne venderanno a pacchi sotto natale dato che l'utente medio-basso guarda i numerini e stavolta Apple di numerini ne ha forniti tanti: poi che siano veri o fuffa è tutto da dimostrare :)

poi altro fattore non da poco, il memory controller di M1 pare supporti solo fino a 16GB di ram, quindi ci sta che sian partiti dalla fascia bassa.

il punto è questo
il MBP 16" e gli iMac hanno GPU discrete e Apple con M1 è andata a rimpiazzare modelli che avevano le integrate Intel

è probabile che in primavera esca qualcosa, ad esempio un iMac, con una variante di M1 (M1X o come cavolo vorranno chiamarlo...) con un comparto GPU migliore e aggiungerei il supporto a un quantitativo di RAM di almeno 32GB ma immagino pure 64
può anche darsi che per gli iMac rivedano la parte CPU dove ora ci sono 4 core veloci e 4 efficienti, può avere senso sul MBP ma meno su un desktop che può consumare e dissipare maggiormente

secondo me quello che abbiamo visto ora è il chip più "noioso" che somiglia moltissimo a quello che sarebbe stato (e probabilmente sarà) A14X per gli iPad Pro
la velocità era sufficiente per i 3 prodotti che hanno presentato, compreso il Mini che non ha batteria ma anche in precedenza non era particolarmente spinto come prestazioni e quindi hanno iniziato con quelli, ma la parte più interessante deve ancora venire
E' possibile.

poi altro fattore non da poco, il memory controller di M1 pare supporti solo fino a 16GB di ram, quindi ci sta che sian partiti dalla fascia bassa.
Anche questa sarebbe una buona motivazione.


credo che come in un tutte le cose la verità stia nel mezzo e sarebbe già una gran cosa a mio avviso
Quoto.
Anche perché se un Macbook Air (e quindi anche il Mac Mini) con M1 in emulazione riuscisse a far girare app x86 più velocemente di un iMac 2020 da 27 pollici con Intel Core i9-10910 a 3,6 GHz che costa circa 3000 euro sarebbe una roba da fine del mondo... E soprattutto sarebbero costretti a svendere gli iMac x86 a metà prezzo. Osborne 2 la vendetta.

Anche a me sembra un articolo clickbait. A parte l'affidabilità di Geekbench ma se veramente le prestazioni sono così stupefacenti che "il punteggio single-core di Rosetta 2 supera comunque qualsiasi altro Mac Intel, incluso l'iMac 2020 da 27 pollici con Intel Core i9-10910 a 3,6 GHz" (quindi figuriamoci in formato nativo Arm) allora non si capisce perché Apple non abbia presentato anche tutti gli iMac con l'M1 e magari anche dei Mac Pro versione base con l'M1... Non le mancano certamente le risorse per farlo.

Sui risultati di Geekbench siamo d'accordo...

Sul perchè non abbiano presentato anche gli iMac e i Mac Pro: M1 ha dei limiti con la memoria massima di 16GB, non espandibile, e con l'I/O ( supporto per sole due porte Thunderbolt 3 e 2 USB 3.0 ).
Per un iMac base una configurazione così può andare pure bene, ma per uno di fascia alta o addirittura un Mac Pro assolutamente no.

Probabile che gli iMac più costosi e i Mac Pro avranno una versione avanzata di M1 con più core CPU a disposizione , molto probabilmente una GPU discreta e soprattutto la Ram espandibile.
Già il Mini con M1, per memoria e porte, è un " downgrade " di quello Intel...

Poi esce una comparativa su cinebench r23 e la magia dell'M1 sparisce e si ridimensiona un pò:
https://hexus.net/tech/news/cpu/146878-apple-m1-cinebench-r23-benchmark-scores-revealed/

il miracolo è rimandato al prossimo anno.

Poi esce una comparativa su cinebench r23 e la magia dell'M1 sparisce e si ridimensiona un pò:
https://hexus.net/tech/news/cpu/146878-apple-m1-cinebench-r23-benchmark-scores-revealed/

il miracolo è rimandato al prossimo anno.

Eh mi sa anche a me...anche se è una buona base di partenza indubbiamente.

Questo è il risultato dell'A12Z, molto meno potente.

https://pbs.twimg.com/media/Em59GQzUYAAPF2-?format=jpg&name=large

https://twitter.com/dylan522p/status/1328136491462127617

EDIT: e ci sono cascati tutti come dei polli https://twitter.com/BitsAndChipsEng/status/1328321644667015168

EDIT: https://twitter.com/BitsAndChipsEng/status/1328321644667015168[/QUOTE]

Cascati, almeno il sottoscritto, direi proprio di no. É un prodotto interessante sicuramente, ma troppo pane duro dovranno mangiare per stare almeno su una base di parità.
Per non parlare del comparto grafico poi. Se vuoi le prestazione VERE in 3D, l'integrato non sarà mai la strada da percorrere.

Eh mi sa anche a me...anche se è una buona base di partenza indubbiamente.

Vorrei vedere, hanno tirato fuori una bestia da 16 miliardi di transistor a 5nm, non hanno nulla a che vedere con le architetture arm striminzite, è più wide di tutte le architetture x86 sul mercato.
Hanno speso un budget secondo me più sostanzioso di intel e amd quindi mi aspettavo la buona cpu che è, chiaramente non c'è nessun miracolo e amd&intel non sono così babbei.

Poi esce una comparativa su cinebench r23 e la magia dell'M1 sparisce e si ridimensiona un pò:
https://hexus.net/tech/news/cpu/146878-apple-m1-cinebench-r23-benchmark-scores-revealed/

il miracolo è rimandato al prossimo anno.

Questo è il risultato dell'A12Z, molto meno potente.

https://pbs.twimg.com/media/Em59GQzUYAAPF2-?format=jpg&name=large

https://twitter.com/dylan522p/status/1328136491462127617

EDIT: e ci sono cascati tutti come dei polli https://twitter.com/BitsAndChipsEng/status/1328321644667015168


Cascati, almeno il sottoscritto, direi proprio di no. É un prodotto interessante sicuramente, ma troppo pane duro dovranno mangiare per stare almeno su una base di parità.
Per non parlare del comparto grafico poi. Se vuoi le prestazione VERE in 3D, l'integrato non sarà mai la strada da percorrere.

Si, parlavo più dei siti di news in realtà.
Certo che non è la soluzione per tutto e saranno le recensioni tra qualche giorno a provarlo, non certo leak fasulli!

Vorrei vedere, hanno tirato fuori una bestia da 16 miliardi di transistor a 5nm, non hanno nulla a che vedere con le architetture arm striminzite, è più wide di tutte le architetture x86 sul mercato.
Hanno speso un budget secondo me più sostanzioso di intel e amd quindi mi aspettavo la buona cpu che è, chiaramente non c'è nessun miracolo e amd&intel non sono così babbei.

Tutto può essere...ancora. Potrebbe essere un trampolino di lancio fantastico per Apple con le prossime versioni...o potrebbe benissimo trasformarsi in un flop micidiale. Molto dipenderà dalla mole di software compatibili, che dovranno essere almeno pari a quelli supportati dalla precedente piattaforma x86 e quanto ci metteranno ad essere disponibili.

Questo dimostra quanto hype si è creato intorno a sto M1.

Cmq anche se si tratta di A12X mena di brutto in single core eh mecoions

Questo è il risultato dell'A12Z, molto meno potente.

https://pbs.twimg.com/media/Em59GQzUYAAPF2-?format=jpg&name=large

https://twitter.com/dylan522p/status/1328136491462127617

EDIT: e ci sono cascati tutti come dei polli https://twitter.com/BitsAndChipsEng/status/1328321644667015168



Ma allora siamo proprio alle comiche! Inoltre Cinebench è pur sempre un benchmark sintetico quindi relativamente utile anche se avessero usato un M1.

Ma allora siamo proprio alle comiche! Inoltre Cinebench è pur sempre un benchmark sintetico quindi relativamente utile anche se avessero usato un M1.

Ni, è un bench sintetico che simula un workload reale di rendering e dato che è basato su cinema4D è abbastanza affidabile.

Un bench deve essere riproducibile a determinate condizioni quindi tutti i software creati per "benchare" sono, a vari livelli, sintetici.

Anche 3D mark è sintetico per questo si affianca ai test con giochi reali e frame presi in game, magari con strumenti appositi.

Una prova che mi viene in mente è, eventualmente, la conversione di un video con Handbrake semmai lo convertiranno per AS, quello potrebbe essere un test affidabile.

Non è facile comparare 2 arch così diverse.

https://github.com/HandBrake/HandBrake/releases/tag/1.4.0-beta.1

Edit neanche a farlo apposta, ci sarà sia per AS che per apple x86, quindi sarà un ottimo bench reale per capire come sulle diverse piattaforme: linux windows, apple x86 e AS.

Ni, è un bench sintetico che simula un workload reale di rendering e dato che è basato su cinema4D è abbastanza affidabile.

Un bench deve essere riproducibile a determinate condizioni quindi tutti i software creati per "benchare" sono, a vari livelli, sintetici.

Anche 3D mark è sintetico per questo si affianca ai test con giochi reali e frame presi in game, magari con strumenti appositi.

Una prova che mi viene in mente è, eventualmente, la conversione di un video con Handbrake semmai lo convertiranno per AS, quello potrebbe essere un test affidabile.

Non è facile comparare 2 arch così diverse.

https://github.com/HandBrake/HandBrake/releases/tag/1.4.0-beta.1

Edit neanche a farlo apposta, ci sarà sia per AS che per apple x86, quindi sarà un ottimo bench reale per capire come sulle diverse piattaforme: linux windows, apple x86 e AS.

handbrake sarà velocissimo su M1 in quanto sfrutterà l'hardware dedicato (già oggi sfrutta T2 se non erro).

handbrake sarà velocissimo su M1 in quanto sfrutterà l'hardware dedicato (già oggi sfrutta T2 se non erro).

Insieme a CB23 e ad altri software contribuirà a dimostrare SE l'M1 è buono o meno :)

Per chi continua a non credere ai risultati, c’è solo da capire che queste cpu NON SONO X86. Non si portano piu dietro 40 anni di legacy, affrontano i task in modo differente rispetto ad x86, usano istruzioni diverse e sono enormente piu efficienti anche in termini di branch prediction.

Per chi continua a non credere ai risultati, c’è solo da capire che queste cpu NON SONO X86. Non si portano piu dietro 40 anni di legacy, affrontano i task in modo differente rispetto ad x86, usano istruzioni diverse e sono enormente piu efficienti anche in termini di branch prediction.

Concordo ma, personalmente, aspetto test reali sul campo.

Basta non ce la faccio più dalle risate :rotfl:

Mi volete morto, cattivi :(

handbrake sarà velocissimo su M1 in quanto sfrutterà l'hardware dedicato (già oggi sfrutta T2 se non erro).

Quindi probabilmente M1 è stato ottimizzato per i software più usati in quei settori dove il Mac è più diffuso come elaborazione grafica/video e simili. Allora forse M1 sarà un po' meno general purpose rispetto a un x86 e pagare pegno in altri settori. Il che ha anche senso per Apple: se fai una cpu custom meglio farla secondo le proprie esigenze, tanto mica la venderà agli altri.
Comunque una ragione in più per fare dei test reali sul campo ma con qualsiasi tipo di software, non solo di elaborazione grafica/video.

Quindi probabilmente M1 è stato ottimizzato per i software più usati in quei settori dove il Mac è più diffuso come elaborazione grafica/video e simili. Allora forse M1 sarà un po' meno general purpose rispetto a un x86 e pagare pegno in altri settori. Il che ha anche senso per Apple: se fai una cpu custom meglio farla secondo le proprie esigenze, tanto mica la venderà agli altri.
Comunque una ragione in più per fare dei test reali sul campo ma con qualsiasi tipo di software, non solo di elaborazione grafica/video.

Personalmente penso che sarà velocissimo in certi ambiti (i famosi 5x, 10x pubblicizzati da Apple), che come dici bene saranno appunto gli use-case più popolari per macOS (software di editing, musica, etc.), più l'accelerazione in carichi legati a ML, aggiungendoci pure una GPU integrata decisamente migliore di quelle pre-Intel Xe.

Il resto andrà almeno come sui processori Intel montati sui portatili della rispettva fascia. Il tutto a consumi e calore decisamente inferiore.

Se sarà così, sinceramente, si tratta di una svolta eccellente.

...nel 2020 dell'era cosiddetta "volgare" spero sia conosciuto il fatto che ARM ovvero Advanced RISC Machine sia quello che esprime ovvero una ISA di tipo RISC e non una ISA CISC.
Da rimarcare che dal Pentium PRO in poi nemmeno le cpu x86 (o meglio oggi x86_64) sono architetture "pure" a set di istruzioni complesso.

Marco71

scusate per prima cosa.
non sono super tecnico come voi, scusate il modo di porre la domanda.

ho ordinato 2 giorni fa il mac mini M1 (16GB)... e oggi pomeriggio Apple ha prelevato l'importo... quindi sarà in preparazione l'ordine.

ho letto che vi sono notizie di caricamenti lunghissimi per l'office.

volevo chiedervi 2 cose:

- ma se uso office365 online? via browser non dovrei avere quei rallentamenti?
- ma Microsoft non ha affermato che ha aggiornato Office per M1 o che lo sta facendo?

io in sostanza uso il computer per outlook, excel, word... office insomma...
non è che ho fatto una stupidata con il mini M1?

grazie, ciao
Massimo

scusate per prima cosa.
non sono super tecnico come voi, scusate il modo di porre la domanda.

ho ordinato 2 giorni fa il mac mini M1 (16GB)... e oggi pomeriggio Apple ha prelevato l'importo... quindi sarà in preparazione l'ordine.

ho letto che vi sono notizie di caricamenti lunghissimi per l'office.

volevo chiedervi 2 cose:

- ma se uso office365 online? via browser non dovrei avere quei rallentamenti?
- ma Microsoft non ha affermato che ha aggiornato Office per M1 o che lo sta facendo?

io in sostanza uso il computer per outlook, excel, word... office insomma...
non è che ho fatto una stupidata con il mini M1?

grazie, ciao
Massimo

Il rallentamento dovrebbe essere solo al primo avvio in assoluto poi non avrà di questi problemi, e in un futuro prossimo Microsoft dovrebbe fare il porting di Office nativo per l'M1, inoltre il termine del reso è il 20 gennaio, puoi andare tranquillo, poi raccontaci :)

.... inoltre il termine del reso è il 20 gennaio, puoi andare tranquillo, poi raccontaci :)

l'arrivo a casa del mini è previsto tra il 26 novembre e il 3 dicembre.
speriamo bene :) l'ho comprato per Office... mi sembra incredibile che non funzioni bene.

Il rallentamento dovrebbe essere solo al primo avvio in assoluto poi non avrà di questi problemi, e in un futuro prossimo Microsoft dovrebbe fare il porting di Office nativo per l'M1, inoltre il termine del reso è il 20 gennaio, puoi andare tranquillo, poi raccontaci :)

Non credo avrai problemi, sicuramente non con l'applicativo online, con l'installazione vai di rosetta finché non faranno l'app nativa per AS.

Quindi probabilmente M1 è stato ottimizzato per i software più usati in quei settori dove il Mac è più diffuso come elaborazione grafica/video e simili. Allora forse M1 sarà un po' meno general purpose rispetto a un x86 e pagare pegno in altri settori. Il che ha anche senso per Apple: se fai una cpu custom meglio farla secondo le proprie esigenze, tanto mica la venderà agli altri.
Comunque una ragione in più per fare dei test reali sul campo ma con qualsiasi tipo di software, non solo di elaborazione grafica/video.

diciamo che handbrake è già di suo ottimizzato per le architetture apple.

oh, sembra tutto vero..! https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested/7

io ci rimango :eek:

Dopo questi test posso dire che mi sbagliavo, intel&amd hanno fatto la figura dei babbei :D
Non parliamo poi della gpu integrata che intel si può capire, non è il suo mestiere, ma la scoppola presa da amd&nvidia è ingiustificabile.

Dopo questi test posso dire che mi sbagliavo, intel&amd hanno fatto la figura dei babbei :D
Non parliamo poi della gpu integrata che intel si può capire, non è il suo mestiere, ma la scoppola presa da amd&nvidia è ingiustificabile.

Ci sono rimasto anche io, le moltiplicazione presentate, più o meno, sono vere.

Complimenti davvero soprattutto per l'integrata che va davvero, più o meno, come una 1050.

Chapeau

Ci sono rimasto anche io, le moltiplicazione presentate, più o meno, sono vere.

Complimenti davvero soprattutto per l'integrata che va davvero, più o meno, come una 1050.

Chapeau

quindi con il mac mini da 16GB che mi arriva tra qualche giorno... potrò fare Office e simili a buona velocità? :D

quindi con il mac mini da 16GB che mi arriva tra qualche giorno... potrò fare Office e simili a buona velocità? :D

Da quello che si è visto in questi primi giorni di review si, la review di anandtech è abbastanza completa dagli un occhio, indicativamente un'app emulata va un 20% più lenta di una nativa per arm.

Da quello che leggo in giro la situazione è buona, non perfetta ma migliorerà nel tempo :)

Sono arrivate diverse notizie e thread sull'M1 di Apple, con annesse vagonate di commenti, ma approfitto di questo per scrivere velocemente le mie riflessioni.

In primis complimenti ad Apple che ha tirato fuori un chip (perché non è soltanto una questione di CPU e GPU, ma anche degli altri acceleratori hardware e dell'intero ecosistema che ha realizzato) davvero superlativo.

Adesso un paio di considerazioni su consumi e prestazioni.

I consumi non possono che essere bassi, considerato che il chip è un SoC che integra tutto all'interno, ma soprattutto che ha tagliato tutto ciò che non è affatto necessario per un chip mobile (perché di questo stiamo parlando: l'M1 è un SoC per iPhone/iPad et similia riciclato anche per i computer dell'azienda). Persino la RAM è montata sul package, eliminando tutta la componentistica che ritroviamo, invece, sulle normali memorie (soprattutto quelle normali, non SODIMM), e che ovviamente contribuisco sui consumi (e suo costi: anche questo non dimentichiamolo).

Tanto per fare un esempio, diversi utenti di AMD si sono lamentati tempo fa del fatto che l'ultimo chipset di AMD, che supporta PCI-Express 4.0, abbia la ventolina sopra e faccia rumore. Questo perché un controller PCI-Express 4.0 è molto più complesso di uno 3.0, richiede parecchi transistor in più, funziona a frequenze più elevati, e quindi consuma di più.

L'M1 non ha nulla di tutto ciò, perché i collegamenti fra le periferiche (CPU <-> GPU e acceleratori vari) sono diretti e non passano da alcun PCI-Express (che al massimo sarà emulato a livello applicativo. Nel senso che i vari componenti saranno visti dal s.o. come periferiche PCI-Express, e trattati come tali, per non dover riscrivere tutto lo stack software accedervi e utilizzarli).

La memoria è condivisa e vale lo stesso discorso. Infine aggiungiamo il fatto che Apple utilizza pure l'ultimissimo processo produttivo a 5nm di TSMC, e si capisce perché i consumi siano così bassi pur con prestazioni così elevate.

Riguardo alle prestazioni, sono mediamente superiori a quelle di Intel e un pelo sotto a quelle di AMD. Anche qui, eccellente lavoro, ma i core sono molto grossi. Avete visto la fotografia del chip? E parliamo di silicio con processo a 5nm, per l'appunto, per cui c'è un'elevatissima densità di transistor nell'area occupata dai core.

Ma, soprattutto, avete visto la seconda pagina dell'articolo di AnandTech? Lì, oltre a mostrare il diagramma della (micro)architettura, è ancora più interessante vedere i numeri relativi alle risorse hardware che Apple ha utilizzato per i suoi core "big". Parliamo di numeri in assoluto elevati, e di gran lunga superiori a quanto AMD e Intel abbiano finora utilizzato nelle ultime incarnazioni delle loro micro-architetture.

Per forza, quindi, che le prestazioni siano così elevate. Ma al contempo ciò fa capire anche il potenziale ancora a disposizione da AMD e, soprattutto, Intel (che è quella più indietro) che possono ancora sfruttare per le loro future micro-architetture.

Infine, si è detto che Intel sia indietro: certo che sì. E questo perché ha sbagliato due volte.
Il primo perché non ha svincolato lo sviluppo delle micro-architetture dall'utilizzo dei processi produttivi, castrandone enormemente lo sviluppo e, di conseguenza, le prestazioni. Peraltro avrebbe potuto benissimo effettuare il backport delle nuove micro-architetture sul rodatissimo processo a 14nm, consentendole di rimanere in posizione di vantaggio almeno sul fronte delle prestazioni single-core/thread, ma è parecchio in ritardo anche su questo fronte (Rocket Late è stato spostato al prossimo anno).
Il secondo perché, pur con più di 4 anni di ritardo, si ostina ancora a non voler rivolversi ad altre fonderie per realizzare i suoi chip. Sì, sarebbe un apocalisse nonché uno smacco ancora più grande, visto che Intel è LA fonderia per eccellenza, ma almeno potrebbe competere ad armi pari con AMD e Apple.

Apple, che pensa soltanto agli utili e gode di un trattamento privilegiato dai fornitori (TSMC in primis) si può permettere il lusso di fare quello che vuole. Giustamente! Chi non lo farebbe al suo posto?

My 2 cents...

cmq avere tali prestazioni con consumi così ridicoli se non è una rivoluzione questa non so cosa lo sia.

la competizione è sempre meglio per il cliente. intel si è meritata certi scossoni. adesso spero si riprenda prima o poi se no anche amd alzerà così la cresta e venderà cpu a peso d'oro. INTEL : "se volete più di 4 core dovete darmi 1000 euri"

I consumi li ha stimati Anand che ha fatto meglio di tutti, ha attaccato un wattametro, anche se a bassi assorbimenti non è precisissimo, al mac mini.

La ram non è nel package ma è appena fuori ma cmq il discorso non cambia, con tutti i componenti cosi vicini ci sono indubbi vantaggi.

Condivido le tue considerazioni cdimauro, sto M1 è stata una bella svolta

Sono arrivate diverse notizie e thread sull'M1 di Apple, con annesse vagonate di commenti, ma approfitto di questo per scrivere velocemente le mie riflessioni.

In primis complimenti ad Apple che ha tirato fuori un chip (perché non è soltanto una questione di CPU e GPU, ma anche degli altri acceleratori hardware e dell'intero ecosistema che ha realizzato) davvero superlativo.

Adesso un paio di considerazioni su consumi e prestazioni.

I consumi non possono che essere bassi, considerato che il chip è un SoC che integra tutto all'interno, ma soprattutto che ha tagliato tutto ciò che non è affatto necessario per un chip mobile (perché di questo stiamo parlando: l'M1 è un SoC per iPhone/iPad et similia riciclato anche per i computer dell'azienda). Persino la RAM è montata sul package, eliminando tutta la componentistica che ritroviamo, invece, sulle normali memorie (soprattutto quelle normali, non SODIMM), e che ovviamente contribuisco sui consumi (e suo costi: anche questo non dimentichiamolo).

Tanto per fare un esempio, diversi utenti di AMD si sono lamentati tempo fa del fatto che l'ultimo chipset di AMD, che supporta PCI-Express 4.0, abbia la ventolina sopra e faccia rumore. Questo perché un controller PCI-Express 4.0 è molto più complesso di uno 3.0, richiede parecchi transistor in più, funziona a frequenze più elevati, e quindi consuma di più.

L'M1 non ha nulla di tutto ciò, perché i collegamenti fra le periferiche (CPU <-> GPU e acceleratori vari) sono diretti e non passano da alcun PCI-Express (che al massimo sarà emulato a livello applicativo. Nel senso che i vari componenti saranno visti dal s.o. come periferiche PCI-Express, e trattati come tali, per non dover riscrivere tutto lo stack software accedervi e utilizzarli).

La memoria è condivisa e vale lo stesso discorso. Infine aggiungiamo il fatto che Apple utilizza pure l'ultimissimo processo produttivo a 5nm di TSMC, e si capisce perché i consumi siano così bassi pur con prestazioni così elevate.

Riguardo alle prestazioni, sono mediamente superiori a quelle di Intel e un pelo sotto a quelle di AMD. Anche qui, eccellente lavoro, ma i core sono molto grossi. Avete visto la fotografia del chip? E parliamo di silicio con processo a 5nm, per l'appunto, per cui c'è un'elevatissima densità di transistor nell'area occupata dai core.

Ma, soprattutto, avete visto la seconda pagina dell'articolo di AnandTech? Lì, oltre a mostrare il diagramma della (micro)architettura, è ancora più interessante vedere i numeri relativi alle risorse hardware che Apple ha utilizzato per i suoi core "big". Parliamo di numeri in assoluto elevati, e di gran lunga superiori a quanto AMD e Intel abbiano finora utilizzato nelle ultime incarnazioni delle loro micro-architetture.

Per forza, quindi, che le prestazioni siano così elevate. Ma al contempo ciò fa capire anche il potenziale ancora a disposizione da AMD e, soprattutto, Intel (che è quella più indietro) che possono ancora sfruttare per le loro future micro-architetture.

Infine, si è detto che Intel sia indietro: certo che sì. E questo perché ha sbagliato due volte.
Il primo perché non ha svincolato lo sviluppo delle micro-architetture dall'utilizzo dei processi produttivi, castrandone enormemente lo sviluppo e, di conseguenza, le prestazioni. Peraltro avrebbe potuto benissimo effettuare il backport delle nuove micro-architetture sul rodatissimo processo a 14nm, consentendole di rimanere in posizione di vantaggio almeno sul fronte delle prestazioni single-core/thread, ma è parecchio in ritardo anche su questo fronte (Rocket Late è stato spostato al prossimo anno).
Il secondo perché, pur con più di 4 anni di ritardo, si ostina ancora a non voler rivolversi ad altre fonderie per realizzare i suoi chip. Sì, sarebbe un apocalisse nonché uno smacco ancora più grande, visto che Intel è LA fonderia per eccellenza, ma almeno potrebbe competere ad armi pari con AMD e Apple.

Apple, che pensa soltanto agli utili e gode di un trattamento privilegiato dai fornitori (TSMC in primis) si può permettere il lusso di fare quello che vuole. Giustamente! Chi non lo farebbe al suo posto?

My 2 cents...

ho bisogno di un altro paio di cents :D

non credi che i soli 16 registri GRP dell'architettura x86_64 siano un limite alla possibilità di estrarre parallelismo e quindi ipc dal codice (questo a prescindere poi dalle risorse a valle come dispatcher ed unità di esecuzione)
dunque se così fosse non sarebbe arrivato il tempo di una revisione della base dell'architettura con un eventuale "x86_64+" 32GPR ecc? ^_^

Sono arrivate diverse notizie e thread sull'M1 di Apple, con annesse vagonate di commenti, ma approfitto di questo per scrivere velocemente le mie riflessioni.

........

My 2 cents...

Condivido buona parte di quello che hai scritto, aggiungo solo un tre cose:

1) Big Sur su M1 esegue quasi 5 VOLTE PIÙ VELOCEMENTE acquisizione e rilascio degli NSObject (fonte https://daringfireball.net/2020/11/the_m1_macs ).

Praticamente quasi tutte le risorse a livello di S.O. e framework applicativi Apple sono gestite come NSObject (gestiti con reference counting), quindi questo ha effetto su tutte le applicazioni compilate appositamente per il S.O. Apple.
Si parla di circa 30 ns su x86, circa 6.5 ns su M1 nativo e circa 14 ns con codice "per Apple x86" emulato su M1.
Questo ha anche risvolti positivi sul risparmio energetico complessivo.
E suppongo che vi siano altre ottimizzazioni meno evidenti che traggono vantaggio da M1.
Penso che sia da li che hanno origine molti dei miglioramenti in termini di prestazioni e risparmio energetico: ottimizzazione sinergica di hardware e software.
Rispetto alle più che buone performance con app x86 compilate per Mac, c'è quindi da aspettarsi prestazioni più basse quando si fa girare in emulazione software x86 per Windows sugli M1.
Con codice x86 che chiama poco il S.O. rispetto al tempo in cui esegue codice le prestazioni saranno più basse, mentre se si usa solo software compilato per Mac (per M1 o per x86 ma che chiama spesso il S.O.) si avranno prestazioni migliori.

2) il set di istruzioni è rilevante per quel che riguarda quali sono le ottimizzazioni architetturali di una cpu.
Se gli x86 di Intel ed AMD si sono fermati a decodificare 4..5 istruzioni per ciclo, mentre Apple ne decodifica 8, é perche con l'attuale architettura x86 il rapporto prestazioni/costo arriva fino a li, mentre con AArch64 è possibile salire oltre prima che il "costo implementativo" superi i benefici.
Sia chiaro che non è che Arm sia superiore ad x86 o viceversa, ma che set di istruzioni differenti possono richiedere ottimizzazioni architetturali differenti (es: sugli x86 è già da anni conveniente avere l'hyperthreading, sugli Arm ancora no).

3) Gira voce che nel 2021 Apple proporrà sul mercato un evoluzione di M1 con 12 core (8 ad alte prestazioni e 4 a basso consumo), non mi stupirei se fosse quella la cpu che verrà proposta per la fascia desktop/workstation/server.
Ipotizzo che semplicemente non ci sarà la GPU integrata ed al suo posto ci saranno altri 4 core e le interconnessioni ed interfacce per supportare una maggior quantità di ram e la GPU "esterna" (oppure nello stesso package?).

cmq avere tali prestazioni con consumi così ridicoli se non è una rivoluzione questa non so cosa lo sia.
Mi riquoto:
"In primis complimenti ad Apple che ha tirato fuori un chip [...] davvero superlativo."
:read:
la competizione è sempre meglio per il cliente. intel si è meritata certi scossoni.
Ma anche no. La competizione migliore per i consumatori sarebbe stata se Intel NON avesse avuto problemi coi suoi processi produttivi, e quindi avesse potuto trarre beneficio della maggior densità dei transistor E dei minor consumi, permettendo quindi di avere CPU con molti più core e/o con core a prestazioni molte più elevate e/o con consumi più ridotti.

Augurare a Intel di meritarsi quel che sta passando equivale, per un consumatore, a darsi una martellata sui gioielli di famiglia.
adesso spero si riprenda prima o poi se no anche amd alzerà così la cresta e venderà cpu a peso d'oro. INTEL : "se volete più di 4 core dovete darmi 1000 euri"
Ti svelo un segreto: il prezzo lo fa il mercato, e non Intel.

Ed è fondamentale che ci sia parecchia competizione nel mercato, per far abbassare i prezzi e/o per ottenere chip con prestazioni a parità di costo.
ho bisogno di un altro paio di cents :D

non credi che i soli 16 registri GRP dell'architettura x86_64 siano un limite alla possibilità di estrarre parallelismo e quindi ipc dal codice (questo a prescindere poi dalle risorse a valle come dispatcher ed unità di esecuzione)
C'è un paper che però è un po' vecchiotto, che ha indagato proprio sulla scalabilità delle prestazioni di x86-64 in base al numero dei registri a disposizione. Lo trovi qui (https://dlnext.acm.org/doi/abs/10.1007/11688839_14).

Questa la sintesi:
"Finally, we observe that using 16 GPRs and 16 XMM registers significantly outperforms the scenario when only 8 GPRs and 8 XMM registers are used. However, our results also show that using 12 GPRs and 12 XMM registers can achieve as competitive performance as employing 16 GPRs and 16 XMM registers.
[...]
Figure 7 gives the normalized execution time (with respect to the base compilation using 16 GPRs and 16 XMM registers) with the REG_8 and REG_12 register configurations for the SPEC2000 benchmarks. On average, with the REG_8 configuration, the CINT2000 exhibits a 4.4% slowdown, and the CFP2000 exhibits a 5.6% slowdown; with the REG_12 configuration, the CINT2000 is slowed down by 0.9%, and the CFP2000 is slowed down by 0.3%. Clearly, these results show that REG_12 already works well for most of the SPEC2000 benchmarks.
[...]
In addition to performance, the normalized dynamic number of memory accesses (including stack accesses) for the CINT2000 and CFP2000 is shown in Fig. 8. On average, with the REG_8 configuration, the memory references are increased by 42% for the CINT2000 and by 78% for the CFP2000; with the REG_12 configuration, the memory references are increased by 14% for CINT2000 and by 29% for the CFP2000.
Overall, for the SPEC2000 benchmark suite, we can see the trend that when the number of available registers is increased from 8 to 12, the memory accesses are reduced dramatically, and moderate performance improvement is achieved. However, with more than 12 registers, although the memory accesses are further reduced, the performance is barely improved"
In sintesi: con 12 registri anziché i classici 16 le prestazioni sono quasi le stesse. L'unica differenza è un aumento delle richieste di accesso alla memoria (+14% per CINT200 e +29% per CFP2000), che però non hanno praticamente influenza sulle prestazioni (-0,9% e -0.3% rispettivamente).

Questo penso per tre motivi.

Il primo è che Intel ha (aveva, all'epoca di questa ricerca) un'ottima micro-architettura che gestisce molto bene gli accessi alla memoria (d'altra parte basti analizzarne anche oggi i diagrammi per vedere proprio come Intel abbia da sempre privilegiato quest'aspetto).

Il secondo è che un'architettura (non micro-architettura) CISC ha bisogno di meno registri rispetto a una RISC, perché in genere può applicare l'accesso alla memoria (solo load+op, o load+op+store) a ogni istruzione (o comunque alla maggior parte / più comuni - "general purpose") che le consente di risparmiare registri utilizzati.

Oltre al fatto, ed è il terzo motivo a corollario del precedente, che dispone di molte più modalità d'indirizzamento verso la memoria, e quindi richiede meno registri per alcuni scenari più complicati, ma comunque abbastanza comuni.
Tipico esempio è l'accesso agli array con elementi superiori al byte (interi o float a 16, 32 e 64-bit), che ad esempio su x86/x64 (ma anche nei gloriosi Motorola 68020+ :cool: ) si risolve con la modalità d'indirizzamento [Base + Indice * Scala + Offset), che parecchi RISC non hanno a disposizione, e quindi soffrono nel tentare di emularla (in particolare RISC-V i cui accademici hanno ben pensato di offrire UNA sola modalità d'indirizzamento, Base + Offset, e poi si vede come le prestazioni crollino nei casi di cui sopra).
dunque se così fosse non sarebbe arrivato il tempo di una revisione della base dell'architettura con un eventuale "x86_64+" 32GPR ecc? ^_^
Leggendo il paper di cui sopra sembrerebbe di no, e quindi che pure i 16 registri siano persino abbondanti.

In realtà, e come dicevo prima, il paper è molto vecchio e parecchi benchmark, come pure le applicazioni reali, sono cambiate nel corso degli anni.

Probabilmente oggi più registri potrebbero essere sfruttati meglio per migliorare le prestazioni e/o per ridurre gli accessi alla memoria (una santa cosa anche questa), ma in ogni caso a un CISC, x64 incluso (ormai x86 lasciamolo perdere, perché il futuro è chiaramente a 64 bit, tant'è che ormai persino nell'embedded comincia ad avere una percentuale rilevante), servirebbero meno registri.

Inoltre l'utilizzo dei registri si può ulteriormente ridurre in un CISC introducendo altre utili nonché comuni modalità d'indirizzamento verso la memoria (ad esempio quelle di pre/post inc/decremento), oppure con istruzioni di tipo memory-to-memory, o ancora facendo sì che le istruzioni possano essere "potenziate" consentendo di abilitare nuove caratteristiche che si applicano in parallelo al lavoro che fanno normalmente (ad esempio marcare come "non-temporal" l'accesso alla memoria in modo da evitare che i dati siano copiati nelle cache e quindi che la "inquinino". Oppure far sì che un'istruzione modifichi i flag se questa normalmente non lo prevede, o viceversa venga soppressa la modifica dei flag per le istruzioni che normalmente lo fanno. O ancora che si possa leggere dalla memoria un dato di dimensione minore rispetto a quello con la quale lavora l'istruzione, estendendolo con zero o con segno, ecc.).

Sono tutte cose che si possono implementare in un CISC, e che consentono di migliorare la densità di codice e/o di ridurre il numero di registri usati e/o di ridurre il numero di istruzioni eseguite e/o di ridurre l'utilizzo della memoria e/o di ridurre l'utilizzo delle cache dati.
Sfortunatamente ormai c'è poca ricerca nei CISC, perché da parecchio praticamente tutti, produttori di CPU e accademici, si sono buttati a pesce sui RISC.

La mia architettura, invece, va controcorrente perché è CISC, e nasce per proprio per dare impulso e sfruttare ancora meglio le caratteristiche / funzionalità di tale macrofamiglia. Infatti implementa tutte le caratteristiche di cui sopra più altre (che non ho snocciolato per non appesantire ancora di più il discorso), e i primi risultati mostrano che a livello di densità di codice c'è un miglioramento (soprattutto in confronto a x64), ma anche il numero di istruzioni eseguite è ridotto (perché due o più istruzioni x86/x64 sono "fuse" in una sola della mia ISA). Il tutto utilizzando soltanto una piccola frazione di tutte le nuove caratteristiche, e dunque con ampi margini di miglioramento.

Quindi, e per rispondere alla tua domanda, un "x86_64+" 32GPR ci sarebbe già, visto che la mia ISA è compatibile al 100% a livello di sorgenti con x86 e x64, e casualmente mette a disposizione proprio 32 registri GP (ma nei miei benchmark ne uso soltanto 9-10 quando la confronto con x86, e 17-18 quando la confronto con x64).

Non c'è compatibilità binaria, perché tanto è del tutto inutile, visto che se i registri diventano 32 dovresti comunque cambiare gli opcode, e quindi risulterebbe incompatibile con x86/x64. Cosa che peraltro è avvenuta con x64, visto che è sostanzialmente una nuova ISA (anche se basata in buona parte su x86; quindi non è nemmeno 100% compatibile a livello di sorgenti / istruzioni a disposizione), e che è avvenuta con AArch64 che non ha nulla a che vedere con la classica ARM visto che gli opcode sono completamente diversi ed è soltanto parzialmente compatibile a livello sorgente.
Condivido buona parte di quello che hai scritto, aggiungo solo un tre cose:

1) Big Sur su M1 esegue quasi 5 VOLTE PIÙ VELOCEMENTE acquisizione e rilascio degli NSObject (fonte https://daringfireball.net/2020/11/the_m1_macs ).

Praticamente quasi tutte le risorse a livello di S.O. e framework applicativi Apple sono gestite come NSObject (gestiti con reference counting), quindi questo ha effetto su tutte le applicazioni compilate appositamente per il S.O. Apple.
Si parla di circa 30 ns su x86, circa 6.5 ns su M1 nativo e circa 14 ns con codice "per Apple x86" emulato su M1.
Questo ha anche risvolti positivi sul risparmio energetico complessivo.
E suppongo che vi siano altre ottimizzazioni meno evidenti che traggono vantaggio da M1.
Sì, ma non è una novità: iOS funziona già così da anni pure coi precedenti SoC Apple.

Apple è passata all'architettura a soli 64 bit anche per questo motivo, perché sfrutta parte dei bit dei puntatori come "tag" per memorizzare delle informazioni per il garbage collector e altro. Ecco perché riesce a essere così veloce nell'allocazione, utilizzo, e rilascio degli oggetti.

E' una caratteristica peculiare dell'implementazione Apple di AArch64, ma che anche altri produttori CPU potrebbe utilizzare, anche con architetture completamente diverse.
Penso che sia da li che hanno origine molti dei miglioramenti in termini di prestazioni e risparmio energetico: ottimizzazione sinergica di hardware e software.
Rispetto alle più che buone performance con app x86 compilate per Mac, c'è quindi da aspettarsi prestazioni più basse quando si fa girare in emulazione software x86 per Windows sugli M1.
Con codice x86 che chiama poco il S.O. rispetto al tempo in cui esegue codice le prestazioni saranno più basse, mentre se si usa solo software compilato per Mac (per M1 o per x86 ma che chiama spesso il S.O.) si avranno prestazioni migliori.
Esattamente, ed è anche normale e ovvio che sia così: il livello di integrazione nonché personalizzazione fra hardware e software che ha Apple non ce l'ha nessuno, e i benefici sono evidenti.
2) il set di istruzioni è rilevante per quel che riguarda quali sono le ottimizzazioni architetturali di una cpu.
Se gli x86 di Intel ed AMD si sono fermati a decodificare 4..5 istruzioni per ciclo, mentre Apple ne decodifica 8, é perche con l'attuale architettura x86 il rapporto prestazioni/costo arriva fino a li, mentre con AArch64 è possibile salire oltre prima che il "costo implementativo" superi i benefici.
Questo succede perché quelle di x86/x64 sono istruzioni CISC, e che dunque generano più micro-op, mentre quelle di AArch64 sono RISC e normalmente non generano più micro-op.

Dunque non si possono confrontare direttamente le 4-5 (ma credo che siano 4 al massimo, pure con Skylake) di x86/x64 con le 8 di AArch64/Apple.

IMO il vero vantaggio (a livello prestazionale) delle micro-architetture Apple è il mostruoso backend unito a una montagna di risorse in più che sono messe a sua disposizione.

Il frontend di x86/x64, per quanto certamente molto più complicato di quello di AArch64, è relativamente piccolo perché da parecchi a questa parte è sostanzialmente lo stesso, con qualche piccola aggiunta che è stata via via fatta.

Considerato che il numero di transistor a disposizione (e utilizzati) raddoppia ogni 2 anni, puoi capire da solo che in tutti questi anni tale frontend occupi ormai ben poco spazio rispetto a tutto il resto.

Ricapitolando: è complicato e succhia energia, ma con chip da decine di miliardi di transistor ormai il suo peso è relativamente trascurabile.
Sia chiaro che non è che Arm sia superiore ad x86 o viceversa, ma che set di istruzioni differenti possono richiedere ottimizzazioni architetturali differenti
Assolutamente. Uno dei vantaggi dei RISC, che si rivela essere una forte penalizzazione di x86/x64 in diversi casi comuni, è dato dalla possibilità di eseguire istruzioni ternarie (due registri sorgenti e uno destinazione), che consente loro di risparmiare sia un registro (o, al limite, di usare lo stesso registro, ma creando uno stallo nella pipeline a causa della dipendenza che si crea) sia un'istruzione eseguita (x86/x64 devono usare in ogni caso due istruzioni per poter fare la stessa cosa).
(es: sugli x86 è già da anni conveniente avere l'hyperthreading, sugli Arm ancora no).
Anche sugli ARM sarebbe conveniente, e mi riferisco principalmente per le micro-architetture che hanno core grossi.

Il discrimine se usare tecnologie come HT/SMT IMO è proprio quello: quanto grandi siano i core (che, quindi, richiedono una piccola percentuale di transistor per duplicare le risorse necessarie per i due o più thread hardware).
3) Gira voce che nel 2021 Apple proporrà sul mercato un evoluzione di M1 con 12 core (8 ad alte prestazioni e 4 a basso consumo), non mi stupirei se fosse quella la cpu che verrà proposta per la fascia desktop/workstation/server.
Sui desktop non avrei dubbi, ma su workstation e server sì, visto che lì serve parecchia memoria, e i SoC Apple hanno i chip saldati sopra.
Ipotizzo che semplicemente non ci sarà la GPU integrata ed al suo posto ci saranno altri 4 core e le interconnessioni ed interfacce per supportare una maggior quantità di ram e la GPU "esterna" (oppure nello stesso package?).
La GPU integrata fa comodo, specialmente considerando che usa lo stesso bus per accedere alla memoria. E dunque diversi carichi di lavoro si possono smistare a questa componente.

Cut

la tua architettura ha istruzioni ternarie?
ha qualche forma (non totalmente) di ortogonalità delle istruzioni ?

la tua architettura ha istruzioni ternarie?
Certamente, e proprio per quanto detto sopra non potevano mancare. :D

Più precisamente per tutte le istruzioni che sono esclusivamente binarie (la maggior parte di quelle più vecchie; quelle nuove spesso sono già ternarie di loro, ma sono comunque poche al momento) ho tre possibilità:
- R1 = R2 op immediato-con-segno-a-8 bit soltanto per poche istruzioni (le più comuni: ADD, SUB, SBB, ecc..)
- R1 = R2 op R3 per tutte le istruzioni binarie;
- R1 = R2 op Memoria (oppure Memoria = R2 op R1) per tutte le istruzioni binarie, che vengono "promosse" (dall'attuale forma R1 = R1 op Memoria, oppure Memoria = Memoria op R1) potendo impiegare un registro addizionale (che ho chiamato genericamente R2) quale prima sorgente.

Le prime forme occupano 32-bit / 4 byte, quindi la dimensione è la stessa dei RISC, e non c'è penalizzazione da questo punto di vista. La terza forma, dovendo prevedere la possibilità di referenziare la memoria (oltre ai registri) occupa necessariamente più di 4 byte, ma in questo caso posso applicare/abilitare "gratuitamente" (senza richiedere ulteriori byte in più) alcune delle caratteristiche che ho elencato prima ("non-temporal", flag modificati o soppressi, estensione con zero o segno della seconda sorgente con dimensione inferiore all'istruzione).
ha qualche forma (non totalmente) di ortogonalità delle istruzioni ?
Le istruzioni sono per lo più ortogonali, perché agiscono su tutti i registri indifferentemente, e soprattutto la dimensione dell'operando è liberamente selezionabile fra byte/word/longword/quadword (perfino per istruzioni che su x86/x64 supportano soltanto alcune di quelle dimensioni).

La cosa più interessante, però, è l'unità SIMD, che è totalmente ortogonale: ogni istruzione può operare indifferentemente:
- sui registri MMX, SSE, AVX, AVX-512;
- può essere scalare (non su MMX, ovviamente) o packed (128, 256, 512 o 1024 bit. Con l'opzione del supporto ai registri vettoriali a dimensione variabile nel caso di soppressione del supporto alle MMX);
- può essere intera o floating point;
- può essere a 8, 16, 32 o 64 bit se è intera, o 16, 32, 64 o 128 bit se è floating point;
- maschere e istruzioni di gather/scatter funzionano su qualunque set di registri (MMX, SSE, AVX, AVX-512), anche se le estensioni SIMD originali non lo prevedevano.

Nell'architettura ci sono anche delle istruzioni non ortogonali, ma sono per lo più relative alle versioni "compressed"/corte/"quick". Come, peraltro, capita con altre architetture (perché le istruzioni compresse hanno opcode più piccoli, e quindi si devono fare necessariamente delle scelte, come ad esempio supportare soltanto un sottoinsieme dei registri disponibili).

Augurare a Intel di meritarsi quel che sta passando equivale, per un consumatore, a darsi una martellata sui gioielli di famiglia.



"il prezzo lo fa il mercato"

ma lol il mercato dove intel domina sempre e dove sente il pepe al culo perchè c'è amd non è lo stesso

"il prezzo lo fa il mercato"

ma lol il mercato dove intel domina sempre e dove sente il pepe al culo perchè c'è amd non è lo stesso
Hai editato? Bravo, perché la motivazione che hai dato: "Motivo: Errore" è del tutto falsa, visto che alla tua prima scrittura mi avevi subito accusato di essere partigiano.

Che poi fa semplicemente ridere, detto da uno che ha scelto come nick amd-novello...

E hai editato anche perché prima avevi quotato questo:
"Augurare a Intel di meritarsi quel che sta passando equivale, per un consumatore, a darsi una martellata sui gioielli di famiglia."

e poi aggiunto il commento attuale, che ovviamente non c'entra assolutamente nulla con la frase quotata.

Evidentemente alla prima scrittura del commento era prevalso il cieco fanatismo della tua marca del cuore.

Poi, passate due ore (ce n'è voluto, eh!), ti sei ripreso e hai corretto il tiro, eliminando lo strafalcione (un accostamento che non aveva il minimo senso), ma lasciando comunque la tua vena polemica, sulla quale non replico nemmeno perché non ne vale la pena.

Lol ma curati

Lol ma curati
Detto da un fanatico AMD (nomen omen: bel nick che ti sei scelto!) che vive nella più completa confusione (vedi sopra, dove mi sono semplicemente limitato a riportare quello che hai fatto) e che si sia sentito in dovere di difendere la propria marca del cuore anche quando non ce ne fosse assolutamente bisogno sennò non poteva dormire la notte, lo prendo come un complimento.

Continua pure a fare sogni bagnati con Lisa Su...