Instructiesets Larrabee en Core groeien naar elkaar toe

Intel is trots op het feit dat Larrabee compatibel is met x86, maar in de praktijk zijn er belangrijke verschillen in de instructieset ten opzichte van de gewone Core-serie. Die gaan echter langzaam verdwijnen.

De komende jaren zal Intel regelmatig nieuwe instructies aan zijn processors blijven toevoegen. Nehalem introduceert bijvoorbeeld sse 4.2, waar onder meer foutcorrectie en tekstvergelijkingsfuncties in opgenomen zijn. Laatstgenoemde zijn onder meer nuttig voor databases, (xml-)parsers en bedrijven als Google die veel aan textmining doen.

Westmere, de 32nm-versie van Nehalem, krijgt daarna nog eens zes extra instructies om aes-encryptie te versnellen. Verwacht wordt dat dit op de tweede generatie van Nehalem 3 tot 10 keer sneller zal verlopen dan op de eerste. Daarnaast zou de hardware-implementatie moeilijker af te luisteren zijn door middel van side band-aanvallen, zoals de beruchte 'bug' in Hyperthreading waar een paar jaar geleden ophef over was.

Ongeveer tegelijk met Westmere introduceert Larrabee een hele eigen instructieset met 512bit-vectoren. Meer details daarover zijn in dit artikel te vinden, maar kort samengevat krijgt de 'cgpu' een hoop geavanceerde functies die in Nehalem en Westmere ontbreken.

Ongeveer een jaar later verschijnt de Sandy Bridge, de tweede generatie van de 32nm-chip. Als deze nu precies dezelfde instructies kreeg als Larrabee dan was er niets aan de hand geweest, maar Intel heeft ervoor gekozen om Sandy Bridge een aparte instructieset te geven met 256bits vectoren: AVX.

AVX lijkt tot op zekere hoogte wel op de vectorextensie van Larrabee, maar de een heeft functies die de ander mist en vice versa. Voor ontwikkelaars is dit uiteraard niet optimaal, maar redding is gelukkig wel in zicht. In toekomstige versies van Larrabee en de 22nm-architecturen Ivy Bridge en Haswell zullen de instructiesets langzaam naar elkaar toe worden getrokken.

Geschatte roadmap, samengesteld door Tweakers.net

Reacties (28)

[Akino]

Gaan we nu elke paar dagen tot ergens medio 2009 over de "mogelijke mogelijkheden"van de Larrabee lezen.????
Die veel verder als simulaties nog nergens werkend gezien is.

Niet dat ik het niet intersant vind,maar word zo al,lang voor de release al aardig Larrabee moe.

En Intel bevestig hiermee simpelweg,dat ze de zelfde ontwerpen blijven opleuken en hergebruiken.

Ook vind ik dat de groei/beter zijn/sneller van de grafix t.o.v de groei van de rekenkracht van de GPU's steeds meer en meer tegenvallen.
Blinkend en stralende oppervlakken zijn vaak van de factor te.
Als je dicht met je neus tegen een muur staat ziet het er nog steeds niet uit.

[Soultaker]

Mee eens, en ik wil er graag aan toevoegen dat als er dan een nieuwspost wordt gemaakt over Larrabee, dat er dan tenminste een bron van nieuwe informatie is. In de huidige nieuwpost wordt alleen gerefereerd aan een Tweakers.net review van vorige week!

[elmuerte]

tekstvergelijkingsfuncties

Wat moet ik me hier bij voorstellen? unicode support in de CPU?

[Verwijderd]

Hum... ik denk dat je niet verder komt dan strcmp() op hardwareniveau.
Wel cool, wordt veel gebruikt.

[Soultaker]

Maar dat kan al lang (met de repeat-prefix en vergelijkingsinstructies).

Voor zover je specialistische operaties überhaupt hardwarematig wil uitvoeren, zouden Unicode-operaties misschien juist wel zinnig zijn, vooral omdat Unicode strings tegenwoordig in veel gevallen onderdeel van de standard library zijn en dus kandidaat om platformspecifiek te optimaliseren (als onderdeel van portable code is dat minder wenselijk) en bovendien veel gebruikt worden.

Aan de andere kant is text processing in veel gevallen niet echt een bottleneck (en b.v. AES encryptie wel, als je b.v. een VPN gebruikt).

[Reactie gewijzigd door Soultaker op 28 juli 2024 08:21]

[Rob Coops]

Het lijkt er op dat Intel de cgpu en de cpu een te maken. Als je dan bedenkt dat Intel al tijden over tientalen, honderden of zelfd duizende cores in een computer spreekt kun je je voor stellen dat uit eindelijk een apparte gpu niet echt nodig is omdat je gewoon genoeg processor kracht hebt om bijde door de cpu te laten doen.

Maar dat is altijd al het geval geweest met MS-Dos had je geen dual core CPU nodig en zou je nu dus makelijk de tweede of tweede, derde en vierde core kunnen gebruiken voor de 3D graphics.
Helaas is het zo dat onze vrienden in Redmond steeds maar meer en meer toeters en bellen aan hun OS hangen en dus steeds meer processor kracht nodig hebben. Zo veel zelfs dat je tegenwordig zelfs met de nieuwste computers nog het gevoel hebt dat je op een systeem uit 1990 zit te werken gewoon omdat ze in Redmond vinden dat het mooi is om een serie semi transperante windows in een sort van 3 dimensionale carosel op je scherm te laten zien terwijl je eigenlijk alleen maar je mailbox wilde bekijken inplaats van die web pagina.

Als het Intel lukt om hun processoren echt sneller te maken zonder dat Redmond het voor elkaar krijgt om nog meer vertragingen in hun OS te bouwen dan kon Intel mischien wel een glijk krijgen maar als Intel hun processoren net zo veel sneller maakt als Redmond nieuwe "features" levert dan gaat het Intel nooit lukken om hun droom van 1 processor die zowel graphics als general purpose doet waar te maken.

Ehm, ja ik gebruik nog steeds Windows XP, Vista, NT, 2003, Linux, HP-UX en Solaris op een bijna dagelijkse basis en nee ik heb niets tegen Microsoft en ben ook niet voor *nix. Ik leg gewoon uit waarom ik denk dat Intel het nog wel eens moeilijk kon krijgen om deze plannen echt waar te maken.

[Atomsk]

Er zijn altijd meerdere ontwikkelingen. Hardwaremakers als Intel komen met steeds snellere cpu's. Softwaremakers als Microsoft gaan dat uiteraard niet uitsluitend gebruiken om een bestaand OS steeds sneller te maken en voor de rest niks. Wie zou er Vista kopen wanneer het er exact hetzelfde uitzag als Windows95, met alleen wat meer ondersteuning voor nieuwe hardware en instructiesets? Een systeembeheerder misschien, maar de doorsnee consument wil meer dan dat.

Daarnaast is veel van die eyecandy gewoon uit te schakelen wanneer je je daar aan ergert. Punt is wel dat MS wat meer rekening zou kunnen houden met het optimaliseren van transparantie e.d. zodat het op een doorsnee pc ook goed werkt. Dat kan Apple ook, al hebben die het wat gemakkelijker omdat ze zelf ook grotendeels verantwoordelijk zijn voor de hardware.

MS is overigens niet de enige die je van gemakzucht kunt beschuldigen. Programmeurs van encoders, encryptie en compressiesoftware zijn nu ook niet bepaald snel te noemen met het implementeren van nieuwe functionaliteit. Goede support voor multicore is nog steeds ver te zoeken. Idem voor zaken als Unicode ondersteuning. Onder XP kun je makkelijk bestanden met Chinese of Japanse tekens in de bestandsnaam opslaan, maar ga niet proberen die met Winzip te openen, want die kan daar niet mee omgaan.

[Antipater]

Gespecialiseerde hardware is nu eenmaal sneller te maken en zal daardoor altijd blijven bestaan. Je ziet in het verleden wel dat zulke hardware dan vaak in de meer algemene hardware geintegreerd wordt (x87 co-processor), en dan na een tijdje weer opduikt als apart onderdeel.
Ook voor de HD en DVD codecs hebben grafische kaarten bijvoorbeeld gespecialiseerde hardware ingebouwd,

Softwareontwikkelaars zullen altijd de huidge hardware ten volle gebruiken, is het niet om de competitie voorbij te streven dan wel om kosten te besparen door een minder zuinig ontwikkelproces. Hetzelfde geldt voor hardware fabrikanten. Larrabee is leuk, maar ik betwijfel het sterk of deze processor mee zal kunnen komen met de volledig op graphics ingerichte GPU's.

even off topic: Ik deel je frustratie over slome applicaties, ongelofelijk hoe stroperig het voelt om een beetje het internet te browsen tegenwoordig. Gevoelsmatig is dat alleen maar langzamer geworden de laatste 5 jaar, verschrikkelijk.

[.oisyn]

je dan bedenkt dat Intel al tijden over tientalen, honderden of zelfd duizende cores in een computer spreekt kun je je voor stellen dat uit eindelijk een apparte gpu niet echt nodig is omdat je gewoon genoeg processor kracht hebt om bijde door de cpu te laten doen

Het punt is dat processorkracht niet de issue is. Goed, we hebben momenteel nog wat te weinig cores om shaders effectief op de CPU in te kunnen zetten, maar als we dat wel zouden hebben dan nog hebben we een heel erg groot probleem: memory issues. Een GPU is veel meer dan alleen een processor met heel veel semi-threads (de shader pipelines). Hij heeft ook dedicated hardware om om te gaan met memory fetches en writes van/naar framebuffer, z-buffer en texture memory. Om bijvoorbeeld een texture fetch met bilinear filtering toe te passen heb je al 4 texels nodig (die niet per se naast elkaar in het geheugen staan). Bij trilinear filtering zijn dat er al 8 (interpoleren tussen mipmap levels, dus 2x4). Voor n-taps anisotropic filtering doe je feitelijk n trilinear fetches, dus in totaal 8n texel samples. Als je dat allemaal zelf moet gaan zitten fetchen en filteren dan kost dat een godsvermogen, en daarom heeft een GPU (en dus ook Larrabee) dedicated texture hardware die je aan het werk kan zetten terwijl je zelf nog wat andere dingen gaat doen.

[g4wx3]

Tekstvergelijking vind ik wel een heel intressante functie, hoewel het heel makkelijk software matig te emuleren is, is het hardware matig veel sneller.
Waar ik deze functie interessant vind is in DNA-analyse functies. Met PCR en electroforese kun je al veel achterhalen, maar met de computer nog veel meer, ze het human genome project.

[wizzkizz]

Zou dit hardwarematige AES versnelling er ook toe (kunnen) leiden dat Intel er (op verzoek van de NSA) een backdoor inbouwt? Dus dat je software wel goed is, je compiler betrouwbaar maar je vervolgens toch genaaid kunt worden door je CPU?

Of is dit niet aan de orde?

P.S. ik weet wel dat encryptie in de meeste gevallen niet gebruikt zal worden om de NSA te dwarsbomen, maar het is maar een vraag.

[BramT]

Je bedoeld dat de AES encryptie niet goed (en makkelijker kraakbaar) gemaakt wordt door de CPU? Hmmm, heel-erg-in-theorie misschien wel, maar een beetje software (die resultaat checkt) heeft dat meteen in de gaten.

Bovendien zitten er een hele berg fanatiekelingen dit soort geintjes in de gaten te houden. D'r zijn er genoeg die bv de hele communicatie tussen je pc en windows-update in de gaten lopen te houden omdat ze willen weten wat MS nou precies binnenkrijgt.

Intel zou gigantisch uitwerpselen aan de spreekwoordelijke glazen bal krijgen als geintjes als dit uitkomen (en dat komen ze dus echt wel). Ik ben er dus absoluut niet bang voor.

[Simon Verhoeven]

Het wordt natuurlijk helemaal interessant als ze voor elkaar gaan bijspringen wat waarschijnlijk wel de bedoeling gaat zijn.

[Verwijderd]

Wat wordt er bedoelt met hardware FMA? Het enige wat ik kan vinden is Fast Memory Access van Intel en dat wordt nu al gebruikt als ik op de website van Intel kijk.

Het lijkt me logisch dat Intel voor de gewone Core eerst gebruik maakt van 256bits vectoren. Voor toepassingen die niet voor grafische doeleinden bedoelt zijn lijkt het me voldoende. Daarvoor zouden bepaalde instructies minder van belang zijn. Ik zie niet direct het nut van heel snel gelijktrekken van de functionaliteit en het aantal bits.

Is er ook nog nieuws over hoeveel cores de processors ongeveer krijgen?

[MSalters]

FMA = Fused Multiply and Add. Dus X = A*B + C. Dat wordt dus 1 instructie, in plaats van 2. Erg belangrijk voor GPUs, omdat je die combinatie in coordinaattransformaties nogal eens nodig hebt.

[Soultaker]

Wat maakt dat zoveel efficiënter dan een losse vermenigvuldiging en optelling? De processor vertaalt die x86 instructies toch naar micro-operations, dus zou ik verwachten dat in de CPU de instructie uiteindelijk op dezelfde manier uitgevoerd wordt, al bespaar je je misschien een update van het flags register en is je code iets korter omdat je een opcode en een operand minder hebt.

[mschol]

dat is toch niks nieuws?


ik vraag mij wel af wat de extra functies voor nut hebben voor normale eindgebruikers?

[Reactie gewijzigd door mschol op 28 juli 2024 08:21]

[Little Penguin]

Laatstgenoemde zijn onder meer nuttig voor databases, (xml-)parsers

Ook op de desktop wordt er gebruik gemaakt van databases (denk aan SQLite in Firefox bijvoorbeeld, op dit moment is dat het enige concrete voorbeeld wat ik kan bedenken), nu zullen deze niet direct gebruik maken of kunnen maken van de extra functies - op termijn kan dat echter wel het geval zijn.

En over (XML-)parsers gesproken: Wat dacht je van HTML, CSS, JavaScript et al? Dat moet allemaal geparsed worden - ik type dit bericht in Firefox en de UI van Fx is zelfs in XML geschreven...

[leuk_he]

larrabee is de GPU processor van intel. Deze Krijgt echter een zodanige architectuur dat deze ook voor meer dingen is te gebruiken. (netzo als dat je op een nvidea via CUDA ook programma's op je gpu kunt draaien).

Je CPU gaat dus in de toekomst ook GPU instrucites aan kunnen.

/Edit:

http://www.theinquirer.ne...idf-2008-analysis-nehalem

"Interestingly, almost every Intellite we spoke to mentioned the word 'Larrabee' at some point. And, it's not just that initial PCI-E card we're talking about. For better or worse, at the end, Larrabee is an X86 processor - yes a very specialised one, but still an X86er which in theory could run that very same X86 code, and one day maybe even boot an X86 OS depending on the MMU in there. An Intel compiler, say rev 11, could easily make a fat binary that runs on both X86 CPU-only and X86 CPU+GPU, or should we say, CPU+coprocessor - remember the 8087 days?

Hold on, coprocessors should operate in the same memory space as the main CPU for simple coding, after all - PCI-E may only allow shared virtual memory, even after all the tricks are exhausted. Those that use Quadrics QsNet supercomputer interconnect from Old Blighty, the only one that enables this at high speed over PCI, know this well."


het lijkt meer en meer op een coprocessor

net als 80286 & 80287 later geintegreerd werden in een 80486 wordt misschien de Larrabee 2 generaties verder ook geintegreerd.

[Reactie gewijzigd door leuk_he op 28 juli 2024 08:21]

[Toontje_78]

Programma's die de nieuw geimplementeerde functies gebruiken kunnen sneller uitgevoerd worden, doordat voor deze instructie voorheen een reeks instructies uitgevoerd moest worden voor hetzelfde resultaat.

Zoals het oude CISC vs RISC argument, dient de functie wel vaak genoeg aangesproken te worden om de 'kosten' in transistoren te rechtvaardigen.

AES versnellen zal waarschijnlijk ook inhouden dat er meer versleuteld kan gaan worden bij dataverkeer; dit is denk ik wel voornamelijk handig voor bijv. een vpn of ssh verbinding, en dan speciaal servers die meerdere van deze verbindingen verzorgen.

[Little Penguin]

(...) Er is altijd een veel betere / snellere CPU gepland (...)

Omdat mij niet duidelijk was waar de 'Larrabee' nu voor bedoeld is, heb ik het volgende bericht nog eens vlug doorgelezen (nieuws: Intel onthult meer details over Larrabee)

Voor zover ik begrijp gaat het helemaal niet om een processor, maar om een chip die bedoelt is voor gebruik in grafische kaarten.

Edit@Bitage: Ik bedoel een general purpose CPU zoals de x86, ARM of PowerPC gebaseerde CPU's dat zijn.

[Reactie gewijzigd door Little Penguin op 28 juli 2024 08:21]

[Antipater]

Het ligt net iets ingewikkelder. De grafische kaarten en 'normale' x86 processoren zijn de laatste jaren meer naar elkaar toe aan het groeien. Dat betekent dat de GPU's in grafische kaarten voor steeds meer applicaties geschikt worden dan alleen graphics, terwijl de gewone CPU's meer instructies krijgen om de applicaties waar de GPU heer en meester is te versnellen.
Dit samengaan gaat maar tot op zekere hoogte. Je kan het model van de GPU vergelijken met een enorme hoeveelheid lopende banden, een moderne fabriek die een beperkt aantal producten zeer efficient verwerkt. De CPU daaraantegen is meer een alleskunner die intelligent maatwerk kan leveren, maar daardoor veel inefficienter is voor sommige applicaties. Larrabee is nu een soort versmelting van deze twee, met de nadruk op efficientie. Qua ontwerp heeft het wel iets weg van de cell maar dan met behoud van de zwaar verouderde x86 instructieset. Uiteindelijk moet het verschil tussen GPU en CPU helemaal weg gaan vallen wat betreft de instructiesets.

Het lijkt mij trouwens dat de ontwikkelaars die van deze instructiesets gebruik gaan maken helemaal gek zullen worden van al die nieuwe instructies. Er bestaan er nu al een paar honderd, alleen maar voor simd.

[Matis]

Volgens mij gaat het erover om de shaders die nu in een GPU zitten, te gaan gebruiken om een cpu te maken, met meer dan 32 of 64 rekenunits .

Om op deze manier een hoop simpele dingen sneller te berekenen, zoals physx en ook de GPU een beetje preprocessing te geven.

[Bitage]

Voor zover ik begrijp gaat het helemaal niet om een processor

Een GPU is ook een processor hoor Maar verder is het een hybride, dus een CPU en GPU in één, waarmee grafische berekeningen nu ook via x86 gedaan kunnen worden.

Zie ook: nieuws: 'Intel Larrabee gebaseerd op Pentium-core'

[Reactie gewijzigd door Bitage op 28 juli 2024 08:21]

[Verwijderd]

het is idd erg moeilijk te concurreren met tekst in een artikel zonder daadwerkelijk product