Link alla notizia: https://www.hwupgrade.it/news/cpu/la-startup-finlandese-flow-computing-vuole-migliorare-le-prestazioni-delle-cpu-di-100-volte-con-la-ppu_127975.html

La CPU è l'anello debole delle prestazioni dei PC e server moderni: la startup finlandese Flow Computing ha progettato la PPU, una soluzione integrabile nel die delle CPU che, gestendo in parallelo i task, consente di ottenere miglioramenti prestazionali senza precedenti.

Click sul link per visualizzare la notizia.

Se non sono supercaz* e Keller (Tenstorrent) ci crede allora speriamo arrivino presto sul mercato.

Manca solo che inverta l'entropia e poi la lista e' completa...

..consente di ottenere miglioramenti prestazionali senza precedenti.
Quanto di più?
Almeno il doppio!
https://64.media.tumblr.com/562a452e3c068b37109807a661472ddc/tumblr_o9g9krXgYE1qz6z2wo1_400.gifv

Un po' la stessa cosa che sta facendo Keller con i risc-V,difatti sta puntando a una semplificazione e a una parallelizzazione molto importante.
Se fossi AMD,prenderei la palla al balzo, è la azienda che se perde un treno, è un vero bagno di sangue,non è Intel ne Nvidia che hanno le spalle molto ma molto grosse.

".. lavora a un progetto per un core PPU e a un compilatore che vuole concedere in licenza ad altre aziende"

Per me puzza parecchio.. che se ne fanno di un compilatore se "La PPU, inoltre, è completamente retrocompatibile, ovvero permette di migliorare fino a 2 volte le prestazioni con gli applicativi vecchi e attuali, anche senza ricompilazione."

Io gli auguro ogni bene comunque, anche se tutto è abbastanza fumoso.

Anche a me puzza parecchio. Anche perchè, anche se e' vero che la programmazione delle CPU e' seriale, le moderne CPU usano gia' tutti una serie di trucchi paralleli per velocizzare l'esecuzione (es. esecuzione speculativa).

E vale sempre la regola

"Extraordinary claims require extraordinary evidence"

Magari hanno integrato il memory manager del kernel in hardware :sofico:
Quello sì che darebbe una bella spinta!

Oggi l'erba era buona

non me ne intendo, per cui rimango sull'esempio dello chef.. dato che ha sempre due mani, anche se trovi il modo di fargli arrivare più roba o sgravarlo da compiti inutili, quanto mai potrà velocizzare? Sicuramente non come 100 chef..

Anche a me puzza parecchio. Anche perchè, anche se e' vero che la programmazione delle CPU e' seriale, le moderne CPU usano gia' tutti una serie di trucchi paralleli per velocizzare l'esecuzione (es. esecuzione speculativa).

E vale sempre la regola

"Extraordinary claims require extraordinary evidence"

scusami, ma quando un dato viene elaborato questo non dovrebbe essere riscritto in ram a e sua conclusione?
Quando quello stesso dato deve essere elaborato in sequenza da un altro th deve essere ricaricato.
Se questo sistema mantiene sincronizzati i dati in ram e cache gestendoli in background ed in modo trasparente per i th i tempi saranno per forza di cosa ridotti.
Seguendo l'esempio del cuoco per ogni singolo ingrediente o spezia questo deve andare in dispensa a prenderlo ( restando inattivo per il tempo necessario al tragitto) mentre con un aiutante che lo segue scrupolosamente questi saranno mediamente disponibili prima evitando diverse perdite di tempo.
Attenzione questo dovrebbe accadere solo per le elaborazioni sequenziali, ma probabilmente quelle casuali subiranno un overhead.

Doppio

scusami, ma quando un dato viene elaborato questo non dovrebbe essere riscritto in ram a e sua conclusione?
Quando quello stesso dato deve essere elaborato in sequenza da un altro th deve essere ricaricato.
Se questo sistema mantiene sincronizzati i dati in ram e cache gestendoli in background ed in modo trasparente per i th i tempi saranno per forza di cosa ridotti.
Seguendo l'esempio del cuoco per ogni singolo ingrediente o spezia questo deve andare in dispensa a prenderlo ( restando inattivo per il tempo necessario al tragitto) mentre con un aiutante che lo segue scrupolosamente questi saranno mediamente disponibili prima evitando diverse perdite di tempo.
Attenzione questo dovrebbe accadere solo per le elaborazioni sequenziali, ma probabilmente quelle casuali subiranno un overhead.

Quello che volevo scrivere e' che questi 'aiutanti' esistono già nelle CPU moderne da molto tempo. Addirittura, per velocizzare l'esecuzione, esistono 'aiutanti' che fanno operazioni potenzialmente utili che possono servire o no a seconda di quello che poi effettivamente serve 'al cuoco' in un secondo momento.

Quindi, come messa nell'articolo e da ignorante del settore, non mi sembra chissa' quale novità concettuale. Bisogna vedere cosa verrebbe effettivamente implementato per capire se e' qualcosa che funziona o no.

Resta il fatto che una soluzione a "bacchetta magica" che permette miglioramenti di N volte su qualsiasi microarchitettura presente e futura sa molto di "Tubo di Tucker" su silicio.

Quello che volevo scrivere e' che questi 'aiutanti' esistono già nelle CPU moderne da molto tempo. Addirittura, per velocizzare l'esecuzione, esistono 'aiutanti' che fanno operazioni potenzialmente utili che possono servire o no a seconda di quello che poi effettivamente serve 'al cuoco' in un secondo momento.

Quindi, come messa nell'articolo e da ignorante del settore, non mi sembra chissa' quale novità concettuale. Bisogna vedere cosa verrebbe effettivamente implementato per capire se e' qualcosa che funziona o no.

Resta il fatto che una soluzione a "bacchetta magica" che permette miglioramenti di N volte su qualsiasi microarchitettura presente e futura sa molto di "Tubo di Tucker" su silicio.

La predizione dei salti ( o prefech ) non viene applicata nelle operazioni sequenziali ma serve a riempire il vuoto temporale che intercorre tra la scrittura del dato in ram a seguito di un operazione e la sua successiva lettura.
Il data prefech non può essere utilizzato perché il risultato non è ancora disponibile in ram.
Questa ppu dovrebbe teoricamente mappare una partizione di memoria immaginaria che funziona come la cache dei controller raid dove la CPU crede di aver scritto il dato sul disco mentre in realtà questo viene scritto in differita ma re dondolo allo stesso momento subito disponibile in lettura.
Ripeto questo vantaggio avviene solo con operazioni sequenziali sullo stesso dato di partenza da parte di più thread ed ha impatto nullo sui salti causali.
Immagina che sulla stessa tela devono dipingere in sequenza più pittori con colori diversi.
Ad oggi ogni pittore ( thread) va a prendere la tela in deposito (ram), usa i suoi colori e la riporta in deposito.
Il secondo pittore aspetta che la tela sia disponibile in deposito e poi la va a prendere.
Con questo sistema il pittore usa il fattorino ppu invece che il suo, che lo preleva dal primo pittore ed invece di portarlo in deposito ( ram) lo porge direttamente al secondo scrittore aggiornando solo il registro del deposito stesso.

La predizione dei salti ( o prefech ) non viene applicata nelle operazioni sequenziali ma serve a riempire il vuoto temporale che intercorre tra la scrittura del dato in ram a seguito di un operazione e la sua successiva lettura.
Il data prefech non può essere utilizzato perché il risultato non è ancora disponibile in ram.
Questa ppu dovrebbe teoricamente mappare una partizione di memoria immaginaria che funziona come la cache dei controller raid dove la CPU crede di aver scritto il dato sul disco mentre in realtà questo viene scritto in differita ma re dondolo allo stesso momento subito disponibile in lettura.
Ripeto questo vantaggio avviene solo con operazioni sequenziali sullo stesso dato di partenza da parte di più thread ed ha impatto nullo sui salti causali.
Immagina che sulla stessa tela devono dipingere in sequenza più pittori con colori diversi.
Ad oggi ogni pittore ( thread) va a prendere la tela in deposito (ram), usa i suoi colori e la riporta in deposito.
Il secondo pittore aspetta che la tela sia disponibile in deposito e poi la va a prendere.
Con questo sistema il pittore usa il fattorino ppu invece che il suo, che lo preleva dal primo pittore ed invece di portarlo in deposito ( ram) lo porge direttamente al secondo scrittore aggiornando solo il registro del deposito stesso.

Continuo a non essere convinto.

Non mi sembra tu stia descrivendo un meccanismo differente dal funzionamento di una normale cache L2(quando condivisa)/L3/L4

Comunque il branch prediction non e' l'unica tecnica di esecuzione speculativa..

https://en.m.wikipedia.org/wiki/Speculative_execution

Continuo a non essere convinto.

Non mi sembra tu stia descrivendo un meccanismo differente dal funzionamento di una normale cache L2(quando condivisa)/L3/L4

Comunque il branch prediction non e' l'unica tecnica di esecuzione speculativa..

https://en.m.wikipedia.org/wiki/Speculative_execution

Tutte le ottimizzazioni partono hanno come assunto imprescindinbile che il dato sia gia presente in ram.
Nelle operazioni sequenziali questo è impossibile perchè il dato da eleborare è il risultato di un'operazione in corso, quindi non presente in ram.
Questo sistema dovrebbe ottimizzare ( ed uso il condizionale) soltando in questi casi.
Tornando all'esempio dei pittori:
Io uso il rosso sulla tela ed il risultato è una tela bianca con delle parti rosse.
Tu devi usare il verde, ma solo nelle aree bianche non coperte dal rosso.
Come puoi applicare il tuo colore se non hai il mio lavoro gia pronto?
Non puoi inventarti nulla e nemmeno precaricarica la tela in cache dato che questa esiste in ram solo nella versione completamente bianca.
Ti tocca aspettare che io finisca il mio lavoro e poi riconsegno la tela in ram dove tu poi devi andare a prendere la tela da me lavorata e portartela sul tuo cavalletto.
Questo sistema dovrebbe limitare i tempi di scrittura e lettura di quel dato in ram, passando la tela direttamente a te e garantendo al tempo stesso la coerenza dei dati.

Tutte le ottimizzazioni partono hanno come assunto imprescindinbile che il dato sia gia presente in ram.
Nelle operazioni sequenziali questo è impossibile perchè il dato da eleborare è il risultato di un'operazione in corso, quindi non presente in ram.
Questo sistema dovrebbe ottimizzare ( ed uso il condizionale) soltando in questi casi.
Tornando all'esempio dei pittori:
Io uso il rosso sulla tela ed il risultato è una tela bianca con delle parti rosse.
Tu devi usare il verde, ma solo nelle aree bianche non coperte dal rosso.
Come puoi applicare il tuo colore se non hai il mio lavoro gia pronto?
Non puoi inventarti nulla e nemmeno precaricarica la tela in cache dato che questa esiste in ram solo nella versione completamente bianca.
Ti tocca aspettare che io finisca il mio lavoro e poi riconsegno la tela in ram dove tu poi devi andare a prendere la tela da me lavorata e portartela sul tuo cavalletto.
Questo sistema dovrebbe limitare i tempi di scrittura e lettura di quel dato in ram, passando la tela direttamente a te e garantendo al tempo stesso la coerenza dei dati.

Ho capito l'esempio ma continuo a non cogliere la differenza da una cache L3.:stordita:

Già adesso, da quel che so, non scrivi mai 'direttamente' sulla ram ma sulla cache per questo motivo. E carichi dalla ram solo se la linea era stata precedentemente 'sfrattata' (evicted)

Ho capito l'esempio ma continuo a non cogliere la differenza da una cache L3.:stordita:

Già adesso, da quel che so, non scrivi mai 'direttamente' sulla ram ma sulla cache per questo motivo. E carichi dalla ram solo se la linea era stata precedentemente 'sfrattata' (evicted)

Non proprio, lo store in cache serve per eseguire la scrittura in ram in background, ma in fase di accesso ai dati il dato tra ram e cache deve essere coerente altrimenti ti ritroveresti un cache miss anche se non reale.
L'uso del dato store in cache viene usato ( per quel poco che ne so) soltando se è il medesimo th che lo ha parcheggiato ad accedervi, ma se è un th diverso questo chiede alla cu il dato che verifica se il dato in ram è presente in cache e se questo è in suspend to write deve aspettare che il dato vengo sincronizzato per garantirne la coerenza ( e questo dovrebbe avvenire per tutte le architetture OoO mentre per quelle InO potrebbe esserci qualche ottimizzazione).

Segnalo che le cpu consumer eseguono calcoli in parallelo senza PPU di stok@zzo da 30 anni.

A me PPU ricorda tanto Ageia e le sue schede PhysX, prima dell'acquisizione da parte di nVidia

Non proprio, lo store in cache serve per eseguire la scrittura in ram in background, ma in fase di accesso ai dati il dato tra ram e cache deve essere coerente altrimenti ti ritroveresti un cache miss anche se non reale.
L'uso del dato store in cache viene usato ( per quel poco che ne so) soltando se è il medesimo th che lo ha parcheggiato ad accedervi, ma se è un th diverso questo chiede alla cu il dato che verifica se il dato in ram è presente in cache e se questo è in suspend to write deve aspettare che il dato vengo sincronizzato per garantirne la coerenza ( e questo dovrebbe avvenire per tutte le architetture OoO mentre per quelle InO potrebbe esserci qualche ottimizzazione).


Però, da quel che so, quello che descrivi e' necessario solo per sincronizzare lo stato della cache locale di ogni core (L1/L2). La cache L3 e' invece globale e condivisa tra tutti I core di un multiprocessore. Quindi quando scrivi sulla L3 le modifiche sono immediatamente visibili a tutti i core e funziona esattamente come la cache del controller RAID che hai citato nel tuo precedente messaggio.

https://images.anandtech.com/reviews/cpu/amd/barcelona/cache.gif

http://www.nic.uoregon.edu/~khuck/ts/acumem-report/manual_html/ch_intro_coherence.html

E anche se leggi Wiki, i problemi di coerenza ci sono solo quando hai cache, e quindi copie, locali. Quando hai una memoria globale il problema non si pone.

https://en.m.wikipedia.org/wiki/Cache_coherence

Però, da quel che so, quello che descrivi e' necessario solo per la cache locale di ogni core (L1/L2). La cache L3 e' invece globale e condivisa tra tutti I core di un multiprocessore. Quindi quando scrivi sulla L3 le modifiche sono immediatamente visibili a tutti i core e funziona esattamente come la cache del controller RAID che hai citato nel tuo precedente messaggio.

https://images.anandtech.com/reviews/cpu/amd/barcelona/cache.gif

http://www.nic.uoregon.edu/~khuck/ts/acumem-report/manual_html/ch_intro_coherence.html

E anche se leggi Wiki, i problemi di coerenza ci sono solo quando hai cache, e quindi copie, locali. Quando hai una memoria globale il problema non si pone.

https://en.m.wikipedia.org/wiki/Cache_coherence

Sarò io scarso ma mi sembra che tu stai portando esempi di variabili, mentre io parlo di risultato:
Quando più th accedono alla stessa variabile questa segue la coerenza in cache ( quando possibile) mentre il mio esempio:
Tela bianca-tela bianco-rossa tela bianco-rossa-verde, sono tre dati diversi ( che oltre ad avere indirizzi di memoria diversi hanno dimensioni diverse e sono a tutti gli effetti entità diverse) che non possono essere condivise in cache perchè proprio non esistono fino alla loro elaborazione.
La tela bianco-rossa non esiste in cache fino alla sua creazione e questa non è presente nemmeno nella tabella degli indirizzi dei vari core.
Non si può condividere una cosa che non esiste.
Nel mio esempio se il secondo th deve lavorare sulla tela bianco-rossa come fa a mapparla se non esiste?
Se fosse come dici ( tela bianca tela bianco-rossa tela bianco-rossa-verde ) devono essere variabili di volta in volta modificate dai vari th e non il risultato di un elaborazione.
Per capirci meglio:
Due rami di pittori uno con i colori A e B, l'altro con i colori C e D
Entrambi caricano la tela Bianca X ( che non è una variabile)
Quando il ramo 1 va a creare il dato 1XA non va ad aggiornare il dato in cache, ma ne crea uno nuovo che va scritto in ram in modo che il pittore successivo parte dalla tela 1XA e non dalla tela X e nemmeno dalla tela 2XC.
Ma fintanto che 1XA o 2XC non vengono creati e scritti in ram questi dati non esistono perchè esiste solo l'entità X che non è una variabile.

Sarò io scarso ma mi sembra che tu stai portando esempi di variabili, mentre io parlo di risultato:
Quando più th accedono alla stessa variabile questa segue la coerenza in cache ( quando possibile) mentre il mio esempio:
Tela bianca-tela bianco-rossa tela bianco-rossa-verde, sono tre dati diversi ( che oltre ad avere indirizzi di memoria diversi hanno dimensioni diverse e sono a tutti gli effetti entità diverse) che non possono essere condivise in cache perchè proprio non esistono fino alla loro elaborazione.
La tela bianco-rossa non esiste in cache fino alla sua creazione e questa non è presente nemmeno nella tabella degli indirizzi dei vari core.
Non si può condividere una cosa che non esiste.
Nel mio esempio se il secondo th deve lavorare sulla tela bianco-rossa come fa a mapparla se non esiste?
Se fosse come dici ( tela bianca tela bianco-rossa tela bianco-rossa-verde ) devono essere variabili di volta in volta modificate dai vari th e non il risultato di un elaborazione.
Per capirci meglio:
Due rami di pittori uno con i colori A e B, l'altro con i colori C e D
Entrambi caricano la tela Bianca X ( che non è una variabile)
Quando il ramo 1 va a creare il dato 1XA non va ad aggiornare il dato in cache, ma ne crea uno nuovo che va scritto in ram in modo che il pittore successivo parte dalla tela 1XA e non dalla tela X e nemmeno dalla tela 2XC.
Ma fintanto che 1XA o 2XC non vengono creati e scritti in ram questi dati non esistono perchè esiste solo l'entità X che non è una variabile.

Sostituisci nel tuo discorso 'ram' con 'L3' e 'cache' con 'L1/L2' hai lo stesso identico risultato.


Quando il ramo 1 va a creare il dato 1XA non va ad aggiornare il dato in L1/L2, ma ne crea uno nuovo che va scritto in L3 in modo che il pittore successivo parte dalla tela 1XA e non dalla tela X e nemmeno dalla tela 2XC.
Ma fintanto che 1XA o 2XC non vengono creati e scritti in L3 questi dati non esistono perchè esiste solo l'entità X che non è una variabile.



Comunque nel link che ho fornito sopra e' scritto abbastanza bene come funziona la sincronizzazione della cache in un sistema multicore.. (MESI)

EDIT

Addirittura, teoricamente, se il programma potesse essere contenuto interamente in L3, non sarebbe neanche necessario scrivere o leggere dalla ram. Ed uno dei motivi per cui processori moderni da decine/centinaia di cores hanno anche L3 gigantesche e' che, se non l'avessero, I tempi di sincronizzazione con la ram renderebbe inutile avere cosí tante unità di lavoro in molti tipi di carico.

(sentitevi liberi di fustigarmi :D )

Sostituisci nel tuo discorso 'ram' con 'L3' e 'cache' con 'L1/L2' hai lo stesso identico risultato.




Comunque nel link che ho fornito sopra e' scritto abbastanza bene come funziona la sincronizzazione della cache in un sistema multicore.. (MESI)

EDIT

Addirittura, teoricamente, se il programma potesse essere contenuto in L3, non sarebbe neanche necessario scrivere o leggere dalla ram. Ed e' questo anche il motivo per cui processori moderni da decine/centinaia di cores hanno anche L3 gigantesche. Se non l'avessero la sincronizzazione con la ram renderebbe inutile avere cosí tante unità di lavoro in molti tipi di carico.
L'articolo parla di dati elaborati in sequenza :
A che crea B ( ma continua ad esistere A) B che diventa C ( ma continuano ad esistere A e B) ecc.
Non stiamo parlando di una variabile X ( e tale variabile può essere T + tela più recente) che viene applicata come filtro ad un file ( e la variabile X per quanto possa sembrare assurda è fissa in cache e aggiornata di volta in volta)

Anche a me puzza parecchio.

Aggiungici che io PPU non riesco a non leggerla come la PuPU' :asd:
la cosa puzza ancora di più :D

L'articolo parla di dati elaborati in sequenza :
A che crea B ( ma continua ad esistere A) B che diventa C ( ma continuano ad esistere A e B) ecc.
Non stiamo parlando di una variabile X ( e tale variabile può essere T + tela più recente) che viene applicata come filtro ad un file ( e la variabile X per quanto possa sembrare assurda è fissa in cache e aggiornata di volta in volta)

Ok, ma non cambia il discorso. Quando I dati A, B, C (stato della memoria) vengono elaborati in sequenza, da diversi core o meno, devono comunque essere assegnati ad una variable(indirizzo memoria). Che sia la stessa variabile o 3 distinte non cambia. La sincronizzazione di questa/e puo' essere fatta tra i diversi core che necessitano di tali variabili 'con stato aggiornato' attraverso la cache globale L3 e non necessariamente attraverso la ram.

Poi sono possibili alcuni trucchi andando a usare direttamente I registri dell'unità di elaborazione o con istruzioni apposite. Ma non e' roba nuova e non e' a costo 0.

Aggiungici che io PPU non riesco a non leggerla come la PuPU' :asd:
la cosa puzza ancora di più :D


Nel futuri se non avrai almeno 16 PuPU nel PC, non potrai far girare crysis 4000 in 32 K :D

Ok, ma non cambia il discorso. Quando I dati A, B, C (stato della memoria) vengono elaborati in sequenza, da diversi core o meno, devono comunque essere assegnati ad una variable(indirizzo memoria). Che sia la stessa variabile o 3 distinte non cambia. La sincronizzazione di questa/e puo' essere fatta tra i diversi core che necessitano di tali variabili 'con stato aggiornato' attraverso la cache globale L3 e non necessariamente attraverso la ram.

Poi sono possibili alcuni trucchi andando a usare direttamente I registri dell'unità di elaborazione o con istruzioni apposite. Ma non e' roba nuova e non e' a costo 0.


Non è riferito ai th di uno stesso processo quello che dico, ma da più processo con ognuno di essi una specifica parte di memoria ( ram cache) allocata ed isolata, dove th di processi separati non possono e devono in alcun modo accedere. Il risultato del processo poi dei essere scritto in memoria e caricato dal processo successivo ( a prescindere da quanti th è composto il singolo processo e da quali e quantii core siano essi elaborati)


Nel futuri se non avrai almeno 16 PuPU nel PC, non potrai far girare crysis 4000 in 32 K :D

Giustamente potrebbe essere tutta una bischerata ( a mo di tucker per intenderci) ma non credo che investitori di un certo calibro si facciano fregare come un comune cittadino ignaro dell'argomento.
Se le trattative con i nome dell'articolo sono reali un fondo di realtà ci deve essere, non credo che Keller ( e le centinaia di ingegneri delle altre realtà citate) ne sappiano di architettura dei processori come la massaia di Voghera.