Under de senaste åren har de traditionella sätten att hålla ökningen av hårdvaruprestanda i den takt som förutses i Moores lag försvunnit. När uni-cores var normen, frikopplades hårdvarudesign från programvarustacken tack vare en väldefinierad instruktionsuppsättning arkitektur (ISA). Detta enkla gränssnitt gjorde det möjligt att utveckla applikationer utan att oroa sig för mycket för den underliggande hårdvaran, medan maskinvarudesigners kunde aggressivt utnyttja undervisningsnivå parallellism (ILP) i superskalar processorer. Med irruption av multi-cores och parallella program, detta enkla gränssnitt började läcka. Som en följd av detta flyttades rollen som frikoppling igen program från hårdvaran till runtime-systemet. Effektivt använda den underliggande hårdvaran från denna körning utan att utsätta sin komplexitet för ansökan har varit målet för mycket aktiv och produktiv forskning under de senaste åren. Nuvarande multikärnor är konstruerade som enkla symmetriska multiprocessorer (SMP) på ett chip. Vi anser dock att detta inte är tillräckligt för att övervinna alla de problem som flera kärnor redan har att ta itu med. Det är vår ståndpunkt att runtime måste driva utformningen av framtida multi-cores för att övervinna de begränsningar i kraft, minne, programmerbarhet och motståndskraft som multi-cores har. I det här dokumentet introducerar vi en första strategi mot en Runtime-Aware Architecture (RAA), en massivt parallell arkitektur utformad ur runtimes perspektiv. Nyckelord: Parallella arkitekturer, runtime system, hårdvara-programvara co-design. När uniprocessorer var normen utnyttjades instruktionsnivåparallellism (ILP) och datanivåparallellism (DLP) i stor utsträckning för att öka antalet instruktioner som utfördes per cykel. De viktigaste hårdvarudesigner som användes för att utnyttja ILP var superskalar och mycket lång instruktion Word (VLIW) processorer. VLIW metoden kräver att statiskt bestämma beroenden mellan instruktioner och schemalägga dem. Eftersom det i allmänhet inte är möjligt att få optimala schemaläggningar vid sammanställningstidpunkten utnyttjar dock VLIW inte fullt ut den potentiella ILP som många arbetsbelastningar har. Superscalar design försöker övervinna de ökande minneslatenser, den så kallade Memory Wall [42], genom att använda Out of Order (OoO) och spekulativa avrättningar [18]. Dessutom, tekniker som prefetching, för att börja hämta data från minnet i förväg, djupa minneshierarkier, för att utnyttja den plats som många program har, och stora omordning buffertar, för att öka antalet spekulativa instruktioner som exponeras för hårdvaran, har också använts för att förbättra superskalar processorer prestanda. DLP uttrycks vanligtvis explicit på programvaruskiktet och bestod i en parallell operation på flera data som utförs av flera oberoende instruktioner, eller av flera oberoende trådar. I uniprocessorer, instruktion Set arkitektur (ISA) var ansvarig för att frikoppla ansökan, skriven i en hög nivå programmeringsspråk, och hårdvaran, som vi kan se i den vänstra sidan av Figur 1. I detta sammanhang tillämpades förbättringarna av arkitekturen på rörledningsnivå utan att ISA ändrades. För några år sedan försvann de traditionella sätten att fortsätta att öka hårdvaruprestandan i den takt som förutses i Moores lag, dessutom till minnesväggen. Processorn klockfrekvens stagnerade eftersom, när den ökade över en tröskel, effekten per enhet av area (effekttäthet) inte kunde avledas. Det problemet kallades Power Wall [27]. En studie 1 Barcelona Supercomputing Center, Carrer Jordi Girona 29, 08034 Barcelona, Spanien 2 Universitat Politecnica de Catalunya, Carrer Jordi Girona 1-3, 08034 Barcelona, Spanien DOI: 10.14529/jsfi140102 Supercomputing Frontiers and Innovations Figur 1. Vänster: Avkoppling av hårdvaran och programvarulagren i enprocessorer. Höger: Körtiden driver hårdvarudesignen i multiprocessorer. Vi kallar denna strategi en Runtime-Aware Architecture (RAA) design. enligt den internationella teknikfärdplanen för halvledare förutser en årlig frekvensökning på 5 % för de kommande 15 åren [19]. Det innebär att vi lämnas ensamma med parallellism för att ytterligare öka prestandan. För att övervinna stagnationen av processorn klockfrekvens, började leverantörer att släppa multi-core enheter över ett decennium sedan. De kan potentiellt ge önskade resultatvinster genom att utnyttja Task Level Parallelism (TLP). Men multi-core design, snarare än att fixa de problem som är förknippade med minne och makt väggar, förvärra dem. Förhållandet cachelagring / operation stagnerar eller minskar i flerkärnig design samt minnesbandbredden per operation gör det, vilket gör det mycket svårt att fullt ut utnyttja det dataflöde som flerkärnig design har. En annan viktig fråga är energiförbrukningen, eftersom om den fortsätter att växa med samma takt som i dag, kommer vissa stora tekniska utmaningar som att utforma exaskala superdatorer eller utveckla petaflop mobiler att bli chimeras. Denna uppsättning utmaningar relaterade till strömförbrukningsfrågor utgör en ny kraftmur. Dessutom kan flerkärniga system ha en heterogen uppsättning processorer med en annan ISA, ansluten genom flera lager av delade resurser med variabel åtkomst latens och distribuerade minnesregioner. Att hantera datarörelser inom denna djupa och heterogena minneshierarki samtidigt som man hanterar icke-enformiga minnesaccesseffekter (NUMA) på rätt sätt och respekterar en strikt maktbudget i datarörelser kommer att bli en stor utmaning i framtida multikärnmaskiner. Alla dessa problem när det gäller programmerbarhet och datahantering över hela minneshierarkin brukar kallas programmerbarhetsväggen [9]. Flerkärniga arkitekturer kan teoretiskt uppnå betydande prestanda med låga spänningar och frekvenser. Eftersom spänningen matar skalor i förhållande till transistor tröskelspänningen, ökar känsligheten för kretsförseningar för transistorparametervariationer anmärkningsvärt, vilket innebär att processorfel kommer att bli vanligare i framtida konstruktioner. Det faktum att det totala antalet kärnor i framtida konstruktioner kommer att öka i flera storleksordningar gör dessutom problemet med felprevalensen mer dramatiskt. Förutom de aktuella utmaningarna inom parallellism, minne och makthantering rör vi oss mot en tillförlitlighetsmur [43]. Med irruption av multi-cores och parallella program, det enkla gränssnittet mellan hårdvaran och programmet började läcka. Som en följd av detta flyttades rollen som frikoppling igen program från hårdvaran till runtime-systemet. Detta runtime lager är också ansvarig för att effektivt använda den underliggande hårdvaran utan att utsätta sin komplexitet för programmet. I själva verket blir samarbetet mellan den heterogena parallella hårdvaran och runtime-lagret det enda sättet att hålla den programmerbarhet som vi förutser inom acceptabla nivåer samtidigt som vi hanterar minnes-, kraft- och motståndskraftsväggarna. Nuvarande multikärnor är konstruerade som enkla symmetriska multiprocessorer (SMP) på ett chip. Vi anser dock att detta inte är tillräckligt för att övervinna alla de problem som flera kärnor redan har att ta itu med. För att på ett korrekt sätt dra nytta av deras potential krävs ett förstärkt samarbete med hårdvaruprogramvara. Det är vår ståndpunkt att runtime måste driva utformningen av framtida multi-cores för att övervinna utmaningarna med de ovan nämnda väggarna. Vi ser fram emot en Runtime-Aware Architecture (RAA), en helhetssyn där den parallella arkitekturen delvis implementeras som ett runtime-hanteringslager för programvara, och resten i hårdvara. I denna arkitektur styrs TLP och DLP av körtiden och är öppna för programmeraren. Tanken är att ha en uppgiftsbaserad representation av parallella program och hantera uppgifterna på samma sätt som superscalar processorer hantera ILP, eftersom uppgifter har databeroenden mellan dem och en databeroende graf kan byggas på runtime eller statiskt. Som sådan skulle körtiden driva utformningen av nya arkitekturkomponenter för att stödja sin verksamhet. På höger sida av figur 1 kan vi se en representation av denna idé, där applikationen genomförs med hjälp av en högnivåprogrammeringsmodell som frikopplar den från körtiden och hårdvaran. Runtime inte bara använder hårdvaran effektivt, men också driver sin design. Som sådan, specifika hårdvarukomponenter som stöder runtime aktiviteter är en viktig punkt i RAA-metoden. Under erfarenheten av den nuvarande slutåldern och utrustad med en mogen vision om vad en produktiv framtid kan vara, många bra idéer som försvann under RISC klockfrekvens boom på 80- och 90-talen kan omformas och tillämpas med oförutsedda skalor eller omfattning, vilket resulterar i en innovativ vision om hur man ska hantera den aktuella broderingen där hårdvaruteknik har tagit oss. Vår inställning till parallella arkitekturer erbjuder en enda lösning som kan lindra de flesta av de problem vi stöter på i de nuvarande strategierna: hantering av parallellism, minnesväggen, kraftväggen, programmerbarhetsväggen och den kommande tillförlitlighetsväggen i ett brett spektrum av applikationsdomäner från mobila upp till superdatorer. Sammantaget är denna nya inställning till framtida parallella arkitekturer ett sätt att säkerställa fortsatta prestandaförbättringar, så att vi kan ta oss ur de tekniska svårigheter som datorer har förvandlats till, än en gång på grund av Moores lag. I avsnitt 1 beskriver vi mer i detalj hur en uppgiftsbaserad körtid hanterar arbetsbelastningen och hur vissa idéer som utnyttjas av superskalarprocessorer kan utnyttjas av körtiden. I Avsnitt 2 förklarar vi hur superscalar runtime har använts för att effektivt utnyttja multi-cores. I avsnitt 3 förklaras begreppet runtime-aware arkitekturer i detalj. Avsnitt 4 berättar om några relaterade arbeten. Slutligen kommenterar vi i avsnitt 5 slutsatserna från detta arbete. Vi planerar att använda ett runtime-system som använder en aktivitetsbaserad abstraktion där programmeraren specificerar vilka indata- och utdataargument för de olika uppgifterna, som går till Supercomputing Frontiers och Innovations Out-of-Order Execution Pipelined Execution Speculative Executive Execution hanteras på samma sätt som superscalar processorer hanterar instruktioner. Denna dataflödesinformation gör det möjligt att dynamiskt bygga och underhålla en Task-Dependency Graph (TDG), som utgör grunden för ett tätt samarbete med hårdvaran för att driva schemaläggningsbeslut och för att upptäcka möjligheter att hantera datarörelser i arkitekturen. Mer exakt, som vi kan se i tabell 1, runtime lager föreställa sig de olika uppgifterna i en parallell tillämpning som om de var instruktioner i en superskalar processor. På samma sätt kan hämta, avkoda och funktionella enheter i en pipeline ses som kärnan i den heterogena mångkärniga hårdvaran, medan register kan förutses som lokala och huvudsakliga minnen av parallella arkitekturer. Som sådan, begrepp som Out-of-Order, piped, och spekulativt utförande visas naturligt på körtidsnivå i termer av uppgiftsbaserade parallella tillämpningar. Aktivitetsberoende grafen tillåter körtiden att utföra oberoende uppgifter Out-of-Order, som instruktioner i traditionella superskalar arkitekturer. Djupa pipelines, som typiskt är en komponent i superskalar processorer, visas också på många kärnnivå i termer av sekvenser av uppgifter som kan överlappas för att uppnå mer prestanda. I framtiden många kärnsystem med hundratals kärnor, tomgångskärnor kan användas för att spekulativt utföra uppgifter för att påskynda ansökan framsteg och prefetch data i chipet. Eftersom vårt tillvägagångssätt består i att bearbeta uppgifter på samma sätt som superskalararkitekturer hanterar dynamiska instruktioner, kan många tillvägagångssätt som vanligtvis har tillämpats på undervisningspipelinenivå inspirera till optimeringar av körtiden och nya maskinvarudesigner. Ännu mer, eftersom uppgiftsberoende grafen är mycket mer komplex och har mycket mer parallellism att utnyttja än instruktioner beroenden, betydande optimeringar i termer av prestanda, kraft eller motståndskraft kan uppnås genom att exponera uppgift-beroende grafen för den tillgängliga hårdvaran och sedan balansera arbetsbelastningen i enlighet därmed. Dessutom förväntas nya arkitektoniska komponenter för att stödja körtiden spela en viktig roll. I synnerhet planerar vi att genomföra vår strategi i toppen av OpenMP Superscalar (Omps) [11] runtime lager, som representerar den senaste tekniken i uppgiftsbaserade runtime lager. Omps är en inbäddning av StarS [29] i OpenMP. Uppgiften abstraktion och hantering av parallellism från runtime systemet utgjorde ett stort genombrott i parallellprogrammering. Exponera dataflödet över uppgifter, gör det möjligt för runtime-systemet att effektivt driva den parallella hårdvaran på samma sätt som superscalar-processorerna hanterar de funktionella enheterna. Detta öppnar dörren för en stor mängd komplexa optimeringar som runtime-systemet och den underliggande arkitekturen kan prestera på ett transparent sätt, vilket ger varaktiga prestandaförbättringar över nya maskinvarugenerationer. För resten av avsnittet kommenterar vi flera tekniker som körtiden kan gälla för att övervinna var och en av de ovan nämnda väggarna. Runtime schemaläggaren kan upptäcka och utnyttja tidsdata återanvändning genom att ombeställa uppgifter som återanvänder samma indata, eller som använder resultaten av de tidigare uppgifterna. Dessutom kan det fatta beslut om datadistribution, allokera data i närheten av var uppgiften kommer att utföras, förhämtning av data i förväg, och skapa explicita kopior för ökad lokalitet om samma data krävs på flera platser samtidigt. Bellens m.fl. [3] visa den potentiella nyttan av dessa tekniker i Cell Broadband Engine mikroarkitektur, som har åtta acceleratorer, var och en med ett 256KB lokalt minne, och en PowerPC-processor. Runtime tar hand om uppgiften schemaläggning och datahantering mellan de olika processorer i denna heterogena arkitektur genom att använda en lokal-medveten mekanism för att minska overhead av dataöverföringar från PowerPC till acceleratorer. Minimering av datarörelser i minneshierarkin är verkligen en nyckelteknik för att hantera minnesväggen, eftersom det minskar antalet åtkomster till huvudminnet och utnyttjar synergier mellan minnessystemets olika komponenter. Vissa initiala resultat har redan erhållits i CPU+GPU-system [7]. Runtime systemet flyttar data som behövs mellan de olika noderna och GPUs minimerar effekten av kommunikation genom att använda affinitet schemaläggning, caching, och genom överlappande kommunikation med den beräkningsuppgift. När en GPU-kärna startas, begär GPU-trådarna en ny uppgift till schemaläggaren. Därefter initieras överföringen av data som kan behövas av den förbeställda uppgiften. På så sätt kommer uppgifterna redan att vara tillgängliga när denna uppgift kan utföras. Denna prefetch är mer effektiv när den kombineras med överlappande beräkningar och dataöverföringar. För att göra det möjligt för processorer att utnyttja mer ILP, har registerrenaming utnyttjats i superskalar arkitekturer. Sådana metoder gör det möjligt att ha mer fysiska register än logiska register, undvika seriellisering sanktioner på grund av register återanvändning. De kräver att man håller reda på beroenden mellan instruktioners operander för att avgöra om ett nytt namnbytesregister kan tilldelas ett arkitekturregister. Renaming kan bidra till att ta bort anti-beroende mellan instruktioner, som också kan tillämpas på uppgifter [4]. Renaming kan tillämpas vid direktioneringstid, eller skjutas upp till strax före utförandet av uppgiften, på samma sätt som virtuella register [15], som kan fördröja fördelningen av fysiska register tills ett sent skede i rörledningen, i stället för att göra det i avkodar skedet. Eftersom diagrammet för uppgiftsberoende kan genereras i förväg är det möjligt att fördröja minnestilldelningen till uppgifter tills de börjar köras. Denna virtuella resursallokering gör det möjligt för andra uppgifter i den kritiska vägen att dra nytta av detta extra minne. Power Wall Potentialen att utnyttja den kritiska vägen har redan utvärderats i MPI-program [6]. Genom att använda kunskapen om den kritiska vägen och kombinera den med enkla profilbaserade tekniker, en uppsättning kompakta prestandaindikatorer som beskriver viktiga prestandarelaterade frågor, såsom belastningsobalans, resursförbrukning eller dynamisk arbetsbelastning, kan en effektiv schemaläggning härledas. Dessa prestandaindikatorer kan användas av körtidssystemet för att effektivt hantera belastning, handel prestanda för kraft eller vice versa, och totalt sett optimera och anpassa beslut om körtid till användarnas behov. Förbättringar upp till 18% i Runtime-Aware Architectures: A First Approach Supercomputing Frontiers and Innovations exekveringstid och 21% i energieffektivitet har uppnåtts genom att använda dynamiska prestandamått för att justera runtime beslut [37]. Utnyttja uppgift specialisering kan ge betydande förbättringar eftersom olika uppgifter kan schemaläggas och mappas till olika hårdvarukomponenter för att leverera maximal prestanda medan du spenderar låg effekt. Till exempel, genom att använda minnesspecifik prestandainformation (dvs. cachekapacitet och minne bandbredd krävs), kan de olika uppgifterna mappas till hårdvara komponenter med de nödvändiga minnesresurserna eller, alternativt, om en uppgift redan var igång, det skulle vara möjligt att stänga av icke-krävda bitar av minnet. Detta skulle innebära mycket viktiga förbättringar när det gäller energiförbrukningen. Dessutom kan programmeraren eller kompilatorn för samma uppgift tillhandahålla olika versioner av kod som riktar sig mot flera acceleratorer och, enligt hårdvarutillståndet, körtiden kan välja vilken version av koden som ska användas [30]. Som sådan, om maskinen har vissa kärnor med stöd för vektor instruktioner, kan körtiden minska strömförbrukningen schemalägga lämpliga uppgifter för dem att utnyttja sin minskade hämta och avkoda strömförbrukningen. Tillförlitlighet Vägg Ett brett utbud av tekniker kan tillämpas på körtidsnivå för att öka applikationernas motståndskraft och hantera pålitlighetsväggen. Om vi antar att uppgifterna är idempotent, kan vi ta kontroll-punkter av uppgifternas indata och åter utföra dem om något fel äger rum [38]. För att minska minnet overhead, kan vi använda en smart kopieringsmekanism som tar bara en kontrollpunkt per inmatning, även om det används av flera uppgifter. Alternativt är det också möjligt att utöka programmeringsmodellen för att göra det möjligt för användaren att ange koder som är särskilt känsliga ur motståndskraftssynpunkt genom att använda särskilda pragmaanmärkningar. Detta skulle ge till körningen informationen om vilka uppgifter som bör kartläggas i mer motståndskraftiga hårdvarukomponenter. En annan möjlig förbättring som uppgiftsbaserade körtider tillåter är att tolerera latency som recomputation tekniker inducerar genom överlappande beräkning med återvinningstekniker och låt utförandet fortskrider om den felaktiga uppgiften inte är i den kritiska vägen. Det är ett utmärkt ramverk för att distribuera algoritmiska återvinningar eftersom dess kostnad kan tolereras genom att överlappa dem med vanliga körtidsuppgifter. Körtiden kan hantera databeroenden som gör det möjligt för programmeraren att leverera en enkel kod där bara in- och utgångsparametrarna för de olika uppgifterna specificeras, vilket i synnerhet förenklar arbetet med att effektivt programmera heterogena många huvudarkitekturer. Som sådan används aktivitetsberoendekurvan av körtiden för att exponera den parallella arbetsbelastningen för den tillgängliga hårdvaran på ett transparent sätt från programmerarens synvinkel, i den meningen att programmets källkod inte innehåller information om hur arbetsbelastningen ska hanteras förutom att ange in-/utmatningsparametrarna. Som sådan kan de programmeringssvårigheter som observerats i heterogena mångkärniga arkitekturer som Cellprocessorn [41] undvikas genom att man betraktar körtidshanteringen som en del av den hårdvara som effektivt hanterar lasten utan att problemet uttryckligen behöver exponeras för programmerarna. Som en följd av detta tar runtime hand om att balansera belastningen mellan olika kärnor och kan tilldela fler uppgifter till snabbare kärnor. Samma runtime-lager kan enkelt anpassas till program med flera implementationer av samma aktivitetstyp (dvs. justerat för olika acceleratorer eller kärnor) och bestämma i vilken exekveringsenhet uppgiften ska köras. En uppgiftsbaserad metod kan potentiellt minska de synkroniseringskostnader som delade minnesstrategier normalt har och därmed uppnå betydande prestandaförbättringar när de hanterar mycket parallella arbetsbelastningar på många kärnor marker. Eftersom de gör det möjligt för programmeraren att ange programdelar som kallas uppgifter, som kan utföras samtidigt, görs kartläggningen av uppgifter till trådar dynamiskt genom en körtidsmiljö utan något specifikt programmeraransvar på det sätt som synkroniseringskostnaderna minskas. Vår visionerade Runtime-Aware Architecture (RAA) utgör ett nytt paradigm av parallella datorsystem där runtime management lager driver hårdvara design, och de båda samarbetar för att utnyttja en aldrig tidigare skådad grad av parallellism on-chip och utnyttja information om databeroenden. I detta avsnitt beskriver vi i detalj de olika aspekterna av sådan hårdvara-programvara samarbete och vi diskuterar några nya möjligheter som det medför. Vi exponerar flera aspekter av RAA-metoden genom att beskriva flera tekniker för att hantera minne, kraft, motståndskraft och programmerbarhet väggar och förklara hur hårdvaru-samarbete kan utnyttja dem. Minnesvägg Ökande data återanvändning i superskalar arkitekturer var avgörande för att minska effekten av minnesväggen. I RAA:s finns det en stor marginal för prestanda- och energieffektivitetsförbättringar i utvecklingen av schemaläggningsstrategier som utnyttjar denna kunskap om framtiden, kodad i uppgiftsberoende grafen. RAA: s erbjuda möjligheten att utöka dessa idéer med specifik hårdvara stöd som automatiskt hanterar dessa dataöverföringar med hjälp av runtime systemet genom att förlita sig på programvara samstämmighet eller på specifikt arkitektoniskt stöd för att sprida uppdateringar över flera kopior av data. Prefetching spelade en oerhört viktig roll i kampen mot minnesväggen i superskalar arkitekturer. I RAA: s kan vi kombinera kapaciteten hos runtime schemaläggaren för att utnyttja information om framtida dataöverföringar, med rätt typ av hårdvara stöd för att optimera sådana överföringar. Det nödvändiga hårdvarustödet är asynkrona datarörelser, som gör det möjligt för schemaläggaren att överlappa de dataöverföringar som krävs för framtida uppgifter med utförandet av den aktuella uppgiften, vilket minskar bandbreddskraven och tolererar minneslatenser eftersom överföringen är utanför den kritiska vägen [25]. Konstruktionskraven för detta nya minnessystem skiljer sig avsevärt från dagens konstruktioner där minnesöverföringar alltid befinner sig i den kritiska vägen. Eftersom körtiden systemet kan avgöra i förväg vilka uppgifter som kommer att utföras i en viss kärna efter den aktuella verkställande uppgiften slutförs, kan det också bestämma de data som krävs av den kommande uppgiften och förladda dessa data till önskad nivå i cachehierarkin med hjälp av lås- och spolningsmekanismer som utvecklats med detta mål [14, 28]. Denna teknik har en hel del potential, men om tillämpas för aggressivt eller för tidigt, kan vräka aktiva data av den aktuella verkställande uppgiften, negativt påverkar prestandan av ansökan. Som ett alternativ kan särskilda buffertar läggas till arkitekturen för att lagra indata från framtida uppgifter utan att påverka innehållet i cachehierarkin. Dessutom kan uppgifter från tillverkare och konsumenter på ett effektivt sätt vidarebefordras med lämpligt hårdvarustöd [23]. Minimera datarörelser på chip och off-chip är mycket viktigt när det gäller slutprestanda och strömförbrukning. Att utnyttja lokaliteten genom återanvändning eller förhämtning kommer inte att vara tillräckligt i framtida mångkärniga system. Förenklade koherensprotokoll som styrs av körtidens system kan användas för att minska koherenstrafiken [24]. Ett intressant komplement består av uppgraderade rörelseprimära som utför användardefinierade transformationer på datan när den överförs. In-minne funktionella enheter för heltal, flyttal eller vektor operationer har varit Supercomputing Frontiers och Innovationer föreslås i det förflutna, men dessa omvandlingar kan också göras i nätverket routrar. Dessutom, mer avancerade Network-on-Chip (NoC) topologier som kan dynamiskt anpassa datarörelser beroende på innehållet i nätverket kan bidra till att minska NoC:s tviste- och kommunikationslatenser. I allmänhet, kritisk-medveten kommunikation kommer att vara avgörande i vår föreställande RAA. Vi kan också föreställa oss strategier som tilldelar mer eller snabbare resurser till uppgifter som befinner sig i den kritiska vägen (eller sannolikt kommer att vara) för den parallella tillämpningen. I ett mångkärnigt system är schemaläggning av kritiska uppgifter till snabbare kärnor och samtidigt minimering av resursinnehåll och datarörelse av största vikt och kräver ett nära samarbete mellan arkitekturen och runtime-systemet. Eftersom hybrida NoC:er och minnen kommer att bli verklighet i sådana system, är utvecklingen av lämpliga prioriteringsmekanismer för kommunikation och minnesåtkomst av kritiska uppgifter en nyckelpunkt för att minska den totala verkställighetstiden för den parallella applikationen. Power Wall Den kritiska vägen är en av de viktigaste dynamiska egenskaperna hos ett parallellt program. Eftersom det är den globala genomförandevägen för uppgifter som tvingar till att vänta på andra uppgifter utan att själv fördröjas, är de händelser som inte ingår på den upp till en viss utsträckning latenstoleranta, eftersom de kan ta mer tid att slutföra utan att skada utförandet av hela ansökan. Det öppnar ett brett spektrum av potentiella förbättringar när det gäller strömförbrukning eller prestanda: Om en given minnesåtkomst inte är i den kritiska vägen, kan den utföras i en lång-latens och därmed låg effekt region i minnet. På samma sätt kan uppgifter som inte är i den kritiska vägen kartläggas till långsammare och därmed låg effekt hårdvarukomponenter i det mångakärniga systemet. Alternativt, om en viss uppgift är i den kritiska vägen, kan det kartläggas till snabbare hårdvarukomponenter eftersom dess tidiga slutförande kan avsevärt minska väntetiden för andra uppgifter och därmed minska den totala energiförbrukningen. I superscalar processorer, specialiserade funktionella enheter kan förbättra prestanda och uppnå låga strömförbrukningshastigheter för olika faser av program utförande. Heterogena konstruktioner kan påskynda många tillämpningar som kombinerar beräkningsintensiva och kontrollintensiva faser av beräkning, som helst bör hanteras av olika bearbetningselement. Dessa koder inkluderar storskaliga vetenskapliga beräkningar, komplexa simuleringar av fysiska fenomen, komplexa visualiseringar eller finansmarknadernas förutsägelser. Medan system med heterogena funktionella enheter avsevärt kan förbättra prestanda och strömförbrukning, de kräver att korrekt dela upp programmets kod över alla tillgängliga funktionella enheter eller att effektivt hantera datarörelser mellan funktionella enheter. Således kan runtime systemet bli en utmärkt hantering lager för att effektivt använda hårdvara med heterogena kärnor och acceleratorer utan att göra programmerbarheten svårare. Eftersom diagrammet över uppgiftsberoende kan skapas före uppgifternas utförande kan hanteringen av heterogena funktionella enheter planeras på ett korrekt sätt. Dessutom kan viss historisk information om de uppgifter som redan har utförts i form av prestanda eller resursanvändning behållas av körtiden. Genom att kombinera dessa historiska data med diagram över uppgiftsberoende kan effektiva planeringsbeslut fattas av körtiden. Tillförlitlighet Vägg Minska felutbredning är avgörande för att öka applikationernas motståndskraft och hantera pålitlighetsväggen. Eftersom mjuka fel som inträffar under en aktivitetsutförande kommer att påverka dess utgångar och alla uppgifter som använder dessa som inmatningsparametrar, erbjuder RAA viktiga möjligheter eftersom informationen i aktivitetsberoendekurvan kan användas som en proxy för uppgifternas känslighet när det gäller felutbredning. Som sådan kan vi bestämma de mest känsliga delarna av uppgiftsberoende grafen och utföra motståndskraftsförbättringar på dem. Dessa en- hancements kan variera från enkla tillvägagångssätt såsom uppgift replikation till sofistikerade algoritmiska kontroller. I vilket fall som helst bör motståndskraftsteknikerna kunna kontrollera fel och korrigera så många som möjligt. Hårdvaran kan stödja dessa motståndskraftsförbättringar antingen genom att möjliggöra snabba och effektiva omräkningar, genom att använda data som redan finns i cache, genom att stödja snabba datarörelser, eller genom att ha några dedikerade kärnor uteslutande inriktade på att köra algoritmiska kontroller för att upptäcka och korrigera datakorruptioner. Felkorrigering av koder (ECC) [35] är en välkänd teknik baserad på kodning av vissa data på ett redundant sätt speciellt utformad för att upptäcka eventuell korruption i de ursprungliga uppgifterna. De implementeras vanligtvis i minnessystem för att upptäcka och korrigera datakorruptioner. ECC kan även användas för att mäta felfrekvensen som en viss hårdvarukomponent experiment, som gör det möjligt att leverera maskiner med en viss motståndskraft garanti. RAA-metoden kan också dra nytta av dessa metoder genom att utföra ECC-kontroller av data medan de överförs. Till exempel, om ett visst paket väntar i kön på en omkopplare, kan vissa ECC-baserade kontroller utföras på det för att upptäcka korruption och återställa dataintegritet om möjligt. Sådana ECC-kontroller skulle inte påverka prestandan, eftersom de utförs under transmisioner. Som sådan, minne, on- and off-chip nätverk bör ha stöd för ECC. Programmerbarhet Vägg För nuvarande körtidssystem, granulariteten av uppgifter måste vara grov nog att försumma körtiden overhead. Till följd av detta måste uppgifternas minsta varaktighet vara i storleksordningen tiotals hundra millisekunder. För vissa algoritmer krävs finare detaljrikedomar av uppgifter för att bättre uttrycka algoritmens inneboende parallellism. Av den anledningen har arkitektoniskt stöd för uppgiftsbaserade genomförandeparadigm föreslagits för att påskynda körtiden systemet och tolerera mycket finare uppgifter granulariteter. Att hantera tusentals uppgifter i drift kräver hårdvarumekanismer för att påskynda byggandet av THG [12, 44], och schemaläggning beslut [22, 33]. För att balansera belastningen av ansökan, uppgift stjäla tekniker kan genomföras i hårdvara [22]. I heterogena system är belastningsbalansering och schemaläggning mycket komplex ur programmerarens perspektiv. Att kunna hantera en enorm mängd finkorniga uppgifter tillsammans med hårdvarustöd för lastbalansering och schemaläggning kommer avsevärt att underlätta skrivandet av parallella applikationer för många kärnor. Vår visionerade RAA Architecture Figur 2 och 3 skildrar de olika delarna av vår visionerade runtime-medveten arkitektur. Vi utformar ett massivt parallellt system med flera noder där varje nod har flera uttag, och varje uttag flera kluster av kärnor. Det är vår ståndpunkt att framtida exaskala system kommer att vara heterogena på flera nivåer, med olika typer av exekveringsenheter (stora och små kärnor) och acceleratorer (GPU, vektorprocessorer, nätverk, etc.).), sammankopplingsnät (elektriska, optiska och trådlösa) och minnen (DRAM, icke-flyktigt minne osv.). Dessutom kommer hanteringen av djupa minneshierarkier och sammankopplingsnät på flera nivåer att vara avgörande för att uppnå toppprestanda. Med tanke på hårdvarans heterogenitet, datalokalitet och återanvändning, strömförbrukning och tillförlitlighet i drift är det avgörande för att övervinna de väggar som hotar Moores lag. Berikad information på hårdvarunivå krävs för att köra systemet för att optimera dessa mål. För att minimera omkostnaderna för detta körtidssystem är särskilt hårdvarustöd obligatoriskt [12, 22, 33]. Med hjälp av dessa strukturer kan viktiga aspekter av RAA:s uppbyggnad av GDG, schemaläggning av uppgifter, lastbalansering och dataplacering göras utan att det påverkar programmets prestanda. Dessa strukturer skulle vara den största delen av systemkärnor blockdiagram i figur 2. På samma sätt som IBM Blue Gene/Q-processor [17] ingår en specifik kärna för operativsystemets verksamhet (OS i figur 2 ) i varje kluster av kärnor, medan runtime front-end-aktiviteter sker i en specifik hårdvara (RT). Det är fortfarande en öppen fråga om dessa två kärnor kan kombineras i en enda struktur. Körbara uppgifter sätts in i ett kösystem som liknar Carbon [22], som stöder aktivitetsstöld och schemaläggs till de tillgängliga kärnorna. För att karakterisera de hårdvaruresurser som varje aktivitetstyp kräver, utformas en specifik struktur, betecknad resursinnehåll Core (RCC). Slutligen är en Data Transfer Engine (DTE) ansvarig för datarörelser i kärnklustret. Den DTE utnyttjar data återanvändning, lokalitet, och prefetches uppgifter in i förväg. De generiska klusterkärnorna i figur 2 omfattar exekveringskärnor, acceleratorer, on-chip-nätverk och cachehierarki. Processorkärnor fungerar alltså effektivt som funktionella enheter. I RAA:s föreslår vi att ha en hybridminneshierarki med en L1-datacache och ett lokalt minne (eller scratchpad) per kärna, som visas i figur 2. Det är mycket svårt att hantera en sådan minneshierarki, men om vi gör det på ett tillfredsställande sätt kan vi avsevärt minska koherenstrafiken och få ett mer energieffektivt system. Vi har till exempel visat att med lämpligt kompilatorstöd kan en sådan hybridhierarki utnyttjas för OpenMP-koder [1]. I detta tillvägagångssätt betjänas avancerade åtkomster av det lokala minnet, medan oregelbundna åtkomster betjänas av L1-datacachen. Ett minimalt maskinvarustöd krävs för enhetlighet och konsekvens, men betydande energibesparingar uppnås som ett resultat av detta. I samband med RAA:s verksamhetsbaserade programmeringsmodeller som Omps kan vara till stor hjälp. Till exempel kan aktivitetsindata och utdata automatiskt kartläggas till lokala minnen, medan andra åtkomster skulle betjänas av L1-cachen. DTE i systemkärnorna kan hantera DMA-överföringar för att förge data i tid. Med detta tillvägagångssätt skulle slutligen datarörelserna på grund av koherensprotokollen minskas avsevärt. Den nuvarande Network-on-Chip (NoC) designar som ring- och bussbaserade topologier [39] ger en energi- och genomströmningseffektiv lösning för kommunikation inom små multikärnor. Eftersom dessa traditionella tillvägagångssätt för NoC inte skala för många kärnor, är det nödvändigt att utforska nya och skalbara NoC metoder såsom trådlösa sammanlänkningar, som kan användas i samband med traditionella trådbundna och optiska sammanlänkningar i nya RAA NoC topolo-gies för både 2D och 3D integrerade kretsar [45]. Slutligen utformas heterogena nätverk på chip för att tjäna de olika egenskaperna hos dessa strukturer i hybridminneshierarkin. Cluster kärnor delar en lokal L2 cache, medan en stor sista nivå på chip cache delas mellan olika kluster i uttaget. Lokala minnen i olika kluster kommer att kunna kommunicera via ett specifikt kluster till klusterkommunikationsmotorn (benämns CL2CL Comm i figur 2). Denna motor kunde också hantera kommunikation mellan olika uttag i en nod. Olika uttag i en nod är anslutna med ett höghastighetsnät, medan olika typer av minnen är tillgängliga för uttaget. Att bestämma om man ska fördela minnet i ett vanligt DRAM-minne eller i ett icke-flyktigt minne kommer att vara en viktig aspekt som kommer att bli lättare att avgöra tack vare den berikade information som tillhandahålls av dataflödesrepresentationen av programmet. Vi kan till exempel föreställa oss att de slutliga resultaten av en ansökan bör kartläggas till ihållande minnen. Flera forskargrupper har föreslagit systemarkitekturer med likheter med vår visionerade RAA. Till exempel föreslår SARC-arkitekturen [31] att man ska ha separata kluster av master- och arbetarkärnor med lokala minnen och sammanhängande L2- och L3-cacher. Rigelarkitekturen [21] föreslår att man ska ha kluster av kärnor med L1-instruktionscacher och inkonsekventa L2-cacher (per kluster), tillsammans med en global delad L3-cache. Slutligen bygger Runnemede-arkitekturen [8] också på en dataflödesutförandemodell för att utföra i en datormiljö nära tröskeln, med flera kluster av homogena kärnor och en hierarki av lokala minnen. I denna arkitektur hanteras samstämmigheten mellan kluster fullt ut i programvara. Relaterat arbete Det mest spridda distribuerade minnet API är MPI [16], som i princip består av en uppsättning makron för att uttryckligen indikera datautbyte mellan olika uppgifter. Kommunikation kan vara peka på punkt eller kollektiv och använda synkrona eller asynkrona protokoll, den första är mer robust i den meningen att data inte kan förloras utan betala den typiska synkronisering börda. OpenMP är en implementering av den klassiska delade minne multitrådade gaffeljoin programmeringsmodell [2]. Som standard kör varje tråd sin egen parallelliserade kodsektion självständigt. Parallellism på uppgifts- och datanivå kan uppnås genom arbetsdelningskonstruktioner som används för att dela upp beräkningsbelastningen mellan trådarna. Trådar allokeras till processorer baserade på miljövariabler eller i kod med hjälp av funktioner. Runtime-Aware Architectures: A First Approach Supercomputing Frontiers and Innovations I samband med högpresterande datorer används OpenMP vanligtvis för att hantera parallellism på chip, eftersom delning av datatrådar kan använda minnesresurserna mer effektivt. OpenMP skalas dock inte upp till flera tiotals trådar på grund av synkroniseringskostnader. Följaktligen måste MPI användas för att uppnå godtagbar skalbarhet i måttliga och storskaliga körningar. Typiskt är MPI används för att hantera off-chip kommunikation. Det är intressant att säga att hybrid MPI+OpenMP implementationer på något sätt återspeglar hur minnet är organiserat i parallella kluster. Som sådan har hybrid MPI+OpenMP blivit normen inom området vetenskaplig databehandling. Flera aktivitetsbaserade programmeringsmodeller har utvecklats under de senaste åren: Cilk [5] är ett runtime-system för multitrådade koder. För att till fullo kunna utnyttja Cilk-potentialen måste koderna struktureras för att exponera parallellism och utnyttja lokalitet, vilket lämnar Cilks körtid med ansvar för att schemalägga beräkningen för att optimalt köras på en given plattform. Som sådan, Cilk runtime systemet hanterar saker som lastbalansering, synkronisering och kommunikationsprotokoll. Intel Threading Building Blocks (TBB) [32] är ett C++ mallbibliotek för aktivitetsbaserad parallellism. Det är tänkt att förenkla den parallella programbördan genom att be programmerarna att ange logisk parallellism i stället för trådar och genom att låta runtimebiblioteket kartlägga logisk parallellism på trådar som effektivt använder den tillgängliga hårdvaran. CUDA (Compute Unified Device Architecture) är en parallell datormaskinvara och programmeringsmodell som utvecklats av NVIDIA speciellt utformad för grafikenheter (GPU). Det gör det möjligt för utvecklarna att komma åt den virtuella instruktionsuppsättningen och minnet av de parallella GPU:erna. OpenCL är en standard för plattformsoberoende parallellprogrammering. Det gör det möjligt för programmerare att implementera och köra parallella koder i heterogena plattformar som kan inkludera CPU, GPU's, Digital Signal Processors (DSP) eller andra typer av processorer. Trots att många av de programmeringsmodeller och datorparadigm som nämns ovan har varit framgångsrika på att uppnå betydande genomgångar från nuvarande högpresterande datorinfrastrukturer, utmattning av traditionella prestandaförbättringar tekniker, som ILP eller OoO, innebär att mer asynkrona och flexibla programmeringsmodeller och runtime system kommer att användas för att exponera enorma mängder parallellism till hårdvaran. För att minska synkroniseringskostnaderna, optimera datarörelse över djupa minneshierarkier och hantera kritiska vägbaserade optimeringar behöver vi dataflödesscenarier som är mycket mer flexibla och har mycket mer potential än traditionella gaffel-join-strategier. Vissa modeller för dataflödesprogrammering håller på att utformas för att lösa sådana problem. Projektet Habanero [34] syftar till att utveckla en programmeringsmodell, en kompilator och ett runtime-system för att hantera uppgiftsbaserad asynkron parallellism samtidigt som man utnyttjar lokaliteten bland uppgifter och data som distribueras över kärnorna. Charm++ [20] är en C++-baserad asynkron meddelandedriven programmeringsmodell. Dess grundläggande arbetsenheter är meddelandedrivna föremål som kallas tecken. När programmet startar ett meddelande skapas ett objekt och dess tillhörande arbete utförs. När arbetet är klart förstörs skaran och dess utgång skickas till nästa utbrott av tecken som använder dessa data som inmatning. De tecken är dynamiskt kartlagda till fysiska processorer av körtiden systemet. Sådan kartläggning är transparent för programmet och därför görs det i syfte att öka belastningsbalansen och feltoleransen. Intressant nog har domänspecifika programmeringsspråk, som Sequoia [13], utvecklats för att specifikt uttrycka hierarkiskt minne genom att använda vissa programmeringsmodell primitiver och därmed låta programmeraren beskriva datarörelser vertikalt genom maskinen och lokalisera beräkningar till särskilda minnesplatser inom den. 4.4. Vad är det för fel på dig? Data-Graph Execution ISA: s Vissa ISA: s har särskilt utformats för att utföra instruktionerna med hjälp av en data-graf metod. LAU:s multiprocessor [10] föreslogs som syftar till att dra nytta av parallellism över tre nivåer: mellan jobb, mellan uppgifter inom ett arbete och mellan instruktioner inom en uppgift. För att möjliggöra skalbara och distribuerade processorkärnor har klinkerarkitektur föreslagits [26, 36, 40]. De består av flera enkla bearbetningselement som är sammankopplade med en on-chip-anslutning. Schemaläggningsinstruktioner i klinkerarkitekturer är avgörande för att få bra prestanda [26]. Explicit Data Graph Execution (EDGE) arkitekturer är exempel på kaklade arkitekturer [36]. Till skillnad från traditionella processorarkitekturer som arbetar på granulariteten av en enda instruktion, EDGE ISA stöd stora grafer av beräkning kartlagt till en flexibel hårdvara substrat, med instruktioner i varje graf kommunicera direkt med andra instruktioner, snarare än att gå igenom en delad registerfil. Denna förmåga minskar inte bara design komplexitet, men avtecknar utförandet overheads över en stor graf av instruktioner. I det här dokumentet introducerar vi en första strategi mot en Runtime-Aware Architecture (RAA), en massivt parallell arkitektur utformad ur runtimes perspektiv. Detta tillvägagångssätt erbjuder en enhetlig och allmän lösning som potentiellt kan lösa de flesta av de problem vi stöter på i de nuvarande strategierna: hantering av parallellism, minnesväggen, kraftväggen, programmerbarhetsväggen och den kommande tillförlitlighetsväggen i ett brett spektrum av applikationsdomäner från mobila upp till superdatorer. Sammantaget är denna nya inställning till framtida parallella arkitekturer ett sätt att säkerställa fortsatta prestandaförbättringar, så att vi kan ta oss ur de tekniska svårigheter som datorer har förvandlats till, än en gång på grund av Moores lag. Erkännanden. Detta arbete har delvis fått stöd av det spanska ministeriet för vetenskap och innovation inom ramen för bidraget TIN2012-34557, HiPEAC Network of Excellence och av Europeiska forskningsrådet inom ramen för Europeiska unionens sjunde ramprogram, ERC Grant Agreement nummer 321253. Vi vill tacka Alex Ramirez, Osman Unsal, Adrian Cristal, Mario Nemirovsky, Ramon Beivide, Alejandro Rico och hela RoMoL-teamet för de produktiva diskussionerna och all den feedback som vi fick när vi förberedde detta manuskript.
Uppgift Superscalar avbröts på grund av några design dödlägen, och inspirerade Picos som ett tidigt exempel på en Runtime-Aware arkitektur REF.
Runtime-Aware Architectures: A First Approach
{'venue': 'Supercomputing Frontiers and Innovations', 'journal': 'Supercomputing Frontiers and Innovations', 'mag_field_of_study': ['Computer Science']}