[cdimauro]

Originariamente inviato da LMCH

L'IPC dipende principalmente dall' implementazione del core, non dal set d'istruzioni, ne dall'architettura logica visibile al programmatore.

Anche l'ISA conta, e non poco. Non foss'altro perché l'implementazione dipende, ovviamente, da essa.

Paradossalmente, per quel che riguarda il set d'istruzioni, gli ARM si presterebbero a soluzioni con un IPC più elevato di quello ottenibile con gli x86.

Per quale motivo dovrebbe essere così?

Quindi al massimo puoi dire "per ora le implementazioniARM come IPC sono inferiori a quelle X86".

Questo è normale, al momento la situazione è quella e potrebbe anche cambiare in futuro, ma segnali di cambiamento non se ne vedono.

Per ottenere un IPC più elevato Intel ha di fatto esaurito tutti i metodi disponibili

E' senz'altro vero che sia difficile pensare a balzi notevoli sul fronte del calcolo "general purpose", ma come fai a escludere a priori che non possa saltare fuori qualche idea per innovare (e migliorare le prestazioni, ovviamente) qualche particolare aspetto dell'implementazione dell'ISA? Le innovazioni non sono certo mancate finora...

(per questo ora puntano molto su nuove estensioni al set d'istruzioni).

Veramente lo fa da più di 20 anni ormai, e per ottime ragioni: mentre è difficile spingere le prestazioni single-thread per il codice general purpose, per quello parallelo una soluzione economica a livello implementativo, e che si presta a essere molto scalabile, è l'approccio SIMD.

Per questo sono nate tante estensioni, e altre ancora arriveranno, con contributi che non sono legati soltanto all'aumento della dimensione dei registri o all'aggiunta di nuove istruzioni.

In quest'ambito i RISC hanno parecchi problemi dovuti all'opcode di dimensione fissa (32 bit, in genere), per cui sono costretti a limitare l'instruction set e alle funzionalità impacchettate nelle istruzioni.

Al contrario i CISC, potendo contare su istruzioni di lunghezza variabile, possono mettere a disposizione funzionalità più interessanti / ricche, che ovviamente incidono positivamente sulle prestazioni.

Le architetture ARM sul mercato invece non sono così "spinte" perchè certe cose richiedono consumi più elevati o superficie del chip più ampia che non sono accettabili su SoC per smartphone e tablet.

E' anche vero che i processi produttivi sempre migliori hanno consentito di impaccare molti più transistor a parità di superficie, riducendo anche i consumi. L'A7 di Apple conta 1 miliardo di transistor (anche se bisogna tenere presente pure la GPU), e ha "appena" due core.

Con numeri così elevati in gioco anche la "x86 tax" non ha più un peso così rilevante nel computo della dimensione del die e nei consumi.

Senza dimenticare che pure ARM si porta dietro la sua "tax", che consiste nelle diverse ISA che deve supportare, non ultima quella a 64-bit che presenta un'opcode table e una struttura delle istruzioni molto diversa da quella tradizionale. Anche questo ha un costo; non elevato come nel caso di Intel, ma che incide sia nel numero di transistor che nell'implementazione della pipeline.

Ovviamente se qualcuno deciderà di produrre cpu ARM con gli stessi consumi ed area su chip di cpu x86 "per desktop/server" le cose potrebbero cambiare drasticamente.

Bisogna vedere gli obiettivi che ci pone. Consumi e/o area del chip non sono gli unici parametri importanti per misurare la "bontà" di un'architettura.