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.

Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Morten Siebuhr

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.

  • 5
  • 0
Thorbjørn Andersen

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 .... :)

  • 3
  • 0
Morten Andersen

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.

  • 8
  • 0
Thomas Fach-Pedersen

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.

  • 3
  • 0
Casper Bang

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.

  • 1
  • 0
Poul-Henning Kamp Blogger

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.

  • 8
  • 0
Thomas Søndergaard

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.

  • 0
  • 0
Log ind eller Opret konto for at kommentere