Gå til innhold

Tusenkjerneprosessor en realitet


Anbefalte innlegg

Videoannonse
Annonse

I og med at det ikke er snakk om x86 (eller noen av de mest nærliggende ISA-ene) så får jeg vel skyte inn at AMDs kommende Radeon 6990 skal få hele 3072 kjerner, og det er ikke en gang "proof of consept" i laboratoriesammenheng men et reelt produkt som er på markedet for "hvermansen" om kort tid.

Lenke til kommentar

I og med at det ikke er snakk om x86 (eller noen av de mest nærliggende ISA-ene) så får jeg vel skyte inn at AMDs kommende Radeon 6990 skal få hele 3072 kjerner, og det er ikke en gang "proof of consept" i laboratoriesammenheng men et reelt produkt som er på markedet for "hvermansen" om kort tid.

 

Amd begynnte vel med Stream Prosessorer i 2006 hvis jeg ikke tar helt feil, men man kan vel ikke sammenligne disse med 1000 kjernesprosessoren som det er snakk om i artikkelen.

Lenke til kommentar

Oi her var det mye rart...

 

FPGA brukes i hovedsak hvis en har lave volumer. Om et produkt er blitt stabilt og produseres i høye volumer konverterer en gjerne til ASIC som gir mye mer ytelse per areal og per watt. Et unntak er rekonfigurerbar logikk som ikke kan være ASIC. Personlig tror jeg ikke dette vil ta av noe serlig da kombinasjoner av CPU og GPU på ASIC vil være både raskere og mer fleksibelt i praksis.

 

Det er ikke noe vanskeligere å lage en FPGA enn en ASIC, heller omvendt. Spesielt hvis en skal tune for ytelse vil en bruke mye mer tid på å designe en ASIC, men på høyt nivå er FPGA og ASIC koding helt likt.

 

Kan vanskelig tenke meg at FPGA er serlig utbredt i høyvolum enheter som TV. I rutere er det nok noe mer vanlig, men f.eks CISCO er på tur bort fra FPGA i sine highend routere (CRS) som naturlig nok selger i små volumer. FPGA brukes også i datamaskiner til tungregning. SGI leverer dette til sine Altix maskiner.

 

En stream prosessor i en GPU bør ikke uten videre sammenlignes med selv en svært enkel CPU kjerne selv om en stream prosessor godt kan ha høyere ytelse. Årsaken til dette er begrensningene som ligger i tråd håndtering. På en CPU kjerne kan du til en hvert tid schedulere en eller flere tråder av vilkårlig opphav. På en streamprosessor er dette ikke mulig. Her kjører en gjerne tusenvis av instanser av den samme tråden, men på forskjellige data. Stream prosessorene er organisert i grupper og det er gjerne slik at hver stream prosessor innen samme gruppe må eksekvere samme instruksjon fra samme tråd sammtidig. Det er imidlertid en trend i retning av større frihet til å kjøre forskjellige tråder sammtidig også for GPU men avstanden opp til friheten i en CPU er fortsatt enorm. I en cpu kjerne kan du eksekvere instruksjoner og tråder helt uavhengig av hverandre. Det er faktisk bare helt unntaksvis at samme tråd kan kjøre på mer enn en kjerne, og da i den hensikt å øke påliteligheten (lockstepping).

 

Generet kan en si at en GPU er en databehandler blodtrimmet for dataparallellitet. Den ofrer blandt annet oppgave parallellitet, fleksibilitet i kontroll flyt, seriell ytelse og datasett størrelse for å bli best på dette. For førstnevnte begrensning er det en trend på å løse opp litt for å bedre tilpasse seg gp-gpu og oppgaver med mindre dataparallellitet generelt, som også begynner å bli vanlig i mer avansert realtime 3D rendering.

Endret av Anders Jensen
  • Liker 5
Lenke til kommentar

FPGA har jo typisk lavere frekvenser enn ASIC.

Kan det være at 20 ganger raskere henviser til teoretisk peak FLOPS eller MIPS?

Det hadde vært morsomt å høre fort hvordan layout av en slik prosessor er. Bruker de tilsvarende et cluster oppsett internt på prosessoren?

"The researchers then used the chip to process an algorithm which is central to the MPEG movie format – used in YouTube videos – at a speed of five gigabytes per second: around 20 times faster than current top-end desktop computers."

 

Forsåvidt imponerende nok, men regner vel med at kjernene her er nokså pinglete. Det en bør ta med i betraktningen er at dette bare er til forskning. Når en har funnet gode måter for implementering av hardware samt tilhørende programmeringsmodell så kan en implementere det samme i ASIC og få et kraftig løft i ytelsen. Men først må en altså finne de riktige metodene. Det er godt kjent at dagens CPU kjerner, minne hierarki, interkommunikasjon og programmeringsmodell ikke er spesielt effektiv når en skal skalere opp i disse dimmensjonene. Da har en i hovedsak fire alternativer for forskningen:

- simulere: unøyaktig og nokså tregt

- emulere: veldig tregt

- implementere i rekonfigurerbar hardware (FPGA): nokså rakst og billig

- implementere i ASIC: svindyrt, lang implementeringstid, gir reelle resultater, men egentlig bare Intel og IBM som har muligheten i serlig skala.

Endret av Anders Jensen
  • Liker 2
Lenke til kommentar

Jeg tror jeg leste om noe liknende nesten 10 år tilbake i tid. "Starbridge systems" hadde en artig "mission statement" på hjemmesida dems, som fortalte om ønsket om å lage superdatamaskiner i desktop størrelse og med lavt strømforbruk, med sånne omprogrammerbare gater. Etter en stund forsvant denne artige mission statement fra hjemmesida dems. Seinere leste jeg at arbeidet var visst for vanskelig, og at teknologien brukes kun for spesielle oppgaver.

Endret av Decoman
Lenke til kommentar

I og med at det ikke er snakk om x86 (eller noen av de mest nærliggende ISA-ene) så får jeg vel skyte inn at AMDs kommende Radeon 6990 skal få hele 3072 kjerner, og det er ikke en gang "proof of consept" i laboratoriesammenheng men et reelt produkt som er på markedet for "hvermansen" om kort tid.

At AMD kaller det kjerner er vel mer for markedsføring... For å si det sånn så vil ikke Radeon 6990 kortet klare å prosessere 3072 uavhengige "tråder" med forskjellige kodepaths...

 

Cayman brikkene til AMD inneholder 24 SIMD-clustere. Et SIMD-cluster inneholder 16 SIMD prosessorer, og en SIMD prosessor inneholder 4 ALU'er som kan utføre en 32-bit FP MAD/MUL/ADD per klokkesykkel. Brikken har da totalt 1536 ALU'er.

Endret av [GDI]Raptor
Lenke til kommentar
Gjest Slettet+513

Cuda kjernene har litt større potensial der. De er basert på å gjøre fysikk prosessering hver for seg (tror jeg) og fysikk er vel en slags matte. Ati kjernene er vel bare gode til shader prosess?

Endret av Slettet+513
Lenke til kommentar

Nå er ikke utfordingen å lage flest mulig kjerner, men å koble dem sammen. Tusen kjerner kan se veldig fint ut på papiret, men hvis de bruker svært lang tid på å kommunisere med hverandre, få overført data til/fra minnet, eventuelt blokkerer kommunikasjonskanalene til hverandre, er en like langt.

Lenke til kommentar
Raptor' timestamp='1294153472' post='16716969']At AMD kaller det kjerner er vel mer for markedsføring...

Se litt mer filosofisk på det: Hva er definisjonen på en kjerne? Det finnes prosessorer eller "enheter" i alle nyanser fra kompliserte brede CISC til anorektiske synkrone RISC.

 

Poenget mitt var bare at en FPGA "kjerne" er et så løst begrep at det kan bety nesten hva som helst.

 

"Kjerne" har vist blitt et moteord på linje med "nanoteknologi" og brukes om nesten alt mellom hummer og kanari.

  • Liker 2
Lenke til kommentar
Raptor' timestamp='1294153472' post='16716969']At AMD kaller det kjerner er vel mer for markedsføring...

Se litt mer filosofisk på det: Hva er definisjonen på en kjerne? Det finnes prosessorer eller "enheter" i alle nyanser fra kompliserte brede CISC til anorektiske synkrone RISC.

 

Poenget mitt var bare at en FPGA "kjerne" er et så løst begrep at det kan bety nesten hva som helst.

 

"Kjerne" har vist blitt et moteord på linje med "nanoteknologi" og brukes om nesten alt mellom hummer og kanari.

I min bok bør i allefall en kjerne kunne ha egen kontroll og data flyt. Hvis den bare har en av delene og deler resten, bør en være forsiktig med hvordan en sammenligner. Vil du si at hver vogn i et tog er et eget kjøretøy? Hva med lasten som hviler på hver aksling eller hjul? eget kjøretøy? eller kontainere og kolli...

 

Ellers er nok noen klar definisjon på kjerne ikke så greit lengre selv for CPU. I allefall fra og med Bulldozer og Poulson kommer på banen. En vil nok i større grad begynne å se på hvor mange kontekster en har tilgjengelig og hvilke egenskaper disse har. Dagens datamaskiner er i full fart med å bli heterogene så det vil være flere grupper av egenskaper per maskin.

Endret av Anders Jensen
Lenke til kommentar

- emulere: veldig tregt

Hva innebærer denne metoden?

Du implementerer en software versjon av det du ønsker å emulere, f.eks en CPU kjerne, og lar den kjøre software kompilert for "software kjernen". Dette kan gi en del gode resultater, men det er nødvendigvis tregt å generere resultater selv om det kan ta kort tid å implementere designet. Det er også en del fallgruver, f.eks er det vanskelig å vite hvor rask en funksjon er i hardware før en har prøvd. Hva er f.eks max frekvens til en cache? vanskelig å si før en har prøvd.

Endret av Anders Jensen
Lenke til kommentar

På denne 1000 kjerners saken hadde hver kjerne litt minne tror jeg integrert i FPGAn.

Og i tillegg så var hver kjerne EKSTREMT spesialisert ..

 

Ellers så ER en FPGA akkurat som actual hardware såvidt jeg har fått med meg .. Alle de logiske strukturene. Bare det at den kan programmeres om og endres med feks VHDL, (husker ikke hva det andre språket heter) ..

 

Vi retro freaks følger ellers med på morsomme prosjekter som NatAmi og MiniMig (snart med AGA).

 

Førstnevnte en Amigaclone i en FPGA med ekstrafunksjoner (men det drøyer jo evigheter før den kommer ..)

 

Mens MiniMig er klar. Det er en OCS/ECS - Amiga500 kompatibel sak i en FPGA. Kan kjøpes ferdiggbygd , dvs bare HK , kasse er litt i det blå, dessverre er ikke mini ITX redesignen produsert, bare v1.1(av aCube, kan kjøpes på Vesalia og AmigaKit. For den litt teknisk anlagte.)

 

Men så er det en kar som heter MikeJ som lager FPGA arcade prosjektet, det skal simulere hardwaren til endel arcade maskiner, OG MiniMig med AGA ! (Altså A1200 kompatibel. Mer eller mindre tror jeg.)

 

Google .. :new_woot:

Endret av Fjodorgrim
Lenke til kommentar

VHDL og Verilog. :) FPGA er i realiteten matriser av logikk koblet med busser. Så blokkerer en ut den funksjonaliteten en ikke trenger. Ville nesten sammenlignet det ved å laget et blide der en har papir med alle fargene i flere lag, så skraper en vekk lag for lag til en kommer ned til ønske farge. Selvfølgelig i sterkt overført betydning. Poenget er at en må ha alle "fargene" over alt fra FPGA produsentens side så må du velge hva du vil bruke. Resultatet er at det går med mange flere transistorer og databusser for å oppnå nøyaktig samme funksjon som en ASIC hvor du selvfølgelig bare bruker den logikken og bussene du behøver. Konsekvnsen av dette igjen er dårligere ytelse og ytelse/watt for en FPGA produsert i tilsvarende CMOS prosess som en ASIC.

 

Grunnen til at FPGA benyttes er som oftest utviklingskostnadene. En enkel implementasjon i FPGA kan gjøres på gutterommet med et middelmådig ukelønn budsjett. En ASIC på nyeste CMOS prosess koster titalls eller hundretalls millioner USD for første chip og derfra og ut koster hver nye chip en dollar eller så.

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å
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...