I detta dokument presenteras de viktigaste idéerna om Grid.it-projektets högpresterande komponentbaserade programmeringsmiljö för rutnät. Högpresterande komponenter kännetecknas av en programmeringsmodell som integrerar begreppen strukturerad parallellism, komponentinteraktion, kompositionalitet och adaptivitet. Vi visar att ASSIST, prototypen av den parallella programmeringsmiljö som för närvarande är under utveckling i vår grupp, är en lämplig grund för att fånga alla önskade funktioner i komponentmodellen på ett flexibelt och effektivt sätt. För interoperabilitetens skull är ASSIST-moduler eller -program automatiskt inkapslade i standardramar; för närvarande experimenterar vi Web Services och CORBA-komponentmodellen. Rutnätstillämpningar, som är uppbyggda som sammansättningar av ASSIST-komponenter och eventuellt andra befintliga (legacy)-komponenter, stöds av en innovativ Grid Abstract Machine, som inkluderar viktiga abstraktioner av standard Middleware-tjänster och en hierarkisk Application Manager (AM). AM stöder statisk fördelning och dynamisk omfördelning av adaptiva applikationer enligt ett prestationskontrakt, en omkonfigureringsstrategi och en prestandamodell. Komponenter, Strukturerad parallellprogrammering, Programmeringsmodeller, Grid, Adaptive Applications, High Performance Computing, Omkonfigurering. Inom ramen för Grid-plattformar på olika integrationsnivåer [1] måste en Gridaware-applikation kunna hantera heterogenitet och dynamik i * Detta arbete har fått stöd av det italienska MIER FIRB Grid.it-projektet (RBNE01KNFP) på högpresterande Grid-plattformar och -verktyg, och av MIER CNR:s strategiska projekt L 499/2000 om högpresterande distribuerade möjliggörande plattformar. 2 det mest effektiva sättet (adaptive applications), för att garantera den angivna prestandanivån trots de olika run-time händelser som orsakar ändringar i resurstillgänglighet (ladda urbalansering, nod / nätverk fel, administrationsfrågor, nödsituationer, och så vidare). När det gäller traditionella plattformar är det mycket viktigare att förlita sig på tillämpningars utvecklingsmiljöer och verktyg som både garanterar programmerbarhet på hög nivå, programkomposition, programvarukompatibilitet och återanvändning, och de kan uppnå hög prestanda och förmåga att anpassa sig till utvecklingen av underliggande teknik (nätverk, noder, kluster, operativsystem, mellanprogram) [2] [3] [4] [5] [6] [7] [8]. Att uppnå denna högnivåsyn på utvecklingen av nättillämpningar är det grundläggande målet för vår forskning, i det nationella Grid.it-projektet [9] och i tillhörande initiativ på nationell och europeisk nivå. För att effektivt kunna utforma, utveckla och distribuera en sådan typ av högpresterande Grid-medvetna applikationer är vi intresserade av innovativa programmeringsmiljöer som i) stöder programmerarna i all verksamhet som rör parallellismexploatering, genom att tillhandahålla någon form av strukturerade primitiver för parallellismexploatering, ii) gör det möjligt att uppnå full interoperabilitet med befintlig programvara, både parallell och sekventiell, antingen tillgänglig i käll- eller objektform, iii) stödja och genomdriva återanvändning av redan utvecklad kod i andra tillämpningar. I synnerhet vill vi utnyttja vår grupps erfarenhet av utformning och genomförande av strukturerade parallella programmeringsmiljöer [10] [11] [12] för att rikta Grids som består av kluster eller nätverk av heterogena arbetsstationer Tabell 1. Layerad programvaruarkitektur för Grid-medvetna applikationer Komplexa, tvärvetenskapliga applikationer. Programmerare uttrycker bara den typ av parallellism, utan att bry sig om några detaljer som är involverade i dess utnyttjande eller relaterade till det faktum att målarkitekturen är ett rutnät. Användaren levererar, för varje parallell komponent, ett fullgörandekontrakt som ska uppfyllas. Utnyttjande av strukturerad parallellism, grundläggande mekanismer som stöder kompositionalitet, interoperabilitet och återanvändning av befintlig programvara, stöd för dynamisk kontroll av prestandakontrakt och anpassningsförmåga. Funktionaliteter och mekanism som stöder programmeringsmiljön, inklusive dynamisk applikationshantering och alla nödvändiga funktioner från resurs-, kollektiv- och konnektivitetsnivåer i Grid middleware Components för. Vi anser att en komponentbaserad programmeringsmiljö är en lämplig utgångspunkt för att uppnå de uppsatta målen. I detta arbete diskuterar vi de väsentliga inslagen i en programplaneringsmiljö som bygger både på komponentmodellen och på strukturerad parallellism. Programmeringsmiljön är ett lager av en större bild, såsom den i tabell 1. Vi kommer först att diskutera egenskaperna hos en komponentbaserad parallellprogrammeringsmodell. Sedan kommer vi att ta hänsyn till hur dessa funktioner för närvarande eller snart kommer att stödjas i ASSIST. ASSIST är en strukturerad parallellprogrammeringsmiljö som ursprungligen utformades för att endast behandla kluster och nätverk av TCP/IP-arbetsstationer, inom ramen för det italienska nationella projektet ASI-PQE2000 [18]. Vi visar att ASSIST är en lämplig grund för att fånga alla önskade funktioner på ett flexibelt och effektivt sätt, och i synnerhet diskuterar vi hur den ursprungliga ASSIST-miljön för närvarande omvandlas till en komponentbaserad, Grid-medveten parallellprogrammeringsmiljö. Denna utveckling av ASSIST-miljön genomförs inom ramen för Grid.it Italiens nationella projekt. Grid.it är ett treårigt projekt med stora forskningsinstitut i Italien som syftar till att tillhandahålla innovativa programplaneringsmetoder och verktyg för Grids. Projektet har ett specifikt arbetspaket som leds av vår grupp och som syftar till att utforma och implementera en prototyp med hög prestanda för parallellprogrammering av Grids. Komponentbaserad ASSIST är det förväntade, utvärderade resultatet av detta arbetspaket. Flera studier erkände att komponentteknik kunde utnyttjas för att underlätta utvecklingen av Grid-tillämpningar. Vi antar som referenskomponentstandarder CORBA Component Model (CCM), på grund av dess rena och rika komponentmodell [19] [20], och Web/Grid Services [21], eftersom de växer fram som standardinfrastruktur för att integrera heterogena system [21]. Den gemensamma komponentarkitekturen (CCA) är en framträdande standardiseringsinsats som syftar till att definiera en högpresterande komponentarkitektur [22]. Vi avviker från CCA-baserade tillvägagångssätt som CCaffeine [23] eftersom vi uttryckligen behandlar frågor om komponentsammansättning (se Sect. 1.2 och Sect. Europaparlamentets yttrande vid den första be handlingen: Bull. 62003, punkt 1.3.2 Vårt tillvägagångssätt skiljer sig från GridCCM [24], eftersom det senare fokuserar på kommunikationsoptimering, medan vårt arbete är inriktat på applikationsanpassning och Grid-medvetenhet i allmänhet. Vi är närmare GRAD-projektet [25] när det gäller begreppet anpassningsförmåga och i vissa arkitektoniska aspekter, men vi skiljer oss åt i programmeringsmodellen. Vår modell, baserad på strukturerad parallell programmering, har förmågan att i) från den parallella strukturen av applikationer syntetisera prestandamodellerna som används för att anpassa sin beräkning, och ii) att styra applikationen i körtid, med hjälp av en parametrisk implementation av parallella programmeringskonstruktioner. Ett nära relaterat projekt till vår är ProActive [26], som utökar Fractal komponentramverket för Java [27] för att stödja parallella, omkonfigurerbara komponentarkitekturer på Grid. Vi delar med Proactive-projektet avvikelsen från flata komponentmodeller för att gå mot explicit komponentsammansättning, betoningen på run-time adaptivity av komponentstrukturer, och exploateringen av dessa hierarkiska strukturer för att hantera tillämpningen omkonfigurering. Vi skiljer oss från den forskningen eftersom vi inte är begränsade till Java, vi har istället en väldefinierad, språkbaserad separation mellan sekventiellt programbeteende och parallell samordning, på intra- och interkomponentnivåer. Vårt primära mål med att förbättra komponentinteraktionen är också annorlunda, eftersom vi vill utnyttja en bredare uppsättning interaktionsmekanismer än RMI. Tvärtom utnyttjar Proactive främst parallella och kollektiva RMI-abstractioner (och deras optimeringar t.ex. genom terminer) att utvidga den sekventiella komponentramen till en parallell, distribuerad ram. Högpresterande komponenter för Grid-medvetna applikationer: beräkningsmodell De grundläggande funktioner som krävs för att genomföra en komponentbaserad, högpresterande programmeringsmiljö som riktar sig mot Grid inkluderar de flesta av dem som redan införts i nuvarande tillgängliga komponentmodeller, såsom JavaBeans [28] eller CORBA-komponentmodellen [19]. Dessa funktioner är de som behövs för att genomföra ett distribuerat eller ett parallellt program, det vill säga de är främst ramfunktioner och kommunikation/interaktionsmekanismer. När det gäller ramverksmekanismerna behöver vi naturligtvis praktiska sätt att både skapa/intantiera och ringa komponenter mellan de olika bearbetningselementen i målarkitekturen. Vi behöver också mekanismer och funktioner som erbjuder programmeraren möjligheten att kontrollera det parallella beteendet hos Grid-medveten applikation. I Grid.it programmeringsmiljö vill vi tillhandahålla sådana mekanismer på det mest abstrakta sätt som möjligt. I synnerhet vill vi lämna programmeraren förmågan att koncentrera sig på det funktionella beteendet i applikationen, liksom på de kvalitativa aspekterna av parallellismexploatering. Det vill säga, vi vill befria programmeraren från ansvaret att direkt hantera alla detaljer som rör de kvantitativa aspekterna av parallellismexploatering, och alla de som rör användningen av specifika Grid middleware mekanismer. För att förstå egenskaperna hos en högpresterande komponentmiljö kan det vara användbart att skilja mellan tre konceptuella nivåer: a) beräkningsmodell, b) funktionella och icke-funktionella gränssnitt och c) stödarkitektur för Gridaware-applikationer. I detta avsnitt börjar vi ta itu med den första frågan. De andra diskuteras i på varandra följande avsnitt, där Grid.it approach Komponenter för Gridprogrammering med hög prestanda i Grid.it 5 baserat på ASSIST presenteras. Ur beräkningsmodellens synvinkel föreslår vi att komponenter med hög prestanda studeras och karakteriseras i termer av parallellism, komponentinteraktion, komposition och adaptivitet. Parallellism. I allmänhet, komponenter har en intern parallell struktur (intrakomponent parallellism). Det måste vara möjligt att konfigurera flera olika versioner av samma komponent, alla versioner med samma funktionella gränssnitt. Övergång från en version till en annan kan göras genom omkompilering och/eller omladdning, i de enklaste situationerna (statiska versioner); men vi är också intresserade av parallella komponenter som kan ändra sin interna struktur/beteende vid körning (dynamiska versioner), beroende på funktionella förhållanden (t.ex. bygger på beräkningstillståndet) och/eller på icke-funktionella förhållanden (t.ex. variationer i den uppnådda prestandan). Förutom intrakomponentparallalism är interkomponentparallalismen också grundläggande för högpresterande komponentapplikationer. Komponentinteraktion. De flesta komponentbaserade ramverk tillhandahåller ett sätt att deklarera de offentliga tjänster som tillhandahålls av en komponent och att åberopa en tjänst som tillhandahålls av en (fjärr)komponent. Mekanismen är baserad på användning/tillhandahåller portabstraction. Eftersom detta i huvudsak är en ny utgåva av RPC/RMI paradigm, är detta tillräckligt för att garantera korrekt interaktion mellan komponenter, när de följer denna enkla klient/server modell. Som ett exempel kan man använda sig av dessa mekanismer på ett mycket effektivt sätt för att beräkna jordbruksföretagets uppgifter (dvs. pinsamt parallella). Det behövs dock olika mekanismer för att genomföra andra parallella mönster. Till exempel kan rörledningar inte lätt uttryckas med hjälp av mekanismen för användning/tillhandahåller hamn. Därför antar vi att åtminstone två olika mekanismer genomförs: händelser, det är ett sätt att registrera händelsehanterare och sprida händelser genom komponentnätverket. Denna mekanism finns redan i CCM. Det kan utnyttjas för att genomföra alla typiska asynkrona aktiviteter av parallella beräkningar, såsom övervakning. strömmar, som är ett sätt att ha användning/tillhandahåller portar som implementerar dataflödesliknande kanaler för sekvenser av enkelriktad typad kommunikation, utan att ådra sig prestandapåföljder relaterade till returmeddelanden och synkroniseringar som är typiska för vanlig användning/tillhandahåller hamnmekanism. I allmänhet har en komponent flera inflöden och flera utflöden, som kan användas i ett dataflöde och/eller på ett icke-deterministiskt sätt. En rik uppsättning interaktionsmekanismer, som är typiska för de parallella beräkningsmodellerna, 6 är grundläggande också för att genomföra abstraktioner på högre nivå, såsom komplexa arbetsflödesbaserade PSE. Sammansättning............................................................................................................. För närvarande tillgängliga komponentmodeller gör det möjligt för komponenter att interagera på flera olika sätt. Men bara några få av dem (t.ex. CCM med monteringskonstruktionen) betrakta komponentsammansättning som en primitiv operation. Vi anser att sammansättningen är grundläggande för att göra det möjligt att utveckla och förse användaren med allt mer komplexa parallellismexploateringsmönster som komponenter. Som härlett från våra erfarenheter med algoritmiska skelett, så snart en effektiv mekanism för att utnyttja grundläggande parallellism mönster finns tillgänglig (se [29] [30] ) då behovet av häckning / sammansättning mekanismer uppstår (se [14, 10] ). Genom att utnyttja mönstersammansättningen kan nya parallella mönster programmeras, bäst anpassade till användarens behov. Genom att på ett korrekt sätt begränsa synligheten för användardefinierade, sammansatta parallella mönster kan dessutom olika grad av programmerbarhet hos parallella applikationer presenteras för olika klasser av användare. I vårt sammanhang utgår vi från att utforma en strukturerad, komponentbaserad programmeringsmiljö, och vi vill faktiskt kunna utnyttja sammansättningen av komponenter för att tillhandahålla nya, icke-primitiva komponenter som stöder utvecklingen av Grid-medvetna parallella applikationer. Sammanfattningsvis måste vi definiera komplexa beräkningsstrukturer med hjälp av parallell sammansättning av parallella komponenter. En sammansättning av komponenter kan definieras och återanvändas som en ny komponent i mer komplexa strukturer. Vi antar att en allmän, explicit parallell struktur är inkapslad i en komponent för att skapa en grundläggande parallell komponent. Ett Grid-medvetet program måste kunna hantera heterogenitet och dynamik för att garantera den angivna prestandanivån, trots de olika run-time händelser som kan ändra resurstillgänglighet. En komponent måste kännetecknas av icke-funktionella gränssnitt, relaterade till prestandastyrningen, och av funktioner som gör det möjligt för programmeraren att specificera hur beräkningen anpassar sig vid körning. Dessutom måste dessa funktioner genomföras effektivt på stödnivå. Det finns ett starkt samband mellan de fyra egenskaper som anges ovan. De måste integreras konsekvent i en global strategi, ram eller bättre i en programplaneringsmodell för högpresterande Grid-programmering. I Grid.it använder vi ASSIST som programmeringsmodell som kan uppfylla detta krav.  Vi introducerar ASSIST som härlett från NOW/COW programmeringsmiljön som sättet att beteckna parallella, högpresterande, komponentbaserade, Grid-applikationer. Vi diskuterar också hur redan implementerade ASSIST-funktioner motsvarar kraven från föregående sektionsdiskussion eller kan utnyttjas/förbättras för att matcha sådana krav. ASSIST-program är strukturerade som generiska grafer (identifieras av det generiska nyckelordet), där noder är parallella eller sekventiella moduler och bågar representerar inskrivna strömmar av data/objekt. Ingen begränsning påtvingas formen av grafer, även om "strukturerade" grafer, såsom de typiska för en klassisk skelettmodell, är en anmärkningsvärd klass av fall som har effektiva implementationer. Alla interaktioner som är av intresse för sammansättningen av högpresterande komponenter implementeras enkelt och effektivt med ASSIST-strömmarna. Strömmen är asynkron, men RPC/RMI-interaktioner kan emuleras effektivt. Parallella moduler uttrycks av ett generiskt skelett, som kallas parmod. I detta sammanhang innebär "generiskt" att en parmod är en allmän konstruktion som kan skräddarsys, för varje tillämpning, till specifika fall av klassisk streamparallell och/eller dataparallell skelett, och även till nya former av regelbunden och oregelbunden parallellism. Ett parmod fungerar på flera ingångsströmmar och flera utgångsströmmar. Flera distributions- och insamlingsstrategier tillhandahålls för in- respektive utflöden. Dessutom kan inflöden kontrolleras på ett dataflöde eller på ett icke-deterministiskt sätt. Nondeterminism är viktigt för att modellera flera fall av arbetsflödesstrukturer, samt interaktion av händelser. Den parallella beräkningen uttryckt i ett parmod bryts ned i sekventiella enheter som tilldelas abstrakta exekutorer som kallas virtuella processorer (VP). Parmod kan ha ett uttryckligen definierat internt tillstånd under beräkningstiden. Denna funktion är viktig i många fall, till exempel i icke-deterministiska/reaktiva beräkningar, liksom i många oregelbundna och dynamiska beräkningar. Som i alla modeller för strukturerad parallell programmering kännetecknas parmodkonstruktionen av den viktiga egenskapen att genomförandemodellen är parametrisk. Detta innebär att förverkligandet av run-time-stödet till stor del är oberoende av den faktiska kartläggningen av de virtuella processorer av parmod till de verkliga processorer: detta är sant när det gäller distributionen av funktioner, distributionen av data, och kommunikationen. På samma sätt kännetecknas ett exempel på en parmod av en performancemodell, som är parametrisk med avseende på det faktiska förverkligandet. I den strukturerade parallella programmeringsmiljön har en stor mängd prestandamodeller tillhandahållits för många stream-parallell- och dataparallellskelett. I ASSIST utnyttjar vi denna erfarenhet för att karakterisera beteendet hos en parmod i termer av den prestanda den kan erbjuda enligt den faktiska kartläggningen. I många fall, dvs. Om parameterbeteendet är förutsägbart, är prestandamodellen igenkännbar vid kompileringstidpunkten, medan det i andra, mer dynamiska fall krävs viss notering av programmeraren och/eller kunskapen om systemets eller applikationens tidigare historia för att en prestandamodell ska kunna kopplas till beräkningen, uttryckt i ett parmod. Alla prestandamodeller kan göras tillgängliga, i ett slags Performance Model Repository, för de strategier som genomförs av kompilatorn och för stöd för körtiden. Den "parametriska" funktionen (parametrisk genomförandemodell och parametrisk prestandamodell) är grunden för genomförandet av adaptiva strategier i högpresterande Grid-program. Hur denna fråga behandlas i Grid.it kommer att diskuteras i detalj i Sect. Rådets förordning (EG, Euratom) nr 1605/2002 av den 25 oktober 2000 med budgetförordning för Europeiska gemenskapernas allmänna budget (EGT L 298, 26.11.2000, s. 1). Parmodkonstruktionens "genericitet" ger en intressant möjlighet att uttrycka adaptiva parallella beräkningar per program. Det vill säga, samma parmod (samma samling av virtuella processorer, in- och utgångsströmmar, och tillståndsvariabler) kan uttrycka olika parallellism former enligt värdet av det interna tillståndet eller av ingångsvärdena. Till exempel har dividend- och conquer-implementationen av C4.5-algoritmen [18], i olika faser, modulen har en data-parallell eller en uppgift-farm-liknande beteende, för att optimera den tillgängliga parallellismen i varje fas av beräkningen. På grund av den enorma mängd data som är kopplad till det interna tillståndet är detta flexibla genomförande i ASSIST mycket effektivare än en likvärdig version där dataparallellfasen och den gårdsliknande fasen uttrycks av olika specifika skelett. Med andra ord erbjuder ASSIST en kraftfull funktion för att uttrycka och genomföra adaptiva beräkningar: samma beräkning kan uttryckas enligt flera alternativa strategier. Som vi beskriver i Sect. 1.4.1 Alternativa strategier kan kopplas till värden som genereras av programmet vid körtid, eller de kan väljas enligt de faktiska prestandavärdena med avseende på prestandakontraktet. ASSIST-moduler kan hänvisa till externa objekt under någon fas av beräkningen, dvs. på föremål som inte definieras av ASSIST-samordningsspråket och som följaktligen hänvisas till deras specifika gränssnitt/aPI. Förutom bibliotek och systemfaciliteter (I/O, fil, databaser) är aktuella externa objekt i ASSIST delade variabler, CORBA-fjärrobjekt, lagringsobjekt och dataarkiv. Externa objekt är ytterligare en möjlighet att uttrycka alternativa strategier för adaptiva beräkningar. Komponenter för högperformance Grid Programmering i Grid.it ASSIST ger full interoperabilitet med CORBA: inte bara ett ASSIST-program kan fungera som en klient till en CORBA-server, men, mest påtagligt, ett ASSIST-program kan automatiskt kompileras som ett CORBA-objekt med RMI-liknande synkrona anrop eller med stream-liknande asynkron data passerar. Det har visats [31] att de allmänna omkostnader som införts genom programomvandlingen definitivt är godtagbara för många parallella tillämpningar. Denna erfarenhet visar att interoperabilitetsfunktioner effektivt kan slås samman med ASSIST-modellen för att utforma tillämpningar som sammansättning av komponenter, varav en del så småningom kommer att vara parallella. Vi räknade med att färdplanen omvandlar ASSIST-program/moduler till komponenter enligt följande: först tillåter vi att ASSIST-moduler inkapslas som komponenter i befintliga, välkända komponentramar; sedan inkluderar vi i komponentramen alla mekanismer som behövs för att implementera högpresterande applikationer; så småningom integrerar vi ramverket på ett sådant sätt att parallella ASSIST-komponenter och befintliga äldre komponenter kan samexistera i en högpresterande parallell Grid-applikation. Efter denna färdplan kommer vår nuvarande forskning [31] att producera nästa version av ASSIST (2.0), där ett ASSIST-program, uttryckt antingen som en enda ASSIST-modul eller som en graf av parallella eller sekventiella moduler, betraktas som en högpresterande komponent som: a) kan komponeras med hjälp av standardkomponentramar, förutom de infödda ASSIST-mekanismerna, b) exportera icke-funktionella gränssnitt och funktioner automatiskt stöd till adaptiva applikationer, som kommer att diskuteras i nästa avsnitt. W.r.t. Ordförande Standardramar, vi experimenterar flera lösningar baserade på Web Services (WS) och CORBA Component Model (CCM). Genomförandestrategin liknar den som redan antagits för CORBA 2 interoperabilitet, dvs. Kompilatorn genererar bro-ASSIST-moduler som stöder de olika typer av komponentportar som är relaterade till de funktionella gränssnitten samt portar som är relaterade till de icke-funktionella gränssnitten. Ur kompositionssynpunkt erbjuder den ASSIST-baserade metoden följande funktioner: i) En komponent (antingen WS eller CCM) inkapslar en ASSIST- (under)graf, ii) komponenter kan komponeras enligt ASSIST-mekanismer eller enligt mekanismerna i den standardkomponentram som antagits. I den första lösningen i punkt ii) består två eller flera komponenter, som är ASSIST-grafer, av den generiska konstruktionen, som beskriver strukturen på den resulterande ASSIST-grafen i termer av komponentmoduler och strömmar (och eventuellt externa objekt). Det komponerade ASSIST-programmet kompileras automatiskt 10 till en standardkomponent. Denna lösning kan användas när komponenterna är alla (nya eller befintliga) ASSIST-program vars ASSIST källkod är tillgänglig. I den andra lösningen i punkt ii använder programmeraren interaktionsmekanismerna i komponentramen (hamnar) för att komponera två eller flera komponenter. Detta tillvägagångssätt används vanligtvis när en eller flera av delarna i ansökan är befintliga (legacy) komponenter som inte har utformats i ASSIST. Enligt vad som sagts i tidigare avsnitt måste flera kritiska punkter tas upp när vi tar itu med anpassningskontroll i Grid-medvetna applikationer. I synnerhet måste icke-funktionella gränssnitt och omkonfigureringsstrategi och tillämpningshantering beaktas. I detta avsnitt kommer vi att diskutera hur dessa funktioner har beaktats vid utformningen av vår prototyp av den komponentbaserade parallella programmeringsmiljön ASSIST 2.0. Vi antar att en Grid-medveten applikation är en sammansättning av högpresterande komponenter. Det vill säga, vi begränsar oss till det fall där inga äldre, icke-parallella komponenter används i ansökan. Låt oss undersöka i vilket fall sådana komponenter är ASSIST-komponenter (grafer över sekventiella moduler och/eller parmoder), sammansatta med hjälp av den allmänna grafkonstruktionen. Förutom funktionella gränssnitt, som genereras automatiskt vid kompileringstidpunkten (ut ur ASSIST-koden), kännetecknas varje komponent av icke-funktionella gränssnitt. De uttrycks som anteckningar i en riktig formalism, som översätts av kompilatorn till en run-time representation baserad på XML. Sådana anmärkningar förmedlar information om fullgörandekontrakt, omkonfigureringsstrategi och tilldelningsbegränsningar. Mallen för en ASSIST-komponent utgår således från det formulär som visas i bild. 1................................................................ Prestandakontrakt. Många parametrar kan användas för att ange den prestandanivå som krävs för ansökan. I detta dokument hänvisar vi till processbandbredden (tjänstetid) i strömbaserade beräkningar och/eller till färdigställandetiden, som är betydande även för icke-strömsberäkningar. Följande diskussion är dock i stort sett oberoende av de specifika resultatparametrar som antagits. Prestandakontraktet kan specificeras för hela tillämpningen och/eller för varje enskild komponent. Om den erforderliga prestandan för varje komponent anges, kan den erforderliga prestandan för hela applikationen härledas vid sammanställningstidpunkten med hjälp av kunskapen i grafen. Till exempel kan metoden för köande nätverk användas, både när det gäller asynkron ström och när det gäller RMI-liknande interaktion. Om endast hela applikationens prestanda specificeras är det fortfarande möjligt att härleda grov information vid kompilering och körtid om prestandan hos de enskilda komponenterna, med hjälp av profileringsberäkningar och, viktigast av allt, med beaktande av att en ASSIST-komponent är en sammansättning av ASSIST-moduler för var och en av dem där en prestandamodell kan vara känd på grundval av ett prestandamodellarkiv. Ytterligare information om kommunikationsbandbredd och latens måste uppskattas. Naturligtvis är denna informations tillförlitlighet kanske inte särskilt exakt. Det är dock just på grund av dessa och andra felaktigheter, som ingår i Grid-plattformar, som vi behöver stöd för adaptiva Gridaware-tillämpningar. Omkonfigureringsstrategi. För varje komponent anger applikationsdesignern på vilket sätt komponenten ska omstruktureras i körtid om och när fullgörandekontraktet råkar inte längre vara uppfyllt. Strategin för omkonfigurering uttrycks i princip i ASSIST med tillägget av några kommentarer. I Sect. 1.3.1 Vi såg att ASSIST gör det möjligt för programmeraren att uttrycka alternativa strategier (t.ex. olika parametriska former av parallellism) direkt i samma program, när deras aktivering beror på värdena för vissa programvariabler (t.ex. Det interna tillståndet i en parmod). Dessutom kan programmeraren ange att alternativa strategier måste aktiveras när prestationskontraktet överträds. Låt oss begrunda följande exempel (Fig. 2).................................................................. 12 a) Komponent C1 är ett gränssnitt mot en Grid-minneshierarki, som virtualiserar och omvandlar datamängder tillgängliga på Grid till två strömmar av objekt, den första (vars element har en elementär typ) skickas till C2, och den andra (vars element har arraytyp) skickas till C3. C1 kan vara en befintlig komponent tillgänglig på rutnätet, förmedlad av ett ASSIST-program. b) C2 är en parallell komponent som inkapslar ett ASSIST-program. Omkonfigurationsstrategin för C2 anger att "som standard" C2 är en sekventiell modul som utför en viss funktion F. När den nuvarande prestandanivån måste justeras omvandlas C2 till en jordbruksberäkning vars arbetstagare utför samma funktion F. Det faktiska antalet arbetstagare kommer att fastställas parametriskt vid körtiden, enligt prestandamodellen och den nuvarande tillgången på resurser. c) C3 är en parallell komponent som inkapslar ett ASSIST-dataparallellprogram som arbetar på varje strömelement av arraytyp. Liksom i fallet C2 anger strategin för C3 att dess parallellismgrad (dvs. Den mängd verkliga processorer som den virtuella processorn är kartlagd på) kan vid behov ändras. d) C4 är en parallell komponent som inkapslar ett ASSIST-program som, som standard, är en sekventiell modul, men den kan omstruktureras till ett parmod som fungerar på inmatningsströmmen enligt en dataparallell eller en uppgiftsgårdsstil, beroende på värdena för parmod-tillståndet och själva inmatningsvärdena. Därför tillämpas i detta fall anpassningsprincipen på två nivåer: på programnivå och på stödnivå för körtid. e) C5 är en parallell komponent som inkapslar ett ASSIST-program som arbetar icke-deterministiskt på de ingångsvärden som erhålls från C3 eller C4 och omvandlar de två strömmarna till en datamängd. Låt oss anta att vissa övervakningsaktiviteter vid en viss tidpunkt signalerar att C2 håller på att bli en flaskhals och att detta leder till en betydande försämring av hela tillämpningens prestanda. C2 kan omvandlas till en version med lämplig parallellismgrad. I detta fall kan andra komponenter behöva omstruktureras (t.ex. C4,C5) för att garantera prestandanivån. Som tidigare nämnts är detta möjligt enligt en global strategi baserad på kunskap om applikationsstrukturen. Vid omstruktureringen av dataparallellkomponenterna (C3) måste strategin också tillämpas på omfördelningen av de uppgifter som utgör det interna tillståndet för en parmod. ASSIST-komponenter
Inom ramen för projektet kommer det att undersökas en "innovativ programmeringsmiljö som i) stöder programmerarna i all verksamhet som rör parallellismexploatering, genom att tillhandahålla någon form av strukturerade primitiver för parallellismexploatering, ii) gör det möjligt att uppnå full interoperabilitet med befintlig programvara, både parallell och sekventiell, antingen tillgänglig i käll- eller objektform, iii) stödja och genomdriva återanvändning av redan utvecklad kod i andra tillämpningar" REF.
Components for high performance Grid programming in Grid.it
{'venue': 'Proc. of the Workshop on Component Models and Systems for Grid Applications, CoreGRID series', 'journal': None, 'mag_field_of_study': ['Computer Science']}