Intel toont Larrabee-wafer

Intel heeft tijdens de IDF in Beijing een wafer met Larrabee-chips getoond. De wafer bewijst dat de Larrabee een grote chip wordt. Volgens Intel-topman Pat Gelsinger moet de processor eind dit jaar of begin 2010 op de markt komen.

Pat Gelsinger toonde de wafer tijdens zijn keynote op de IDF in Beijing, maar de beelden zijn niet in de webcast van Intel opgenomen. Een vertegenwoordiger van de Franse site Hardware.fr wist echter een foto te maken. De site vergelijkt de grootte van de chip met die van de GT200-gpu van Nvidia. Op basis van geschatte die-grootte denkt Hardware.fr dat de Larrabee op 45nm gebakken wordt en nog niet op 32nm, zoals de Westmere-cpu's, waarvan de massaproductie eind dit jaar start.

Gelsinger maakte verder bekend dat Intel inmiddels werkende Larrabee-samples in zijn onderzoeksfaciliteit heeft. Eind dit jaar moet verder de eerste bèta van Intels 'GT'-compiler verschijnen. De GT-taal is geoptimaliseerd voor het schrijven van parallelle programmatuur en moet onder andere de concurrentie met Cuda van Nvidia aangaan.

Reacties (46)

[Pyronick]

Heel mooi spul, ik vraag me enkel af of hun ideeën wel zo reeël zijn.
Het is geen native Direct3D/OpenGL architectuur, alles word geëmuleerd dus efficient is het niet echt.
Daarnaast komt men wederom met een aparte proprietary parallel computing architectuur...

Desalniettemin ben ik erg geïnteresseerd in deze technologie, misschien dat x86 toch niet bedreigt word.

[player-x]

Tja het kan een flop worden of een schot in de roos, dat weet je pas echt als je het uitbrengt.

• Word het op gepakt door ontwikkelaars? (kans is groter om dat men weet dat intel het pushed)
• Hoe makelijk is het om er voor te programmeren?
• Hoe snel is het IRL?

Kijk je naar bv de 48x0 GPU iedereen dacht toen de G200 uit kwam dat het geheel door het nVidia geweld zou worden verpletterd, het tegenovergestelde is min of meer gebeurd.
Ja nVidia heeft de prestatie kroon, maar ATi heeft de prijs/prestatie kroon, en wat nog veel belangrijker is, een veel goedkopere chip dan nVidia om te maken.
nVidia moet zijn top GPU's bijna verkopen tegen kost prijs.

Dit alles zegt natuurlijk niks over of Lrarabee top of flop is, ik denk dat er een aantal dingen zullen zijn waar Larrabee zal uitblinken als een PPU, maar ik betwijfel dat het een goede GPU word in iedergeval niet de eerste generatie.

[hollandismad]

Je neemt hier toch een aantal cruciale punten niet mee in je top vs. flop lijstje:

1) Larrabee kan niet alleen als GPU en PPU ingezet worden maar ook als co-processor.

2) Het feit dat het x86 is en ondersteuning van Intel heeft betekent dat het schrijven van programma's die van zowel CPU als Larrabee gebruik maken gemakkelijker zal zijn dan van CPU en normale GPU.

3) Gezien de recente push naar real-time Raytracing en het feit dat Larrabee daar veel beter in zal zijn dan haar GPU concurrenten(zonder grote veranderingen) is het niet onwaarschijnlijk dat Intel op die manier de GPU markt gaat proberen te veroveren. Helemaal gezien het feit dat het schrijven van een real-time Raytracing enigine voor een game niet zo duur is nog lang duurt.(Een zakje met geld van Intel kan dus wonderen doen.)


Of Larrabee een flop wordt of een succes hangt dus van veel meer af dan de directe concurrentie met de huidige op Rasterization gebaseerde GPU's van Nvidia en ATI/AMD.

[player-x]

2) Het feit dat het x86 is en ondersteuning van Intel heeft betekent dat het schrijven van programma's die van zowel CPU als Larrabee gebruik maken gemakkelijker zal zijn dan van CPU en normale GPU.

Of dit wel zo veel makelijker is, is nog maat af te wachten, men heeft nu al problemen om code te schrijven die optimaal van 2 core's gebruikt maakt, ehhh... hoeveel had Larrabee er ook al weer ???

[Snoitkever]

"Men" heeft er problemen mee ja, maar "men" snapt ook niets van kernfysica, en toch hebben we talloze kerncentrales op deze aardbol. Dat de doorsnee programmeur niet verder komt dan VB wil niet zeggen dat er niet bedrijven zijn die staan te springen om de mogelijkheden die LRB biedt. Er zijn genoeg bedrijven die nu al software schrijven voor platforms als CUDA, of voor complexe supercomputers. LRB is dus heel belangrijk voor Intel, want HPC is een flinke markt met hoge marges, en Intel wil maar al te graag een deel van die taart.

[dmantione]

Vermoedelijk krijgt hij er 32. Dat is klein bier vergeleken met wat ATi en Nvidia doen, die werken met honderden kernen. Grafische applicaties schalen als een tierelier, laat gewoon iedere kern aan een andere pixel rekenen.

[SuperNull]

Ik denk de 'merit' van Larrabee in eerste instantie zal zijn dat de GPU en CPU op de zelfde chip zitten. Dit is aantrekkelijk voor laptops en handhelds.
Voor handhelds is het nu al normaal dat de CPU architectuur 'non standaard' is dus een iets wat afwijkende x86 spec zal geen probleem zijn.

De 3D mogelijkheden van Larrabee zullen wel (netzoals bij de Cell processor) in eerste instantie lastig zijn om optimaal te gebruiken.

[Snoitkever]

Ik wil niet lullig doen, maar jouw informatie klopt echt niet. Larrabee is geen processor, het is een GPU. "Toevallig" een GPU die x86 kan, maar dan nog. Het is bedoeld voor 3D kaarten, zeker niet voor laptops, handhelds, of CPU-vervangende taken. Daarnaast zal Larrabee waarschijnlijk gebruikt gaan worden in de HPC hoek, maar dat is een ander verhaal.
De 3D mogelijkheden van Larrabee zijn bovendien heel makkelijk te gebruiken, aangezien er gewoon DX en OpenGL drivers voor zullen zijn. Alleen de ware hackers zullen hun eigen rendering pipeline voor Larrabee schrijven.

[Verwijderd]

de P in CPU en GPU staan voor processor. Dat er vroeger een duidelijk verschil is bestond tussen plaatjes en databewerking is de laatste 4 jaar niet meer het geval, CPU's doen aan SSE en GPU's doen aan generic processing. Net als je middelvinger vroeger bedoeld was om iets stevig vast te pakken, gebruik je hem nu om letters te typen en mensen te attenderen dat je ze niet lief vindt. Dus als jij een creatieve toepassing vindt voor dit platform kan je dat ook zeker gebruiken. Zeker voor handhelds,laptops kun je zo'n ding prima toepassen als je er maar genoeg in geloofd om er tijd en geld in te investeren.

[KilZone]

Voor de volledigheid moeten er toch een aantal dingen rechtgezet worden... De P in CPU en GPU staat voor processing en niet voor processor, met de bijbehorende U voor unit. De letter(s) ervoor de C, de G of GPG duiden aan wat deze PU kan. Respectievelijk staat het voor central, graphics en general-purpose graphics. De meest bekende vertaling van CPU in het Nederlands is processor, maar dit eigenlijk incorrect en het zou moeten zijn CVE, wat staat voor Centrale VerwerkingsEenheid.

CPU vs (GP)GPU
Hoewel het verschil de afgelopen jaren kleiner is geworden, is er nog steeds een duidelijke splitsing tussen een CPU en een GPU. Je noemt zelf al de SSE (Streaming SIMD Extensions), wat in feite Floating Point Operations mogelijk maakt via de CPU, maar dit maakt het geen GPU (kom ik zo op). De GPU (en dan met name de GPGPU) heeft de mogelijkheid op via technieken zoals NVidia's CUDA ook CPU berekeningen uit te voeren, dit maakt het echter niet hetzelfde als de CPU.

CPU
De CPU is ontworpen voor maar één ding, snelheid. Het ontwerp is zo uitgewerkt dat een stroompje de korste route door de wafer kan lopen. Een erg versimpeld, maar dagelijks voorbeeld is de TomTom... zet die op de korste/snelste route en je bent zo snel als mogelijk op je bestemming. In de computerwereld betekent dit dat je zo snel als mogelijk een antwoord hebt. Echter als iedereen in Amsterdam als bestemming Rotterdam aangeeft en aanvinkt 'snelste route', dan krijgen we een gigantische file A4. Dit is ook zo in de computer, als je al je programma's tegelijk zou starten, dan moeten ze achter elkaar door de route heen, omdat de CPU niet ontworpen is voor parallel processing... Nu we wat verder zijn in de tijd hebben we technieken zoals HyperThreading (alweer verouderd), Dual Core en Quad Core. Wat ten dele parallel processing mogelijk maakt. Echter zal de processor altijd direct naar de monitor tekenen (tegen de GPU die in een buffer een frame teken en dan print op het scherm) en dus altijd een 'trage refresh rate' hebben. De CPU is handig voor complexe berekeningen die niet paralell kunnen, nummeriek integreren (als simpel voorbeeld).

GPGPU
De GPU is ontworpen voor iets anders, namelijk het zo veel mogelijk parallel berekenen. Het resultaat hiervan is dat de stroompjes niet per definitie de snelste route kiezen en dus het aantal MHz zit beduidend lager dan dat in een CPU. Met andere woorden als je maar één enkele berekening hebt, verliest de GPU met grote achterstand van de CPU. Heb je echter gigantisch veel berekeningen (zeg een afbeelding die je moet tekenen) dan is het parallel berekenen vele male handiger. (Zie het als honderd snelwegen tussen Amsterdam en Rotterdam...) Nu we wat verder zijn hebben we de GPGPU geintroduceerd (waar de Larrabee een vorm van is) die ook voor wat allerdaagse taken gebruikt kunnen worden. Dit is handig voor het niet intensieve soort berekening (simpele rekensommen) waarvan je er heel veel moet doen, bijvoorbeeld MD5 collision (breken van encryptie).

Larrabee
De Larrabee combineert (volgens Intel) het beste van beide werelden. Een chip die een stroompje zowel de korste route door de wafer laat nemen, als mede het mogelijk maakt parallel te berekenen. Wat theoretisch de snelheid van de computer drastisch moet verhogen (mits goed toegepast). Dit maakt het echter eerder een GPGPU met CPU capaciteiten dan een CPU, waardoor de bewering van Snoitkever waar is.

[Snoitkever]

Ik weet dat zowel GPUs als CPUs processoren zijn, maar het lijkt me toch logisch dat ik gezien de context met "processor" een "CPU" bedoelde.

Daarnaast is het gewoon niet waar dat LRB gebruikt kan worden in laptops of handhelds, om meerdere redenen. De belangrijkste lijkt me toch logisch, namelijk energieverbruik. LRB is bedoeld als desktop-GPU chip, en zal dan ook zoveel stroom verbruiken dat het gewoon in eerste instantie niet gebruikt kan worden in dergelijke situaties. Hetzelfde geldt voor hitte. Een dergelijke chip brandt gewoon door elke handheld toepassing heen. Zie jij jezelf al met een RV770 van 90 graden in je broek rondlopen?
Ten tweede is LRB gewoon niet los in de verkoop. Het is een GPU, en wordt net als NVIDIA en AMD doen verkocht aan AIB partners die de kaart maken en in de winkel brengen. Je kan ook geen losse NVIDIA of AMD GPUs kopen, en hetzelfde geldt straks ook voor LRB.

Uiteraard zijn dit dingen die in de toekomst vast aangepakt zullen worden, en uiteindelijk zien we misschien ook wel een hybride CPU/GPU, afgeleid van LRB, maar reken er de eerste jaren nog maar niet zomaar op.

[NC83]

Ik zou de Larrabee niet met de cell vergelijken hoor, Larrabee is een dedicated GPU en de cell is een CPU.

Ik heb het idee dat de Larrabee niet van dezelfde fout als de Cell gaat hebben. De Larrabee zal waarschijnlijk symmetriche cores hebben waardoor het programmeren voor een dergelijke architectuur en stuk makkelijker wordt. Een programmeur hoeft voor deze chip niet na te denken over op welke core het programma moet draaien zoals bij de cell.

[Snoitkever]

Wat is wel "native Direct3D/OpenGL" dan? Een moderne GPU is zo ontzettend generiek dat je ze al bijna als gewone processor kan gebruiken. LRB heeft toevallig een x86 instructieset, maar heeft verder veel meer gemeen met een GPU dan met een CPU, en ik denk dat de volgende generaties AMD en NVIDIA chips ook meer en meer op een generieke processor (en dus op LRB) gaan lijken.

[dmantione]

Hmmm, nee, de Larrabee heeft niet meer gemeen met een GPU dan een CPU, hij heeft het meest gemeen met een x86-processor met heel veel kernen. Een echte GPU doet nog altijd veel functies in hardware (z-buffering, mipmapping, interpolatie) en doet niet aan cachecoherentie wat bij een CPU juist wel erg belangrijk is. De Larrabee zit in deze volledig aan de CPU-zijde. Bovendien zijn de rekenkernen bij een GPU veel primitiever (hun aantal is echter veel groter).

[Snoitkever]

Hoeveel x86-processoren met heel veel kernen ken je dan? Ik ken er geen namelijk. Wel een aantal GPUs met veel meerdere "cores". LRB mag dan x86 uitvoeren en gebaseerd zijn op oude Pentium cores, moderne CPUs hebben meestal bergen cache, branche-prediction, OoOE en meer van die ongein, en LRB heeft dat allemaal niet. Omgekeerd hebben CPUs doorgaans ook geen 16-wide SIMD eenheden of texture units. En als LRB eerder gewoon een CPU is, waarom hebben we dan de Larrabee New Instructions nodig?

Niet dat ik wil ontkennen dat Larrabee niet ook gewoon een CPU is. De chip zou zelfs gewoon een normaal OS kunnen draaien, maar dat is niet mijn punt. Ja, LRB heeft alle x86 features, maar het verschilt verder zo radicaal van een gewone CPU, en leent zoveel van moderne (en zeker toekomstige) GPUs dat het gewoon in die categorie valt. Dat was toch ook gewoon het doel van LRB?

[dmantione]

Hoeveel x86-processoren met heel veel kernen ken je dan? Ik ken er geen namelijk. Wel een aantal GPUs met veel meerdere "cores".

Kijk eens naar de Niagara-processoren. Die zijn dan Sparc, ze komen in ontwerp erg overeen met de Larabee. Zelfs het aantal threads, 4 per kern, komt overeen.

LRB mag dan x86 uitvoeren en gebaseerd zijn op oude Pentium cores, moderne CPUs hebben meestal bergen cache, branche-prediction, OoOE en meer van die ongein, en LRB heeft dat allemaal niet.

Klopt, de Larabee is gebaseerd op de oorspronkelijke Pentium en die had dat niet. Desondanks was de Pentium toch een volwaardige processor, het feit dat deze funcitonaliteit ontbreekt is geen argument dat de Larabee geen processor is.

Omgekeerd hebben CPUs doorgaans ook geen 16-wide SIMD eenheden of texture units.

GPU's hebben doorgaans ook geen 16-brede SIMD-eenheden. Zoals gezegd, GPU's gebruiken hele primitieve kernen, maar het aantal is nogal groot. De recente Radeon's hebben 800 kernen, dat is dus ordes meer dan de Larabee. De kernen zijn geen volwaardige processorkernen, ze zijn in staat de de HLSL of GLSL uit te voeren, maar ook niet mee dan dat.

De textureunit is het belangrijkste GPU-kenmerk dat de Larabee heeft.

En als LRB eerder gewoon een CPU is, waarom hebben we dan de Larrabee New Instructions nodig?

Een x86-kern is (per definitie) al redelijk complex. Het aantal kernen dat je op een die kwijt kunt zal dus altijd lager liggen dan je bij echte GPU-kernen kan bereiken. Het gevolg is dat, om met de meerdere teraflops die een GPU heeft te kunnen concurreren, de rekenkracht per kern omhoog moet. De meest logische methode is de SIMD-eenheid te verbreden.

Bovendien moet het mogelijk zijn de SIMD-eenheid efficiënter te gebruiken, immers, de 800 losse kernen van een Radeon kunnen allemaal aan onafhankelijke data rekenen, bij SIMD moeten gegevens in array-structuren worden aangeboden.

Larrabee New Instructions voorzien in de bredere SIMD-eenheid en in instructies om gegevens die niet in array-vorm staan alsnog in een SIMD-register te krijgen. Dit is op GPU-gebied volledig onverkend terrein.

Niet dat ik wil ontkennen dat Larrabee niet ook gewoon een CPU is. De chip zou zelfs gewoon een normaal OS kunnen draaien, maar dat is niet mijn punt. Ja, LRB heeft alle x86 features, maar het verschilt verder zo radicaal van een gewone CPU, en leent zoveel van moderne (en zeker toekomstige) GPUs dat het gewoon in die categorie valt. Dat was toch ook gewoon het doel van LRB?

Ik zou de Larrabee definiëren als een poging om dezelfde prestaties die specialistische hardware leveren te behalen met generieke hardware. Als dat lukt hebben we geen specialistische GPU-hardware meer nodig en de Larrabee heeft een aantal nieuwe concepten die de zogeheten "Stream"-rekenkracht van een CPU flink te verhogen, mogelijk tot GPU-niveau's, wat het mogelijk maakt de GPU in software te implementeren.

Of Intel daarin slaagt zal moeten blijken. Zowel ATi als Nvidia hebben aangegeven een Larrabee-achtig ontwerp in het verleden overwogen te hebben, maar dat het voor hen niet zinvol leek om de 3D-oorlog te winnen. Je moet er dus rekening mee houden dat de Larrabee niet de snelste GPU gaat zijn en het moet hebben van zijn x86-compatibiliteit en grotere flexibiliteit.

[Snoitkever]

Oke, laten we de "waar lijkt het op" discussie laten rusten, de waarheid ligt toch ergens tussen GPU en CPU.

Echter:

GPU's hebben doorgaans ook geen 16-brede SIMD-eenheden. Zoals gezegd, GPU's gebruiken hele primitieve kernen, maar het aantal is nogal groot. De recente Radeon's hebben 800 kernen, dat is dus ordes meer dan de Larabee. De kernen zijn geen volwaardige processorkernen, ze zijn in staat de de HLSL of GLSL uit te voeren, maar ook niet mee dan dat.

Hier zul je toch echt even aan je theorie moeten gaan werken 800 kernen mijn aars, zou AMD willen. Zelfde verhaal bij NVIDIA, waar marketing je wil laten geloven dat ze daadwerkelijk 240 "processoren" op een chip hebben weten te proppen. No way. Dat is allemaal SIMD.

G200 is het makkelijkst uit te leggen waarschijnlijk. G200 bestaat uit 10 clusters van 3 "processors". (Beyond3D gebruikt de term Streaming Multiprocessor, SM). Elke SM heeft 8 scalar ALU's (Arithmetic Logic Units). Deze blokjes logica kunnen optellen, aftrekken, vermenigvuldigen, etc. Dit is wat NVIDIA een "stream processor" noemt, maar dat is onzin. Elke SM is namelijk gewoon een SIMD eenheid, en de 8 ALUs kunnen alleen dezelfde operatie uitvoeren. Oftewel, G200 bestaat gewoon uit 30 "cores" met elk een 8-brede SIMD eenheid. Want naast de SIMD logica heeft elke SM ook zijn eigen "scheduling" logica om de hele SM aan te sturen, een stuk cache, een double precission ALU, en fixed function interpolatieeenheden.

RV770 is een zelfde verhaal, maar heeft complexere ALUs. 4 simpele en 1 complexe ALU vormen samen een blok van 5, en elke "core" van RV770 heeft dan weer een SIMD met 16 van deze eenheden. De chip zelf heeeft dan weer 10 van deze "cores".

Zie je al waar Larrabee op lijkt? En ja, G200 en RV770 hebben meer fixed function logica dan Larrabee. Larrabee komt echter pas in Q4 2009 op z'n vroegst, en anders pas in Q1 2010. De trend in GPU ontwerp is de laatste jaren geweest om steeds minder fixed function logica te hebben, dus laten we eerst afwachten wat G300 en RV870 en chips daarna ons brengen voordat we LRB als revolutionair bestempelen.

[Reactie gewijzigd door Snoitkever op 26 juli 2024 10:00]

[Amanoo]

Ik dnek niet dat x86 überhaupt bedreigd wordt.
Misschien verliest het op een paar fronten, maar voor bijvoorbeeld gaming lijkt het me erg moeilijk zomaar over te gaan.
Of we moeten allemaal stoppen met pc-gaming en een Xbox of zo nemen.
Zie ik niet zo snel gebeuren.
Zomaar een nieuwe architectuur introduceren in de pc-gaming wereld gaat ook niet zomaar gebeuren.
Niet nu er zoveel games zijn die we niet meteen willen opgeven.
Of je moet twee van die dure game pc's kopen, 1 x86, en 1 andere architectuur, maar ik kan me niet voorstellen dat ik de enige ben die daar het geld niet voor heeft.

[appel437]

of een nieuwe processor die X86 emuleert. niet erg efficient... maar als deze processor toch zoveeel sneller is kan het wel.
het probleem is dat de meeste mensen de pc pas na 3 jaar vervangen ofzo... en dus kan je nog niet effiecient nieuwe programma's uitbrengen omdat die niet op x86 werken...

[MSalters]

of een nieuwe processor die X86 emuleert. niet erg efficient...

Je weet dat elke recente "X86" processor - pak'm beet uit de laatste 10 jaar - de X86 al emuleert? Ze werken allemaal intern met andere micro-ops, en vertalen x86 code on the fly naar die interne ISA.

[TheGhostInc]

voor bijvoorbeeld gaming lijkt het me erg moeilijk zomaar over te gaan.
Dit is echt 100% de "schuld" van Microsoft en de consumenten die daar geen probleem mee hebben.

Bijvoorbeeld OpenGL is al sinds het begin platform onafhankelijk en Linux draait op praktisch alle architecturen. Een programma dat geen platform specifieke aanroepen gebruikt zal dus overal op te draaien zijn. Nu is het al zo dat voor windows 64bit al aparte stukken code zijn geschreven. Dan moeten ze alleen nog een universele executable (of beter gezegd loader) maken die op alle OS-en de juiste compilatie bij elkaar zoekt.

PC Gaming is prima over te zetten, maar zolang groot machten als Microsoft maar ook EA Games (die hebben ook weinig zin in extra werk) zich daar niet of nauwelijks voor inspannen zal het niet gebeuren. Technisch is er geen enkele reden....

[MSalters]

Nee dus. Linux is geen tovermiddel. Een programma gecompileerd voor Linux x64 draait niet op Linux x86, laat staan op Linux-ARM9. "Compilaties" kun je niet bij elkaar zoeken. Universal binaries werken op de Mac, maar dat zijn simpelweg x86 en Power binaries die in 1 file geduwd zijn. Als je OSX (Darwin) naar de ARM port, dan doen die zogenaamde universele binaries het ook niet meer.

[Goderic]

Is het dan niet mogelijk om die programma's simpelweg te hercompileren?

[isama]

idd, de source half gecompiled op de instalatie cd/dvd/het rarretje, en dan tijdens de installatie compilen naar het os/de arch naar keuze.

[Verwijderd]

Lol, zal het makkelijker voor worden voor de gemiddelde gebruiker

[robvanwijk]

Nagenoeg elk programma dat je wilt gebruiken laat je een installer downloaden, niet rechtstreeks de executable. Als je die installer platform-onafhankelijk kunt maken (hetzij met een universal binaries truc: alle "smaken" in één bestand bij elkaar dumpen, hetzij via een java truc: schrijven in een taal die wordt gedraaid op een virtual machine) dan zou dat best kunnen werken hoor.
Tuurlijk, de installatie zal er niet sneller op worden; in plaats van alleen bestanden uitpakken moet er een (halve) compilatie worden uitgevoerd, maar dat is op zich niet onoverkomelijk. De gebruiker hoeft hier in elk geval helemaal niks van te merken, dus het blijft net zo makkelijk.

Als je in je OS een extra system call toevoegt met ongeveer de betekenis "hier heb je code in een intermediate taal, compile die voor me naar native code" dan ben je al een heel eind. Als de OS-fabrikanten dat allemaal ondersteunen (lees: als iemand een hack bedenkt om dat op Windows ook te laten werken) dan zou je zelfs OS-independent kunnen zijn met alleen een kleine select-case statement in je installer.

[Verwijderd]

Klinkt als Java. Java code wordt gecompileerd naar "byte code" en de JVM (Java Virtual Marchine) die platform specifiek is vertaald het naar de juiste machine code.

Het kan dus en is er zelfs al jaren. Het enige nadeel is echter dat die on the fly compileren een kleine performance decrease geeft.

Zie ook http://en.wikipedia.org/wiki/Java_virtual_machine.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 10:00]

[Verwijderd]

Zeer mooie ontwikkeling dit. Ook al zijn dit kleine CPU's, maar zijn programmatuur is gebaseerd op dat van het vergelijkbare GPU. Dat zou een stuk sneller kunnen gaan dat de huidige processoren.

Ook mede dank het feit dat er multiple cores zijn geeft mij een goed gevoel. Deze technologie hoeft ook niet alleen voor mainstream processoren gebruikt te worden, maar (aanzienlijk) ook voor embedded devices. Maar ook zal dit een goede uitkomst kunnen zijn voor server, met name MySQL databases en/of PHP websites. En misschien zelfs nog extensies gebruiken zoals Python op een website (Een geoptimaliseerde versie ervan, ALS dat er komt).

Ja, ik zie de toekomst van Larrabee (En die opvolgende architecturen gebaseerd op Larrabee) heel erg goed.

[Bitage]

De GT-taal is geoptimaliseerd voor het schrijven van parallelle programmatuur en moet onder andere de concurrentie met Cuda van Nvidia aangaan.

Oh nee hè, niet nog zo'n taal Ga nou eens voor één keer met zijn allen goed rond de tafel zitten en maak met elkaar nou eens één taal. OpenCL is al een heel eind op weg, helaas vinden de grote chipbakkers het natuurlijk weer nodig om een eigen ding te brouwen. Jammer, want nu heb je dus 'tig verschillende talen voor 'tig verschillende apparaten, terwijl het veel mooier en netter is om er één te hebben die op al die dingen werken.

[Reactie gewijzigd door Bitage op 26 juli 2024 10:00]

[Fiander]

Die is er toch al ( bijna ) ??
Je mag één keer raden......... DX 11.........
Word door zowel AMD als Nvidia als Intel ondersteunt straks, en gaat ondersteuning bieden voor Cuda achtige dingen.

[Pyronick]

Ach ja, straks hebben we AMD/ATI Stream, nVidia CUDA, Intel GT en toch kunnen ze allemaal overweg met DirectX 11 compute shader en OpenCL.

[NoResult]

Intel zit wel in het consortium dat de OpenCL standaard beheert (Khronos Group) - dat is toch op z'n minst hoopgevend. Het probleem met OpenCL is dat er nog geen echte implementatie van bestaat. Intel zal zich niet uitsluitend richten op iets dat zich nog moet bewijzen lijkt me.

[Reactie gewijzigd door NoResult op 26 juli 2024 10:00]

[flippy]

ik ben eigenlijk best benieuwd wat zo'n wafertje kost die hij daar in zijn handjes heeft.

(gezien de prijzen van de i7 )

[Timfonie]

Geweldig om dat 'prestatie-scherm' (CPU-usage history) te zien.
Inderdaad 64 cores.

Mooi om te weten dat wat ooit enkel leek op een 'proof of concept' binnen een jaar echt op de markt gaat komen.

[Reactie gewijzigd door Timfonie op 26 juli 2024 10:00]

[g0tanks]

Het zijn 32 cores en 64 threads.

[tdw]

Prestatiescherm dus

[trippelb]

Wat je daar ziet is niet een larrabee gpu, maar de cpu belasting van een 4 socket octocore nehalem server opstelling met hypertreading ingeschakeld (4*8*2)=64

Dat is overigens ook een leuke opstelling, maar heeft niks met deze larrabee te maken.

Verder claimt de bron site hardware.fr dat het om een diesize ter grootte van een gt200 gpu gaat, maar dan op 45nm gebakken. Als dit waar is dan hebben we het wel over belachelijk grootte gpu's. De prestaties moeten wel belachelijk goed zijn, anders zijn ze immens inefficient bezig.

@grizzlybeer, idd, foutje, al die termen ook , ik heb het verbeterd dankje

[Reactie gewijzigd door trippelb op 26 juli 2024 10:00]

[Verwijderd]

Wat je daar ziet is niet een larrabee gpu, maar de cpu belasting van een 4 socket octocore nehalem server opstelling met virtualisatie ingeschakeld (4*8*2)=64

Hyperthreading

[Verwijderd]

Als je de link wil bekijken moet je een spatie achter de .jpg tikken en dan enter drukken. Dan werkt het wel

[Triek-Meister]

@g0tanks
Volgens de afbeelding ziet hij toch echt 64 cores.
Deze text had aan het bericht van g0tank moeten hangen

[Reactie gewijzigd door Triek-Meister op 26 juli 2024 10:00]

[g0tanks]

Als je in de task manager kijkt op een Core i7 PC zie je ook acht 'cores'. Dit komt door hyper threading, elke core heeft twee threads en zo heb je zogenaamd acht cores.

http://en.wikipedia.org/wiki/Hyper-threading