(11) Lajstromszám: E (13) T2 EURÓPAI SZABADALOM SZÖVEGÉNEK FORDÍTÁSA

Átírás

1 !HU T2! (19) HU (11) Lajstromszám: E (13) T2 MAGYAR KÖZTÁRSASÁG Magyar Szabadalmi Hivatal EURÓPAI SZABADALOM SZÖVEGÉNEK FORDÍTÁSA (21) Magyar ügyszám: E (22) A bejelentés napja: (96) Az európai bejelentés bejelentési száma: EP (97) Az európai bejelentés közzétételi adatai: EP A (97) Az európai szabadalom megadásának meghirdetési adatai: EP B (1) Int. Cl.: G06F 9/4 (06.01) (87) A nemzetközi közzétételi adatok: WO PCT/FR 0/ () Elsõbbségi adatok: FR (72) Feltalálók: BODIN, François, F-3700 Rennes (FR); JALBY, William, F Mareil sur Mauldre (FR); LE PASTEUR, Xavier, F-923 Bourg La Reine (FR); LEMUET, Christophe, F-783 Levis-saint-nom (FR); COURTOIS, Eric, F-00 Rennes (FR); PAPADOPOULO, Jean, F-921 ANTONY (FR); LECA, Pierre, F-70 PARIS (FR) (73) Jogosultak: COMMISSARIAT A L ENERGIE ATOMIQUE, 70 Paris (FR); Caps Entreprise, 3700 Rennes (FR); Université de Versailles Saint-Quentin-en- Yvelines, 7803 Versailles Cédex (FR) (74) Képviselõ: dr. Harangozó Gábor, DANUBIA Szabadalmi és Jogi Iroda Kft., Budapest (4) Optimalizált kód automatikus elõállítására szolgáló rendszer HU T2 A leírás terjedelme oldal (ezen belül lap ábra) Az európai szabadalom ellen, megadásának az Európai Szabadalmi Közlönyben való meghirdetésétõl számított kilenc hónapon belül, felszólalást lehet benyújtani az Európai Szabadalmi Hivatalnál. (Európai Szabadalmi Egyezmény 99. cikk (1)) A fordítást a szabadalmas az 199. évi XXXIII. törvény 84/H. -a szerint nyújtotta be. A fordítás tartalmi helyességét a Magyar Szabadalmi Hivatal nem vizsgálta.

2 A találmány tárgya elõre meghatározott hardverplatformra optimalizált mûveleti kód automatikus elõállítására szolgáló rendszer elõre meghatározott alkalmazási területhez, amely hardverplatform legalább egy processzort tartalmaz, és ahol a kódgenerálást a felhasználó által készített forráskódok alapján végezzük (a felhasználókat ez esetben tágan értelmezzük, vagyis beletartoznak a végfelhasználók, valamint az alkalmazásfejlesztõ programozók és a rendszerprogramozók is). Az informatika kialakulása óta jelentõs fejlesztéseket végeztek a compilerek területén. A compiler feladata egy magas szintû nyelven írt forráskód elemzése, majd ezt követõen az annak megfelelõ bináris kód elõállítása a célgép számára. Ez a folyamat általában statikusan megy végbe a végrehajtást megelõzõen. Léteznek ugyanakkor interpreterek is, amelyek a fordítási mûveleteket dinamikusan végzik el, és amelyek lehetõvé teszik ez utóbbi megszorítás enyhítését azáltal, hogy lehetõséget biztosítanak a kódnak a végrehajtáskor, az utolsó pillanatban történõ elõállítására. A compiler a programkészítési lánc egy eleme. A fordítás (compilálás) eredménye létrehozható már lefordított és elõállított eljárások révén (különálló vagy könyvtár alakú compilálás), amely eljárások a beolvasáshoz statikusan, a végrehajtáshoz dinamikusan kötõdnek. A compilerek mûködése általában három szakaszra osztható: 1. Közbülsõ kód elõállítása: a forráskód alapján a compiler felismeri a nyelvi elemeket és egy, a forrásnyelvtõl független absztrakt formátumú kódot állít elõ; ezt a formátumot rendszerint köztes nyelvnek nevezik. Ez a nyelv független a célgéptõl. 2. Magas szintû optimalizálás: ebben a fázisban bizonyos számú optimalizálásokat egyesítenek, amelyek általában függetlenek a célarchitektúrától: konstansok továbbterjesztése, erõforrás csökkentése, közös kifejezések stb. Ezek az optimalizálások általában egyszerû intézkedések: az utasítások számának csökkentése, a kód struktúrájának egyszerûsítése. 3. Kódgenerálás és alacsony szintû optimalizálás; ebben a fázisban valósítják meg az összes mûveletet és a célgépnek megfelelõ optimalizálásokat: az utasítások elõállítása és válogatása, regiszterek allokációja, utasítások sorba rendezése stb. Egy compiler minõségét nemcsak a célarchitektúra (az elõállított kód teljesítménye) határozza meg, hanem a forrásnyelv (könnyebb vagy nehezebb compilálás), valamint a szoftver szempontjából annak tulajdonságai is (robusztusság, választási lehetõségek számossága, végrehajtási sebesség stb.). A dinamikus fordítás konkrét esetét kivéve a fent említett három fázis mindegyikét a végrehajtás elõtt kell elvégezni és ésszerû idõn belül, ami leginkább korlátozza azon optimalizáló algoritmusok komplexitását, amelyek a compilerben implementálhatók. A compilerekkel kapcsolatos kutatások egy része ezért elsõsorban a magas szintû forrásnyelv kiválasztásával és definiálásával kapcsolatos A compilerek fejlõdése a processzorarchitektúrák, illetve még inkább az ilyen architektúrák mûködését leíró teljesítménymodellek mûködésével is kapcsolatos. Mint minden optimalizálási problémánál, itt is komoly nehézséget jelent egy olyan költségfüggvény definiálása, amely a végrehajtási idõt reprezentálja. Az elsõ utasításkészletek rendkívül egyszerû módon viselkedtek: az utasítássorozat végrehajtási ideje egészen egyszerûen a szekvenciában lévõ egyes utasítások végrehajtási idõinek az összege volt. Következésképpen az optimalizálási eljárás rendkívül egyszerû volt és az optimalizálási stratégia elve az elõállított utasítások számának és komplexitásának csökkentése volt. Az elsõ CISC (Complex Instruction Set Computer, összetett utasításkészletû számítógép) utasításkészletek megjelenése némiképp módosította a helyzetet abban az értelemben, hogy rendkívül összetett utasítások váltak elérhetõvé. Az optimalizálási probléma ekkor lényegében a nyelvi elemek felismerésének problémája lett (pattern matching, mintaillesztés). Ugyanebbe a kategóriába voltak sorolhatók a vektoros utasításkészletek és a vektorizálók, amelyek képesek voltak felismerni az olyan ciklusokat, amelyek közvetlenül lehetõvé tették egy vektorkód elõállítását. Szükség esetén a forráskódot át is lehetett alakítani vektorkódos struktúrák megjelenítésére. Az optimalizálási stratégiákban egy törés következett be a pipeline¹ok megjelenésével, ami egy olyan architekturális fejlõdési lépés volt, amely során a mûveletek feldolgozását felosztották több egymást követõen végrehajtandó mûveletre, egy üzem gyártósorának mintájára. Ez a technika, amely lehetõvé teszi egy adott idõpontban több utasítás egyidejû végrehajtását, jelentõsen javítja a rendszerek teljesítményét, ugyanakkor jelentõs elágazásokat eredményez a pipeline szétválása esetén, például egy elágazó utasítás megjelenésekor. Ez véget vetett egy adott kód megjósolható viselkedésének. Egy másik jelentõs törés a memóriahierarchiák alkalmazásából adódott: az optimalizálásnak egy rendkívül sajátos intézkedés pontos értékelésére kellett támaszkodnia: nevezetesen a (térbeli és idõbeli) megtalálhatóságra. A processzor és a memóriarendszer közötti együttmûködés azonban egyszerû volt, az optimalizáló folyamatnak az volt az elsõdleges feladata, hogy minimalizálja a tévesztések (hibák) számát, mivel minden egyes hiba büntetést eredményezett a végrehajtási idõ számára. Meg kell azonban jegyeznünk, hogy a tévesztések számának minimalizálása kényes feladat volt, és lényegében a ciklikus, egyszerû kódú struktúrák számára volt megvalósítható. A megtalálhatósági tulajdonságok statikusan történõ becslésének említett nehézsége oda vezetett, hogy az optimalizáló módszereket profilok kezelésével együtt alkalmazták: a kódot elõször a hely tulajdonságainak pontos meghatározására hajtották végre (profil létrehozása). Ezt a profilt azután egy második menetben a hely felhasználásához tartozó optimalizálások végrehajtására használták. Az architekturális komplexitásnak ezen a szintjén már rendkívül nehéz volt egy haté- 2

3 kony optimalizálási stratégia egyszerû módon történõ definiálása. Pontosabban szólva rendkívül nagy tudást igényelt a különbözõ optimalizálások kombinálása még a rendkívül egyszerû esetekben is: nem létezett olyan mechanizmus, amely lehetõvé tette a teljesítmények hatékony módon történõ modellezését/számításba vételét. Ilyen körülmények között fejlesztették ki azokat az iteratív compilálási technikákat, amelyek egyesítik a végrehajtást és az optimalizálást oly módon, hogy a lehetõ legjobb kódot állítsák elõ. Pontosabban szólva az iteratív compilálás egy (statikus vagy dinamikus) teljesítmény mérésére alkalmas kódtranszformációs ciklus alkalmazását tartalmazza. Lényegében egy olyan technikáról van szó, amely lehetõvé teszi egy alacsony költségû kódtranszformációs térben történõ keresést, amelynek célja kizárólag az olyan megoldások megtartása, amelyek a legjobb eredményeket adják. A rendkívül megnövekedett számítási idõ és az ilyen iteratív eljárások konfigurálásának költsége azonban korlátozást jelentett az ilyen módszerek alkalmazási területein a könyvtárak optimalizálásánál. A 80¹as évek közepén megjelentek az RISC (Reduced Instruction Set Computer, csökkentett utasításkészletû számítógép) architektúrák, amelyek egyszerû és (a CISC utasítással ellentétben) egységes utasításkészletet használtak. A RISC processzorok elsõ generációi rendkívül korlátozottak voltak a funkcióikat tekintve, és az elõállított kód minõsége (különösen az utasítások sorrendje) kulcsfontosságú tényezõvé vált a futás során a teljesítmény szempontjából. Rendkívül hasonló módon a VLIW (Very Long Instruction Word, nagyon hosszú utasítás szó) architektúrák teljesen hasonló compilálási technikákat használtak a hardver minél jobb kihasználása érdekében. Az említett RISC és VLIW architektúrák mindig is egyszerû determinisztikus teljesítménymodellel rendelkeztek, ugyanis az utasítások minden esetben ugyanabban a sorrendben hajtódtak végre, mint ahogy az elõállított programkódban elhelyezkedtek, ami jelentõsen leegyszerûsítette az ilyen architektúrák mûködését és ezáltal az optimalizálási eljárást. Mindenesetre ezek az architektúrák rendkívül gyorsan általánosították a pipeline és a cache memóriák használatát a nagyobb teljesítmény elérése érdekében (pontosabban szólva ez az átlagos teljesítmény növekedését eredményezte a megjósolhatóság rovására). A szuperskaláris (vagyis a ciklusonként több utasítás végrehajtására alkalmas) architektúrák megjelenése, és fõként az utasítások nem sorrendben történõ feldolgozására (Out of Order Processing) szolgáló mechanizmusok megjelenésével még bonyolultabbá váltak a teljesítményoptimalizáló eljárások. Ráadásul a memóriahierarchiák gyorsan fejlõdtek egymással egyidejûleg: a szintek száma megnövekedett és megjelentek a különbözõ olyan mechanizmusok, amelyek lehetõvé tették a különbözõ cache-tárak (elõtöltõ, prioritáskezelõ stb. tárak) többé-kevésbé explicit kezelését. Az ilyen mechanizmusok együttese a rendkívül egyszerû kódrészek viselkedését (két vagy három táblához való hozzáféréssel mûködõ ciklus) rendkívül bonyolulttá tette és ezáltal lehetetlenné vált az optimalizálás az egyszerû teljesítménymodellek felhasználásával. Ez a helyzet tovább romlott azáltal, hogy a processzorok teljesítménye és a memóriák teljesítménye fokozatosan távolodott egymástól. Összességében az utolsó két évtized során, a processzorok architektúráját tekintve, jelentõsen megnövekedett az elérhetõ funkciók száma. Ezáltal a regiszterek száma is jelentõs mértékben megnõtt: a CISC architektúráknál szabványos 8 regiszterbõl a RISC architektúrákban 32 regiszter lett és ugyanezen szám a szuperskaláris architektúrákban már 80 regiszterre növekedett. Elsõ ránézésre azt gondolhatnánk, hogy a regiszterek számának növekedése leegyszerûsíti az optimalizálást, a gyakorlatban azonban a memóriák fejlõdése még fontosabbá tette a regiszterek használatát és a regiszterek allokációjának ezen problémája miatt a regiszterek allokálásához szükséges hatékony algoritmusok költsége jelentõsen megnövekedett, mivel azok komplexitása a rendelkezésre álló regiszterek számának exponenciális függvénye. Az utóbbi idõk fejlõdéseire adott válaszként a compilerek technológiája alig fejlõdött: a végrehajtott optimalizálások száma ugyan növekedett, azonban globális optimalizálási stratégia definiálási képessége nemcsak hogy nem növekedett, hanem inkább csökkent. Végül egy utolsó irányzat jelent meg a dinamikus compilálással. Az elv egyszerû és vonzó: a dinamikus compilálás (vagy más szóval a végrehajtásra történõ specializálódás) a kódnak az utolsó pillanatban történõ, vagyis a végrehajtáskor történõ optimalizálásait jelenti. Egy kódsorozatot a program a (végrehajtási környezetébõl származó) bemeneti adatok függvényében adaptál (specializál). Egy végrehajtási mechanizmus megvizsgálja a programok viselkedését az utasítássorozatok végrehajtási gyakorisága alapján, és eldönti, hogy egy meghatározott végrehajtási kontextushoz alkalmazzon¹e vagy sem optimalizált verziókat. Az ilyen önmagában dinamikus mechanizmus a számítási idõ szempontjából kevésbé költséges optimalizálási technikákra korlátozódik azok végrehajtása céljából, mivel azoknak nem kell büntetniük a kódok végrehajtását. Megjegyezzük ugyanakkor, hogy egy könyvtár nem más, mint olyan eljárások halmaza, amely egy alkalmazási terület vagy az adott alkalmazási terület egy részének reprezentálására szolgál: egy könyvtár elemeinek valójában meg kell felelniük a gyakran használt standard eljárásoknak. A könyvtár fogalma elve rendkívül régi, még a compilerek fogalmánál is régebbi, ami jelentõs támaszt jelent a szoftver számára (alkotóelemek újbóli felhasználása). A Java példaként említhetõ azokra a nyelvekre, amelyek a könyvtár fogalmát rendkívül szisztematikusan használják. A könyvtárak a legegyszerûbbtõl a legbonyolultabbig különbözõ absztrakciós szinteknek felelhetnek meg: a BLAS1 (Basic Linear Algebra Subroutines Level I) rendkívül egyszerû mûveletek halmaza, amelyek vektorokra vonatkoznak, de lehetõvé teszik nagyszámú hagyományos, lineáris algebrai algoritmus kifejezését. A másik véglet, a LINPACK (vagy EISPACK) az el- 3

4 járások egy olyan teljes csoportja, amely lehetõvé teszi a lineáris egyenletrendszerek megoldását (a saját vektorok és a saját értékek kiszámítását). Nagyszámú könyvtárat fejlesztettek ki és használnak széles körben az alábbi konkrét szakterületeken: tudományos számítás: BLAS1, BLAS2, BLAS3, BLAAT, SPARSE BLAS, LINPACK, LAPACK, BLACS, PVM, MPI stb. jelfeldolgozás: FFTPACK, VSIPI stb. grafika: DerictX, OpenGL. Az a tény, hogy egy adott alkalmazási területen egy bizonyos számú könyvtárat definiáltak és azonosítottak, azt jelenti, hogy az adott szakterület szintetizálható volt. A könyvtárak legnagyobb hátránya ugyanakkor az, hogy a funkcionalitásuk rendkívül korlátozott, továbbá hogy manuális felhasználást vonnak maguk után (vagyis szükségessé teszik a forráskódban egy explicit eljáráshívás elhelyezését). A könyvtárak elsõ generációit (amelyek még egyszerû és kisméretû eljárásoknak feleltek meg) általában kézzel fejlesztették assembly nyelven. Gyakran ez a megoldás maradt, mihelyst a teljesítmény vált a legfontosabb szemponttá (természetesen feltételezve azt, hogy az eljárások ésszerû méretek között maradnak). Ezzel ellentétben a compilálástól eltérõen, amely általában egy online folyamat (a compilálási idõknek csekélynek kell maradniuk), a könyvtárak optimalizálása lényegében egy offline folyamat és olyan eljárásokat is használhat, amelyek számítási idõigénye rendkívül nagy. Ily módon az iteratív compilálás egy kiváló optimalizálási eszköz a könyvtárak fejlesztéséhez, azonban sajnálatos módon kizárólag csak az egyszerû kódokhoz használható, tekintettel a felhasználási nehézségeire. Ugyanebben az összefüggésben az Automatic Tuning Algebra Software típusú technológia lehetõvé teszi az optimalizálás egy részének elvégzését (a megfelelõ paraméterek, például a blokkméretek kiválasztását). Sajnos ez a módszer rendkívül korlátozott felhasználást enged, mivel erõsen függ a vizsgált alkalmazás típusától (tömör mátrixokon végzett számítás, rendkívül kötött idõbeliséggel rendelkezõ számítások). A kód elõállításának és optimalizálásának egy másik módszere ismerhetõ meg James M. Stichnoth Generating Code for High-Level Operations through Code Composition címû tanulmányából (1997. augusztus, CMU-CS-97 16); ez a módszer egy kód elõredefiniált részeit (ún. kód template-eket) használ, amelyek célkódot és olyan fordítási utasításokat tartalmaznak, amelyek a létrehozandó ilyen kódrészeket specifikálják. A létezõ teljesítményanalizáló eszközök rendkívül sokfélék lehetnek (különösen a kutatás tárgyának függvényében): Teljesítménytesztek (benchmark¹ok): ezek az alkalmazási területet többé-kevésbé jellemzõ kódok, amelyek lehetõvé teszik a különbözõ gépek teljesítményének összehasonlítását. Szimulátorok: lehetõvé teszik egy architektúra viselkedésének a legalaposabb megismerését Sajnos ezek rendkívül drágák, a fejlesztésük nagy szaktudást igényel, nagyon lassúak és nem feltétlenül a célprocesszorra vannak kifejlesztve. Matematikai modellek: a gépek teljesítményének egyenletbe foglalásáról szólnak. Ezek alkalmazása általában rendkívül korlátozott és csak egy rendkívül egyszerû kód különbözõ egyszerû változatainak tanulmányozására használhatók. Profilok vezérlésére/kezelésére szolgáló eszközök: ezek az eszközök lehetõvé teszik egy program végrehajtásával kapcsolatos különbözõ információk feltárását (a célhardveren végzett mérések révén): ciklusok számát, tévesztések számát stb. A fentiekkel kapcsolatosan az alábbi megjegyzéseket tehetjük: Teljesítménytesztek: kismértékben fejlõdnek és azok fõleg kereskedelmi szempontból váltak rendkívül fontossá, a fejlesztõk által igen gyakran túlzásba vitt optimalizálásuk meghamisítja az elért eredmények jelentõségét és érvényességét. Szimulátorok: az eredményeinek felhasználása (a kód optimalizálására) egyre nehezebbé válik, mivel a célarchitektúra egyre komplexebb. Matematikai modellek: kevésbé fejlõdnek és a fent említett lokális felhasználáson kívül egyáltalán nem használhatók. Ennek egyik oka, hogy a modellezés jó matematikai eszközei egyformán átlagos viselkedést feltételeznek, ami távol áll a gyakorlati élettõl. Profilokat vezérlõ/kezelõ eszközök: alapvetõen három hátrányos jellemzõjük van: globális információt szolgáltatnak, vagyis nem a tevékenység idõbeli lefolyására vonatkozó információt adnak; nem teszik lehetõvé a kód és a viselkedés közötti finom korrelálást; végül ezek felhasználása (a szimulátor esetében) rendkívül körülményes, elsõsorban a célarchitektúra komplexitása miatt. A találmánnyal célunk a fent említett hátrányok kiküszöbölése és egy legalább egy processzort tartalmazó, elõre definiált hardverplatform számára optimalizált mûveleti kódok automatikus elõállítása elõre meghatározott alkalmazási területen, a felhasználók által készített forráskódok alapján. A találmánnyal kiemelt célunk az informatikai rendszerek teljesítményének a forrásnyelv megválasztásától független módon történõ növelése és az olyan rendszerek számára, amelyek olyan processzorokat alkalmaznak, amelyek architektúrája megkövetelheti egyszerû vagy összetett utasítások használatát, és amely kisebb vagy nagyobb számú regisztert tartalmazhat, egységes funkcionalitású és gyorsítótárat tartalmazhat. A találmánnyal további célunk a speciális programkönyvtárak által biztosított funkciók kibõvítése és egy olyan rendszer megvalósítása, amely nagyszámú hasonló kódsorozat számára automatikusan állít elõ olyan optimalizált kódokat, amelyek különbözõ komplexitású szintekkel rendelkeznek. A kitûzött célokat a találmány értelmében olyan rendszer megvalósításával érjük el, amely legalább 4

5 egy processzort tartalmazó, elõre definiált hardverplatformra optimalizált mûveleti kódok automatikus elõállítására szolgál elõre meghatározott alkalmazási területen a felhasználók által elõállított forráskódok alapján. A rendszer jellemzõje, hogy tartalmaz az említett processzor viselkedését a teljesítmény szempontjából reprezentáló szimbolikus kódszekvenciákat, úgynevezett mintaszekvenciákat fogadó eszközöket; az elõre meghatározott hardverplatform, annak processzora és a mintaszekvenciák alapján meghatározott statikus paramétereket fogadó eszközt; az elõre meghatározott hardverplatform, annak processzora és a mintaszekvenciák alapján meghatározott dinamikus paramétereket fogadó eszközt; a mintaszekvenciák, a statikus paraméterek és a dinamikus paraméterek alapján meghatározott teljesítménymértékek és ¹tesztek alapján optimalizálási szabályokat létrehozó analizálóberendezést; egyrészt a felhasználói forráskódok vizsgálatához, az optimalizálható ciklusok észleléséhez, a magokra történõ szétbontáshoz, valamint az optimalizált kódok továbbítása céljából a kódok összeállításához és beillesztéséhez szükséges optimalizálási szabályokat, másrészt a mintaszekvenciákat fogadó kódoptimalizáló és ¹generáló berendezést; és a kódoptimalizáló és ¹generáló berendezés által elõállított és a magokra jellemzõ információkat a mintaszekvenciákba újból beillesztõeszközt. Egy különösen elõnyös kiviteli alaknál az analizálóberendezés tartalmaz egy olyan tesztgenerátort, amely egyrészt a mintaszekvenciákat fogadó eszközökhöz, másrészt a statikus paramétereket fogadó eszközökhöz kapcsolódik nagyszámú tesztváltozat automatikus elõállítása céljából, amelyek eltárolás céljából átviteli eszköz révén a változatokat tároló adatbázisba vannak továbbítva; egy tesztelõmodult, ami egyrészt a különbözõ változatokat tartalmazó adatbázisban eltárolt tesztváltozatok fogadására szolgáló átviteli eszközhöz, másrészt a tesztváltozatokat a dinamikus paraméterek változatainak egy tartományában történõ végrehajtása és az átviteli eszköz által az eredményeket tartalmazó adatbázisban történõ eltárolás céljából továbbított eredmények elõállítása céljából dinamikus paramétereket fogadó eszközhöz kapcsolódik; és egy olyan analizátort, amely az eredményeket tartalmazó adatbázisban eltárolt eredményeket fogadó és azokat analizáló, valamint azokból optimalizálási szabályokat kikövetkeztetõ átviteli eszközhöz kapcsolódik, és amely optimalizálási szabályok átviteli eszközzel egy optimalizálási szabályokat tartalmazó adatbázisba vannak továbbítva. Az analizátor elõnyösen tartalmaz egy, az optimális teljesítmény tetszõleges küszöbértéke alapján szûrõ eszközt, amely a szûrést oly módon végzi, hogy az eredményeket tartalmazó adatbázisból származó valamely változatot optimálisnak tekinti a paramétertérben, amennyiben az kielégít bizonyos szûrési feltételeket. Egy célszerû kiviteli alaknál az analizátor tartalmaz továbbá a statikus paramétereket módosító eszközt, valamint a dinamikus paramétereket módosító eszközt A kódoptimalizáló és ¹generáló berendezés tartalmaz egy optimalizált kódot elõállító berendezést és optimalizálót, ahol ez utóbbi tartalmaz egy olyan stratégiaválasztó modult, amely egyrészt az eredeti forráskódban azonosított magok fogadására szolgáló eszközhöz, másrészt a mintaszekvenciákat fogadó eszközhöz, harmadrészt az optimalizálási szabályokat fogadó eszközhöz kapcsolódik egy tesztelt mintaszekvenciának megfelelõ minden egyes mag számára több különbözõ változat elõállítása céljából, ahol minden egyes változat optimális egy bizonyos paraméterkombináció szempontjából, továbbá egy olyan kombináló és egyesítõ modult tartalmaz, amely az optimalizálási szabályokat fogadó eszközhöz, a stratégiaválasztó modul által elõállított információkat fogadó eszközhöz, valamint a különbözõ változatokat fogadó eszközhöz kapcsolódik egy átviteli eszközön keresztül a megfelelõ optimalizált változatokat, azok felhasználási tartományát, valamint adott esetben a legjobban alkalmazkodó változat dinamikus meghatározása céljából végrehajtandó tesztet tartalmazó információk továbbítására. Egy lehetséges célszerû kiviteli alaknál a rendszer tartalmaz egy, az optimalizált magokat tartalmazó adatbázist, továbbá a kombináló és egyesítõ modul átviteli eszköz révén az optimalizált magok adatbázisához kapcsolódik az optimalizált változatokra, azok felhasználási tartományára és adott esetben a leginkább alkalmazkodó változat dinamikus meghatározásához végrehajtandó tesztre vonatkozó információknak az optimalizált magok említett adatbázisában történõ eltárolása céljából. A kódoptimalizáló és ¹generáló berendezés tartalmaz egy optimalizálót és egy optimalizált kódot elõállító berendezést, ahol ez utóbbi tartalmaz egy olyan, optimalizálható ciklusokat észlelõ modult, amely a felhasználói forráskódot fogadó eszközhöz kapcsolódik, egy magokra történõ szétbontást végzõ modult, egy, az esetet elemzõ és a kódot összeállító és beillesztõ modult, amely átviteli eszközön keresztül az optimalizálóhoz kapcsolódik az észlelt mag azonosítójának továbbítása céljából, valamint további átviteli eszközhöz kapcsolódik a megfelelõ optimalizált magot leíró információk fogadására, ahol az esetet elemzõ és a kódot összeállító és beillesztõ modult az optimalizált kódot elõállító eszközhöz kapcsolódik. Az esetet elemzõ és a kódot összeállító és beillesztõ modul az optimalizált magokat tartalmazó adatbázishoz is kapcsolódik a megfelelõ optimalizált magot leíró információk fogadására, amit az optimalizáló hívása nélkül hajt végre, amennyiben a keresett mag abban már el van tárolva. Elõnyös, ha az esetet analizáló, a kódot összeállító és beillesztõ modul tartalmaz továbbá eszközt olyan magoknak a mintaszekvenciákhoz történõ hozzáadására, amelyek az említett esetanalizáló és kódösszeállító és ¹beillesztõ modul számára nyilvánvalóvá váltak az optimalizált magokat tartalmazó adatbázisban vagy a mintaszekvenciákban lévõ megfelelõ azonosító ismerete nélkül.

6 Egy elõnyös kiviteli alaknál a rendszer tartalmaz egy compilert és egy linkert egy, a kódoptimalizáló és ¹generáló berendezés által elõállított, átalakított forráskód fogadására és egy, a hardverplatformra adaptált, optimalizált bináris kód elõállítására. A rendszer tartalmazhat olyan eszközt, amely az optimalizált magok adatbázisában lévõ optimalizált magok forráskódját a compilerhez továbbítja. Egy további lehetséges kiviteli alaknál a rendszer tartalmazhat egy compilert és egy telepítõmodult egy olyan dinamikus könyvtárnak a hardverplatformon történõ telepítésére, amely dinamikus könyvtár az optimalizált magok összes funkcióját tartalmazza. A találmány különbözõ alkalmazási területeken használható, például a tudományos számításoknál, a jelfeldolgozásnál, valamint grafikus feldolgozásnál. Rendkívül elõnyös, ha a mintaszekvenciák egy forrásnyelven specifikált és a ciklus törzsének kódját tekintve a növekvõ komplexitás alapján hierarchikus szintekbe rendezett egyszerû és generikus ciklikus kódok egy csoportját tartalmazza. Ebben az esetben a mintaszekvenciák olyan 0. szintû mintaszekvenciákat tartalmaznak, amelyekben egyetlen elemi mûvelet van tesztelve, amely megfelel egy 0 magasságú fa által reprezentált egyetlen aritmetikai kifejezésbõl álló ciklustörzsnek. Ezenkívül a mintaszekvenciák olyan 1. szintû mintaszekvenciákat is tartalmazhatnak, amelyeknél két 0. szintû mûvelet kombinációi vannak figyelembe véve és tesztelve, ahol az 1. szintû mintaszekvenciák mûveletei olyan ciklustörzsek, melyeket egy 1 magasságú fa által reprezentált, egyetlen aritmetikai kifejezés vagy két olyan aritmetikai kifejezés alkot, amelyek mindegyikét egy 0 magasságú fa reprezentálja. Egy lehetséges kiviteli alaknál a mintaszekvenciák olyan 2. szintû mintaszekvenciákat tartalmaznak, amelyeknél két 1. szintû mûvelet vagy három 0. szintû mûvelet kombinációi vannak figyelembe véve és tesztelve. A statikus paraméterek elõnyösen az egyes mintaszekvenciákhoz tartozó ciklusok iterációinak számát, a táblázatokhoz való hozzáférési lépést, az operandus típusát, a felhasznált utasítások típusát, az elõtöltési stratégiákat, valamint az utasítások és az iterációk sorba rendezési stratégiáit tartalmazzák. A dinamikus paraméterek elõnyösen a memóriahierarchia különbözõ szintjein lévõ táblázatos operandusok helyét, a táblázatok kezdõcímeinek relatív pozícióját és az elágazások idõrendi történetét tartalmazzák. Elõnyös, ha az optimalizált magok adatbázisa olyan ciklikus forráskód-szekvenciákat tartalmaz, amelyek valós és hasznos kódrészek, melyek a növekvõ komplexitás szerint szintekbe vannak rendezve. Az elõre definiált hardverplatform legalább egy IN- TEL gyártmányú Itanium processzort, vagy egy IBM gyártmányú Power vagy PowerPC processzort tartalmaz. Különösen az Itanium processzort tartalmazó rendszereknél elõnyösen használható kiviteli alakok esetében az optimalizálási szabályok az alábbi szabályok közül legalább néhányat tartalmaznak: (a) az írások számának minimalizálása abban az esetben, ha az írások teljesítménye rosszabb, mint az olvasásoké, (b) lebegõpontos betöltési párok alkalmazásának jelentõsége, (c) a végrehajtás mértékének beállítása a ciklustörzs komplexitásának függvényében, (d) aritmetikai mûveletek mûveleti késleltetésének felhasználása, (e) maszkolási technikák alkalmazása a rövid vektoroknál, (f) helyazonosító utótagok használata a memória-hozzáféréseknél (olvasás, írás, elõtöltés), (g) az elõtöltés távolságainak definiálása, (h) 4¹es fokozatú vektorizálás végrehajtása az L2 bankok konfliktusai egy részének kiküszöbölése céljából, (i) több változat figyelembe vétele az L2 bankok konfliktusai másik részének, valamint az olvasás/írások várakozó fájljában fellépõ konfliktusok kiküszöbölése céljából, (j) a különbözõ optimalizálásokhoz tartozó teljesítménynyereségek számításba vétele, (k) elágazási láncok használata a hibás predikciók minimalizálása céljából (rövid vektorok), (l) a memória-hozzáférések egyesítése (pixelek csoportosítása), (m) a pixelenként történõ feldolgozások vektorizálása. Különösen a Power vagy PowerPC processzort tartalmazó rendszereknél elõnyösen használható kiviteli alakok esetében az optimalizálási szabályok az alábbi szabályok közül legalább néhányat tartalmaznak: (a) az olvasások sorrendjének átrendezése a cache-tárak üres helyeinek átcsoportosítása céljából, (b) az elõtöltésnek kizárólag az írásoknál történõ alkalmazása, (c) a végrehajtás mértékének beállítása a ciklustörzs komplexitásának függvényében, (d) az aritmetikai mûveletek mûveleti késleltetéseinek kihasználása, (e) a helyazonosító utótagok alkalmazása a memóriahozzáféréseknél (olvasás, írás, elõtöltés), (f) elõtöltési távolságok definiálása, (g) több változat számításba vétele az olvasás/írás várakozó fájljaiban fellépõ konfliktusok kiküszöbölése céljából, (h) a különbözõ optimalizálásokhoz tartozó teljesítménynyereségek számításba vétele. A találmány további jellemzõi és elõnyei megismerhetõk az alábbiakban bemutatásra kerülõ különbözõ kiviteli alakokból, melyeket a mellékelt rajzra történõ hivatkozással mutatunk be. A rajzon: az 1. ábra egy, az optimalizált kód automatikus elõállítására szolgáló, találmány szerinti eljárás moduljainak blokkvázlata, a 2. ábra egy olyan blokkvázlat, amely részletesebben szemlélteti az 1. ábrán látható rendszerben alkalmazható teljesítményelemzõ modul felépítését, 6

7 a 3. ábra egy olyan blokkvázlat, amely részletesebben ismerteti az 1. ábrán látható rendszerben alkalmazható kódoptimalizáló és ¹generáló modul felépítését, a 4. ábra egy olyan blokkvázlat, amely az átalakított forráskódot elõállító modul egy elsõ példája, amely a vizsgált célplatformra optimalizált bináris kód elõállítására szolgáló eszközhöz tartozik, és az. ábra egy olyan blokkvázlat, amely az átalakított forráskódot elõállító modul egy második példáját szemlélteti, amely a vizsgált célplatformra optimalizált bináris kód elõállítására szolgáló eszközhöz tartozik. Elõször is az 1. ábrára hivatkozunk, amely egy optimalizált kód automatikus elõállítására szolgáló rendszer egészét szemlélteti, amely a kódoptimalizáló és ¹generáló 80 modul 73 kimenetén optimalizált mûveleti kódokat szolgáltat egy olyan elõre definiált 90 hardverplatform számára, amely legalább egy 91 processzort tartalmaz. Az optimalizált kódot elõállító rendszer elõre meghatározott alkalmazási területre vonatkozik és a 80 modul 71 bemenetén keresztül a felhasználók által elõállított 17 forráskódokat fogad, ahol a felhasználókat tágan kell értelmezni, vagyis azok közé tartozónak tekintjük a végfelhasználókat, az alkalmazásfejlesztõ programozókat és a rendszerprogramozókat is. A kódoptimalizáló és ¹generáló 80 modul 2 bemenetére, valamint egy analizáló modul 1 bemenetére szimbolikus kódok szekvenciáit, vagyis olyan 1 mintaszekvenciákat adunk, amelyek a 91 processzor viselkedésére jellemzõek a teljesítmény szempontjából a vizsgált alkalmazási területen. A különbözõ környezeti paraméterek hatásának és a mintaszekvenciák közötti kölcsönhatásnak az elemzése lehetõvé teszi a jó és rossz teljesítményû zónák helyének meghatározását és a kapott eredmény okainak megértését. A mintaszekvenciák nem szigorúan olyan valós kódszekvenciákat reprezentálnak, amelyeket klasszikus programozási nyelveken állítanak elõ. A mintaszekvenciáknak csak egy tesztelt részhalmaza alkotja a felhasználói kód optimalizálásához használt magokat. Egy optimalizálható ciklus olyan programalkotás, amely a vektorváltozókon végrehajtható, többé-kevésbé komplex mûvelet algoritmikus reprezentációját kódolja. Egy elemi mag vagy elemi ciklus egy optimalizálható ciklus egyszerû alakját képezi. A találmány szerinti rendszer 80 modulja lehetõvé teszi nagyszámú, a speciális matematikai könyvtárak által nyújtott funkciók számánál lényegesen nagyobb számú optimalizált mag automatikus elõállítását. Ugyanannak a magnak általában több változatát is elõállítjuk, ahol mindegyik változat a környezeti paraméterek egy bizonyos kombinációja szempontjából van optimalizálva. Egy 12 optimalizáló egységben (3. ábra) végzett optimalizálási fázis tehát az alkalmazási területre jellemzõ funkciókat reprezentáló 90 célplatformra optimalizált magok egy csoportját vagy könyvtárát állítja elõ automatikusan. Az optimalizálási fázis a (3. ábrán látható) 18 kódgeneráló egységben végrehajtott kódgenerálási fázishoz tartozik, amely 18 kódgeneráló egység megvizsgálja a felhasználói program forráskódját annak érdekében, hogy abban optimalizálható ciklusokat találjon. A 18 kódgeneráló egység célja, hogy a kód helyett optimalizált magok használatát írja elõ a kódnak azon a helyén, ahol azt a standard compiler elõállítaná. Arra, hogy az 1 mintaszekvenciákba a 80 modul által elõállított információkat beszúrjuk, 74 eszközt használunk. A kódoptimalizáló és ¹generáló fázisokat megelõzi egy, a analizáló modulban végzett analizálási fázis, amelynek célja annak meghatározása, hogy a hardver 90 célplatform és a vizsgált alkalmazási terület esetén milyen optimalizálási szabályokat kell figyelembe venni az optimális teljesítmények eléréséhez. A analizáló modul 7 kimenete lehetõvé teszi az optimalizálási szabályok továbbítását egy 9 optimalizálási szabálykészlethez, amely a 18 átviteli eszközök révén a 80 modul 12 optimalizáló egységéhez kapcsolódik. A továbbiakban a 2. ábrára való hivatkozással részletesebben ismertetjük a analizáló modult. A analizáló modulhoz az 3, 4 eszközökön keresztül olyan 2 statikus paramétereket és 7 dinamikus paramétereket továbbítunk, amelyeket a 91 processzor architektúrája, még általánosabban az optimalizálás 90 célplatformján alapuló rendszer, valamint a mintaszekvencia határoz meg. A 2 statikus paraméterek közé tartozik például az egyes mintaszekvenciákhoz tartozó ciklus iterációinak száma, a táblázatokhoz való hozzáférési lépés, az operandus típusa, a felhasznált utasítások típusa, az elõtöltési stratégiák, valamint az utasítások és az iterációk sorbarendezési stratégiái. A 7 dinamikus paraméterek közé tartozik például a memóriahierarchia különbözõ szintjein lévõ táblázatos operandusok helyének meghatározása, a táblázatok kezdõcímeinek relatív pozíciója, valamint az elágazások idõrendi sorrendje. A teljesítményelemzõ modulban egy 3 tesztgenerátor használja fel a 2 statikus paraméterekre és a 7 dinamikus paraméterekre vonatkozó adatokat, amelyeket az 1, 3 bemenetek biztosítanak potenciálisan igen nagy számú változat elõállítására, amelyeket 61 átviteli eszközök egy, a különbözõ változatokat tároló 4 adatbázishoz továbbítanak. Egy másik automatikus eszköz, az tesztelõmodul (exerciser) a 2 átviteli eszközökön keresztül különbözõ változók adatait, valamint a 4 változókat tartalmazó adatbázis adatait fogadja, elindítja az így összeállított teszteket és végrehajtja azokat, miközben az átviteli eszköz által szolgáltatott 7 dinamikus paraméterek értékét azok megengedett tartományában változtatja, majd a 63 átviteli eszközök révén a megfelelõ eredményeket egy másik adatbázisnak, nevezetesen az eredményeket tartalmazó 6 adatbázisnak továbbítja. 7

8 Az eredményeket tároló 6 adatbázisban lévõ eredményeket 64 átviteli eszközökön keresztül egy 8 analizátorhoz továbbítjuk, amely a paraméterezéstõl függõen a jó és rossz teljesítményû zónák azonosítása alapján lehetõvé teszi 9 optimalizálási szabályok elõállítását, amelyeket az 7 átviteli eszközök segítségével a 9 optimalizálási szabálygyûjteménybe továbbítunk. A 8 analizátor tartalmaz továbbá a 2 statikus paramétereket módosító 4 eszközt és a dinamikus paramétereket módosító 6 eszközt, például ha megállapításra kerül az adott paraméter különbözõ változásaira való csekély érzékenység. A 8 analizátor tartalmazhat az optimális teljesítmény egy tetszõleges küszöbértékét kiszûrõ eszközöket. Ebben az esetben az eredmények halmazának az a változata, amely nem felel meg az optimális teljesítményeknek, mégis megtartható optimálisként a paramétertérben, mivel kielégíti a szûrési feltételeket. Az alábbiakban a 3. ábra segítségével a kódoptimalizáló és ¹generáló 80 modult ismertetjük. A 12 optimalizáló berendezés tartalmaz egy olyan stratégiaválasztó 13 modult, amely az eredeti forráskódban azonosított magokat fogadó 92 eszköz révén a kódgeneráló 18 modulhoz kapcsolódik. A stratégiaválasztó 13 modul ezenkívül az 1 mintaszekvenciákat fogadó 2 eszközhöz és a 9 optimalizálási szabályokat fogadó 8 eszközhöz is kapcsolódik. A stratégiaválasztó 13 modul a 67 kimenetén a vizsgált mintaszekvenciának megfelelõ minden egyes maghoz n különbözõ változatból álló halmazt állít elõ, amelynek mindegyik eleme egy bizonyos paraméterkombináció számára optimális. A kombináló és változatokat egyesítõ 14 modul a 9 optimalizálási szabályokat fogadó 9 eszközökhöz, a stratégiaválasztó 13 modul által elõállított információkat fogadó 66 eszközökhöz és az összes (n számú) verziót fogadó 68 eszközökhöz kapcsolódik. A 14 modul a 93 átviteli eszközökön keresztül a megfelelõ optimalizált változatokat, azok felhasználási tartományát és adott esetben a legjobban adaptált változat dinamikus meghatározásához végrehajtandó tesztet tartalmazza. Az optimalizált kódot elõállító 18 modul tartalmaz egy, az optimalizálható ciklusokat észlelõ modult, amely a felhasználói 17 forráskódokat fogadó 71 eszközhöz kapcsolódik. A modul 7 kimenete egy, a magokat szétválasztó 22 modulhoz kapcsolódik, amelynek a 77 kimenete viszont egy, az esetet elemzõ, és a kódot létrehozó és beillesztõ 23 modulhoz kapcsolódik, amely 92 átviteli eszközökön keresztül egy 12 optimalizálóhoz kapcsolódik, amely továbbítja az észlelt mag azonosítóját. A 23 modul egyébként a 93 átviteli eszközökön keresztül olyan információkat fogad, amelyek a megfelelõ optimalizált magot írják le. A 23 modul egy olyan 73 eszközhöz is kapcsolódik, amely a 19 optimalizált kódokat állítja elõ. Egy elõnyös kiviteli alaknál a kódoptimalizáló és ¹generáló 80 modul tartalmazza a 16 optimalizált magok egy halmazát is. A 14 kombináló és egyesítõ modul 79 átviteli eszközökön keresztül a 14 optimalizált magok halmazához kapcsolódik és az optimalizált magoknak ezen halmazában tárolja az optimalizált változatokra vonatkozó információkat, azok felhasználási zónáját és adott esetben a legjobban adaptált változat dinamikus meghatározásához végrehajtandó tesztet. Ennél a kiviteli alaknál az esetet elemzõ, valamint a kódot összeállító és beillesztõ 23 modul ezenkívül az optimalizált magok 16 halmazához is kapcsolódik 72 átviteli eszköz révén és olyan információkat fogad, amelyek az optimalizált magokat írják le a 12 optimalizáló igénybevétele nélkül, amennyiben a keresett magot már eltároltuk ebben a 16 halmazban. Amint a 3. ábrán látható, az esetet elemzõ és a kódot egyesítõ és beillesztõ 23 modul tartalmaz továbbá olyan 74 eszközt, amely az 1 mintaszekvenciákhoz olyan magokat ad hozzá, amelyek nyilvánvalóvá váltak ebben a 23 modulban anélkül, hogy az optimalizált magok 16 halmazában vagy a mintaszekvenciában megfelelõ módon azonosítva lettek volna. A 4. ábra egy konkrét kiviteli alakot ismertet, ahol nem tüntettük fel a 12 optimalizálót, amely azonos a 3. ábrán látható változattal, amelynek megfelelõen létezik egy optimalizált magokat tartalmazó 16 halmaz. Ennél a kiviteli alaknál a kódgeneráló 18 modul az abban lévõ helyzetelemzõ és kódot elõállító és beillesztõ 23 modul 73 kimenetén egy olyan 19 átalakított forráskódot állít elõ, amelyet ezt követõen klasszikus 81, 82 programkészítõ eszközökkel dolgoznak fel a 90 célhardverre optimalizált 83 bináris kód elõállítási céljából. A 4. ábrán egy olyan kiviteli alak látható, amely könnyen megvalósítható. Az eredeti 17 felhasználói forráskódot a fent már ismertetett kódoptimalizáló és ¹generáló 80 modulban átalakítjuk oly módon, hogy az optimalizálható ciklusokat szubrutinok hívásával helyettesítjük, ahol az említett szubrutinnak megfelelõ kódot beillesztjük az átalakított 19 forráskódba az optimalizált magok 16 csoportja utáni helyre. Az így átalakított 19 forráskód már az összes szükséges elemet tartalmazza a hardver 90 célplatformra adaptált 83 optimalizált bináris kód elõállításához, amely bináris kódot egy 81 compilert és egy 82 kapcsolatszerkesztõt (linker) tartalmazó hagyományos lánc felhasználásával hozzuk létre. Az egyik lehetséges kiviteli alaknál a 16 optimalizált magcsoport optimalizált magjainak forráskódja közvetlenül felhasználható a kompilálási lépésben mint kiegészítõ forráskönyvtár. Ezt a 4. ábrán a 8 szaggatott vonalú nyíllal jelöltük, amely a 16 optimalizált magcsoportot a 81 compilerhez köti. Ez a kiviteli alak így lehetõvé teszi az optimalizált magok forráskódjának az átalakított forráskóddal történõ közvetlen beillesztését és ezáltal megkönnyíti a 18 modulban végrehajtott kódgenerálási lépés végrehajtását. Az. ábra a 4. ábrán látható kiviteli alak egy másik változatát szemlélteti. Az. ábrán látható kiviteli alak kihasználja azt a lehetõséget, hogy bizonyos operációs rendszerek számára lehetõvé teszi könyvtárak létrehozását végrehajtható és a programok által hozzáférhetõ bináris kódok formájában, dinamikus linkek szerkesztése révén, az említett kódok végrehajtási idõpontjában. 8

9 Az. ábrán látható kiviteli alaknál már nincs szükség semmilyen kód beszúrására a 16 optimalizált magok csoportja után a 19 átalakított forráskódban. Azonban egy, az optimalizált magok funkcióinak együttesét tartalmazó dinamikus könyvtárat kell telepíteni a 90 célplatformon egy 181 compiler és egy 182 telepítõ modul segítségével. Lehetõség van egyetlen közös compilert használni az. ábrán látható 81 és 181 compilerként. Az. ábrán látható kiviteli alaknál a telepítési mûveletet csak egyszer kell elvégezni minden egyes célplatform esetében, így ez a kiviteli alak még gazdaságosabb az optimalizálási folyamat teljes feldolgozását tekintve. A találmány szerinti optimalizált kódot elõállító rendszer elsõsorban három területen alkalmazható, nevezetesen a tudományos számításoknál, a jelfeldolgozásnál és a grafikai feldolgozásoknál. Valójában az említett három területen a használt kódok különbözõ CAR1 CAR4 tulajdonságokkal rendelkeznek, melyek az említett alkalmazás szempontjából fontosak. CAR 1: a ciklikus struktúrák (vagy ciklusfészkek ) alkotják a végrehajtási idõ szempontjából leginkább idõigényes kódrészeket. CAR 2: a felhasznált adatok struktúrái nagyrészt többdimenziós táblázatos típusúak és rendkívül szabályos mintázatok (sorok, oszlopok, blokkok stb.) szerint érhetõk el. CAR 3: a ciklusokat (vagy a ciklusok fészkét) általában független és párhuzamosítható iterációk alkotják. CAR 4: a ciklustörzset általában egy olyan aritmetikai kifejezésekbõl álló szekvencia alkotja, amely megfelel egy nagy adathalmazon végzett egységes (vagy kvázi egységes) számításnak. Természetesen, amennyiben az imént említett három terület, vagyis a tudományos számítás, a jelfeldolgozás és a grafikus feldolgozás közös pontokkal rendelkezik, azok bizonyos jelentõs különbségekkel is rendelkeznek, így például a jelfeldolgozás területén a komplex adatok olyan rendkívül fontos adattípust alkotnak, amely speciális optimalizálásokat igényel, miközben ennek az adattípusnak a jelentõsége elhanyagolható a másik két területen. Ezzel szemben a grafikus feldolgozásra kifejezetten jellemzõ bizonyos adattípusok használata, például pixelek, valamint speciális aritmetika alkalmazása. Ráadásul a grafikában az adatoknak és az algoritmusoknak a kétdimenziós képernyõhöz viszonyított strukturálása alapvetõ fontosságú. A fent említett négy tulajdonság (CAR1 CAR4) fontos következményekkel jár a kódoptimalizálás szempontjából és lehetõvé teszik egészen speciális technikák kifejlesztését: CAR 1 az optimalizálások valójában a ciklus típusú struktúrákra koncentrálnak, amelyeknek két fõ elõnye van: az ismétlõdés (és megjósolhatóság), valamint a reprezentálás tömörsége. CAR 2 a táblázatokhoz való hozzáférések, ami a végrehajtási idõk egy jelentõs részét képezi (fõleg a cache-tárak növekvõ mértékû felhasználása miatt) könnyen analizálható és optimalizálható azok szabályossága miatt. CAR 3 az iterációk cikluson belüli vagy a ciklusok fészkén belüli függetlensége lehetõvé teszi az iterációs tér útvonalainak felhasználását (optimalizálását) a táblázatokhoz való hozzáférések függvényében és a célarchitektúra saját tulajdonságai alapján. Megjegyezzük, hogy egy táblázatban szereplõ N elemhez való hozzáférés N! számú különbözõ módon (sorrendben) hajtható végre. CAR 4 a ciklusok törzsének egyszerû struktúrája az aritmetikai kifejezések szempontjából lehetõvé teszi olyan szisztematikus és hierarchikus megközelítés alkalmazását, amely egy aritmetikai kifejezés fastruktúrában történõ reprezentációján alapul. Az analizálási fázis lényegében egy kísérleti lépés, amelynek végén az alábbi feladatokat kell elvégezni: meg kell határozni az architektúra erõs pontjait és gyenge pontjait, meg kell határozni a kód teljesítménye és szerkezete közötti korrelációt, azonosítani kell a jó optimalizálási stratégiákat, amelyek a kódhoz tartozó különbözõ paraméterek függvénye lehet. Amint korábban már jeleztük, a kiindulási pont egyszerû, de általános forrás jellegû kódok együttese, amelyeket mintaszekvenciáknak nevezünk. Ezek a kódok ciklikus szerkezetûek, és a forrás jellegû kifejezés azt jelzi, hogy a mûveletek magas szinten és nem pedig assembly szinten vannak specifikálva. Ezek a kódok szintekre vannak osztva hierarchikus módon, a ciklustörzs kódjának növekvõ komplexitása szerinti sorba az alábbi módon: 0. szintû mintaszekvencia: ezen a szinten egyetlen elemi mûveletet tesztelünk: vagyis a ciklus törzse egyetlen mûveletet tartalmaz: pl. a táblázat egy elemének a beolvasását, a táblázat egy elemének írását, lebegõpontos összeadást stb. végzünk Ezek a mûveletek megfelelnek egy 0 magasságú fa által reprezentált egyetlen aritmetikai kifejezésbõl álló ciklus törzsének. 1. szintû mintaszekvencia: ezen a szinten két 0. szintû mûvelet kombinációit vizsgáljuk és teszteljük: például egy táblázat olvasását és írását, két különbözõ táblázat olvasását, egy táblázat olvasását és ahhoz való hozzáadást stb. Ezek a mûveletek megfelelnek egy 1 magasságú fa által reprezentált egyetlen aritmetikai kifejezésbõl álló ciklusok törzsének vagy két aritmetikai kifejezésbõl álló ciklusok törzsének, ahol az egyes kifejezéseket egy 0 magasságú fa reprezentálja. 2. szintû mintaszekvencia: ezen a szinten két 1. szintû mûvelet vagy három 0. szintû mûvelet kombinációját vizsgáljuk és teszteljük: például három különbözõ táblázat olvasását, két táblázat beolvasását és komponensenként történõ összeadását, majd az eredmény kiírását egy harmadik táblázatba stb. 9

10 K. szintû mintaszekvencia: a K. szint könnyen definiálható az elõzõ szintek mûveleteinek ismétlésével. Az összes 0. szintû mintaszekvencia mesterséges kódok, vagyis nem a valódi ciklusok fordításai. A növekvõ komplexitás szerinti szintekbe történõ ilyenfajta csoportosítás az optimalizálási fázisban is használatos. Az ily módon definiált mintaszekvenciák száma végtelen. A mintaszekvenciák két különbözõ paraméterkészletet használnak: statikus paraméterek: ezeket a paramétereket statikusan definiáljuk (vagyis a végrehajtás elõtt és a végrehajtástól függetlenül). A statikus paramétereket tovább oszthatjuk két nagyobb alcsoportra: magas szintû statikus paraméterek (a ciklus iterációinak száma, a táblázatokhoz való hozzáférési lépés, operandustípus stb.), valamint alacsony szintû statikus paraméterek (speciális utasítások használata, utasítások sorba rendezése stb.) Dinamikus paraméterek: ezeket a paramétereket a ciklus végrehajtásakor definiáljuk. Ide tartozik például a táblázatos operandusoknak a memóriahierarchiában történõ lokalizálása, a táblázatok kezdõ címeinek relatív pozíciója stb. A paraméterek ezen két csoportját rendkívül eltérõ módon használjuk fel: a statikus paramétereket különbözõ tesztkódoknak a késõbbiekben bemutatásra kerülõ változatokkal/optimalizációkkal kombinált elõállítására használjuk, míg a dinamikus paramétereket kizárólag a tesztadatokkal történõ végrehajtás során használjuk. A magas szintû statikus paraméterek viszonylag korlátozottak és lényegében valamilyen magas szintû nyelven (például Fortran vagy C nyelven) készült ciklus vagy táblázatok klasszikus paramétereit alkotják a célprocesszor bármilyen sajátos tulajdonságának figyelembevétele nélkül. Az alacsony szintû statikus paraméterek lehetõvé teszik a processzor (architektúra) és az utasítások sorba rendezésének (tárgykód generálása) összes jellemzõjének figyelembevételét. Valójában a mintaszekvenciák magas szintû absztrakciót hordoznak (ami a vizsgált processzor architektúrájától független, forrásnyelven definiált absztrakciót jelent) és semmilyen optimalizálást nem foglalnak magukban. Egy adott processzoron történõ tesztelésükhöz elõ kell állítani és optimalizálni kell a megfelelõ assembly kódokat. Ezen kódgenerálás során automatikusan különbözõ kódváltozatokat (assembly utasítássorozatokat) állítunk elõ. Egy adott mintaszekvenciához tartozó változat a kiindulási mintaszekvenciával szemantikusan ekvivalens kódot alkot. Ezek a változatok kerülnek végrehajtásra és mérésre. Az említett változatok a különbözõ kódoptimalizálási technikáknak (vagyis az alacsony szintû statikus paramétereknek) felelnek meg. Ezek az optimalizációk meghatározhatók absztrakt módon, valamely mintaszekvencia konkrét szerkezetére való hivatkozás nélkül, és az alacsony szintû statikus paraméterek lényeges részét alkotják. Az alacsony szintû statikus paraméterek az alábbiakat tartalmazzák: assembly utasítások felhasználása: ugyanaz a forrás szintû mûvelet különbözõ utasítássorozatokkal hajtható végre. Pontosabban szólva, itt kell kezelni a különbözõ lehetséges stratégiákat az adatok és az utasítások elõtöltésének alkalmazása céljából. a ciklus törzsének struktúrája: a ciklus törzsének (változó mértékû) végrehajtása, a ciklus törzsének sorba rendezése: a ciklus törzsében lévõ utasítások sorba rendezése (elõtöltési távolságok, vektorizálás), a cache-tár üres helyeinek összegyûjtése, a várakozó fájlokban fellépõ konfliktusok kezelése), az iterációk sorba rendezése: szoftveres pipeline (változó mélység). Számos compilerben a fent ismertetett alacsony szintû statikus paraméterek olyan compilálási opciók, amelyek lehetõvé teszik a kívánt optimalizálás explicit módon történõ végrehajtását. A 3 tesztgenerátor feladata egyrészt a magas szintû statikus paramétereknek (például a táblázatokhoz való hozzáférési lépéseknek), másrészt az alacsony szintû statikus paramétereknek megfelelõ, fent ismertetett különbözõ változatok elõállítása. Szükségesnek tartjuk megjegyezni, hogy az 1. szintû mintaszekvencia esetében az elõállítandó/analizálandó változatok összes száma rendkívül magas és akár több millió is lehet. Ennek ellenére a kódgeneráló és ¹analizáló folyamat rendkívül egyszerûen automatizálható. Az tesztelõmodulban és a 8 analizátorban a különbözõ változatok teljesítményeinek tesztelése és a lehetõ legjobb változatok/optimalizálások kiválasztása történik. Ez a szakasz magában foglalja nagyszámú eredmény elõállítását, melyeket a 6 eredmény-adatbázisban tárolunk el. A kísérleteket hierarchikus módon és az analizáló fázisokkal összefonódva végezzük el: ily módon az elsõ kísérleteket a 0. szintû mintaszekvencia változatain hajtjuk végre. A kísérletek ezen elsõ csoportjának elvégzésekor a kapott eredmények függvényében elvégezhetjük a különbözõ eredmények egy elsõ osztályozását. Bizonyos változatokat teljesen elvetünk és egyáltalán nem veszünk figyelembe a következõ szinteken, ami lehetõvé teszi a végrehajtandó kísérletek számában bekövetkezõ kombinatorikai robbanás korlátozását. Az eredmények analizálási fázisát elsõ ránézésre rendkívül egyszerû végrehajtani, mivel egyetlen mérõszámot (a teljesítményt) használunk. Valójában a folyamat komplexitásának nagy része abból ered, hogy a legjobb változatok kiválasztása általában nagymértékben függ a paraméterektõl. Az elsõ osztályozást rendkívül egyszerûen lehet végrehajtani az architektúra specifikációja alapján az egyes mintaszekvenciákhoz tartozó optimális teljesít-

11 mények kiszámításával. Ezzel szemben gyorsan nehézségekbe ütközhetünk az architektúra és a kód közötti bonyolult kölcsönhatások miatt (ideértve az olyan egyszerû kódokat is, mint amilyen a 0. vagy 1. szintû mintaszekvenciák): ez olyan bonyolult összefüggések alapján kerül lefordításra, amelyek különbözõ értékeit a paraméterek függvényében írják le. Ezeket az összetett mûveleteket elõször analizálhatjuk képfeldolgozó algoritmusok alkalmazásával, majd szintetizálhatjuk azokat egy adott paraméter értéktartományhoz tartozó változat minõsítésével. Ily módon az analizálási fázis nem egyszerûen egy olyan listát generál, amely minden egyes mintaszekvenciához a legjobb (és egyedi) változatot/optimalizálási technikát adja meg: valójában minden egyes mintaszekvenciához a paraméterek egy értékkészletének listáját határozzuk meg és minden egyes ilyen értéktartományhoz megadjuk a legjobb változatot/optimalizálási technikát: ez egy olyan információ, amit optimalizálási szabálynak nevezünk. A tesztelt mintaszekvenciák csoportja a mintaszekvenciák csoportjának egy erõsen korlátozott részhalmaza. Ez a csoport, amelyet a késõbbiekben az optimalizálásokhoz használunk, az úgynevezett referencia-mintaszekvenciák halmaza. Gyakorlatban rendkívül fontos az optimalizálás ésszerû céljának rögzítése: ugyanis az optimum mindenáron történõ megkeresése rendkívül nagyszámú változat elõállítását idézheti elõ, míg az optimumra vonatkozó megszorítás enyhítésével és az optimum körüli %¹os teljesítmények elfogadásával egyetlen változat is használható a paraméterek egy tág értékkészletéhez. Ezért egy szûrést végzünk például az optimális teljesítmény 90%¹os küszöbértékére. A gyakorlatban elegendõ kizárólag a mintaszekvenciák 0., 1. és 2. szintjét tesztelni és analizálni a legfõbb optimalizálási technikák kiválasztására és ellenõrzésére. A mintaszekvenciák hivatkozott halmaza általában nem tartalmazza a 3.¹nál magasabb szintû szekvenciákat. A kísérletezések száma a valóságban rendkívül gyorsan növekszik, különösen a második szinten. A csoportos kísérletezés ideális a párhuzamosíthatóság szempontjából: a tesztek 0 vagy akár 00 gépen is párhuzamosan végrehajthatók. Ez a párhuzamosíthatóság rendkívül hasznos és lehetõvé teszi a szisztematikus keresések végrehajtását és azok elfogadható idõben történõ végrehajtását. Ez a fázis teljesen automatizálható és a minõségellenõrzési eljárások, valamint az eredmények koherenciájának vizsgálatára vonatkozó eljárások szintén automatizáltak. Az emberi beavatkozás csak az elõállított eredményeknek a minõség-ellenõrzõ és koherenciát ellenõrzõ eljárásokkal automatikusan végzett analízis eredményeként fellépõ hibák/anomáliák helyreállításához szükséges. Az analizálási fázis végrehajtásának célja speciálisan a célarchitektúra számára optimalizált nagyszámú egyszerû kód, úgynevezett mag elõállítása, ahol az optimalizálási folyamat lényegében azokra az optimalizálási technikákra támaszkodik, amelyek az analizálási fázis végén állnak rendelkezésre. Szigorú értelemben véve a magok olyan ciklikus forráskód-szekvenciák, amelyeket általános esetben a mintaszekvenciák egy részhalmaza alkot. Ez utóbbiaktól annyiban tér el, hogy a magok valódi és hasznos kódrészletek. Akárcsak a mintaszekvenciák, a magok szintén szintekre vannak osztva a növekvõ komplexitásuk szerint. Az említett magok elõállítása/optimalizálása az alábbi négy fázisban kerül végrehajtásra: Egy vagy több referencia-mintaszekvenciával történõ korrelálás: a legegyszerûbb magok esetében közvetlen megfeleltetés van a magok és a mintaszekvenciák között, az összetettebb magok esetében a magot több referencia-mintaszekvenciára bontjuk. Ezt a korrelálást/szétbontást forrásszinten végezzük a mag ciklustörzse jellemzõinek, pl. a táblázatok száma, a táblázatokhoz való hozzáférési lépések stb. függvényében Kódgenerálás/utasítások sorba rendezése/utasítások optimalizálása: ennek során olyan optimalizálási technikákat használunk, amelyeket az analizálási fázis során észleltünk (a megfelelõ mintaszekvenciák függvényében) és azokat közvetlenül a kódgenerálásra/kódoptimalizálásra alkalmazzuk a magok számára. Ugyanahhoz a maghoz több lehetséges változat is elõállítható a paraméterek függvényében. Regiszterek allokálása: a felhasznált nagyszámú optimalizálási technika jelentõsen megnöveli a rendelkezésre álló regiszterekre nehezedõ nyomást. Ebben az esetben érdemes szabályozni a rendelkezésre álló regiszterek allokálását. Kísérletezés/ellenõrzés: az elõállított és optimalizált magot az analizálási fázis tesztadatainak felhasználásával teszteljük. Ezen fázis befejeztével a mag teljesítményének egy egyszerû modelljét hozzuk létre. A compilerben használt hagyományos optimalizálásokhoz képest a találmánynál alkalmazott optimalizálások egészen másképpen mûködnek: mindenekelõtt a találmány szerinti eljárások közvetlenül a teljesítményértékelés (az elemzési fázis során végrehajtott) részletes eljárásából származnak, majd ezután rendkívül összetettek és nagy teljesítményûek lesznek, különösen a regiszterek allokálását tekintve, mivel idõkorlát nélkül, offline módon kerülnek végrehajtásra. A referencia-mintaszekvenciák és a generálási szabályok alkalmazása lehetõvé teszi, hogy egyrészt az architektúra összes tulajdonságát figyelembe vegyük (végrehajtott és nem elméleti jellemzõk), másrészt azon különbözõ változatok figyelembe vételét, amelyek a paraméterek függvényében kerülnek kiválasztásra. Ezen fázis befejeztével egy olyan 16 adatbázist hozunk létre, amely optimalizált magokat tartalmaz, és amely nemcsak a generált kódokat tartalmazza, hanem a teljesítményekre vonatkozó információkat is, melyek a különbözõ paraméterek függvényei. Végül az 11

12 összes ilyen magot teszteljük a mintaszekvenciákhoz használt eljárás alkalmazásával. A gyakorlatban az optimalizált magokat tartalmazó 16 adatbázis szisztematikusan és kimerítõ módon tartalmazza az összes 1., 2., 3., 4. és. szintû magot. Az említett adatbázis létrehozásának számítási igényére jellemzõ költség jelentõs, azonban akárcsak a teljesítményelemzési fázis, ez is rendkívül hatékonyan párhuzamosítható. A felhasználói kód optimalizálása az alábbi három fázisban hajtható végre: Optimalizálható ciklusok észlelése ( modul): ebben a lépésben a forráskódban a magokra szétbontható ciklusokat keressük meg. Ez a fázis az automatikus párhuzamosítás/vektorizálás technikáihoz nagyon hasonló technikákat alkalmaz. Szükség esetén a forráskódot átstrukturáljuk ahhoz, hogy a ciklus az optimalizálás szempontjából kedvezõbb alakban jelenjen meg. Az optimalizálható ciklus elemzése, magokra történõ szétbontása (22 modul): a magok optimalizálásánál használt konfiguráláshoz és a szétbontáshoz hasonló konfigurálás, ill. szétbontás társítási technikái alapján a ciklust a magok egy sorozatára bontjuk szét. A kód összeállítása és beillesztése (23 modul): a szétbontáshoz használt különbözõ magokat egyesítjük és beillesztjük a forráskódba. A szétbontási eljárás általában az eredeti forráskód ciklusjellemzõinek függvényében van paraméterezve. A javasolt optimalizálások beépíthetõk egy preprocesszor révén egy meglévõ compilálási láncba transzparens módon, vagyis anélkül, hogy a compiler kódjához való hozzáférésre szükség lenne, akár közvetlenül a compilerbe, ami nyilvánvalóan szükségessé tesz bizonyos módosításokat a compiler kódjában. Amint azt korábban a 3. ábrára történõ hivatkozással már említettük, az analizálási fázis befejezésekor bizonyos számú optimalizálási szabály áll rendelkezésre: ezek a szabályok a mintaszekvencia és a paraméterkészlet függvényei. Ahelyett, hogy végrehajtjuk a magok közbülsõ lépését, egy további lehetséges megoldás az optimalizálható ciklusnak mintaszekvenciákkal történõ közvetlen korrelálása és az optimalizálási szabályoknak közvetlenül az optimalizálható ciklusra való alkalmazása anélkül, hogy a magokat eltárolnánk az optimalizált magokat tartalmazó 16 adatbázisban. Ez a változat egyszerûbb, mint a magokkal végzett mûvelet és lehetõvé teszi az optimalizálási szabályok rugalmasabb felhasználását. Ugyanakkor, abból kifolyólag, hogy lényegében online módon kerül végrehajtásra, a feltárt változatok száma szükségszerûen korlátozottabb és így az elérhetõ teljesítmények eleve kevésbé jók lesznek. Az optimalizálási fázis befejezésekor a rendszer optimalizált alakokat szolgáltat bizonyos számú optimalizálható ciklus számára, amelyek eredetileg nem álltak közvetlenül rendelkezésre a magok adatbázisában, mivel szükségessé tették a szétbontásukat. Ezek az optimalizált alakok eltárolhatók az optimalizált magokat tartalmazó 16 adatbázisban és a késõbbiekben újból felhasználhatók. Ily módon a magokat tartalmazó 16 adatbázis automatikusan bõvül a tanulás ilyen formája révén. SZABADALMI IGÉNYPONTOK 1. Rendszer legalább egy processzort (91) tartalmazó, elõre definiált hardverplatformra (90) optimalizált mûveleti kódok (19) automatikus elõállítására elõre meghatározott alkalmazási területen a felhasználók által elõállított forráskódok (17) alapján, azzal jellemezve, hogy tartalmaz az említett processzor (91) viselkedését a teljesítmény szempontjából reprezentáló szimbolikus kódszekvenciákat, úgynevezett mintaszekvenciákat (1) fogadó eszközöket (1, 2); az elõre meghatározott hardverplatform (90), annak processzora (91) és a mintaszekvenciák (1) alapján meghatározott statikus paramétereket fogadó eszközt (3); az elõre meghatározott hardverplatform (91), annak processzora (91) és a mintaszekvenciák (1) alapján meghatározott dinamikus paramétereket fogadó eszközt (); a mintaszekvenciák (1), a statikus paraméterek (2) és a dinamikus paraméterek (7) alapján meghatározott teljesítménymértékek és ¹tesztek alapján optimalizálási szabályokat (9) létrehozó analizálóberendezést (); egyrészt a felhasználói forráskódok (17) vizsgálatához, az optimalizálható ciklusok észleléséhez, a magokra történõ szétbontáshoz, valamint az optimalizált kódok (19) továbbítása céljából a kódok összeállításához és beillesztéséhez szükséges optimalizálási szabályokat (9), másrészt a mintaszekvenciákat (1) fogadó kódoptimalizáló és ¹generáló berendezést (80); és a kódoptimalizáló és ¹generáló berendezés (80) által elõállított és a magokra jellemzõ információkat a mintaszekvenciákba (1) újból beillesztõ eszközt (74). 2. Az 1. igénypont szerinti rendszer, azzal jellemezve, hogy az analizálóberendezés () tartalmaz egy olyan tesztgenerátort (3), amely egyrészt a mintaszekvenciákat fogadó eszközökhöz (1), másrészt a statikus paramétereket fogadó eszközökhöz (3) kapcsolódik nagyszámú tesztváltozat automatikus elõállítása céljából, amelyek eltárolás céljából átviteli eszköz (61) révén a változatokat tároló adatbázisba (4) vannak továbbítva; egy tesztelõmodult (), ami egyrészt a különbözõ változatokat tartalmazó adatbázisban (4) eltárolt tesztváltozatok fogadására szolgáló átviteli eszközhöz (62), másrészt a tesztváltozatokat a dinamikus paraméterek (7) változatainak egy tartományában történõ végrehajtása és az átviteli eszköz (63) által az eredményeket tartalmazó adatbázisban (6) történõ eltárolás céljából továbbított eredmények elõállítása céljából dinamikus paramétereket fogadó eszközhöz () kapcsolódik; és egy olyan analizátort (8), amely az eredményeket tartalmazó adatbázisban (6) eltárolt eredményeket fogadó és azokat analizáló, valamint azokból optimalizálási szabályokat kikövetkeztetõ átviteli esz- 12

13 közhöz kapcsolódik, és amely optimalizálási szabályokat átviteli eszközzel (7) egy optimalizálási szabályokat tartalmazó adatbázisba (9) vannak továbbítva. 3. A 2. igénypont szerinti rendszer, azzal jellemezve, hogy az analizátor (8) tartalmaz egy, az optimális teljesítmény tetszõleges küszöbértéke alapján szûrõeszközt, amely a szûrést oly módon végzi, hogy az eredményeket tartalmazó adatbázisból származó valamely változatot optimálisnak tekinti a paramétertérben, amennyiben az kielégít bizonyos szûrési feltételeket. 4. A 2. vagy 3. igénypont szerinti rendszer, azzal jellemezve, hogy az analizátor (8) tartalmaz továbbá a statikus paramétereket (2) módosító eszközt (4), valamint a dinamikus paramétereket (7) módosító eszközt (6).. Az 1 4. igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy a kódoptimalizáló és ¹generáló berendezés (80) tartalmaz egy optimalizált kódot elõállító berendezést (18) és optimalizálót (12), ahol ez utóbbi tartalmaz egy olyan stratégiaválasztó modult (13), amely egyrészt az eredeti forráskódban azonosított magok fogadására szolgáló eszközhöz (92), másrészt a mintaszekvenciákat (1) fogadó eszközhöz (2), harmadrészt az optimalizálási szabályokat (9) fogadó eszközhöz kapcsolódik egy tesztelt mintaszekvenciának megfelelõ minden egyes mag számára több különbözõ változat () elõállítása céljából, ahol minden egyes változat optimális egy bizonyos paraméterkombináció szempontjából, továbbá egy olyan kombináló és egyesítõ modult (14) tartalmaz, amely az optimalizálási szabályokat (9) fogadó eszközhöz (9), a stratégiaválasztó modul (13) által elõállított információkat fogadó eszközhöz (66), valamint a különbözõ változatokat () fogadó eszközhöz (68) kapcsolódik egy átviteli eszközön (93) keresztül a megfelelõ optimalizált változatokat, azok felhasználási tartományát, valamint adott esetben a legjobban alkalmazkodó változat dinamikus meghatározása céljából végrehajtandó tesztet tartalmazó információk továbbítására. 6. Az. igénypont szerinti rendszer, azzal jellemezve, hogy egy, az optimalizált magokat tartalmazó adatbázist (16) tartalmaz, továbbá a kombináló és egyesítõ modul (14) átviteli eszköz (79) révén az optimalizált magok adatbázisához (16) kapcsolódik az optimalizált változatokra, azok felhasználási tartományára és adott esetben a leginkább alkalmazkodó változat dinamikus meghatározásához végrehajtandó tesztre vonatkozó információknak az optimalizált magok említett adatbázisában történõ eltárolása céljából. 7. Az 1 6. igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy a kódoptimalizáló és ¹generáló berendezés (80) tartalmaz egy optimalizálót (12) és egy optimalizált kódot elõállító berendezést (18), ahol ez utóbbi tartalmaz egy olyan, optimalizálható ciklusokat észlelõ modult (), amely a felhasználói forráskódot (17) fogadó eszközhöz (71) kapcsolódik, egy magokra történõ szétbontást végzõ modult (22), egy, az esetet elemzõ és a kódot összeállító és beillesztõ modult (23), amely átviteli eszközön (92) keresztül az optimalizálóhoz (12) kapcsolódik az észlelt mag azonosítójának továbbítása céljából, valamint további átviteli eszközhöz (93) kapcsolódik a megfelelõ optimalizált magot leíró információk fogadására, ahol az esetet elemzõ és a kódot összeállító és beillesztõ modul (23) az optimalizált kódot elõállító eszközhöz (73) kapcsolódik. 8. A 6. vagy 7. igénypont szerinti rendszer, azzal jellemezve, hogy az esetet elemzõ és a kódot összeállító és beillesztõ modul (23) az optimalizált magokat tartalmazó adatbázishoz (16) is kapcsolódik a megfelelõ optimalizált magot leíró információk fogadására, amit az optimalizáló (12) hívása nélkül hajt végre, amennyiben a keresett mag abban már el van tárolva. 9. A 8. igénypont szerinti rendszer, azzal jellemezve, hogy az esetet analizáló, a kódot összeállító és beillesztõ modul (23) tartalmaz továbbá eszközt (74) olyan magoknak a mintaszekvenciákhoz (1) történõ hozzáadására, amelyek az említett esetanalizáló és kódösszeállító és ¹beillesztõ modul (23) számára nyilvánvalóvá váltak az optimalizált magokat tartalmazó adatbázisban (16) vagy a mintaszekvenciákban lévõ megfelelõ azonosító ismerete nélkül.. A 6., 8. és 9. igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy tartalmaz egy compilert (81) és egy linkert (82) egy, a kódoptimalizáló és ¹generáló berendezés (80) által elõállított, átalakított forráskód (19) fogadására és egy, a hardverplatformra (90) adaptált, optimalizált bináris kód (83) elõállítására. 11. A. igénypont szerinti rendszer, azzal jellemezve, hogy olyan eszközt (8) tartalmaz, amely az optimalizált magok adatbázisában (16) lévõ optimalizált magok forráskódját a compilerhez (81) továbbítja. 12. A. igénypont szerinti rendszer, azzal jellemezve, hogy tartalmaz egy compilert (181) és egy telepítõ modult (182) egy olyan dinamikus könyvtárnak a hardverplatformon (90) történõ telepítésére, amely dinamikus könyvtár az optimalizált magok összes funkcióját tartalmazza. 13. Az igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy az elõre meghatározott alkalmazási terület a tudományos számítás. 14. Az igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy az elõre meghatározott alkalmazási terület a jelfeldolgozás.. Az igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy az elõre meghatározott alkalmazási terület a grafikus feldolgozás. 16. Az 1. igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy a mintaszekvenciák (1) egy forrásnyelven specifikált és a ciklus törzsének kódját tekintve a növekvõ komplexitás alapján hierarchikus szintekbe rendezett egyszerû és generikus ciklikus kódok egy csoportját tartalmazza. 17. A 16. igénypont szerinti rendszer, azzal jellemezve, hogy a mintaszekvenciák (1) 0. szintû mintaszekvenciákat tartalmaznak, amelyekben egyetlen elemi mûvelet van tesztelve, amely megfelel egy 0 magas- 13

14 ságú fa által reprezentált egyetlen aritmetikai kifejezésbõl álló ciklustörzsnek. 18. A 17. igénypont szerinti rendszer, azzal jellemezve, hogy a mintaszekvenciák olyan 1. szintû mintaszekvenciákat tartalmaznak, amelyeknél két 0. szintû mûvelet kombinációi vannak figyelembe véve és tesztelve, ahol az 1. szintû mintaszekvenciák mûveletei olyan ciklustörzsek, melyeket egy 1 magasságú fa által reprezentált, egyetlen aritmetikai kifejezés vagy két olyan aritmetikai kifejezés alkot, amelyek mindegyikét egy 0 magasságú fa reprezentálja. 19. A 18. igénypont szerinti rendszer, azzal jellemezve, hogy a mintaszekvenciák (1) 2. szintû mintaszekvenciákat tartalmaznak, amelyeknél két 1. szintû mûvelet vagy három 0. szintû mûvelet kombinációi vannak figyelembe véve és tesztelve.. A igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy a statikus paraméterek (2) elõnyösen az egyes mintaszekvenciákhoz tartozó ciklusok iterációinak számát, a táblázatokhoz való hozzáférési lépést, az operandus típusát, a felhasznált utasítások típusát, az elõtöltési stratégiákat, valamint az utasítások és az iterációk sorba rendezési stratégiáit tartalmazzák. 21. A 16. igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy a dinamikus paraméterek (7) elõnyösen a memóriahierarchia különbözõ szintjein lévõ táblázatos operandusok helyét, a táblázatok kezdõ címeinek relatív pozícióját és az elágazások idõrendi történetét tartalmazzák. 22. A 6., 8. és 9. igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy az optimalizált magok adatbázisa (16) olyan ciklikus forráskód-szekvenciákat tartalmaz, amelyek valós és hasznos kódrészek, melyek a növekvõ komplexitás szerint szintekbe vannak rendezve. 23. Az igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy az elõre definiált hardverplatform (90) legalább egy Itanium típusú processzort tartalmaz. 24. Az igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy az elõre definiált hardverplatform (90) legalább egy Power vagy PowerPC típusú processzort tartalmaz. 2. A 13. és a 23. igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy az optimalizálási szabályok (9) az alábbi szabályok közül legalább néhányat tartalmaznak: (n) az írások számának minimalizálása abban az esetben, ha az írások teljesítménye rosszabb, mint az olvasásoké, (o) lebegõpontos betöltési párok alkalmazásának jelentõsége, (p) a végrehajtás mértékének beállítása a ciklustörzs komplexitásának függvényében, (q) aritmetikai mûveletek mûveleti késleltetésének felhasználása, (r) maszkolási technikák alkalmazása a rövid vektoroknál, (s) helyazonosító utótagok használata a memória-hozzáféréseknél (olvasás, írás, elõtöltés), (t) az elõtöltés távolságainak definiálása, (u) 4¹es fokozatú vektorizálás végrehajtása az L2 bankok konfliktusai egy részének kiküszöbölése céljából, (v) több változat figyelembe vétele az L2 bankok konfliktusai másik részének, valamint az olvasás/írások várakozó fájljában fellépõ konfliktusok kiküszöbölése céljából, (w) a különbözõ optimalizálásokhoz tartozó teljesítménynyereségek számításba vétele, (x) elágazási láncok használata a hibás predikciók minimalizálása céljából (rövid vektorok), (y) a memória-hozzáférések egyesítése (pixelek csoportosítása), (z) a pixelenként történõ feldolgozások vektorizálása. 26. A 13. és a 24. igénypontok bármelyike szerinti rendszer, azzal jellemezve, hogy az optimalizálási szabályok (9) az alábbi szabályok közül legalább néhányat tartalmaznak: (i) az olvasások sorrendjének átrendezése a cache-tárak üres helyeinek átcsoportosítása céljából, (j) az elõtöltésnek kizárólag az írásoknál történõ alkalmazása, (k) a végrehajtás mértékének beállítása a ciklustörzs komplexitásának függvényében, (l) az aritmetikai mûveletek mûveleti késleltetéseinek kihasználása, (m) a helyazonosító utótagok alkalmazása a memóriahozzáféréseknél (olvasás, írás, elõtöltés), (n) elõtöltési távolságok definiálása, (o) több változat számításba vétele az olvasás/írás várakozó fájljaiban fellépõ konfliktusok kiküszöbölése céljából, (p) a különbözõ optimalizálásokhoz tartozó teljesítménynyereségek számításba vétele. 14

15 HU T2 Int. Cl.: G06F 9/4

16 HU T2 Int. Cl.: G06F 9/4 16

17 HU T2 Int. Cl.: G06F 9/4 17

18 HU T2 Int. Cl.: G06F 9/4 18

19 HU T2 Int. Cl.: G06F 9/4 19

20 Kiadja a Magyar Szabadalmi Hivatal, Budapest Felelõs vezetõ: Törõcsik Zsuzsanna Windor Bt., Budapest