La startup finlandese Flow Computing vuole migliorare le prestazioni delle CPU di 100 volte con la PPU

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/la...pu_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.

[io78bis]

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

[jepessen]

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

[omerook]

..consente di ottenere miglioramenti prestazionali senza precedenti.
Quanto di più?
Almeno il doppio!

[supertigrotto]

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.

[DarIOTheOriginal]

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

[ZeroSievert]

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"

[erupter]

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

[agonauta78]

Oggi l'erba era buona

[Opteranium]

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

[Piedone1113]

Originariamente inviato da ZeroSievert

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.

[ZeroSievert]

Doppio

[ZeroSievert]

Originariamente inviato da Piedone1113

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.

[Piedone1113]

Originariamente inviato da ZeroSievert

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.

[ZeroSievert]

Originariamente inviato da Piedone1113

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

[Piedone1113]

Originariamente inviato da ZeroSievert

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.

[ZeroSievert]

Originariamente inviato da Piedone1113

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.

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)

[Piedone1113]

Originariamente inviato da ZeroSievert

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

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

[+Benito+]

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

[fukka75]

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