Share via

Kodar man för multi-core i framtiden?

  • Article

Sitter på TechDays och lyssnar på keynote med Daniel Akenine när han pratar kort om vad som händer när multi-core anläder på bred front, och Johan Lindfors gjorde även en kort demo av Parallel Extension for .NET (numera del av .NET 4.0). Eftersom jag för några dagar sedan skrev ett inlägg (delvis inspirerat av Daniel) om just multi-core utan att skicka upp det så är det väl dags att göra det nu!

---

Jag kollade på Daniel Akenines blog och när jag såg hans inlägg om vad som blir viktigt när antalet processorkärnor ökar kom jag att tänka på en Channel 9 intervju med Pat Helland som jag tittade på för ett tag sedan. Pat jobbar idag i SQL Server teamet men var på 90-talet en av huvudpersonerna bakom Microsoft Transaction Server (MTS) för er som minns den (föregångaren till COM+).

I ARCast.TV - Pat Helland on the Drive to Many-Core Processors beskriver Pat varför vi kommer se en utveckling mot fler kärnor i våra processorer. Det går inte att bara öka GHz hela tiden utan begränsningar finns bl.a. i den värmeutveckling som snabbare processorer (mätt i GHz) utstrålar samt i hur snabbt minne kan accessas. Lösningen är då att lägga ihop flera lite långsammare kärnor i en processor och därmed få ut mer prestanda. Idag är två kärnor standard och nyare datorer börjar komma med fyra kärnor. Pats slutsats är att det om några år inte kommer vara konstigt om en processor har 256 kärnor och kopplat till det kan man konstatera att Windows Server 2008 R2 kommer stödja upp till 256 kärnor.

Frågan jag ställer mig är hur mycket av detta som kommer påverka utvecklarna. Optimalt vore såklart om kompilatorerna eller run-time miljön gjorde automatiska omstruktureringar och optimeringar av den kod utvecklaren skriver.

Om det inte sköts automatiskt måste utvecklarna själva vara medvetna om både HUR man skriver parallell kod och NÄR man ska använda parallella funktioner. Jag tror att detta inte är något som den typiska utvecklaren kommer ha kompetens att utföra.

Troligen blir utvecklingen liknande det som har skett med programmering mot trådar. Genom Win32 API finns idag möjligheter att fullt utnyttja Windows trådmodell men det utnyttjas av ytterst få utvecklare. Då är det nog vanligare att man i t.ex. ett användargränssnitt använder .NET för att starta en aktivitet i bakgrunden, men egentligen så behöver man inte veta något om trådar utan trådhanteringen sker helt dolt under ytan.

Under 2000-talet har jag själv mestadels jobbat med BizTalk och SharePoint och då har trådproblematiken i den kod som utvecklaren själv skriver inte varit någon stor fråga (om man bortser från användning av global statiska data). Däremot har det vid flera tillfällen varit diskussioner kring hur många och när trådar allokeras i COM+, BizTalk och SharePoint. För det är nämligen viktigt att att ta hänsyn till trådhanteringen hos underliggande system för att få en korrekt lösning, men det betyder inte att du själv måste hantera trådarna när du programmerar.

I vår TechDays sessions (SharePoint Workflows - experiences from the field) kommer vi att komma in på hur man bör ta hänsyn till egenskaper hos SharePoint tråd-pool för workflows när man designar sin lösning, men man behöver inte komma i direkt kontakt med trådprogrammering när man kodar lösningen mot SharePoint.

Så sammanfattningsvis är min förhoppning att man i framtiden inte kommer behöva bry sig så mycket om det finns 1 eller 256 kärnor utan det kan skötas av de underliggande systemet, precis som hanteringen av trådar fungerar idag.

/Mattias

Comments