2016-06-08 15 views
5

Il processore Intel Xeon Phi "Knights Landing" sarà il primo a supportare l'AVX-512, ma supporterà solo "F" (come SSE senza SSE2, o AVX senza AVX2), quindi roba a virgola mobile principalmente.Will Knights Landing CPU (Xeon Phi) accelera il codice intero byte/parola?

Sto scrivendo un software che funziona su byte e parole (8 e 16 bit) utilizzando fino alle istruzioni SSE4.1 tramite intrinseche.

Sono confuso se ci saranno versioni codificate EVEX di tutte/molte istruzioni SSE4.1 in AVX-512F, e se questo significa che posso aspettarmi che il mio codice SSE ottenga automaticamente istruzioni estese EVEX e mappa a tutti i nuovi registri.

Wikipedia dice:

La larghezza del file registro SIMD viene aumentata da 256 bit a 512 bit, con un totale di 32 registri ZMM0-ZMM31. Questi registri possono essere indirizzati come registri YMM a 256 bit da estensioni AVX e registri XMM a 128 bit da Streaming SIMD Extensions e le istruzioni AVX e SSE legacy possono essere estese per operare sui 16 registri aggiuntivi XMM16-XMM31 e YMM16-YMM31 quando si utilizza EVEX forma codificata.

Questo, purtroppo, non chiarisce se la compilazione di codice SSE4 con AVX512 abilitati porterà alla stessa (impressionante) aumento di velocità che compilarlo a AVX2 fornisce (codifica VEX delle istruzioni precedenti).

Qualcuno sa cosa accadrà quando il codice SSE2/4 (C intrinseco) viene compilato per AVX-512F? Ci si può aspettare un aumento di velocità come con la codifica VEX di AVX1 delle istruzioni di byte e parole?

+1

Potrei aver risposto alla mia stessa domanda con più attenzione. Vedere l'ultima frase di questo: https://en.wikipedia.org/wiki/AVX-512#SIMD_modes ... Sembra che le istruzioni SSE/AVX operino su byte e le parole NON condividano uno spazio dei nomi con i nuovi registri fino a AVX512BW. Qualche chiarimento se questo in realtà significa qualcosa sul rendimento? – user1649948

+0

Si potrebbe desiderare di aspettare Purley (l'anno prossimo, presumibilmente) - avrà le aggiunte AVX-512BW. –

+1

AVX-512F sarà supportato sia da "Big Core" (Xeon) che da "Throughput hpc accelerator" (Xeon Phi). Ma Xeon Phi e Big Core avranno anche set di istruzioni AVX-512 unici, destinati esclusivamente agli utenti Big Core o esclusivamente agli usi "Throughput". AVX-512BW è esclusivo per Big core, mentre ad es. AVX-512ER (reciproci) è esclusivo di Xeon Phi. Non sono sicuro che si tratti di "prestazioni saggio", ma dovrebbe essere "power-perfomance wise" e un po 'focalizzato su FP-focus (dal momento che Xeon Phi è destinato a utenti orientati al throughput più orientati al fattore FP). – zam

risposta

3

Ok, penso di aver messo insieme abbastanza informazioni per dare una risposta decente. Ecco qui.

Cosa succederà quando il codice nativo SSE2/4 viene eseguito su Knights Landing (KNL)?

Il codice verrà eseguito nel quarto inferiore dei registri su un singolo VPU (denominato livello di compatibilità) all'interno di un nucleo. Secondo un webinar pre-release di Colfax, ciò significa occupare solo da 1/4 a 1/8 dello spazio di registrazione totale disponibile per un core e in esecuzione in modalità legacy.

Cosa succede se lo stesso codice viene ricompilato con i flag del compilatore per AVX-512F?

Il codice SSE2/4 verrà generato con prefisso VEX. Ciò significa che pshufb diventa vpshufb e funziona con un altro codice AVX in ymm. Le istruzioni NON saranno promosse in EVEX nativo di AVX512 o permesso di indirizzare specificamente i nuovi registri zmm. Le istruzioni possono essere promosse su EVEX solo con AVX512-VL, nel qual caso ottengono la possibilità di indirizzare direttamente (rinominato) i registri zmm. Non è noto se la condivisione dei registri sia possibile a questo punto, ma il pipelining su AVX2 ha dimostrato un throughput simile con AVX2 a mezza larghezza (AVX-128) come con il codice AVX2 a 256 bit completo in molti casi.

Ancora più importante, come si ottiene il codice di dimensione di byte/parola SSE2/4/AVX128 in esecuzione su AVX512F?

Dovrete caricare blocchi di 128 bit in xmm, sign/zero estendere quei byte/parole in 32-bit in zmm e operare come se fossero sempre numeri interi più grandi. Quindi al termine, riconvertire in byte/parole.

È veloce?

Secondo materiale pubblicato su Larrabee (prototipo cavalieri Landing), conversioni di tipo di qualsiasi larghezza intero sono liberi da XMM a ZMM e viceversa, purché registri sono disponibili. Inoltre, dopo aver eseguito i calcoli, i risultati a 32 bit possono essere troncati al volo fino alla lunghezza di byte/parola e scritti (impacchettati) in una memoria non allineata in blocchi di 128 bit, potenzialmente salvando un registro xmm.

Su KNL, ogni core ha 2 VPU che sembrano essere in grado di comunicare tra loro. Quindi, le ricerche 32-way a 32-bit sono possibili in una singola istruzione vperm * 2d di un throughput presumibilmente ragionevole. Questo non è possibile nemmeno con AVX2, che può permutare solo all'interno di corsie a 128 bit (o tra corsie solo per il vpermd a 32 bit, che non è applicabile alle istruzioni di byte/parole). Combinato con conversioni di tipo libero, la possibilità di utilizzare le maschere in modo implicito con AVX512 (risparmiando l'uso costoso e intensivo del registro di blendv o generazione di maschere esplicite) e la presenza di più comparatori (nativo NOT, non firmato/lt/gt, ecc.) , dopo tutto potrebbe fornire un ragionevole incremento delle prestazioni per riscrivere il codice byte/parola SSE2/4 per AVX512F. Almeno su KNL.

Non preoccuparti, metterò alla prova il momento in cui metterò le mie mani sulle mie. ;-)

+1

Le conversioni di tipo intero "libero" erano presenti su KNC, ma non sono presenti su KNL, purtroppo. –