Programvare må endres for 80-kjerners CPU

[Del]

Puh, her var det mye å ta tak i, tror jeg gir opp med en gang. Men den som spør får svar..

 

Dessuten har alle problemer iboende serielle avhengigheter som gjør det upraktisk å skalere til så store antall kjerner med mindre du har veldig store datasett. Vil tro det ikke er lenge før HPC miljøene begynner å klassifisere problemtyper etter hvor mange bytes med data en bør ha per tråd fremfor asymptotisk skalering. Hva tror du Del?

7760872[/snapback]

Jupp. noe i den duren ihvertfall. Noen oppgaver er jo lettere parallelliserbare enn andre, og Niagara er vel et utslag av dette. Toppmodell Niagara kjører 32 tråder simultant hvis jeg husker riktig, men fp ytelsen er dritt, så det er nok mer db man tenker på. Når det gjelder HPC er det en helt klar trade off mellom antall kjerner og hvor mye ytelse en får igjen (hvor Amdahls lov bare er en av flere faktorer), og på mange problemer og arkitekturer vil kurvene krysse tidlig, før vi kommer til 80 kjerner (for ikke å snakke om terra). Silisiumbaserte terrakjerner tror jeg vi skal glemme med en gang, jeg kjøper argumentet ditt der glatt.

[kindings]

4. AMD holder seg til X86 og tar markedsandeler fra Intel fra folk og firmaer som utsetter å gå vekk fra X86. Intel tvinges til å tilpasse seg markedet og forlenge støtten til X86 utover den perioden de opprinnelig hadde tenkt.

 

Tviler vel på at Intel er førstemann bort fra X86, tror nok Intel vil være med på det løpet så lenge det er profitt i det.

 

Jo, det er riktig at patenter går ut etter ett x-antall år, men i dataindustrien, så er det urealistisk å tro at utgåtte patenter vil være verd noe. Det er vel også slik at patentene i seg selv blir verdiløse før den tid pga oppdateringer/endringer som krever nye patenter...

 

IA64 er vel ikke død? Trodde Intel fremdeles arbeidet med dette arkitekturet for fullt? Jeg tror at dersom noen skal komme opp med en arvtager til X86, så vil det bety flere år med utvikling og lite økonomisk inntjening før man kan håpe på å være på høyde med X86 eller bedre. X86 har tross alt blitt utviklet gjennom 30 år++ etterhvert....

[Phyx]

Ser det er mange her som kan mye om ting som finnes o.l.

 

Men tenk om de kunne hive hele x86 på søppla og slutte og videre utvikle noe som er fra 70 talet og faktiskt kunna lage noe som er litt nyere og mere gjennomtenkt og ikke bare tar forbehold om og må tenkte bakover og ikke fremover.

 

Jeg mener: idag sitter vi på en PC som fortsatt mer eller mindre som er kompatibel med en 386 fra 70-80 talet.

 

Hjelp! Tenk fremover og in i fremtiden. Tenk om de skraper hele x86 systemet, hva skjer da med microsoft sitt monopol tro

[Simen1]

Phyx: Intel prøvde å skrape x86 med sin nye arkitektur IA64 en gang i tida. Vi så jo hvordan det gikk. IA64 var ment å jobbeseg nedover fra high-end servere til småservere og videre til desktop-PCer og bærbare. Den veien gikk det ikke fordi det var enorme mengder programvare som ikke var kompatibelt og det ikke var kostnadseffektivt å flytte over på IA64. Itanium har eksistert noen år nå uten å komme seg nedover til desktop. Folk vil rett og slett ikke kjøre det siden det ikke finnes programvare til det og programmerere vil ikke programmere for det siden det ikke finnes nok kunder for det. Høna og egget.

 

Saken er at man bør vidreføre x86 en stund til med en utvidelse til nye instruksjoner slik at overgangen blir lett og man slipper høna og egget-problemet. Når bruken av x86 synker kraftig så kan man gå over til å emulere det i første omgang og deretter kutte det helt ut. Akkurat det samme har blitt gjort med 8bit og 16bit instruksjoner til x86.

 

Utvidelser av x86 har blitt gjort i mange omganger: 16bit, 32bit, MMX, 3DNow, SSE, 3DNow Enhanced, SSE2, 64bit, SSE3, NX-bit, SSE4, osv. De eldste modusene, 8 og 16bit er vel ikke mulig å kjøre lengre?

 

Noen årstall:

1978: 8086 ble lansert (8bit) (første x86-prosessor selv om den var en vidreutvikling av 8008 og 4004)

1982: 80286 ble lansert (16bit)

1986: 80386 ble lansert (32bit) (8bit kompatibilitet ble vel utelatt omtrent nå?)

2003: AMD64 ble lansert (64bit) (16bit kompatibilitet ble vel utelatt?)

 

Forøvrig så har Microsoft Windows til IA64 og lager selv kompilatorer til hvilken arkitektur de måtte ønske. Microsoft mister altså ikke automatisk noe monopolisme av å måtte bytte instruksjonssett.

[Prognatus]

Hm.. synes å huske at IBM PC kom med 8088 inni først, som var forløperen til 8086. Jeg hadde PCer med begge disse husker jeg. Med orange (amber) skrift på Hercules-skjermen... Tror "AT-prosessoren" 80286 kom i 1984 også, men dette er så lenge siden nå at jeg kanskje husker feil.

[Simen1]

Det kan godt hende. Produsenter som IBM, AMD, med flere produsrte jo 8086, 8088, 286, 386 og 486 på lisens fra intel. Det var først når intel lanserte Pentium i 1993 at de ikke gadd å selge lisenser lengre. Da hadde de så stor produksjonskapasitet at de ville ha hele markedet for seg selv. De ville bli monopolister.

 

Nostalgi er morsomt. Jeg husker da jeg langde et program for å "benchmark"e min første PC, en XT 8088, ved å lage en løkke som la sammen 1+1, 10.000 ganger og tok tiden på det. Jeg kom fram til at den klarte ca 100.000 operasjoner per sekund, altså 1 instruksjon per 47 klokkesyklus. Men nå var dette høykode-instruksjoner så det kunne sikkert gått mye raskere om jeg hadde skrevet det i maskinkode. Nå suser moderne prosessorer av gårde med 2-3 instruksjoner i gjennomsnitt per klokkesyklus. Mye mer komplekse instruksjoner er det også.

 

Om kanskje 5 år suser de vel av gårde med 5-50 instruksjoner per klokkesyklus fordelt på 80 kjerner.

[Prognatus]

100.000 operasjoner pr. sekund? Det var temmelig kjapt i forhold til hva jeg gjorde i 1980:

 

På min Zinclair ZX80 lagde jeg et lite program for å teste Integer Randomizeren i prosessoren (det var ikke noen x86-prosessor i den maskinen), fordi jeg hadde mistanke til at den favoriserte visse tall. Programmet loopet 1 million ganger og for hver loop tok et tilfeldig tall mellom 0 og 9, og summerte alle forekomstene av disse. Vel, det viste seg at jeg hadde rett - 5 og 7 var overrepresentert. Men den virkelig store overraskelsen var at det tok nesten to dager å kjøre programmet...

 

Om kanskje 5 år suser de vel av gårde med 5-50 instruksjoner per klokkesyklus fordelt på 80 kjerner.

Vi trenger all den datakraften vi kan få, hvis vi skal kunne virkeliggjøre håndskriftgjenkjenning, talestyring, rendring av HD-video innen rimelig tid, osv. Datakraft kan vi aldri få nok av.

Endret 22. januar 2007 av Prognatus

[Simen1]

Hvis jeg ikke husker feil så er vel random en av de mest krevende instruksjonene på de gamle prosessorene. Det er vist en lang løkke med instruksjoner som kjøres for å regne ut et "tilfeldig" tall.

 

Men morsom observasjon.

[Del]

OK, jeg har antagelig alt for mye tid på hendene, men det får så være. Jeg starter i hvertfall en plass...

 

Det snakkes mye om at generell Programvare og OS må endres, men minst like viktig er compiler-teknologi og bedre støtte i API'er og utviklingsverktøyene. Dette er en forutsetning for at det i det hele tatt skal være "mulig" å utvikle bedre programvare uten at kostnadene blir veldig høye.

Kompilator og biblioteker er det du trenger. I utgangspunktet skal koder da kunne flyttes lett mellom arkitekturer, i praksis viser det seg likevel at det er litt mer innfløkt.

 

Andre utfordringer er minneaksess for alle kjernene, når så mange kjerner som 80 stk begynner å krangle om det samme minnet, er kanskje tiden inne for å segmentere litt minne per core . Enten i form av vesentlig større cache per kjerne eller on core minne av et eller annet slag.

Dette er ikke noe nytt, det heter delt minne, og er en kjempeutfordring. Normalt håndteres dette med et hierarkisk minnesystem (eks. SGI sin ccNuma). Hvorvidt større cache pr. kjerne vil løse dette, stiller jeg meg meget tvilende til. Nå er det vel uansett snakk om 80 kjerner på en sokkel, og da kan delingen av minnet styres on-chip, det er tilsynelatende mye enklere problem.

 

I store parrallelle prosessor systemer med f.eks tusen prosessorer ser vi lignende ting i dag, det brukes ikke shared memory i de, men avansert routing i mellom prosesseseringsenhetene for å dele variable og minne. Dette for å gi hver prosessor enhet rask tilgang til minnet istedenfor å vente i kø til de andre enhetene blir ferdig.

Jeg tror du er litt forvirret her. Du sikter antagelig til linux klynger med distribuert minne. Når det gjelder power og itanium systemer kan de godt ha over 1000 kjerner og delt minne, men som sagt hierarkisk minnesystem.

 

Det blir selvsagt noe annet når alle prosessorene (dvs. kjernene) sitter på samme sokkel slik som nevnt i denne artikkelen, ergo tror jeg det blir en form for lokalt minne per kjerne (muligens en form for  cache) som må til for å få opp ytelsen.

Likefullt går tendensen motsatt vei, med delt cache. Jeg tror likevel du har et godt poeng her, det kan vise seg krevende å dele minnet mellom 80 kjerner på en sokkel. Problemet ligger i at mengden modulært minne du kan knytte til en sokkel er veldig begrenset, så minnebussen har ikke all verden å gi. En del coherency overhead når 80 kjerner må dele minnet må vi også renge med (skal vi tro at Kentsfield tallene er representative blir den hit'en betydelig). Blir ikke mye minneytelse igjen pr. kjerne.

 

En modell uten delt minne der minnet på hver prosessor må adresseres direkte fra programvaren vil kreve helt nye API'er i forhold til dagens.

7761644[/snapback]

Det finnes allerede, og kalles MPI.

Endret 22. januar 2007 av Del

[Del]

Det samme opplever jeg på jobben med vårt simuleringsverktøy. Jeg har sterke mistanker til at det er dårlig koding som er problemet. Alt det veksles mellom enkel og dobbel presisjon og at enkelte verdier og grensebetingelser ikke utvelskes i samme rekkefølge eller noe sånt.

7762120[/snapback]

Kan godt være råtten kode. Single precision er også en meget farlig ting, men du kan sikkert fort finne ut om det er brukt.

 

Det er riktig at en kan endre resultatet av et numerisk regnestykke (dvs. et regnestykke gjort av en datamaskin) rett og slett ved å endre rekkefølgen man utfører beregningene i. Helt konkret, på laveste nivå i koden skyldes dette kanselleringsfeil (på et eller annet tidspunkt i koden subtraherer man to tall som er nesten like). På mer overordnet nivå kan dette typisk skje hvis man prøver å invertere noe som nesten er singulært, f.eks. en newton iterasjon nær et ekstrempunkt. Er du heldig kan økt presisjon på tallene berge deg unna.

 

Når det gjelder IA64, så skal ikke jeg påstå å sitte inne med svarene på hvorfor denne ikke har fått større gjennomslag. Det virker på meg som om arkitekturen ikke har fått tilstrekkelige midler til å vise hva den er god for. Dersom Intel hadde brukt like store ressurser på Itanium som de gjør på x86, så skulle jeg vel vært litt mer skråsikker.

Endret 22. januar 2007 av Del

[Del]

Hvis jeg ikke husker feil så er vel random en av de mest krevende instruksjonene på de gamle prosessorene. Det er vist en lang løkke med instruksjoner som kjøres for å regne ut et "tilfeldig" tall.

 

Men morsom observasjon.

7776666[/snapback]

Tja, den vanlige måten å generere tilfeldige tall på er såvidt jeg husker å bruke restleddet etter divisjon med et egnet primtall. Til sammenligning bruker gjerne power borti 100 klokkesykler på state-of-the-art bilbliotek, mens sin, cos, tan bruker drøyt 50.

Endret 22. januar 2007 av Del

[Del]

(x64 har ikke blitt den store sukksessen ennå).

7771302[/snapback]

Dette tror jeg Intel må ta en del av skylden for med sin 32-bit Petnium M/Core, Vista ville ellers vært en god kandidat til å gjøre 64-bit til default oppsett.

 

1. Når denne arkitekturen er klar for lansering, har vi allerede vent oss til å kjøre 4-kjerners prosessorer for lenge siden og da vil en ny prosessor med "bare" to x86-prosessorer for bakoverkompatibilitet synes å være et tilbakeskritt for mange.

 

..snip..

 

Disse faktorene kan være med på å få utviklingen av flerkjerneprosessorer til å fortsette med krympingen av X86-prosessorer. Jeg tror det skal veldig mye til før vi forlater den nåværende arkitekturen til fordel for en ny og uprøvd innen 2011. Det er tross alt ikke lenge til. Bare fire år.

7771501[/snapback]

Du sitter nærmest med en nøkkel her. Kan hende quad-kjerne ikke rekker å få særlig innpass på desktopen før andre alternativer er på markedet med mer heterogene kjerner, AMD sin fusion skulle vel komme om et par år. Så ditt siste argument kan vise seg å slå i hjel det første.

 

Når det gjelder denne 80 kjerne saken har jeg ikke sjekket nettsidene til Intel, men det forundrer meg om denne er tiltenkt desktopen i det hele tatt.

Endret 22. januar 2007 av Del

[Fruktkake]

Programvare må endres for 80-kjerners CPU

 

Sjokk.

[Theo343]

Ser for meg miljø hvor man kan bestemme hvor mange terminalbrukere som skal kjøres på hver kjerne.

 

Evt. er det jo også perfekt for virtuelle servere.

Endret 1. februar 2007 av Theo343

[Anders Jensen]

Ser for meg miljø hvor man kan bestemme hvor mange terminalbrukere som skal kjøres på hver kjerne.

 

Evt. er det jo også perfekt for virtuelle servere.

7849533[/snapback]

Ikke for å være frekk, men det er faktisk ikke en korrekt observasjon. Det ideelle hadde vært en kjerne med den samlede kraften til de 80 kjernene. Det ville gitt samme throughput, men opptil 80 ganger bedre responstid. Nå er jo forsåvidt dette et hypotetisk problem siden det ikke er fysisk mulig å implementere alternativet innenfor et fornuftig effektbudsjett. Men hvis noen kunne lagd en 40 kjernes prosessor med samme throughput OG samme ytelse/watt så ville de hatt en vinner. Ser dere hvor dette konvergerer? Den som kan levere høyest ytelse med samme ytelse/watt på færest mulig kjerner blir vinneren... dette vil selvfølgelig være workload avhengig, så det blir komplett umulig å kåre en vinner på generel basis.

 

Håper slidene til et aktuelt foredag kommer ut her:

http://www.stanford.edu/class/ee380/Abstracts/070131.html

 

The sequential processor era is now officially over, as the IT industry has bet its future on multiple processors per chip. The new trend is doubling the number of cores per chip every two years instead the regular doubling of uniprocessor performance. This shift toward increasing parallelism is not a triumphant stride forward based on breakthroughs in novel software and architectures for parallelism; instead, this plunge into parallelism is actually a retreat from even greater challenges that thwart efficient silicon implementation of traditional uniprocessor architectures.

Det er velig få som ser ut til å ha forstått dette ennå. Antagelig pga. markedsføringshysteriet fra Intel og AMD med flere.

 

Husk dette er en høyst teoretisk betraktning. I praksis må vi ha parallellitet for å komme videre, slik nevnt i quoten ovenfor.

Endret 1. februar 2007 av Anders Jensen

[Theo343]

Det er korrekt at det beste hadde vært

... en kjerne med den samlede kraften til de 80 kjernene. Det ville gitt samme throughput, men opptil 80 ganger bedre responstid.

Men når man har 80kjerner uten god software for å styre det så skjønner ikke jeg hvorfor det ikke skulle være bra å kunne ha 80 virituelle servere kjørende på hver sin kjerne eks. Evt. 40 VS med 2 kjerner hver.

 

Selvf. er dette en manuell tildeling av ressurser, men alikevel gir det deg en god mulighet til å kjøre rimelig mange virtuelle servere på en plattform. Riktignok blir minnebruken en utfordring.

 

EDIT:

Og jeg ser helt klart utfordringene, men jeg tenkte også hypotetisk. Eller la meg kalle det ønsketenkning, med en dårlig implementasjon.

Endret 1. februar 2007 av Theo343

[snorreh]

IBMs sjefarkitekt for programvare, Catherine Crawford, kommer med sine syn på saken i dette interessante intervjuet i InformationWeek:

 

Where's The Software To Catch Up To Multicore Computing?

 

Jeg regner med at dette bør være av interesse for leserne av denne tråden

[Simen1]

Det spennende de neste årene er at man kan kombinere mange små kjerner med noen få store. Innenfor fornuftige effektbudsjetter og økonomiske budsjetter.

 

Ytelse er svært avhengig av arbeidstypen og i noen situasjoner vil mange små kjerner vinne over noen få store kjerner. Hvis man har varierende arbeidstyper så er det en fordel om hver av disse typene kan kjøre på hardware som er optimalisert for oppgaven. Med andre ord at lett parallelliserbar programvare kan kjøre på de mange små kjernene og vanskelig parallelliserbar programvare kan kjøre på de få store kjernene.

[Simen1]

Intel 80 core chip revealed in full detail

[Anders Jensen]

Dette ser jo veldig interessant ut. Bra de ikke hadde bestemt seg for x86 på de tynne kjernene allerede. Dette kan jo bli veldig interessant sammen i et system med noen fete kjerner. Hadde vært kult å sett hva de kunne gjort med tynne EPIC+SIMD kjerner. Da kunne en fått litt bedre general purpose ytelse enn en ren SIMD slik som Cell SPE.

Endret 12. februar 2007 av Anders Jensen