Quote:
Originariamente inviato da paolo.oliva2
Da quel che ho capito, le falle hanno trovato terreno fertile nel modo in cui Intel ha cercato di velocizzare la ricerca/trasferimento dei dati da elaborare.
I fix adottano dei work-around, ed è ovvio che la perdita prestazionale ci sia
visto che i circuiti erano progettati per lavorare in modo differente.
Mi fa strano che inserendo dei controlli (o quanto meno un modo differente di lavoro) si possa ottenere la stessa prestazione degli stessi senza FIX.
|
La questione è semplice. Tutti i processori fanno branch prediction / speculative execution. Intel ha toppato nell'implementazione in hw di suddetti algoritmi, perché si è spinta troppo oltre a scapito della sicurezza dei dati.
Hanno messo una toppa sia lato hw sia con il microcode ma sono mitigation, non hanno risolto a livello di architettura.
Se ricordo bene, le patch microcode per mitigare spectre e meltdown tagliavano le prestazioni del 20% quando il workload simulato era quello di un DB (caso peggiore possibile).
Se intel tira fuori una nuova uArch pensata concettualmente in modo differente, in teoria potrebbe già recuperare diversi punti %.
Il problema è che ci sono tante variabili in gioco. Magari Intel ha già un'ottima uArch, ma le fonderie non ci stan dietro. O, magari, le fonderie sono già a livello di TSMC, ma la uArch nuova non è ancora all'altezza delle aspettative.
Sarebbe bello poter analizzare le perf di una cpu intel prodotta su wafer di TSMC e/o una cpu amd prodotta con i macchinari intel.
