Gå til innhold

Intel smelter CPU og GPU


Anbefalte innlegg

Jeg kan ikke fatte hvorfor Intel gikk for x86 på kjernene. Larrebee vil uansett ikke kunne kjøre vanlig x86 programmvare på annet enn hastigheter fra forrige årtusen uten at programmet som et minimum blir rekompilert og mest sannsynlig må det skrives om. Da kan en like gjerne gå for et mer moderne instruksjonssett. Jeg tror derfor at AMD og Nvidia ikke kommer til å få store problemer med å slå Larrabee. De benytter bedre instruksjonssett og beveger seg mot samme mål men fra motsatt side med sine GPU løsninger.

 

Jeg tror derfor dette kan bli en gedigen flopp for Intel. Hvis de får god støtte for C programmer så vil nok HPC miljøet heller ha dette enn GPU i første omgang, men utover det så ser jeg ikke helt det store håpet. Intel må i såfall fullstendig parkere aktører som IBM, AMD og TSMC på CMOS-teknologi for å kompensere for det retroaktive idiotvalget av instruksjonssett.

 

Interconnect på larrabee er ikke veldig imponerende. Den benytter 512bit bidireksjonal ring. Det ligner mye på Cell som har bidireksjonal buss, men Larrabee sin løsning blir litt mer skalerbart. Det blir da også nødvendig når en skal opp på 48 kjerner. At dette kan skalere til flere hundre kjerner er åpenbart ikke riktig, men Intel har også andre prosjekter som er mer lovende på dette området. Sikter da til den 80 CPU brikken med rutere i 2D mesh og en link til en slags RAM fra hver ruter.

 

Kjernene i Larrabee er greie nok med unntak av at de benytter x86 selvfølgelig; in-order Pentium basert ,altså siste generasjon Intel in-order CPU, med 4-way SMT for å gjemme minne forsinkelser. Jeg tror det kommer langt mer fancy ting på markedet enn dette. Intel Poulson, IBM Power 7 og SUN Rock f.eks.

Endret av Anders Jensen
Lenke til kommentar
Videoannonse
Annonse

Her har de fjerna mye som har gjort at x86 har klart å henge litt med i ytelse, som blandt annet out-of-order execution. Alt annet er også kutta kraftig ned f.eks. branching støtte.

 

Hvis disse kortene er tilgjengelig om et år som var antydet som best-case tror jeg nok det litt for lite litt for sent. Da regner jeg med at både AMD og nVIDIA har neste generasjon hardware ute (DX11).

 

Som jeg sa før i denne tråden. Tragisk at Intel drar x86 inn i GPU-verden. De har potensiale til mye bedre!

Lenke til kommentar
Hver enkelt kjerne er basert på den opprinnelige Pentium-kjernen, utstyrt med 64-bit-instruksjoner og flertråds-støtte.

Den helt originale Pentium-kjernen med kodenavn P5 fra 1993? Den med den berømte FDIV-bugen? Bugen er selvsagt fjernet, men resten av arkitekturen er jo ikke akkurat moderne lengre. Det eneste bra er at den krever svært få transistorer (I sin tid: 3,1 millioner inkludert L1 cache). Det gjør det lett å plassere svært mange slike på en brikke med moderne produksjonsteknikk. Men jeg har sterke tvil til at det er så veldig hensiktsmessig å bruke en så gammel arkitektur, og ikke minst x86 i det hele tatt.

 

Sukk... Hvorfor må de dra x86 til GPU-verden... :(

Helt enig. Det eneste x86 kan tilby fremfor andre ISA er i mine øyne bakoverkompatibilitet, kort tid til markedet og åpenheten for konkurranse. x86 egner seg jo hverken til parallellisering (som bør være hovedpoenget med en 48-kjerner), lav effekt eller høy ytelse.

 

Håper AMD og Nvidia samarbeider om å lage et felles mangekjerne-ISA som skal erstatte Cuda og CTM. Det tror jeg kan banke den gjenopplivede x86-dinosauren grundig.

 

Må da være en enorm fordel rent kommunikasjonsmessig at CPU/GPU er kombinert i én brikke?

Det blir nok raskere kommunikasjon mellom CPU og GPU, men det vil gi en annen, stor flaskehals: Minnebåndbredde. En moderne GPU har opp til 141 GB/s minnebåndbredde mens en moderne CPU bare har opp mot 25 GB/s.

Lenke til kommentar
Bugen er selvsagt fjernet, men resten av arkitekturen er jo ikke akkurat moderne lengre. Det eneste bra er at den krever svært få transistorer (I sin tid: 3,1 millioner inkludert L1 cache). Det gjør det lett å plassere svært mange slike på en brikke med moderne produksjonsteknikk. Men jeg har sterke tvil til at det er så veldig hensiktsmessig å bruke en så gammel arkitektur, og ikke minst x86 i det hele tatt.

4-way SMT er en veldigstor og dyptgripende endring i kjernen. Den gjør også kjernen egnet til høy throughput per watt. At kjernen ikke er moderne er forsåvidt ikke så farlig. Pentium pro (P6) var det første skrittet i feil retning med out-of-order pipeline. Det er som å tisse i buksa for å holde seg varm. Føles bra til å begynne med, men så kommer ulempene i rask rekkefølge. Med Prescot hadde Out-of-order design nådd sin ultimate galskap og Intel gikk tilbake til en Pentium M lignende arkitektur. Nå tar de steget videre tilbake til Pentium og hele out-of-order utviklings kretsløpet terminerer på en måte med dette selv om vi selvfølgelig vil ha out-of-order design i ganske mange år til. Det har imidlertid vært helt klart at Out-of-order ikke er en farbar vei lenge nå, og det er bare et spørsmål om tid før denne epoken går over i et vagt minne om hvor utrolig tungvindt en løsning kan være hvis en bare går inn for det med trangt nok syn.

 

x86 i nok et markedssegment er imidlertid bare til å gråte over. Særlig når det ikke er noen gode politiske eller markedsdynamiske faktorer som tilsier at det skulle lønne seg. Eneste jeg kan komme på er at Intel marketing kan få folk til å tro at dette er mer kompatibelt enn annen type GPU, noe det i realiteten ikke er, og dermed skape et segment på det viset. Får inderlig håpe det "teraflopper".

Endret av Anders Jensen
Lenke til kommentar
Jeg kan ikke fatte hvorfor Intel gikk for x86 på kjernene. Larrebee vil uansett ikke kunne kjøre vanlig x86 programmvare på annet enn hastigheter fra forrige årtusen uten at programmet som et minimum blir rekompilert og mest sannsynlig må det skrives om.

Det går bare én vei, prosessorer med stadig flere kjerner. Så progammer optimalisert for flere kjerner vil nok komme, Larrabee eller ei.

 

Ellers håper jeg det vil gå mot kombinerte CPU/GPU. Slik det er i dag, hvor man har to stor-krafts prosessorer fremstår det jo som en sløsing av maskinkraft, når man kjører prosessorintensiv (gjerne parallellintensiv) men ikke grafikkintensiv programvare står GPUen helt kald og kastes rett og slett bort. Og ja, jeg vet at GPU og CPU har forskjellig arkitektur og derfor ikke kan kjøre samme programvare, men jeg prøver å ha et litt overordnet perspektiv her.

 

Den første generasjonen Larrabee vil nok kanskje ikke fremstå som det helt store GPU-monsteret. Men jeg mener det viktigste her er prosesseringskraft versus pris, hvis de får til denne biten ganske bra kan Larrabee bli et bra alternativ for lav- og mellom-segmentet. Med parallellprosessering og Intels komplimerings/optimaliserings-ekspertise (for å kjøre DirectX- og OpenGL-kode optimalt på programmerbare prosessorer) tror jeg dette muligens kan fungere iallefall i lav/mellom-segmentet :)

Lenke til kommentar

Larabee skal støtte DirectX (Direct3D) og OpenCL? Hva med OpenGL da? OpenCL er jo ikke en standard engang ennå. Apple foreslo den som standard i juni iår. DirectX er lukket og proprietær, og kjenner jeg Apple rett blir vel OpenCL det samme. OpenGL er derimot en åpen standard.

 

Nei, dette var skuffende nyheter.

Lenke til kommentar

Vel jeg ser en god ting med dette, for å være litt positiv.

Gamle spill som q3 og cs kommer til å FLYYYYYYY =)

Latens tiden må jo bli tilnærmet ikke eksisterende lokalt.

Å spille mot maskinen vil bli en smule annerledes kan jeg tenke meg.

For dedikerte spill servere f.eks er nok dette interessant.

Ellers blir vel desktop bruk og type 2d tegne programmer kanskje hakket mer responsivt. Tenker spesielt på wacom type dyrt tegne-brett/skjerm.

Endret av amiganostalgia
Lenke til kommentar
Det blir nok raskere kommunikasjon mellom CPU og GPU, men det vil gi en annen, stor flaskehals: Minnebåndbredde. En moderne GPU har opp til 141 GB/s minnebåndbredde mens en moderne CPU bare har opp mot 25 GB/s.

 

Hvem sier at vi må beholde cpuen sin minnekontroller? HK med 256 og 512 bit båndbredde blir kanskje dyrt å produsere, men det er da mulig? I værste fall kan jo cpu ha 2 minnekontrollere.

Lenke til kommentar
Epic er svært positive til Larrabee, og trekker også fram muligheten for å programmere Larrabee direkte som svært positivt.

Software render er selvfølgelig mye mer fleksibelt enn hardware render og det er vel en naturlig vei å gå. Bare så synd at Intel tok utgangspunkt i det dårligste instruksjonssettet de hadde liggende for å fronte denne trenden. Nå er det riktignok et veldig kraftig vektor tillegg til x86 i Larrabee. Det kan redde ytelsen, men jeg fatter fremdeles ikke hvorfor de fant frem dette Trabi karosseriet for å bygge neste generasjon superbil.

Lenke til kommentar
Software render er selvfølgelig mye mer fleksibelt enn hardware render og det er vel en naturlig vei å gå. Bare så synd at Intel tok utgangspunkt i det dårligste instruksjonssettet de hadde liggende for å fronte denne trenden. Nå er det riktignok et veldig kraftig vektor tillegg til x86 i Larrabee. Det kan redde ytelsen, men jeg fatter fremdeles ikke hvorfor de fant frem dette Trabi karosseriet for å bygge neste generasjon superbil.

Det har vel litt å gjøre med kompatibilitet og sånn, husk brikken skal ikke bare dra grafikk men også vanlig programvare. En grafikkbrikke som krever at all programvare til PC-en må komplimeres på nytt i et annet instruksjonssett ville floppet ganske fort.

 

x86 er også veldig godt kjent i spillverdenen fra før av, så alle er kjent med det og vet hvordan det fungerer, så de slipper sette seg inn i enda et nytt instruksjonssett, og selv eldre spill er garantert å fungere (da brikken kan "emulere" Directx).

Lenke til kommentar
Det har vel litt å gjøre med kompatibilitet og sånn, husk brikken skal ikke bare dra grafikk men også vanlig programvare. En grafikkbrikke som krever at all programvare til PC-en må komplimeres på nytt i et annet instruksjonssett ville floppet ganske fort.

Det er veldig begrensa hvilke programmer som kommer til å egene seg til å kjøre på denne brikken. Programmene her må også være designet for arkitekturen hvis man skal ha ok ytelse. Bruke vektorenhetene er nøklen.

 

Høyst sannsynlig må programmer også rekompileres for å få ok ytelse.

Lenke til kommentar

Ja, det her er jo i praksis en utradisjonell GPU med gode muligheter for å prosessere FP-intensive oppgaver ved siden av. Den er ikke akkurat egnet til prosessering av oppgaver normalt gjort av CPU.

 

HW hjelper jo ikke akkurat med tydeliggjøring av hva Larrabee er heller, ved å påstå at den konkurrerer med AMD sin Fusion (CPU/GPU på samme die).

Lenke til kommentar
Software render er selvfølgelig mye mer fleksibelt enn hardware render og det er vel en naturlig vei å gå. Bare så synd at Intel tok utgangspunkt i det dårligste instruksjonssettet de hadde liggende for å fronte denne trenden. Nå er det riktignok et veldig kraftig vektor tillegg til x86 i Larrabee. Det kan redde ytelsen, men jeg fatter fremdeles ikke hvorfor de fant frem dette Trabi karosseriet for å bygge neste generasjon superbil.

Det har vel litt å gjøre med kompatibilitet og sånn, husk brikken skal ikke bare dra grafikk men også vanlig programvare. En grafikkbrikke som krever at all programvare til PC-en må komplimeres på nytt i et annet instruksjonssett ville floppet ganske fort.

 

x86 er også veldig godt kjent i spillverdenen fra før av, så alle er kjent med det og vet hvordan det fungerer, så de slipper sette seg inn i enda et nytt instruksjonssett, og selv eldre spill er garantert å fungere (da brikken kan "emulere" Directx).

Du må rekompilere "vanlig" x86 for å kjøre den på Larrabee med noe mer ytelse enn på en enkelt Atom kjerne. Uten rekompilering får du ikke vektor utvidelsen med og ikke de siste 47 kjernene. Du sitter altså igjen med mindre enn 1% av den potensielle ytelsen. Kompatibilitets argumentet er derfor uvesentlig i praktiskbruk. Hvis du vil ha god ytelse uten å rekompilere så bør du bruke Core 2 eller Nehalem når den kommer, ikke Larrabee.

 

DirectX støtten er også å finne på alle andre GPUer. Den er ikke noe argument for å velge Larrabee fremfor en annen GPU og heller ikke noe argument for x86. Forskjellen er at Larrabee blir fremover kompatibel med DirectX 11, 12 osv., med forbehold om brukbar ytelse på applikasjoner som er lansert flere år etter brikken.

Endret av Anders Jensen
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...