Windows on ARM più veloce sui Mac M1 che su Surface Pro X: il test

[LMCH]

Originariamente inviato da cdimauro

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 ?

Originariamente inviato da cdimauro

Infatti il backend dell'M1 è semplicemente mostruoso.

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

Originariamente inviato da cdimauro

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). ;-)

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

x86/x64 non hanno di questi problemi, ovviamente.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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

Parzialmente possibile.

Originariamente inviato da cdimauro

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ù.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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).

[cdimauro]

Originariamente inviato da Phoenix Fire

@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.

Originariamente inviato da Phoenix Fire

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.

Originariamente inviato da pabloski

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

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.

Originariamente inviato da pabloski

Beh però ha investito moltissimo nel far fuori la concorrenza

https://www.networkworld.com/article...f-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...

[cdimauro]

Originariamente inviato da LMCH

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.

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.

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 ).

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.

[LMCH]

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

[cdimauro]

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à.