S calling upp program till exaskala kommer att kräva betydande programmeringsinsatser, även om nuvarande programmeringsmodeller visar sig vara tillräckliga: program kommer att behöva styra miljarder trådar som körs på kärnor med olika arkitekturer; bra power management kommer att vara viktigt; program kommer att behöva använda mindre kommunikation och minne i förhållande till mängden datorteknik; misslyckanden kommer att vara vanligare och eventuellt inkludera tysta fel; och power management och felhantering kommer att orsaka olika delar av systemet att köras i olika hastigheter. Vi diskuterar i den här artikeln parallella programmeringsmodeller och deras förmåga att hantera dessa utmaningar. Vi fokuserar på programmeringsmodeller som skiljer sig från programmeringssystem: en parallell programmeringsmodell ger "en uppsättning abstraktioner som förenklar och strukturerar hur programmeraren tänker och uttrycker en parallell algoritm", 1 medan ett programmeringssystem är ett genomförande av en eller flera modeller. Således är meddelandepassering en programmeringsmodell; meddelandepassagegränssnittet (MPI) 2 är ett programmeringssystem som stöder den modellen samt andra modeller, såsom fjärråtkomst till direktminne (RDMA). En bra programmeringsmodell behöver en prestandamodell för att uppskatta prestanda som en funktion av indata- och plattformsparametrar. Prestandamodellen är ungefärlig och har ingen formell definition, men det är viktigt: utan en sådan modell har programmeraren ingen inblick i ett programs sannolika prestanda. En bra programmeringsmodell för prestandadata bör exponera för programmeraren de resurser som har en betydande inverkan på prestanda och som kan styras av programvara; det bör dölja detaljer som har en sekundär inverkan, inte är under programvarukontroll, eller kan hanteras väl av kompilator och körtid. En "maskin-nivå" parallell datormodell exponerar hårdvaran på ett så direkt sätt som möjligt: ett program körs på en plattform som består av ett fast antal noder, var och en med ett fast antal fysiska trådar och minne. Modellen anger kommunikationsmekanismerna mellan trådar-antingen delade variabler inom en nod eller meddelande passerar över noder. Ett program anger sedan den instruktionssekvens som varje fysisk tråd utför. MPI+OpenMP stöder denna modell: varje nod blir en MPI-process som utför ett OpenMP-program som använder exakt en arbetsdelningskonstruktion (parallell loop eller avsnitt) för att starta en körning på varje tråd. OpenMP-programmet använder ett fast antal trådar och affinitet schemaläggning för att ha en fast association av logiska trådar till kärnor. Vanligtvis använder du William Gropp University of Illinois på Urbana-Champaign Argonne National Laboratory Computing i SCienCe & Engineering inte alla fysiska trådar så att systemkoden kan köras på separata resurser. Dessutom är det ofta att föredra att dela en fysisk nod i flera MPI-processer. Programmeringsmodeller på högre nivå virtualiserar resurser och använder ett runtime-lager för att kartlägga "virtuella" enheter (t.ex. trådar eller variabler) till fysiska enheter (kärnor eller minnesplatser). Detta görs för att underlätta programmering och portabilitet. Användningen av programuttag på högre nivå kommer också att uppmuntra eller ge mandat till användning av restriktiva programmönster som minskar sannolikheten för fel eller underlättar virtualisering. I den här artikeln kommer vi att behandla de designval som görs av flera föreslagna exaskala datormodeller. En högpresterande parallellprogrammeringsmodell omfattar flera designval utöver dem som finns i en sekventiell programmeringsmodell. Vi diskuterar fem av de viktigaste övervägandena här. Kartläggningen mellan logiska exekveringstrådar och fysiska trådar kan vara dynamisk och hanteras vid körning. I ett sådant fall kan programmeringsmodellen rymma ett varierande antal logiska trådar och operationer som ger upphov till nya trådar eller väntar på att de ska slutföras. Hur dessa trådar är schemalagda att köra och om de kan flytta till olika kärnor eller noder kan avsevärt påverka prestanda. Vissa modeller, som t.ex. Thread Building Blocks (TBB), 3 fattar ett enda schemaläggningsbeslut när tråden skapas. Andra, såsom OpenMP (för delat minne) 4 eller Charm++ (för distribuerat minne) 5 stödtrådsmigrering vid specifika punkter i trådutförandet (detta brukar kallas belastningsbalansering). Hybridmodeller är också möjliga-logiska trådar är statiskt fördelade på noder men dynamiskt fördelade på kärnor inom noder. MPI+OpenMP stöder denna typ av modell. På nuvarande maskiner, kommunikation mellan cache och minne, över cache i noder, och över noder tar betydligt mer tid än beräkning. Kommunikation mellan cache och minne är en bieffekt av laster och butiker. En förenklad prestandamodell förutsätter att tillgången till minne är lika snabb som tillgången till L1-cachen. Programmerare ser till att denna approximation är giltig genom att skriva kod med god temporal, rumslig och trådlokalitet. Men inte alla algoritmer kan uttryckas med god lokalitet. Dessutom kan kostnaden för associativa cache (i kisel och energi) leda till att de delvis eller fullständigt ersätts i framtida system genom uttryckligen adresserbara skrapplattor. Dessutom kan det vara svårt att stödja cachekonsistens på noder med hundratals kärnor. Därför kommer core-to-memory kommunikation och kärn-to-core kommunikation sannolikt att bli mer programvara kontrolleras och eventuellt exponeras för användaren. Även om kompilatorer enkelt kan generera explicita data flytta kommandon från kod med laster och butiker, de har en svår tid att optimera dessa rörelser-till exempel genom att aggregera eller köra dem kollektivt. I dessa fall måste kostnaden för delad kommunikation ingå i prestandamodellen. Kommunikationen kan vara ensidig, utföras av programvara som körs på en plats-till exempel läser och skriver till lokalt minne eller få och sätta operationer på fjärrminne. Det kan också vara tvåsidigt, med programvara som körs på båda platserna inblandade-till exempel skicka / ta emot meddelande passerar operationer. Alternativt kan det vara kollektivt, med en grupp av platser som är gemensamt involverade; sådana operationer kan genomföras effektivt i hårdvara men kommer att prestera dåligt när de ställs inför jitter (variationer i utförande hastighet på grund av bakgrundssystem aktiviteter eller andra orsaker). Olika prestandamodeller för internodekommunikation följer postmodellen (kommunikation av m byte tar tid a + bm) eller ibland den mer komplexa LogP-modellen. Synkronisering Tvåsidig kommunikation synkroniserar de inblandade parterna. Ensidig kommunikation synkroniseras inte, så separat synkronisering krävs för att upprätthålla databeroenden. Både delade och distribuerade minnessystem stöder synkronisering. De flesta delad-minnessynkroniseringsoperationer, såsom lås eller atomsektioner, är symmetriska, ömsesidiga-exklusionskonstruktioner: de säkerställer att olika trådar inte utför operationer eller instruktionsblock samtidigt, men de anger inte i vilken ordning trådarna kommer att köras. Distribuerade-minnessynkroniseringsoperationer, såsom dubbelsidig kommunikation eller barriärkommunikation, är asymmetriska konstruktioner. Användningen av att beställa synkroniseringskonstruktioner kan eliminera icke-determinism och därmed underlätta felsökning. En enkel synkroniseringsmodell är modellen bulksynkron parallell (BSP), där antalet trådar är fast och alla trådar kör november/dedecember 2013 29 i synkroniserade faser så att fjärrdata som förbrukas i fas i av en tråd produceras av en annan tråd i fas j < i. 7 En bulk-synkron utförande är lätt att förstå, med producentkonsumentrelationer synkroniseras av en global klocka. Denna modell stöds i MPI om all kommunikation är kollektiv eller om hinder definierar faserna; alla skickar utförs i fas i matchas av de mottagare som är färdiga i slutet av fas i eller i en senare fas. Denna modell kan utökas (även om den fortfarande bevarar sin konceptuella enkelhet) till en bofast bulksynkron modell, som delar upp trådar i grupper som utför under BSP-modellen. 8 MPI-kommunikatörer kan hjälpa till att genomföra denna modell. Denna modell stöds också av lämpligt begränsade OpenMP-program. Kommunikationskostnaderna beror på uppgifternas "hem": där de lagras när de inte används aktivt. De flesta distribuerade programmeringsmodeller ger användarkontroll på data hem. I ett objektorienterat system som Charm++ är data inkapslad i objekt tillsammans med metoder; objektens plats avgör både var data lagras och var metoderna utförs. Samma fasta samband mellan lagringsplats och plats för utförande förekommer i meddelandepasserande modeller och partitionerade globala adressutrymmesspråk (PGAS). Kommunikationskostnaderna kommer att vara beroende av lämplig samlokalisering av uppgifter och de åtgärder som vidtas på detta område. En datacentrerad vy (dataparallalism) fokuserar på datadistribution och matchar beräkningsplatsen till den. En kontrollcentrerad vy (task eller kontrollparallalism) fokuserar på kontrolldistribution och flyttar data till där det behövs. De flesta aktuella programmeringsmodeller uppmuntrar en datacentrerad vy för distribuerat minne och en kontrollcentrerad vy för delat minne. Den senaste forskningen försöker ge en mer symmetrisk bild genom att underlätta både data- och kontrollmigration. Oavsett om du flyttar data till kontroll eller kontroll till data, har du fortfarande kommunikation som är inneboende i den parallella algoritmen: data måste flyttas till data. I ett system med en lokal syn på kontroll kör varje fysisk tråd sitt eget (sekvens) program. Programmen är identiska i ett enda program, flera data (SPMD) modell; de skiljer sig i flera program, flera data (MPMD) modell. Flera utföranden samverkar genom kommunikation och synkronisering. Med en global syn på kontroll använder ett program parallella kontrollangivelser (t.ex. en parallell slinga) eller parallella dataoperationer (t.ex. en vektoroperation) för att specificera aktiviteter som kan hända samtidigt på flera fysiska trådar. Den enda instruktionen, flera data (SIMD) modellen uppnår parallellism med sekventiell kontroll och parallella dataoperationer. På samma sätt kan du ha en lokal bild av data, där varje tråd har sina egna lokala datastrukturer, eller en global bild av data där aggregerade datastrukturer såsom matriser spänner över flera noder; en datafördelningsfunktion anger vilken del av matrisen som lagras var. I det första fallet nås en fjärrsändningsplats genom att använda en annan syntax än en lokal (t.ex. a(index) och a(index) [numproc], i Fortran). I det senare fallet kan samma uttryck-a [index] i Unified Parallel C (UPC)-avse en lokal eller en fjärrplats, beroende på fördelningen av array a. Kan vi programmera exaskala system med våra nuvarande metoder? Kan utvecklingen av nuvarande strategier ge lämpligt stöd till exaskalasystem? För att besvara dessa frågor måste vi titta närmare på de nuvarande programmodellerna och deras sannolika förlängningar. Dagens programmeringsmodeller för parallella datorer täcker ett brett spektrum av tillvägagångssätt; i tabell 1 sammanfattas de viktigaste. [9] [10] [11] [12] [13] [15] [16] [17] [18] [19] [20] [20] Dessa exempel visar att ett programmeringssystem, såsom MPI, kan stödja flera programmeringsmodeller. I vissa fall kan flera programmeringssystem användas tillsammans, de vanligaste är MPI och OpenMP. Eftersom ett exaskala system sannolikt har distribuerad minnes hårdvara, är ett av de mest naturliga programmeringssystem MPI, som för närvarande används på mer än 1 miljon kärnor med exceptionell skalbarhet. Det är därför rimligt att fråga om MPI kan användas på ett exaskala system. Denna fråga väcker följande frågor, som inte nödvändigtvis är giltiga problem: • Mängden meddelandebuffertutrymme växer inte som O(P) om korrekt implementeras. 21 För många applikationer växer den bara som O(log(P)). • Andra MPI interna minne, såsom beskrivningen av MPI kommunikatörer, också inte "MPI överallt" strategi står inför flera utmaningar: • MPI-processen modellen uppmuntrar programmerare att göra lokala kopior av data för att förbättra prestanda. Eftersom exaskalsystem sannolikt har relativt små mängder minne per kärna måste applikationerna vara mycket minneseffektiva. En möjlig lösning för MPI-program är att använda den direkta åtkomsten till delat minne som introduceras i MPI-3. • Även om MPI ger tillräckligt stöd till programmerare för att implementera effektiv, skalbar kod även i närvaro av prestandaosäkerhet, är det ett lågnivåsystem som förlitar sig på programmeraren för att använda den väl. Dessutom, som bibliotek, en MPI implementation har några extra overhead. Även om dessa utmaningar inte är oöverstigliga, kan de kräva betydande insatser både för att bygga en skalbar MPI-implementation och för att använda MPI på ett skalbart sätt. Flera andra kandidater har föreslagits för ett enda system överallt. OpenMP kan utvidgas till distribuerade minnessystem, till exempel, men distribuerade minnesimplementeringar av delade minnessystem uppnår normalt inte godtagbar prestanda. 24 PGAS system som UPC och Fortran skulle kunna införas för ett exaskala system och diskuteras senare, men dessa strategier har också problem. Vissa operationer är svåra att skala upp, och beskrivningar räknas upp på ett icke skalbart sätt. Dessutom har dessa strategier haft begränsad framgång i praktiken, med få viktiga koder som använder dem, kanske för att prestanda kräver uppmärksamhet på plats liknande vad MPI kräver. Det programmeringssystem som oftast används för delad parallellism i vetenskapliga koder är OpenMP. Men att skala upp den till hundratals kärnor kommer att kräva förändringar både i programmeringsstil och i själva språket. OpenMP tillhandahåller en ren kontrollparallell modell, men inga mekanismer för att kontrollera datadistributionen. Därför kan OpenMP-koder inte mappas effektivt till ett icke-uniform minne arkitektur (NUMA) system. OpenMP tillhandahåller många icke skalbara synkroniseringskonstruktioner (lås, atomsektioner och sekventiella sektioner) och tenderar att uppmuntra finkornig synkronisering. Därför är många OpenMP-program skrivna i en stil som hindrar skalning. Olika förslag har lagts fram för att utvidga OpenMP-språket och för ny kompilator- och körtidsteknik som kan lindra dessa problem. Några av dessa förändringar gjordes i OpenMP v4.0-i synnerhet, stöd för trådaffinitet-men bevis saknas att OpenMP kommer att skala till hundratals kärnor. Ett möjligt alternativ är att använda ett PGAS-system som ett gemensamt programmeringsspråk. Sådana system, som för närvarande är utformade och implementerade, ger dock inte bra stöd för lastbalansering. Skalbarhetsproblem kan underlättas genom att använda ett hybridsystem, det enklaste är ett system som följer maskinvaruarkitekturen: MPI används för internode parallellism och några andra delade minnesprogrammeringsmodell för intranode parallellism. Denna modell kallas ofta MPI+X, och den utnyttjar det faktum att MPI är utformad för att vara kompatibel med gängning. En sådan modell minskar trycket för att skala antingen MPI eller OpenMP, minskar minnestrycket eftersom mindre data replikeras inom varje nod, och kan bättre utnyttja delat minne. Det största problemet när man blandar programmeringssystem är att de konkurrerar om resurser, som t.ex. trådar (för runtime progress), samt bandbredd (inklusive åtkomst av minne via internoden. Även om vissa ansträngningar har övervägt detta problem återstår 25 mycket att göra. Lyckligtvis är hjälp på väg, och nya programmeringsmodeller för högpresterande datorer har dykt upp under de senaste åren. Modern kommunikationsutrustning stöder i allt högre grad RDMA för att minska mängden kopiering som sker under kommunikation och för att minska kommunikationsprogramvarans overhead. Ensidig kommunikation stöder PGAS-programmeringsmodellen väl. I denna modell kan data antingen vara privata (endast lokalt tillgängliga) eller delas, med tillgång till privata data något snabbare än till delade lokala data och tillgång till lokala data mycket snabbare än tillgång till fjärrdata som kräver RDMA. PGAS-modellen kan stödjas av ett bibliotek som MPI, Shared Memory (SHMEM), 13 eller Global Arrays (GA) 16 eller av ett språk som UPC 14 eller Fortran (särskilt de co-array-funktioner som lagts till Fortran 2008). 15 I det förra fallet görs fjärråtkomst uttryckligen via funktionssamtal, medan de i det senare är implicita: språket skiljer, per typ, privata variabler från delade variabler och kan genom syntax skilja lokala referenser från fjärrreferenser. PGAS-system skiljer sig åt i hur det globala namnutrymmet är organiserat. Vissa, till exempel SHMEM eller Fortran, ger en lokal bild av data; andra ger en global bild. UPC och X10 12 stöder endimensionella block-cykliska matrisfördelningar, medan GA stöder flerdimensionella fördelningar, med block av lika eller skilda storlekar. Kapellets språk 17 stöder delade kartor (med täta eller glesa indexuppsättningar) och godtyckliga, användardefinierade distributioner. PGAS-systemen skiljer sig också åt i sina styrstrukturer. De flesta (MPI, UPC och X10) ger en lokal syn på kontroll. UPC ger en kollektiv forall uttalande som byter till en global syn på kontroll; Chapel betonar denna globala syn. MPI och UPC stöder också en statisk schemaläggningsmodell med ett fast antal trådar, medan X10 och Chapel stöder dynamisk schemaläggning. I X10 kan uppgifter migreras från en process till en annan eller skapas asynkront på en annan process. I kapellet kan användaren styra platsen där ett uttalande utförs, för att samla den körningen med ett datum eller en plats. En global vy av data eller kontroll underlättar anpassningen av sekventiell kod: slingor ersätts med parallella slingor, och matriser distribueras. Men det kan också leda till ineffektiva programmeringsmönster: eftersom datalokalisering inte är framträdande, är det lätt att skriva kod med överdriven tillgång till fjärrdata. Dessutom är det inte alltid möjligt att vid sammanställningen särskilja lokal åtkomst till delade data från fjärråtkomst, vilket resulterar i extra omkostnader för delad dataåtkomst. Global kontroll uppmuntrar en programmeringsstil där varje synkronisering förenar alla trådar och sedan gafflar kontroll igen, vilket resulterar i onödiga overheads. Caching är viktigt för att uppnå prestanda i (hårdvara-stödd) delat minne. Det är mest effektivt när strömmen av minnesreferenser har god tidsmässig och rumslig lokalitet. PGAS-implementationer använder lokalt minne som en cache till fjärrminnesdata; cachehantering sker via körtid. Tyvärr är det för dyrt att köra ett globalt koherensprotokoll och för svårt för kompilatorn att analysera när ett cachat värde blir ogiltigt. Därför används den lokala buffrade kopian ofta bara en gång, även om koden har god timlig lokalitet. Fasta linjestorlekar fungerar inte effektivt för internode kommunikation, och kompilatorer misslyckas ofta att aggregera flera fjärrord åtkomster till större meddelanden. För att uppnå god tidsmässig och rumslig lokalitet måste programmerare ofta Computing i SCienCe & engineering explicit kopiera data och förlora mycket av den bekvämlighet som PGAS språk har jämfört med ensidiga bibliotek. 26 PGAS språk utvecklas fortfarande; nya funktioner kommer att behövas innan de är redo att användas i extrem skala. stöd till grupper. Multifysikkoder består ofta av flera moduler, varje körs på en delad uppsättning av processer; modulerna kan köras samtidigt (på separata noder) eller sekventiellt (på samma noder). MPI tillhandahåller kommunikatörer för att stödja sådana koder; liknande teamfaciliteter har diskuterats för PGAS språk. Multitasking och meddelandedriven körning. Konkurrent eller samtidig multitrådning kan användas för att undvika sysslolös tid när cache missar inträffar: om en tråd blockeras och väntar på en minnesåtkomst, då en annan tråd kan använda CPU. Dessutom, cache prefetching kan hjälpa till att undvika cache missar; hårdvara kan generera prefetches för sammanhängande avancerade åtkomster, och en kompilator kan infoga dem för oregelbundna åtkomster. Liknande tekniker behövs för att dölja internode kommunikationslatens. Icke-blockerande kommunikation-till exempel, nonblocking får-är motsvarigheten till cache prefetching, men på grund av de mycket högre latenser, är det osannolikt att prefetches kan kompilator-genereras. Något mer bekvämt och effektivt är att köra fler trådar än kärnor och sedan schemalägga dessa trådar dynamiskt, antingen med icke-blockerande trådar aktiverade när deras inmatningsmeddelande anländer och avslutas när de genererar ett utmatningsmeddelande 5,28 eller med längre livslängd trådar som blockerar när de utför en blockerande internode kommunikation och boka om efter kommunikationen är klar. 29 Projektet Dynamic Exascale Global Address Space (DEGAS) studerar språk som kombinerar PGAS och multitasking. Avrättningstid och kommunikationstid kommer att uppvisa högre avvikelser på exaskala system på grund av de större nivåerna av parallellism, varierande utförande hastighet på grund av makthantering och felhantering, och oegentligheter i koderna själva. Multitasking ökar vår förmåga att hantera den ökade variansen. Virtualisering. Medan PGAS språk vanligtvis kartlägger lokaler till fasta fysiska platser, finns det ingen inneboende anledning till varför denna kartläggning inte kunde ändras under utförandet. Charm++ systemet omfördelar regelbundet "tecken" över noder för att förbättra belastningsbalansen. Data- och beräkningsmigrering kan ske på ett transparent sätt via körtid eller under användarkontroll. hierarkisk utformning. PGAS+multitasking ger en två-nivå programmering modell som liknar MPI+OpenMP. Allteftersom systemets storlek ökar blir lagrings- och kommunikationshierarkierna djupare. Det är allmänt trott att exaskala system kommer att kräva stöd för hierarkiska programmeringsmodeller med mer än två nivåer: på högre nivåer i hierarkin, lastbalansering åtgärder blir sällsyntare, och kommunikation förväntas vara mindre frekvent. Hierarkiskt Tiled Array-projektet är ett exempel på en programmeringsmodell som är organiserad kring en hierarkisk datastruktur. 31 Ett domänspecifikt språk (DSL) är "ett programmeringsspråk eller körbart specifikationsspråk som genom lämpliga noteringar och abstraktioner erbjuder uttryckskraft som är fokuserad på och vanligtvis begränsad till en viss problemdomän". 32 DSL stöds vanligtvis av källkodskompilatorer som översätter DSL-notationen till kod skriven på ett konventionellt språk som använder domänspecifika bibliotek. DSL kan underlätta kodutveckling, underhåll och portering på bekostnad av de insatser som krävs för att utveckla DSL och de programmeringsverktyg som krävs för att använda det effektivt. DSL är därför mest effektiva när de tjänar en smal domän med en stor användargemenskap: ansträngningarna i DSL: s utveckling amorteras mot de större samhällsvinster. Som ett exempel skrev vi denna artikel i LaTeX, en DSL för att generera dokument: det är ett smalt program med många användare. En "domän" är vanligtvis inte en specifik vetenskapsdomän, utan snarare en matematisk eller algoritmisk domän. Till exempel kan Matlab ses som en DSL för domänen linjär algebra. Medan ofta motiveras av en viss vetenskap domän, många DSLs genomföra någon kombination av datastrukturer och operationer på dessa datastrukturer och få sina fördelar genom att specialisera sig på vissa operationer. DSL för olika vetenskapliga datadomäner som genererar parallellkod har varit föremål för forskning i flera decennier. 19, 20, [33] [34] [35] Två uppenbara hinder för deras bredare användning är att samhället av vetenskapliga HPC programmerare är liten och prestanda DSL-genererad kod är inte alltid konkurrenskraftiga med prestanda november / december 2013 33 handjusterad kod. Detta första hinder kan lindras genom att utveckla teknik som underlättar utvecklingen av nya DSL, 36 och det andra med hjälp av autotuning. Även om DSL anses skilja sig från bibliotek och ramar, är denna distinktion krympande. Ett bibliotek som PETSc 18 är i själva verket ett inbäddat DSL, ett värdspråk som utökas med domänspecifika konstruktioner. Den domänspecifika kunskapen kan byggas in i en källkodsöversättare som optimerar koden med hjälp av dessa tillägg. 38 Vi förväntar oss att DSL är en del av lösningen för exaskala programmering, men de ersätter inte allmän-purpose parallellprogrammering miljöer-i själva verket, de är beroende av dem. Dessutom är DSL mer effektiva när de är mer specialiserade; de är osannolikt att täcka hela utbudet av HPC-tillämpningar. DSL och bibliotek är speciella exempel på "multilevel programmering": programforskare program i en notation som är meningsfull för henne, medan prestanda programmeraren implementerar bibliotekens program på en nivå som är närmare hårdvaran. Mekanismer och verktyg som underlättar en sådan arbetsfördelning är föremål för intensiv forskning. 39, 40 W e've diskuterat tillvägagångssätt som kan lindra oron för skalbarhet, lågt minne, och höga kommunikationskostnader på exaskala system. Vi har ännu inte täckt heterogenitet, makthantering och motståndskraft. Anledningen till dessa utelämnanden är att det inte är uppenbart att nya programmeringsmodeller kommer att behövas för att hantera dessa frågor. Vi förväntar oss att ett system kommer att användas för att programmera delade minnesnoder och hantera heterogeniteterna hos kärn- och minnesarkitektur med betydande kompilatorhjälp. Version 4 av OpenMP-standard 4 ger tillägg för att ange vilken kod som kommer att avlastas till acceleratorer och styra förflyttningen av data över adressrymder. Programmering för låg energianvändning är oftast synonymt med att minska kommunikationen, vilket kräver en uttrycklig användarkontroll av kommunikationen. Belastningsbalansering kan bidra till att begränsa temperaturen och minska energiförbrukningen. Det råder stor osäkerhet om kraven på programplaneringsmodell för motståndskraft. Det är möjligt särskilt om tysta fel kan undvikas-att inga nya funktioner kommer att behövas, 42 men ett minimikrav kommer att vara för fel som förekommer ofta för att generera väl definierade undantag och lämna programmet i ett väldefinierat tillstånd. Vi har gjort små framsteg under de senaste decennierna mot den "heliga graal" av en enkel modell som kan användas för att programmera i vilken skala som helst. Kanske är detta mål inte genomförbart. Trots detta har vi långsamt förbättrat programmeringsmodeller och programmeringsmetoder för HPC, och sökandet efter bättre programmeringsmodeller måste fortsätta. Det finns fortfarande en hel del osäkerhet om modellerna som kommer att användas i exaskala, men det finns definitivt visshet om de nödvändiga kraven: stort antal trådar, minskad kommunikation och synkronisering, tolerans för varians i utförandetid, och så vidare. Nya koder, även om de skrivs med aktuella programmeringsmodeller, måste skrivas för att uppfylla dessa krav, så att framtida portar inte kräver algoritmförändringar. Detta är särskilt viktigt för nyskriven OpenMP-kod, eftersom det är naturligt att skriva sådan kod utan hänsyn till lokalitet och med finkornig synkronisering. Goda programplaneringsmetoder är viktigare än goda programplaneringsmodeller.
Ett gemensamt tema för dessa nya modeller är förmågan att stödja intranode parallellism med hjälp av multi-tasking eller gaffel-join modeller REF, tillsammans med någon form av distribuerad minneskommunikation.
Programming for Exascale Computers
{'venue': 'Computing in Science & Engineering', 'journal': 'Computing in Science & Engineering', 'mag_field_of_study': ['Computer Science']}