Kraft är ett allmänt bekymmer och det är omöjligt att optimera ett systems energiförbrukning utan att ta hänsyn till systemet som helhet. Stora framsteg har gjorts i optimeringen av en hårdvaruimplementation, men det räcker inte längre. Hela systemet måste optimeras.
Det finns långtgående konsekvenser av detta, av vilka några driver vägen mot domänspecifik datoranvändning. Vänsterväxling spelar roll, men ännu viktigare betyder det att alla parter som spelar en roll i den totala energiförbrukningen för en definierad uppgift måste samarbeta för att uppnå det målet.
Energi håller snabbt på att bli ett förstklassigt övervägande. "Eftersom energieffektivitet blir ett kritiskt problem inom alla datorområden, uppmanas arkitekter ofta att överväga energikostnaden för algoritmer för både hårdvaru- och mjukvarudesign", säger Guillaume Boillet, senior chef för produktledning och strategisk marknadsföring för Arteris. "Fokus skiftar från att enbart optimera för beräkningseffektivitet (hastighet, genomströmning, latens) till att också optimera för energieffektivitet (joule per operation). Detta kräver att man beaktar faktorer som antalet minnesåtkomster, parallelliseringsförmågan hos beräkningen och användningen av specialiserade hårdvaruacceleratorer som kan erbjuda mer energieffektiv beräkning för vissa uppgifter."
Detta flyttar fokus från hårdvaruimplementering till arkitektonisk analys av både hårdvaran och mjukvaran. "Under de senare stadierna av designflödet minskar möjligheterna till optimering", säger William Ruby, produktledningschef inom EDA Group of Synopsys. "Du kanske har fler möjligheter till automatisk optimering, men du är begränsad till en mindre procentuell förbättring. När man överväger kurvan för potentiella besparingar (se figur 1), är det inte en jämn kurva från arkitektur till sign-off. Det finns en böjningspunkt vid syntesen. Innan designen mappas till en implementering har du många fler frihetsgrader, men efter denna brytpunkt tappar saker drastiskt.”
Fig.1: Möjligheter till energibesparing under designstadier. Källa: Synopsys
Den stora barriären är att kraften före vändpunkten blir aktivitetsberoende, och det gör automatisk optimering mycket svårare. "Under RTL-utveckling kan dynamiska vektordrivna kontroller användas för att avslöja slöseri och utföra logisk omstrukturering, klockstyrning, operatörsgrindning och andra tekniker för att minska det", säger Qazi Ahmed, produktchef på Siemens EDA. "Det är också viktigt att förstå att makt är känsligt för användningsområden och måste profileras med faktiska mjukvarudrivna arbetsbelastningar för att säkerställa att alla möjliga scenarier täcks. Detta är särskilt sant i sammanhanget av den fullständiga SoC, där effektenveloppen kan vara helt annorlunda än vad syntetisk vektordriven analys på IP-nivå kan visa."
"Mer förhandsplanering, profilering och optimering kommer att krävas", säger Tim Kogel, chefsingenjör för virtuell prototypframställning på Synopsys.
Kogel pekade på olika nivåer som måste åtgärdas:
- På makroarkitekturnivå, för analys av stora affärer och val av dedikerade bearbetningselement;
- På mikroarkitekturnivå, för att optimera instruktionerna och exekveringsenheterna för målapplikationen;
- På algoritmisk nivå, val och optimering av algoritmer för beräkningseffektivitet och minnesåtkomst, och
- På mjukvarunivå, ge feedback till utvecklare om hur de kan optimera sin mjukvara för kraft och energi.
"Detta kommer att kräva kraft- och energimedvetna verktyg för virtuell prototypframställning och mjukvaruutveckling för att generera data, från vilken hårdvaru- och mjukvaruimplementeringen kan optimeras," noterade han.
Mappning av programvara
Att bestämma vad som ska finnas i programvaran är en tidig uppgift. "Vill jag ha en DSP-kärna för att ladda processorn?" frågar Synopsys' Ruby. "Hur påverkar det min strömförbrukning? Vill jag implementera en hårdvaruaccelerator, eller vill jag utföra alla dessa funktioner i mjukvara? Energikostnaden för programvara som körs på CPU:n är inte noll."
Eftersom system blir alltmer definierade av deras mjukvara, är det där hänsyn till energi måste börja. "Programvaran är en nyckelfaktor när det gäller att spara energi och förbättra prestanda", säger Vincent Risson, senior chef CPU-arkitekt för Ärm. ”Datorintensiva applikationer drar ofta stor nytta av applikationsoptimering. Detta kan vara både statiskt i termer av högt avstämda bibliotek eller dynamiska ramverk som gör att beräkningar kan riktas mot den mest optimala bearbetningsmotorn. Till exempel har mobila enheter standardiserats på en CPU-systemarkitektur som ger applikationsprocessorer olika beräkningsprestanda samtidigt som de överensstämmer med en gemensam ISA och konfiguration. Detta gör att applikationer kan migreras dynamiskt till de processorer som är optimala för effektivitet. Mekanismer för introspektion och mångsidighet, som tillhandahålls av kombinationen av både mjukvara och heterogen hårdvara, kommer att ge möjligheter till förbättrad effektivitet i framtiden."
Det finns ofta mer än en klass av processorer som programvara kan köra. "Vi kan välja, baserat på de typer av arbetsbelastningar som vi ser, var en given applikation ska köras", säger Jeff Wilcox, fellow och design engineer group CTO för klient SoC-arkitekturer på Intel. "Om det överstiger behoven för en mindre kärna, kan större kärnor eldas upp. Det finns telemetri och arbetsbelastningskarakterisering för att försöka ta reda på var saker ska köras för att vara mest energieffektiva. Många av arbetsbelastningarna som vi ser nu är annorlunda. Även om det är symmetriska agenter som arbetar med samma arbetsbelastning, har de beroenden mellan varandra. Allt fler arbetsbelastningar kräver asymmetriska agenter, där vi har GPU:er, NPU:er, IPU:er tillgängliga och där dessa typer av arbetsbelastningar samarbetar med CPU:n. Det är mycket svårare att optimera. Vi har kommit till den punkt där vi har krokarna för att kunna förstå prestanda- och kraftutmaningarna, men vi bygger fortfarande verktygen för att verkligen förstå hur man kan smälta och optimera det fullt ut.”
Svårigheten här är att arkitekturen för arbetsbelastningen kan bero på hårdvarans arkitektur. "Det finns många utvecklingar inom området AI, och det är inte bara storleken på modellen som är viktig", säger Renxin Xia, vice vd för hårdvara på Untether AI. – Det är lika viktigt hur modellerna är uppbyggda och om de är uppbyggda på ett energieffektivt sätt. Det är svårare att svara på eftersom det är arkitekturberoende. Energikostnaderna för en algoritm som körs på en GPU kan vara mycket annorlunda än energikostnaden för den algoritmen som körs på ett minne vid datorarkitektur."
Fokusera på mjukvara
Den allmänna samsynen är att inget av detta är möjligt utan mer hård- och mjukvarusamarbete. "Samutveckling av maskinvara och mjukvara behövs för att få dessa stegfunktionsförbättringar", säger Sailesh Kottapalli, senior fellow i Intels datacenterenhet. "Bara att försöka göra det transparent i hårdvara når sina gränser. Titta på vad som händer inom AI. Om hårdvara var det enda elementet, skulle vi inte se den massiva utvecklingen vi ser. Mycket av det är algoritmiska förbättringar. Med mjukvarualgoritmer, om du minskar sökvägslängden, kan du uppnå samma resultat med färre antal instruktioner och minskat mjukvaruarbete. Ibland när du får klarhet i det kan vi ta reda på att det för dessa algoritmer finns en ny optimal instruktionsuppsättning, en ny mikroarkitektur, och sedan kan du optimera det ytterligare i hårdvara.”
Det kräver en stor förändring i mjukvaruutvecklingsflöden. "Tidigare optimerades arkitekturer och mjukvaruflöden för produktivitet, vilket betyder processorer för allmänna ändamål programmerade med högnivåspråk, med de snabbaste och billigaste mjukvaruverktygen", säger Synopsys' Kogel. "Den allmänna inriktningen var att ge så mycket flexibilitet och produktivitet som möjligt, och bara optimera så mycket som absolut nödvändigt. Detta måste vändas till att bara ge så mycket flexibilitet som krävs, och i övrigt använda dedikerade implementeringar."
För många programvarufunktioner är minnesåtkomst den största energikonsumenten. "En mjukvarufunktion kan implementeras på olika sätt, och det resulterar i olika instruktionsströmmar med olika effekt- och energiprofiler", säger Synopsys Ruby. "Du måste väga eller tilldela tyngre kostnader till instruktionerna för minnesåtkomst. Du måste vara försiktig med hur du modellerar saker. Även om det bara är CPU:n måste du modellera energikostnaderna i systemsammanhang.”
I framtiden kan resultatnoggrannhet också vara en faktor som kan hjälpa till med optimering. "Betydande energibesparingar kan uppnås genom att optimera programvara för att bättre använda tillgängliga hårdvaruresurser", säger Arteris Boillet. "Detta inkluderar kompilatoroptimeringar, kodrefaktorering för att minska beräkningskomplexiteten och algoritmer speciellt utformade för att vara energieffektiva. Det senare kan uppnås med ungefärlig beräkning för applikationer som kan tolerera en viss grad av oprecision, som multimediabehandling, maskininlärning och sensordataanalys.”
Analys
Allt börjar med analys. "Vi kan skapa en virtuell modell av systemet", säger Ruby. "Då kan vi definiera användningsfall, som i det här sammanhanget egentligen är en sekvens av driftsätt för designen. Det är inte mjukvara ännu. Du har systemet beskrivet som en samling modeller, både prestandamodeller och kraftmodeller. Och det kommer att ge dig en kraftprofil baserad på dessa modeller och det användningsfall som du har definierat. Nästa alternativ är en liknande typ av virtuell systembeskrivning. Nu kör du en verklig mjukvarubelastning mot det. Om du går ännu djupare, vill du ha mer synlighet, finare detaljer kan du ta RTL-beskrivningen av designen, kanske är den inte slutgiltig ännu, kanske är det fortfarande tidigt, men så länge det mestadels vickar kan du sätta på det en emulator och kör det riktiga arbetet. När du gör det kommer emulatorn att generera en aktivitetsdatabas. Det finns emuleringsorienterade effektanalysfunktioner som kan ta en stor mängd data, hundratals miljoner klockcykler av arbetsbelastningsdata och generera en effektprofil. Det finns ett spektrum av saker som kan göras.”
I vissa fall kanske det inte är tillräckligt lång tid. "De flesta av våra termiska analyser är baserade på sluten slinga-analys, byggd på kiseldata, inte på pre-silikonsimulering på grund av de spårlängder som krävs och den tid som krävs för analysen", säger Intels Kottapalli. "Det finns inget sätt vi kan simulera så länge för att få en realistisk termisk profil etablerad. Vi använder profildata från kisel, med olika typer av arbetsbelastningar och spår, och sedan analyserar vi vilka lösningar vi behöver bygga.”
Det är lättare när tidsramarna är kortare. "Fundamentala arkitektoniska beslut måste övervägas med någon slags maktsyn i åtanke", säger Ruby. "Du behöver en högre nivå, mer abstrakt modell av alla delar av ditt system inklusive alla bearbetningskärnor och minnesundersystemet, för hur det är organiserat är verkligen, verkligen viktigt. Hur mycket minne behövs egentligen? Detta är grundläggande arkitektoniska beslut. Du måste ha vissa strömdata kopplade till dessa komponenter. Hur mycket ström förbrukar CPU:n under just den här arbetsbelastningen eller den specifika arbetsbelastningen? Hur är det med DSP-kärnan, hårdvaran, minnet, nätverket på chippet – hur mycket förbrukar var och en av dessa när man gör varje operation? De krävs för att fatta grundläggande arkitektoniska beslut."
Det krävs många nya elrelaterade verktyg. "Medan EDA-verktyg finns för att hantera höghastighetstransienter med hög effekttäthet, finns det många andra utmaningar", säger Intels Wilcox. "Några av de andra utmaningarna är att titta på längre tidskonstant dynamik, eller hur man hanterar saker över hela SoC. Jag har inte sett så mycket i EDA-utrymmet som hjälper till med det. Vi gör fler egentillverkade verktyg för att försöka bygga upp dessa funktioner."
Även om verktyg har utvecklats för hårdvarusidan av dessa arkitektoniska kompromisser, finns det få verktyg idag för att hjälpa till på mjukvarusidan. "Vi behöver våra mjukvaruingenjörer för att producera korrekt kod så snabbt som möjligt", säger Ruby. "Vad jag tror verkligen behövs är någon slags följeslagningsteknik för mjukvaruutvecklaren. Precis som vi har RTL-energianalysverktyg för hårdvaran, behöver mjukvaruutvecklingssystem någon sorts effektprofilerare som talar om för dem hur mycket ström och energi den här koden förbrukar. Eftersom vi nu lever i AI:s tidsålder skulle det vara coolt att låta AI-teknik analysera koden. Du får en uppskattning av strömförbrukningen och viss AI-teknik kan säga att om du strukturerar om din kod på detta sätt kan du spara mycket ström."
Slutsats
Hårdvaruvärlden slår mot väggar relaterade till kraft och energi. Termiska gränser och farhågor växer inom det samhället. Utan att ta hänsyn till dem kan hårdvarufunktionaliteten inte växa. Men dessa har inte nått den nivå som är problem på systemnivå. Förrän alla parter som bidrar till energiförbrukningen sätter sig i samma rum och designar systemet för att vara energieffektivt, kommer vi inte att se riktiga lösningar på problemet.
Det finns en andra sida av detta också. Alla människor som producerar verktygen de använder måste också komma in i samma rum och utveckla flöden som gör att alla kan bli framgångsrika. Även om det har gjorts vissa framsteg mellan EDA och systemvärlden för att lösa några av de termiska utmaningarna, finns det mindre framsteg på arkitektonisk nivå, och nästan inga framsteg mellan hårdvaru- och mjukvaruvärlden. Virtuella prototyper som koncentrerar sig på funktionalitet räcker inte. De måste utökas till systemkraft och energi, och det kan inte göras utan att kompilatorutvecklarna blir inblandade. Det finns en möjlighet inom domänspecifik datoranvändning, eftersom dessa människor tar en ny riktning inom hårdvara som ett resultat av dessa problem, och det kan vara tillräckligt viktigt för dem att göra framsteg inom de närliggande områdena. Men allt verkar ligga kvar en lång tid fram i tiden.
Relaterad läsning
Det stigande priset på kraft i marker
Mer data kräver snabbare bearbetning, vilket leder till en hel massa problem - som inte alla är uppenbara eller ens lösbara.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
- Källa: https://semiengineering.com/optimizing-energy-at-the-system-level/
