GCC vs. Clang/LLVM: An In-Depth Comparison of C/C++ Compilers

Visual C++, GNU Compiler Collection (GCC), and Clang/Low Level Virtual Machine (LLVM) are three mainstream C/C++ compilers in the industry. A Visual C++ grafikus felhasználói felületeket (GUI-ket) biztosít, és könnyen hibakereshető, de nem alkalmas Linux platformokra. Ezért ez a dokumentum elsősorban a GCC-t hasonlítja össze a Clang/LLVM-rel.

a GCC a GNU által kifejlesztett programnyelv-fordító. Ez egy szabad szoftver, amelyet a GNU General Public License (GPL) és a GNU Lesser General Public License (LGPL) alatt adtak ki. Ez egy hivatalos fordító a GNU és Linux rendszerekhez, valamint egy fő fordító más UNIX operációs rendszerek összeállításához és létrehozásához.

az LLVM modularizált fordítókomponensek és szerszámláncok sorozatát tartalmazza. Képes optimalizálni a programnyelveket és a linkeket az összeállítás, a futási idő, valamint a tétlen idő alatt, és kódot generálni. LLVM szolgálhat a háttérben fordítók több nyelven. Clang egy C, C++, Objective-C, vagy Objective-C++ fordító, amely össze a c++ alapján LLVM alatt kiadott Apache 2.0 licenc. Clang elsősorban arra használják, hogy a teljesítmény jobb, mint a GCC.

hosszú távú fejlesztés és iteráció révén a GCC, a Clang és az LLVM Érett fordítókká váltak az iparban. Akkor melyik fordító jobb? Melyiket használjuk a programok és rendszerek összeállításához és felépítéséhez?

egy jó fordító jelentősége

a Modern processzorok mind szuperskaláris és hosszú csővezetékekkel, valamint komplex belső struktúrákkal rendelkeznek, és támogatják a Vektorkiterjesztési egységeket a komplex utasításkészletben számítógép (CISC) vagy csökkentett utasításkészlet számítógép (RISC) architektúra. Sok olyan program esetében, amely általános számításigényes magokat tartalmaz, a programozók vektor kiterjesztési parancsokat használhatnak a program végrehajtási teljesítményének jelentős javítása érdekében. A mátrix-és vektorműveletekben például a kombinált szorzási és összeadási parancsokat használják a teljesítmény és a pontosság javítására. A bitmaszk parancsokat a vektoros műveletek ágfeldolgozására használják. A legnagyobb teljesítmény elérése érdekében azonban a programozóknak és a fordítóknak továbbra is sok erőfeszítést kell fordítaniuk a feladatok komplex memóriahasználati módokkal és nem szabványos kernelekkel történő kezelésére.

emellett a modern fejlett nyelvek szabványai folyamatosan kivonják a mögöttes hardver – és adatstruktúrák részleteit, hogy általános kódot generáljanak, ami logikusabb és Matematikai, a konkrét kezelési utasítások és a memória elérési utak helyett. A C++ szabványok egyre inkább kifejezőek és elvontak. A Python azért népszerű, mert olvashatóbb és kifejezőbb, még alacsonyabb futási sebesség mellett is. A nagyobb expresszivitás növeli a fordító terhét, hogy jó összeszerelési kódot generáljon a programozók által összeállított komplex struktúrákból. A fordítónak okosabbnak kell lennie, és keményebben kell dolgoznia a teljesítmény maximalizálása érdekében a kód használatával. Nem minden fordító képes erre. A fordító kiválasztásakor először meg kell fontolnunk, hogy ugyanaz a kódszegmens hatékonyabb összeszerelési parancsokat generálhat-e.

a nagy teljesítményű futtatható programok generálása mellett a modern fordítóknak maguknak is nagy teljesítményűnek kell lenniük. A C++-ban lévő nagyméretű szoftverprojekt több száz-ezer egyedi fordítási egységet tartalmazhat. Minden fordítási egység több ezer sornyi kódot tartalmazhat. A C++ kód számos sablon alapú programozási technológiát is használhat. Ezek a technológiák megkövetelik a fordítótól, hogy a célfájl létrehozásához többször továbbítsa a releváns információkat. A nagyméretű C++ projektek összeállítása több órát is igénybe vehet, és a fejlesztés során egyidejűleg több kölcsönösen függő változtatást kell benyújtani. Minden benyújtás megköveteli a fejlesztőktől, hogy a kódkönyvtárak nagy részét újra lefordítsák. Ezért a gyorsabb fordítók (építési eszközök) kritikusak a nagy csapatok magas termelékenységének eléréséhez.

a nyelvbővítés szempontjából a modern, több maggal rendelkező számítástechnikai rendszerek, a vektoros feldolgozási képességek, valamint a gyorsítók olyan képességeket biztosítanak, amelyek meghaladják a közös programozási nyelvek természetes képességeit. Ezért speciális nagy teljesítményű számítástechnikai (HPC) keretek, mint például az OpenMP és az OpenACC, kitölthetik ezt a rést. Ezek a keretek olyan alkalmazásprogram interfészeket (API-kat) biztosítanak, amelyeket a programozók a kód párhuzamosságának kifejezésére használhatnak. A fordítónak és a megfelelő futásidejű könyvtárnak meg kell térképeznie a párhuzamos kódot a processzor architektúrájával. Számos HPC projekt függ az OpenMP és az OpenACC szabványoktól, amelyeket a fejlesztők és a hardvergyártók is kiterjesztenek. Ezért a fordítóknak lépést kell tartaniuk a nyelvi kiterjesztési szabványok fejlesztésével.

összefoglalva, egy jó fordító lehetővé teszi számunkra, hogy a programozás folyamatára összpontosítsunk, nem pedig a hiányosságok elleni küzdelemre. Támogatja a legújabb nyelvi szabványokat, optimalizált parancsokat generál a legelvontabb kódból, majd kevesebb idő alatt lefordítja a forráskódot.

GCC fejlesztési előzmények

a GCC megtanulása előtt először meg kell értenie a GNU projektet. Richard Stallman 1984-ben indította el a GNU projektet egy UNIX-szerű nyílt forráskódú szoftverrendszer létrehozására. A GNU operációs rendszer nem fejlődött ki széles körben az idő múlásával. Ugyanakkor számos kiváló és hasznos nyílt forráskódú szoftvereszközt inkubált, mint például a Make, Sed, Emacs, Glibc, GDB és GCC. Ezek a GNU nyílt forráskódú szoftverek és Linux kernelek együttesen alkotják a GNU / Linux rendszert. Kezdetben a GCC stabil és megbízható fordítókat biztosított a GNU rendszer számára a C programozási nyelv alapján. Teljes neve GNU C fordító. Később több nyelvet (például Fortran, Obj-C és Ada) támogattak, és a GCC teljes neve GNU Fordítógyűjteményre változott.

a GCC-1.0-t Richard Stallman adta ki 1987-ben, több mint harminc évvel ezelőtt. A szoftver szempontjából nagyon régi. Valaki 1989 és 2012 között gyűjtötte össze a GCC fejlesztési rekordjait, és készített egy harminc perces animációs videót (GNU Compiler Collection dev history 1989-2012), amely intuitív módon demonstrálja a GCC fejlesztési folyamatát. A GCC fejlesztési történetéről a következő verziókból tanulhatunk:

• GCC-1.0: Richard Stallman kiadta 1987-ben.
• GCC-2.0: 1992-ben jelent meg és támogatta a C++ – t. Később a GCC közösséget megosztották, mert Richard Stallman a GCC-t a GNU rendszer megbízható C fordítójaként határozta meg, és úgy gondolta, hogy a GCC akkoriban elegendő volt a GNU rendszerhez, és a fejlesztési fókuszt a GCC-ről a GNU rendszerre kell áthelyezni. Más nagy fejlesztők azt remélték, hogy továbbra is fejlesztik a GCC-t, és radikálisabb fejlesztéseket és fejlesztéseket hajtanak végre különböző aspektusokban. Ezek az aktív Fejlesztők 1997-ben elhagyták a GCC közösséget, és kifejlesztették az EGCS villát.
• GCC-3.0: nyilvánvaló, hogy a fejlesztők általában erős vágyat mutattak a jó fordítók iránt. Az EGCS Villa zökkenőmentesen fejlődött, egyre több fejlesztő ismerte fel. Végül az EGCS-t használták az új GCC gerincként, a GCC-3.0 pedig 2001-ben jelent meg. A megosztott közösséget újra egyesítették, de Richard Stallman befolyása bizonyos mértékig gyengült. Ezenkívül a GCC ipari Bizottsága megkezdte a GCC fejlesztési irányának meghatározását.
• GCC-4.0: 2005-ben jelent meg. Ezt a verziót integrálták a Tree Serial Storage Architecture (SSA) – be, a GCC pedig modern fordítóvá vált.
• GCC-5.0: 2015-ben jelent meg. Később a GCC verzió házirendjét módosították, és minden évben kiadtak egy nagyobb verziót. Váratlan előny, hogy a verziószám megfelel az évnek. Például a GCC-7 2017-ben jelent meg, a GCC-9 pedig 2019-ben jelent meg.

most a GCC fejlesztése belépett a”modern krónikába”. Szemben a kompetitív nyomást az LLVM, a GCC közösség aktívan sok kiigazításokat, mint a gyorsuló válogatás javítása a fordítási figyelmeztetés, információ. Az elmúlt 30 évben a GCC a fordító iparág kihívójától a Linux rendszerek mainstream fordítójává fejlődött, most pedig az LLVM kihívásával szembesül. Szerencsére a GCC közösség kiigazításokat hajt végre a GCC fejlődésének felgyorsítása érdekében. Arra számíthatunk, hogy a két összeállítási technológia közötti verseny továbbra is jobb fordítókat biztosít a szoftverfejlesztőknek.

Clang és LLVM fejlesztési története

az LLVM Chris Lattner uuic kutatásából származik 2000-ben. Chris Lattner dinamikus összeállítási technológiát akart létrehozni minden statikus és dinamikus nyelv számára. Az LLVM egy nyílt forráskódú szoftver, amelyet a BSD licenc alapján fejlesztettek ki. Az 1.0 kezdeti verziója 2003-ban jelent meg. 2005-Ben Az Apple Inc. Chris Lattnert és csapatát bízta meg az Apple számítógépek programozási nyelveinek és fordítóinak fejlesztésével, majd az LLVM fejlesztése a gyors sávba lépett. Az LLVM 2.5-től kezdődően évente két kisebb LLVM verzió is megjelent (általában márciusban és szeptemberben). 2011 novemberében megjelent az LLVM 3.0, hogy az alapértelmezett XCode fordító legyen. Az XCode 5 alapértelmezés szerint a Clang és az LLVM 5.0 használatát kezdte el használni. A verzió házirendjét az LLVM 5.0 és a későbbi verziókhoz igazították, évente két fő verzió jelenik meg. A jelenlegi stabil verzió 8.0.

az LLVM nevét először az alacsony szintű virtuális gépről rövidítették. Mivel ez a projekt nem korlátozódik egy virtuális gép létrehozására, az LLVM rövidítést gyakran megkérdőjelezik. Az LLVM kifejlesztése után számos összeállítási eszköz és alacsony szintű szerszámtechnológia együttes kifejezésévé vált, így a név kevésbé megfelelő. A fejlesztők úgy döntöttek, hogy elhagyják a rövidítés mögötti jelentést. Most LLVM vált a hivatalos márkanév, alkalmazható minden projekt alatt LLVM, beleértve LLVM Intermediate képviselet (LLVM IR), LLVM hibakereső eszközök, valamint LLVM C++ standard könyvtárak. Az LLVM hagyományos fordítóként, JIT fordítóként, assemblerként, hibakeresőként, statikus elemzőeszközként, valamint a programozási nyelvekkel kapcsolatos egyéb funkciókhoz is használható.

2012 – ben az LLVM elnyerte az Association for Computing Machinery (ACM) szoftverrendszer díját, valamint olyan hagyományos rendszereket, mint a UNIX, WWW, TCP/IP, TeX és Java. Az LLVM nagymértékben leegyszerűsíti az új programozási nyelvi eszközláncok megvalósítását. Az elmúlt években számos új programozási nyelv, például a Swift, A Rust és a Julia az LLVM-et használta összeállítási keretrendszerként. Emellett az LLVM lett a Mac OS X, iOS, FreeBSD és Android rendszerek alapértelmezett fordítója.

Clang

Clang célja, hogy egy frontend fordító, amely helyettesítheti GCC. Az Apple Inc. (beleértve a következő később) már használja GCC, mint a hivatalos fordító. A GCC mindig jól teljesített, mint egy szabványos fordító a nyílt forráskódú közösségben. Az Apple Inc. saját követelményei vannak az összeállítási eszközökre. Egyrészt az Apple Inc. hozzáadott sok új funkciók az Objective-C nyelv (vagy akár, később, a C nyelv). A GCC fejlesztői azonban nem fogadták el ezeket a funkciókat, és alacsony prioritással támogatták ezeket a funkciókat. Később egyszerűen két ágra osztották őket külön fejlesztés céljából, következésképpen az Apple Inc.által kiadott GCC verzió. sokkal korábban, mint a hivatalos verzió. Másrészt a GCC kód erősen összekapcsolt, és nehezen fejleszthető külön. Ezenkívül a későbbi verziókban a kód minősége továbbra is csökken. Az Apple Inc.által igényelt számos funkció azonban. (mint például a továbbfejlesztett integrált fejlesztési környezet (IDE) támogatás) kell hívni GCC, mint egy modul, de GCC soha nem nyújt ilyen támogatást. Ezenkívül a GCC futásidejű könyvtári mentesség alapvetően korlátozza az LLVM GCC fejlesztését. Szintén korlátozott az engedély, Apple Inc. az LLVM nem használható a GCC alapú kódgenerálás minőségének további javítására. Ezért Az Apple Inc. úgy döntött, hogy írja a frontend Clang a C, C++, objektív-C nyelvek a semmiből, hogy teljesen helyettesíti GCC.

ahogy a neve is sugallja, a Clang csak a C, C++ és az Objective-C. fejlesztést támogatja 2007 – ben, a C fordító pedig először készült el. Clang for Objective – C cloud teljes mértékben használható a termelési környezet 2009-ben. A C++ támogatása is gyorsan haladt. A Clang 3.3 teljes mértékben támogatta a C++ 11-et, a Clang 3.4 teljes mértékben támogatta a C++ 14-et, a Clang 5 pedig teljes mértékben támogatta a C++ 17-et, és mindegyik jelentősen megelőzte a GCC-t abban az időben.

Clang/LLVM and GCC Community

mint más nyílt forráskódú szoftver közösségek, a GCC közösség uralja szabad szoftver rajongók, hackerek. A fejlesztési folyamat során a GCC közösségi irányítási és részvételi mechanizmusai fokozatosan alakulnak ki. Jelenleg a GCC közösség egy viszonylag stabil és jól definiált ismerős társadalom, amelyben minden személy világos szerepek és feladatok:

• Richard Stallman és Free Software Foundation( FSF): bár ritkán vesz részt a GCC közösségi menedzsment, Richard Stallman és FSF még mindig levált engedély és jogi ügyek.
• GCC Ipari bizottság: Irányítja a GCC közösségi ügyeit, a technológiafüggetlen GCC fejlesztési témáit, valamint a felülvizsgálók és karbantartók kinevezését és bejelentését. Jelenleg 13 tagja van.
• globális karbantartók: ők uralják a GCC fejlesztési tevékenységeit. Bizonyos mértékig meghatározzák a GCC fejlődési trendjét. Jelenleg 13 globális karbantartó van, akik nem mindannyian hivatalba lépnek a GCC ipari bizottságában.
• Frontend, middle-end és backend karbantartók: ők a frontend, backend és egyéb modulok karbantartói. Ők felelősek a megfelelő GCC modul kódjáért, sokan közülük a modul kódjának fő közreműködői. Érdemes megjegyezni, hogy a bírálókat általában ebbe a csoportba sorolják. A különbség az, hogy a felülvizsgálók nem hagyhatják jóvá saját javításukat, míg a karbantartók saját felelősségükön belül saját módosításokat nyújthatnak be a felülvizsgálók jóváhagyása nélkül.
• közreműködők: ők a GCC közösség legszélesebb fejlesztői csoportjai. A szerzői jogi megállapodás aláírása után bármely fejlesztő kérheti az írást a közösség jóváhagyása után, majd saját maga is benyújthatja a kódot.

mint más nyílt forráskódú közösségek, az érett GCC közösséget már nem a hackerek uralják. A kereskedelmi vállalatok fontos szerepet játszottak a közösségben, mint például a fejlesztők toborzása és a fejlesztési találkozók szponzorálása. Jelenleg a GCC közösséget a következő típusú kereskedelmi vállalatok uralják:

• rendszergyártók, elsősorban a RedHat és a SUSE.
• chipgyártók, elsősorban Intel, ARM, AMD és IBM (PowerPC).
• speciális gyártók, mint például a CodeSourcery és szerszámlánc szolgáltatók, mint például az AdaCore az Ada nyelv alapján. CodeSourcery volt egy ragyogó története toborzott sok híres fejlesztők, de csökkent, miután megszerezte a Mentor.

a jelenlegi GCC közösségben a chipgyártók uralják a backend fejlesztését, míg a rendszergyártók más fejlesztési területeket irányítanak. A közösségfejlesztés szempontjából a GCC kód jelenleg saját SVN szerverén található. A fejlesztés és a benyújtás megkönnyítése érdekében Git API-t biztosítunk. Patch felülvizsgálat hasonló, hogy a Linux Kernel közösség használja a Levelezőlista formájában. Mint már említettük, a GCC közösség viszonylag stabil (vagy zárt) ismerős társadalom. A közösségnek alapvetően évente 150-200 aktív közreműködője van, és minden év szeptemberében fejlesztői konferenciát tart. 2019 szeptemberében a fejlesztői konferenciát Montrealban, Kanadában tartják.

LLVM közösség

az LLVM közösség egy noob-Barát fordító közösség. Gyorsan válaszol az új felhasználók kérdéseire, valamint a javító felülvizsgálatokra. Ez az alapja és forrása a későbbi LLVM alapítványi megbeszéléseknek, valamint az LLVM közösségi magatartási kódexének elfogadásának, és egy sor politikailag korrekt vitát vált ki.

az összes LLVM projektet és problémát a DevExpress e-mail listán keresztül tárgyaljuk, a kód beküldését pedig a commit e-mail listán keresztül értesítjük. Az összes hibát és funkciómódosítást a hibalistán keresztül követjük nyomon. A benyújtott javításokat a mesterágak számára ajánljuk. A stílus megfelel az LLVM kódolási szabványoknak, a kód felülvizsgálata pedig a Phabricator segítségével történik. Jelenleg az LLVM kódtár átkerült a githubra.

a GCC közösséggel ellentétben az LLVM közösségnek csak az LLVM alapja van. Az LLVM Alapítványnak nyolc tagja van. Az LLVM közösségi ügyeinek kezelése mellett az LLVM Alapítvány minden tagjának irányítania kell a technológiával kapcsolatos LLVM fejlesztési kérdéseket. Jelenleg az elnök Tanya Lattner, Chris Lattner felesége. Maga Chris Lattner is tagja az alapítványnak, és erős befolyással van az LLVM közösségére és az LLVM fejlesztési irányára.

az LLVM közösségben a kódértékelési politika alapvetően megegyezik a GCC közösségben alkalmazott politikával. A különbség az, hogy az LLVM gyors fejlődése miatt sok közreműködőnek nincs hozzáférési engedélye, kódját a karbantartókon keresztül kell benyújtania. Jelenleg a Klang és LLVM közösségekben évente több mint 1000 közreműködő van. Általában évente áprilisban és októberben tartanak fejlesztői konferenciákat. A fejlesztői konferencia októberben 2019, kerül sor San Jose, USA.

az LLVM licenc az UIUC licencről az Apache 2.0 licencre változik LLVM kivételekkel. Elsősorban annak a problémának a megoldására használják, hogy az LLVM runtime könyvtár MIT licencen alapul, a projekthez szükséges szabadalmi engedély pedig túl kiterjedt. A jelen Licenc alapján az LLVM lehetővé teszi bárki számára, hogy korlátozás nélkül SZÁRMAZTASSON kereskedelmi termékeket az LLVM-ből, és nem követeli meg, hogy bármely származékos termék nyílt forráskódot biztosítson, ezáltal elősegítve az LLVM széles körű használatát, beleértve:

1. az LLVM letöltése vagy használata részben vagy egészben személyes, belső vagy kereskedelmi célokra. Az LLVM kód módosítása anélkül, hogy hozzájárulna a projekthez.
2. LLVM-et tartalmazó csomag vagy kiadási verzió létrehozása. Az LLVM társulása az összes többi nagy nyílt forráskódú licenc által engedélyezett kóddal (beleértve a BSD, MIT, GPLv2 és GPLv3).
3. az LLVM ismételt terjesztésekor meg kell őriznie a szerzői jogi értesítést. Nem törölheti vagy cserélheti ki a szerzői jogi fejlécet. Az LLVM-et tartalmazó bináris fájlnak tartalmaznia kell a szerzői jogi értesítést.

teljesítmény összehasonlítás GCC és LLVM között

architektúra: x86_64
Processzor: Intel (R) Xeon (R) Platinum 8163 CPU @ 2.50 GHz
L1 adat gyorsítótár: 32 KB
L2 gyorsítótár: 1,024 KB
L3 gyorsítótár: 33,792 KB
memória: 800 GB
operációs rendszer: Alibaba Group Enterprise Linux Server release 7.2 (Paladin)
kernel: 4.9.151–015.ali3000.alios7.x86_64
Fordító: Clang/LLVM 8.0 GCC8.3.1

Benchmark

SPEC CPU 2017 egy sor CPU alrendszer teszt eszközök tesztelésére a CPU, cache, memória, és fordító. Tartalmaz 43 vizsgálatok a négy kategóriában, beleértve SPECspeed 2017 INT, valamint FP, hogy a teszt az egész, sebesség, lebegőpontos művelet sebesség, SPECrate 2017 INT, valamint FP, hogy a teszt az egész konkurens ráta pedig lebegőpontos konkurens arány. Clang nem támogatja a Fortran nyelvet. Ezért ebben a példában a SPEC Speed test set C / C ++ programjait használjuk a Clang és a GCC által generált bináris programok egymagos teljesítménykülönbségének tesztelésére. Az alábbi táblázat a SPEC CPU2017 C és C++ készleteket sorolja fel:

Cint2017 SpeedCFP2017 Speed600.perlbench_s619.lbm_s602.gcc_s644.nab_s605.mcf_s620.omnetpp_s623.xalancbmk_s625.x264_s631.deepsjeng_s641.leela_s657.xz_s

vizsgálati módszerek

az LLVM-lnt automatizálási keretrendszer a teszt elvégzésére és a teljesítmény összehasonlítására szolgál. Ugyanúgy fut, mint a SPEC CPU runcpu-ja. Az LLVM-lnt futtatása előtt a gyorsítótár (echo 3 > /proc/sys/vm/drop_caches) törlődik, majd a tesztadatkészlet fut. Ezután a ref adatkészlet háromszor fut. A három ref vizsgálati eredmény átlagos értékét használják végeredményként. A CPU-átállás vagy a kontextuskapcsoló által okozott teljesítményingadozások csökkentése érdekében a tesztadatkészleten futó folyamatok a CPU affinity eszköz használatával a CPU-maghoz kötődnek. A fordítási idő teszthez ez a módszer az 1.szálat használja a tesztprogram felépítéséhez, valamint a hosszú ideje összeállított tesztelemek összehasonlításához. A fordítási idő nem tartalmazza a linker végrehajtási idejét. Ez csak azt az időt tartalmazza, amikor az összes tesztprogram összes forrásfájlja létrejön.

összeállítási teljesítmény összehasonlítás

a GCC összeállítási folyamata a következő: olvassa el a forrásfájlt, dolgozza fel a forrásfájlt, konvertálja IR – re, optimalizálja és generálja az összeszerelő fájlt. Ezután az összeszerelő létrehoz egy objektumfájlt. Clang és LLVM nem támaszkodnak független fordítók, de integrálja saját megvalósítású fordítók a backend. Az összeszerelési fájlok generálásának folyamata elmarad az objektumfájlok generálásának folyamatában. Az objektumfájl közvetlenül az IR-ből származik. Ezenkívül a GCC IR-hez képest az LLVM IR adatstruktúrája tömörebb. Kevesebb memóriát foglal el az összeállítás során, és támogatja a gyorsabb áthaladást. Ezért a Clang és az LLVM előnyös a fordítási idő szempontjából, amit a SPEC-összeállításból származó adatok is bizonyítanak, amint az az alábbi ábrán látható. A Clang 5-10%-kal csökkenti az egyszálú fordítási időt a GCC-hez képest. Ezért a Clang több előnyt kínál nagy projektek építéséhez.

Összehasonlítása SPEC összeállítási idő

Összehasonlítása Végrehajtás Teljesítmény

a Legtöbb felhő terhelés szükség, hogy az alkalmazások futnak a különböző klaszterek. Ezen alkalmazások létrehozásakor ne adjon meg géppel kapcsolatos paramétereket. A keresletváltozások által okozott gyors iterációhoz való alkalmazkodáshoz a helyiségen kívüli munkaterheléseknek is hibakereshetőnek kell lenniük. Ezért, eltekintve néhány stabil és közös könyvtárak, amelyek lehetővé teszik a magas összeállítási optimalizálási szint, a munkaterhelés maga egy alacsony összeállítási és optimalizálási szint (O2 vagy alatti). Ennek a követelménynek a teljesítéséhez ez a dokumentum összehasonlítja a különböző fordítók teljesítményét az INT sebességű programok O2 és O3 optimalizálási szintjein, az alábbi ábrán látható módon:

Teljesítmény összehasonlítása a SPEC CPU2017 INT Sebesség

GCC rendelkezik az 1% – ról 4% – os teljesítmény előnye Csenget, majd LLVM a legtöbb program a O2, valamint O3 szinten, átlagosan pedig egy körülbelül 3% – os teljesítmény előnye SPEC CPU2017 INT Sebesség. Ami a 600.perlbench_s és 602.gcc_s / O2, GCC van egy nagy teljesítmény előnye (több mint 10%). Ez a két tesztelem nem rendelkezik kiemelkedő hotspotokkal, és tükrözheti a fordító átfogó optimalizálási hatását. A vizsgálati eredmények azt mutatják, hogy a GCC mindig előnyös a teljesítmény optimalizálásában. Két AI-vel kapcsolatos program esetében azonban, beleértve a 631-et is.deepsjeng_s és 641.a SPEC teszthez újonnan hozzáadott leela_s, Clang és LLVM több mint 3% – kal javítja a teljesítményt a GCC-hez képest. Ez tükrözi az LLVM gyors előrehaladását az optimalizálás szempontjából. A 625. x264_s O2 optimalizálás, az LLVM 40% – kal javítja a teljesítményt, mivel az eset hotspotja megfelel a vektorizált szabályoknak. De a Clang és az LLVM optimalizálja a vektorokat O2 szinten, míg a GCC optimalizálja a vektorokat O3 szinten. A vektorizált programok kivételével a GCC nem javítja jelentősen az O3 szintű teljesítményt az O2 szinthez képest. Más szavakkal, a programok nem érzékenyek a GCC O3 optimalizálására. Ezzel szemben a Clang és az LLVM jelentősen javítja egyes programok (például 600) teljesítményét. perlbench_s és 602. gcc_s) O3 szinten.

a HPC programok, például az FP sebesség, általában csúcskategóriás kiszolgálókon futnak. Ezek stabil Core algoritmusok, magas követelmények teljesítményhez kapcsolódó vektorizáció, párhuzamosság, és lehetővé teszi a magas szintű optimalizálás (O3 vagy újabb). Ezért ez a dokumentum összehasonlítja a teljesítményt az O3 + march = native (skylake-avx512) optimalizálási szinten, az alábbiak szerint:

a spec cpu2017 FP sebesség összehasonlítása

a két FP program esetében a GCC körülbelül 3% – kal javíthatja a teljesítményt. Clang és LLVM konzervatív in loop optimalizálás, így nem előnyös a teljesítmény. A Clang és LLVM Polly alprojektje azonban egy magas szintű loop és data locality Optimizert biztosít, amelyet széles körben alkalmaznak a gépi tanulásban, a nagy teljesítményű számítástechnikában és a heterogén számításoptimalizálásban. Úgy gondolom, hogy a Polly nagyban javíthatja a vektorizációs és párhuzamossági szabályoknak megfelelő hotspot hurkokat tartalmazó programok teljesítményét. A Polly teljesítményét egy sor referenciaértékben és munkaterhelésben is elemezni fogom.

Záró megjegyzések

a fenti benchmarking tesztekből láthatjuk, hogy a Clang több előnyt kínál nagy projektek építéséhez, míg a GCC mindig előnyös a teljesítmény optimalizálásában. A bla függ az adott alkalmazás

amellett, hogy a teljesítmény összehasonlítás, szeretném megosztani az előnyeit és hátrányait GCC és Clang és LLVM:

előnyei GCC

• GCC támogatja több hagyományos nyelven, mint Clang és LLVM, mint például Ada, Fortran, és Go.
• a GCC több kevésbé népszerű architektúrát támogat, és korábban támogatta a RISC-V-t, mint a Clang és az LLVM.
• a GCC több nyelvi kiterjesztést és több assembly nyelvi funkciót támogat, mint a Clang és az LLVM. A GCC továbbra is az egyetlen lehetőség a Linux kernel összeállítására. Bár a kutatás kernel összeállítása segítségével Clang és LLVM is beszámoltak az iparban, a kernel nem lehet összeállítani módosítása nélkül a forráskód és összeállítás paramétereit.

A Clang és az LLVM előnyei

• a feltörekvő nyelvek az LLVM keretrendszereket használják, mint például a Swift, Rust, Julia és Ruby.
• Clang és LLVM szigorúbban felelnek meg a C és C ++ szabványoknak, mint a GCC. GNU Inline és egyéb problémák során GCC frissítés nem fordulnak elő.
• a Clang néhány kiterjesztést is támogat, például a szálbiztonsági ellenőrzés attribútumait.
• Clang további hasznos eszközöket, mint például a scan-build és clang statikus analyzer statikus elemzés, clang-formátum és clang-tidy szintaxis elemzés, valamint a szerkesztő plug-in Clangd.
• Clang pontosabb és barátságos diagnosztikai információkat nyújt, valamint kiemeli a hibaüzeneteket, a hibavonalakat, a hibavonal-utasításokat és a javítási javaslatokat. Clang a diagnosztikai információkat jellemzőnek tekinti. A diagnosztikai információkat csak a GCC 5.0-ról kezdték javítani, majd a GCC 8-ban éretté váltak.

(eredeti cikk: ma Jun马骏)