Moč je vseprisotna skrb in nemogoče je optimizirati porabo energije sistema brez upoštevanja sistema kot celote. Na področju optimizacije strojne izvedbe so bili narejeni ogromni koraki, vendar to ni več dovolj. Celoten sistem je treba optimizirati.

To ima daljnosežne posledice, od katerih nekatere usmerjajo pot k domensko specifičnemu računalništvu. Premik v levo ima pomembno vlogo, a kar je še pomembneje, pomeni, da morajo vse strani, ki igrajo vlogo pri skupni porabi energije za določeno nalogo, sodelovati, da dosežejo ta cilj.

Energija hitro postaja prvorazredna zadeva. »Ker postaja energetska učinkovitost kritična skrb na vseh področjih računalništva, se od arhitektov pogosto zahteva, da upoštevajo stroške energije algoritmov za načrtovanje strojne in programske opreme,« pravi Guillaume Boillet, višji direktor za upravljanje izdelkov in strateško trženje pri Arteris. »Poudarek se premika od optimizacije izključno za računalniško učinkovitost (hitrost, prepustnost, zakasnitev) k optimizaciji tudi za energetsko učinkovitost (džulov na operacijo). To zahteva upoštevanje dejavnikov, kot so število dostopov do pomnilnika, vzporednost računanja in uporaba specializiranih strojnih pospeševalnikov, ki lahko nudijo energetsko učinkovitejše računanje za določene naloge.«

To premakne fokus z izvedbe strojne opreme na arhitekturno analizo tako strojne kot programske opreme. »V kasnejših fazah načrtovanja se možnosti za optimizacijo zmanjšajo,« pravi William Ruby, direktor produktnega upravljanja v skupini EDA Synopsys. »Morda imate več priložnosti za samodejno optimizacijo, vendar ste omejeni na manjši odstotek izboljšave. Ko upoštevamo krivuljo potencialnih prihrankov (glej sliko 1), ni gladka krivulja od arhitekture do odpisa. Pri sintezi je prelomna točka. Preden je načrt preslikan v izvedbo, imate veliko več stopenj svobode, toda po tej prelomni točki stvari drastično padejo.«

Slika 1: Priložnosti za varčevanje z energijo v fazah načrtovanja. Vir: Synopsys

Velika ovira je, da pred prevojno točko moč postane odvisna od dejavnosti, kar oteži samodejno optimizacijo. »Med razvojem RTL se lahko dinamična vektorsko vodena preverjanja uporabijo za odkrivanje izgube in izvajanje logičnega prestrukturiranja, stribiranja ure, strebljenja operaterja in drugih tehnik za njihovo zmanjšanje,« pravi Qazi Ahmed, glavni produktni vodja pri Siemens EDA. »Pomembno je tudi razumeti, da je moč občutljiva na primere uporabe in jo je treba profilirati z dejanskimi delovnimi obremenitvami, ki jih poganja programska oprema, da zagotovimo, da so zajeti vsi možni scenariji. To še posebej velja v kontekstu celotnega SoC, kjer bi lahko ovojnica moči bila popolnoma drugačna od tiste, ki bi jo lahko pokazala sintetična vektorska analiza na ravni IP.«

»Potrebnega bo več vnaprejšnjega načrtovanja, profiliranja in optimizacije,« pravi Tim Kogel, glavni inženir za virtualno izdelavo prototipov pri Synopsys.

Kogel je opozoril na različne ravni, ki jih je treba obravnavati:

• Na ravni makroarhitekture za analizo kompromisov z velikimi stroški in izbiro namenskih procesnih elementov;
• Na ravni mikroarhitekture za optimizacijo nabora navodil in izvedbenih enot za ciljno aplikacijo;
• Na algoritemski ravni izbira in optimizacija algoritmov za računalniško učinkovitost in dostop do pomnilnika ter
• Na ravni programske opreme zagotavljanje povratnih informacij razvijalcem o tem, kako optimizirati svojo programsko opremo za moč in energijo.

"To bo zahtevalo orodje, ki upošteva moč in energijo, za virtualno izdelavo prototipov in razvoj programske opreme za generiranje podatkov, iz katerih je mogoče optimizirati izvedbo strojne in programske opreme," je opozoril.

Programsko preslikavo
Odločitev, kaj naj bo v programski opremi, je zgodnja naloga. »Ali želim imeti jedro DSP za razbremenitev CPE?« se sprašuje Synopsysova Ruby. »Kako to vpliva na mojo porabo energije? Ali želim implementirati strojni pospeševalnik ali želim vse te funkcije izvajati v programski opremi? Stroški energije programske opreme, ki se izvaja na CPE, niso enaki nič.«

Ker sisteme vse bolj opredeljuje njihova programska oprema, je treba začeti razmišljati o energiji. »Programska oprema je ključni element, ko gre za varčevanje z energijo in izboljšanje zmogljivosti,« pravi Vincent Risson, višji glavni arhitekt CPE za Roka. »Računalniško intenzivne aplikacije imajo pogosto veliko koristi od optimizacije aplikacij. To je lahko statično v smislu zelo prilagojenih knjižnic ali dinamično ogrodje, ki omogoča, da je računanje usmerjeno na najbolj optimalen procesni mehanizem. Mobilne naprave so se na primer standardizirale na sistemski arhitekturi CPE, ki aplikacijskim procesorjem zagotavlja različno računalniško zmogljivost, hkrati pa ustreza skupnemu ISA in konfiguraciji. To omogoča dinamično selitev aplikacij na procesorje, ki so optimalni za učinkovitost. Mehanizmi za introspekcijo in vsestranskost, ki jih zagotavlja kombinacija programske in heterogene strojne opreme, bodo zagotovili priložnosti za izboljšano učinkovitost v prihodnosti.«

Programska oprema lahko pogosto izvaja več kot en razred procesorjev. »Glede na vrste delovnih obremenitev, ki jih vidimo, lahko izberemo, kje naj se določena aplikacija izvaja,« pravi Jeff Wilcox, sodelavec in tehnični direktor skupine za načrtovanje za arhitekture odjemalskih SoC pri Intelu. »Če presega potrebe manjšega jedra, je mogoče zakuriti večja jedra. Na voljo sta telemetrija in karakterizacija delovne obremenitve, da poskusite ugotoviti, kje naj se stvari izvajajo, da bodo najbolj učinkovite z energijo. Veliko delovnih obremenitev, ki jih vidimo zdaj, je drugačnih. Tudi če simetrični agenti delajo na isti obremenitvi, so med seboj odvisni. Vedno več delovnih obremenitev zahteva asimetrične agente, kjer imamo na voljo GPU-je, NPE-je, IPU-je in kjer te vrste delovnih obremenitev sodelujejo s CPE-jem. To je veliko težje optimizirati. Prišli smo do točke, ko imamo kljuke, da lahko razumemo izzive glede zmogljivosti in moči, vendar še vedno gradimo orodja, da bi resnično razumeli, kako to v celoti prebaviti in optimizirati.«

Težava je v tem, da je lahko arhitektura delovne obremenitve odvisna od arhitekture strojne opreme. »Na področju umetne inteligence je veliko razvoja in pomembna ni le velikost modela,« pravi Renxin Xia, podpredsednik strojne opreme pri Untether AI. »Enako pomembno je, kako so modeli izdelani in ali so izdelani na energetsko učinkovit način. Na to je težje odgovoriti, ker je odvisno od arhitekture. Stroški energije algoritma, ki se izvaja na GPE, so lahko zelo različni od stroškov energije tega algoritma, ki se izvaja na pomnilniku v računalniški arhitekturi.«

Osredotočite se na programsko opremo
Splošno soglasje je, da nič od tega ni mogoče brez večjega sodelovanja strojne in programske opreme. »Potreben je skupni razvoj strojne in programske opreme, da bi dosegli te izboljšave stopenjskih funkcij,« pravi Sailesh Kottapalli, višji sodelavec v enoti Intelovega podatkovnega centra. »Samo poskušanje preglednosti v strojni opremi dosega svoje meje. Poglejte, kaj se dogaja v AI. Če bi bila strojna oprema edini element, ne bi videli ogromnega napredka, ki ga vidimo. Veliko tega so algoritemske izboljšave. Če s programskimi algoritmi zmanjšate dolžino poti, lahko dosežete enak rezultat z manjšim številom navodil in zmanjšanim delom programske opreme. Včasih, ko vam je to jasno, lahko ugotovimo, da za te algoritme obstaja nov optimalen nabor navodil, nova mikroarhitektura, nato pa lahko to dodatno optimizirate v strojni opremi.«

Zahteva veliko spremembo v tokovih razvoja programske opreme. »V preteklosti so bile arhitekture in tokovi programske opreme optimizirani za produktivnost, kar pomeni procesorje za splošne namene, programirane z jeziki na visoki ravni, z uporabo najhitrejših in najcenejših programskih orodij,« pravi Kogel iz Synopsysa. »Splošna usmeritev je bila zagotoviti čim večjo prilagodljivost in produktivnost ter optimizirati le toliko, kolikor je nujno potrebno. To je treba obrniti tako, da se zagotovi le toliko prilagodljivosti, kot je potrebno, sicer pa uporabiti namenske izvedbe.«

Za številne funkcije programske opreme je dostop do pomnilnika največji porabnik energije. »Programsko funkcijo je mogoče implementirati na različne načine, kar ima za posledico različne tokove navodil z različnimi profili moči in energije,« pravi Ruby iz Synopsysa. »Navodilom za dostop do pomnilnika morate tehtati ali dodeliti višje stroške. Paziti morate, kako modelirate stvari. Čeprav gre samo za CPE, morate modelirati stroške energije v kontekstu sistema.«

V prihodnosti bo lahko tudi točnost rezultatov dejavnik, ki lahko pomaga pri optimizaciji. »Z optimiziranjem programske opreme za boljšo uporabo razpoložljivih virov strojne opreme je mogoče doseči znatne prihranke energije,« pravi Arterisov Boillet. »To vključuje optimizacije prevajalnika, preoblikovanje kode za zmanjšanje računske kompleksnosti in algoritme, posebej zasnovane za energijsko učinkovitost. Slednje je mogoče doseči s približnim računalništvom za aplikacije, ki lahko dopuščajo določeno stopnjo nenatančnosti, kot je večpredstavnostna obdelava, strojno učenje in analiza podatkov senzorjev.«

Analiza
Vse se začne z analizo. "Ustvarimo lahko virtualni model sistema," pravi Ruby. »Potem lahko definiramo primere uporabe, ki so v tem kontekstu v resnici zaporedje načinov delovanja zasnove. To še ni programska oprema. Sistem imate opisan kot zbirko modelov, tako modelov zmogljivosti kot tudi modelov moči. Dala vam bo profil moči na podlagi teh modelov in primera uporabe, ki ste ga definirali. Naslednja možnost je podoben opis virtualnega sistema. Zdaj proti temu izvajate dejansko delovno obremenitev programske opreme. Če greste še globlje, če želite večjo vidljivost, natančneje zrnate podrobnosti, lahko vzamete RTL opis dizajna, morda še ni dokončen, morda je še zgodaj, a dokler se večinoma premika, ga lahko postavite emulator in zaženite pravo delo. Ko to storite, bo emulator ustvaril podatkovno bazo dejavnosti. Obstajajo zmožnosti analize moči, usmerjene v emulacijo, ki lahko sprejmejo veliko količino podatkov, na stotine milijonov urnih ciklov podatkov o delovni obremenitvi in ​​ustvarijo profil moči. Obstaja vrsta stvari, ki jih je mogoče narediti.«

V nekaterih primerih to morda ni dovolj dolgo obdobje. »Večina naše toplotne analize temelji na analizi z zaprto zanko, zgrajeni na silicijevih podatkih, ne na simulaciji pred silicijem zaradi potrebnih dolžin sledi in količine časa, ki je potreben za analizo,« pravi Kottapalli iz Intela. »Ni načina, da bi lahko simulirali tako dolgo, da bi vzpostavili realističen toplotni profil. Uporabljamo podatke o profilu iz silicija, z uporabo različnih vrst delovnih obremenitev in sledi, nato pa analiziramo, katere rešitve moramo zgraditi.«

Lažje je, če so časovni okviri krajši. "Temeljne arhitekturne odločitve je treba upoštevati z nekakšnim pogledom na moč," pravi Ruby. »Potrebujete višjo raven, bolj abstrakten model vseh delov vašega sistema, vključno z vsemi procesorskimi jedri in pomnilniškim podsistemom, ker je to, kako je to organizirano, zelo, zelo pomembno. Koliko pomnilnika je res potrebno? To so temeljne arhitekturne odločitve. S temi komponentami morate imeti povezane podatke o moči. Koliko energije CPE porabi pri tej določeni delovni obremenitvi ali tisti določeni delovni obremenitvi? Kaj pa jedro DSP, strojna oprema, pomnilnik, omrežje na čipu – koliko vsak od teh porabi pri vsaki operaciji? Ti so potrebni za sprejemanje temeljnih arhitekturnih odločitev.«

Potrebnih je veliko novih orodij, povezanih z energijo. »Medtem ko obstajajo orodja EDA za obvladovanje prehodnih pojavov visoke hitrosti in gostote moči, obstaja veliko drugih izzivov,« pravi Intelov Wilcox. »Nekateri drugi izzivi se nanašajo na daljšo časovno konstantno dinamiko ali na to, kako upravljati stvari v sistemu SoC. V prostoru EDA nisem videl toliko, da bi pomagalo pri tem. Delamo več domačih orodij, da bi poskušali zgraditi te zmogljivosti.«

Medtem ko so bila orodja razvita za strojno stran teh arhitekturnih kompromisov, danes obstaja le malo orodij, ki bi pomagala na strani programske opreme. »Naše programske inženirje potrebujemo, da čim hitreje izdelajo pravilno kodo,« pravi Ruby. »Verjamem, da je resnično potrebna nekakšna spremljevalna tehnologija za razvijalce programske opreme. Tako kot imamo orodja za analizo moči RTL za strojno opremo, sistemi za razvoj programske opreme potrebujejo nekakšen profiler moči, ki jim bo povedal, koliko energije in energije ta koda porabi. Ker zdaj živimo v dobi umetne inteligence, bi bilo kul, če bi tehnologija umetne inteligence analizirala kodo. Dobite oceno porabe energije in nekatera tehnologija umetne inteligence lahko reče, če na ta način prestrukturirate kodo, lahko prihranite veliko energije.«

zaključek
Svet strojne opreme trka ob zidove, povezane z močjo in energijo. Toplotne omejitve in skrbi v tej skupnosti naraščajo. Brez njihovega upoštevanja funkcionalnost strojne opreme ne more rasti. Vendar ti niso dosegli ravni skrbi na sistemski ravni. Dokler se vse strani, ki prispevajo k porabi energije, ne usedejo v isti prostor in načrtujejo energetsko učinkovitega sistema, ne bomo videli pravih rešitev problema.

Obstaja tudi druga stran tega. Vsi ljudje, ki proizvajajo orodja, ki jih ti ljudje uporabljajo, morajo priti v isto sobo in razviti tokove, ki vsem omogočajo uspeh. Medtem ko je bil dosežen določen napredek med EDA in svetom sistemov pri reševanju nekaterih toplotnih izzivov, je manj napredka na arhitekturni ravni in skoraj nobenega napredka med svetom strojne in programske opreme. Virtualni prototipi, ki se osredotočajo na funkcionalnost, niso dovolj. Razširiti jih je treba na moč in energijo sistema, tega pa ni mogoče storiti brez vključitve razvijalcev prevajalnika. Znotraj domensko specifičnega računalništva obstaja priložnost, ker ti ljudje zaradi teh težav ubirajo novo smer v strojni opremi in je zanje morda dovolj pomembno, da napredujejo na sosednjih področjih. A zdi se, da vse skupaj ostaja še dolgo v prihodnosti.

Sorodno branje
Naraščajoča cena moči v čipih
Več podatkov zahteva hitrejšo obdelavo, kar vodi v cel kup težav, ki niso vse očitne ali celo rešljive.

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• PlatoData.Network Vertical Generative Ai. Opolnomočite se. Dostopite tukaj.
• PlatoAiStream. Web3 Intelligence. Razširjeno znanje. Dostopite tukaj.
• PlatoESG. Ogljik, CleanTech, Energija, Okolje, sončna energija, Ravnanje z odpadki. Dostopite tukaj.
• PlatoHealth. Obveščanje o biotehnologiji in kliničnih preskušanjih. Dostopite tukaj.
• vir: https://semiengineering.com/optimizing-energy-at-the-system-level/