Citat:
Ursprungligen inskrivet av
Gramner
Du har inte kodat någon modern video encoder va?
Nej och skulle jag göra det så skulle jag använda quick-sync vilket är långt mycket snabbare än även en 4 kärnor / 8 trådars CPU. Men rent teoretiskt så borde det gå att delar upp varje enskild bild i olika areor och jobba oberoende på dessa. Att jobba på flera bilder samtidigt inser jag att det inte fungerar då i princip alla moderna film-komprimeringsalgoritmer bygger på nyckelbilder (key-frames) som innehåller all information och sedan kommer en rad bilder som bara innehåller delta från tidigare bild, i.e. det är omöjligt att jobbat på bild N innan bild N+1 om inte N+1 är nästa nyckelbild.
Om man kan koda film eller inte var heller inte min huvudpoäng, min poäng var att de program som de flesta använder kan i många fall inte ens skrivas om så de använder många CPU-kärnor då de algoritmer som används inte lämpar sig för att köra på flera CPU-kärnor. Om man sedan tittar på hur en modern multicore-CPU faktiskt är uppbygd, främst då hur cache och man håller cache koherent mellan alla CPU-kärnor så borde alla inse att vissa algoritmer kan i teorin köras på många CPU-kärnor, men givet hur CPU:erna fungerar så kommer man få extremt dåligt prestanda-utdelning och i många fall går det faktiskt långsammare när man använder flera CPU-kärnor.
Förutom att
MESI-bussen kommer bli en flaskhals så är det största problemet att det CPU
X skriver/läser är inte exakt synkroniserat med det CPU
Y skriver/läser. I många fall spelar detta ingen roll och i problem som är
embarrassingly parallel så spellar detta i praktiken aldrig någon roll. Men i de fall när det spelar roll måsta man stoppa in speciella instruktioner, s.k. minnesbarriärer samt synkroniserade instruktioner. Problemet med dessa instruktioner är att visst ger de rätt garantier så algoritmen fungerar, men för att kunna ge dessa garantier så måste CPUn vänta in alla minnesoperationer som ligger och väntar på att bli klar innan den kan köra den första instruktionen efter barriären. På Sandy Bridge (har inte läst in mig på Ivy ännu) så kan det vara upp till 160 instruktioner "in-flight", vilket betyder att i värsta fall så måste man vänta in 160 instruktioner innan nästa instruktion kan köras. Alla inser nog vad det har för typ av påverkan på prestanda.
Simplare CPUer som ARM och även Atom/Brazos är faktiskt mycket enklare att få att skala med flera CPU-kärnor än avancerade CPUer som Sandy Bridge och Bulldozer då simplare CPUer är endera in-order (Atom och ARM fram till Cortex A8) eller har extremt kort out-of-order fönster (typ 10-20 instruktioner, inte 160) så kostnaden för minnesbarriärer och synkroniserade instruktioner är relativt sätt mycket lägre. Men även på dessa så sjunker effekten av extra CPU-kärnor snabbt när man börjar komma upp på =>4 CPU-kärnor då även extremt små seriella delar i ett program kraftigt påverkar effekten man får av att öka antalet CPU-kärnor. Något som illustreras väl av
Amdahl's_law.
Ett annat exempel som visar hur dåligt saker skalar med flera CPU-kärnor är benchmarks mellan Tegra3 och Qualcomm S4. Tegra3 är har fyra Cortex A9 kärnor på runt 1.3GHz och S4 har två "Krait" kärnor på runt 1.5GHz. Krait är sedan kanske 20% snabbare även vid samma klockfrekvens. Totalt sett är S4 långsammare, men majoriteten av alla fall som är relevanta på en telefon så är ett system med Krait klart snabbare än ett system med Tegra3.
En bra tumregeln för desktopprogram brukar vara: om du kan välja mellan 30% mer prestanda per tråd eller dubbal antalet CPU-kärnor så är det nästan alltid bättre att öka prestanda per tråd om man är ute efter maximal prestanda. På en server gäller däremot oftast det omvända.
i5 3450S beställd!
en transistordensitet som är 84% högre. 84% mindre yta med samma antalet transistorer skulle ju innebära ** 1/(1-0.84) -1 = 525% ** en ökning av transistordensiteten på 525%. 
Linjär visning
