Intel lover Larrabee i 2010

[int20h]

Den første waferen med Larrabee-brikker ble vist frem ganske nylig.

 

Les mer

[Gjest Slettet-Pqy3rC]

Jeg har stadig lettere problemer med å forstå hva dette til slutt blir. Skjermkort med x86 instruksjonssett eller cpu med integrert skjermkort ?

[ArneJ.]

Jeg har stadig lettere problemer med å forstå hva dette til slutt blir. Skjermkort med x86 instruksjonssett eller cpu med integrert skjermkort ?

Det blir såvidt jeg har forstått en gpu basere på en matrise med mange, relativt vanlige x86-kjerner som er utstyrt med en egen vektorenhet i tillegg. Vektorenheten skal kunne utføre 16 flyttallsoperasjon pr. klokkesyklus.

[Gjest Slettet-Pqy3rC]

Det blir såvidt jeg har forstått en gpu basere på en matrise med mange, relativt vanlige x86-kjerner som er utstyrt med en egen vektorenhet i tillegg.

Det er hva andre tråder på forumet også konkluderer med så det virker korrekt.

 

Er det da riktig å anta at dette er tenkt som en direkte konkurrent til gForce og Radeon eller er Larabee ment brukt som noe annet ?

[Simen1]

Jeg skjønner heller ikke helt hva Larrabee skal være godt for. Som GPU kommer den ikke til å duge sammenlignet med AMD og Nvidias GPUer. Som generell x86-prosessor kommer den ikke til å duge. Jeg skjønner hvordan den er bygget opp, men ikke hva den skal brukes til.

[Salt kjeks]

Forrige viste Intel den aller første Larrabee-waferen som skal settes i serieproduksjon mot slutten av året.

Forrige hva da? Uke? Helg? Måned? År? Fullstendige setninger takk...

[zicoz]

Jeg skjønner heller ikke helt hva Larrabee skal være godt for. Som GPU kommer den ikke til å duge sammenlignet med AMD og Nvidias GPUer. Som generell x86-prosessor kommer den ikke til å duge. Jeg skjønner hvordan den er bygget opp, men ikke hva den skal brukes til.

 

 

Mener å ha lest noe om at DreamWorks siktet seg inn mot Larrabee, så det kan virke som om de kanskje tenker på å konkurere mot FireGL/Quadro?

[sannheten_666]

Jeg skjønner heller ikke helt hva Larrabee skal være godt for. Som GPU kommer den ikke til å duge sammenlignet med AMD og Nvidias GPUer. Som generell x86-prosessor kommer den ikke til å duge. Jeg skjønner hvordan den er bygget opp, men ikke hva den skal brukes til.

 

Det er snakk om å konkurrere mot CUDA og ATI stream computing (eller hva det nå heter). Den vil være mye lettere å programmere enn nVidia og ATIs løsning pga. at den er x86 basert.

nVidia har jo brukt enhver anledning til å rakke ned på x86, og snakke varmt om "parallel computing". Dette er Intels steg i retning parallel computing, basert på x86 med de fordeler og ulemper som følger. nVidia og AMD vil nok ha løsninger som er mye kraftigere, men vanskeligere å utnytte og mer rigide enn x86.

 

PS: dette har jeg veldig lite greie på, så ikke skyt meg om jeg tar feil

 

Anandtechs artikkel om Larrabee

Endret 17. april 2009 av hardrock_ram

[HKS]

Det er snakk om å konkurrere mot CUDA og ATI stream computing (eller hva det nå heter). Den vil være mye lettere å programmere enn nVidia og ATIs løsning pga. at den er x86 basert.

nVidia har jo brukt enhver anledning til å rakke ned på x86, og snakke varmt om "parallel computing". Dette er Intels steg i retning parallel computing, basert på x86 med de fordeler og ulemper som følger. nVidia og AMD vil nok ha løsninger som er mye kraftigere, men vanskeligere å utnytte og mer rigide enn x86.

Ikke nødvendigvis. Ønsker du å utnytte Larrabee så må man skrive programmer for det eksplisitt. Intel har allerede annonsert at de kommer med sine egne "extentions" til C, ala CUDA.

 

Greit nok at man kan kjøre X86 kode, men sammenlignet med Nehalem så vil ytelsen per kjerne være ganske dårlig, da kjernene i Larrabee mangler ting som out-of-order-execution, branch prediction etc.

 

x86 prosessor i dette segmentet er rett og slett en dårlig idé,

[sannheten_666]

Jeg skjønner heller ikke helt hva Larrabee skal være godt for. Som GPU kommer den ikke til å duge sammenlignet med AMD og Nvidias GPUer. Som generell x86-prosessor kommer den ikke til å duge. Jeg skjønner hvordan den er bygget opp, men ikke hva den skal brukes til.

 

 

Mener å ha lest noe om at DreamWorks siktet seg inn mot Larrabee, så det kan virke som om de kanskje tenker på å konkurere mot FireGL/Quadro?

 

FireGL\Quadro er akkurat de samme kortene som Geforce og Radeon, ofte med mer minne, men med andre drivere. Det er driverne man betaler for i det tilfellet.

[sannheten_666]

Det er snakk om å konkurrere mot CUDA og ATI stream computing (eller hva det nå heter). Den vil være mye lettere å programmere enn nVidia og ATIs løsning pga. at den er x86 basert.

nVidia har jo brukt enhver anledning til å rakke ned på x86, og snakke varmt om "parallel computing". Dette er Intels steg i retning parallel computing, basert på x86 med de fordeler og ulemper som følger. nVidia og AMD vil nok ha løsninger som er mye kraftigere, men vanskeligere å utnytte og mer rigide enn x86.

Ikke nødvendigvis. Ønsker du å utnytte Larrabee så må man skrive programmer for det eksplisitt. Intel har allerede annonsert at de kommer med sine egne "extentions" til C, ala CUDA.

 

Greit nok at man kan kjøre X86 kode, men sammenlignet med Nehalem så vil ytelsen per kjerne være ganske dårlig, da kjernene i Larrabee mangler ting som out-of-order-execution, branch prediction etc.

 

x86 prosessor i dette segmentet er rett og slett en dårlig idé,

 

Javel?

 

Når det gjelder det du sier om programmering, så kan jeg bare sitere fra anandtech:

 

"You have two options for harnessing the power of Larrabee: writing standard DirectX/OpenGL code, or writing directly to the hardware using Larrabee C/C++, which as it turns out is standard C (you can use compilers from MS, Intel, GCC, etc...). In a sense, this is no different than what NVIDIA offers with its GPUs - they will run DirectX/OpenGL code, or they can also run C-code thanks to CUDA. The difference here is that writing directly to Larrabee gives you some additional programming flexibility thanks to the GPU being an array of fully functional x86 GPUs. Programming for x86 architectures is a paradigm that the software community as a whole is used to, there's no learning curve, no new hardware limitations to worry about and no waiting on additional iterations of CUDA to enable new features. You treat Larrabee like you treat your host CPU."

 

Når det gjelder påstanden din om dårlig ytelse pr kjerne, så skriver anandtech dette:

 

"Running a single instruction stream (e.g. single threaded application), the Core 2 can process as many as four operations per clock, since it can issue 4-instructions per clock and it isn't execution unit constrained. The 10-core design however can only issue two instructions per clock and thus the peak execution rate for a single instruction stream is two operations per clock, half the throughput of the Core 2. That's fine however since you'll actually want to be running vector operations on this core and leave your single threaded tasks to your Core 2 CPU anyways, and here's where the proposed architecture spreads its wings.

 

With two cores, each with their ability to execute 4 concurrent SSE operations per clock, you've got a throughput of 8 ops per clock on Core 2. On the 10-core design? 160 ops per clock, an increase of 20x in roughly the same die area and power budget."

 

Når det gjelder konklusjonen din, så vet ikke jeg om du har rett eller ikke, men jeg vil tippe at Intel har overveid dette en smule mer enn deg ...

Forøvrig beklager jeg at mine eneste motsvar blir sitater fra anandtech, men jeg vet ikke noe særlig om dette selv.

Endret 17. april 2009 av hardrock_ram

[HKS]

Nå er det jo snakk om spesialisert hardware, og et mål om å flest mulig kjerner på et fornuftig volum.

 

Når det gjelder det du sier om programmering, så kan jeg bare sitere fra anandtech:

 

"You have two options for harnessing the power of Larrabee: writing standard DirectX/OpenGL code, or writing directly to the hardware using Larrabee C/C++, which as it turns out is standard C (you can use compilers from MS, Intel, GCC, etc...). In a sense, this is no different than what NVIDIA offers with its GPUs - they will run DirectX/OpenGL code, or they can also run C-code thanks to CUDA. The difference here is that writing directly to Larrabee gives you some additional programming flexibility thanks to the GPU being an array of fully functional x86 GPUs. Programming for x86 architectures is a paradigm that the software community as a whole is used to, there's no learning curve, no new hardware limitations to worry about and no waiting on additional iterations of CUDA to enable new features. You treat Larrabee like you treat your host CPU."

DirectX/OpenGL for å skrive GPGPU er bare å glemme. Hvor god grafikkytelsen blir her vet jeg ikke. Intel kommer til å gjøre veldig mye av det AMD og nVIDIA gjør i hardware i software, umulig å si hvor bra det blir, men er ikke spesielt positiv. Husk at Larrabee kommer til å konkurrere med R800/GT300 kort fra AMD/nVIDIA.

 

Når det gjelder å skrive kode som C-program så har man selvsagt en fordel med at det er en X86 arkitiektur, men ønkser man å bruke ekstra vektorenheter som er på Larrabee så må man kode programmene eksplisitt for dette. Intel kommer med et nytt instruksjonssett til dette (Larrabee New Instructions), og disse vil programmeres med en extention til C ala CUDA.

 

Når det gjelder påstanden din om dårlug ytelse pr kjerne, så skriver anandtech dette:

"

Running a single instruction stream (e.g. single threaded application), the Core 2 can process as many as four operations per clock, since it can issue 4-instructions per clock and it isn't execution unit constrained. The 10-core design however can only issue two instructions per clock and thus the peak execution rate for a single instruction stream is two operations per clock, half the throughput of the Core 2. That's fine however since you'll actually want to be running vector operations on this core and leave your single threaded tasks to your Core 2 CPU anyways, and here's where the proposed architecture spreads its wings.

Det er akuratt det jeg sier jo. Single thread ytelse per kjerne er dårlig så frem ikke applikasjonen er skrevet for å bruke Larrabee sine dedikerte vektor-enheter. 2 instruksjoner per klokke er også kun teoretisk.

 

Når det gjelder konklusjonen din, så vet ikke jeg om du har rett eller ikke, men jeg vil tippe at Intel har overveid dette en smule mer enn deg ...

Man kan spørre seg hvilke alternativer Intel har. Til og med AMD som også har gode X86 kjerner har også uttalt at dette ikke er veien å gå.

 

Hvem som får rett til syvende og sist gjenstår å se, vi vet rett og slett ikke nok om Larrabee enda.

 

Jeg jobber selv med forskning rundt bla. GPGPU og jeg mener fremdeles at X86 har ingenting å gjøre i et grafikkort.

[magnemoe]

Det er snakk om å konkurrere mot CUDA og ATI stream computing (eller hva det nå heter). Den vil være mye lettere å programmere enn nVidia og ATIs løsning pga. at den er x86 basert.

nVidia har jo brukt enhver anledning til å rakke ned på x86, og snakke varmt om "parallel computing". Dette er Intels steg i retning parallel computing, basert på x86 med de fordeler og ulemper som følger. nVidia og AMD vil nok ha løsninger som er mye kraftigere, men vanskeligere å utnytte og mer rigide enn x86.

Ikke nødvendigvis. Ønsker du å utnytte Larrabee så må man skrive programmer for det eksplisitt. Intel har allerede annonsert at de kommer med sine egne "extentions" til C, ala CUDA.

 

Greit nok at man kan kjøre X86 kode, men sammenlignet med Nehalem så vil ytelsen per kjerne være ganske dårlig, da kjernene i Larrabee mangler ting som out-of-order-execution, branch prediction etc.

 

x86 prosessor i dette segmentet er rett og slett en dårlig idé,

Så om jeg forstår riktig vil dette være en cpu som vil yte veldig godt om du kjører x86 kode som kan paraliseres nok til å kjøres på alle kjernene, den vil yte betydlig bedre om du kopilerer spesifikt for den, men den vil ikke være så effektiv som et sjermkort til skjemkort bruk.

Ser det som en spesial brikke, superdatamaskiner, tungregning, renderfarms vil ha nytte av den, men den vil kreve for mange store kjerner for å bli et effektivt skjemkort.

Den vil ha mer kraft og fleksiblitet pr kjerne en et skjermkort men betydlig dårligere ne en standard quadcore.

[zicoz]

Med andre ord så kan det stemme at f.eks. DreamWorks vil benytte dette i sin filmproduksjon?

[HKS]

Så om jeg forstår riktig vil dette være en cpu som vil yte veldig godt om du kjører x86 kode som kan paraliseres nok til å kjøres på alle kjernene, den vil yte betydlig bedre om du kopilerer spesifikt for den, men den vil ikke være så effektiv som et sjermkort til skjemkort bruk.

Det er ikke å kompilere spesifikt for arkitekturen. Skal programmet yte betydlig bedre så må applikasjonen skrives om til å bruke Larrabee sine spesielle regneenheter.

 

Med andre ord så kan det stemme at f.eks. DreamWorks vil benytte dette i sin filmproduksjon?

Ja, de vil bruke clustere med mange Larrabee de til å rendre filmen (noe som er en prosess som ofte tar flere uker).

[Imsochobo]

Så om jeg forstår riktig vil dette være en cpu som vil yte veldig godt om du kjører x86 kode som kan paraliseres nok til å kjøres på alle kjernene, den vil yte betydlig bedre om du kopilerer spesifikt for den, men den vil ikke være så effektiv som et sjermkort til skjemkort bruk.

Det er ikke å kompilere spesifikt for arkitekturen. Skal programmet yte betydlig bedre så må applikasjonen skrives om til å bruke Larrabee sine spesielle regneenheter.

 

Med andre ord så kan det stemme at f.eks. DreamWorks vil benytte dette i sin filmproduksjon?

Ja, de vil bruke clustere med mange Larrabee de til å rendre filmen (noe som er en prosess som ofte tar flere uker).

 

Kan de ikke gjøre dette med vanlig GPGPU.

 

Hvis intel ikke greier å lage en kraftig nok gpu ved bruk av X86 processorer med en stort vector cluster.

 

Så vil jeg si at dette blir skrinlagt business, men for dette, trenger vi en felles API for skjermkort.

 

Det er hva jeg tror kommer til å skje, og hva nvidia og amd må gjøre for å ta intel litt.

intel må da begynne ganske bra på nytt, og skrinlegge larabee, hvis den ikke klarer å gi nok ytelse vs tradisjonelle skjermkort.

[ATWindsor]

Det er snakk om å konkurrere mot CUDA og ATI stream computing (eller hva det nå heter). Den vil være mye lettere å programmere enn nVidia og ATIs løsning pga. at den er x86 basert.

nVidia har jo brukt enhver anledning til å rakke ned på x86, og snakke varmt om "parallel computing". Dette er Intels steg i retning parallel computing, basert på x86 med de fordeler og ulemper som følger. nVidia og AMD vil nok ha løsninger som er mye kraftigere, men vanskeligere å utnytte og mer rigide enn x86.

Ikke nødvendigvis. Ønsker du å utnytte Larrabee så må man skrive programmer for det eksplisitt. Intel har allerede annonsert at de kommer med sine egne "extentions" til C, ala CUDA.

 

Greit nok at man kan kjøre X86 kode, men sammenlignet med Nehalem så vil ytelsen per kjerne være ganske dårlig, da kjernene i Larrabee mangler ting som out-of-order-execution, branch prediction etc.

 

x86 prosessor i dette segmentet er rett og slett en dårlig idé,

 

Men det er vel neppe noen som kjøper et produkt som dette for å få god single-core ytelse?

 

AtW

[magnemoe]

Så om jeg forstår riktig vil dette være en cpu som vil yte veldig godt om du kjører x86 kode som kan paraliseres nok til å kjøres på alle kjernene, den vil yte betydlig bedre om du kopilerer spesifikt for den, men den vil ikke være så effektiv som et sjermkort til skjemkort bruk.

Det er ikke å kompilere spesifikt for arkitekturen. Skal programmet yte betydlig bedre så må applikasjonen skrives om til å bruke Larrabee sine spesielle regneenheter.

 

Med andre ord så kan det stemme at f.eks. DreamWorks vil benytte dette i sin filmproduksjon?

Ja, de vil bruke clustere med mange Larrabee de til å rendre filmen (noe som er en prosess som ofte tar flere uker).

 

Kan de ikke gjøre dette med vanlig GPGPU.

 

Hvis intel ikke greier å lage en kraftig nok gpu ved bruk av X86 processorer med en stort vector cluster.

 

Så vil jeg si at dette blir skrinlagt business, men for dette, trenger vi en felles API for skjermkort.

 

Det er hva jeg tror kommer til å skje, og hva nvidia og amd må gjøre for å ta intel litt.

intel må da begynne ganske bra på nytt, og skrinlegge larabee, hvis den ikke klarer å gi nok ytelse vs tradisjonelle skjermkort.

 

Etter det jeg forstår er ikke vanlige skjermkort serlig egnet til spillefilm kvalitet render, meget store textures, raytracing og mer, skjermkort er spesalisert for activX/ opengl realtime rendering. Vet bare at poser, maya og de fleste andre 3d programmer bruker cpu til produksjons render men opengl for preview.

 

Skjermkortene har blitt mer fleksibele, men er ikke enda ikke fleksible nok for denne bruken. Tror Larrabee vil bli dyrere og dårligere for spillbruk men vil muligens stille meget sterkt mot Nvidia Quadro og andre arbeidsstasjons kort siden de vil virke bedre til tungregning og produksjons rendering.

For superdatamaskiner vil larrabee ha en fordel, ved at du vil få masse regnekraft fordelt på svært mange kjerner som du vil kunne kjøre linux eller et annet os på direkte.

[adonay]

Men det er vel neppe noen som kjøper et produkt som dette for å få god single-core ytelse?

 

AtW

 

Well tror egentlig ikke det er en god påstand se hva de sa om atom og hvordan den seller feks....

 

Det må nokk være et marked for denne chippen ellers tror jeg ikke intel hadde satset på den ...

[ATWindsor]

Men det er vel neppe noen som kjøper et produkt som dette for å få god single-core ytelse?

 

AtW

 

Well tror egentlig ikke det er en god påstand se hva de sa om atom og hvordan den seller feks....

 

Det må nokk være et marked for denne chippen ellers tror jeg ikke intel hadde satset på den ...

 

At den ikke har god single-core-ytelse betyr da vitterlig ikke at det ikke er et marked for den? Det finnes andre parametre enn single-core-ytelse.

 

AtW