Faktumet att välja en processor med fler kärnor leder ofta inte till en prestandaökning i samma grad när man använder vissa program. Varför uppstår detta fenomen och vad är därför orsakerna till det? Vi förklarar det för dig i detalj.
En av anledningarna till att använda nyare versioner av program med tiden är att de är designade för att bättre dra nytta av processorer med högre kärnantal. Låt oss inte glömma att med tiden ökar antalet av dessa i CPU:erna. Men varför ökar inte prestandan i program i paritet?
Program skalas aldrig med antalet kärnor
Det är viktigt att ta hänsyn till att de program som körs inte har förmågan att dela upp sina aktiva processer eller uppgifter vid varje givet tillfälle, enligt antalet exekveringstrådar som vi har i vår CPU. Mer än något annat på grund av det faktum att denna uppdelning är explicit i programkoden, det vill säga den är produkten av programmerarens skicklighet och applikationens design.
Det som är relevant när man kodar ett program är egentligen inte att optimera det för att använda så många kärnor som möjligt, utan snarare för latens. Att förstå det senare som den tid det tar en processor att slutföra en uppgift mätt i tidsenheter. Och det är att prestandan hos en CPU består av att slutföra flest uppgifter på kortast möjliga tid. Vilket kommer att bero på din arkitektur först och din klockhastighet sedan.
Det som dock intresserar oss angående latens är att veta hur många uppgifter den kan slutföra under en given period, vilket är arbetsbelastningen och detta kommer att bero på situationen och hur programmen har skrivits. Med andra ord beror prestanda inte bara på hårdvaran, utan på hur bra eller dåligt programvaran har skrivits.
Arbetsfördelning i flera kärnor
Nu, om vi ökar antalet kärnor i ett system, blir det möjligt att bryta arbetet i bitar och få det slutfört mycket lättare. Det är här T/N-formeln kommer in, där T är antalet uppgifter som ska utföras och N är antalet exekveringstrådar som systemet kan exekvera. Uppenbarligen kunde vi ladda det maximala antalet jobb på några kärnor och brutalt tvinga dem att fixa dem. Problemet är att denna åtgärd är kontraproduktiv eftersom den gynnar de modernaste CPU:erna, som har högre prestanda individuellt på varje kärna.
Att dela upp arbetet mellan olika kärnor är dock ett tilläggsarbete som vanligtvis ges till en kärna som fungerar som ledare och ska utföra följande uppgifter:
- Du måste skapa processer och uppgiftslistor och ha bra koll på det hela tiden.
- De måste hela tiden veta hur de ska förutsäga när en uppgift börjar och slutar, inklusive den tid det tar att slutföra en och påbörja en annan.
- De olika kärnorna måste ha förmågan att skicka en signal till huvudkärnan för att veta när en process startar och slutar.
Denna lösning antogs av SONY, Toshiba och IBM i Cell Broadband Engine, den centrala processorn i PS3 där en huvudkärna ansvarade för att styra resten. Även om den är mycket längre tillbaka antogs den av Atari Jaguar. För PS4 upprepade SONY inte den här modellen igen och ingen har implementerat den på datorn eftersom det är en mardröm, men det är det mest effektiva sättet att dela upp arbetet.
Allt kan inte köras på flera kärnor
Om vi frågar oss om vi kan dela upp någon uppgift i deluppgifter för att fördela i ett större antal kärnor på obestämd tid, är svaret nej. Specifikt måste vi klassificera uppgifter i tre olika typer:
- De som kan parallelliseras totalt och därför delas mellan de olika kärnorna som centralprocessorn har.
- Uppgifter som kan köras delvis parallellt.
- Delar av koden som inte kan köras parallellt.
I det första fallet tillämpas T/N på 100 %, i det andra fallet går vi redan in i den så kallade Amdahls lag där accelerationen på grund av att antalet kärnor ökar är partiell och i det tredje fallet behöver vi helt enkelt alla kraften hos en enda kärna för den uppgiften,
Vad skiljer CPU från GPU i multithreading
Här kommer vi till en skillnad, varje GPU eller grafikchip har en kontrollenhet som ansvarar för att läsa kommandolistorna och fördela dem mellan de olika GPU-kärnorna och även mellan de olika enheterna. Detta är en implementering på hårdvarunivå av det tidigare fallet och fungerar perfekt i alla konfigurationer där du vill mätta, så länge det finns arbete, och därför hålla så många kärnor upptagna som möjligt. Vi måste dock förstå att koncepttråden för exekvering i en GPU alltid motsvarar en motsvarande data och dess lista med instruktioner. Det vill säga en pixel, vertex eller vilken data som helst.
Vilket gör dem lätta att parallellisera. Det vill säga, om vi ville steka ett ägg, skulle processen i CPU:n vara att steka ägget, vilket skulle vara helt sekventiellt. Å andra sidan, i grafikchippet, skulle en uppgift helt enkelt vara att värma olja eller lägga till ett ägg i pannan. Allt detta skulle inte påskynda stekningen av ett ägg, utan flera, varför GPU:er är bättre för uppgifter som att beräkna miljontals polygoner eller pixlar samtidigt, men inte för sekventiella uppgifter.