Vi undersöker användningen av ett program distribuerat delat minne (DSM) skikt för att stödja oregelbundna beräkningar på distribuerade minnesmaskiner. Programvara DSM stöder oregelbunden beräkning genom behovshämtning av data som svar på minnesåtkomst fel. Med tillägg av en mycket begränsad form av kompilatorstöd, nämligen identifiering av den del av indirektion array som nås av varje processor, många av dessa on-demand-sida hämtar kan aggregeras i ett enda meddelande, och prefetched före åtkomstfelet. Vi har mätt prestandan av detta tillvägagångssätt för två oregelbundna applikationer, molyyn och nbf, med TreadMarks DSM-system på en 8-processor IBM SP2. Vi finner att det har liknande prestanda som inspektören-executor metoden stöds av CHAOS run-time biblioteket, samtidigt som det kräver mycket enklare kompilering-tid stöd. För mölyn, är det upp till 23 ~ 0 snabbare än CHAOS, beroende på inmatningsproblemets egenskaper; och för nbf, är det inte värre än 14% långsammare. Om vi inkluderar tiden för utförandet av inspektören, den programvara DSM-baserade metoden är alltid snabbare än CHAOS. Fördelen med detta tillvägagångssätt ökar i takt med att frekvensen av förändringar i indirektionsmatrisen ökar. Nackdelen med detta tillvägagångssätt är potentiaJ för falskt dela overhead när datamängden är liten eller har dålig rumslig lokalitet, Inspector-executor metoder har föreslagits som ett sätt att effektivt utföra oregelbundna beräkningar på distribuerade minnesmaskiner [18]. En separat slinga, inspektören-, föregår den faktiska beräkningsslingan (kallas ezecutor). Inspektörsloopen bestämmer de data som läses och skrivs av de enskilda processorer som utför beräkningsloopen. Denna information används sedan för att beräkna ett kommunikationsschema och överföra data från producenterna till konsumenterna i början och/eller slutet av varje slinga. Kommunikationsaggregation används för att minska antalet utbytta meddelanden. För att ytterligare minska överhuvudet görs ett försök att utföra inspektörsloopen endast en gång för ett stort antal iterationer av executorloopen. Det har hävdats att hela eller en del av ovanstående förfarande kan automatiseras av en kompilator [21]. Analysen av kompilatorn kan emellertid vara ganska komplicerad [1, 6, 20]. I detta dokument föreslår vi ett alternativt tillvägagångssätt. Vi använder ett programvara distribuerat delat minne (DSM) lager som ger ett delat minne gränssnitt ovanpå meddelandelagret [13]. I sin enklaste form stöder DSM-skiktet oregelbundna beräkningar genom efterfrågedriven insamling av data. Vårt tillvägagångssätt innebär dessutom en enkel kompilator frontend som genererar dataåtkomst information, vilket gör det möjligt för run-time systemet att effektivt förhandskompilera den uppsättning sidor som kommer att nås av varje processor under nästa iteration. Dessa sidor begärs sedan, innan iterationen, i ett enda meddelande utbyte med varje processor från vilken data behövs. Med andra ord, vår strategi utökar basprogramvara DSM lager genom att göra det möjligt att aggregera kommunikationen av data för oregelbundna program. Kompilatorn stöd som krävs för vårt tillvägagångssätt är mycket enkel: det räcker att bestämma indirektion array, och den del av indirektion array som nås av varje processor. Detta är vanligtvis ett vanligt avsnitt [4]. Tillvägagångssättet med inspektören kräver däremot en komplicerad analys för att avgöra om inspektörens slinga kan lyftas ut ur huvudslingan [1, 20]. I detta dokument presenteras vår strategi i detalj. För att samla experimentella resultat använder vi en modifierad version av TreadM arks [2] som stöder förhämtning och aggregering på det sätt som beskrivs ovan. Dessutom har vi utökat Parascope parallellprogrammeringsmiljön [12] för att utföra den nödvändiga kompilatoranalysen. Vi presenterar resultat för två oregelbundna applikationer, molyyn och nbf. Resultaten erhölls på en 8-processor IBM SP2 med bas Tread Marks och Tread Marks med aggregeringsstöd. Vi jämför dessa resultat med mätningar av handkodade executor-versioner av samma applikationer som använder CHAOS run-time-biblioteket [7]. Vi finner att TreadMarks förstärkt med kompilatorstöd för kompilatoraggregation i oregelbundna program har liknande prestanda som den executor-metod som stöds av CHAOS run-time-biblioteket. För mölyn, är det upp till 23 ~o snabbare än CHAOS, beroende på inmatningsproblemets egenskaper; och för nbf, är det inte värre än 14% långsammare. Dessutom är det upp till 38% snabbare än bas TreadMarks-systemet. Om vi inkluderar tiden för avrättningen av inspektören, är vår strategi alltid snabbare än CHAOS. Fördelen med vår strategi incre.mes som frekvensen av förändringar i indirektion array ökar. Dess nackdel 48
Lu et al REF föreslog kompilatorstöd för oregelbundna program på program distribuerat delat minne.
Compiler and software distributed shared memory support for irregular applications
{'venue': "PPOPP '97", 'journal': None, 'mag_field_of_study': ['Computer Science']}