Framväxten av energiavskiljare skapar potentialen för batterilös avkänning och datorutrustning. Sådana enheter fungerar endast intermittent, eftersom energi finns tillgänglig, vilket innebär ett antal utmaningar för programvaruutvecklare. Programmerare står inför ett komplext designutrymme som kräver resonemang om energi, minneskonsistens och framsteg framåt. I detta dokument introduceras Alpaca, en låg-overhead-programmeringsmodell för intermittent databehandling på energiskördande apparater. Alpaca-program består av en sekvens av användardefinierade uppgifter. Den Alpaca runtime bevarar utförandet framsteg på granularity av en uppgift. Den viktigaste insikten i Alpaca är privatiseringen av data som delas mellan uppgifter. Delade värden skrivna i en uppgift detekteras med hjälp av idempotence analys och kopieras till en buffert privat till uppgiften. I slutet av uppgiften är modifierade värden från den privata bufferten atomiskt engagerade i huvudminnet, vilket säkerställer att data förblir konsekventa trots strömavbrott. Alpaca tillhandahåller ett välbekant programmeringsgränssnitt, en mycket effektiv körtidsmodell, och sätter få restriktioner på en målenhets hårdvara. Vi implementerade en prototyp av Alpaca som en förlängning till C med ett LLVM kompilatorpass. Vi utvärderade Alpaca, och direkt jämfört med två system från tidigare arbete. Alpaca eliminerar kontrollpunkter, vilket förbättrar prestandan upp till 15x, och Alpaca undviker statisk multi-versioning, vilket förbättrar minnesförbrukningen med upp till 5,5x. och konsumerar snabbt den lagrade energin. Energiutarmas snabbare under drift (t.ex. millisekunder) än den ackumuleras under laddning (t.ex. sekunder). När energin är uttömd och apparaten avaktiverar, flyktigt tillstånd, t.ex. Register och stackminne går förlorat, medan icke-flyktigt tillstånd, t.ex. ferroelektriskt minne (FRAM), kvarstår. Laddnings-/urladdningscykeln för en energislukande enhet tvingar programvara att köra enligt den intermittenta utförandemodellen Lucia och Ransford 2015; Van Der Woude och Hicks 2016 ]. Ett intermittent utförande omfattar perioder av aktivitet som perforeras av strömavbrott. Den viktigaste skillnaden mellan intermittent utförande och kontinuerlig körning är att en beräkning i den intermittenta modellen endast delvis kan utföras innan effekten går sönder och måste återupptas efter att effekten har återställts. Korrekt och effektivt intermittent utförande kräver ett system för att uppfylla en uppsättning krav på korrekthet (C1-3) och prestationsmål (G1-3). C1: Ett program måste bevara framsteg trots att förlora volatila tillstånd på strömavbrott. C2: Ett program måste ha en konsekvent bild av sitt tillstånd över flyktigt och icke-flyktigt minne. C3: Ett program måste respektera höga atomicitetsbegränsningar (t.ex. provtagningsrelaterade sensorer tillsammans). G1: Applikationer bör sätta så få restriktioner på processorn och minneshårdvaruarkitekturen som möjligt. G2: Ansökningarna bör vara lättåtkomliga när de utformas för att kunna använda energilagringskapaciteten på ett effektivt sätt. G3: Applikationer bör minimera drifttid overhead, minnesavtryck, återställa overhead, och åter implementerad kod. På senare tid har arbetet gjort framsteg mot flera av dessa mål. Flyktiga vägkontroller [Balsamo et al. Denna förordning träder i kraft den tjugonde dagen efter det att den har offentliggjorts i Europeiska unionens officiella tidning. , 2015 Mirhoseini et al. År 2013; Ransford m.fl. 2011a,b] säkerställa framsteg (C1). System för statisk multiversion [Colin and Lucia 2016] och dynamisk versionering [Lucia och Ransford 2015; Van Der Woude och Hicks 2016] skapar selektivt kopior av modifierade data för att hålla instabila och icke-flyktiga tillstånd konsekvent (C2). Uppgiftsbaserade system [Colin och Lucia 2016; Lucia och Ransford 2015] gör det möjligt för programmerare att uttrycka Atomicitetsbegränsningar på applikationsnivå (C3) och matcha energikostnaden för en uppgift med enhetens energikapacitet (G2). Tidigare tillvägagångssätt måste dock nödvändigtvis kompromissa med vissa av målen. Kontroll med endast flyktig kontroll säkerställer inte att flyktiga och icke-flyktiga data förblir konsekventa (C2). Statiska och dynamiska versionssystem har höga omkostnader i tid [Lucia och Ransford 2015] eller utrymme [Colin och Lucia 2016] (G3). Idempotent sammanställning [Van Der Woude och Hicks 2016] minskar overhead (G3), men gäller endast enheter där allt minne är icke-flyktigt, inte till off-the-shelf mikrokontroller med hybrid flyktig och icke-flyktig minne på marknaden idag (G1). Den idempotenta sammanställningens helautomatiska karaktär berövar programmeraren kontrollen över energikostnaderna för de uppgifter som blir följden (G2) och gör det svårare att tvinga uppgifter att respektera höga atomiska begränsningar (C3). Detta papper utvecklar Alpaca 1, en programmering och utförande modell som tillåter programvara att köra intermittent. Precis som toppmoderna system bevarar Alpaca framsteg trots strömavbrott (C1) och säkerställer minneskonsistens (C2). Alpaca använder en statisk aktivitetsmodell utan kontrollpunkter och explicit restaurering av flyktigt tillstånd. Alpacas inställning till att behålla minneskonsistens trots strömavbrott liknar begreppsmässigt transaktionsminnet (TM) [Shavit och Touitou 1995] med redo-loggning. En Alpaca uppgift manipulerar privatiserade kopior av data och förbinder uppdateringar till dessa data atomärt när uppgiften avslutas. Genom att kasta privatiserade kopior, Alpaca kan starta om en uppgift med försumbar kostnad, på samma sätt som Chain [Colin och Lucia 2016], men utan minnet overhead av statisk multi-versioning (G3). Alpaca dynamiskt versioner icke-flyktiga data, som DINO [Lucia och Ransford 2015], men utan kontroll av flyktigt tillstånd (G3). Alpaca selektivt versioner icke-flyktiga minnesplatser identifieras av en kompilator-baserad idempotence analys, som 1 Alpaca: Adaptive Lightweight Programmering Abstraction for Consistency and Atomicity Alpaca: Intermittent Execution without Checkpoints Ratchet [Van Der Woude and Hicks 2016], men utan flyktiga tillstånd kontrollpunkter (G3) och utan att begränsas till hårdvara med endast icke-flyktiga minne (G1). Alpacas konstruktionsskillnader, i förhållande till toppmoderna system, resulterar i prestandavinster på i genomsnitt 4,2x (upp 15x i vissa fall) och ett icke-flyktigt minnesavtryck mindre med 1,3-5,5x. I motsats till en helt automatiserad kompilator-endast tillvägagångssätt [Van Der Woude och Hicks 2016] och just-in-time dynamisk checkpointing tillvägagångssätt [Balsamo et al. Denna förordning träder i kraft den tjugonde dagen efter det att den har offentliggjorts i Europeiska unionens officiella tidning. , 2015 Mirhoseini et al. År 2013; Ransford m.fl. 2011a,b] gör Alpacas uppgiftsmodell det möjligt för programmeraren att kontrollera var uppgifterna börjar och slutar. Med denna kontroll kan Alpaca-tillämpningar uppfylla kraven på atomicitet på tillämpningsnivå (C3) och använda uppgifter som är dimensionerade till enhetens energikapacitet (G2). Avsnitt 2 ger bakgrund om intermittenta datorer. I avsnitten 3 och 4 beskrivs programmodellen Alpaca och dess genomförande. I avsnitt 5 diskuteras viktiga designbeslut. Avsnitt 6 och 7 beskriver våra riktmärken och utvärdering. Vi avslutar med en diskussion om relaterat (avsnitt 8) och framtida (avsnitt 9) arbete.
Alpaca REF bevarar verkställandet av en uppgift genom att privatisera de delade uppgifterna mellan uppgifter som upptäcks med hjälp av idempotenceanalys.
Alpaca: intermittent execution without checkpoints
{'venue': 'PACMPL', 'journal': None, 'mag_field_of_study': ['Computer Science', 'Engineering']}