Intel breidt AVX uit naar 512 bits

Intel heeft details gegeven over de volgende generatie AVX-instructies. Daarmee moeten toekomstige generaties processors effectiever om kunnen gaan met vectorberekeningen. Vooral servers zouden daarvan moeten profiteren.

De nieuwe instructieset gaat voluit de Intel Advanced Vector Extensions 512 heten, kortweg AVX-512, zo meldt Intel op zijn softwareblog. De nieuwe instructieset volgt de 512bit brede simd-set op die in Knights Corners werd geïntroduceerd. In de opvolger van die Xeon Phi-coprocessor, met codenaam Knights Landing, zal de AVX-512-instructieset debuteren. Ook toekomstige generaties Xeon-processors zullen met AVX-512 worden uitgerust.

De instructieset ondersteunt acht double precision of zestien single precision floating point-getallen in de 512bit-vectors. Daarin passen ook acht 64bit-integers of zestien 32bit-integers: daarmee verdubbelt AVX-512 de hoeveelheid verwerkte data ten opzichte van de AVX2-instructieset. AVX-512 is compatibel met voorgaande AVX-instructiesets. Intel maakte niet bekend of de AVX-512-instructies ook in toekomstige generaties consumentenprocessors gebruikt wordt. Die processors, met codenaam Broadwell en later Skylake, zouden AVX 3.2 krijgen: of dat de nieuwe 512bit-instructieset wordt, is afwachten.

Reacties (34)

[paknaald]

De Basic Linear Algebra Subprograms van Intel ondersteunen dit standaard. Daardoor kan een grote klasse (commerciële) wetenschappelijke software heel gemakkelijk gebruik maken van deze uitbreiding van de instructieset. Ook GCC kan een deel van de instructies al compilen voor flinke performance-winst. Dit zijn flink stappen vooruit, voor weliswaar kleine communities.

[Verwijderd]

Vooral servers zouden daarvan moeten profiteren.

Onzin. Dit is evenzeer concurrentie voor AMD's APUs.

R.I.P. GPGPU

Intel maakte niet bekend of de AVX-512-instructies ook in toekomstige generaties consumentenprocessors gebruikt wordt. Die processors, met codenaam Broadwell en later Skylake, zouden AVX 3.2 krijgen: of dat de nieuwe 512bit-instructieset wordt, is afwachten.

Is overduidelijk als je tussen de lijnen leest. 8x floating-point prestaties in 4 architectuur-generaties:

Nehalem/Westmere: 128-bit FMUL+FADD
Sandy Bridge/Ivy Bridge: 256-bit FMUL+FADD
Haswell/Broadwell: 256-bit FMA+FMA
Skylake/Skymont: 512-bit FMA+FMA

Knights Corner ondersteunde reeds 512-bit, en ze vermelden expliciet Sandy Bridge/Ivy Bridge en Haswell als deel van de generaties, dus het is duidelijk de CPU-lijn waar ze het over hebben.

[Dreamvoid]

R.I.P. GPGPU

Nou ja, het is duidelijk dat Intel, nVidia en AMD een andere insteek hebben wat betreft massively-parallel-vector-computing:
- Intel voegt de vector units toe aan de CPU, en verzint een paar nieuwe x86 instructies ervoor
- nVidia ramt een videokaart vol met vector units
- AMD hangt er tussenin met hun APU filosofie, met een architectuur die niet zo geintegreerd is als Intel maar ook niet totaal separaat als nVidia.

Maar wat de ideale aanpak is, is nog niet duidelijk. De insteek van Intel is het meest elegant, maar in de praktijk zijn de meest elegante oplossingen zelden degene die ook het beste werken.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 06:16]

[Verwijderd]

Intel voegt de vector units toe aan de CPU, en verzint een paar nieuwe x86 instructies ervoor

Een paar? Men voegt alles toe waar een GPU ook over bezit voor general purpose computing...

nVidia ramt een videokaart vol met vector units

Dat is zinloos voor de consumentenmarkt. Real-time applicaties moeten vlot data kunnen uitwisselen tussen de CPU en GPU om dat werkbaar te maken, maar de bandbreede groeit niet met gelijke tred als de rekenkracht! Bandbreedte is relatief duur en kost ook veel vermogen. Een CPU met AVX-512 daarintegen kan maximaal profiteren van de caches, die gigantisch veel bandbreedte leveren bij zeer matig verbruik.

AMD hangt er tussenin met hun APU filosofie, met een architectuur die niet zo geintegreerd is als Intel maar ook niet totaal separaat als nVidia.

AMD maakt geen schijn van kans. Hun marktaandeel is zeer klein en ontwikkelaars zoeken de beste ROI: goeie groei in prestaties, met maximale afzetmarkt, minimale risicos, en minimale moeite. AMD verwacht een zeer grote inspanning van developers om voor hun architectuur te ontwikkelen, maar er zit geen geld in voor hen.

Maar wat de ideale aanpak is, is nog niet duidelijk.

Is nogthans overduidelijk. De 'bandwidth-wall' vergt steeds meer integratie, en dat betekent uiteindelijk zeer dichte samensmelting van CPU en GPU-technology.

[Dreamvoid]

AMD maakt geen schijn van kans.

Toegegeven, op het moment zit AMD in de hoek waar de klappen vallen. Zowel nVidia als Intel hebben betere parallelle computing oplossingen. Maar je weet nooit wat ze nog uit de hoed trekken.

De "bandwidth wall" blijft een tradeoff - de vraag is of software werkelijk veel data heen en weer schuift tussen de vector units en de cpu.

Ik moet ook zeggen dat op papier de Intel aanpak er veel logischer uit ziet, maar ik loop al te lang mee om zo snel al een winnaar aan te wijzen

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 06:16]

[goarilla]

Wat is er zo elegant aan weer "nieuwe x86 extensies".

[Dreamvoid]

Elegant als in: je parallelle vector unit is gewoon deel van de cpu, geen nieuwe instructieset (OpenCL, CUDA), geen bottlenecks tussen gpu/cpu, geen specifieke nieuwe programmeertalen of skills nodig, dezelfde compiler - het is gewoon een dikkere versie van de huidige SIMD units op een cpu.

Zie ook het succes van ARM SoC's: dat is ook gebouwd op extensies op de oude ARM ISA (NEON, VFP, Thumb2, etc), niet op het toevoegen van allemaal losse units met hun eigen instructiesetjes.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 06:16]

[svenk91]

Zal software dan erg aangepast moeten worden om hier gebruik van te maken? Ik geloof dat iniedergeval op desktops nieuwe instructies pas na vele jaren worden toegepast in software zodat alles backwards compatible blijft.

[KirovAir]

De software hoeft niet per sé aangepast te worden. De compilers zullen de uiteindelijke programmacode moeten omzetten naar de nieuwe instructieset, dus wellicht is een compiler-upgrade al voldoende.

[gast128]

Deze AVX instructie set zit niet in alle processoren. Als je applicaties ontwikkelt die op alles werkt, kan je of dit niet gebruiken, of je hebt een intermediate language nodig (c#, java) die compileert voor de aanwezige processor of je gebruikt een abstractie laag die afhankelijk van de processor een implementatie kiest. IPP is daar een voorbeeld van.

Wellicht is dit specifiek bedoeld voor rekencentra en ook om GPGPU's wind uit de zeilen te nemen.

[bkor]

Onder Linux is het redelijk gebruikelijk dat processor specifieke optimalizaties standaard mee worden gecompileerd en tijdens het uitvoeren bepaald wordt wat de beste versie voor iets is. Dit voornamelijk in libraries enzo. Maar dat zijn net de dingen waarin je dit zou willen hebben.

[GewoonWatSpulle]

Of virtual machine, bestaande uitgerolde .NET of Java code zou mogelijk met een runtime upgrade alweer sneller gaan functioneren.

[hardwareaddict]

Het is heel lastig om AVX2 te gebruiken.

Zelfs de beste programmeurs die priemgetalsoftware bouwen zijn jaren ermee bezig geweest en kregen 't op Larrabee (tegenwoordig Xeon Phi) niet zo best aan de praat.

Dat ligt niet zozeer aan de instructieset, maar met name de hardware implementatie.

Indirecte lookups op larrabee zijn pokketraag.

Kortom alleen voor pure vectorcodes is dit goed bruikbaar. Daarvan draai je er niet zoveel van op je PC.

Intels libraries zijn wel heel erg goed, dus als iemand 't KAN gebruiken dan is de support daar wel heel erg goed.

Custom code in avx2 schrijven is echter niet erg lonend.

We zien ook hoe dat in 'amateursoftware' ook compleet mislukt is voor AVX en SSE2 al.

De compilers konden deze instructies ook maar mondjesmaat genereren.

Met andere woorden - dit is interessant voor een heel erg kleine doelgroep - met name voor de groep die fiks wil number crunchen. Dat is echter alleen interessant op de manycore processoren tegenwoordig, daar die zo enorm sneller zijn dan de CPU's dat het abnormaal is.

Zo heb ik hier op dit moment nog wat Tesla's idle staan. Dat is al de VORIGE generatie tesla.

Maar die levert double precision wel 0.5 Tflop.
Processoren druk je nog uit in gflop en dat zijn theoretische getallen vaak (niet genoeg memory bandbreedte om de cores bij te benen).

Het overstappen op AVX2 heeft wel een reden voor intel. Het is relatief eenvoudig om de bandbreedte iets omhoog te gooien.

Liever zou ik echter meer INTEGER cores zien op een CPU.

[DLGandalf]

"We zien ook dat.."
Wie is we? Waar komen je conclusies vandaan?

AVX2 heeft behoorlijk wat snelheids winst met de 'dood normale' gcc compiler:
http://www.phoronix.com/s...tem=intel_core_avx2&num=2

(toegegeven er zijn ook regressies, maar dat zegt meer over het nog niet ge-optimaliseerd zijn van de compiler.)

[Dreamvoid]

Intel's filosofie is dat die hele GPU niet nodig is als je cpu's met AVX2/AVX-512 hebt.

[Dreamvoid]

Kortom alleen voor pure vectorcodes is dit goed bruikbaar.

Daar is dit dan ook voor gemaakt.

[hardwareaddict]

liever een goedkopere CPU dan, of een cpu met meer cores, en een snellere graphicscard dan weer dit gepruts van een CPU die low latency is, mogelijkheden om ietsjes meer vectorcodes te executen

Die vectorsnelheid had ik hier al op de gpu's namelijk. Daar ga ik geen dure CPU voor kopen die toch FACTOREN trager is dan zo'n manycore, terwijl hij niet sneller wordt voor pure software die op de CPU draait, want er zijn niet meer cores en die codes vectoriseren gewoon niet.

[Verwijderd]

Die vectorsnelheid had ik hier al op de gpu's namelijk. Daar ga ik geen dure CPU voor kopen die toch FACTOREN trager is dan zo'n manycore...

Wat je niet lijkt te verstaan is dat de doorsnee GPU in de consumentenmarkt niet zo bijster snel is. Bovendien zijn GPUs inherent lastig te programmeren voor generiek gebruik. AVX-512 brengt zeer veel rekenkracht naar de CPU-cores zelve.

Mijn i7-4770 haalt 435 GFLOPS op de CPU-cores, terwijl de geintegreerde GPU slechts 384 GFLOPS levert. De GPU kan in theorie groter gemaakt worden, maar dan zit die met te weinig bandbreedte. Daarvoor gebruikt Intel een L4 cache. Maar dat schaalt dus ook niet veel verder. AVX-512 levert twee maal de rekenkracht van Haswell, per core, en octacore wordt waarschijnlijk gemeengoed.

Geintegreerde GPUs winnen aan marktaandeel, maar de rekenkracht is dus beperkt door de bandbreedte en CPUs maken een inhaalslag. Tel daarbij op dat GPUs moeilijker te programmeren zijn, en het is duidelijk dat AVX-512 een betere toekomst tegemoet gaat.

[Dreamvoid]

Uiteraard, maar dit is met vergelijkbare instructies (OpenCL, CUDA) niet anders - als je het draait op een platform dat de instructies niet kent, dan werkt het niet. Maar je kan als programma natuurlijk redelijk eenvoudig een check doen op wat de cpu kan, en dan verschillende libraries gebruiken.

[_Thanatos_]

Zal software dan erg aangepast moeten worden om hier gebruik van te maken?

Niet de software die via tussencode werkt, zoals .NET, Java, python, etc. Die applicaties staan op disk in een vorm die nog niet door de CPU wordt begrepen; het framework is daar verantwoordelijk voor. Dit betekent dus dat de betrokken frameworks en hun modules die native code genereren, moeten worden geupdate.

Wat betreft "native applicaties", dus bijv software die in C++ geschreven is, die zullen wrs moeten worden gehercompileerd met een geupdate compiler. Alleen hoe/waar dan de beslissing gemaakt wordt om deze instructies wel/niet te gebruiken, is aan de software om uit te vogelen (tenzij je bijna alle andere CPU's niet hoeft te ondersteunen).

[larreh]

Hoe zit het dan bijvoorbeeld met Adobe pakketten en rendering van 3D pakketten in het algemeen? Kan een instructieset zoals bovengenoemde door middel van een 512 bits register toevallig sneller encoden/transcoden en renderen, of zal het nog jaren duren voordat dergelijke code die Adobe gebruikt in haar pakketen kan profiteren van een 512 bits register?

[Verwijderd]

...rendering van 3D pakketten in het algemeen? Kan een instructieset zoals bovengenoemde door middel van een 512 bits register toevallig sneller encoden/transcoden en renderen...

Absoluut. AVX-512 is een afgeleide van de Xeon Phi instructieset, die op zijn beurt is afgeleid van het Larrabee-project; een extreem programmeerbare discrete GPU. Bedoeld voor rendering dus.

Larrabee werd gecancelled omdat games er niet snel genoeg gebruik van zouden maken (lees: veel verlies voor Intel voordat het hen mogelijks iets ging opleveren). Maar die technologie vindt dus nu zijn weg naar de CPU, eerst met AVX, dan AVX2, en nu AVX-512. Dit is minder risicovol voor Intel (iedereen heeft sowieso een CPU nodig) en developers krijgen de tijd om er software voor te ontwikkelen.

De mogelijkheden zijn eindeloos, als het maar veel parallele berekeningen vergt. Grafische programma's, multimedia, stem/gezichtsherkenning, fysische simulaties, noem maar op.

[Dreamvoid]

Alleen Adobe kan deze vraag beantwoorden

[larreh]

Interessant. Ik heb overigens dezelfde vraag gesteld aan een medewerker van Adobe, via een chat sessie. Hij gaf aan dat de code om deze nieuwe techniek in te zetten nog in ontwikkeling is en dat het nog niet getest is. Maar we merken het vanzelf!

[DamonTheron]

Snap ik je niet of heb je het nu over de voorganger, waarvan de hoeveelheid verwerkte data dus wordt verdubbeld?

[Verwijderd]

De gemiddelde software heeft geen drol aan 512 bits natuurlijk.

Dan snap je blijkbaar niks van SIMD. Elke lus in je code met onafhankelijke iteraties, kan in parallel worden uitgevoerd via vectorisatie. De LLVM compiler bevat zelfs optimalisaties die ogenschijnlijk minder geschikte lussen transformeert in SIMD-vriendelijke code.

Ter info: http://ispc.github.io/index.html

Dus door die SIMD units hebben die cpu's minder cores dan ze zouden kunnen hebben!

Cores vergen erg veel vermogen. SIMD rekeneenheden zijn zuiniger, en AVX-512 kan tot 16x zo veel data verwerken als een scalaire core.

Dit is ook hoe GPUs werken. Een GK104 heeft 8 cores, 6 vectoreenheden, van 32 elementen. Zo komt men aan 1536 CUDA-cores, wat uiteraard marketing-onzin is om de benaming 'core' te misbruiken.

[dmantione]

Ja, maar tenzij je programma met enorme arrays werkt zul je tegen grenzen aanlopen: Je kunt niet onbeperkt vectorizeren. Zeker met wat langere pijplijnen zul je dus lus al in de lengte moeten openvouwen (anders wordt de lusoverhead te groot). Met 512 bits reken je 8 doubles per keer uit. Stel dat je daarna nog eens 8 maal openvouwt om de lusoverhead te elimineren, dan zit je al aan 64 doubles per lusiteratie.

Programma's die zoveel berekeningen ineens doen bestaan, maar ga er niet vanuit dat het gemiddelde programma de kans heeft om zijn gegevens in blokken van 64 doubles kan verwerken.

Net als dat een GPU prima geschikt is om beelden op het scherm te toveren, maar een schaakprogramma dat op de GPU draait zul je minder snel tegen komen.

[Reactie gewijzigd door dmantione op 25 juli 2024 06:16]

[Verwijderd]

Met SPMD vectoriseer je tussen iteraties, niet binnen een iteratie. De lusoverhead wordt dus niet groter!

Veel lussen voeren duizenden iteraties uit. Dus een overvloed aan potentieel om meerdere iteraties in parallel uit te voeren, zelfs met 8 of 16 elementen per vector.

[Dreamvoid]

De SIMD units doen natuurlijk meer dan alleen 512 bits instructies verwerken. Maar idd, normale programma's hebben nauwelijks baat bij deze *instructies*, wel bij meer SIMD units natuurlijk. Chipbakkers zetten ze er niet voor de lol in.

Als je simpele integer cores bakt, dan kom je op zoiets als een Cortex A7 uit van <1 mm2 groot. Daar kan je er 256 van op 1 die plempen, en dan heb je een parallel integer computing monster (met een heleboel interconnect bottlenecks). Wie dat nodig heeft, is een andere vraag, maar het kan wel.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 06:16]