Grazie. I miglioramenti ci sarebbero, perché sarebbe possibile ridurre gli accessi alla memoria, quindi diminuendo le load e/o store. Non è un caso che ARM, con la sua nuova ISA a 64 bit (ARM64 aka ARMv8), abbia provveduto a estendere i registri dai 16 (in realtà 15, perché uno era il PC) a 30/31 (ci sono alcuni registri che hanno un utilizzo speciale).
Ma non credo che assisteremmo a risultati eccezionali. Un po’ come AMD, che introducendo x64 ha raddoppiato i registri e migliorato le prestazioni mediamente del 10-15%. Al solito, dipende dal codice, ma penso che ne gioverebbero di più i server, ed è soprattutto per questo che ARM ha tirato fuori ARM64.
Comunque raddoppiare il numero di registri di x64 (x86 è stato già esteso da questa) portandoli a 32 introdurrebbe altri problemi non di poco conto.
Il primo è che, ovviamente, la nuova architettura (perché tale diventa alla fine, sebbene le istruzioni vengano sostanzialmente riciclate) romperebbe la compatibilità col passato, richiedendo codice appositamente generato, compilatori e kernel dei s.o. ad hoc per supportarla correttamente.
Il secondo riguarda la densità del codice, che diminuirebbe ulteriormente. Abbiamo visto con x64 che abbiamo mediamente il 34% di spazio in più occupato. Nella migliore delle ipotesi dovremmo introdurre un prefisso lungo due byte (il secondo byte conterrebbe il bit di size a 64 bit, un bit per il quarto registro delle estensioni SIMD AVX, e poi 3 coppie di bit per ognuno dei 3 possibili registri utilizzabili) per accedere ai nuovi 16 registri (fino ai primi 16 registri si potrebbe continuare a usare il prefisso REX, mentre fino ai primi 8 non servirebbe nemmeno questo), e ciò risulterebbe abbastanza penalizzante. Già adesso abbiamo una lunghezza media di 4,3 byte per istruzione rispetto a x86 (che vanta 3,2 byte di media), per cui il panorama è destinato a peggiorare; anche supponendo che, ad esempio, mediamente si aggiunga soltanto 1/4 di byte in media, avremmo 4,55 byte di media per le istruzioni, cioè il 42% in più rispetto a x86.
Aumentare la dimensione del codice significa mettere più pressione alla memoria, alla cache, e anche alle entry della TLB, oltre al fatto che i decoder troverebbero meno istruzioni da decodifica.
Quindi tutto ciò porta ad avere prestazioni leggermente minori, anche se controbilanciate e in saldo positivo per il fatto di poter disporre del doppio di registri (in particolare per l’unità SIMD, che è quella che ne gioverebbe di più).
E’ una situazione abbastanza complessa, come vedi, e il problema sta tutto nel fatto che parliamo sempre dell’architettura x86 (e x64), che si porta uno schema di codifica decisamente contorto.Con una codifica (e quindi ISA) nuova di pacca, tanti di questi problemi si potrebbero, invece, risolvere, pur ottenendo codice con densità molto più elevata rispetto a x64 (e comparabile a x86). Ma di questo magari ne riparleremo in futuro, se si presenterà l’occasione.