Flera kärnor ingenting för superdatorer

latensen är ju stora problemet. Visst är det bra att få en bred buss med precis som han förklarar så ju djupare ju lägre tid tar det.

Spelar ju igen större roll hur mycket data som kan skickas om det tar 200 cyklar för processorn att få datan. hade processorn vart så enkel som dom rösta var med bara några register och helt cachelösa och igen form av prefetch så hade det ju tatt 200 cyklar för att ens påbörja en instruktion så det hade ju blevet 1: fetch, 2: decode, 3: execute, 4: write back sedan vänta 200 cyklar och samma sak igen. så 4 cyklar som den gör nåt på av 204st? Inte ens alla banbred i världen hade botat det. Därför så mycket logik i processorn är tillägnad att hämta begära dom där 200 nästkomande instruktioenra och spekulera och tom beräkna möjliga senarion i fall dom behövs bara för att banbredden ändå fins där.

För i tiden när man knappt ahde flytals enheter så var det nåt som drog ner prestandan. Mins själv när folk klankade på K6-2 för kass flytals prestanda. Men enligt detta föredraget så är latency ett s töre problem än kass flytalsprestanda på en modärn CPU. Hellre låg latency än hög fpu prestanda.
Ska man programera så ska man tänka på latencerna före kass flytals prestanda resonerar han till skillnad mot 10-20 år sedan då det var tvärt om. Minnet var snabbt och billigt men flytalsprestandan var premium. I dag är minnets accesstid ren premium.
i ett exempel han vissade från en studie av intel med en processor med en lång pipline så gick dom ju miste om ca 4000 möjliga instruktioner som kunde exekverats med uteblev pga en cache miss. Det kan ju dra ner prestandan en del även på den absolut flytalstarkaste processorn.

och som nämndes så är det väldigt lite av processorn som gör själva beräkningarna. Jag själv ahr ritat en helt fugerande alu och simulerat på min burk. Inte specielt krävande alls och går å bygga eller köpa som enkla IC kretsar. Självklart är en fpu enhet mer avancerad och det behövs decoders osv men som ett exempel som togs upp så utgör itanium 84% cache och 1% ren beräknigskraft av alla transistorer dom andra 15% är logik som jag snackade om innan som ser till att rätt data fins i cachet och försöker förutspå vad som ska in i pipen här näst vid tex en bransh. Så enligt detta föredraget så är ca 1% av en modärn CPU det som gör själva beräknigen, alu, fpu, simd eller vector enhet osv. Rästen är bara där för å se till att dessa har nåt å göra.

Var rätt fräckt med hur han vissade när dom kodar med flera trådar och hur vicktigt det var att hantera processorn cache rätt. Även om båda trådarna använde varsin kärna så fick dom igen vinst om båda skulle åt samma rad i cachet om jag förstog det rätt.

Inte sett klart allt än börjar bli lite sleten men rätt mö om programering nu så känner mig lite mer villsen då jag bara läst det mäst grundläggande om programering mäst för å förstå inte för å kunna programera.

Detta är ingen nyhet, titta bara på grafikkorten, de består ju av hundratals enklare kärnor, beräkningsenheter som måste ha tillgång till data att bearbeta.

De löser det via dyra lösningar som väldig hög frekvens samt bandbredd 256 512 bits bussar.

Varför sattsa på processorer när man har grafikort? MYCKET billigare och efektivare. känns som om de är på helt fel spår när de ska utväckla processorer för flera miljoner som skulle prestera kanske 1 fjärdedel mot ett av dagens spelgrafikkort OM man lyckas få til ramen.

skulle räcka med en quad på kanske 6ghz för att starta upp program medans man låter grafikkort ta hand om beräkningarna

Ett grafikkort fugnerar på helt annat vis. Annars hade inte processorn sett ut som den gör i dag.
Så så enkelt är det inte som du och många resonerar.

en processor förblir MYCKET mer flexibel och enkel att programera och kan göra mycket mer kompliserade uppgifter.

En GPU presterar i regel bara bra på stora dataset likt en vector baserad processor gör.

Det går inte att ghämföra GPU:er och CPU:er. Varför tror ni inte vi ser fler GPU baserade applikationer än vi redan gjort? Därför det är svårt att implementera och teoretisk beräkningskraft är inget värt i praktiken om det ej går att implementera.

rätta mig om jag har fel men är inte anledning till att stödet för Grafikkorts beräkningar är dålig just det att det är så många kärnor som behöver utnyttjas? nu försöker de ju tillverka processorer med 64 kärnor och kommer väll få liknande problem.

vet att arkitekturen på GPU och CPU skilljer en hel del men tror att det mäst handlar om vilja att utväckla program med stöd för GPU. T ex så har väll Bla annat flashplayer och den nya photoshop stöd för just detta?

Så är det inte. Problemet är att GDDR3 eller GDDR4 helt enkelt inte kommer upp i samma frekvenser.
Om du kollar hur ofta en butik får leveranser varge vecka så får du fram dess frekvens av leveranser.
Sedan hur stora dessa är var avgör mägden varor.
Så ökad bred betyder inte ökad mägd varor om man mer än halverar frekvensen. Så frekvens + banbredd ger mägden data. DDR5 arbetar på väldigt höga frekvenser och kan därför skicka väldigt mycekt data pär tidsenhet. Det är smidigt att slippa ha massa lednigsbanor då 612Bit kräver det dubbla i form av lednigsbanor gämfört med 256bit. Så öka frekvensen med 2x istället för bredden med 2x är smidigare vad det gäller GPU'ns storlek och PCB'n (kretskortet) antal lednigsbanor och dämed komplexitet och storlek. Det är problemet med nvidias GTX280 då det har väldigt stor GPU och förbpackning och kräver en väldig komplex PCB villket gör att priset blir högt till skillnad från HD4870 som komemr undan med en mindre GPU och förpackning och enklare PCB.

Det är svårt att koda flertrådat.
Liten guide för C++ om att koda med flera trådar.
http://paulbridger.net/multithreading_concepts

Dock kan jag inte programera nåt värt att nämna även om jag läst lite och provat så är det inget jag fallit för.

Men först å främst måste problemet vara möjligt att dela upp så man kan parallellisera det.
Varje tråd blir som ett litet program inom det stora programmet. Men dom måste kunna komma överens om resurser och koordinera sig med varan.

Program i all sin enkelhet är lite som en bok. man läser rad för rad.
Tänker vi oss att boken är en instruktionsbok där man följer punkter en å en i taget. Men en punkt kan hänvisa till en annan del i boken så allt eftersom man läser så kan man hoppa runt i instruktionsboken allt eftersom man löst olika problemen (monterat sin dator eller vad det nu är).

Program i teorin eller som dom skrivs ska ju utföras i den ordningen programmeraren skrev instruktionerna i annars blir det ju totalt kalabalik. Dock gör inte moderna processorer det utan dom kan utföra saker out of order men det viktigaste är att det i slutändan kommer ut i rätt ordning väl processat.

Tänk dig att du följer en instrucktionsbok för hur du monterar di ndator i delar. Du å några kompisar ska montera den. En kompis läser instrucktionerna för att montera processor ram och CPU, en monterar nätag, hårdisk och cd i chassi. Sedan monterar en in moderkortet och ansluter det väl klart. Så en sådan uppgift gick å dela upp relativt lätt.

men tänk dig att försöka bygga en skyskrapa och dela upp jobbet för varje våning. Lite svårt å bygga andra våningen när första inte ens existerar.

Kanske inte bästa exemplen men en programerare som skriver ett program för å vara flertrådat måste skriva flera trådar inne i programet. Lite som flera instrucktioner i en bock uppdelat i oliak delar eller kappitel för flera användare att sammtidigt utföra. En instrucktionsbok med 4 kappitel tex för 4st olika monterigsanvisnigar för 4st olika personer att gemensamt kunna montera saken i fråga. Normalt sett skriver man ju en instrucktionsbok pugt för pungt där taken är att en individ läser den i årdning och utför uppgifterna en å en i taget tills man monterat vad det nu är.

Det är inte bara å ta en GPU som någon resonerade och ersätta en CPU med och tro att vi har nsäta generatios super dator med 1Tflop prestanda istället för dagens quad core 50GFLOP prestanda.

Facktum är att en CPU främst pysslar med LOAD och STOR operationer vilket inte innefattar nån som helst flytals prestanda eller heltal för den delen heller. En GPU är primärt byggd för att enbart beräkna flytal och många av dom samtidigt. En GPU suger rätt hårt på att göra nåt annat precis som en CPU inte är så snabb på flyttal men å andra sidan är den avsevärt mycket mer flexibel och kan göra mycket varierande uppgifter.

Jag är medveten om suns multicor processorer och vad dess fördelar är. Och som du säger så kan den byta tråd på en cykel villket är snabbt. Dock måste man ändå hålla en sånda processor mata också. Tror kanppast den har mindre sofostikerad logik för det. Ska den hinna med mer så behövs ju mer data tillgägligt så den bör nog ha hyfast cache och prefetch logik med.

Sedan var ju inte första versionen så snabb då 8 kärnor delade en FPU men numera har dom en var vill jag minnas. Sedan har den väll hyffast I/O system för minnet också. Mins inte exackt hur minneshanterigen såg ut men för mig den hade rätt hyffsad design.

Sedan Mhz eller en hz är bar en cykel. Frekvensen anger antalet cyklar pär tidsenhet så bara relevant om man vet vad processorn kan göra och under en cykel.

Sedan att gämföra suns niagara med powerpc 6 är nog lite missvisande. Köper man power 6 till en miljö som presterar bäst med många trådar och gjort sig bättre på niagara så har man nog missbedömt ordentligt. Troligen gör man en nogran annalys innan man gör inköpet.

Sedan fins det iget som sgäer att en CPU som power 6 idlar oftare än en x86 på 3Ghz då det helt beror på om den har data att tillgå eller ej. Nu vet jag itne exackt hur mycekt cache power 6 har även om jag skulle kunna googla upp det men power 6 är en väldigt avancerad processor så svårt å tro att en modärn x86 processor har mycket å säga till om. Dom tävlar ju i helt andra ligor.

man kompenserar ju för latencys genom att försöka förutspå vad som ska hända här näst och desutom ladda så mycket data som möjligt när banbred för det fins ledigt. Tex behöver man data från en viss addres och man kan hämta datan från flera efterföljande addreser så gör processorerna i dag det eftersom det är hög sanolikhet att det kommer behövas. IBM är knappst kända för att göra dåliga architecturer eller processorer heller. Med en processor i 5-6Ghz klassen så behöver man nog ganska hårt piplina processorn och se till att hella tiden ha konstant dataflöde så jag tror nog inte att en power 6 idlar mer än en vanlig x86 processor. Men självklart är det ju en svårare bedrift att skapa en sådan processor men å andra sidan är power 6 inget för hemma användaren utan rör sig i en helt annan prisklass. Troligen mycket mer sofistikerad logik för att hålla pipen full med instruktioner.

IBM är ganska inovativa om man säger så. Bara kolla deras vattenkylning för processorn i power 6 servrar. Kylbocket är ju i princip intergrerat med kärnan. Kärnan är ju specielt tillverkade för att kylas av vatten för maximal kotackt.

Sedan passar ju ine suns niagara för mer generla applikationer utan trivs ju bäst i miljöer med många krävande trådar som går sammtidigt. Power 6 är nog lättare att behärska än en niagara om man inte kan annpassa programen för flera trådar.

Blue Gene vill jag minans har en dualcore IBM PPC processor på 800Mhz med 2st double precision FPU's pär kärna. Sedan har den lokalt minne och all I/O intergrerad för att sammanlänka sig med andra noder. CPU'erna och all I/O är intergrerat å ett kiselchip så jag har för mig en nod b ara är ca 10x10cm däromkring mins dock ej exackt men skulle tro det står på wiki pedia. Lite likt SGI's modulära atom projckt.

Så en nod ligger väl då på ca 3.2Glfops eller nåt sånt. Inte gätte mycket med dagens mått men det är ändå rätt hyggligt för nåt inte mycket större än ett par kortlekar i storlek.

Opteron är ju väldigt intresant och därför jag framhåller AMD som mer inovativa. Just pga hur låg tid det tar för signaler att gå från ram till CPU:n så är det ju extremt bra lösning att slippa en extra buss att gå över och ett extra chip. Att skippa nortbryggan och front side bussen för komunikation till minnet och istället köra direckt mot processorn minskar ju latencerna avsevärt. Det reducerar ju direckt mägden cache som behövs för samma prestanda nivå och processorns förmåga att ligga före beräknigarna.
Därför intel har behövt så mycket cache för att nå bra prestanda medans AMD har kunnat komma undan med det.

Cray kör ju med AMD opteron i sina superdatorer så det bevisar ju bara hur bra dom är.
i7 är ju intresant men igäntligen iget mer än en c2d med onbord memory controler. AMD var visserligen inte först men do mvar först att introducera en högprestanda plattform till PC Med minneskontrollern i processorn.

Sedan oavset processor så avgör ju koden också till stora delar hur effektivt processorn jobbar. Ju mer programeraren vet om maskinen och ju bättre han är på att optimera ju mer prestanda kan han ju plocka ut genom att se till att processorn jobbar för honom genom att hantera cachet och registrena optimalt.

Kollade som sagt på filmen so mdet läkades till här och det var ju rätt uppenbart att med rätt kunskap så kunde man ju nytta olika prefetch funktioner processor gör till sin fördel, just det att processorn tex inte bar hämtar datan på en vissa addres men även det som kommer efter. Men jag är igen programmerare så svårt å få skallen runt alla dessa metoder utan att kunna programera men men.

Jo men du förutsätter ju att man inte ökar banbredeen eller mägden cache eller dess prefetch förmåga så att säga.

Och som sagt vet jag principen bakom niagara men ett problem med den är just att den presterar dåligt om den inte har mycket att göra. Den msåt vara hårt lastad med många trådar och helst med optimerad mjukvara. Då utpresterar den en x86 cpu lätt men just att den använder enklare kärnor med sämre prefetch och minder cache på 4Mb gör att den inte presterar så bra under lättare laster.

Så det är ju lite hugget som stucket. Dörför jag försäkte få fram att det beror ju helt på vad man vill åstakomam med maskinen.

Sedan att den kan byta tråd och arbeta på det som fins i cachet är appsolut en bra lösning för att koma runt problemet med cache missar och latency peneltys det förnekade jag inte snarare tvärt om.

Självklart behövs minnensbanbred också då enbart cache inte hjälper villket jag mer eller mindre förklarade i mitt första inlägg om du läste det men register och cache råder delvis bot på problemet då det inte är specielt effecktivt att skicak saker fram å tebaks till minnet som man arbetar på hela tiden.

Sedan varför jag annser att man inte heller bara kan hänga upp sig på frekvensen på ett chip även om 3-6Ghz har stora problem så som att över 3Ghz på en modärn CPU så hinenr inte en signal från en ända av chipet till den andra. Men också därför man använder piplining då det delar upp chipet i små delar som var arbetar för sig. Istället för att hela processorn fungerar som en stor enhet ungefär som någon försöker kassta en boll över en hel fotbolsplan själv så orkar man nog inte det. Män ställer man upp 20 personer på rad alla med en liten boll var och alla kastar den framåt till personen framför så har vi ju fått in en boll i början på arenan och en kom ut ur andra ändan.

En 5Ghz CPU får nog vara hårt piplinad som sagt men det medför ju sina problem även det.

Sedan är det ju svårt å utala sig om power 6 då jag aldrig lekt emd en pga priset men den bygger ju på ett helt annat koncept. Vad jag kan se så verkar den ju extremt flytalstark och även ha ganska mycket ny teknik inom fyltalsberäknigar men även vectorisering. Att flera power 6 processorer kan gå ihop å bilda en enda stor vector processor tycker jag lät lite fräckt facktiskt.

Man kan nog diskutera detta i all evighet utan å bli nåt klokare dock.
Jag har varken lekt med niagara eller power 6 så det förblir speckulationer.

Men lika mycket som jag ser lösnigar i båda architecturerna ser jag problem. Den optimal processorn är nog inte uppfunnen ännu.

Sedan vad det gäller MIPS så betyder ju MIPS "Milions of Instrucktions Pers Second"
Men det talar ju bara om hur många isntrucktioner en CPU klarar av att utföra. Det i sig är ju relevant men det talar ju tyvär inte om vad det är för instrucktioner. Fins ju processorer helt utan en flytals enhet. Hur skulle det prestera i en miljö som förlitade sig hårt på flytal? Ganska kast troligen.

Vad för isntrucktioner den kan utföra och hur många maximalt av varge typ under en given tid är ju intresant som sagt. Ju bättre den är på olika instrucktioner ju mer flexibel blir den ju.

SÅ tycker MIPS är lite missvisande i sig utan å veta vad processor är kapabel av.

Jag försöker inte avfärda vad du säger men det jag säger är väl snarare att sannigen inte är svar eller vit. Som sagt går ju att diskutera i all evighet.

Niagara 2 prestera so magt bra under hård last med många många trådar. Det är ju dess sätt att prestera helt enkelt. Så vist om du har många små program som gör uppgiften åt dig parrallelt istället för ett program som gör det med en eller några trådar som skulle passa en x86 eller power6 bättre.

Men å andra sidan vänder man på det så presterar ju det omvända inget vidare.

Men det jag försökte säga var att en processor som niagara passar inte alla uppgifter heller. Annars hade vi nog sett ett trändbyte. Men bara det att det går så trögt å få 2 eller 4 trådiga program eller mer till PC tex vissar ju varför traditonela processorer lever kvar. Niagar passar ju perfekt i miljöer med mågna trådar sammtidigt och där mer skräddarsyd mjukvara kan tillgås eller skrivas efter behov. Men det är ju itne fallt inom alla områden tyvär.

Hade vi kunnat flertråda alla applikationer över en natt så visst hade det nog var underbart.

Och jag har inte påståt att det är lätt att ladda data i förväg. Snarare ett svårt problem. Är ju inte konstigt at cache utgör över 80% av en modärn CPU och nästan allt annat är för prefetch för att flytal detta cache och nån ynka procent gör beräknigarna.

Ökad banbred ger inte lägra latencer så det kan inte minska antalet cyklar som processorn måste förutspå vad den ska göra.

Men tex att dubbla banbreden skulle ju i teorin tillåta processorn att hämta dubbelt så mycket data till cachet varge gång den får tillgång till det så även om den får ligga 200 cyklar före så kan den hämta 2x datan rent teoretiskt säger vi. Då är ju sannolikheten för en cache miss mindre. Nödvändigtvis inte helften då processorn ofta baserar sin prefetch på data som efterföljer addresen i fråga för instrucktionen den hämtar data för men även försöker den hämta data som kan bli acktuell beroende på vad resultatet av en beräknig blir. Tex om ett värde är sant eller falskt. Processorn försöker ju desutom att gissa utgågen baserad på statestik från tidigare tillfällen den kört samma kod. Men som sagt ju högre latencer ju lägre blir ju kädjan och ju större är ju risken att den gissar fel då fler å fler variablar kommer in i leken.

så ökad banbred kan ju till viss del öka mängden data till å från cachet och minska cachet missar men en fördubbling betyder ju inte mer än kanske 5-10% vinst på en given plattform som exempel.

hade en cpu värkligen kunnat vara synsk så den vetat vad den behövde för data varge cykel 200-300 cyklar framåt så hade den ju kunnat begära specefikt just denna datan 300 cyklar i färväg så det kom in i cachet innan det behövdes och sedan desutom hanterat den optimalt inom cachet och register för att minimera onödig trafik till minnet. Så då hade man nog haft extremt få cachemissar då latencen mer eller mindre blivit irelevant. Men så är det ju inte och en processor lär inte bli synsk nej. Den gissar bara utifrån tidigare erfarenheter och sanolikheter och fins tillfälle så tar den och hämtar mer data än vad som just behövs som har hög sanolikhet att bli acktuel då ledig banbred inte offrar nån prestanda att utnytja. T a tillfället i ackt alltså. Men oavset hur bra man gissar så har man fel för eller senare.

Jag har aldrig försökt bråka om vad saker kostar eller vad som krossar vad. jag har läst om både T1, T2 och Power 5 och 6 och allahanda PPC processorer när dessa var acktuela elelr ur historisk synvinkel. Om MIPS, Z80, x86, Cray osv osv. Igen expert på nån av dom då jag har 0 dator utbildning och är en amatör i den mån men varför jag läser om olika processorer och dess architectur och för å lära mig hur dom fungerar och ju mer man läser om olika architecturer ju mer inser man att det inte fins nån perfekt arkitektur anser jag då man hela tiden bråkar med kända problem och en lösning för ett problem skapar ett annat probelm. Lite som utrycket pest eller kolera.

Gäller fortfarande å välja rätt plattform till rätt uppgift.