Snapdragon 1000: fino a 12 W per competere con Intel tramite Windows on ARM

[cdimauro]

Originariamente inviato da LMCH

Non erano pertinenti ai casi d'uso di quei dispositivi, in cui i profili di utilizzo davano un vantaggio a chi seppur con prestazioni minori e consumi più alti con le cpu al 100% riusciva aconsumare meno negli altri scenari molto più frequenti.

Questo è senz'altro vero. D'altra parte la piattaforma low-cost di Intel di allora oggettivamente non poteva nemmeno essere classificata come mobile (smartphone, table).

Anche questo è vero, ma già con i Cherry Trail il problema "retrocompatibilità ARM" ormai non esisteva più (almeno per app recenti).
In quel periodo sviluppavo app per industria e domotica in cui si andava pesantemente di NDK (per far girare sorgenti C++ codificati in origine per dispositivi desktop ed embedded "fissi") e nonostante si andasse pesanti ed in profondità gli unici dispositivi che davano problemi erano quelli Samsung con SoC Marvell (driver GPU scritti con il cuo, c'era un bug di inizializzazione che veniva re-introdotto ad update alterne, non so se dipendesse da chi gestiva il firmware in Samsung o in Marvell).

Purtroppo anche per le applicazioni & giochi moderni non tutti venivano compilati per più architetture. Ricordo che all'epoca c'erano delle pagine che riportavano i giochi nativi e quelli emulati, le problematiche di queste ultime, e non c'erano soltanto giochi vecchi.

Su questo sono pienamente d'accordo, almeno su tablet da 10"..13" con display ad alta risoluzione (e batterie belle grosse) già i Cherry Trail si difendevano bene, specialmente se gli si faceva girare sopra qualcosa da "vero" tablet con UI complessa, grafica più pesante e maggior utilizzo di CPU e GPU a piena potenza rispetto al caso d'uso "smartphone".

Ecco un'altra cosa che avevo dimenticato di citare prima: la GPU. Intel non ha mai prodotto GPU aventi prestazioni elevate e/o con consumi ridotti.

E si andava a scontrare con GPU pensate appositamente per il mobile...

Vero che le ultime versioni degli Atom montavano GPU più potenti e ottimizzate, ma Adreno e Mali erano meglio ottimizzate per gli scenari mobile.

Se è per questo sia Google che Microsoft lavorano pure sul design di nuove cpu (tipo il progetto EDGE di Microsoft, da non confondere con il browser Edge).

Sì, lo conosco e ho letto un po' di documentazione tempo fa, ma non mi sembra un'architettura general purpose.

Lo fanno sia per avere sia uno strumento di pressione su Intel quando si tratta di discutere dei costi delle cpu che per avere un piano B (o anche C e D) nel caso discutere non basti più.

Ma non si cambia tipologia di cpu giusto per il gusto di farlo o solo perche si hanno prestazioni superiori senza considerare altri fattori (altrimenti negli anni '90 le cpu Alpha avrebbero spazzato via gli x86).

Beh, è ben noto che Intel sviluppa apposite estensioni (istruzioni) per specifici grossi clienti, però son cose che Google & co. possono benissimo farsi in casa (come peraltro hanno già dimostrato).

[LMCH]

Originariamente inviato da cdimauro

Sì, lo conosco e ho letto un po' di documentazione tempo fa, ma non mi sembra un'architettura general purpose.

Sui prototipi implementati su FPGA hanno fatto il porting sia di Windows 10 che di Linux.
( Fonte: https://www.theregister.co.uk/2018/0...ge_windows_10/ )
Nell"articolo parlano anche di una cooperazione tra Microsoft e Qualcomm per sviluppare due cpu EDGE chiamate R0 ed R1.

[cdimauro]

E' proprio uno degli articoli che avevo letto.

Dentro c'è un link a una pagina rimossa, ma che è stata resa accessibile grazie a archive.org, con maggiori dettagli su come funziona EDGE.

[LMCH]

Originariamente inviato da cdimauro

E' proprio uno degli articoli che avevo letto.

Dentro c'è un link a una pagina rimossa, ma che è stata resa accessibile grazie a archive.org, con maggiori dettagli su come funziona EDGE.

La cosa più interessante di tale architettura è che dovrebbe scalare molto bene una volta messo a punto il backend di ottimizzazione dei compilatori per essa, visto che da un lato rende possibile ad esempio semplificare il loop unrolling e più in generale vettorizzare automaticamente un sacco di codice "sequenziale", mentre dall'altro lato permette di mixare le istruzioni provenienti da più thread in un unico pool di unità di esecuzione.
Nel senso che codice ottimizzato per un R1 32-way gira bene anche su un R0 con solo 8 -way e viceversa, specialmente se ci sono altri thread in esecuzione ed al tempo stesso si riduce enormemente la gestione delle interdipendenze e lo scheduling lato cpu.

Ovviamente se il compilatore non fa bene il suo lavoro poi c'e' il rischio di ritrovarsi con i problemi riscontrati in precedenza su Intel EPIC/Itanium e sul Cell di IBM, ma a differenza di questi due l'architettura EDGE dovrebbe dare buoni risultati anche con core più "semplici" (per sistemi embedded a basso consumo) o che disattivano unita di esecuzione dinamicamente per ridurre i consumi in base al carico computazionale ed altro.

[cdimauro]

Eh, ma è proprio quello il problema: nessun compilatore potrà mai generare codice in grado di competere con la "visione" ciclo di clock per ciclo di clock e il conseguente "dispatch" delle istruzioni a runtime.

Itanium docet, per l'appunto.

[LMCH]

Originariamente inviato da cdimauro

Eh, ma è proprio quello il problema: nessun compilatore potrà mai generare codice in grado di competere con la "visione" ciclo di clock per ciclo di clock e il conseguente "dispatch" delle istruzioni a runtime.

Itanium docet, per l'appunto.

Se non ho capito male, è un approccio differente dall'EPIC di Itanium.
Usano una codifica delle istruzioni e delle informazioni su interdipendenze e dataflow che è più efficiente e si presta bene anche al multithreading.
Semplicemente la cpu non spreca area sul chip e logica di scheduling per "ricostruire parzialmente" le informazioni di ottimizzazione e parallelizzazione che il compilatore estrare anche per le altre cpu, quindi si possono realizzare cpu più semplici a parità di ipc medio oppure che fanno scheduling più sofisticato visto che non devono "riscoprire" quello che gli può già dire il compilatore.
Con EPIC il compilatore doveva ottimizzare molto di più tenendo conto dello specifico numero di unità di esecuzione differenti ecc. ecc. (è c'erano un sacco di feature che si intralciavano tra loro) con EDGE invece sembra che vi sia un maggior equilibrio,dove compilatore e cpu si limitano a fare quello in cui eccellono senza intralciarsi troppo.

[cdimauro]

Guarda, alla fine è esattamente lo stesso principio dei VLIW prima e di EPIC/Itanium poi.

Puoi ottimizzare quanto ti pare e codificare come meglio credi le dipendenze: non potrai MAI prevedere al 100% le branch misprediction e i tempi delle load (e anche store, se ci mettiamo di mezzo la paginazione), schedulando di conseguenza le istruzioni da eseguire.

L'approccio di EDGE, dunque, può senz'altro andare bene per codice "più lineare", ma per quello "general purpose" certamente no: è molto meglio un processore out-of-order tradizionale.

[Yrbaf]

Originariamente inviato da cdimauro

Puoi ottimizzare quanto ti pare e codificare come meglio credi le dipendenze: non potrai MAI prevedere al 100% le branch misprediction e i tempi delle load (e anche store, se ci mettiamo di mezzo la paginazione), schedulando di conseguenza le istruzioni da eseguire.

Però è anche vero il contrario una CPU non avrà mai (o facilmente a certi costi) le risorse necessarie (e tra le risorse figura anche il tempo) per computare tutte le combinazioni necessarie per estrapolare un elevato parallelismo dal codice (se questo parallelismo esiste).

Solo un ottimo compilatore può scoprire che con un certo ordine si può mandare in parallelo magari 32 istruzioni sul singolo core (naturalmente avendo le unità funzionali necessarie).
Haswell per esempio mi pare che oltre 8 istruzioni (poi istruzioni micro-ops) non riesca ed è già un gran numero, altre archittetture (tra cui gli arm almeno fino a A57) oltre 3 o 4 non si spingono.

Quindi la schedulazione dinamica della cpu dovrà sempre essere aiutata da un buon codice ottimizzato e se si vuole andare oltre certi livelli di parallelismo ci vorrà probabilmente la schedulazione statica ed un compilatore in grado saturare le unità funzionali presenti.

[cdimauro]

Diciamo che generalmente più un codice è parallelizzabile, e più è conveniente utilizzare processori vettoriali, o addirittura si passa direttamente al modello GPU.

E' vero che i processori x86/x64 di Intel sono in grado di eseguire max 8 uop per ciclo di clock (sono 10 per Ryzen). Sul versante ARM il massimo in tal senso è rappresentato da Project Denver di nVidia, che pur non essendo un processore nativo ARM arriva a eseguire fino a 7 istruzioni ARM per ciclo di clock; seguito a ruota da Apple, con max 6 per ciclo di clock (ecco perché i core di Apple sono molto grossi paragonati a quelli della concorrenza, e con prestazioni così elevate).

Però ma una uop può anche eseguire un'operazione SIMD, e quindi su più dati allo stesso momento (con AVX512 di Intel che arriva a max 64 operazioni su byte e fino a max 8 operazioni in virgola mobile a precisione doppia).

Quindi un processore general purpose moderno ha pure abbastanza risorse e capacità per eseguire un certo numero di operazioni per ciclo di clock.

Ovviamente non potrà mai eccellere sul versante parallelo, perché soluzioni come quelle di cui abbiamo parlato finora si prestano decisamente meglio.

Alla fine il concetto rimane sempre lo stesso: non esiste la soluzione in grado di avere prestazioni migliori su tutti gli ambiti applicativi. Ed è anche il motivo per cui i processori moderni sono affiancati da coprocessori diversi (GPU in primis, ma anche DSP per l'audio e/o per elaborazione di immagini, Quicksync per transocodifica video, ecc.).

P.S. Servono anche buoni compilatori, ovviamente, anche per processori general purpose e fortemente out-of-order.

[LMCH]

Originariamente inviato da cdimauro

Guarda, alla fine è esattamente lo stesso principio dei VLIW prima e di EPIC/Itanium poi.

Puoi ottimizzare quanto ti pare e codificare come meglio credi le dipendenze: non potrai MAI prevedere al 100% le branch misprediction e i tempi delle load (e anche store, se ci mettiamo di mezzo la paginazione), schedulando di conseguenza le istruzioni da eseguire.

L'approccio di EDGE, dunque, può senz'altro andare bene per codice "più lineare", ma per quello "general purpose" certamente no: è molto meglio un processore out-of-order tradizionale.

Il vantaggio di EDGE rispetto a VLIW ed EPIC sta nell'usare le informazioni che il compilatore "conosce già", senza pretendere che sia il compilatore a farsi carico di tutto.

EDGE è strutturato in più core fisici che possono essere raggruppati in core logici con maggior parallelismo interno e questo lo decide il compilatore in base a quante istruzioni riesce a parallelizzare, quindi si ha comunque una maggior efficienza nell'utilizzo delle unita di esecuzione (se il compilatore "vede" che non riesce a parallelizzare a sufficienza, seleziona un singolo core fisico, lasciando più risorse per eseguire altri thread/processi).

Poi l'implementazione dei core fisici può essere n-way, in-order o out-of-order, in base a cosa è più importante per un certo tipo di cpu, SoC o macrocella.

Mi sembra decisamente più versatile rispetto a VLIW ed EPIC e con molto più margine di crescita rispetto ad un "classico" sistema multicore out-of-order.

[cdimauro]

EDGE può cercare di spremere il massimo che un compilatore possa fare, ma rimangono i limiti dei compilatori, che non possono prevedere tutto, per l'appunto.

Alla fine mi sono fatto la seguente, personalissima nonché banale, idea: l'esecuzione out-of-order non esisterebbe se i compilatori fossero in grado di farsi carico di tutto il lavoro di ottimizzazione & schedulazione delle istruzioni.

Per questo dubito che EDGE possa trarre vantaggio dall'uso di eventuali core out-of-order: come fai a "parallelizzare" a compile time raggruppando istruzioni tenendo conto che poi queste istruzioni potrebbero avere problemi in esecuzione?

Il lavoro di EDGE, peraltro, riescono già a farlo degli ottimi compilatori, se si tratta di (auto)vettorizzare il codice e/o di distribuire il carico di lavoro su più core.

Se vantaggio c'è in questa nuova architettura, continua a essere difficile notarlo in ambito più general purpose.