Link alla notizia: https://www.hwupgrade.it/news/sistemi-operativi/windows-on-arm-piu-veloce-sui-mac-m1-che-su-surface-pro-x-il-test_93872.html

Chi è riuscito a installare Windows on ARM sui sistemi Mac con processore M1 ha potuto verificare prestazioni "piuttosto elevate". A tal punto che i nuovi sistemi Apple sono più veloci di quelli di Microsoft, che possono sfruttare nativamente l'architettura proprietaria

Click sul link per visualizzare la notizia.

Link alla notizia: https://www.hwupgrade.it/news/sistemi-operativi/windows-on-arm-piu-veloce-sui-mac-m1-che-su-surface-pro-x-il-test_93872.html

Chi è riuscito a installare Windows on ARM sui sistemi Mac con processore M1 ha potuto verificare prestazioni "piuttosto elevate". A tal punto che i nuovi sistemi Apple sono più veloci di quelli di Microsoft, che possono sfruttare nativamente l'architettura proprietaria

Click sul link per visualizzare la notizia.

Roba obsoleta. Guardate qua:
https://www.eetimes.com/micro-magic-risc-v-core-claims-to-beat-apple-m1-and-arm-cortex-a9/

RISC-V core, 5GHx, consuma 200mW!!!! Cioe' 0.2W. 100 volte meno di M1.
E niente royalties, e' un Risc-V.

No vabbè, assurdo.
Ma MS che sta combinando? Possibile che restino così fermi sugli allori?
Ok che MacOS resterà di nicchia (quanto avrà, il 10% del mercato desktop) però manco lavorare così male...

...bello questo articolo...

E come dire che Windows gira più veloce su un PC di generazione successiva....

Prossimo articolo.... Le APP girano più veloci su iPhone 13 che su iPhone 12

Fosse stato Windows per x86/x64 gira più veloche che su Core i9 10xxx già se ne riparlava, ma questi articoli fatti apposta per i click e pubblicizzare apple...

Inoltre ricordo che MacOS 9 girava meglio su Amiga 4000 con Shapeshifter che su Quadra 900.....
(Si Amiga aveva il 68040 / 25Mhz ....e su 68060/50Mhz tutti i MAC erano lumache)
Stessa qualità d'articolo.

No vabbè, assurdo.
Ma MS che sta combinando? Possibile che restino così fermi sugli allori?
Ok che MacOS resterà di nicchia (quanto avrà, il 10% del mercato desktop) però manco lavorare così male...

Guarda che apple non e' affatto RISC-V, anzi e' la concorrenza. Semplicemente
questa ditta fa le cose seriamente.

;47138708']...bello questo articolo...

E come dire che Windows gira più veloce su un PC di generazione successiva....

Prossimo articolo.... Le APP girano più veloci su iPhone 13 che su iPhone 12

Fosse stato Windows per x86/x64 gira più veloche che su Core i9 10xxx già se ne riparlava, ma questi articoli fatti apposta per i click e pubblicizzare apple...

Magari leggere l'articolo aiuterebbe. Di nuovo, te lo rispiego:
RISC-V NON E' APPLE MA LA CONCORRENZA.
SI TRATTA DI UN'ALTRA DITTA CON UN ALTRO PROCESSORE.

M$ non ha mai cercato le prestazioni per i suoi surface, si e' limitata e fare le macchine apripista di riferimento 2in1 di potenza adeguata e poi consentire ai suoi "coopetitor" (HP, Dell, etc.) a cui licenzia il software, di sbizzarrirsi con le configurazioni.

Le configurazioni del surface X sono addirittura oscene, con dischi da 128GB...

Adesso che ci danno dentro di virtualizzazioni voglio proprio vedere con 8GB di RAM...

Di solito il tallone d'achille di qemu e' la grafica; nonostante con le virtualizzazioni e le paravirtualizzazioni per l'i/o raggiunge anche il 90-95% delle prestazioni native, quando entra in gioco la grafica (escludendo il passthrough che richiede la doppia scheda video), queste calano vistosamente.

Sarebbe interessante conoscere questi dati.

Per giunta gia Windows for ARM dovrebbe usare un'emulatore (alla Rosetta) per fare girare a sua volta le applicazioni Windows X64 (e' gia' uscito? Dicevano Novembre).

Questo è solo l’inizio.. con m1x e le prossime architetture per desktop...bah..ne vedremo delle belle.

Scritto da @vla7742
Magari leggere l'articolo aiuterebbe. Di nuovo, te lo rispiego:
RISC-V NON E' APPLE MA LA CONCORRENZA.
SI TRATTA DI UN'ALTRA DITTA CON UN ALTRO PROCESSORE.

.....forse leggere a chi rispondi e il POST aiuterebbe quanto leggere l'articolo

ARM M1 (Apple) e ARM SQ2 (Microsoft) non è POWER-V (Che centra con il quote del mio post) che serve solo a dimostrare che ARM SQ2 e di un anno indietro di progettazione confronto ad M1..... Quindi di che stiamo a parlare.

Se proprio va fatto un "Confronto" andrà fatto con Surface Pro X II

Questo è solo l’inizio.. con m1x e le prossime architetture per desktop...bah..ne vedremo delle belle.

Mi ricordo di test che virtualizzanodo lo stesso OS nativo dava punteggi più alti in alcuni benchmark.
In seguito si scopri essere un bug del test che misurava male il timing in virtualizzazione e 30 secondi reali erano misurati come 20.
Quindi occhio a comparare risultati di benchmark, preferisco utilizzare un software di calcolo che sia presente nativamente per le due architetture ( e con le accelerazioni abilitate per l'architettura sul quale gira.
Ma occhio anche a prendere con le pinze anche tale confronto:
Se oggi su un ryzen un calcolo impiega 30 sec e domani con un aggiornamento del programma ne impiega 20 non è diventato più veloce la cpu, ma più efficiente l'algoritmo di calcolo

Roba obsoleta. Guardate qua:
https://www.eetimes.com/micro-magic-risc-v-core-claims-to-beat-apple-m1-and-arm-cortex-a9/

RISC-V core, 5GHx, consuma 200mW!!!! Cioe' 0.2W. 100 volte meno di M1.
E niente royalties, e' un Risc-V.

Scusa ma dall'articolo da te citato
Huang said that although the company has successfully operated as an EDA services company, it intends to offer the RISC-V core to customers using an IP licensing model.

Quindi RISC-V è open e senza royalties ma la CPU che ha ottenuto quelle performance viene ceduta in licenza a pagamento

;47138822'].....forse leggere a chi rispondi e il POST aiuterebbe quanto leggere l'articolo

ARM M1 (Apple) e ARM SQ2 (Microsoft) non è POWER-V (Che centra con il quote del mio post) che serve solo a dimostrare che ARM SQ2 e di un anno indietro di progettazione confronto ad M1..... Quindi di che stiamo a parlare.

Se proprio va fatto un "Confronto" andrà fatto con Surface Pro X II Un anno? 2-3 minimo.

Roba obsoleta. Guardate qua:
https://www.eetimes.com/micro-magic-risc-v-core-claims-to-beat-apple-m1-and-arm-cortex-a9/

RISC-V core, 5GHx, consuma 200mW!!!! Cioe' 0.2W. 100 volte meno di M1.
E niente royalties, e' un Risc-V.100 volte di meno? Soltanto..? Scusa ma ti sembra credibile come cosa? Sinceramente.

Si torna a fine Anni ‘80: Apple macchine costose ma completamente di altro livello!!! Finalmente!!!

Roba obsoleta. Guardate qua:
https://www.eetimes.com/micro-magic-risc-v-core-claims-to-beat-apple-m1-and-arm-cortex-a9/

RISC-V core, 5GHx, consuma 200mW!!!! Cioe' 0.2W. 100 volte meno di M1.
E niente royalties, e' un Risc-V.

...ma che c’entra???
Apple ha presentato un’architettura assolutamente nuova, con il vantaggio *ENORME* di una integrazione *ASSOLUTA* fra chip e OS, come succedeva all’inizio dell’informatica, per le macchine ultra-specializzate.
È chiaro che se prendi uno schifo-chip che deve fare solo una cosa, magari possa essere pure più veloce, ma M1 e OS-X costituiscono un environment completo, rivolto a professionisti e sviluppatori....

Questa cosa direi che lascia abbastanza il tempo che trova.
Apple su M1 ha mostrato un lavoro notevole ed ha sfornato un SOC davvero valido ragionando in termini di PC e non di smartphone o tablet.
E' piuttosto ovvio che M1 sia superiore in potenza a dei SOC arm di generazioni precedenti oltretutto pensati per smartphone o tablet.

Adesso è facile immaginare che anche altri produttori (Nvidia?) calchino la mano in questo senso realizzando SOC su base ARM di altrettanta potenza o probabilmete anche superiore.

;47138708']...bello questo articolo...

E come dire che Windows gira più veloce su un PC di generazione successiva....

Prossimo articolo.... Le APP girano più veloci su iPhone 13 che su iPhone 12

Fosse stato Windows per x86/x64 gira più veloche che su Core i9 10xxx già se ne riparlava, ma questi articoli fatti apposta per i click e pubblicizzare apple...

Inoltre ricordo che MacOS 9 girava meglio su Amiga 4000 con Shapeshifter che su Quadra 900.....
(Si Amiga aveva il 68040 / 25Mhz ....e su 68060/50Mhz tutti i MAC erano lumache)
Stessa qualità d'articolo.

Ricordi molto male:

Mac OS 9 uscì a fine '99 e supportava esclusivamente i Mac con PPC;

Nessun Macintosh Classic, di cui faceva parte la famiglia Quadra ( 900/950 ), ha mai ricevuto i Motorola 68060.

Si torna a fine Anni ‘80: Apple macchine costose ma completamente di altro livello!!! Finalmente!!!

Ad onor del vero si tratta di due approcci differenti.
In quegli anni del boom dei personal computer diversi produttori facevano scelte molto diverse nei loro prodotti perchè era ancora poco chiaro quale fosse la giusta direzione.
Così metre i primi PC si basavano su processori X86 a 16 bit piuttosto limitati Apple optò per i Motorola già realizzati a quel tempo a 32 bit.
Una scelta molto valida visto che i primi MAC potevano fare cose che per i limitati processori X86 erano inarrivabili.
Le cose poi cambiarono nel giro di qualche anno ed il gap iniziale si ando a ridurre velocemente per poi essere completamente superato, tanto è vero che alla fine Apple staeesa dovette mollare Motorola che non era in grado di competere e dovette passare anche lei ad Intel.

Questa cosa direi che lascia abbastanza il tempo che trova.
Apple su M1 ha mostrato un lavoro notevole ed ha sfornato un SOC davvero valido ragionando in termini di PC e non di smartphone o tablet.
E' piuttosto ovvio che M1 sia superiore in potenza a dei SOC arm di generazioni precedenti oltretutto pensati per smartphone o tablet.

Adesso è facile immaginare che anche altri produttori (Nvidia?) calchino la mano in questo senso realizzando SOC su base ARM di altrettanta potenza o probabilmete anche superiore.

Quello che è meno ovvio è che asfalta anche i processori x86 "potenti". Guardati i video in cui lo mettono a confronto con i MacBook Pro 16 (che hanno i7 o i9) o semplicemente installa Cinebench R23 sul tuo pc e guarda i punteggi che tira fuori. Si, so che il tuo 2600K è molto vecchio (così come il mio 4790K ormai) ma io ho provato anche su uno dei miei pc in ufficio (i9 9900K con un dissipatore BeQuiet che è grande da solo come un Mac Mini :asd:) e in single core fa meno punti del M1... hanno tirato fuori un mostro, non solo in ambito SoC.
Se gli altri faranno roba simile o superiore non posso che essere contento... ma non lo vedo così scontato.

Originariamente inviato da: AlexSwitch02
Ricordi molto male:
Mac OS 9 uscì a fine '99 e supportava esclusivamente i Mac con PPC;
Nessun Macintosh Classic, di cui faceva parte la famiglia Quadra ( 900/950 ), ha mai ricevuto i Motorola 68060.

E' passato qualche anno sai....e non uso MAC, magari non sarà OS9 ma OS8 (680x0), e si solo Amiga, qualche F16 e qualche Ecografo hanno ricevuto lo 68060 ed era inteso per quello che i Mac 68040 erano lumache (no che con il 060 lo fossero) il confronto, era solo per indicare un esempio pregresso dove a parità di codice senza ricompilazione l'architettura e la generazione di processore fà la differenza, non mi puoi fare un confronto del genere tra Surface X e Mac con M1, visto che Windows ARM su ARM gira nativamente e ci stà "Almeno" una generazione di processore di differenza, (si microsoft poteva fare meglio su quel progetto lo so) è come confrontare e dire windows gira meglio su 486DX PCI che su 386SX ISA.... e grazie al Cavolo.

Comunque manca quest'anno l'articolo dove un iPhone xx salva la vita a qualcuno, già un milioramento c'è stato sulle scelte editoriali.

Quello che è meno ovvio è che asfalta anche i processori x86 "potenti". Guardati i video in cui lo mettono a confronto con i MacBook Pro 16 (che hanno i7 o i9) o semplicemente installa Cinebench R23 sul tuo pc e guarda i punteggi che tira fuori. Si, so che il tuo 2600K è molto vecchio (così come il mio 4790K ormai) ma io ho provato anche su uno dei miei pc in ufficio (i9 9900K con un dissipatore BeQuiet che è grande da solo come un Mac Mini :asd:) e in single core fa meno punti del M1... hanno tirato fuori un mostro, non solo in ambito SoC.
Se gli altri faranno roba simile o superiore non posso che essere contento... ma non lo vedo così scontato.

ed in multi come se la cava? senza polemiche, rispetto un 9900k?

ed in multi come se la cava? senza polemiche, rispetto un 9900k?In Cinebench R23 M1 ottiene 7700 punti in multicore. i9 9900k 12.500. In geekbench 7500 vs 8700. Non ho i dati per SPEC2017 ma dovrebbe essere a metà strada fra i 2.

In sintesi l'i9 è chiaramente più performante in full multicore, ma la cosa non dovrebbe sorprendere.

;47139471']E' passato qualche anno sai....e non uso MAC, magari non sarà OS9 ma OS8 (680x0), e si solo Amiga, qualche F16 e qualche Ecografo hanno ricevuto lo 68060 ed era inteso per quello che i Mac 68040 erano lumache (no che con il 060 lo fossero) il confronto, era solo per indicare un esempio pregresso dove a parità di codice senza ricompilazione l'architettura e la generazione di processore fà la differenza, non mi puoi fare un confronto del genere tra Surface X e Mac con M1, visto che Windows ARM su ARM gira nativamente e ci stà "Almeno" una generazione di processore di differenza, (si microsoft poteva fare meglio su quel progetto lo so) è come confrontare e dire windows gira meglio su 486DX PCI che su 386SX ISA.... e grazie al Cavolo.

Comunque manca quest'anno l'articolo dove un iPhone xx salva la vita a qualcuno, già un milioramento c'è stato sulle scelte editoriali.

Su come vengono redatti diversi articoli sono pienamente d'accordo... Il messaggio, come pubblicato da altri siti, è che sui Mac M1 si può installare tranquillamente Windows ARM, senza troppi hack.

...comunque rimane che sono tutte discussioni su "Aria Fritta", le architetture e le scelte non sono più paragonabili, visto che sono due cose ben distinte e intel e amd non hanno mai implementato unità AI all'interno delle loro CPU.

M1 sarà almeno (ma minimo) 20 volte più veloce di i9 9900k nel deep learning ed in calcoli dedicati dove le unità neurali ne fanno da padrone.

La differenza la si vedrà tra un annetto, pure Qualcomm si muove in quell'ambito (ora), intel invece pur avendo creato delle ottime unità per il deep learning non le ha mai integrate nelle sue GPU ma ha sempre fatto dei "CoProcessori" da usare su pennetta USB o su Hardware dedicato. (bello sbaglio...).

E le differenze le vedremo proprio in quei software dove MAC ha sempre tenuto la corona, magari non nella prima release ma in quelle future, vorrei vedere in Photoshop o in Premiere dove il software deve "Decidere" come ricostruire un area le differenze tra Computazione con AI e senza AI chi vince, forse solo con la RTX usando i Tensor Core, ma vuoi mettere su un portatile Mac fare un ritocco in un filmato e non doverlo dar in pasto ad una GPU da 600w.

io non capisco cosa vuol dire virtualizzare un OS e metterlo a confronto, contando che WonARM è ancora da finalizzare! forse ci girava meglio ancora windows x86 virtualizzato!!
adesso prendo win95 e lo virtualizzo! guarda come corre, meglio del mio 486 a 25MHz

Quello che è meno ovvio è che asfalta anche i processori x86 "potenti". Guardati i video in cui lo mettono a confronto con i MacBook Pro 16 (che hanno i7 o i9) o semplicemente installa Cinebench R23 sul tuo pc e guarda i punteggi che tira fuori. Si, so che il tuo 2600K è molto vecchio (così come il mio 4790K ormai) ma io ho provato anche su uno dei miei pc in ufficio (i9 9900K con un dissipatore BeQuiet che è grande da solo come un Mac Mini :asd:) e in single core fa meno punti del M1... hanno tirato fuori un mostro, non solo in ambito SoC.
Se gli altri faranno roba simile o superiore non posso che essere contento... ma non lo vedo così scontato.

Non fraintendermi, sono il primo ad essere sorpreso ed entusiasta di questo nuovo SOC.. perchè è chiaro che se lo ha fatto Apple vuol dire che possono farlo anche altri e un domani avremo davvero PC su base arm di potenza notevole.

ed in multi come se la cava? senza polemiche, rispetto un 9900k?

In Cinebench R23 M1 ottiene 7700 punti in multicore. i9 9900k 12.500. In geekbench 7500 vs 8700. Non ho i dati per SPEC2017 ma dovrebbe essere a metà strada fra i 2.

In sintesi l'i9 è chiaramente più performante in full multicore, ma la cosa non dovrebbe sorprendere.

Esatto, 12500 circa. Ma parliamo di una cpu che fa fatica ad essere raffreddata da dissipatori da un kg...

Non fraintendermi, sono il primo ad essere sorpreso ed entusiasta di questo nuovo SOC.. perchè è chiaro che se lo ha fatto Apple vuol dire che possono farlo anche altri e un domani avremo davvero PC su base arm di potenza notevole.

Un domani si. Oggi però c'è quello. e quello va valutato. :)

Non asfalta un fico secco, è un chippetto da pochi Watt che si fa pubblicità solo con bench sintetici, per giunta alcuni di questi nati apposta per i telefonini, credere che un chip del genere possa fornire le stesse performance di un x86 da oltre 100W è poco credibile.

Su Cinebench R23 è sotto un 4600U che è una CPU basata su Zen2 da 15W di TDP e nonostante questo M1 disponga anche di un vantaggio di nodo consistente.

Non asfalta un fico secco, è un chippetto da pochi Watt che si fa pubblicità solo con qualche bench sintetico, credere che un chip del genere possa fornire le stesse performance di un x86 da oltre 100W è poco credibile.

Cinebench R23 è compilato in modo che l'M1 possa eseguirlo usando la parte grafica che è molto più efficiente ovviamente, cosa che le altre CPU non fanno e nonostante ciò riesce pure a perdere, quindi è un test che lascia il tempo che trova.

Beh no. Ci sono svariati test su Phoronix ( e molti non sono sintetici ) e ci sono i bench su Google Chrome.

Ma del resto era ovvio. Lo dico da anni che l'utilizzo mirato di acceleratori hardware, produce risultati fantastici. Amiga dovrebbe averci insegnato qualcosa a riguardo.

Alla fin fine, la customizzazione del mondo ARM giocherà a loro favore. Intel ( e AMD ) ha sempre voluto vendere monoblocchi, con dentro solo quello che secondo il loro, insindacabile parere, è importante. E ti ritrovi con Torvalds che giustamente spara a zero sulle AVX-512 che saranno usate, si e no, da 1000 persone su tutto il pianeta. Ma l'obolo lo paghiamo tutti.

Non asfalta un fico secco, è un chippetto da pochi Watt che si fa pubblicità solo con qualche bench sintetico, credere che un chip del genere possa fornire le stesse performance di un x86 da oltre 100W è poco credibile.

Cinebench R23 è compilato in modo che l'M1 possa eseguirlo usando la parte grafica che è molto più efficiente ovviamente, cosa che le altre CPU non fanno e nonostante ciò riesce pure a perdere, quindi è un test che lascia il tempo che trova.Stai scrivendo delle sciocchezze.

M1 ha performance eccellenti in Geekbench, R23 e SPEC, sia nella versione 2006 che 2017.
Eccelle anche nel compiling software (ben poco sintetico direi):
https://www.imore.com/sites/imore.com/files/styles/larger/public/field/image/2020/11/dave2d-xcode-build-times-m1-mba.jpeg
Nei benchmark web asfalta la concorrenza, anche usando lo stesso software.
Persino nella compressione ha performance eccellenti: https://cdn.arstechnica.net/wp-content/uploads/2020/11/Apple-M1-Mac-Mini.pigz-p1-1-1440x1080.png

Vorrei poi vedere un link che mostri che Cinebench usa la GPU nella sua versione ARM.
E poi... riuscire a perdere rispetto a cosa? :asd:

Beh no. Ci sono svariati test su Phoronix ( e molti non sono sintetici ) e ci sono i bench su Google Chrome.Si molto significativi i test su Chrome guarda :asd:
Parliamoci chiaro quando vedremo test di confronto su note suite di video-editing e conversione video pesante che permettono di sfruttare le VGA anche su X86 o test su videogiochi triplaA a bassa risoluzione ne riparleremo.

Ma del resto era ovvio. Lo dico da anni che l'utilizzo mirato di acceleratori hardware, produce risultati fantastici. Amiga dovrebbe averci insegnato qualcosa a riguardo.
Produce solamente confronti tarocchi e non indicativi direttamente.

Alla fin fine, la customizzazione del mondo ARM giocherà a loro favore. Può giocare a loro favore ma solo nel mondo mobile low end, dove con bassi valori di consumo possono dare il meglio di sè, ma nei piani alti fino a che ci saranno limiti di TDP e consumo non si va lontano. inoltre nessun chippetto ARM grosso o piccolo che sia può integrare una GPU paragonabile ad una High End.

Stai scrivendo delle sciocchezze.

M1 ha performance eccellenti in Geekbench, R23 e SPEC, sia nella versione 2006 che 2017.
Eccelle anche nel compiling software (ben poco sintetico direi):
Nei benchmark web asfalta la concorrenza, anche usando lo stesso software.

Vorrei poi vedere un link che mostri che Cinebench usa la GPU nella sua versione ARM.
E poi... riuscire a perdere rispetto a cosa? :asd:
Ah bè allora .... :O
GeekBench, SPEC2006 e Chrome molto significativi per valutare la reale performance di una workstation.

Stai scrivendo delle sciocchezze.

M1 ha performance eccellenti in Geekbench, R23 e SPEC, sia nella versione 2006 che 2017.
Eccelle anche nel compiling software (ben poco sintetico direi):
https://www.imore.com/sites/imore.com/files/styles/larger/public/field/image/2020/11/dave2d-xcode-build-times-m1-mba.jpeg
Nei benchmark web asfalta la concorrenza, anche usando lo stesso software.
Persino nella compressione ha performance eccellenti: https://cdn.arstechnica.net/wp-content/uploads/2020/11/Apple-M1-Mac-Mini.pigz-p1-1-1440x1080.png

Vorrei poi vedere un link che mostri che Cinebench usa la GPU nella sua versione ARM.
E poi... riuscire a perdere rispetto a cosa? :asd:
aggiungo che ormai il mondo è pieno di test su sw specifici (dalla suite adobe a davinci a altri)

Ah bè allora .... se lo dice GeekBench .... :OSei serio? Fra i vari dati che ho fornito ancora ti attacchi a GB?

Continuo ad aspettare il link che confermi che Cinebench usa la GPU nel suo risultato M1. :read:

Anzi, permettimi di dimostrarti che hai scritto una sciocchezza direttamente.

Eccoti i powermetric durante un run di R23 multicore:

https://i.ibb.co/HzS7L4M/En-DBV0-UUAEWXKG.jpg


Core "performance" al 100%. Core "Efficiency" usati al 100%.
CPU power usage: 15W(!).
GPU power usage. 9mW

:read:


Ora, proviamo con un benchmark 3D come GFX bench.

https://i.ibb.co/51ctnMs/En-DF9z-KWMAMlnv-Y.png

Oltre 10W per la GPU.

Sei serio? Fra i vari dati che ho fornito ancora ti attacchi a GB?

Continuo ad aspettare il link che confermi che Cinebench usa la GPU nel suo risultato M1. :read:Hai ragione, devo aver fatto confusione, fa uso di un unità float più efficiente rispetto alle FPU degli x86 :

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2

On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors. Floating-point operations throughput here is 1:1 with the pipeline count, meaning Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles).


Motivo però per cui registra valori alti in tutti gli ambiti che fanno ampio uso di calcoli in virgola mobile, come tutti quelli da te elencati.

Ciò non cambia però il fatto che il confronto contro gli x86 sul Cinebench non sia direttamente indicativo nel confronto con un X86. Escludendo il lato Float dove in ambienti X86 sarà comunque possibile usare la GPU discreta, in tutto il resto è da verificare sul lato pratico, dove appunto non c'è ancora nessun risultato.

Ciò non cambia però il fatto che il confronto contro gli x86 sul Cinebench non sia direttamente indicativo con le performance che è in grado di fornire questa CPU. Escludendo il lato Float dove in ambienti X86 sarà comunque possibile usare la GPU discreta, è tutto da verificare sul lato pratico, dove appunto non c'è ancora nessun risultato.

Se la poniamo in questi termini di "INDICATIVO" non c'è niente.
Di solito per vedere quanto va una CPU gli si fa macinare calcoli in virgola mobile che sono quelli più pesanti.
Se viaggia bene su quelli va da se che se la cava bene anche in tutti gli altri scenari pratici di vita reale.

Se la poniamo in questi termini di "INDICATIVO" non c'è niente.
Di solito per vedere quanto va una CPU gli si fa macinare calcoli in virgola mobile che sono quelli più pesanti.
Se viaggia bene su quelli va da se che se la cava bene anche in tutti gli altri scenari pratici di vita reale.Per il grosso dei calcoli float oramai molti software si appoggiano alla GPU.

Se non sbaglio anche le GPU integrate sia in M1 così come anche le Mali son basate su medesima architettura, facile quindi intendere che questa architettura sia ugualmente affine a questo tipo di calcoli. Vedremo in altri contesti.

Se la poniamo in questi termini di "INDICATIVO" non c'è niente.
Di solito per vedere quanto va una CPU gli si fa macinare calcoli in virgola mobile che sono quelli più pesanti.
Se viaggia bene su quelli va da se che se la cava bene anche in tutti gli altri scenari pratici di vita reale.

Veramente nemmeno questo è un valore indicativo, e per molteplici fattori diversi:
Una cpu può essere il doppio più veloce ( parliamo di fp) entro determinati range di valori e andare la metà in altri.
Il raffronto che andrebbe fatto piuttosto è sulla resa ( perchè architetture diverse su os diversi non saranno mai direttamente confrontabili):
Prendo un mac e gli faccio renderizzare un video, la stessa cosa faccio con x86, ma non userò lo stesso software ma quello più performante su quella tipologia.
Misuro i tempi, comparo i risultati finali ( con output di uscità pressocche identici) e poi valuto quale infrastruttura è meglio.
Se in una conversione video istruzioni avx512 mi danno un boost 10x che mi permette di renderizzare nella metà tempo di m1 non vedo il motivo per il quale utilizzare premiere che non ne sfrutta le potenzialità ( solo per dire che lo si fa con lo stesso software).
Il mio è solo un esempio dove i prodotti e le funzionalità dovrebbero essere sostituiti da X e Y.
Un po come voler confrontare ( e lo si fece) un pentium con un pentium pro con software a 16 bit.
Il secondo era più lento ( e costoso), ma quando si utilizzava codice a 32bit non c'era storia nei tempi di esecuzione dello stesso lavoro

Hai ragione, fa uso di un unità float più efficiente rispetto alle FPU degli x86 :

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2

On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors. Floating-point operations throughput here is 1:1 with the pipeline count, meaning Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles).


Motivo però per cui registra valori alti in tutti gli ambiti che fanno ampio uso di calcoli in virgola mobile, come tutti quelli da te elencati.

Ciò non cambia però il fatto che il confronto contro gli x86 sul Cinebench non sia direttamente indicativo con le performance che è in grado di fornire questa CPU. Escludendo il lato Float dove in ambienti X86 sarà comunque possibile usare la GPU discreta, è tutto da verificare sul lato pratico, dove appunto non c'è ancora nessun risultato.Non è che puoi escludere in modo arbitrario le porzioni della CPU che non ti piacciono e aspettare i test in cui possibilmente M1 farà relativamente peggio rispetto ad x86 per affermare che il "chippetto" è scarso.

Usi l'analisi di Anandtech, ma evidentemente non ti piacciono le loro conclusioni: M1 ha performance per watt eccezionali e eccellenti performance in senso assoluto. In termini di IPC è superiore ai design AMD e Intel.
Questo è ciò che fondamentalmente dice Anandtech, e ciò che si evince dai test sinceramente.

Non ti piaccioni i benchmark sintetici. Non ti piacciono i test Web. Non ti piace la compilazione di codice software. Non ti piacciono test di compressione. Suppongo non ti piacciano neanche i test con app foto ( https://www.dday.it/redazione/37644/macbook-pro-2020-m1-photoshop-lightroom-affinity-photografia ). Final Cut (video editing), Logic Pro anche non ti andrebbero bene sicuramente (M1 vince easy).

Non è chiaro quindi cosa si debba usare per valutare questo processore.
Videogame non esistenti su MacOS e rendering con Blender non nativo forse? Sicuramente il campo di uso di un ultrabook come il MacbookAir... :sofico:


Dovresti dare una occhiata a video "reali" ( https://www.youtube.com/watch?v=_MUTS7xvKhQ&t=1530s ). Dopo ore di bench sintetici, Lightroom, Logic Pro ed editing video, xCode, R5 10Bit, il notebook con M1 ha ancora il 67% di batteria, mentre il macbook pro 16 Intel è morto. E le performance sono, nel caso peggiore, appena inferiori.
Quel video è assolutamente imbarazzante per intel. 60-90W. 100°, batteria che dura meno di 1/3 e ventola al 100% vs 30W, 60-70° e ventola quasi inesistente.

Dovresti dare una occhiata a video "reali" ( https://www.youtube.com/watch?v=_MUTS7xvKhQ&t=1530s ). Dopo ore di bench sintetici, Lightroom, Logic Pro ed editing video, il notebook con M1 ha ancora il 67% di batteria, mentre il macbook pro 16 Intel è morto. E le performance sono, nel caso peggiore, appena inferiori.Questa è la cosa che mi interessa di più, al di là delle mere prestazione (che saranno tutte da verificare, ma le premesse sembrano ottime... e di premesse ne ho lette fin troppe in questi giorni per non considerarle plausibili).

Se solo ci potessi emulare Windows 10 x86 64-bit al 100% ci farei un pensierino per il prossimo anno sul 13''.

Non ti piaccioni i benchmark sintetici. Non ti piacciono i test Web. Non ti piace la compilazione di codice software. Non ti piacciono test di compressione. Suppongo non ti piacciano neanche i test con app foto ( https://www.dday.it/redazione/37644/macbook-pro-2020-m1-photoshop-lightroom-affinity-photografia ). Final Cut (video editing), Logic Pro anche non ti andrebbero bene sicuramente (M1 vince easy).

Non è chiaro quindi cosa si debba usare per valutare questo processore.

i test approvati da lui lol

Si molto significativi i test su Chrome guarda :asd:

E' un browser. Un software estremamente generico. Non è certamente un benchmark sintetico. Non vedo perchè ridicolizzarlo.


Parliamoci chiaro quando vedremo test di confronto su note suite di video-editing e conversione video pesante che permettono di sfruttare le VGA anche su X86 o test su videogiochi triplaA a bassa risoluzione ne riparleremo.


Certo. Arriveranno, non temere.


Può giocare a loro favore ma solo nel mondo mobile low end, dove con bassi valori di consumo possono dare il meglio di sè, ma nei piani alti fino a che ci saranno limiti di TDP e consumo non si va lontano.


Continuo a non capire questa nozione secondo cui ARM avrebbe problemi col TDP. I deisgn ARM sono da sempre usati in ambiti in cui il TDP conta, per questo vediamo quasi soltanto SoC con basso TDP e poco performanti.

Ma poi abbiamo altri SoC ARM con TDP decisamente elevati, che vengono usati nei supercomputer https://www.arm.com/blogs/blueprint/fujitsu-a64fx-arm


Nessun chippetto ARM grosso o piccolo che sia può integrare una GPU paragonabile ad una High End.

Se è per questo, nemmeno un Ryzen o un Intel possono. Intanto Nvidia ci ha dimostrato di poter integrare GPU di fascia media nei suoi SoC ARM. Vedi i risultati https://www.phoronix.com/scan.php?page=article&item=nvidia-jetson-xavier&num=2



Per il resto è abbastanza chiaro, l'M1 che renderizza con la GPU perde con le CPU x86 è già indicativo a sufficienza.

Come sei arrivato a questa conclusione? Faccio notare che i test che sono stati fatto, usano quasi sempre software x86_64 tradotto da Rosetta. E trovo veramente difficilmente credere che quel software possa automagicamente sfruttare la GPU del SoC.

Non è che puoi escludere in modo arbitrario le porzioni della CPU che non ti piacciono e aspettare i test in cui possibilmente M1 farà relativamente peggio rispetto ad x86 per affermare che il "chippetto" è scarso.

Usi l'analisi di Anandtech, ma evidentemente non ti piacciono le loro conclusioni: M1 ha performance per watt eccezionali e eccellenti performance in senso assoluto. In termini di IPC è superiore ai design AMD e Intel.
Questo è ciò che fondamentalmente dice Anandtech, e ciò che si evince dai test sinceramente.

Non ti piaccioni i benchmark sintetici. Non ti piacciono i test Web. Non ti piace la compilazione di codice software. Non ti piacciono test di compressione. Suppongo non ti piacciano neanche i test con app foto ( https://www.dday.it/redazione/37644/macbook-pro-2020-m1-photoshop-lightroom-affinity-photografia ). Final Cut (video editing), Logic Pro anche non ti andrebbero bene sicuramente (M1 vince easy).

Non è chiaro quindi cosa si debba usare per valutare questo processore.
Videogame non esistenti su MacOS e rendering con Blender non nativo forse? Sicuramente il campo di uso di un ultrabook come il MacbookAir... :sofico:


Dovresti dare una occhiata a video "reali" ( https://www.youtube.com/watch?v=_MUTS7xvKhQ&t=1530s ). Dopo ore di bench sintetici, Lightroom, Logic Pro ed editing video, xCode, R5 10Bit, il notebook con M1 ha ancora il 67% di batteria, mentre il macbook pro 16 Intel è morto. E le performance sono, nel caso peggiore, appena inferiori.
Quel video è assolutamente imbarazzante per intel. 60-90W. 100°, batteria che dura meno di 1/3 e ventola al 100% vs 30W, 60-70° e ventola quasi inesistente.

ma solo a me è saltato all'occhio come le prestazioni del ryzen 4600h ( con tdp a 35w) ed architettura "vecchia" non sfiguara affatto e ridimensiona di molto in prospettiva l' M1?

Se solo ci potessi emulare Windows 10 x86 64-bit al 100% ci farei un pensierino per il prossimo anno sul 13''.

Non credo dovrai aspettare molto. Un tizio ha già virtualizzato Windows ARM sugli M1, e ha usato il traduttore binario fornito da Windows per far girare dei programmi x86.

Credo che MS a breve ultimerà i lavori su Windows ARM.

i test approvati da lui lol

Beh diciamo che si nota un astio nei confronti di ARM incomprensibile. Ma ricordo che i suoi interventi sono sempre stati di questo tenore. Lui parte dall'assunto ( tutto da dimostrare ) che ARM non può essere sinonimo di prestazioni.

E' evidente che gli dà parecchio fastidio vedere x86 messa all'angolo. E il fatto che sia stata Apple la prima a farlo ( lui è un fan Microsoft ) lo fa letteralmente imbestialire.

ma solo a me è saltato all'occhio come le prestazioni del ryzen 4600h ( con tdp a 35w) ed architettura "vecchia" non sfiguara affatto e ridimensiona di molto in prospettiva l' M1?

Non è a 45W? Comunque definire vecchia Zen 2...non esageriamo.

Ma il punto è che il M1 è a 15W!!! 3 M1 arrivano su Marte.

E comunque non è che Apple voglia fare gnè gnè al mondo x86. Semplicemente ha dimostrato che ai suoi Mac ARM non mancherà nulla rispetto alle controparti x86. E stiamo ancora ragionando su test di software x64 tradotti. Vedremo dove arriverà coi software prodotti specificamente per questo SoC.

Non credo dovrai aspettare molto. Un tizio ha già virtualizzato Windows ARM sugli M1, e ha usato il traduttore binario fornito da Windows per far girare dei programmi x86.

Credo che MS a breve ultimerà i lavori su Windows ARM.Il problema è che non so se anche Windows ARM possa fare al caso mio (ne avevo già parlato in altri topic). Un conto è capire se ci possa girare Excel o qualche altro programma abbastanza noto, per il quale trovare informazioni in giro sarebbe relativamente facile.

Un altro è farci girare programmi abbastanza particolari, semi-amatoriali e usati in ambiti ristretti, per i quali esistono solo versioni per Windows (ci fossero per Mac risolverei, ma neanche per Mac esistono). Se avessi la certezza che girino in emulazione sarei a cavallo.


Perchè poi quello che mi interessa è, appunto, l'autonomia. Ipoteticamente mi dovrebbe reggere almeno 10-12 ore con avviati 3-4 programmi che lavorano di continuo (certo, nulla che richieda chissà quali potenze di calcolo). In condizioni di luminosità dello schermo ridotta al minimo (vantaggio) e temperature anche sotto lo zero (svantaggio).

Leggendo una recensione, ho letto che il 13'' regge 13 ore e passa facendo girare un video in FullHD con la luminosità dello schermo al 50%. Nelle indicazioni della Apple si parla da 17 a 20 ore di autonomia.
Se questi valori fossero confermati, per me sarebbero perfetti.


Questa è la prima volta che un "portatile" Apple attira la mia attenzione. Certo, la possibilità del 2-in-1 del mio Surface PRO 3 la trovo una gran cosa, ma per una cosa del genere potrei giungere ad un compromesso.

ma solo a me è saltato all'occhio come le prestazioni del ryzen 4600h ( con tdp a 35w) ed architettura "vecchia" non sfiguara affatto e ridimensiona di molto in prospettiva l' M1?Non direi. In photoshop è 2 volte più lento e il TDP è maggiore.
Credo però Cezanne(5800U) possa ridimensionare M1.
Resta da vedere se Apple continuerà ad offrire un +20% di performance per anno, come ha fatto fino ad ora con i SoC per iphone. In quel caso la vedo difficile anche per AMD, dato che i loro tempi di refresh sono in media più lunghi.

E' un browser. Un software estremamente generico. Non è certamente un benchmark sintetico. Non vedo perchè ridicolizzarlo.perchè non conta nulla, le perfomance lato desktop si vedono su altre tipologie di applicativi, i test sul browser li riservo ai telefonini.

Certo. Arriveranno, non temere.Quando arriveranno vedremo di che pasta è fatto questo M1.

Continuo a non capire questa nozione secondo cui ARM avrebbe problemi col TDP. I deisgn ARM sono da sempre usati in ambiti in cui il TDP conta, per questo vediamo quasi soltanto SoC con basso TDP e poco performanti.

Ma poi abbiamo altri SoC ARM con TDP decisamente elevati, che vengono usati nei supercomputer https://www.arm.com/blogs/blueprint/fujitsu-a64fx-arm
Non mi pare che gli ARM ad alti TDP arrivati nel mercato anche da diversi anni abbiano mai spodestato gli Xeon.
Eppure se avessero veramente un IPC così elevato con 1/10 del consumo la totalità degli ambienti Unix based migrerebbe al volo.

Se è per questo, nemmeno un Ryzen o un Intel possono. Non è necessario visto che molti applicativi si poggiano già alla VGA discreta.

ma solo a me è saltato all'occhio come le prestazioni del ryzen 4600h ( con tdp a 35w) ed architettura "vecchia" non sfiguara affatto e ridimensiona di molto in prospettiva l' M1?

Che sono sempre una decina di watt in più rispetto alla versione più pompata di M1 ( quella montata su Mac Mini con dissipatore più grande e ventola ).
Inoltre qui in parecchi sembrano dimenticarsi il fatto che M1 è il SoC per i Mac di " fascia bassa " dove l'efficienza energetica ha la sua importanza ( unica eccezione è il Mac Mini ).
A breve ci saranno gli iMac e i MBP da 16" equipaggiati molto probabilmente con la prima evoluzione di M1 che dovrebbe garantire un ulteriore boost prestazionale.
Viste le premesse di M1, non immagino cosa potrà offrire un M1X o M2 con TDP compresi tra 35 e 45 Watt.

perchè non conta nulla, le perfomance lato desktop si vedono su altre tipologie di applicativi, i test sul browser li riservo ai telefonini.


Affermazione parecchio arrischiata. Un test WebGL non è indicativo della potenza della GPU? Un test coi webworkers non è indicativo delle capacità di multitasking della CPU?


Non mi pare che gli ARM ad alti TDP arrivati nel mercato anche da diversi anni abbiano mai spodestato gli Xeon. Eppure se avessero veramente un IPC così elevato con 1/10 del consumo la totalità degli ambienti Unix based migrerebbe al volo.

Erano design chiaramente inadeguati. E sono stati fatti si e no 3-4 esperimenti del genere. Non c'è stato nemmeno il tempo e i volumi tali da poter seriamente considerare uno switch. E il supporto software era inesistente.

Ed è la stessa cosa che sta succedendo a Raptor con i suoi computer basati su Power9. Interessanti, potenti, ma il mercato è difficile da smuovere.

Invece ci sono design fatti bene, come quelli di Fujitsu. E i risultati si vedono.


Non è necessario visto che esiste la GPU discreta.

Beh, se è per questo, non c'è nessun limite all'accoppiamento di GPU discrete con SoC ARM. Tanto il supporto al Pci-e ce l'hanno pure loro.

E non credo che Apple lascerà la sola GPU integrata nei Mac Pro.

Non ti piaccioni i benchmark sintetici. Non ti piacciono i test Web. Non ti piace la compilazione di codice software. Non ti piacciono test di compressione. Suppongo non ti piacciano neanche i test con app foto ( https://www.dday.it/redazione/37644/macbook-pro-2020-m1-photoshop-lightroom-affinity-photografia ). Final Cut (video editing), Logic Pro anche non ti andrebbero bene sicuramente (M1 vince easy).

Non è chiaro quindi cosa si debba usare per valutare questo processore.
Videogame non esistenti su MacOS e rendering con Blender non nativo forse? Sicuramente il campo di uso di un ultrabook come il MacbookAir... :sofico:

I test sintetici specie come Geekbench lasciano il tempo che trovano.
I test sul browser sono solitamente usati per le piattaforme ultra mobile, non sono di certo una tipologia di test usata valutare la performance di una workstation, semmai di un telefonino.

Note suite di rendering e video-editing vanno benissimo, peccato che quei confronti lascino fuori le GPU, unità su cui si appoggiano molti o tutte le applicazioni di quel tipo.

Questo tipo di applicazioni, così anche come le performance web e anche la compressione sono tutte tipologie di applicazioni che fan largo uso di calcoli float, dove l'archittura ARM è molto più efficiente delle FPU delle X86, visto che con la medesima architettura vengono realizzate anche molte delle loro GPU integrate.

Sicuramente il campo di uso di un ultrabook come il MacbookAir...Degli ultrabook non mi interessa nulla, se fai paragoni con le CPU desktop io parlo in tale ottica.

Vedremo quando usciranno i Mac Pro il confronto con una workstation X86, visto che lì non ci saranno più le batterie di mezzo, nè le limitazioni di una soluzione compatta.

il notebook con M1 ha ancora il 67% di batteria, mentre il macbook pro 16 Intel è morto. E le performance sono, nel caso peggiore, appena inferiori.Che le cpu X86 fossero inefficienti in soluzioni a basso consumo di certo non ci voleva M1 a chiarirlo.

Affermazione parecchio arrischiata. Un test WebGL non è indicativo della potenza della GPU? Un test coi webworkers non è indicativo delle capacità di multitasking della CPU?



Erano design chiaramente inadeguati. E sono stati fatti si e no 3-4 esperimenti del genere. Non c'è stato nemmeno il tempo e i volumi tali da poter seriamente considerare uno switch. E il supporto software era inesistente.

Ed è la stessa cosa che sta succedendo a Raptor con i suoi computer basati su Power9. Interessanti, potenti, ma il mercato è difficile da smuovere.

Invece ci sono design fatti bene, come quelli di Fujitsu. E i risultati si vedono.



Beh, se è per questo, non c'è nessun limite all'accoppiamento di GPU discrete con SoC ARM. Tanto il supporto al Pci-e ce l'hanno pure loro.

E non credo che Apple lascerà la sola GPU integrata nei Mac Pro.

Questo è sicuro... in soluzioni di fascia medio alta, dove l'autonomia non è un problema, ci saranno le GPU discrete ( molto probabilmente Apple ) con architettura di memoria UMA.

Si ma: che centrano le GPU quando si sta cercando di confrontare le prestazioni e l'efficienza delle CPU? :stordita:

I test sintetici specie come Geekbench lasciano il tempo che trovano.
I test sul browser sono solitamente usati per le piattaforme ultra mobile, non sono di certo una tipologia di test usata valutare la performance di una workstation, semmai di un telefonino.

Note suite di rendering e video-editing vanno benissimo, peccato che quei confronti lascino fuori le GPU, unità su cui si appoggiano molti o tutte le applicazioni di quel tipo.

Questo tipo di applicazioni, così anche come le performance web e anche la compressione sono tutte tipologie di applicazioni che fan largo uso di calcoli float, dove l'archittura ARM è molto più efficiente delle FPU delle X86, visto che con la medesima architettura vengono realizzate anche molte delle loro GPU integrate.M1 è un SoC per ultrabook da 15-20W. Cosa c'entrano le workstation o le GPU dedicate lo sai solo tu.

Quella dei floating point è solo una scusa.
E non è "l'architettura ARM", ma quella Apple al massimo. Il reference design di ARM ha meno della metà delle performance FP del M1 in SPEC:

https://images.anandtech.com/graphs/graph16252/111168.png


Degli ultrabook non mi interessa nulla, se fai paragoni con le CPU desktop io parlo in tale ottica. Ed un desktop High End dispone benissimo di una VGA per quel tipo di applicazioni che tanto pubblicizzano.

Vedremo quando usciranno i Mac Pro il confronto con una workstation X86.Qui si sta ragionando in termini di performance per core, performance per clock e performance per watt. In questi termini ha senso far confronti fra le varie architetture di CPU per valutare lo stato del mercato. Mai sentito l'espressione "moving the goalposts"?

Si ma: che centrano le GPU quando si sta cercando di confrontare le prestazioni e l'efficienza delle CPU? :stordita:Bella domanda. Ma siccome è innegabile il livello di performance di M1 in quegli ambiti, allora si usa la scusa "ah, ma quei calcoli possono essere accelerati dalla GPU". A me non risulta che web browsing, software compiling, ecc siano accelerati dalle GPU. Siamo arrivati al punto in cui neanche Cinebench(!) è più valido come benchmark.

Affermazione parecchio arrischiata. Un test WebGL non è indicativo della potenza della GPU? Un test coi webworkers non è indicativo delle capacità di multitasking della CPU?
Nelle reviews delle CPU non mi pare che nessuno corra a guardare i test sul browser, e forse nemmeno tutte le reviews le pubblicano.
Le GPU ? Per valutare una GPU lato desktop io uso i titoli AAA, poi te se le test col browser è una tua scelta.
Per valutare le capacità multitasking esistono scenari ben migliori di un browser, visto che quest'ultima non è di certo una tipologia di applicazione che viene vista come esosa o considerata particolarmente stressante, a patto di avere HW vecchio.


Erano design chiaramente inadeguati. E sono stati fatti si e no 3-4 esperimenti del genere. Non c'è stato nemmeno il tempo e i volumi tali da poter seriamente considerare uno switch. E il supporto software era inesistente.Per i volumi non sò ma per quel che riguarda l'IPC per clock era ridicoli, potevano competere con gli Xeon solo grazie al numero di cores e basta. Di fatto CPU ARM ad elevato TDP a pari cores con le soluzioni x86 non ne vedo. Anche quest'ultimo M1 è un piccolo chip da appena 10W.

Invece ci sono design fatti bene, come quelli di Fujitsu. E i risultati si vedono.Io non li vedo, le CPU di riferimento lato server continuano ad essere gli Xeon e ultimamente anche Epyc.

Beh, se è per questo, non c'è nessun limite all'accoppiamento di GPU discrete con SoC ARM. Tanto il supporto al Pci-e ce l'hanno pure loro. E non credo che Apple lascerà la sola GPU integrata nei Mac Pro.Il punto non era quello, una GPU discreta High End è sicuramente molto più performante lato float di qualsiasi ARM.

M1 è un SoC per ultrabook da 15-20W. Cosa c'entrano le workstation o le GPU dedicate lo sai solo tu.

Quella dei floating point è solo una scusa.
E non è "l'architettura ARM", ma quella Apple al massimo. Il reference design di ARM ha meno della metà delle performance FP del M1 in SPEC:

https://images.anandtech.com/graphs/graph16252/111168.png

SPEC 2006 ?
Ma ti rendi conto che ci sono i due chip dell'iPhone che eguagliano rispettivamente 5950X e 3950X ?
Quale razza di indicatività può avere un test del genere ?

Io ancora continuo a non vedere confronti su software significativi a parte i test mostrati su applicativi esclusivi Apple in confronto a specifici loro prodotti, probabilmente le apps saranno anche settate per ampliare al massimo il gap contro le soluzioni precedenti a scopo promozionale ( prodotti dotati di iGPU Intel e forse testati con l'accelerazione grafica disabilitata ).



Vedo solamente te che sei convinto che un chip da 10W possa essere più performance di uno da 120W e passa, il che è non è credibile.

Inoltre non si capisce mai il motivo per cui non si vedono soluzioni desktop / servers basati su ARM con TDP e numero di cores analoghi .... visto che con soli 10W asfalterebbero a tuo dire i Ryzen 9, figuriamoci cosa potrebbe fare con oltre TDP analoghi agli attuali processori desktop. Un altra domanda senza risposta da un decennio oramai

Siamo arrivati al punto in cui neanche Cinebench(!) è più valido come benchmark.
Ma non esageriamo :

https://i.ibb.co/k3fPpmL/Apple-M1-Cinebench-R23-Benchmarks.jpg

Io già da questo dato vedo che avvicina un modesto 4600U ( TDP 15W ) che ha solo 6 cores e basato su Zen2, nonostate il vantaggio di PP, quindi se performa relativamente meglio nelle suite esclusive Apple di sicuro ci saranno altri trucchi sotto.

Ma perché perdete tempo con Paul?
Quello non si convince perché non sono stati mostrati i test per editing video. E quelli che ci sono non gli piacciono.
Uno gli mostra che stanno facendo i super computer ARM e quello risponde che l'architettura di riferimento server è x86...
Cioé è uno confinato nel suo mondo DA SEMPRE, un integralista totale in tutti gli ambiti, dalle macchine ai videogiochi. A me disse che non valeva la pena giocare se non lo fai tutto al massimo e su un PC top.

Perché ci perdete tempo?

Questo è sicuro... in soluzioni di fascia medio alta, dove l'autonomia non è un problema, ci saranno le GPU discrete ( molto probabilmente Apple ) con architettura di memoria UMA.

Esistono già soluzioni con GPU "desktop" abbinate a processori ARM, la piattaforma NVIDIA Jetson è uno di questi sistemi. Il consumo della sola CPU è di 30W, a cui poi va sommato il consumo della GPU.

SPEC 2006 ?

Io ancora continuo a non vedere confronti su software significativi se non qualcuna in confronto a soluzioni con la sola GPU integrata Intel e forse con accelerazione GPU disabilitata nelle impostazioni delle applicazioni di test, per esaltare al meglio le unità dedicate di questo M1.

Vedo solamente te che sei convinto che un chip da 10W possa essere più performance di uno da 120W e passa, il che è non è credibile.
Ed infatti nessuno ha scritto o lasciato intendere qualcosa del genere. Come scritto molti post fa, anche un i9 9900k ha performance multicore superiori ad M1, ed anche di parecchio, su Cinebench R23, ed il motivo è semplice: ha molti più core e frequenze molto più alte.

Ma, ripeto per l'ennesima volta, se guardiamo a performance per watt, performance per clock e performance per core la situazione è ovvia: M1 è superiore persino a Zen 3 e Intel ne esce umiliata.

Inoltre non si capisce mai il motivo per cui non si vedono soluzioni desktop / servers basati su ARM con TDP e numero di cores analoghi .... visto che con soli 10W asfalterebbero a tuo dire i Ryzen 9, figuriamoci cosa potrebbe fare con oltre TDP analoghi agli attuali processori desktop. Un altra domanda senza rispostaIl motivo è molto semplice: questo non è un design ARM, ma un design Apple basato su ISA ARM. Presto vedrai SoC a 12, 16+ core Apple pensati per il resto della lineup, inclusi i desktop. Ciò che non vedrai invece saranno SoC Apple pensati per i server, dato che Apple non vende hardware a terzi.

Lascialo perdere... trolleggia da sempre così, negando pure l'evidenza dei fatti!!

Scommetto che non avrà persone nemmeno 5 minuti 5 per informarsi sull'architettura di M1 ( la quale non è solamente un CPU e GPU ) e sul perchè sia così efficiente e veloce per watt usato. Amen....

Ma perché perdete tempo con Paul?
Quello non si convince perché non sono stati mostrati i test per editing video. E quelli che ci sono non gli piacciono.
Uno gli mostra che stanno facendo i super computer ARM e quello risponde che l'architettura di riferimento server è x86...
Cioé è uno confinato nel suo mondo DA SEMPRE, un integralista totale in tutti gli ambiti, dalle macchine ai videogiochi. A me disse che non valeva la pena giocare se non lo fai tutto al massimo e su un PC top.

Perché ci perdete tempo?



Esistono già soluzioni con GPU "desktop" abbinate a processori ARM, la piattaforma NVIDIA Jetson è uno di questi sistemi. Il consumo della sola CPU è di 30W, a cui poi va sommato il consumo della GPU.

Si certo, bisogna vedere che soluzione adotterà Apple: una GPU discreta fatta in casa ( di cui al momento esistono solamente rumor ) oppure di AMD e se utilizzerà una architettura di memoria tradizionale oppure UMA.

Ed infatti nessuno ha scritto o lasciato intendere qualcosa del genere. Come scritto molti post fa, anche un i9 9900k ha performance multicore superiori ad M1, ed anche di parecchio, su Cinebench R23, ed il motivo è semplice: ha molti più core e frequenze molto più alte.

Ma, ripeto per l'ennesima volta, se guardiamo a performance per watt, performance per clock e performance per core la situazione è ovvia: M1 è superiore persino a Zen 3 e Intel ne esce umiliata.Se guardiamo la performance per watt in soluzioni a basso consumo la situazione era ovvia anche prima. Non mi risulta che gli X86 fossero dopo i primi anni mai stati competitivi sotto questo aspetto. Il problema è che se ora ARM entra nei desktop, il confronto andrà fatto con queste soluzioni, visto che il consumo lascerà il tempo che trova sui Mac Pro ( che non hanno una batteria da gestire ).


Il motivo è molto semplice: questo non è un design ARM, ma un design Apple basato su ISA ARM. Presto vedrai SoC a 12, 16+ core Apple pensati per il resto della lineup, inclusi i desktop. Ciò che non vedrai invece saranno SoC Apple pensati per i server, dato che Apple non vende hardware a terzi.16 core di cosa parliamo ? 20W anzichè 10 ?
Il punto del discorso è sempre quello, perchè non escono soluzioni con TDP e cores analoghi alle attuali proposte x86 ?

Si certo, bisogna vedere che soluzione adotterà Apple: una GPU discreta fatta in casa ( di cui al momento esistono solamente rumor ) oppure di AMD e se utilizzerà una architettura di memoria tradizionale oppure UMA.

Sono d'accordo. Sottolineavo solo che esistono giá queste soluzioni e non sono cose esotiche come si potrebbe pensare. :)

Se guardiamo la performance per watt in soluzioni a basso consumo la situazione era ovvia anche prima. Non mi risulta che gli X86 fossero dopo i primi anni mai stati competitivi sotto questo aspetto. Il problema è che se ora ARM entra nei desktop, il confronto andrà fatto con queste soluzioni, visto che il consumo lascerà il tempo che trova sui Mac Pro ( che non hanno una batteria da gestire ).

Era ovvio lato smartphone e IOT. Non era ovvio che ARM scalasse bene anche a livello notebook mantenendo assoluta eccellenza in termini Performance per watt senza rinunciare alle performance.

16 core di cosa parliamo ? 20W anzichè 10 ?
Il punto del discorso è sempre quello, perchè non escono soluzioni con TDP e cores analoghi alle attuali proposte x86 ?Circa 50W estrapolando un consumo di quasi 4W per "performance" core durante R23.
Un SoC simile 12+4 dovrebbe competere facilmente con un 5950X consumando circa la metà.
Se espandi il TDP a 100W+, un design con 24 core "firestorm" avrebbe performance di gran lunga superiori ad un 5950X, ad un consumo analogo.
Aumentare il numero di core non è un problema, mentre è molto più difficile prevedere l'efficienza dell'arch Apple aumentando la frequenza; ma non serve aumentare la frequenza dato che già a 3,2Ghz è ai livelli del top gamma AMD in single threaded performance.

Un SoC simile 12+4 dovrebbe competere facilmente con un 5950X consumando circa la metà.Che appunto è ai limiti dell'assurdo.

Che appunto è ai limiti dell'assurdo.Non c'è niente di assurdo, basta estrapolare le performance da M1. Senza toccare la frequenza lo scaling del consumo per core dovrebbe essere piuttosto lineare.

Non c'è niente di assurdo, basta estrapolare le performance da M1. Senza toccare la frequenza lo scaling del consumo per core dovrebbe essere piuttosto lineare.Dal Cinebench che tanto elogi la performance nonostante gli 8 core ( 4+4 poi ) è inferiore ad un 4600U che è una CPU da 15W di TDP e basata su Zen2 e il tutto sfruttando per altro godendo del vantaggio del 5nm.
Anche la performance in single thread è poco credibile.

Era ovvio lato smartphone e IOT. Non era ovvio che ARM scalasse bene anche a livello notebook mantenendo assoluta eccellenza in termini Performance per watt senza rinunciare alle performance.
Stiamo comunque prima di tutto parlando di valori di TDP bassi.
Inoltre se non sbaglio anche un precedente esperimento con un chip Samsung qualche anno fa su Windows per ARM in emulazione ha inizialmente fornito buone impressioni.

Lascialo perdere... trolleggia da sempre così, negando pure l'evidenza dei fatti!!

Scommetto che non avrà persone nemmeno 5 minuti 5 per informarsi sull'architettura di M1 ( la quale non è solamente un CPU e GPU ) e sul perchè sia così efficiente e veloce per watt usato. Amen....
Ecco è arrivato il fanboy.

Dal Cinebench che tanto elogi la performance nonostante gli 8 core ( 4+4 poi ) è inferiore ad un 4600U che è una CPU da 15W di TDP e basata su Zen2 e il tutto sfruttando per altro godendo del vantaggio del 5nm.

Stiamo comunque prima di tutto parlando di valori di TDP bassi.
Inoltre se non sbaglio anche un precedente esperimento con un chip Samsung qualche anno fa su Windows per ARM in emulazione ha inizialmente fornito buone impressioni.La linea mobile di AMD, anche con TDP da "15W", può facilmente arrivare a usarne 25-30W nei primi minuti.
Inoltre non direi proprio che "elogio" Cinebench, anzi, è un test piuttosto limitato basato su Cinema 4D che sembra favorire l'architettura AMD in generale.
è letteralmente uno dei "best case" per AMD in questi confronti, perché test come Geekbench e SPEC, che usano diversi tipi di workload molto più rappresentativi, sono molto più favorevoli per Apple.

La linea mobile di AMD, anche con TDP da "15W", può facilmente arrivare a usarne 25-30W nei primi minuti.
Inoltre non direi proprio che "elogio" Cinebench, anzi, è un test piuttosto limitato basato su Cinema 4D che sembra favorire l'architettura AMD in generale.
è letteralmente uno dei "best case" per AMD in questi confronti, perché test come Geekbench e SPEC, che usano diversi tipi di workload molto più rappresentativi, sono molto più favorevoli per Apple.
GeekBench è un minestrone di sotto bench che esamino aspetti che presi singolarmente non significano nulla, è un benchmark nato per i telefonini e che serve a mettere in risalto queste soluzioni in modo da non far sfigurare i prodotti mobile contro le soluzioni desktop.
Il suo valore è meno di zero.

SPEC2006 invece non lo conosco, ma un test dove ci sono modelli x86 mobile da 15 e 28W che battono i Ryzen 2700X 2 3950X desktop di sicuro non vale la pena perderci troppo tempo, forse ancora più ridicolo di Geek.

Roba obsoleta. Guardate qua:
https://www.eetimes.com/micro-magic-risc-v-core-claims-to-beat-apple-m1-and-arm-cortex-a9/

RISC-V core, 5GHx, consuma 200mW!!!! Cioe' 0.2W. 100 volte meno di M1.
E niente royalties, e' un Risc-V.

Non voglio sollevare un polverone ma RISC-V è decisamente acerbo per competere con x86, amd64 e ARM.

5GHz li hanno raggiunti solo perché il design del core è semplice e non ha nulla a che vedere con le prestazioni effettive. Appena ci aggiungi più cache, una pipeline più complessa con prefetching ecceterà vedi che la frequenza cala ed i consumi aumentano. Alla fisica non si scappa.

Sarà sicuramente più efficente ma di poco.

Che sono sempre una decina di watt in più rispetto alla versione più pompata di M1 ( quella montata su Mac Mini con dissipatore più grande e ventola ).
Inoltre qui in parecchi sembrano dimenticarsi il fatto che M1 è il SoC per i Mac di " fascia bassa " dove l'efficienza energetica ha la sua importanza ( unica eccezione è il Mac Mini ).
A breve ci saranno gli iMac e i MBP da 16" equipaggiati molto probabilmente con la prima evoluzione di M1 che dovrebbe garantire un ulteriore boost prestazionale.
Viste le premesse di M1, non immagino cosa potrà offrire un M1X o M2 con TDP compresi tra 35 e 45 Watt.

No.
Cosa ti manca nel capire il concetto in prospettiva.
R4600 ( che su quel note è settato a 35w e non 45w dato che con i ryzen è possibile farlo) usa zen2 ( e non zen3) quindi architettura vecchia.
Il PP è il solito 7 tsmc ( contro i 5 di apple).
Se ipotizzi la stessa cpu su zen3 e pp a 5nm senza nessun altra miglioria ti ritrovi a poter valutare una cpu a pari condizione.
Quindi non ci vedo affatto ( per il momento) questa grande differenza tra x86 e M1.
M1x o M2 con tdp doppio non avranno il doppio delle prestazioni e senza aumentare il numero dei core, ma agendo solo su cache e frequenza difficilmente avranno un +60% di prestazioni, mentre se aumentaranno i core parte del tdp sarà mangiato dalla cache.
Prendiamo a riferimento un'altro dato non di secondaria importanza:
Apple M1 16 miliardi di transistor
AMD 4900h ( che sarebbe la parte buone delle sfornate dalla quale viene scemato il 4600h che ne è uno scarto) 9.8 miliardi di transistor.
Io tutta questa superiorità di M1 rispetto a x86 non la vedo.
A gennaio/febbraio 2021 amd dovrebbe presentare 5900H prodotto a 5nm quindi tra meno di 3 mesi vedremo le prestazioni relative a pari TDP tra le due architetture.
Ma gia so che tra M1 e Apu Zen3 non ci saranno significative differenze sia nel rapporto efficienza sia nel rapporto Gf Watt.
Con il secondo però in vantaggio su tutto il software circolante e le varie ottimizzazioni specifiche che le software house possono ( ma anche no data la retrocompatibilità totale) rilasciare.
Ps il fatto che Arm ad oggi non porta vantaggi significativi sui chip ad alte prestazioni ( e tdp) lo dice AMD stessa ed M1 con i suoi 15/18w è un chip ad alte prestazioni.
Poi possiamo parlare quanto vogliamo, ma M1 è una generazione avanti alle attuali cpu x86, ma tra tre mesi non lo sarà più ( anzi affronterà una generazione di cpux86 che sarà a cavallo tra il vecchio ed il nuovo e quindi con ancora ampi margini di manovra.

PPs non dico che M1 faccia schifo, ma in molti presi dall'entusiasmo lo osannano come il sacro graal quando invece non lo è.

No.
Cosa ti manca nel capire il concetto in prospettiva.
R4600 ( che su quel note è settato a 35w e non 45w dato che con i ryzen è possibile farlo) usa zen2 ( e non zen3) quindi architettura vecchia.
Il PP è il solito 7 tsmc ( contro i 5 di apple).
Se ipotizzi la stessa cpu su zen3 e pp a 5nm senza nessun altra miglioria ti ritrovi a poter valutare una cpu a pari condizione.
Quindi non ci vedo affatto ( per il momento) questa grande differenza tra x86 e M1.
M1x o M2 con tdp doppio non avranno il doppio delle prestazioni e senza aumentare il numero dei core, ma agendo solo su cache e frequenza difficilmente avranno un +60% di prestazioni, mentre se aumentaranno i core parte del tdp sarà mangiato dalla cache.
Prendiamo a riferimento un'altro dato non di secondaria importanza:
Apple M1 16 miliardi di transistor
AMD 4900h ( che sarebbe la parte buone delle sfornate dalla quale viene scemato il 4600h che ne è uno scarto) 9.8 miliardi di transistor.
Io tutta questa superiorità di M1 rispetto a x86 non la vedo.
A gennaio/febbraio 2021 amd dovrebbe presentare 5900H prodotto a 5nm quindi tra meno di 3 mesi vedremo le prestazioni relative a pari TDP tra le due architetture.
Ma gia so che tra M1 e Apu Zen3 non ci saranno significative differenze sia nel rapporto efficienza sia nel rapporto Gf Watt.
Con il secondo però in vantaggio su tutto il software circolante e le varie ottimizzazioni specifiche che le software house possono ( ma anche no data la retrocompatibilità totale) rilasciare.
Ps il fatto che Arm ad oggi non porta vantaggi significativi sui chip ad alte prestazioni ( e tdp) lo dice AMD stessa ed M1 con i suoi 15/18w è un chip ad alte prestazioni.
Poi possiamo parlare quanto vogliamo, ma M1 è una generazione avanti alle attuali cpu x86, ma tra tre mesi non lo sarà più ( anzi affronterà una generazione di cpux86 che sarà a cavallo tra il vecchio ed il nuovo e quindi con ancora ampi margini di manovra.

PPs non dico che M1 faccia schifo, ma in molti presi dall'entusiasmo lo osannano come il sacro graal quando invece non lo è.Giusto per informazione, ma Cezanne (Zen 3 mobile) non è a 5nm. AMD non userà i 5nm prima del 2022 come minimo sulla linea notebook. Nel 2022 Apple si sposterà ai 3nm quindi difficilmente ci sarà parità fra processi produttivi nel prossimo futuro.
Cezanne pare essere molto promettente: sembra offrire un +40% di performance vs Zen 2, ma è comunque prematuro fare confronti.

Il vantaggio potenziale di Apple è che usa un ciclo di 12 mesi basato su iPhone. Ogni anno nuovo SoC con minimo +20% lato CPU vs generazione precedente. Della serie, se i notebook AMD Zen 3 arrivano sul mercato nel Q1 2021, Apple a settembre ha già a disposizione i nuovi Core basati sull'A15 (per intenderci, A14 è +25% lato CPU pur consumando meno vs A13).
AMD rimarrà con Zen 3 a 7nm (potenzialmente "6") fino a metà 2022.

https://cdn.videocardz.com/1/2020/09/AMD-Rembrand-6nm-Navi2-2020-APU.jpg

Il vantaggio potenziale di Apple è che usa un ciclo di 12 mesi basato su iPhone. Ogni anno nuovo SoC con minimo +20% lato CPU vs generazione precedente. Della serie, se i notebook AMD Zen 3 arrivano sul mercato nel Q1 2021, Apple a settembre ha già a disposizione i nuovi Core basati sull'A15 (per intenderci, A14 è +25% lato CPU pur consumando meno vs A13).
AMD rimarrà con Zen 3 a 7nm (potenzialmente "6") fino a metà 2022.

Grazie della correzione, ma i dati dicono che:

1)
M1 non è quel super chip che in troppi paragonano come il killer di x86

2) stiamo paragonando chip con numero di transistor uno il doppio dell'altro

3) in un chip ad alte prestazioni fondamentale è il processo produttivo e qua ci ritroviamo con un 5 vs 7 nm della stessa fonderia quindi direttamente confrontabili.

L'allert è per chiunque si sta facendo prendere da facili entusiasmi e decreta la morte di x86 a favore di ARM.
Gente che ancora non hanno capito ( e credo che ormai non lo faranno mai) che le diverse ISA ormai lo sono solo esternamente, ma le unità di calcole, i paradigmi e le accelerazioni in hardware ormai sono quasi delle copie.
Per esempio l'unico vero punto di forza di RISC-V è la sua natura Open che rende disponibile a tutti la possibilità di creare cpu con tale ISA senza dover acquisire licenze o altro.
Ma è il suo grande punto debole nel medesimo istante: nessuna grande realtà si impegnerà ad investire su quell'isa per vedersi poi superato da un concorrente che trova gia il mercato creato.
Gli unici che possono ( e dovrebbero investirci) sono gli stati, prima tra tutti Europa, Cina, Russia che si svincolerebbero dalle possibili pressioni del governo USA. Ma questa è una questione politica e non commerciale.

Ps: anche AMD usa un ciclo di 12 mesi per le sue architetture, considerando poi che contemporaneamente sviluppa x86, gpu, arm, il suo ciclo lo si può considerare anche più stringente

Giusto per informazione, ma Cezanne (Zen 3 mobile) non è a 5nm. AMD non userà i 5nm prima del 2022 Il fatto che le APU AMD rimarranno sul 7nm è perchè la politica AMD prevede che questi prodotti a loro meno remunerativi vengano giustamente realizzati con microarchitettura e linea produttiva precedente per abbatterne i costi di produzione.

E allo stesso tempo il fatto che Apple goda dei 5nm, non significa che debba necessariamente essere così sempre.
AMD al momento è leader nelle performance con margine e non ha una reale concorrenza sotto questo punto di vista, non vedo quindi motivo per cui AMD non possa soffiare i PP migliori che offre TSMC nel caso Intel si rifacesse viva.

Inoltre ci sarebbe anche da dire che il 7nm usati per le APU 4000 non è lo stesso di quello usati per Zen3, quindi il vantaggio di Apple lato PP è consistente, lasciando da parte tutto ciò che riguarda la sua microarchitettura.

Il fatto che le APU AMD rimarranno sul 7nm è perchè la politica AMD prevede che questi prodotti a loro meno remunerativi vengano giustamente realizzati con microarchitettura e linea produttiva precedente per abbatterne i costi di produzione.

E allo stesso tempo il fatto che Apple goda dei 5nm, non significa che debba necessariamente essere così sempre.
AMD al momento è leader nelle performance con margine e non ha una reale concorrenza sotto questo punto di vista, non vedo quindi motivo per cui AMD non possa soffiare i PP migliori che offre TSMC nel caso Intel si rifacesse viva.

Inoltre ci sarebbe anche da dire che il 7nm usati per le APU 4000 non è lo stesso di quello usati per Zen3, quindi il vantaggio di Apple lato PP è consistente, lasciando da parte tutto ciò che riguarda la sua microarchitettura.Certo, è una questione di costi(e di die size e frequenze).
Apple è il più grosso cliente di TSMC ed è sempre la prima a passare al nuovo nodo, che guarda caso arriva sempre in produzione di massa in tempo per l'iphone. Apple è stata prima a usare i 16nm FinFET, la prima a usare i 10nm, i 7nm e ora i 5. E sarà la prima ad usare i 3nm, con AMD e NVDA a 2/3 anni di distacco.

C'è competizione per i wafer di TSMC. Chi ha l'assegno più grosso e i numeri più grandi è in prima linea.
Spoiler alert: non AMD.
https://www.extremetech.com/computing/315186-apple-books-tsmcs-entire-5nm-production-capability


Grazie della correzione, ma i dati dicono che:

1)
M1 non è quel super chip che in troppi paragonano come il killer di x86

2) stiamo paragonando chip con numero di transistor uno il doppio dell'altro

3) in un chip ad alte prestazioni fondamentale è il processo produttivo e qua ci ritroviamo con un 5 vs 7 nm della stessa fonderia quindi direttamente confrontabili.

L'allert è per chiunque si sta facendo prendere da facili entusiasmi e decreta la morte di x86 a favore di ARM.
Gente che ancora non hanno capito ( e credo che ormai non lo faranno mai) che le diverse ISA ormai lo sono solo esternamente, ma le unità di calcole, i paradigmi e le accelerazioni in hardware ormai sono quasi delle copie.
Per esempio l'unico vero punto di forza di RISC-V è la sua natura Open che rende disponibile a tutti la possibilità di creare cpu con tale ISA senza dover acquisire licenze o altro.
Ma è il suo grande punto debole nel medesimo istante: nessuna grande realtà si impegnerà ad investire su quell'isa per vedersi poi superato da un concorrente che trova gia il mercato creato.
Gli unici che possono ( e dovrebbero investirci) sono gli stati, prima tra tutti Europa, Cina, Russia che si svincolerebbero dalle possibili pressioni del governo USA. Ma questa è una questione politica e non commerciale.

Ps: anche AMD usa un ciclo di 12 mesi per le sue architetture, considerando poi che contemporaneamente sviluppa x86, gpu, arm, il suo ciclo lo si può considerare anche più stringenteIl numero di transistor è irrilevante. Non ha senso confrontare un SoC con blocchi hardware dedicati, come NPU e ISP con una CPU che ne è sprovvista.
Inoltre AMD non usa un ciclo di 12 mesi:

Zen 1: Febbraio 2017
Zen 1+: Aprile 2018
Zen 2: Luglio 2019
Zen 3: Novembre 2020
Zen 4: Q1-Q3 2022?

Ci sono più di 12 mesi per ognuno di questi upgrade.

C'è competizione per i wafer di TSMC. Chi ha l'assegno più grosso e i numeri più grandi è in prima linea.

Solo in linea di massima, ma non è un asta.
E non è nemmeno detto che in futuro il TSMC rimanga il migliore PP.

Certo, è una questione di costi(e di die size).
E' una questione semmai di costi e basta.
Perchè il die size di sicuro sarà sempre più piccolo col nodo più avanzato.

Solo in linea di massima, ma non è un asta.
E non è nemmeno detto che in futuro il TSMC rimanga il migliore PP.


E' una questione semmai di costi e basta.
Perchè il die size di sicuro sarà sempre più piccolo col nodo più avanzato.Se hai un die size elevato non vuoi certamente essere fra i primi ad adottare un nuovo nodo, dal momento che gli yield sono al livello più basso e di conseguenza avrai molto prodotti di scarto.
Nvidia, ad esempio, non vuole certamente essere la prima su un nuovo nodo di TSMC con die size da 800mm^2 che è al limite reticolare per TSMC. Un minimo difetto e bisogna buttare via tutto, con costi assurdi.
Quindi si, il die size è un aspetto molto importante in considerazione dello yield.

Se hai un die size elevato non vuoi certamente essere fra i primi ad adottare un nuovo nodo, dal momento che gli yield sono al livello più basso e di conseguenza avrai molto prodotti di scarto.
Nvidia, ad esempio, non vuole certamente essere la prima su un nuovo nodo di TSMC con die size da 800mm^2 che è al limite reticolare per TSMC. Un minimo difetto e bisogna buttare via tutto, con costi assurdi.
Quindi si, il die size è un aspetto molto importante in considerazione dello yield.
Con le soluzioni High End forse no, ma volendo competere con le soluzioni mobile un attuale APU 4600U con il primo nodo da 7nm occupa poco più di questo M1. Anche le APU desktop Renoir non sono molto grandi, forse il modello 4600G addirittura sotto i 200mmq ( e sottolineo di nuovo che parliamo di 7nm ).

Ecco è arrivato il fanboy.

Da quale pulpito..... :rolleyes:

Ciò non cambia però il fatto che il confronto contro gli x86 sul Cinebench non sia direttamente indicativo nel confronto con un X86. Escludendo il lato Float dove in ambienti X86 sarà comunque possibile usare la GPU discreta, in tutto il resto è da verificare sul lato pratico, dove appunto non c'è ancora nessun risultato.

Stai scherzando ? Considerando che ha quasi il doppio dei registri interi visibili al programmatore/compilatore (cosa molto buona per dare in pasto al decoder molte più istruzioni senza interdipendenze troppo vicine tra loro), quante istruzioni Aarch64 vengono decodificate per ciclo, quante pipeline per gli interi ha e come sono grandi i buffer di riordino, sul lato delle prestazioni con gli interi mi sa che proprio non ha problemi.

Persino il mantra "ma le istruzioni x86 fanno più cose e sono più compatte" non regge; Aarch64 ha istruzioni "semplici" che fanno molto più lavoro delle corrispondenti istruzioni "semplici" per x86-64.

Ad esempio queste sono le "MOV condizionali":

CCMN rn, #i5, #f4, cc if(cc) rn + i; else N:Z:C:V = f
CCMN rn, rm, #f4, cc if(cc) rn + rm; else N:Z:C:V = f
CCMP rn, #i5, #f4, cc if(cc) rn − i; else N:Z:C:V = f
CCMP rn, rm, #f4, cc if(cc) rn − rm; else N:Z:C:V = f
CINC rd, rn, cc if(cc) rd = rn + 1; else rd = rn
CINV rd, rn, cc if(cc) rd = ∼rn; else rd = rn
CNEG rd, rn, cc if(cc) rd = −rn; else rd = rn
CSEL rd, rn, rm, cc if(cc) rd = rn; else rd = rm
CSET rd, cc if(cc) rd = 1; else rd = 0
CSETM rd, cc if(cc) rd = ∼0; else rd = 0
CSINC rd, rn, rm, cc if(cc) rd = rn; else rd = rm + 1
CSINV rd, rn, rm, cc if(cc) rd = rn; else rd = ∼rm
CSNEG rd, rn, rm, cc if(cc) rd = rn; else rd = −rm


Sono praticamente degli if .. then .. else .. endif eseguiti in un singolo ciclo senza bisogno di branch prediction e che corrispondono a casi d'uso molto frequenti.

Un altro esempio sono le operazioni di and/or/xor in cui il secondo operando può essere opzionalmente invertito logicamente e/o shiftato o ruotato a piacere, sempre in un solo ciclo e pure queste molto utili per eseguire indirizzamento con modulo, usare maschere di selezione e calcolare indirizzi in modi molto più flessibili delle LEA di x86-64.

Ed ovviamente ci sono le operazioni aritmetiche a 3 operandi che su x86-64 corrispondono ad una mov seguita dall'operazione stessa (due istruzioni x86-64 per fare quello che richiede una singola istruzioni su Aarch64).

Insomma, mi sa che si difende bene anche con gli interi a parità di TDP o anche con x86-64 che girano con un TDP un poco più alto.

No.
Cosa ti manca nel capire il concetto in prospettiva.
R4600 ( che su quel note è settato a 35w e non 45w dato che con i ryzen è possibile farlo) usa zen2 ( e non zen3) quindi architettura vecchia.
Il PP è il solito 7 tsmc ( contro i 5 di apple).
Se ipotizzi la stessa cpu su zen3 e pp a 5nm senza nessun altra miglioria ti ritrovi a poter valutare una cpu a pari condizione.
Quindi non ci vedo affatto ( per il momento) questa grande differenza tra x86 e M1.
M1x o M2 con tdp doppio non avranno il doppio delle prestazioni e senza aumentare il numero dei core, ma agendo solo su cache e frequenza difficilmente avranno un +60% di prestazioni, mentre se aumentaranno i core parte del tdp sarà mangiato dalla cache.
Prendiamo a riferimento un'altro dato non di secondaria importanza:
Apple M1 16 miliardi di transistor
AMD 4900h ( che sarebbe la parte buone delle sfornate dalla quale viene scemato il 4600h che ne è uno scarto) 9.8 miliardi di transistor.
Io tutta questa superiorità di M1 rispetto a x86 non la vedo.
A gennaio/febbraio 2021 amd dovrebbe presentare 5900H prodotto a 5nm quindi tra meno di 3 mesi vedremo le prestazioni relative a pari TDP tra le due architetture.
Ma gia so che tra M1 e Apu Zen3 non ci saranno significative differenze sia nel rapporto efficienza sia nel rapporto Gf Watt.
Con il secondo però in vantaggio su tutto il software circolante e le varie ottimizzazioni specifiche che le software house possono ( ma anche no data la retrocompatibilità totale) rilasciare.
Ps il fatto che Arm ad oggi non porta vantaggi significativi sui chip ad alte prestazioni ( e tdp) lo dice AMD stessa ed M1 con i suoi 15/18w è un chip ad alte prestazioni.
Poi possiamo parlare quanto vogliamo, ma M1 è una generazione avanti alle attuali cpu x86, ma tra tre mesi non lo sarà più ( anzi affronterà una generazione di cpux86 che sarà a cavallo tra il vecchio ed il nuovo e quindi con ancora ampi margini di manovra.

PPs non dico che M1 faccia schifo, ma in molti presi dall'entusiasmo lo osannano come il sacro graal quando invece non lo è.

Ma quale sacro Graal.... M1 è un SoC ( a proposito nei 16 MLD di transistor cosa ci hai messo? ) che nel rapporto performance/consumi non ha rivali ( al momento ) ed è anche più efficiente in determinati compiti.
La componente CPU, disegnata da Apple come un 4+4 per una ben specifica serie di Mac e che non sfigura minimamente con altre ben più potenti sulla carta, in condizioni reali di utilizzo sarà sempre coadiuvata dagli acceleratori incorporati nel SoC e dalla configurazione UMA della memoria.
Il " segreto ", il " magico " è in quanto scritto sopra.
Che piaccia o meno M1 non è una mera CPU ma un SoC che permette di accedere contemporaneamente all'OS e App a tutte le sue componenti e alla memoria.
Disquisire solamente della componente CPU è abbastanza relativo nonché fuorviante.

Ma quale sacro Graal.... M1 è un SoC ( a proposito nei 16 MLD di transistor cosa ci hai messo? ) che nel rapporto performance/consumi non ha rivali ( al momento ) ed è anche più efficiente in determinati compiti.
La componente CPU, disegnata da Apple come un 4+4 per una ben specifica serie di Mac e che non sfigura minimamente con altre ben più potenti sulla carta, in condizioni reali di utilizzo sarà sempre coadiuvata dagli acceleratori incorporati nel SoC e dalla configurazione UMA della memoria.
Il " segreto ", il " magico " è in quanto scritto sopra.
Che piaccia o meno M1 non è una mera CPU ma un SoC che permette di accedere contemporaneamente all'OS e App a tutte le sue componenti e alla memoria.
Disquisire solamente della componente CPU è abbastanza relativo nonché fuorviante.

Ma guarda che anche il 4900h è un soc se non te ne sei reso conto.
é un chip monolitico come M1 ( in 10 miliardi di transistor scarsi)
La parte dei core non l'ho nemmeno considerata.
Comunque per correttezza:

https://cdn.wccftech.com/wp-content/uploads/2020/03/AMD-Ryzen-4000H-CPU-Block-Diagram.jpg

Considerando poi che quello è il diagramma home mancano le funzioni ecc del controller ( presenti ma disabilitati) e qualche altra cosuccia.

Ma guarda che anche il 4900h è un soc se non te ne sei reso conto.
é un chip monolitico come M1 ( in 10 miliardi di transistor scarsi)
La parte dei core non l'ho nemmeno considerata.
Comunque per correttezza:



Considerando poi che quello è il diagramma home mancano le funzioni ecc del controller ( presenti ma disabilitati) e qualche altra cosuccia.

Ciò non toglie il fatto che in questo thread si continui a parlare di prestazioni dei core CPU invece di tutto l'insieme.
Detto ciò sono contento che anche AMD stia producendo delle APU e CPU con architettura efficiente facendo concorrenza ( assieme ad Apple ) ad una Intel dormiente o menefreghista.
Apple rimane comunque con un vantaggio temporale e di nodo considerevole: l'architettura di M1 è stata impostata circa 4 anni fa parallelamente a quella dei SoC A11. Ciò significa che già nel corso del 2021 sarà disponibile M2 magari basato sui 3nm di TSMC.

2021 Apple userà N5+ / N5P o come TSMC deciderà di chiamare la loro seconda generazione dei 5nm.
3nm sono per il 2022.

La cosa interessante da osservare è la traiettoria di Intel e Apple:

https://images.anandtech.com/doci/16226/perf-trajectory_575px.png

AMD si è mantenuta su una traiettoria parallela ad Apple con l'upgrade a Zen 2 e Zen 3.
In generale è piuttosto evidente perché Apple ha deciso di passare ai suoi SoC questa generazione.

Detto ciò sono contento che anche AMD stia producendo delle APU e CPU con architettura efficiente facendo concorrenza ( assieme ad Apple ) ad una Intel dormiente o menefreghista.

esatto

meno male che c'è concorrenza e sono finiti i tempi in cui per avere più di 4 core intel ti vendeva la cpu a peso d'oro come se fosse una cosa estrema.

Ciò non toglie il fatto che in questo thread si continui a parlare di prestazioni dei core CPU invece di tutto l'insieme.

Veramente IO ho sempre parlato di performance cpu ( ed apple si è tenuta ben lontano dal paragonare sia i suoi core che la sua gpu da quelli di AMD perchè per la parte cpu l'efficienza non sarebbe stata così evidente, lato gpu invece sarebbe stata dietro, con o senza UMA).
Il riferimento al numero di transistor è talmente chiaro che solo chi non vuole vedere lo fa:
Ho semplicemente detto che l'apu AMD in 35w si difende bene contro M1 e che in prospettiva un ipotetico soc X86 AMD con 16 miliardi di transistor e pp a 5nm sarebbe perfettamente comparabile all'M1 sia come efficienza che potenza bruta.
Questo non per dire che Apple ha fatto un pessimo lavoro, ma per rimarcare che per chip ad alte prestazioni la differenza tra Cisc e Risc è trascurabile sia sul lato efficienza che prestazioni e che ARM ancora non è pronta a sostituire x86 nei suoi campi di utilizzo.
Apple ( come Fujitsu) hanno usato arm perchè ne hanno le licenze e si fanno tutto in casa, ma difficilmente avrebbero adottato un soc ARM senza averne il controllo sulle specifiche e le prestazioni relative.
Questa è normale mercato: perchè pagare ad un terzo soggetto le cpu ( o soc) se ne hai di performanti ( perchè te le sei cucite per le tue esigenze) in casa?

Insomma, mi sa che si difende bene anche con gli interi a parità di TDP o anche con x86-64 che girano con un TDP un poco più alto.
Che puoi formulare anche in modo invertito:
x86 si difende bene vs ARM su chip ad alte prestazioni con un TDP di poco più alto ( a parità di tutto il resto)

;47138708']Inoltre ricordo che MacOS 9 girava meglio su Amiga 4000 con Shapeshifter che su Quadra 900.....
(Si Amiga aveva il 68040 / 25Mhz ....e su 68060/50Mhz tutti i MAC erano lumache)
Stessa qualità d'articolo.
Ricordi male, come ti hanno già detto. Poi i Mac avevano vantaggi a livello di grafica, visto che potevano contare su schede grafiche avanzate a 15/16/24/32 bit (nonché audio a 16 bit e 44Khz e superiori), mentre il 4000 purtroppo si portava ancora dietro quel ridicolo chipset che era l'AGA (un'orribile pezza sul preistorico ECS).
Ad onor del vero si tratta di due approcci differenti.
In quegli anni del boom dei personal computer diversi produttori facevano scelte molto diverse nei loro prodotti perchè era ancora poco chiaro quale fosse la giusta direzione.
Così metre i primi PC si basavano su processori X86 a 16 bit piuttosto limitati Apple optò per i Motorola già realizzati a quel tempo a 32 bit.
Una scelta molto valida visto che i primi MAC potevano fare cose che per i limitati processori X86 erano inarrivabili.
Vero. I Motorola 68000 erano stupendi processori, che ancora oggi adoro.

Ma c'è da dire che nell'84, anno di introduzione dei Mac, c'erano già PC che montavano processori 80286 e che avevano prestazioni mediamente migliori (pur essendo un processore a 16 bit), ma soprattutto la modalità protetta che ha consentito a Intel di superare la certificazione militare per questo processore.
Le cose poi cambiarono nel giro di qualche anno ed il gap iniziale si ando a ridurre velocemente per poi essere completamente superato, tanto è vero che alla fine Apple staeesa dovette mollare Motorola che non era in grado di competere e dovette passare anche lei ad Intel.
Avrebbe dovuto passarci già da parecchio prima: nel 2000. Ma il passaggio fu soltanto rinviato di qualche anno, causa promessa del G5 a Jobs da parte di IBM.
;47139471']E' passato qualche anno sai....e non uso MAC, magari non sarà OS9 ma OS8 (680x0), e si solo Amiga, qualche F16 e qualche Ecografo hanno ricevuto lo 68060 ed era inteso per quello che i Mac 68040 erano lumache (no che con il 060 lo fossero) il confronto,
Continui a ricordare male, e non so come tu faccia a dire che fossero lumache. I Mac usando le schede grafiche in dotazione potevano manipolare la grafica di gran lunga più velocemente rispetto agli Amiga, che erano ancora fermi al chipset AGA che funzionava ancora in modalità planare (bitplane).
Beh no. Ci sono svariati test su Phoronix ( e molti non sono sintetici ) e ci sono i bench su Google Chrome.
Phoronix ha per lo più test sintetici, e i benchmark su Chrome possono usare la GPU, per cui meglio lasciarli perdere.
Ma del resto era ovvio. Lo dico da anni che l'utilizzo mirato di acceleratori hardware, produce risultati fantastici. Amiga dovrebbe averci insegnato qualcosa a riguardo.
Il problema è programmarli / usarli...
Alla fin fine, la customizzazione del mondo ARM giocherà a loro favore. Intel ( e AMD ) ha sempre voluto vendere monoblocchi, con dentro solo quello che secondo il loro, insindacabile parere, è importante. E ti ritrovi con Torvalds che giustamente spara a zero sulle AVX-512 che saranno usate, si e no, da 1000 persone su tutto il pianeta. Ma l'obolo lo paghiamo tutti.
Primo Torvalds ha detto una colossale sciocchezza, che poi infatti ha ritrattato malamente dopo le sberle che gli sono arrivate. Forse sarà rimasto fermo all'80386 da cui è partito...

Secondo, le AVX-512 sono usate e lo saranno sempre di più, perché sono delle ottime estensioni SIMD, che hanno fatto scuola.

Terzo, l'obolo lo paghi solo se compri CPU di cui ne sono dotate. Ma poi ne sfrutti anche i vantaggi. Come sempre.
Stai scrivendo delle sciocchezze.

M1 ha performance eccellenti in Geekbench, R23 e SPEC, sia nella versione 2006 che 2017.
Eccelle anche nel compiling software (ben poco sintetico direi):
https://www.imore.com/sites/imore.com/files/styles/larger/public/field/image/2020/11/dave2d-xcode-build-times-m1-mba.jpeg
Nei benchmark web asfalta la concorrenza, anche usando lo stesso software.
Persino nella compressione ha performance eccellenti: https://cdn.arstechnica.net/wp-content/uploads/2020/11/Apple-M1-Mac-Mini.pigz-p1-1-1440x1080.png

Vorrei poi vedere un link che mostri che Cinebench usa la GPU nella sua versione ARM.
E poi... riuscire a perdere rispetto a cosa? :asd:
Geekbench lascialo perdere che è un benchmark sintetico che fa pena.

I test web potrebbero usare anche la CPU, come già detto, per cui meglio lasciar perdere pure loro.

Per building e compressione si dovrebbe vedere la dotazione hardware (HD/SSD/M.2) usata: se non è esattamente la stessa il test non è molto affidabile, perché non stai testando soltanto la CPU.

Infine SPEC e Cinebench, invece, vanno bene. In questi è innegabile che l'M1 mostri ottime prestazioni. Considerata la varietà di test effettuati da SPEC, e che si tratti de LA test suite per eccellenza, direi che l'M1 è vero mostro. Secondo soltanto a Zen3, ma di poco.
Hai ragione, devo aver fatto confusione, fa uso di un unità float più efficiente rispetto alle FPU degli x86 :

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2

On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors. Floating-point operations throughput here is 1:1 with the pipeline count, meaning Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles).


Motivo però per cui registra valori alti in tutti gli ambiti che fanno ampio uso di calcoli in virgola mobile, come tutti quelli da te elencati.
Questo è davvero molto strano, perché da Zen2 ha 4 unità SIMD a 256 bit che possono eseguire 2 FADD a 256 bit e 2 istruzioni FMUL o FMA a 256 bit. Quindi sarebbe più o meno il doppio di FADD, o lo stesso numero di FMUL, entrambe con latenza di 3 cicli (quindi pure meglio di M1).

Non so da dove esca fuori questo valore quadruplo per l'M1.
Ciò non cambia però il fatto che il confronto contro gli x86 sul Cinebench non sia direttamente indicativo nel confronto con un X86.
Un solo benchmark non sarebbe in ogni caso indicativo. Specialmente uno come Cinebench, che è molto più orientato sui FP e la banda di memoria.
Escludendo il lato Float dove in ambienti X86 sarà comunque possibile usare la GPU discreta,
Questo non c'entra: stiamo parlando della sola CPU.
in tutto il resto è da verificare sul lato pratico, dove appunto non c'è ancora nessun risultato.
I due benchmark SPEC sono più che sufficienti.
Se la poniamo in questi termini di "INDICATIVO" non c'è niente.
Di solito per vedere quanto va una CPU gli si fa macinare calcoli in virgola mobile che sono quelli più pesanti.
Se viaggia bene su quelli va da se che se la cava bene anche in tutti gli altri scenari pratici di vita reale.
Assolutamente no. Anzi, è l'esatto contrario: i calcoli in virgola mobile sono tutt'altro che indicativi per le prestazioni complessive/generali, visto che sono i meno usati in generale.

Lo sono di più le istruzioni "intere"/"scalari", che peraltro sono quelle che soffrono di gran lunga di più a causa dei salti (soprattutto quelli condizionali), mentre il codice FP è più "lineare" (ci sono molti meno salti).
Suppongo non ti piacciano neanche i test con app foto ( https://www.dday.it/redazione/37644/macbook-pro-2020-m1-photoshop-lightroom-affinity-photografia ). Final Cut (video editing), Logic Pro anche non ti andrebbero bene sicuramente (M1 vince easy).
No, perché non stiamo confrontando esclusivamente e puramente (i core del)la CPU. SE è questo l'obiettivo dei confronti, ovviamente.
Dovresti dare una occhiata a video "reali" ( https://www.youtube.com/watch?v=_MUTS7xvKhQ&t=1530s ). Dopo ore di bench sintetici, Lightroom, Logic Pro ed editing video, xCode, R5 10Bit, il notebook con M1 ha ancora il 67% di batteria, mentre il macbook pro 16 Intel è morto. E le performance sono, nel caso peggiore, appena inferiori.
Quel video è assolutamente imbarazzante per intel. 60-90W. 100°, batteria che dura meno di 1/3 e ventola al 100% vs 30W, 60-70° e ventola quasi inesistente.
Come già detto, bisogna vedere cosa vorresti confrontare. Mi pare che tu sia orientato a non confrontare la sola CPU, ma l'intero ecosistema Apple con quelli di altri produttori di hardware.
Ed è la stessa cosa che sta succedendo a Raptor con i suoi computer basati su Power9. Interessanti, potenti, ma il mercato è difficile da smuovere.
Potenti dove? Ma quali benchmark hai visto? Eppure Phoronix lo conosci e lo frequenti...
Ma, ripeto per l'ennesima volta, se guardiamo a performance per watt, performance per clock e performance per core la situazione è ovvia: M1 è superiore persino a Zen 3 e Intel ne esce umiliata.
Quindi non stai confrontando le CPU ma l'ecosistema.

Inoltre l'M1 è un SoC ridotto all'osso: non ha nemmeno un controller della memoria normale, visto che i chip di memoria sono direttamente saldati sul package.

Ovvio che con tutte queste accortezze, a cui si aggiunge il processo produttivo, i consumi siano molto bassi.

Le prestazioni sono molto elevate, ma anche qui perché i core hanno una MONTAGNA di risorse a disposizione rispetto a quanto offerto da Intel o AMD.
Non c'è niente di assurdo, basta estrapolare le performance da M1. Senza toccare la frequenza lo scaling del consumo per core dovrebbe essere piuttosto lineare.
Assolutamente no. Più si sale in frequenza, più i consumi aumentano e possono esplodere, bloccando le frequenze. Chiedi ad AMD e ai suoi Ryzen...
Stai scherzando ? Considerando che ha quasi il doppio dei registri interi visibili al programmatore/compilatore (cosa molto buona per dare in pasto al decoder molte più istruzioni senza interdipendenze troppo vicine tra loro), quante istruzioni Aarch64 vengono decodificate per ciclo,
Su queste cose ti ho già risposto in un altro thread. ;)
quante pipeline per gli interi ha e come sono grandi i buffer di riordino, sul lato delle prestazioni con gli interi mi sa che proprio non ha problemi.
Infatti il backend dell'M1 è semplicemente mostruoso.
Persino il mantra "ma le istruzioni x86 fanno più cose e sono più compatte" non regge; Aarch64 ha istruzioni "semplici" che fanno molto più lavoro delle corrispondenti istruzioni "semplici" per x86-64.
Anche su questo t'ho già risposto.
Ad esempio queste sono le "MOV condizionali":

CCMN rn, #i5, #f4, cc if(cc) rn + i; else N:Z:C:V = f
CCMN rn, rm, #f4, cc if(cc) rn + rm; else N:Z:C:V = f
CCMP rn, #i5, #f4, cc if(cc) rn − i; else N:Z:C:V = f
CCMP rn, rm, #f4, cc if(cc) rn − rm; else N:Z:C:V = f
CINC rd, rn, cc if(cc) rd = rn + 1; else rd = rn
CINV rd, rn, cc if(cc) rd = ∼rn; else rd = rn
CNEG rd, rn, cc if(cc) rd = −rn; else rd = rn
CSEL rd, rn, rm, cc if(cc) rd = rn; else rd = rm
CSET rd, cc if(cc) rd = 1; else rd = 0
CSETM rd, cc if(cc) rd = ∼0; else rd = 0
CSINC rd, rn, rm, cc if(cc) rd = rn; else rd = rm + 1
CSINV rd, rn, rm, cc if(cc) rd = rn; else rd = ∼rm
CSNEG rd, rn, rm, cc if(cc) rd = rn; else rd = −rm


Sono praticamente degli if .. then .. else .. endif eseguiti in un singolo ciclo senza bisogno di branch prediction e che corrispondono a casi d'uso molto frequenti.
Gli equivalenti di CSEL e CSET (CMOVcc e SETcc) ci sono da eoni su x86. Probabilmente ARM le avrà copiato, visto che sono molto utili.

CSETM l'ho inserita parecchi anni fa persino nella mia precedente ISA simil-68K, quindi roba di 9-10 anni fa.

x86 ha pure la FMOVcc per la vecchia FPU x87.

Sono istruzioni "ovvie", perché riguardano casi molto comuni, come dicevo prima.

Sulle altre che mette a disposizione AArch64... non so. Probabilmente ARM avrà trovato dei pattern comuni per averle implementate, ma bisognerebbe vedere in quali tipi di algoritmi e con quale frequenza si presentino nel codice.
Un altro esempio sono le operazioni di and/or/xor in cui il secondo operando può essere opzionalmente invertito logicamente
La ANDN c'è pure su x86 da un bel po', e ha il suo perché. Ma ORN o XORN non sono affatto comuni.
e/o shiftato o ruotato a piacere,
Questo gli serve più che altro perché ARM/AArch64 non può usare dei valori immediati di grandi dimensioni, e con degli shift o rotazioni può in parte compensare per alcune costanti comuni.

x86/x64 non hanno di questi problemi, ovviamente.
sempre in un solo ciclo e pure queste molto utili per eseguire indirizzamento con modulo,
L'allineamento di un puntatore non è un'operazione così comune. In genere la si fa quando si deve allocare un po' di memoria, o più spesso quando lo si è allocato più memoria del necessaria per garantire abbastanza spazio per il successivo allineamento.

Ma non è roba da calcolo intensivo, insomma: si usano in particolari scenari. Fermo restando che x86/x64 possono usare costanti grandi, per cui non devono ricorrere a questi trucchi.
usare maschere di selezione
Ti riferisci sempre a AND/ANDN/OR? Se sì, vedi sopra: è già possibile con x86/x64.
e calcolare indirizzi in modi molto più flessibili delle LEA di x86-64.
Eh, no, dai: non c'è nulla né in ARM né in AArch64 che si possa comparare a una LEA RegDest,[Regbase + RegIndex * Size + offset32]. E' a tutti gli effetti una somma con 3 operandi (di cui uno scalato) e con una costante grande (a 32 bit con segno). Roba del genere i RISC possono soltanto sognarsela.
Ed ovviamente ci sono le operazioni aritmetiche a 3 operandi che su x86-64 corrispondono ad una mov seguita dall'operazione stessa (due istruzioni x86-64 per fare quello che richiede una singola istruzioni su Aarch64).
Sì, questo è un chiaro vantaggio dei RISC, in generale, ma x86/x64 compensa in parte con il macro-op fusion, che consente di eseguire in ogni caso una uop anziché due nel backend.
Insomma, mi sa che si difende bene anche con gli interi a parità di TDP o anche con x86-64 che girano con un TDP un poco più alto.
Questo senz'altro. Ma anche perché x86/x64 non hanno backend con così tante risorse a disposizione. Ciò nonostante, hanno elevatissime prestazioni. Il che dovrebbe far riflettere. ;)
Detto ciò sono contento che anche AMD stia producendo delle APU e CPU con architettura efficiente facendo concorrenza ( assieme ad Apple ) ad una Intel dormiente o menefreghista.
Intel non è né dormiente né menefreghista. Se non fosse per i problemi che ha avuto coi suoi processi produttivi non staremmo nemmeno qui a parlarne e a fare confronti (perché non ce ne sarebbero).
Che puoi formulare anche in modo invertito:
x86 si difende bene vs ARM su chip ad alte prestazioni con un TDP di poco più alto ( a parità di tutto il resto)
E con una montagna di risorse. E non solo come backend: basti guardare la dimensione della cache codice L1...

P.S. Anche qui scusate, ma ho impiegato un sacco di tempo a scrivere, e non ho nessuna voglia di rileggere e correggere.

@cdimauro
è sempre un piacere leggerti, anche se le mie competenze mi permettono di capire forse una metà del post :D

una cosa non concordo, Intel ha si avuto problemi col processo produttivo, ma non puoi negare che abbia un po "dormito" negli anni perché tanto non aveva bisogno di impegnarsi al massimo e il recupero di AMD credo ne sia una prova. Che poi questa cosa è ovviamente "colpa" di AMD perché in precedenza erano troppo "scarsi" per farla impegnare penso sia anche vero

@cdimauro
è sempre un piacere leggerti

Si beh.. si potesse fare a meno della tradizionale mono uber-rispostona mega multiquote di 36 messaggi di 18 utenti diversi.. :D

:fagiano:

@cdimauro
è sempre un piacere leggerti, anche se le mie competenze mi permettono di capire forse una metà del post :D

una cosa non concordo, Intel ha si avuto problemi col processo produttivo, ma non puoi negare che abbia un po "dormito" negli anni perché tanto non aveva bisogno di impegnarsi al massimo e il recupero di AMD credo ne sia una prova. Che poi questa cosa è ovviamente "colpa" di AMD perché in precedenza erano troppo "scarsi" per farla impegnare penso sia anche vero

Smettiamola di dire facilonerie:
Tu responsabile cpu se ti promettono i 10 nm dove puoi infilarci il 35% in più di transistor rispetto al 14nm al giorno x che fai progetti una cpu che non li contenga e invece la progetti per i 14nm?
Se vuoi aumentare l'ipc in modo significativo devi aumentare in modo significativo anche il numero di transistor.
Zen sui 32nm sarebbe stato grande come una mattonella da bagno, con frequenze ridicole e consumi mostruosi:
Quindi senza pp adeguato zen sarebbe rimasto nel cassetto come ogni altra nuova architettura intel progettata in attesa dei 10nm.
Stai pur certo che la schiera sostanziasa di ingegneri intel hanno lavorato per tutto questo tempo e certamente non sono stati pagati per dormire.
Oggi in tutti i settori ( ed in particolar modo quello tecnologico) vale la semplice regola:
chi si ferma è perduto.
Riguardo il dormire o meno di intel lo si vedrà con la sua prima cpu a 7nm, e stai pur certo che saranno evidenti sia il contributo del numero dei transistor sull'ipc sia i consumi dati dal pp.
Chi ha "dormito" è stato il reparto silicio di intel, non certo intel in toto, perchè l'aumento di ipc, la frequenza ed il consumo totale delle sue architetture ha raggiunto quasi la perfezione su un 14nm oramai preistorico.
In definitiva gli ingegneri intel hanno fatto non uno, ma innumerevoli piccoli miracoli. E senza ingegno e un reparto adeguato un colpo di culo è possibile, ma non tutti quelli messi a segno da intel sui 14, e credimi, probabilmente il reparto progettazione non ha dormito nemmeno la notte nel tentativo di prendere quello che si poteva di quanto destinato al 10 e adattarlo sul 14 ( che poi tutti quei + sono solo marketing per tenere buoni gli azionisti e non far emergere le gravi difficoltà in cui si era entrati)

@cdimauro
è sempre un piacere leggerti, anche se le mie competenze mi permettono di capire forse una metà del post :D
Grazie. :) Purtroppo sono questioni estremamente tecniche, e non è facile spiegarle in maniera semplice, mi spiace. :stordita:
una cosa non concordo, Intel ha si avuto problemi col processo produttivo, ma non puoi negare che abbia un po "dormito" negli anni perché tanto non aveva bisogno di impegnarsi al massimo e il recupero di AMD credo ne sia una prova. Che poi questa cosa è ovviamente "colpa" di AMD perché in precedenza erano troppo "scarsi" per farla impegnare penso sia anche vero
Ti ha già risposto sotto Antonio ("Piedone), ma aggiungo soltanto un paio di esempio per farti capire come sono andate le cose.

Cannon Lake, che avrebbe dovuto portare i 10nm e (finalmente) le AVX-512 ovunque, sarebbe dovuto arrivare 4-5 anni fa. Invece è stato ritardato di 2-3 anni ed è arrivato in pochissimi esemplari soltanto su qualche laptop.

IceLake sarebbe dovuto arrivare circa un anno dopo. Invece è arrivato soltanto di recente (lo scorso anno, mi pare), sempre sui laptop (arriverà anche sui server), e in versione desktop non arriverà. Diciamo che a livello micro-architetturale arriverà su desktop soltanto il prossimo anno, con RocketLake, che però sarà a 14nm e non coi previsti 10nm.

Dopo IceLake sarebbe dovuto arrivare TigerLake, sempre all'incirca un anno dopo, e invece è arrivato soltanto quest'anno, ancora una volta soltanto in declinazione mobile (laptop).

E così via.

Di questi tre ne ero già al corrente quando lavoravo alla Intel (fino al 2016), e sul primo avrei dovuto pure metterci mano per testarlo (all'epoca mi occupavo di testare le estensioni SGX e AVX-512, per le nostre estensioni di debug a Visual Studio ed Eclipse)... ma poi è stato, per l'appunto, rimandato, e quindi non

Quindi, e per chiudere, Intel aveva una solidissima roadmap (come sempre), ma i problemi coi processi produttivi (10nm all'epoca, ma adesso ci si è messo pure quello a 7nm) ha mandato tutto a carte 48...
Si beh.. si potesse fare a meno della tradizionale mono uber-rispostona mega multiquote di 36 messaggi di 18 utenti diversi.. :D
Mi spiace. Purtroppo scrivendo e rispondendo è diventato un grande calderone.

La prossima volta proverò a raggruppare i commenti in base al contenuto della discussione. Il problema è che quando si parte con un argomento poi si finisce a parlare di tante altre cose. :stordita:
Smettiamola di dire facilonerie:
Tu responsabile cpu se ti promettono i 10 nm dove puoi infilarci il 35% in più di transistor rispetto al 14nm al giorno x che fai progetti una cpu che non li contenga e invece la progetti per i 14nm?
Se vuoi aumentare l'ipc in modo significativo devi aumentare in modo significativo anche il numero di transistor.
Zen sui 32nm sarebbe stato grande come una mattonella da bagno, con frequenze ridicole e consumi mostruosi:
Quindi senza pp adeguato zen sarebbe rimasto nel cassetto come ogni altra nuova architettura intel progettata in attesa dei 10nm.
Stai pur certo che la schiera sostanziasa di ingegneri intel hanno lavorato per tutto questo tempo e certamente non sono stati pagati per dormire.
Oggi in tutti i settori ( ed in particolar modo quello tecnologico) vale la semplice regola:
chi si ferma è perduto.
Riguardo il dormire o meno di intel lo si vedrà con la sua prima cpu a 7nm, e stai pur certo che saranno evidenti sia il contributo del numero dei transistor sull'ipc sia i consumi dati dal pp.
Chi ha "dormito" è stato il reparto silicio di intel, non certo intel in toto, perchè l'aumento di ipc, la frequenza ed il consumo totale delle sue architetture ha raggiunto quasi la perfezione su un 14nm oramai preistorico.
In definitiva gli ingegneri intel hanno fatto non uno, ma innumerevoli piccoli miracoli. E senza ingegno e un reparto adeguato un colpo di culo è possibile, ma non tutti quelli messi a segno da intel sui 14, e credimi, probabilmente il reparto progettazione non ha dormito nemmeno la notte nel tentativo di prendere quello che si poteva di quanto destinato al 10 e adattarlo sul 14 ( che poi tutti quei + sono solo marketing per tenere buoni gli azionisti e non far emergere le gravi difficoltà in cui si era entrati)
C'è anche gente che sta pagando per questi ritardi. Murthy, il braccio destro del precedente CEO, è stato cacciato un po' di mesi fa.

Non che possa cambiare molto: i problemi rimangono lo stesso, e ci vorrà tempo per sistemarli.

@Piedone1113 @cdimauro
si ma non è una cosa solo degli ultimi 5-6 anni, è praticamente da P4 che che si dice come Intel dorma e si svegli solo ogni volta che AMD tira fuori la sorpresa.

Che questo non sia un problema lato "commerciale" è vero, perché impegnarmi se tanto non ho concorrenza? Questo non vuol dire che Intel non si impegni, ma che in certi periodi (non gli ultimi dove ha avuto grossi problemi tecnici) ha "centellinato" l'innovazione

@Piedone1113 @cdimauro
si ma non è una cosa solo degli ultimi 5-6 anni, è praticamente da P4 che che si dice come Intel dorma e si svegli solo ogni volta che AMD tira fuori la sorpresa.

Che questo non sia un problema lato "commerciale" è vero, perché impegnarmi se tanto non ho concorrenza? Questo non vuol dire che Intel non si impegni, ma che in certi periodi (non gli ultimi dove ha avuto grossi problemi tecnici) ha "centellinato" l'innovazione

"Mike Markkula, l'uomo che ha messo l'intelligenza nella Intel", così chiosò Steve Jobs :D

E' dagli anni '70 che Intel sembra un'altalena. Va su e va giù. Ed è chiaro che non sia guidata da visionari, ma da affaristi. Per cui, quando non c'hanno concorrenza vanno a nanna. Semplice!

Si, ma il punto è perchè così tanta gente "del mestiere" si senta quasi offesa per il fatto che qualcuno ha tirato fuori un SoC ARM con gli attributi. A me queste cose danno la sveglia meglio del caffè.

Ben venga un pò d'innovazione, in un settore ormai stagnante.

@Piedone1113 @cdimauro
si ma non è una cosa solo degli ultimi 5-6 anni, è praticamente da P4 che che si dice come Intel dorma e si svegli solo ogni volta che AMD tira fuori la sorpresa.

Che questo non sia un problema lato "commerciale" è vero, perché impegnarmi se tanto non ho concorrenza? Questo non vuol dire che Intel non si impegni, ma che in certi periodi (non gli ultimi dove ha avuto grossi problemi tecnici) ha "centellinato" l'innovazione

E' indubbio che Intel è bravissima a massimizzare gli investimenti, ma questo non vuol dire che dorma:
Piccolo esempio i7 4+4 consumer era il top fin tanto che non c'era concorrenza. Si massimizzavano gli introiti offrendo una piattaforma ehdt per chi aveva bisogno di più core.
Pur rimanendo sui 14 con Amd ad offrire un numero elevato di core ha innalzato il suo core count su fascia bassa segno che la predisposizione a livello ingegneristico ci fosse ma che per precise scelte commerciali non lo si era attuato.
Il P4 è stato un flop ( non del progetto in se, ma della sua implementazione).
Non dimentichiamoci che era un'architetura destinata a raggiungere i 10 ghz e se la sua implementazione sul silicio fosse andata liscia non staremmo a parlare di flop.
Purtroppo per intel all'aumentare delle frequenze ed il ridursi del pp si sono innescate dinamiche fisiche che fino ad allora erano marginali e trascurabili rendendo il progetto p4 un incompiuto.
Intel ha osato e con presunzione non hanno nemmeno adottato un piano b

E' indubbio che Intel è bravissima a massimizzare gli investimenti, ma questo non vuol dire che dorma:
Piccolo esempio i7 4+4 consumer era il top fin tanto che non c'era concorrenza. Si massimizzavano gli introiti offrendo una piattaforma ehdt per chi aveva bisogno di più core.
Pur rimanendo sui 14 con Amd ad offrire un numero elevato di core ha innalzato il suo core count su fascia bassa segno che la predisposizione a livello ingegneristico ci fosse ma che per precise scelte commerciali non lo si era attuato.
Il P4 è stato un flop ( non del progetto in se, ma della sua implementazione).
Non dimentichiamoci che era un'architetura destinata a raggiungere i 10 ghz e se la sua implementazione sul silicio fosse andata liscia non staremmo a parlare di flop.
Purtroppo per intel all'aumentare delle frequenze ed il ridursi del pp si sono innescate dinamiche fisiche che fino ad allora erano marginali e trascurabili rendendo il progetto p4 un incompiuto.
Intel ha osato e con presunzione non hanno nemmeno adottato un piano b
dorma nel senso che non ha mai investito "anticipatamente" o almeno non in maniera così visibile da anni e ha raccolto tanti errori, dove si è salvata sempre per la mancanza di concorrenza

dorma nel senso che non ha mai investito "anticipatamente" o almeno non in maniera così visibile da anni e ha raccolto tanti errori, dove si è salvata sempre per la mancanza di concorrenza

Beh però ha investito moltissimo nel far fuori la concorrenza :asd:

https://www.networkworld.com/article/2239461/intel-and-antitrust--a-brief-history.html

Non a caso l'UE le ha appioppato 1 miliarduccio e mezzo di multa per aver corr...ehm...dato la paghetta agli OEM!

Su queste cose ti ho già risposto in un altro thread. ;)

Ed io ho risposto a mia volta. ;)
Secondo te i progettisti di ARM quando hanno costruito da zero il set d'istruzioni Aarch64 non hanno fatto le loro considerazione su quale opzione implementativa era la più performante sia nel presente che sul lungo termine ?


Infatti il backend dell'M1 è semplicemente mostruoso.

E' mostruoso perchè il frontend può fornire abbastanza lavoro a tale backend da rendere conveniente la cosa.


Anche su questo t'ho già risposto.

Ed io ti ho risposto sotto con vari controesempi di istruzioni decisamente complesse che permettono di risparmiare un fottio di jump condizionali (che pesano molto sulle prestazioni effettive). ;-)


Gli equivalenti di CSEL e CSET (CMOVcc e SETcc) ci sono da eoni su x86. Probabilmente ARM le avrà copiato, visto che sono molto utili.

Ti ricordo che il set d'istruzioni dei primi ARM aveva già quasi TUTTE le istruzioni ad esecuzione condizionale ben prima degli x86. ;)
Con il redesign avvenuto con Aarch64 hanno rifatto tutto da zero, ri-valutando cosa c'era di buono nei set d'istruzioni e nelle architetture già esistenti e soppesando bene cosa tenere e cosa no.


CSETM l'ho inserita parecchi anni fa persino nella mia precedente ISA simil-68K, quindi roba di 9-10 anni fa.

ARM1 il 5 aprile 1985 l'aveva già implementata in hardware.


x86 ha pure la FMOVcc per la vecchia FPU x87.

Peccato che su x86-64 sia sconsigliato usare la vecchia FPU per questioni di prestazioni.


Sulle altre che mette a disposizione AArch64... non so. Probabilmente ARM avrà trovato dei pattern comuni per averle implementate, ma bisognerebbe vedere in quali tipi di algoritmi e con quale frequenza si presentino nel codice.


f = valore immediato di 4 bit che modifica i flag N,Z,C,V
i = valore immediato di 5 bit per casi in cui basta un incremento immediato

CCMN rn, #i5, #f4, cc if(cc) rn + i; else N:Z:C:V = f
CCMN rn, rm, #f4, cc if(cc) rn + rm; else N:Z:C:V = f

Le CCMN permettono di contare un certo numero di condizioni differenti
oppure di selezionare elementi differenti in un array (oppure di selezionare il prossimo elemento mentre si scorre un array, saltando quelli che non soddisfano certe condizioni)

CCMP rn, #i5, #f4, cc if(cc) rn − i; else N:Z:C:V = f
CCMP rn, rm, #f4, cc if(cc) rn − rm; else N:Z:C:V = f

Le CCMP sono la versione "rovesciata" di CCMN.

Entrambe tornano anche utili per indicizzare una lookup table (di dati oppure di indirizzi a cui saltare in base a condizioni complesse) in modo da valutare senza jump tutta una sfilza di condizioni ed eseguire un singolo jmp.
Hai presente tutti i casi in cui ci sono if..then..else annidati, oppure delle switch .. case .. belle complicate con valori più o meno contigui, intervalli case consecutivi ecc. ?
La cosa torna utile decisamente molto spesso mi sembra.

CINC rd, rn, cc if(cc) rd = rn + 1; else rd = rn
Incremento condizionale, utile per conteggio di eventi e come parte ri codice branchless.

CINV rd, rn, cc if(cc) rd = ∼rn; else rd = rn
Not condizionale (anche questo utile per codificare codice in forma branchless) + move

CNEG rd, rn, cc if(cc) rd = −rn; else rd = rn
Negazione condizionale + move

CSINC rd, rn, rm, cc if(cc) rd = rn; else rd = rm + 1
Questa torna utile per aggiornare puntatori o indici su un ring buffer
senza essere costretti ad usare array o buffer con numero di elementi che corrisponde a potenze di due. Oppure per scorrere liste allocate in spezzoni di elementi consecutivi.

CSINV rd, rn, rm, cc if(cc) rd = rn; else rd = ∼rm
CSNEG rd, rn, rm, cc if(cc) rd = rn; else rd = −rm
Anche queste tornano utile per convertire codice che normalmente contiene dei branch in una più rapida e leggera versione branchless.


La ANDN c'è pure su x86 da un bel po', e ha il suo perché. Ma ORN o XORN non sono affatto comuni.

No, x86 così proprio non le ha, nota che il secondo operando è opzionalmente shiftabile da 1 a 64bit.
E' roba che serve ad esempio per codificare espressioni booleane associate ad eventi o condizioni in stringhe di fino a 64 bit ed elaborarle tutte insieme con singole istruzioni.
E' roba che a livello di codice sorgente non vedi direttamente ma che il compilatore (o uno sviluppatore che deve spremere ogni singolo ciclo utile da un processore) usa per generare codice branchless.


Questo gli serve più che altro perché ARM/AArch64 non può usare dei valori immediati di grandi dimensioni, e con degli shift o rotazioni può in parte compensare per alcune costanti comuni.


Le scelte fatte da ARM riguardo la dimensione max dei valori immediata deriva da analisi che fanno da decenni sulle caratteristiche del codice sorgente di un sacco di applicazioni, non lo dimenticare. ;)

Inoltre quegli shift tornano utili per implementare forme di calcolo indirizzi molto più complesse di quello che può fare una LEA e pre-caricarle su registri.

In loop particolarmente critici, quando hai 32 registri invece di 16 puoi permetterti di pre-caricarne 16 con costanti ed ottenere prestazioni migliori di quel che può fare un x86 con 16 registri ed operandi in memoria.



x86/x64 non hanno di questi problemi, ovviamente.



L'allineamento di un puntatore non è un'operazione così comune. In genere la si fa quando si deve allocare un po' di memoria, o più spesso quando lo si è allocato più memoria del necessaria per garantire abbastanza spazio per il successivo allineamento.



Ma non è roba da calcolo intensivo, insomma: si usano in particolari scenari. Fermo restando che x86/x64 possono usare costanti grandi, per cui non devono ricorrere a questi trucchi.



Ti riferisci sempre a AND/ANDN/OR? Se sì, vedi sopra: è già possibile con x86/x64.

Parzialmente possibile. ;)


Eh, no, dai: non c'è nulla né in ARM né in AArch64 che si possa comparare a una LEA RegDest,[Regbase + RegIndex * Size + offset32]. E' a tutti gli effetti una somma con 3 operandi (di cui uno scalato) e con una costante grande (a 32 bit con segno). Roba del genere i RISC possono soltanto sognarsela.

E' roba che sugli x86 è necessaria perchè fa parte delle "feature" ereditate dagli 8086 ed a suo tempo abbandonarla avrebbe causato seri problemi di prestazioni con le montagne di codice precompilato già in circolazione e codificato per 8086, 80286 ed 80386+.
Ed a quel punto è stata fatta di necessità virtù.


Sì, questo è un chiaro vantaggio dei RISC, in generale, ma x86/x64 compensa in parte con il macro-op fusion, che consente di eseguire in ogni caso una uop anziché due nel backend.

Non è che la macro-op fusion sia un esclusiva degli x86, viene suggerita anche per le implementazioni "ad alte prestazioni" di Risc V.


Questo senz'altro. Ma anche perché x86/x64 non hanno backend con così tante risorse a disposizione. Ciò nonostante, hanno elevatissime prestazioni. Il che dovrebbe far riflettere. ;)

Non hanno un backend con così tante risorse perchè per un x86 gli "sweet spot" tra parallelismo nel backend, complessità del decoder x86, frequenza massima raggiungibile, pressione su registri e unità di load/store ecc. sono differenti (e nel caso di Intel, ulteriormente limitati dall'aver necessità di fare i backporting verso i 14nm).

@Piedone1113 @cdimauro
si ma non è una cosa solo degli ultimi 5-6 anni, è praticamente da P4 che che si dice come Intel dorma e si svegli solo ogni volta che AMD tira fuori la sorpresa.
Non è così. Ti hanno già risposto in merito, ma aggiungo che proprio il P4 che citi è stata la dimostrazione che non dormisse e che, anzi, cercasse di innovare.
Ad esempio, l'HyperThreading l'ha tirato fuori proprio con questi processori. E dopo QUINDICI anni AMD ha pensato di integrarlo nei suoi processori: perché ha dormito tutto questo tempo?

Ma dopo il P4 potrei citarti Centrino/Banias, i Core, i Core Duo, Larrabee, gli Xeon Phi. Le AVX 1&2, le FMA, le AVX-512. Di innovazione direi che ne abbia tirata fuori abbastanza.
Che questo non sia un problema lato "commerciale" è vero, perché impegnarmi se tanto non ho concorrenza? Questo non vuol dire che Intel non si impegni, ma che in certi periodi (non gli ultimi dove ha avuto grossi problemi tecnici) ha "centellinato" l'innovazione
Infatti non è così: Intel s'è impegnata ugualmente, a prescindere: vedi sopra.
dorma nel senso che non ha mai investito "anticipatamente" o almeno non in maniera così visibile da anni e ha raccolto tanti errori, dove si è salvata sempre per la mancanza di concorrenza
No. Vedi sopra: ha investito anticipatamente.

E l'ha fatto pure quando la sua superiorità era schiacciante. Ti ho già elencato i processori che erano già in cantiere da ben prima che AMD se ne uscisse fuori con Zen/Ryzen. Anzi, da quando non si sapeva proprio nulla di questi processori, a parte che AMD ci stava lavorando.
"Mike Markkula, l'uomo che ha messo l'intelligenza nella Intel", così chiosò Steve Jobs :D

E' dagli anni '70 che Intel sembra un'altalena. Va su e va giù. Ed è chiaro che non sia guidata da visionari, ma da affaristi. Per cui, quando non c'hanno concorrenza vanno a nanna. Semplice!
No, semplicemente falso. Vedi sopra.
Si, ma il punto è perchè così tanta gente "del mestiere" si senta quasi offesa per il fatto che qualcuno ha tirato fuori un SoC ARM con gli attributi.
E chi si sarebbe offeso? Hai qualche nome (e link) da portare?
A me queste cose danno la sveglia meglio del caffè.

Ben venga un pò d'innovazione, in un settore ormai stagnante.
Concordo sull'innovazione (e la concorrenza), ma non sulla stagnazione.
Beh però ha investito moltissimo nel far fuori la concorrenza :asd:

https://www.networkworld.com/article/2239461/intel-and-antitrust--a-brief-history.html

Non a caso l'UE le ha appioppato 1 miliarduccio e mezzo di multa per aver corr...ehm...dato la paghetta agli OEM!
Beh, ha fatto ANCHE questo. Ma proprio in quel periodo sono nati Centrino e poi i Core: alla faccia della mancanza di innovazione e delle dormite... :O

Ed io ho risposto a mia volta. ;)
Secondo te i progettisti di ARM quando hanno costruito da zero il set d'istruzioni Aarch64 non hanno fatto le loro considerazione su quale opzione implementativa era la più performante sia nel presente che sul lungo termine ?
Le hanno fatte certamente. E col vantaggio di avere le mani abbastanza libere, perché sapevano già che AArch64 sarebbe dovuta essere non-retrocompatibile con ARM/Thumb.
E' mostruoso perchè il frontend può fornire abbastanza lavoro a tale backend da rendere conveniente la cosa.
Beh, è anche normale che sia così, perché è un RISC, come già detto.

Ma è anche vero che il backend dei processori x86/x64 sia sottodimensionato rispetto al frontend. In particolare quello di Intel, perché AMD già con la prima versione di Zen ha messo sul piatto più risorse sul backend rispetto a Intel, e le ha via via aumentate con Zen2 e Zen3. Non è un caso che proprio Zen3 riesca a tenere testa all'M1 di Apple.
Eppure il frontend è rimasto sostanzialmente lo stesso, e qui mi riferisco in particolare ai decoder, che continuano a decodificare al massimo 4 istruzioni per ciclo di clock (5 o 6 col macro-op fusion, almeno per Intel, come ho riportato nell'altro thread).
Ed io ti ho risposto sotto con vari controesempi di istruzioni decisamente complesse che permettono di risparmiare un fottio di jump condizionali (che pesano molto sulle prestazioni effettive). ;-)
Nulla da dire su questo: sono aggiunte utili ambito prestazionale (come pure sulla densità di codice).
Ti ricordo che il set d'istruzioni dei primi ARM aveva già quasi TUTTE le istruzioni ad esecuzione condizionale ben prima degli x86. ;)
Appunto: lo erano TUTTE, e non soltanto alcune accuratamente selezionate, come ha fatto Intel. ;)
Con il redesign avvenuto con Aarch64 hanno rifatto tutto da zero, ri-valutando cosa c'era di buono nei set d'istruzioni e nelle architetture già esistenti e soppesando bene cosa tenere e cosa no.
Difatto copiando il modello Intel: soltanto alcune istruzioni condizionali, per i casi realmente più frequenti / utili. :fagiano:
ARM1 il 5 aprile 1985 l'aveva già implementata in hardware.
Vedi sopra: non è la stessa cosa. Qui parliamo di alcune istruzioni condizionali.
Peccato che su x86-64 sia sconsigliato usare la vecchia FPU per questioni di prestazioni.
Ma viene ancora usato quando è richiesta più precisione rispetto a quella normalmente a disposizione con quella doppia.

Per cui quell'istruzione può essere utile. E dico "può" perché il codice FP è più lineare e meno soggetto a salti, rispetto a quello "intero" / "scalare", per cui istruzioni del genere vengono usate molto meno.
f = valore immediato di 4 bit che modifica i flag N,Z,C,V
i = valore immediato di 5 bit per casi in cui basta un incremento immediato

CCMN rn, #i5, #f4, cc if(cc) rn + i; else N:Z:C:V = f
CCMN rn, rm, #f4, cc if(cc) rn + rm; else N:Z:C:V = f

Le CCMN permettono di contare un certo numero di condizioni differenti
oppure di selezionare elementi differenti in un array (oppure di selezionare il prossimo elemento mentre si scorre un array, saltando quelli che non soddisfano certe condizioni)
OK, questa era la spiegazione che cercavo: i casi d'uso nel codice reale.
CCMP rn, #i5, #f4, cc if(cc) rn − i; else N:Z:C:V = f
CCMP rn, rm, #f4, cc if(cc) rn − rm; else N:Z:C:V = f

Le CCMP sono la versione "rovesciata" di CCMN.

Entrambe tornano anche utili per indicizzare una lookup table (di dati oppure di indirizzi a cui saltare in base a condizioni complesse) in modo da valutare senza jump tutta una sfilza di condizioni ed eseguire un singolo jmp.
Hai presente tutti i casi in cui ci sono if..then..else annidati, oppure delle switch .. case .. belle complicate con valori più o meno contigui, intervalli case consecutivi ecc. ?
La cosa torna utile decisamente molto spesso mi sembra.
Sì. Utile e comune.

Ma si può fare di gran lunga meglio (nei casi più comuni), senza nessuna catena di istruzioni (confronti, accumuli) del genere. E si può fare già adesso sfruttando un certo numero fisso di istruzioni (una manciata. Quindi non molte). Per la precisione: di opportune istruzioni.
Con una singola istruzione (o forse un paio, per non renderla troppo complicata, e quindi di difficile implementazione a livello micro-architetturale) sarebbe anche meglio, ovviamente.
CINC rd, rn, cc if(cc) rd = rn + 1; else rd = rn
Incremento condizionale, utile per conteggio di eventi e come parte ri codice branchless.
OK
CINV rd, rn, cc if(cc) rd = ∼rn; else rd = rn
Not condizionale (anche questo utile per codificare codice in forma branchless) + move

CNEG rd, rn, cc if(cc) rd = −rn; else rd = rn
Negazione condizionale + move
Qui non elenchi casi d'uso, e non mi sembrano molto utili.
CSINC rd, rn, rm, cc if(cc) rd = rn; else rd = rm + 1
Questa torna utile per aggiornare puntatori o indici su un ring buffer
senza essere costretti ad usare array o buffer con numero di elementi che corrisponde a potenze di due. Oppure per scorrere liste allocate in spezzoni di elementi consecutivi.
Utile, senz'altro.
CSINV rd, rn, rm, cc if(cc) rd = rn; else rd = ∼rm
CSNEG rd, rn, rm, cc if(cc) rd = rn; else rd = −rm
Anche queste tornano utile per convertire codice che normalmente contiene dei branch in una più rapida e leggera versione branchless.
Senza casi d'uso è difficile comprenderne l'utilità.

Che siano branchless è ovvio, ma non mi dice niente.
No, x86 così proprio non le ha, nota che il secondo operando è opzionalmente shiftabile da 1 a 64bit.
E' roba che serve ad esempio per codificare espressioni booleane associate ad eventi o condizioni in stringhe di fino a 64 bit ed elaborarle tutte insieme con singole istruzioni.
E' roba che a livello di codice sorgente non vedi direttamente ma che il compilatore (o uno sviluppatore che deve spremere ogni singolo ciclo utile da un processore) usa per generare codice branchless.
Continuo a non trovare utilità nelle ORN e XORN. Per codificare espressioni booleane sono sufficienti AND, OR, XOR, e ANDN.

Lo shift può essere utile per spostare maschere di bit nella giusta posizione, per poi effettuare l'operazione. Questo può servire, senz'altro.
Le scelte fatte da ARM riguardo la dimensione max dei valori immediata deriva da analisi che fanno da decenni sulle caratteristiche del codice sorgente di un sacco di applicazioni, non lo dimenticare. ;)
Lo so bene. E dovresti sapere bene anche tu che per ARM è stata una scelta obbligata, visto che le sue istruzioni non possono caricare costanti arbitrarie, come invece fanno x86/x64. :cool:
Inoltre quegli shift tornano utili per implementare forme di calcolo indirizzi molto più complesse di quello che può fare una LEA e pre-caricarle su registri.
Saranno casi molto particolare, perché più che scalare l'indice per accedere a un array è difficile utilizzo.

Alla memoria si accede molto spesso secondo pattern precisi, e in particolare indicizzando array per accedere a determinati elementi. Questi sono i casi comuni, e sono ampiamente coperti dalla LEA.
In loop particolarmente critici, quando hai 32 registri invece di 16 puoi permetterti di pre-caricarne 16 con costanti ed ottenere prestazioni migliori di quel che può fare un x86 con 16 registri ed operandi in memoria.
Ne dubito, visto che x64 non richiede alcun registro proprio perché le costanti le può specificare direttamente. Quindi parte a razzo con l'esecuzione del loop. E una volta in esecuzione nel loop la cache non viene nemmeno toccata, e usa direttamente le uop.
E' roba che sugli x86 è necessaria perchè fa parte delle "feature" ereditate dagli 8086 ed a suo tempo abbandonarla avrebbe causato seri problemi di prestazioni con le montagne di codice precompilato già in circolazione e codificato per 8086, 80286 ed 80386+.
Ed a quel punto è stata fatta di necessità virtù.
Direi di no: la LEA è oggettivamente utile non soltanto per eseguire somme quaternarie, ma perché una cosa molto comune nel codice è, per l'appunto, il calcolo di indirizzi (è per questo che è nata: Load Effective Address). In particolare se devi passare degli indirizzi a una funzione.

Per questo è un'istruzione molto usata. Infatti ce l'ha pure Motorola nei 68K, a cui ha pure aggiunto l'utilissima PEA (Push Effective Address; anche qui per il passaggio di indirizzi nelle chiamate a funzione. Istruzione che ho mutuato nella mia architettura, e che ha contribuito a un netto miglioramento nella densità di codice e nella diminuzione delle istruzioni eseguite :fagiano: ).
Non è che la macro-op fusion sia un esclusiva degli x86, viene suggerita anche per le implementazioni "ad alte prestazioni" di Risc V.
Sì, lo so. E viene fatto per compensare alle mancanze dell'ISA, che difetta di utili istruzioni, producendo un netto calo prestazionale, come ho già avuto modo di riportare.
Non hanno un backend con così tante risorse perchè per un x86 gli "sweet spot" tra parallelismo nel backend, complessità del decoder x86, frequenza massima raggiungibile,
Su questo ho parzialmente risposto sopra. Vedremo se in futuro il frontend verrà aumentato (più di 4 istruzioni x86/x64 decodificate).
pressione su registri e unità di load/store ecc. sono differenti
No, questo non c'entra. Infatti puoi vedere tu stesso che già coi Core Duo ha posto particolare enfasi alle unità di load/store delle sue micro-architetture. Lo si nota proprio a occhio, confrontando i diagrammi con la concorrenza, che Intel privilegia da sempre questa parte del backend. Che, infatti, ha ulteriormente potenziato con SunnyCove e successori.

Si tratta di decisioni micro-architetturali che sono frutto della visione che hanno gli ingegneri su come e quali risorse mettere nel backend.
Infatti gli ingegneri di AMD hanno avuto una visione diversa, e hanno preferito puntare di più sulle ALU. Giusto per fare un altro esempio.
(e nel caso di Intel, ulteriormente limitati dall'aver necessità di fare i backporting verso i 14nm).
Hanno ridotto soltanto il numero di massimo: 8 anziché gli attuali 10 del top di gamma. Ma rimangono i core ad alte prestazioni di Sunny Cove.

Qui non elenchi casi d'uso, e non mi sembrano molto utili.


CINV rd, rn, cc if(cc) rd = ∼rn; else rd = rn

Tra le tante possibilità c'e questa:
rd = valore;
if (cc) rd = ∼rd;

ed analogamente per
CNEG rd, rn, cc if(cc) rd = −rn; else rd = rn

uno dei possibili utilizzi è questo:
rd = valore;
if (cc) rd = -rd;

In entrambi i casi si elimina un caso relativamente frequente di branch condizionale che spesso ha circa un 50% di probabilità di essere eseguito e due move con interdipendenze, trasformando il tutto in una singola istruzione.


Senza casi d'uso è difficile comprenderne l'utilità.

Che siano branchless è ovvio, ma non mi dice niente.


CSINV rd, rn, rm, cc if(cc) rd = rn; else rd = ∼rm

CSNEG rd, rn, rm, cc if(cc) rd = rn; else rd = −rm

In entrambi i casi con DUE registri puoi codificare SEI sottoespressioni (rn, ∼rn, -rn, rm, ∼rm, -rm) che tornano utili per eseguire espressioni condizionali senza branch in cui si deve scegliere tra il risultato di due subespressioni
in cui una di esse ha come operazione finale la negazione o il not binario.
E' una cosa basata sull'analisi delle espressioni condizionali nei sorgenti e loro ottimizzazioni.

Scusami, forse non sono stato chiaro.

Come funzionino di per sé le istruzioni mi è chiaro e semplice: è in quali ambiti applicativi (in quali parti di qualche algoritmo noto) che non è facile capire come passano essere impiegate.

Con le altre istruzioni avevi fatto degli esempi di codice reale, che mancano su queste. Tutto qui. Ma se non ti viene in mente niente va bene lo stesso: la mia era pura curiosità. :)