Quote:
Originariamente inviato da avvelenato
la soluzione intel ti propone di scegliere tra rifare da zero il software, con un notevole guadagno prestazionale, oppure semplicemente ricompilarlo e lasciare l'onere dell'ottimizzazione al compilatore: potrebbe anche non essere efficiente come un'ottimizzazione fatta da esseri umani, ma ne ricaverebbe comunque un boost prestazionale, e tutto questo risparmiando soldi e tempi di messa in esercizio (quindi altri soldi).
Questa flessibilità potrebbe far gola a molte aziende quando si tratterà di scegliere tra mic e gpgpu.
|
Già, la soluzione MIC di Intel nella sostanza è un set d'istruzioni incompatibile con quello degli x86 attuali ma che permette di ricompilare abbastanza agevolmente il codice x86 su di essa e di portare i vari S.O. su di essa abbastanza agevolmente.
Il core x86 "di base" è lo stesso, ma quello che erano le SSE "non c'è più" (sono state sostituite dalle istruzioni della "nuova" VPU).
Visto che le parti che contengono istruzioni SSE o le ha generate automaticamente il compilatore oppure sono spezzoni di codice "piccoli" relativamente facili da riscrivere (e spesso con un fallback su codice x86 oppure C/C++ per supportare i vecchi x86 che non avevano le SSE), la cosa è sensata.
Intel potrà proporre i chip su architettura MIC sia per macchine "multicore" tipo server che per architetture HPC in cui le prestazioni aggiuntive dovute alle VPU dei core si faranno sentire di più (avrà quindi anche maggiori economie di scala rispetto ai concorrenti).
L'unica cosa che potrebbe scombinare le carte ad Intel sarebbe qualche sviluppo (es: le interconnessioni ottiche on-chip) che renderesse più efficienti soluzioni basate su molti più "mini-core" (senza VPU e con cache più piccole).
Uno dei motivi per cui MIC o cpugpu hanno senso è che con le tecnologie attuali molti più core "più piccoli" non possono essere sfruttati a dovere a causa dei limiti di banda sulle interconnessioni tra core e core e tra i core e la memoria esterna, ma se le cose cambiassero ...