Citat:
Ursprungligen inskrivet av
Pholostan
Den som skrivit länken har väldigt bra punkter i början som visar varför det i praktiken är nära nog omöjligt att använda Ahmdal's lag till att göra några exakta beräkningar. Men tittar på dessa punkter så inser man rätt snabbt att den parallellism man får i verkligheten är SÄMRE än vad en naiv applicering av Ahmdal´s lag visar, vilket är precis en poäng jag försökt få igenom.
Däremot är has exempel helt galet. Klart det blir fel om man gör uppdelning i seriella och parallella delar på fel sätt. I fall där man har en begränsad och given parallellism så går denna parallellism att ersätta med en motsvarande seriell del. I fallet i länken har han en pipe-line som består av tre delar
Han skriver
Rätt sätt är att ersätta steg 1 och 3 med MAX(steg 1, steg 3) = 2K cykler. Så den seriella delen är 2K cykler och den parallella är 10K cykler. Den snabbaste hastigheten är 2K cykler när man låter antal CPU-kärnor gå mot oändligheten, vilket är rätt.
På samma sätt kan man ersätta något som kan köra på t.ex. tre kärnor (men inte mer) och där varje kärna jobbar 3K cykler med en seriell del som tar 3K cykler.
Men det är i sig ändå irrelevant. Framförallt är det irrelevant för det går i praktiken att veta hur lång tid det tar att exekvera olika delar av programmet, man vet ofta inte exakt hur saker beter sig i monitorer och andra kritiska sektioner (vilket också påpekas i länken).
Det enda relevanta man behöver tänka på, och något Ahmdal's lag illustrerar på ett bra sätt, är att det alltid finns en hård övre gräns för hur mycket man kan parallellirisera ett givet problem. Ratatosk tog upp superdatorer som exempel, men precis som GPU:er används dessa till problem som dels är
embarissingly parallel men ännu viktigare är att de används på problem som inte kräver cache-koherens. Om det är något som sätter en stenhård gräns på hur många kärnor man effektivt kan sätta i en och samma fysiska dator (super-datorer är kluster, d.v.s många fysiska datorer som är ihopkopplade med väldigt snabb kommunikation) så är det cache-koherens samt kostnaden för att distribuera och senare samla ihop problemet till/från alla ingående kärnor.
Så fort ditt program inte får plats i den cache som är lokal för din CPU-kärna så går det i praktiken inte längre att skala linjärt med antal CPU-kärnor. Och även när allt får plats i L1/L2 cache så skalar det ändå inte helt linjärt om någon annan kärna behöver läsa eller skriva i data som någon annan CPU-kärna läst eller skrivit i nyligen.
GPU:er och kluster skalar helt linjärt just därför att de inte är cache-koherenta. Men ett system som inte är cache-koherent blir väldigt ineffektivt på problem där det måste ske relativt mycket kommunikation mellan trådarna. Vissa kanske minns Intel Larrabee... Detta var ett försök av Intel att skapa en cache-koherent GPU då en sådan skulle ha varit extremt mycket lättare och flexiblare som GPGPU. Men en GPU som är cache-koherent kan aldrig tävla med "vanliga" GPUer då skalbarheten när man adderar kärnor (stream-processorer) aldrig blir linjär som den blir på en "vanlig" GPU.
TREVLIG SOMMAR
. Man vill ju spela o se hela spelet man köpt i hela helheten o inte missa det extra som finns...
Okey om det hade varit en sexkärnig phenom II för dom pengarna, då hade jag kunnat leva med den strömförbrukningen. Men 100watt mer än Ivy system och samma/(sämre?) prestanda som jag skulle få bara av att byta ut min cpu mot en 775 quad?!
Linjär visning
