
LLVM/Clang vs. GCC
Niels og jeg sidder og roder med softwaren til en prototype af et "real-time cluster" til ESO's ELT teleskop.
Vi skal lave en masse matematik hurtigt og aflevere resultaterne tidsmæssigt præcist. Det første tager Niels sig af, det andet roder jeg med.
Vi kører på en ren FreeBSD 9 og prøver at bruge så lidt magi som muligt, det giver det mest portable og brugbare resultat for ESO.
Nærmest af vanvare kom jeg til at compilere et af vores benchmarks med LLVM compiler i stedet for GCC og det gav sådan rundt regnet 20% mere performance, bare sådan...
Jeg har siddet og kigget lidt på assemblerkoden og det ligner at LLVM er meget smartere til loop-unrolling og multi-instruction-issue end GCC er.
Men 20% ?!
Niels siger ovenikøbet at han har set 25% på det der formodentlig ender med at være vores færdige kode...
Er der nogen af jer andre der har set noget lignende ?
Er det kun i floating-point sammenhæng, eller ser I tilsvarende forbedringer i al kode ?
phk
PS: ESO har godkendt ELT projektet vores ESO kontakt sagde at en af de ting de skal bruge er firmaer til at lave software QA/Review, meld jer til bigscience.dk, selv små firmaer kan være med.
Poul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (23)
Nu skriver du ikke optimiseringsflagene, men så hudt jeg visker kører LLVM som standard med -O2 og GCC ved -O0 som default.
Hvad har du prøvet af optimeringer?
Det er ikke lige min ekspertise, men har I kigget på http://polly.llvm.org? Så vidt jeg kan se under Performance er deres speedup for matrix multiplikationer i størrelsesordenen x5 i forhold til -O3.
Kan vi ikke få alle relevante compiler switches, evt fulde kommandolinier og hvilken cpu din testmaskine har?
Hvad sker der hvis du bruger -O3 eller -Ofast? Kan vi være sikre på at -O2 er sammenlignelig mellem de to kompilere?
Har i prøvet på andet end FreeBSD 9? Måske har OS også en indflydelse på resultatet.
Det har man kunne gøre i mange år, det er sådan vores installer virker...
Se under "preload" i md(4)
Da jeg skrev speciale for et par år siden i Optimering af McStas, undersøgte jeg bl.a. hvad hhv. ICC, GCC og LLVM præsterede for den givne kodebase (se fig. 4.1, s. 38). LLVM var bagud, men ikke slemt.
Uden jeg har læst op på det, mindes jeg at LLVM/clang generelt klarede sig bedre og bedre, desto "pænere" C jeg fodrede den med. Så det undrer mig ikke at den tre år efter æder kode, skrevet til formålet, råt.
Er der ikke en mulighed for i BSD at tildele beregnings processen (near) realtime prioritet og på den måde fjerne / minimerer OS fra ligningen ?
Har du prøvet i gcc at tilrette:
max-completely-peeled-insns
max-completely-peel-times
gcc er ikke altid en ørn til at indse at smarte i unroll af mange loops, (selv) hvis koden bliver drastisk reduceret af kendte loop-værdier.
GCC har uhyggeligt mange options, og man ofte kan få den til at gøre 'det rigtige'.
Tilgengæld mener jeg også, at det ikke brude være nødvendigt med dette. -Ox burde (set fra programmøreren) være rigeligt - og den burde justere loop-unlopp udfra hvor meget den får reduceret - og ikke efter en hard-codet parameter ...
Angående performance-tab på 25% - så har jeg kun set noget lignende hvis man må tage MS Visual Studio ind i konkurrencen .... :)
Jeg må indrømme at jeg ikke har meget til overs for GCCs underlige options: Det bør ikke være min opgave at læse gcc-kildeteksten igennem for at finde ud af hvilke options jeg skal sætte...
Angående performance-tab på 25% - så har jeg kun set noget lignende hvis man må tage MS Visual Studio ind i konkurrencen .... :)
Interessant - for 10 år siden mener jeg at MSVC var en ret hæderlig compiler til optimeringer. Jeg mener rangordningen var nogenlunde således (bedste øverst):
- Intel
- MSVC / Watcom
- GCC
Og ang. llvm mener jeg også (ca. 1 år gammel viden) at llvm generelt producerede lidt dårligere kode end gcc, men tilgengæld havde en mere clean kodebase. Men det kan jo være den pænere kodebase nu har kapitaliseret sig således at flere har gider tilføje nye optimeringstricks til llvm. Lyder da godt, hvis man således kan få alle fordele ved at bruge llvm.
Du skriver at du bruger en ren FreeBSD 9, så jeg går ud fra at du kører med default-udgaven af GCC deri.
Så vidt jeg kan læse mig frem til er standard-installation af GCC i FreeBSD 9 en temmelig gammel udgave (4.2.1 20070831).
En nyere udgave af GCC vil formentlig give dig bedre performance, måske også bedre end Clang/LLVM, hvis du og ESO kan leve med kompliceringen i at opgradere GCC og licens-skiftet til GPLv3.
Jeg kender ikke til hvordan de optimerer, men det er min klare overbevisning at man i dag bør benytte Clang + LLVM_2.0 frem for GCC. LLVM som modular compiler platform, og med al den fokus den modtager (f.eks. fra Apple via Xcode 4), virker det ikke som om der er megen fremtid for GCC. Der har vist også været noget snak omkring hvorvidt Fedora er på vej væk fra GCC og over til LLVM.
Jeg er ikke religiøs med compilere men jeg har altid fundet det dybt problematisk at GCC havde et så stort monopol.
GCC projektets "kundeservice" lod ikke meget tilbage for det TDC/KTAS i monopoldagene.
På den måde kan man sige at der trods alt er kommet noget godt ud af GPLv3: Det tvang en konkurrent til GCC frem.
Vi brugte -O2 for begge
Jeg arbejder med C99-kode, der ikke kan oversættes med clang, så jeg er nødt til at danse med flodhesten...
Vektorisering af løkker (f.eks. med SSEx instruktioner) kan gøre en stor forskel.
Auto-vektorisering er forbedret i gcc 4.7.
Se også -ffast-math, -ftree-vectorize et al.
Bygger du til samme cpu? Muligvis er gcc mere konservativ en clang i valg af instruktionssæt, og der kan måske også være forskel på hvor godt gcc og clang optimerer afhængig af -march. Prøv evt at gentage eksperimentet med -march=native.
Min erfaring siger mig når man oversætter c++ kode med clang++ at der mangler ca. 5-10% i forhold til gcc. (dette er clang 2.1 som kommer med xcode til Mac OS x)
Der er i hvert fald en gruppe OpenBSD-entusiaster, der er kommet til samme konklusion:
http://www.h-online.com/open/news/item/OpenBSD-forked-to-create-Bitrig-1...
Et software projekt jeg benytter meget i min PhD har haft nogenlunde samme erfaring, dog med en noget højre -Ox
OMNeT++ Network Simulator
"Compiled OMNeT++ with clang and llvm on OS X. Compile times reduced by 10% and has shown 15% percent speedup with -O4. Pretty cool IMHO."
Får vi nogensinde et svar på hvilken version af GCC du brugte i stedet for at gætte på det må være den der er standard i FreeBSD9? :)

