Egy kutatási projekt részeként Megkezdődött a munka egy olyan funkcióval a GCC-hez, amely lehetővé teszi a fordítási folyamat több párhuzamos szálra történő felosztását. Jelenleg a többmagos rendszerek felépítési sebességének javítása érdekében a make segédprogram külön fordítói folyamatok elindítását használja, amelyek mindegyike külön kódfájlt épít fel. Az új projekt párhuzamosítással kísérletez a fordítói szinten, ami potenciálisan javítja a teljesítményt a többmagos rendszereken.
Teszteléshez a GCC egy külön párhuzamosító ága, amely egy új „—param=num-threads=N” paramétert kínál a szálak számának beállításához. A kezdeti szakaszban az eljárásközi optimalizálás külön szálakba való átvitelét valósítottuk meg, amelyeket minden függvénynél ciklikusan hívunk, és könnyen párhuzamosíthatók. A hardverfüggetlen optimalizálásért felelős GIMPLE-műveletek, amelyek a funkciók egymás közötti kölcsönhatását értékelik, külön szálakba kerülnek.
A következő szakaszban az interprocedurális RTL-optimalizálásokat is külön szálakba helyezik át, figyelembe véve a hardverplatform sajátosságait. Ezt követően a függvényen belüli kódra alkalmazott eljáráson belüli optimalizálás (IPA) párhuzamosítását tervezzük megvalósítani, függetlenül a hívás sajátosságaitól. A korlátozó link jelenleg a szemétgyűjtő, amely egy globális zárat adott hozzá, amely letiltja a szemétgyűjtési műveleteket többszálú üzemmódban (a jövőben a szemétgyűjtőt a GCC többszálas végrehajtására fogják adaptálni).
A teljesítményben bekövetkezett változások értékelésére egy tesztcsomag készült, amely összeállítja a gimple-match.c fájlt, amely több mint 100 ezer sornyi kódot és 1700 függvényt tartalmaz. Az Intel Core i5-8250U CPU-val 4 fizikai maggal és 8 virtuális (Hyperthreading) végzett rendszeren végzett tesztek azt mutatták, hogy az Intra Procedural GIMPLE optimalizálás végrehajtási ideje 7 másodpercről 4 másodpercre csökkent 2 szál futtatása esetén és 3 másodpercre 4 szál futtatása esetén. szálak, azaz. A vizsgált összeszerelési szakasz sebességében 1.72-szeres, illetve 2.52-szeres növekedést értek el. A tesztek azt is kimutatták, hogy a virtuális magok Hyperthreading használatával nem növeli a teljesítményt.
A teljes felépítési idő körülbelül 10%-kal csökkent, de az előrejelzések szerint az RTL optimalizálás párhuzamosítása kézzelfoghatóbb eredményeket tesz lehetővé, mivel ez a szakasz lényegesen több időt vesz igénybe a fordítás során. Körülbelül az RTL párhuzamosítása után a teljes összeszerelési idő 1.61-szeresére csökken. Ezt követően az IPA optimalizálás párhuzamosításával további 5-10%-kal csökkenthető a felépítési idő.
Forrás: opennet.ru