2010, En milstolpe för prestandan

[plun]

Johan Lindfors som är utvecklarevangelist på Microsoft skriver ett intressant blogginlägg om "Parallell computing iniative" som kan vara av intresse för fler än utvecklare

http://blogs.msdn.com/johanl/archive/2009/...tis-tandet.aspx

Jo poängen fick han in.....

Det här strukturerade sättet att skapa parallellism bäddar gott inför framtidens ytterligare ökningar av prestanda och hårdvara, i och med att ramverket själv kan skapa ytterligare trådar och distribuera lasten.

Själv är jag mest nyfiken på "molnets broders" lösningar ihop med det här men där är det "hysch-hysch" över det mesta.

Spännande hursomhelst...

[Gäst al6]

Bra länk som berättade på svenska, dock inga realistiska exempel. Jag menar att kodexemplena inte var så verklighetstrogna, det är ju inte bara att lägga till AsParallel så blir programmet parallellt. Ett lite mer praktiskt exempel vore tex quicksort, fibonacci eller någon annan riktig algoritm.

Här kommer ett exempel med quicksort som visar hur enkelt det är att göra en riktig algoritm, parallel med hjälp av Microsofts bibliotek sammarbetande med C++0x's lambdas:

Seriellt, alltså bara något vi utgår från:

void quicksort(int *a, int n)

{

if (n <= 1)

return;

int s = partition(a, n);

quicksort(a, s);

quicksort(a + s, n - s);

}

Parallelt, använder Parallell Pattern Library (Microsoft) och lambdas (C++0x), det blåa är PPL och det röda är lambda, det resterande är ju den koden vi utgick från:

void quicksort(int *a, int n)

{

if (n <= 1)

return;

int s = partition(a, n);

task_group tg;

tg.run([&](){quicksort(a, s);});

tg.run([&](){quicksort(a + s, n - s);});

tg.wait();

}

Vad man nu gjort är att dela upp quicksortalgoritmen i 2 "tasks" som sen kan köras av concurrency runtime. Som ni ser är det fruktansvärt komfortabelt och med minimal ändraing vi gör om hela quicksort till att bli parallel. Om vi nu skulle köra den nedre koden på ett system med kanske 16 kärnor så förstår ni hur groteskt den skulle utklassa den övre koden (teoretiskt 16 gånger snabbare). Och eftersom man överlämnar hanteringen av trådar till concurrency runtime så körs samma kod på olika antal trådar beroende på hur många kärnor CPU:n har. Helt enkelt är Visual Studio 2010 och C++0x vad IT-världen behöver.

Kollar man på TIOBE ser man att intresset för C++ åter igen ökar stort Snart kommer Visual Studio 2010 Beta och då jävlar blir det av att testa.

[Andreas Stenhall]

Snubblade över detta idag http://channel9.msdn.com/shows/Going+Deep/...-Scheduler-UMS/ Jag har dock inte kollat på videon men beskrivningen låter lovande!

[Gäst al6]

Snubblade över detta idag http://channel9.msdn.com/shows/Going+Deep/...-Scheduler-UMS/ Jag har dock inte kollat på videon men beskrivningen låter lovande!

Har sett den och den är faktiskt inte intressant.

Handlar bara om hur kärnan hanterar trådar och sånt och när dom äntligen kommer till concurrency runtime så säger intervjuaren "vi har redan pratat om concurrency runtime här på channel9". Dock har jag nu sett det mesta det finns att se om concurrency runtime och dom nya biblioteken så jag väntar bara på betan

[plun]

Snubblade över detta idag http://channel9.msdn.com/shows/Going+Deep/...-Scheduler-UMS/ Jag har dock inte kollat på videon men beskrivningen låter lovande!

MarkR intervjun till höger är en höjdare.... plugga i lurarna i din bärbara och sofflocket..

Undra vad Intel o AMD klurar på med Speedstep och att styra kärnnyttjandet... ?

Mjukvaran måste ju gå i takt med hårdvaran och här kan man skapa något isf som med Vista som

är enbart "luft"....

[Gäst al6]

De netbooks som använder Intel Atom-processorn kan få en rejäl knuff i och med dessa bibliotek. Atom använder Hyper-Threading vilket i praktiken är samma som om processorn hade två kärnor. Därför är det viktigt att köra parallel kod på sin netbook om man vill pressa fram ny prestanda, vilket förmodligen är vad alla vill. Med ett simpelt test på en eeePC idag kunde jag konstatera att om man kör parallel kod på den så ökar prestandan med hela 66% (från att uträkningen tagit 6 sekunder med seriell kod, till att endast ta 4 sekunder med parallel kod). Börjar man sälja netbooks med riktiga dual core blir det ännu viktigare.

[Gäst al6]

Det börjar hända saker på allvar nu...

Microsoft släpper snart sin Visual Studio 2010 Beta 1 och Linuxvärlden har redan fått smaka lite i och med en ny version av kompilatorn. Självklart var jag tvungen att testa detta; jag laddade hem Fedora 11 med den nya kompilatorn och började testa diverse grejer. Jag gjorde till slut den klassiska fibonacciräknaren, men vad som är annorlunda med denna är att den inte beror på någon som helst kod från Microsoft, utan endast använder standardiserad kod och därmed kan kompileras på alla plattformar - Windows, Linux, Mac OS X, Solaris, BSD, you name it! Vad jag vill visa är alltså fullt möjligt att göra på vilken plattform som helst när den nya standarden kommer. Låt oss kolla på en bild:

Här ser man den gamla visan igen: först räknas fibonaccivärdet 40 ut med seriell kod, alltså på det sättet vi har räknat ut saker med datorer sedan medeltiden. Detta tar 4 sekunder på min dator. I system monitorn ser man att det endast är min ena kärna (blå) som arbetar medan den andra (svart) totalt slappar omkring utan att göra nytta.

Andra testet visar hur fibonaccivärdet 40 åter igen räknas ut fast med parallell kod, alltså på det sättet vi nu och i framtiden bör räkna ut saker med datorer. Vi kommer fram till samma värde, men uträkningen tar endast 2 sekunder nu, något man lätt kan förstå när man kollar i system monitorn och ser att båda kärnorna (blå och svart) nu arbetar parallellt för full rulle. Vi har alltså tagit till vara på datorns kapacitet till fullo.

När jag först postade i denna tråden var jag väldigt intresserad av Microsofts tillägg i nya Visual Studio 2010, visst är jag det fortfarande men jag har nu insett att man på egen hand ganska lätt kan ta hand om viss parallell kod endast genom att använda vanlig standardkod.

Vad är då intressant? Allt som programmeras idag har någon koppling till C++. Alla spel, alla virtuella maskiner, alla operativsystem är beroende av C++ och vad passar då inte bättre än denna extrema uppdatering av det gamla språket. I den nuvarande C++ kan man inte ens skapa en tråd, för att nu helt plötsligt bli trådmästar-ninja-h4x0rz

Hela IT-samhället kommer dra nytta av denna feta uppdatering.

[JoWa]

1 kärna: 4 sekunder

2 kärnor: 2 sekunder

4 kärnor: 1 sekund?

8 kärnor: ½ sekund??

O.s.v.…

Kan man räkna så, eller är det just mellan en och två kärnor den stora skillnaden är?

[Gäst al6]

Som jag har förstått det så kan man göra parallell kod till två kärnor ganska lätt. Denna räknaren använder maximalt två kärnor. Ska man upp till, låt oss säga 8 kärnor får man använda andra tekniker som har mer overhead, alltså onödiga instuktioner.

Det finns tekniker där man har en kö och så många trådar som det finns kärnor. När man vill räkna ut något paketerar man in ett par instuktioner till ett "miniprogram" och lägger detta miniprogram på kön. När då alla trådar läser från kön kommer miniprogrammet att köras på en av dessa trådar. En uppgift kan bestå av flera tusen "miniprogram" som då läggs i kön och dom här trådarna får köra. På detta sätt kan man enkelt göra kod som utnyttjar flera tusen kärnor, men som du kan ana så tar ju själva kösystemet och paketerignssystemet lite av prestandan så det lönar sig inte på en skrutten dual core, där får man lösa problemet med mindre overhead för att få någon prestandaökning.

Jag såg ett exempel där 8 kärnor körde ett program 5 gånger så snabbt som när det kördes av en kärna. Vi skulle i den perfekta världen utan overhead ha ökat prestandan med 8 gånger, men eftersom kösystemet tar en del så ökade vi bara 5 gånger. Parallell kod är egentligen inte en optimering, det är bara ett sätt att utnyttja datorn bättre. "Verkningsgraden" i ett parallellt program är mycket lägre än i ett seriellt program - man kan likna det med en bensinbil där endast 10% (typ) går till att driva bilen fram och resten går åt till värme (overhead), med eftersom vår planet är (var) proppfull av bensin gör det inget eftersom vi ändå kan komma upp i sjuka hastigheter.

Det är lite samma sak med parallell kod; vi gör egentligen programmen långsamamre och klumpgare (mer kod, onödiga kösystem, mer minnesanvändning) men eftersom vi har så sjukt snabb hårdvara nu och i framtiden gör det inget, vi vinner ändå på det eftersom seriell kod bara kan utnyttja en endaste kärna.

[JoWa]

Tack för förklaringen.

Hoppas i alla fall på lätta och lättdrivna system…