Larrabee Versus GPU
- Pagina 1 : Larrabee, analisi tecnica: un mostro, almeno su carta
- Pagina 2 : Un atteso ritorno
- Pagina 3 : In generale
- Pagina 4 : x86: la scelta giusta?
- Pagina 5 : Nel dettaglio: unità scalare e SMT
- Pagina 6 : L’unità vettore e il nuovo set di istruzioni
- Pagina 7 : Vector Unit e Mask Register
- Pagina 8 : Le unità texture
- Pagina 9 : Larrabee Versus Cell
- Pagina 10 : Larrabee Versus GPU
- Pagina 11 : Larrabee contro se stesso?
Larrabee Versus GPU
Come abbiamo detto, Larrabee non assomiglia molto a una GPU, eccezione fatta per le unità di texture. Non c’è segno di altre unità fisse che solitamente si ritrovano, come un motore che converte i triangoli in pixel, e interpola i differenti attributi dei vertici, o le ROP, che scrivono pixel sul frame buffer e gestiscono l’anti-aliasing e ogni operazione di blending.
Nel caso di Larrabee, tutte queste operazioni sono effettuate direttamente dai core. Il vantaggio di questo approccio è la flessibilità. Con il blending, per esempio, è possibile gestire la trasparenza indipendentemente dall’ordine in cui si inviano le informazioni di base, cosa molto complicata per una GPU moderna.
Il risvolto della medaglia è che Intel deve conferire alla sua GPU una potenza di calcolo maggiore rispetto ai suoi concorrenti, che invece possono usare unità dedicate per i vari tipi di task, lasciando le unità programmabili concentrate sullo shading.
Anche se le GPU sono diventate molto flessibili dall’arrivo delle Direct3D, rimangono lontane dalla flessibilità che Larrabee può offrire. Una delle più grandi limitazioni delle GPU, anche usando API come CUDA, è l’accesso alla memoria. Come per il Cell, la gestione della memoria è abbastanza limitata, e per ottenere il massimo, il numero di registri usati deve essere minimizzato e devono essere impiegate piccole zone di memoria, di pochi kilobyte.
Nonostante la flessibilità guadagnata dalle GPU, le loro funzionalità sono rimaste orientate al calcolo grezzo. Per esempio, non c’è modo di effettuare operazioni di I/O con una GPU. Al contrario, Larrabee è totalmente in grado di farlo, poiché può effettuare direttamente printf o operazioni di file-handling. È anche possibile usare funzioni ricorsive e virtuali, impossibili per una GPU.
Ovviamente, tutte queste funzionalità hanno un costo, e ci saranno necessariamente impatti sull’efficienza dei programmi, poiché andranno contro il paradigma del parallel programming ; rimane comunque accettabile per il codice che non viene usato in aree sensibili alle prestazioni. Creando questo tipo di codice, senza usare la CPU, ci sono interessanti possibilità. Per esempio, le moderne GPU includono un compilatore just in time (JIT) per adattare le shader a specifici dettagli della loro architettura in base al task. Larrabee non fa eccezione a questa regola, ma anziché usare un compilatore gestito dal processore, lo integra direttamente.
Un’altra interessante opportunità è che il codice può essere debuggato direttamente su Larrabee, mentre nel caso di CUDA è necessario ricorrere ad un’emulazione tramite la CPU, che simula la GPU, ma senza ottenere un risultato del tutto preciso, quindi alcuni bug possono sfuggire all’analisi.
- Pagina 1 : Larrabee, analisi tecnica: un mostro, almeno su carta
- Pagina 2 : Un atteso ritorno
- Pagina 3 : In generale
- Pagina 4 : x86: la scelta giusta?
- Pagina 5 : Nel dettaglio: unità scalare e SMT
- Pagina 6 : L’unità vettore e il nuovo set di istruzioni
- Pagina 7 : Vector Unit e Mask Register
- Pagina 8 : Le unità texture
- Pagina 9 : Larrabee Versus Cell
- Pagina 10 : Larrabee Versus GPU
- Pagina 11 : Larrabee contro se stesso?
Indice
- 1 . Larrabee, analisi tecnica: un mostro, almeno su carta
- 2 . Un atteso ritorno
- 3 . In generale
- 4 . x86: la scelta giusta?
- 5 . Nel dettaglio: unità scalare e SMT
- 6 . L’unità vettore e il nuovo set di istruzioni
- 7 . Vector Unit e Mask Register
- 8 . Le unità texture
- 9 . Larrabee Versus Cell
- 10 . Larrabee Versus GPU
- 11 . Larrabee contro se stesso?