Virta on kaikkialla läsnä oleva huolenaihe, ja on mahdotonta optimoida järjestelmän energiankulutusta ottamatta huomioon järjestelmää kokonaisuutena. Laitteistototeutuksen optimoinnissa on otettu valtavia harppauksia, mutta se ei enää riitä. Koko järjestelmä on optimoitava.

Tällä on kauaskantoisia seurauksia, joista osa ohjaa tietä verkkoaluekohtaiseen tietojenkäsittelyyn. Vasemmalle siirtymisellä on merkitystä, mutta mikä vielä tärkeämpää, se tarkoittaa, että kaikkien osapuolten, joilla on rooli tietyn tehtävän kokonaisenergiankulutuksessa, on tehtävä yhteistyötä tämän tavoitteen saavuttamiseksi.

Energiasta on nopeasti tulossa ensiluokkainen huomio. "Koska energiatehokkuudesta tulee kriittinen huolenaihe kaikilla tietotekniikan aloilla, arkkitehteja pyydetään usein ottamaan huomioon algoritmien energiakustannukset sekä laitteisto- että ohjelmistosuunnittelussa", sanoo Guillaume Boillet, yrityksen tuotehallinnan ja strategisen markkinoinnin johtaja. Arteris. "Painopiste on siirtymässä pelkästään laskennallisen tehokkuuden (nopeus, suoritusteho, latenssi) optimoinnista myös energiatehokkuuden optimointiin (joulea operaatiota kohti). Tämä edellyttää sellaisten tekijöiden huomioon ottamista, kuten muistin käyttökertojen määrä, laskennan rinnakkaisettävyys ja erikoistuneiden laitteistokiihdyttimien käyttö, jotka voivat tarjota energiatehokkaampaa laskentaa tietyissä tehtävissä."

Tämä siirtää painopisteen laitteiston toteutuksesta sekä laitteiston että ohjelmiston arkkitehtoniseen analyysiin. "Suunnittelun myöhemmissä vaiheissa optimointimahdollisuudet vähenevät", sanoo William Ruby, EDA Groupin tuotehallintajohtaja. Synopsys. "Sinulla saattaa olla enemmän mahdollisuuksia automaattiseen optimointiin, mutta sinun on rajoitettu pienempään prosenttiosuuteen. Kun tarkastellaan mahdollisten säästöjen käyrää (katso kuva 1), se ei ole tasainen käyrä arkkitehtuurista kirjautumiseen. Synteesissä on käännekohta. Ennen kuin suunnittelu kartoitetaan toteutukseen, sinulla on paljon enemmän vapausasteita, mutta tämän käännekohdan jälkeen asiat putoavat rajusti.

Kuva 1: Virransäästömahdollisuudet suunnitteluvaiheessa. Lähde: Synopsys

Suuri este on, että ennen käännekohtaa teho muuttuu aktiivisuudesta riippuvaiseksi, mikä tekee automaattisesta optimoinnista paljon vaikeampaa. "RTL-kehityksen aikana dynaamisia vektoriohjattuja tarkistuksia voidaan käyttää hävityksen paljastamiseen ja loogisten uudelleenjärjestelyjen, kellon portituksen, operaattorin portituksen ja muiden tekniikoiden vähentämiseksi", sanoo Qazi Ahmed, yrityksen päätuotepäällikkö. Siemens EDA. "On myös tärkeää ymmärtää, että teho on käyttökohtainen ja se on profiloitava todellisten ohjelmistopohjaisten työkuormien mukaan, jotta kaikki mahdolliset skenaariot katetaan. Tämä pätee erityisesti täyden SoC:n yhteydessä, jossa tehoverhokäyrä voi olla täysin erilainen kuin synteettinen vektoriohjattu analyysi IP-tasolla.

"Tarvitaan enemmän ennakkosuunnittelua, profilointia ja optimointia", sanoo Tim Kogel, Synopsysin virtuaalisen prototyyppien pääinsinööri.

Kogel viittasi eri tasoihin, joihin on puututtava:

• Makroarkkitehtuurin tasolla suurten kompromissien analysointia ja erityisten prosessointielementtien valintaa varten;
• Mikroarkkitehtuurin tasolla optimoida kohdesovelluksen käskysarja ja suoritusyksiköt;
• Algoritmisella tasolla algoritmien valinta ja optimointi laskentatehoa ja muistin käyttöä varten, ja
• Ohjelmistotasolla palautetta kehittäjille siitä, kuinka ohjelmistonsa optimoidaan tehon ja energian saamiseksi.

"Tämä vaatii teho- ja energiatietoisia työkaluja virtuaaliseen prototyyppiin ja ohjelmistokehitykseen datan tuottamiseksi, josta laitteisto- ja ohjelmistototeutus voidaan optimoida", hän huomautti.

Ohjelmistokartoitus
Sen päättäminen, mitä ohjelmistossa pitäisi olla, on varhainen tehtävä. "Haluanko saada DSP-ytimen prosessorin purkamiseen?" kysyy Synopsysin Ruby. "Miten se vaikuttaa virrankulutukseeni? Haluanko ottaa käyttöön laitteistokiihdytin vai haluanko suorittaa kaikki nämä toiminnot ohjelmistossa? Prosessorilla toimivan ohjelmiston energiakustannukset eivät ole nolla."

Kun ohjelmistot määrittävät järjestelmät yhä enemmän, energian huomioon ottaminen on aloitettava tästä. "Ohjelmisto on avaintekijä energian säästämisessä ja suorituskyvyn parantamisessa", sanoo Vincent Risson, vanhempi prosessoriarkkitehti Varsi. ”Tietokonevaltaiset sovellukset hyötyvät usein merkittävästi sovellusten optimoinnista. Tämä voi olla sekä staattista erittäin viritettyjen kirjastojen että dynaamisten puitteiden osalta, jotka mahdollistavat laskennan kohdistamisen optimaalisimpaan käsittelykoneeseen. Esimerkiksi mobiililaitteet ovat standardoituja CPU-järjestelmäarkkitehtuuriin, joka tarjoaa sovellusprosessoreille erilaisen laskentasuorituskyvyn samalla kun ne ovat yhteisen ISA:n ja kokoonpanon mukaisia. Tämä mahdollistaa sovellusten siirtämisen dynaamisesti tehokkuuden kannalta optimaalisiin prosessoreihin. Ohjelmistojen ja heterogeenisten laitteistojen yhdistelmän tarjoamat itsetutkiskelun ja monipuolisuuden mekanismit tarjoavat mahdollisuuksia tehokkuuden parantamiseen tulevaisuudessa.”

Ohjelmisto voi usein käyttää useampaa kuin yhtä prosessoriluokkaa. "Voimme valita näkemiemme työkuormitustyyppien perusteella, missä tietyn sovelluksen tulisi toimia", sanoo Jeff Wilcox, Intelin asiakkaan SoC-arkkitehtuurien suunnitteluryhmän teknologiajohtaja. ”Jos se ylittää pienemmän ytimen tarpeet, voidaan polttaa suurempia ytimiä. Telemetrialla ja työkuorman karakterisoinnilla yritetään selvittää, missä asiat tulisi ajaa, jotta ne olisivat tehokkainta. Monet työmäärät, joita nyt näemme, ovat erilaisia. Vaikka kyseessä ovat symmetriset agentit, jotka työskentelevät samalla työmäärällä, niillä on riippuvuuksia toisistaan. Yhä useammat työmäärät vaativat epäsymmetrisiä agentteja, joissa meillä on saatavilla GPU:ita, NPU:ita, IPU:ita ja joissa tämän tyyppiset työkuormat toimivat yhteistyössä CPU:n kanssa. Se on paljon vaikeampi optimoida. Olemme päässeet siihen pisteeseen, että meillä on koukut pystyäksemme ymmärtämään suorituskyky- ja tehohaasteita, mutta kehitämme edelleen työkaluja ymmärtääksemme, kuinka se voidaan sulattaa ja optimoida.

Vaikeutena tässä on se, että työkuorman arkkitehtuuri voi riippua laitteiston arkkitehtuurista. "Tekoälyn alalla on paljon kehitystä, eikä pelkästään mallin koko ole tärkeä", sanoo Renxin Xia, Untether AI:n laitteistosta vastaava varatoimitusjohtaja. ”Yhtä tärkeää on se, miten mallit rakennetaan ja onko ne rakennettu energiatehokkaasti. Tähän on vaikeampi vastata, koska se on arkkitehtuuririippuvaista. Grafiikkasuorittimella toimivan algoritmin energiakustannukset voivat olla hyvin erilaisia ​​kuin muistissa toimivan algoritmin energiakustannukset laskenta-arkkitehtuurissa."

Keskity ohjelmistoihin
Yleinen yksimielisyys on, että tämä ei ole mahdollista ilman laitteisto-ohjelmisto-yhteistyötä. "Laitteiston ja ohjelmiston yhteiskehitystä tarvitaan näiden askeltoimintojen parantamiseksi", sanoo Intelin datakeskusyksikön vanhempi tutkija Sailesh Kottapalli. "Yrittää tehdä sen läpinäkyvästi laitteistossa saavuttaa rajansa. Katso mitä tekoälyssä tapahtuu. Jos laitteisto olisi ainoa elementti, emme näkisi valtavaa kehitystä, jota näemme. Suuri osa niistä on algoritmisia parannuksia. Ohjelmistoalgoritmeilla, jos lyhennät polun pituutta, voit saavuttaa saman tuloksen pienemmällä määrällä käskyjä ja vähemmän ohjelmistotyötä. Joskus kun saat selvyyden asiaan, voimme selvittää, että näille algoritmeille on uusi optimaalinen käskysarja, uusi mikroarkkitehtuuri, ja sitten voit optimoida sitä edelleen laitteistossa.

Se vaatii suuren muutoksen ohjelmistokehitysvirroissa. "Aiemmin arkkitehtuurit ja ohjelmistovirrat optimoitiin tuottavuutta varten, mikä tarkoitti yleiskäyttöisiä prosessoreita, jotka oli ohjelmoitu korkean tason kielillä käyttäen nopeimpia ja edullisimpia ohjelmistotyökaluja", sanoo Synopsys' Kogel. ”Yleinen suunta oli tarjota mahdollisimman paljon joustavuutta ja tuottavuutta ja optimoida vain niin paljon kuin on ehdottoman välttämätöntä. Tämä on käännettävä niin, että se tarjoaa vain niin paljon joustavuutta kuin vaaditaan, ja muuten on käytettävä erityisiä toteutuksia."

Monissa ohjelmistotoiminnoissa muistin käyttö on suurin virrankuluttaja. "Ohjelmistotoiminto voidaan toteuttaa eri tavoin, ja tämä johtaa erilaisiin käskyvirtoihin eri teho- ja energiaprofiileilla", sanoo Synopsys' Ruby. ”Muistin käyttöohjeisiin on painotettava tai kohdistettava suurempia kustannuksia. Sinun on oltava varovainen, kuinka mallintaa asioita. Vaikka se on vain prosessori, sinun on mallinnettava energiakustannukset järjestelmäkontekstissa.

Tulevaisuudessa myös tulosten tarkkuus voi olla yksi tekijä, joka voi auttaa optimoinnissa. "Optimoimalla ohjelmistoja voidaan saavuttaa huomattavia virransäästöjä käytettävissä olevien laitteistoresurssien parempaan käyttöön", Arteris' Boillet sanoo. "Tämä sisältää kääntäjien optimoinnit, koodin uudelleenjärjestelyt laskennan monimutkaisuuden vähentämiseksi ja algoritmit, jotka on suunniteltu erityisesti energiatehokkaiksi. Jälkimmäinen voidaan saavuttaa likimääräisellä laskennalla sovelluksille, jotka voivat sietää jonkin verran epätarkkuutta, kuten multimedian käsittely, koneoppiminen ja anturidatan analyysi."

analyysi
Kaikki alkaa analyysistä. "Voimme luoda järjestelmästä virtuaalisen mallin", Ruby sanoo. ”Sitten voimme määritellä käyttötapauksia, mikä tässä yhteydessä on oikeastaan ​​suunnittelun toimintatapojen sarja. Se ei ole vielä ohjelmisto. Sinulla on järjestelmä, joka on kuvattu kokoelmana malleja, sekä suorituskykymalleja että tehomalleja. Ja se antaa sinulle tehoprofiilin, joka perustuu näihin malleihin ja määrittelemääsi käyttötapaukseen. Seuraava vaihtoehto on samanlainen virtuaalisen järjestelmän kuvaus. Nyt käytät todellista ohjelmistotyökuormaa sitä vastaan. Jos mennään vielä syvemmälle, jos haluat enemmän näkyvyyttä, hienojakoisempia yksityiskohtia, voit ottaa mallin RTL-kuvauksen, ehkä se ei ole vielä lopullinen, ehkä se on vielä aikaista, mutta niin kauan kuin se enimmäkseen heiluu, voit laittaa sen emulaattori ja suorita todellista työtä. Kun teet sen, emulaattori luo toimintatietokannan. On olemassa emulointiin suuntautuneita tehoanalyysiominaisuuksia, jotka voivat viedä suuren määrän dataa, satoja miljoonia kellojaksoja työkuormatietoa ja luoda tehoprofiilin. On monia asioita, joita voidaan tehdä."

Joissakin tapauksissa se ei ehkä ole tarpeeksi pitkä aika. "Suurin osa lämpöanalyysistämme perustuu suljetun silmukan analyysiin, joka perustuu piitietoihin, ei piitä edeltävään simulointiin, koska analyysiin tarvitaan jälkiä ja aikaa", sanoo Intelin Kottapalli. "Emme voi mitenkään simuloida niin kauan, jotta saadaan realistinen lämpöprofiili. Käytämme piistä peräisin olevaa profiilidataa erilaisten työkuormien ja jälkien avulla, minkä jälkeen teemme analyysin siitä, mitä ratkaisuja meidän on rakennettava.

Se on helpompaa, kun aikavälit ovat lyhyempiä. "Perusrakenteellisia päätöksiä on harkittava jonkinlainen valtanäkökulma mielessä", Ruby sanoo. "Tarvitset korkeamman tason, abstraktimman mallin kaikista järjestelmäsi osista, mukaan lukien kaikki prosessointiytimet ja muistialijärjestelmä, koska sen järjestäminen on todella, todella tärkeää. Kuinka paljon muistia todella tarvitaan? Nämä ovat perustavanlaatuisia arkkitehtonisia päätöksiä. Näihin komponentteihin on liitettävä virtatietoja. Kuinka paljon prosessori kuluttaa virtaa tällä tietyllä tai tietyllä työkuormalla? Entä DSP-ydin, laitteisto, muisti, sirulla oleva verkko – kuinka paljon kukin niistä kuluttaa kunkin toiminnon aikana? Heitä vaaditaan perustavanlaatuisten arkkitehtonisten päätösten tekemiseen."

Tarvitaan monia uusia tehoon liittyviä työkaluja. "Vaikka EDA-työkaluja on olemassa nopeiden ja suuritehoisten transientien käsittelyyn, on monia muita haasteita", sanoo Intelin Wilcox. "Jotkut muut haasteet liittyvät pidemmän ajan vakiodynamiikkaan tai asioiden hallintaan SoC:n sisällä. En ole nähnyt EDA:ssa niin paljon, mikä auttaisi siinä. Teemme lisää kotitekoisia työkaluja yrittääksemme kehittää näitä ominaisuuksia."

Vaikka työkaluja on kehitetty näiden arkkitehtonisten kompromissien laitteistopuolelle, ohjelmistopuolella on nykyään vain vähän työkaluja. "Tarvitsemme ohjelmistosuunnittelijoitamme tuottamaan oikean koodin mahdollisimman nopeasti", Ruby sanoo. ”Mielestäni todella tarvitaan, on jonkinlainen kumppaniteknologia ohjelmistokehittäjälle. Aivan kuten meillä on RTL-tehoanalyysityökaluja laitteistolle, ohjelmistokehitysjärjestelmät tarvitsevat jonkinlaisen tehoprofiilin, joka kertoo, kuinka paljon virtaa ja energiaa tämä koodi kuluttaa. Koska elämme nyt tekoälyn aikakautta, olisi siistiä saada tekoälyteknologia analysoimaan koodia. Saat arvion virrankulutuksesta, ja jotkut tekoälytekniikat saattavat sanoa, että jos järjestät koodisi uudelleen tällä tavalla, voit säästää paljon virtaa."

Yhteenveto
Laitteistomaailma iskee tehoon ja energiaan liittyviä seiniä. Termiset rajat ja huolenaiheet kasvavat tässä yhteisössä. Ilman niitä huomioon laitteiston toiminnallisuus ei voi kasvaa. Mutta nämä eivät ole saavuttaneet järjestelmätason huolenaiheita. Ennen kuin kaikki energiankulutukseen osallistuvat osapuolet istuvat samaan huoneeseen ja suunnittelevat järjestelmän energiatehokkaaksi, emme näe todellisia ratkaisuja ongelmaan.

Asialla on myös toinen puoli. Kaikkien ihmisten, jotka tuottavat heidän käyttämänsä työkalut, on myös päästävä samaan huoneeseen ja kehitettävä virtoja, jotka mahdollistavat kaikkien menestymisen. Vaikka EDA:n ja järjestelmämaailman välillä on tapahtunut jonkin verran edistystä joidenkin lämpöhaasteiden ratkaisemisessa, edistystä on vähemmän arkkitehtonisella tasolla, eikä edistystä ole juurikaan tapahtunut laitteisto- ja ohjelmistomaailman välillä. Toimivuuteen keskittyvät virtuaaliset prototyypit eivät riitä. Ne on laajennettava järjestelmän tehoon ja energiaan, eikä sitä voida tehdä ilman kääntäjien kehittäjien osallistumista. Aluekohtaisessa laskennassa on mahdollisuus, koska nämä ihmiset ovat ottamassa näiden ongelmien seurauksena uuden suunnan laitteistoissa ja heille voi olla tarpeeksi tärkeää edistyä viereisillä aloilla. Mutta kaikki näyttää jäävän pitkäksi aikaa tulevaisuuteen.

Aiheeseen liittyvä lukeminen
Nouseva sähkön hinta siruina
Enemmän tietoa vaatii nopeampaa käsittelyä, mikä johtaa useisiin ongelmiin – jotka eivät kaikki ole ilmeisiä tai edes ratkaistavissa.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• PlatoData.Network Vertical Generatiivinen Ai. Vahvista itseäsi. Pääsy tästä.
• PlatoAiStream. Web3 Intelligence. Tietoa laajennettu. Pääsy tästä.
• PlatoESG. hiili, CleanTech, energia, ympäristö, Aurinko, Jätehuolto. Pääsy tästä.
• PlatonHealth. Biotekniikan ja kliinisten kokeiden älykkyys. Pääsy tästä.
• Lähde: https://semiengineering.com/optimizing-energy-at-the-system-level/