P-GRADE: Párhuzamos
programok fejlesztése és
futtatása
szuperszámítógépeken, klasztereken és Grid rendszereken[1]
Kacsuk Péter
MTA SZTAKI
kacsuk@sztaki.hu
www.lpds.sztaki.hu
Absztrakt
A SZTAKI PERL laboratóriumában több év óta
folyik egy olyan párhuzamos program fejlesztő rendszer (P-GRADE) tervezése
és fejlesztése, amely magas szintű grafikus eszközeivel a párhuzamos
programok fejlesztésének minden lépését (szerkesztés, fordítás, hibakeresés,
teljesítmény monitorozás és vizualizáció, leképezés szuperszámítógépek és
klaszterek processzoraira) támogatja. A legújabb kutatási eredmények a P-GRADE
futtató rendszer lehetőségeit bővítették számos olyan módszerrel
(ellenőrző-pontok automatikus készítése, automatikus
terhelés-kiegyenlítés, hibatűrő végrehajtás), amelyek révén a P-GRADE
alatt kifejlesztett párhuzamos programok végrehajtásának hatékonysága
jelentős mértékben növelhetők mind a szuperszámítógépeken és
klaszterekben, mind az újabban egyre jobban terjedő Grid rendszerekben.
1. Bevezetés
A P-GRADE rendszert eredetileg párhuzamos
programok fejlesztésének támogatására hozta létre a SZTAKI Párhuzamos és
Elosztott Rendszerek Laboratóriuma. A Párhuzamos rendszerek fejlesztése
lényegesen nehezebb és összetettebb feladat, mint a szekvenciális programoké, ezért
vált szükségessé egy olyan grafikus környezet kidolgozása, melyben nem
informatikus képzettségű végfelhasználók (pl. meteorológusok, kémikusok,
stb.) is képesek szuperszámítógépeken és klasztereken futtatható programok
kifejlesztésére. A P-GRADE rendszer eredeti formájában grafikus nyelvet,
grafikus editort, előfordítót, PVM könyvtár támogatást, elosztott grafikus
hibakereső rendszert, monitorozó és vizualizációs rendszert biztosít a
felhasználóknak [1], [2]. A
programfejlesztés interaktív módon történik az 1. ábrán látható fejlesztési
ciklusnak megfelelően. A szerkesztés, fordítás és hibakeresés végrehajtása
egyprocesszoros környezetben ajánlott. A teljesítményméréseket azonban már
sokprocesszoros környezetben célszerű végrehajtani. Ehhez először is
meg kell határozni a processzek leképezését a processzortérbe, majd a
párhuzamos végrehajtás során folyamatosan mérhetjük az egyes események (pl.
üzenetküldés processzek között) idejét és végül ezeket vizualizálhatjuk. Ha a
teljesítmény nem kielégítő, akkor vagy az eredeti programot kell
módosítani, vagy sok esetben elegendő a processzor leképezésen
változtatni.
A fent leírt programfejlesztés
eredményeképpen létrejön egy párhuzamos program, aminek végrehajtási ideje akár
több napot is igénybe vehet. Egy ilyen program végrehajtására a következő
lehetőségek vannak:
A P-GRADE továbbfejlesztésében a fő cél
az elmúlt két évben a fenti végrehajtási módok támogatása és minél hatékonyabbá
tétele volt. A továbbiakban áttekintjük azokat a P-GRADE kiterjesztéseket, amik
a fenti végrehajtási módokat támogatják.
1. ábra Fejlesztési ciklus
P-GRADE interaktív módban
2. P-GRADE program
végrehajtása dedikált klaszteren
Ha a felhasználó olyan szerencsés, hogy saját
klaszterrel rendelkezik, amit a kifejlesztett párhuzamos program végrehajtására
dedikálhat, akkor a program végrehajtása során a következő
lehetőségek segítik a minél hatékonyabb végrehajtást:
2.1 Automatikus
terhelés-kiegyenlítés
Sok esetben egy párhuzamos program olyan
komplex, hogy viselkedési jellemzői futás közben dinamikusan változnak,
azaz bizonyos processzek a végrehajtás bizonyos fázisaiban aktívabbak máskor
passzívabbak. Ez azt jelenti, hogy a kezdeti processz-gép leképezés a futás
során nem biztosítja a processzorok egyenletes terheltségét, ami hosszú távon a
párhuzamos rendszer hatékonyságának csökkenéséhez és a párhuzamos program
végrehajtási idejének jelentős növekedéséhez vezet. Ennek a jelenségnek a
kiküszöbölése egy több napon, de akárcsak több órán keresztül futó program
esetén is komoly megtakarítást jelent processzoridőben és teljesítményben.
A probléma az automatikus
terhelés-kiegyenlítés módszerével oldható meg. Az ehhez szükséges eszközöket és
ezek kapcsolódását a P-GRADE rendszerhez mutatja a 2. ábra. A
terhelés-kiegyenlítő modul három fő részből áll:
A Monitor modul bizonyos beállítható
periodicitással (pl. 5 percenként) méri a dedikált klaszter processzorainak
terheltségét és a mérés eredményét átadja a Döntési modulnak. Ez a mért értékek
alapján megvizsgálja, hogy a klaszter processzorainak kihasználtsága mennyire
volt egyenletes a mérési periódusban. Ha a terhelési szintek különbsége egy
bizonyos küszöbértéket meghalad, akkor a szimulált-hűtés algoritmust
felhasználva eldönti, hogy a processzek átcsoportosításával elérhető-e
egyenletesebb processzor kihasználtság. Ha ez nem lehetséges, akkor engedélyezi
a párhuzamos program futásának folytatását. Ha az átrendezés eredményes lehet,
akkor összeállítja az átcsoportosítandó processzek listáját megadva régi és új
pozíciójukat a processzortérben. Ezután elküldi ezt a listát a Migrációs
modulnak. Ennek a feladata a processzek tényleges átrendezésének a
megvalósítása. Az átrendezés feltétele, hogy a mérési periódus végén a
processzek állapotáról egy olyan lementés, un. ellenőrző-pont
készüljön, melyből a processzek aktuális állapota az esetleges átrendezés
után visszaállítható és a párhuzamos program működése a megszakítási
ponttól folytatható [3]. A Migrációs modul tehát a mérési periódus végén minden
processzre elkészíti az ellenőrző-pontot és vár a Döntési modul
döntésére. Ha ez nem kér átrendezést, akkor a Migrációs modul engedélyezi a
processzek tovább futtatását az aktuálisan hozzájuk rendelt processzoron. Ha az
átrendezés szükséges, akkor az átrendezési listában szereplő minden egyes
processz számára a processzhez tartozó ellenőrző-pont alapján
telepíti a processzt az átrendezési listán szereplő célgépre.
Mérésekkel igazolható, hogy az automatikus terhelés-kiegyenlítés
jelentős sebességnövekedéshez vezet dinamikusan változó terhelést
eredményező programok esetén, de olyankor is, ha a felhasználó helytelen
kezdeti processz-gép leképezést alkalmaz. A technikai részletek iránt
érdeklődő olvasok megtalálhatják az automatikus
terhelés-kiegyenlítő modul részletes leírását [4]-ban.
2. ábra A P-GRADE rendszer
kiterjesztése
az automatikus
terhelés-kiegyenlítő (load-balancer) modullal
2.2 Automatikus
hibatűrés
A klaszterek általában kevésbé megbízhatóak,
mint egy szuperszámítógép, ahol a gyártók gyakorlatilag 100%-os rendelkezésre
állást garantálnak. (Többek között ez az egyik oka annak, hogy a
szuperszámítógépek legalább egy nagyságrenddel drágábbak, mint az azonos
teljesítményű dedikált klaszterek.) Ugyanakkor, egy több napig futó
program esetén igen bosszantó, és emellett az üzleti életben komoly anyagi
veszteséget okozó lehet, ha a program néhány nap futás után azért áll le, mert
a dedikált klaszter valamelyik gépe meghibásodott. Ennek a problémának a megoldását
szintén biztosítani tudja a P-GRADE rendszer legújabb verziója.
A megoldás alapja ugyanúgy a
ellenőrző-pont készítés, mint az automatikus terhelés kiegyenlítés
esetén. A megoldás lényegében visszavezethető a fent leírt automatikus
terhelés-kiegyenlítő modulra. Ha valamely gép működése leáll, azt a
Monitor modul érzékeli és a mérési periódus végén ezt az információt továbbítja
a Döntési modulnak a többi mért adattal együtt. A Döntési modul ebben a
helyzetben kiértékeli, hogy a még működőképes gépek terheltsége
alapján hová célszerű átrendezni azokat a processzeket, amelyek a
meghibásodott gépen futottak. Ezután az így összeállított átrendezési listát
elküldi a Migrációs modulnak, amely lényegében ugyanúgy működik, mint az
automatikus terhelés kiegyenlítés esetén azzal a különbséggel, hogy nem az
aktuális mérési periódus végén készített ellenőrző-pontot használja
fel az átrendezéshez, hanem az eggyel korábbi mérési periódus végén készült
ellenőrző-pontot. Ennek nyilvánvaló oka, hogy az utolsó
ellenőrző-pont nem tartalmazza azokat a processzeket, amik a
meghibásodott gépen futottak. Ebből az is következik, hogy egy
ellenőrző-pontot csak az utána következő mérési periódus után
lehet törölni.
A fenti megoldás biztosítja, hogy a dedikált
klaszter egy (vagy akár több) gépének meghibásodása esetén nem kell az egész
programot újrakezdeni, mindössze az utolsó mérési periódusbeli futást kell
megismételni és a program futhat tovább a csökkentett méretű klaszteren.
A fenti automatikus terhelés kiegyenlítés és
automatikus hibatűrés tulajdonságokkal a "Klaszter programozási
technológia és alkalmazása a meteorológiában" c. IKTA-3 projekt keretében
terjesztettük ki a P-GRADE rendszert.
2.3 Monitorozás és
vizualizáció
A P-GRADE rendszer lehetővé teszi egy
hosszan, akár több napon keresztül futó program monitorozását és
vizualizációját is. Itt alapvetően két lehetőség közül lehet
választani:
Az első esetben a PROVE
processz-idő ablak "Collect" menűgombjával lehet a
vizualizációt indítani. Hatására a GRM fő monitora összegyűjti a lokális
monitoroktól az összes eddigi trace információt, majd az így összeállított
trace állományt átadja a PROVE vizualizációs modulnak. Ez feldolgozza a
begyűjtött trace információt és a 3.a ábrán látható processz-idő
ablakban kirajzolja a processzek állapotátmeneteit és kommunikációit. Az ábrán
a vízszintes tengely a végrehajtási időt reprezentálja, a függőleges
tengely pedig a processzeket. Minden processzhez tartozik egy vízszintes vonal,
melyben a különböző színek különböző állapotokat reprezentálnak (fekete
= számítások, zöld = üzenetre várakozás, szürke = üzenet elküldésre várakozás).
Két processz-vonalat összekötő nyíl reprezentálja a két processz közötti
kommunikációt.
a.
PROVE processz-idő ablaka b.
PROVE Observ Dialog ablaka
3. ábra PROVE ablakok
A processz-idő ablak rendkívül hasznos
egy párhuzamos program viselkedésének megértésében és ezért nagy szerepet
játszik mind a párhuzamos programok fejlesztésében, mind futásuk
ellenőrzésében. Egy jól belőtt párhuzamos programot teljesen
mértékben magára lehet hagyni, de néhány óránként hasznos (és megnyugtató)
lehet látni, hogy a program valóban úgy viselkedik, ahogy ezt elvárjuk
tőle. Erre ad lehetőséget a PROVE "Collect" funkciója és a
periodikus vizualizáció is, amit a 3.b ábrán látható Observ Dialog ablakkal
lehet indítani. Itt lehet definiálni a trace információ begyűjtésének és
vizulizációjának periódus idejét. Emellett a memória-felhasználás ésszerű
mértéken tartása érdekében magadható, hogy mekkora az az időtartomány,
amit vizualizálni akarunk. A PROVE modul csak azokat az adatokat tartja meg a
memóriában és vizualizálja, amelyek a megadott időtartományba esnek. Így
például a 3.b ábra beállítása azt jelenti, hogy 10 másodpercenként gyűjt
adatot a GRM és vizualizál a PROVE, úgy hogy mindig az utolsó 1 perc eseményeit
mutatja a processz-idő ablakban.
3. Végrehajtás
szuperszámítógépen, vagy nem-dedikált klaszteren
Sok esetben a végrehajtásra nem dedikált
klasztert használnak, hanem olyan szuperszámítógépet, vagy klasztert, amit több
felhasználó között osztanak meg. Erre példa a NIIFI által működtetett Sun
szuperszámítógép, amely az ország bármely kutatója számára nyújt szolgáltatást.
Az ilyen sok-felhasználós rendszereken általában egy lokális job-kezelő
rendszert alkalmaznak. A felhasználók jobként helyezik el programjukat a
lokális job-kezelő várakozási sorában és a job-kezelő feladata, hogy
a várakozó jobok és a rendelkezésre álló processzorok (gépek) összerendelését
különböző, szabályozható stratégiák alapján elvégezze.
Tipikus lokális job-kezelő rendszerek a
Sun Grid Engine (SGE), a Condor, a PBS és a LSF. Az SGE és a Condor nem csak
egy szuperszámítógépen, vagy klaszteren belül, hanem több ilyen erőforrás
között is képes elosztani a jobokat. Ezek tehát lehetőséget adnak arra is,
hogy egy Gridhez hasonló rendszerben gondoskodjanak a job-kezelésről. Erre
példa a magyar Klaszter Grid [5], ahol a Condort használjuk jobok elosztására a
Gridet alkotó összes klaszter között.
Annak érdekében, hogy a P-GRADE-ben
kifejlesztett programokat kényelmesen lehessen jobként futtatni
szuperszámítógépeken, klaszterekben vagy a Gridben, kifejlesztettük a P-GRADE
job-üzemmódját. Ez jelenleg a Condor [6] job-kezelőhöz van kötve, de se
elvi, se gyakorlati akadálya nincs annak, hogy az SGE, vagy más
job-kezelőkhöz is hozzákössük. A P-GRADE job-üzemmódjában alkalmazható
funkciókat mutatja a 4. ábra. A szerkesztés, fordítás, monitorozás és
vizualizálás funkciók a felhasználó szempontjából teljesen megegyeznek az
interaktív módban és a job-módban. A leképezés funkció azonban itt kissé mást
takar, mint az interaktív üzemmódban, ahol egy processzt konkrét géphez kell
hozzárendelni.
4. ábra P-GRADE job-mód
funkciók
Job-módban a Condorhoz hasonlóan
erőforrás osztályokat lehet definiálni és a leképezés során azt kell
megadni, hogy az egyes processzek mely osztályokon legyenek végrehajthatók. Az
erőforrás osztályok definiálása érdekében kiterjesztettük az interaktív
módban használt leképezés (mapping) ablakot, amint azt a 5. ábra legalsó ablaka
mutatja. Itt három erőforrásosztályt definiáltunk. Mindegyik egy klaszter
(SZTAKI: sztaki.hpcc.hu, Wisconsin Egyetem: cs.wisc.edu és Westminster Egyetem:
cluster.cpc.wmin.ac.uk klasztere) és mindegyikből minimum 1, maximum 5
gépet kérünk a program párhuzamos végrehajtásához. Ezek az
erőforrásosztályok a 0, 1 és 2 osztályazonosítókkal vannak ellátva és
ezekkel lehet rájuk hivatkozni a mapping ablak "List of host"
részében, ill. a "Process List - Host" részében. Az ábra mutatja,
hogy a LowerLeft, MiddleLeft és UpperLeft processzek a 0 azonosítójú osztályhoz
vannak rendelve, azaz a SZTAKI klaszterén kell futniuk.
Az már a Condor feladata, hogy a program
futtatásához gondoskodjon az előírt gépeknek a lefoglalásáról és a
megfelelő processzeknek ezen gépekre történő kiosztásáról. Annak
érdekében, hogy a P-GRADE programot Condor jobként lehessen futtatni az
"Execute" menüt kibővítettük a Submit job, Remove job, Detach
job, Attach job funkciókkal. Ezek mind új funkciók, amik egyrészt a jobok
indítását, leállítását segítik, másrészt lehetővé teszik, hogy miközben
egy job fut valahol, a P-GRADE grafikus környezet más program fejlesztésére,
vagy jobként történő indítására is felhasználható legyen (Detach job). Ha
később szükséges a job visszakötése a P-GRADE-hez, akkor ezt az "Attach
job" paranccsal lehet megtenni. Ha a P-GRADE és a job össze van kötve, a
job monitorozása és vizualizálása ugyanúgy végezhető, mint az interaktív
üzemmódban.
5. ábra P-GRADE
kiterjesztése a Condor job-mód támogatására
A P-GRADE Condor alapú job-üzemmódja a magyar
Klaszter Gridben is jól használható, ha a P-GRADE telepítve van a Klaszter Grid
belépési gépén. Ez esetben a P-GRADE alól indított job a Klaszter Grid bármely
klaszterén, sőt egyszerre több klaszterén párhuzamosan is futtatható. A
P-GRADE Condor alapú job-üzemmódját a Condort fejlesztő csoporttal közösen
fejlesztettük ki és működését demonstráltuk a berlini CCGrid'2002
konferencia Grid Demo workshopján. Ebben a demonstrációban az 5. ábrán megadott
3 klaszteren párhuzamosan futott az 5. ábrán látható program.
4. Végrehajtás a Gridben
Egy párhuzamos program végrehajtására a
harmadik lehetőség a Gridben történő végrehajtás. Ilyenkor nem
ismerjük előre azt a szuperszámítógépet, vagy klasztert, amit a
végrehajtásra akarunk használni, csak annyit specifikálunk, hogy az
erőforrásnak milyen paraméterekkel kell rendelkeznie (processzorok száma,
memória mérete, operációs rendszer típusa és verziója, stb.). Az már a Grid
job-kezelő feladata, hogy a Grid információs rendszer segítségével
találjon számunkra megfelelő erőforrást és utána gondoskodjon a job
(beleértve a végrehajtható kódot és a szükséges állományokat) elküldéséről
a kiválasztott erőforrásra. Sajnos ilyen Grid job-kezelőt nem
találtunk és ezért fejlesztettük ki a PERL-GRID Grid job-kezelőt, amely
egy általános Grid job-kezelő legalapvetőbb feladatait képes
megoldani:
A PERL-GRID használata olyankor fontos, ha a
P-GRADE rendszert futtató kliens gép nem tagja egy Condor-klaszternek, vagy a
P-GRADE alól indított jobot egy másik Condor-klaszteren kívánjuk futtatni,
amely nem áll "flocking" kapcsolatban a kliens gépet tartalmazó
Condor-klaszterrel. Egy ilyen Grid rendszert demonstráltunk a piliscsabai 5. EU
DataGrid konferencián (6. ábra). Az alkalmazási program az OMSZ MEANDER
ultra-rövidtávú előrejelző programcsomagja volt, amit a
"Klaszter programozási technológia és alkalmazása a meteorológiában"
c. IKTA-3 projekt keretében az OMSZ és SZTAKI munkatársai közösen
párhuzamosítottak P-GRADE alatt [7] (7. ábra). A demo során a piliscsabai Szent
István Egyetem területéről egy notebookon futó P-GRADE rendszer alól
indítottuk a jobot PERL-GRID üzemmódban. A PERL-GRID gondoskodott a job
átszállításáról a SZTAKI klaszterére. Ott az OMSZ meteorológiai adatbázis
leolvasása után a PERL-GRID átadta a jobot a lokális Condor job-kezelőnek,
amely gondoskodott a program párhuzamos végrehajtásáról. (40 processzor vett
részt a futtatásban.) A párhuzamos végrehajtás során a GRM monitor
gyűjtötte a trace információt és a 2.3 fejezetben leírt módon a
felhasználó kérésére a PROVE on-line vizualizációt (8. ábra) biztosított a
P-GRADE-et tartalmazó notebookon. A program lefutása után a PERL-GRID
gondoskodott a netCDF eredmény állomány elküldéséről Piliscsabára, ahol
egy másik notebookon történt meg a meteorológiai térkép kirajzolása az OMSZ
HAWK programcsomagja segítségével.
6. ábra P-GRADE job-mód és
PERL-GRID együttműködésének demonstrációja
5. Összefoglalás és
továbbfejlesztések
A P-GRADE egy kényelmes programfejlesztő
és futtató környezetet biztosít párhuzamos programok fejlesztésére és
futtatására szuperszámítógépeken, klasztereken és a Gridben. A program
futtatása mind interaktív, mind job-módban lehetséges. A programok monitorozása
és a végrehajtás vizualizálása mindkét üzemmódban támogatott függetlenül attól,
hogy a végrehajtó rendszer szuperszámítógép, klaszter vagy egy Grid.
Megoldottuk a P-GRADE-ben fejlesztett és
futtatott párhuzamos programok ellenőrző-pont készítését és ennek
alapján az ilyen programok hibatűrő módon képesek futni a szuperszámítógépeken,
klasztereken és a Gridben. Az ellenőrző-pont készítése a magyar
Klaszter Grid szakaszos működési körülményei között is megengedi
tetszőlegesen hosszan futó programok végrehajtását. Ha egy program nem
fejeződik be az éjszakai Grid üzemmód alatt, akkor a nappali labor-módra
történő átkapcsolás előtt a párhuzamos program
ellenőrző-pontját a rendszer automatikusan elkészíti és a
következő éjszakai Grid üzemmódba kapcsoláskor az elmentett
ellenőrző-ponttól a párhuzamos program folytatható.
A P-GRADE fent leírt job-módja és Condorhoz
ill. PERL-GRID-hez kötése a "Magyar Szuperszámítógép Grid" c. IKTA-4
projekt keretében történt. Ugyancsak e projekt keretében dolgozunk egy olyan
jobflow (workflow) réteg kidolgozásán, amely lehetővé teszi a P-GRADE
rendszer kiterjesztését a Gridben párhuzamosan működő és egymással
együttműködő job-rendszerek definiálására és azok Gridben
történő futtatására.
7. ábra A MEANDER program
párhuzamos verziója
8. ábra A MEANDER program
végrehajtásának processz-idő diagramja
A P-GRADE a teljes magyar akadémiai közösség
számára elérhető az NIIFI által üzemeltetett Sun E10000
szuperszámítógépen. A P-GRADE telepítve van az OMSZ SGI Origin 2000
szuperszámítógépén, ahol a korábban említett MEANDER párhuzamosítása történt a
P-GRADE segítségével. E mellett intenzíven használják az oktatásban és
kutatásban a varsói Lengyel-Japán Műszaki Főiskola Hitachi SR2201 szuperszámítógépén.
Jelenleg folyik a P-GRADE installálása a Readingi Egyetem IBM SP2
szuperszámítógépére, ahol első sorban nagy numerikus feladatok megoldására
kívánják használni.
A P-GRADE elsősorban Linux klaszterekre
van telepítve (SZTAKI, Miskolci Egyetem, ELTE, Westminster Egyetem, Readingi
Egyetem, stb.), de léteznek munkaállomás klaszter installálások is (SZTAKI,
Bécsi Egyetem, Athéni Egyetem, stb.). A klaszteren futó P-GRADE alkalmazások
között kell megemlíteni a Westminster Egyetemen kifejlesztett városi forgalom
szimulátort és a Readingi Egyetemen fejlesztés alatt álló monte-carlo
szimulációs alkalmazásokat.
A P-GRADE Grid adaptációja most van folyamatban.
Jelenleg dolgozunk azon, hogy a Magyar Klaszter Gridben és a Magyar
Szuperszámítógép Gridben is használható legyen [8]. Ez utóbbiban a BME NTI-ben
kifejlesztett NAIMAN nevű
programcsomag párhuzamosítását végezzük P-GRADE-ben. Ennek célja a
szcintillátor-detektorok gamma-forrásokra adott válaszát modellezni. A "Kémiai
Grid kialakítása és alkalmazása a légszennyezés rövid és hosszú távú
előrejelzésében" c. IKTA-5 projektben az
elemi reakciók kinetikájának és dinamikájának modellezésére, reakció-diffúzió
rendszerek modellezésére, kémiai hullámok gerjeszthető közegben
történő terjedésének modellezésére és Magyarország
levegőszennyezettségének számítására használják a P-GRADE-et. Az EU D23-as
COST alprogramhoz tartozó SIMBEX projekt célja egy európai kémikus Grid
rendszer létrehozása. A projektnek 5 kémikus és 5 informatikus partner tagja
van Európa hat országából. A SIMBEX konzorcium elfogadta, hogy a kémiai alkalmazások
párhuzamosításának hivatalos eszköze a P-GRADE legyen. A "JGrid: Jini alapú Grid
számítási rendszer és integrált grafikus alkalmazás fejlesztő
környezet" IKTA-5 projekt célja többek között, hogy a P-GRADE az eddigi C,
C++ és Fortran támogatás mellett képes legyen Java programok fejlesztését is
támogatni.
A P-GRADE 8.2 verzió (amely az interaktív
üzemmódot támogatja) bináris kódja, kézikönyve és a mintaprogramok
gyűjteménye ingyenesen letölthető a www.lpds.sztaki.hu web oldalról.
Igény esetén bárkinek szívesen rendezünk P-GRADE tanfolyamokat. Hamarosan
tervezzük a 8.4 verzió kiadását, amely már magában fogja tartalmazni a job-mód
támogatását is.
Hivatkozások
[1] Kacsuk P.: Visual Parallel Programming on
SGI Machines, Meghívott előadás, SGI Users’ Conference kiadványa, Krakow,
Poland, pp. 37-56, 2000
[2] P-GRADE User's Manual: www.lpds.sztaki.hu
[3] Kovács J. és Kacsuk P.: Server Based
Migration of Parallel Applications, DAPSYS'2002 workshop kiadványa, Linz, pp.
30-37, 2002
[4] Tóth M. L., Podhorszki N. és Kacsuk P.:
Load Balancing for P‑GRADE Parallel Applications, DAPSYS'2002 workshop
kiadványa, Linz, pp. 12-20, 2002
[5] Stefán P. A magyar ClusterGRID projekt,
Networkshop'2003, Pécs
[6] Condor User's Manual:
http://www.cs.wisc.edu/condor/manual
[7] Lovas R., Kacsuk P. Horváth Á. és Horányi
A.: Application of P‑GRADE Development Environment in Meteorology,
DAPSYS'2002 workshop kiadványa, Linz, pp. 109-116, 2002
[8] Kacsuk P.: A magyar Grid projektek
áttekintése, Networkshop'2003, Pécs
[1] A cikkben leírt kutatásokat a következő projektek
támogatták: OTKA T032226, OMFB-02307/2000, IKTA-00075/2001 és EU
DataGrid IST-2000-25182