Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 31 reacties

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.

Intel instructieset roadmap

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.

Intel core en Larrabee roadmap (schatting samengesteld door Tweakers.net)
Geschatte roadmap, samengesteld door Tweakers.net
Moderatie-faq Wijzig weergave

Reacties (31)

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.
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!
AMD heeft SSE5 op de planning staan.
Zie ook: nieuws: AMD: sse5 vanaf 2009 in Bulldozer-core
Nou je zegt daar wel wat... intel gaat steeds harder en harder. AMD daarentegen lijkt stil te staan. Het feit dat intel durft om deels oude concepten los te laten brengt alles alleen maar in een hogere stroomversnelling.
antwoord van AMD?

"Uhhh.... :/ "
tekstvergelijkingsfuncties
Wat moet ik me hier bij voorstellen? unicode support in de CPU?
Hum... ik denk dat je niet verder komt dan strcmp() op hardwareniveau.
Wel cool, wordt veel gebruikt.
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 22 augustus 2008 12:33]

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.
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.
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.
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.
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.
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.
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.
Het wordt natuurlijk helemaal interessant als ze voor elkaar gaan bijspringen wat waarschijnlijk wel de bedoeling gaat zijn.
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?
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.
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.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True