Intel Larrabee mot AMD og Nvidia

[Brusfantomet]

Spillutviklere koder ikke spesifikt mot hver GPU de programmerer mot DirectX eller OpenGL. Larrabee vil kunne støtte begge og vil dermed ikke medføre noe ekstraarbeid for de som utvikler spill.

 

Tenkte mer på ekstrafungsjoner som kansje kommer i tillegg, som HD 4000 seriens teselator (som ikke er kompatibel med dx 11).

[Anders Jensen]

Full cache coherency vil trolig begrense kraftig både antall kjerner og gi mye dårligere latency enn grupperingsmetoden til GPUer. Larrabee kommer altså til å være avhengig av god separasjon av trådene akkurat som GPUer.

Ja det virker som en håpløs ordning i det lange løp. Det vil nok ikke slå inn så kraftig så lenge de har implementasjoner på mindre enn ~50 kjerner, men når det blir flere kjerner så bli også trafikken mye tyngre. Helt klart en nødvendighet å få inn flere adresserbare minneområder for å kunne få bedre eksplisitt parallellitet helt fra compile time.

 

En annen ting er jo valget av ISA... For grafikk og tungregning er det ikke så stort problem siden x86 delen knapt nok vil bli berørt og vektordelen fungerer veldig fint på tungregningen. For mer general purpose prosessering blir det imidlertid vanskelig å få utnyttet kjernen godt da slike algoritmer typisk ikke er så avhengig av tallknusing, men heller kjører kontroller på verdier og hopper rundt i en større kode. til dette er en smal in-order x86 kjerne omtrent det dårligste du kan få, nest etter de kjernene du finner i dagens GPU som har veldig underdimmensjonerte og delte kontrollenheter.

 

Som nevnt før; Kan jo bare håpe på at Poulson setter en stopper for alle disse stusselige massivt parallelle CPU designene som Larrabee samt GPGPU. Får bare krysse fingrene for at Intel bryter sin konsekvente tradisjon med å utsette IPF prosjektene inntil de er utdaterte ved lansering.

Poulson will be based on a new ultra parallel micro-architecture focused on delivering the best scalable performance, reliability and flexibility. This new micro-architecture takes parallelism to the next level by providing significantly more cores, more threads and more instructions per cycle.

Riktig vei å gå! Endret 6. juni 2009 av Anders Jensen

[Theo343]

Jeg liker Poulson, det gir meg sterke assosiasjoner til Pålsbu våtflua jeg fisket med sammen med bestefar i hallingdal som liten pjokk *ler*. Men av en eller annen grunn husker jeg alltid også Poulson som "Poulsbo" som er en by i Washington.

 

Ellers andre mindre hyggelige assosiasjoner kanskje:

John Garlick Llewellyn Poulson (April 14, 1910 - January 31, 1993) was a disgraced British architect who caused a major political scandal when his use of bribery and connections to senior politicians were disclosed in 1972.

Endret 6. juni 2009 av Theo343

[Simen1]

- Poulsbo er kodenavnet for et brikkesett til Atom.

- Poulson er kodenavnet til den nye Itaniumen

 

Ikke rart man blir forvirret med alle disse kodenavnene.

[Theo343]

Visste jeg hadde hørt Poulsbo i IT sammenheng, takk hehe

[Kirchhoff]

Litt om Larrabee: http://techreport.com/discussions.x/16920

[tjomi]

Såvidt jeg har forstått vil også Larrabee basere seg på eksplisitt parallelprosessering. Så hvorfor skulle det være noe enklere å benytte det en CUDA/openCL?

 

Fordi CUDA/openCL støtter ikke visse ting og funksjoner (som rekursjon), mye pga. kjernene.

Med Larrabee så vil man få med en fullverdig CPU til å fikse slike ting.

[tjomi]

For GPU må du forholde deg spesielle programmeringssåpråk som tvinger programmerer til å forholde seg til trådgrupper og et stort sett separate adresseområder. Det kan over hodet ikke sammenlignes med programmering for Larrabee.

 

øh.. hæ?

Siden når ble C, C++ og Python spesielle programmeringsspråk?

Og separate adresseområder er bare det at du bruker minne på GPU'en, ser ikke helt hva problemet der er.

[tjomi]

Full cache coherency vil trolig begrense kraftig både antall kjerner og gi mye dårligere latency enn grupperingsmetoden til GPUer. Larrabee kommer altså til å være avhengig av god separasjon av trådene akkurat som GPUer.

 

Se gjerne på kjernene som en soldat. Larrabee bygger en hær av soldater som er under direkte kommando av hærsjefen. ATI/Nvidia bygger en hær av soldater i et større rang-system med flere nivåer av mellomledere. (troppsjefer, kompanisjefer, bataljonsjefer) I Larrabee-hæren vil hærsjefen bli overbelastet med småoppgaver som burde vært delegert. På den andre siden trenger bare Laraabees soldater ett mellomledd for å kommunisere, men mellomleddet vil trolig bli en flaskehals. GPUer har et mer tungvint kommunikasjon mellom soldater som ikke er organisert sammen, men mellomlederne vil i hvert fall ikke ha noe problemer med å ta unna jobben og delegere jobber fornuftig mellom grupperingene.

 

</atter en av de dumme analogiene>

 

Ja, en dum analogi, spesielt siden den er gal og noe missvisende.

 

Først å fremst så er det ingen oppdeling i ATI\Nvidias GPGPU systemer, du har et gitt antall kjerner som alle kan gjøre den samme tingen.

Skjønner ikke helt hvordan kommunikasjonen imellom dem skulle være så tungvint, spesielt når de deler samme minneområdet.

Problemet er når det skal gjøres noe som GPU'en ikke støtter, som rekursjon. Det går ikke og program må skrives slik at de ikke gjør noen rekursjones, noe som i seg selv kan føre til dårlig ytelse.

Det som er positivt med Larrabee er at den kan kan gjøre alt en vanlig CPU kan. Det og at den har direkte tilgang til alle resursene på maskinen.

 

Det at Larrabee har en flaskehals med at den vil bli overbelastet med småoppgaver som burde vært delegert. delegert hvor?

Det virker som om det er en missforståelse om at Larrabee vil ha en CPU kjerne, og flere GPU kjerner. det er veldig feil.

Alle kjernene er er "sammensmelting" av CPU og GPU, og ingen er mere avansert en noen andre.

[Simen1]

Du kan se kjerne-hierarkiet i prinsippskissene på disse sidene:

http://www.bit-tech.net/hardware/graphics/...adeon_hd_3870/4

http://www.rage3d.com/reviews/video/atirv7...770-diagram.jpg

http://www.xtremesystems.org/forums/showthread.php?p=3598101

http://www.xbitlabs.com/articles/video/dis...itecture_7.html

http://www.xbitlabs.com/articles/video/dis...re_2.html#sect0

 

Nvidia:

http://www.anandtech.com/printarticle.aspx?i=3334

http://www.anandtech.com/showdoc.aspx?i=3334&p=2

http://www.bit-tech.net/hardware/graphics/...ecture-review/4

 

Stream processors that execute vertex, geometrical and pixel shaders are organized as 4 SIMD units consisting of 16 shader processors, each of which incorporates 5 scalar ALUs capable of executing one FP MAD instruction per clock cycle

[Anders Jensen]

tjomi: Jeg tror ikke du er helt med på premissene som diskuteres.

 

1) Ja du kan programmere med standard programmeringsspråk mot GPU, men da utnytter du kun en brøkdel av kapasiteten og det kan vel diskuteres hvor interessant det er å utvikle software for en GPU hvis resultatet er marginalt bedre enn hva du får ut av kun en CPU sokkel.

 

2) En GPU har MANGE adresseområder. Larrabee har ETT, i likhet med vanlig CPU, men separat fra hovedminnet til maskinen i første omgang. Senere generasjoner skal vist nok være sokkelkompatible med Xeon og bruke samme minne som CPU.

 

På Nvidia sin G80 chip som er den jeg kjenner best så er det flere separate minneområder med egne aksessmetoder og egne ytelsesparametre og begrensninger i det delte minneområdet som er implementert som off-chip DRAM på skjermkortet. Videre har hver enkelt multiprosessor som består av flere streaming processor (SP) ett eget adresseområde felles for alle SP i multiprosessoren. Multiprosessorene er igjen organisert i Texture/Processor Cluster (TPC) med egne minneområder. Summer det opp og du får flere titalls adresseområder (over 40 for GT200 bare internt på brikken) som kan og må adresseres separat. Kompilatorer i dag er ikke i nærheten av å kunne gjøre dette effektivt så det er stort sett opp til programmereren. Da vi på jobben min vurderte å bygge om koden vår til å kjøre på nvidia G80 fant vi at å få portet C koden til kjørbar kode for G80 var et relativt langt arbeid. Det som virkelig slo ut var det enorme arbeidet, kanskje 80-90% av tiden, som måtte til for å få ut noe i nærheten av ytelsespotensialet. Kombiner dette med at fremtidige GPUer vil endre layout på minnehierarkiet og at nvidia er blant de som er minst sannsynlig for å lede ann i det lange løp så ble det lett å velge clustering på vanlig x86 servere. Hadde Larrabee vært ute så ville kanskje dette endret seg siden fremover kompatibiliteten er langt sikrere med kun ett minnehierarki. Faktisk er det sannsynlig av koden lett kunne portes til å kjøre på vanlig x86 eller annet ISA server.

 

3) Den sentraliseringen som Simen1 lager en, noe klønete, analogi til er cache coherency mekanismen som ikke er en sentralisert enhet du kan sette fingeren på i en diephoto, men en distribuert funksjon som finnes i hver eneste cache. Det er altså ikke en sentral ressurs, men en distribuert ressurs som alle slåss om og som i sin natur blir mindre effektiv jo større systemet blir. Litt på samme måte som CSMA/CD (ethernet) nettverk fungerer hvis du kun har hubber og ingen svitsj eller ruter. Trafikk belastningen øker med kvadratet av antall noder. I tilfelle nettverket fordi det blir mange kollisjoner,i tilfellet larrabee fordi alle cache enhetene må kommunisere med alle de andre hver gang de skal bli enige om hvem som eier hvilke data og hvem som har nyeste versjon. På en GPU er tilsvarende funksjonalitet håndtert ved compile time så funksjonen finnes ikke i hardware, kun bussene med kontrollenheter og DMA som kan flytte data rundt. Dette skalerer mye lengre, men er også mye mer komplisert å programmere.

Endret 8. juni 2009 av Anders Jensen

[tjomi]

Hei.

På det første punktet vil jeg hevde at jeg tar rett.

Hvis du ser på CUDA siden til Nvidia og eksemplene der så ser du at de fleste bruker C eller C++.

Eller her hvor de fikk 600x fartsøkning, og de brukte C.

Språket man bruker har ingenting å si her, for vi bruker jo Nvidias egen kompilator for å generere maskinkoden.

Skulle man få bedre ytelse en C så måtte man vel nesten ha brukt assembly, men det er når man tenker på x86 systemene.

 

Jeg var ikke oppmerksom på at de første generasjonene med Larrabee hadde eget minne. noe som tar litt av vitsen med larrabee vekk om du spør meg.

 

Min erfaring er fra to GeForce 9800 GT kort(hakke peiling på hvilken chip). Og erfaringen fra det var at vi trengte bare å bry oss om det delte minneområdet, resten fiksa GPU'en selv. Nå vet ikke jeg om dette var pga kompilatoren eller en annen arkitektur i forhold til G80 kortene. Men i hovedsak så trengte vi ikke bry oss om selve minnearkitekturet.

Skal faktisk sjekke litt mere på akkurat det der.

 

Men jeg forstår ikke helt hva du mener med at kompilatorer ikke kan gjøre det effektivt. Etter min viten finns det bare en CUDA kompilator, og for meg og mitt prosjekt var den ihvertfall effektiv.

 

Når dere vurderte å porte koden deres. Var det da å porte den til et annet språk(i såfall hvilket), eller å gjøre den mer parallel?

[HKS]

Jeg var ikke oppmerksom på at de første generasjonene med Larrabee hadde eget minne. noe som tar litt av vitsen med larrabee vekk om du spør meg.

Huh? Hva er det du mener er alternativet? Minnet som prosessoren bruker er alt for tregt til at det kan effektivt brukes av Larrabee.

 

Min erfaring er fra to GeForce 9800 GT kort(hakke peiling på hvilken chip). Og erfaringen fra det var at vi trengte bare å bry oss om det delte minneområdet, resten fiksa GPU'en selv. Nå vet ikke jeg om dette var pga kompilatoren eller en annen arkitektur i forhold til G80 kortene. Men i hovedsak så trengte vi ikke bry oss om selve minnearkitekturet.

Skal faktisk sjekke litt mere på akkurat det der.

Det spørs på hva du skal programmere. Det delte minnet (shared) eksisterer per SM, og kan ikke deles mellom flere SM'er. Vi bruker det mye til mellomregninger. Det er nesten like raskt som registere, men har veldig liten plass.

Når det gjelder off-chip minne så er det tre typer. global, texture og constant. GPU kan kun skrive til global. Texture og constant kan settes opp fra host (CPU). Til gjengjeld er de cached. Her fikser ikke GPU noen ting, og det er ditt problem å finne ut hvilke type minne som passer til dine oppgaver. Etter det kommer utfordringene med å få data inn og ut av GPU på en effektiv måte (streams?). Med minnet på GPU'en må du også passe på at aksess-mønstrene dine er optimale. Du ønsker coalesed memmory access, og i shared memory ønsker du ikke bank-conflicts.

 

På jobben min driver vi med forskning på blandt annet GPGPU, våres erfaringer er at en veldig stor del av jobben er å optimalisere koden.

[Anders Jensen]

På jobben min driver vi med forskning på blandt annet GPGPU, våres erfaringer er at en veldig stor del av jobben er å optimalisere koden.

Det var det vi også fant ut. Ente derfor opp med en standard regneklynge.