Farvel og tak til GCC: FreeBSD overvejer ny compiler

Compileren LLVM kan forbedre ydelsen af operativsystemet FreeBSD markant, og derfor overvejer holdet bag seriøst at sylte kongen af open source-compilerne, GCC.

Holdet bag det frie operativsystem FreeBSD overvejer seriøst at smide den kendte open source-compiler GCC på møddingen og erstatte den med opkomlingen LLVM.

LLVM kan nemlig både oversætte operativsystemets kodebase omkring dobbelt så hurtigt som GCC, og derudover kan afviklingen af LLVM-oversat FreeBSD-kode i visse tilfælde speedes op med 20-30 procent.

Det fortæller et af de danske medlemmer af FreeBSD-projektet, Erik Cederstrand, til Version2.

Han arbejder til daglig som systemudvikler hos Simcorp, men Erik Cederstrands fritidsarbejde med automatiserede performancetests af FreeBSD taler sit tydelige sprog til fordel for LLVM.

»Selvom LLVM kun lige akkurat er kommet frem som en 'ordentlig' C-compiler, har den allerede vist performanceforbedringer på 20-30 procent i visse henseender. Og den tid, det tager at oversætte FreeBSD-kodebasen, er omkring den halve sammenlignet med GCC,« fortæller Erik Cederstrand.

Den snart 22 år gamle sværvægter GCC ? GNU Compiler Collection - har i mange år været den foretrukne open source-compiler, når navnligt C-kode skal oversættes.

Og det er da endnu heller ikke lykkedes LLVM, der blev startet op i 2000 på University of Illinois at Urbana-Champaign, USA, at vippe GCC af pinden.

LLVM oversætter 95 % af FreeBSD-koden
Men mindre kan også gøre det - i hvert fald for FreeBSD - for LLVMs resultater har været så overbevisende, at FreeBSD-projektet på det seneste har gennemført et egentligt forsøg på at skifte fra GCC til LLVM, fortæller Erik Cederstrand.

LLVM - Low Level Virtual Machine - er oprindeligt designet til at give forbedringer af ydelsen på både compile-, link- og runtime og understøtter en række sprog, blandt andre C, C++ og Fortran.

Indtil videre slipper LLVM dog kun af sted med at kunne oversætte omkring 95 procent af FreeBSD's kodebase, og det er grunden til, at det fulde spring fra GCC til LLVM endnu ikke er taget.

Ifølge Erik Cederstrand er det svært at sige, hvor længe der går, før de sidste fem procent er på plads.

»Lige nu er der seks bugs i LLVM's bugzilla, som vi ved står i vejen. Men selvom de skulle blive rettet, er det ikke umiddelbart til at sige, om koden så giver det rigtige output, selvom den compiler,« fortæller Erik Cederstrand.

Google med på vognen
For nylig har Google meldt ud, at implementeringen af Unladen Swallow ? Googles egen implementering af Python-sproget ? kommer til at basere sig på LLVM - netop for at hente procenter hjem på ydelsen af Unladen Swallow, der gerne skulle blive mindst fem gange hurtigere end Pythons mest udbredte udgave, CPython.

Version2 har spurgt en lille håndfuld danske udviklingshuse, der bruger GCC, om de kender LLVM og har overvejet LLVM som et alternativ.

Virksomhederne Ange Optimization og Ifad TS melder indtil videre pas til begge spørgsmål, men hos udviklingshuset Prevas fortæller softwareudvikler Thomas Ammitzbøll-Bach, at man er opmærksom på LLVM's eksistens.

Indtil videre er GCC dog én blandt flere gennemtestede og veldokumenterede compilere, som virksomheden vælger at holde fast i.

»Vi udvikler til mange forskellige platforme, blandt andet PowerPC og ARM, og det gode ved GCC er, at vi kan optimere koden til de forskellige platforme. Det betyder, at vi nemt kan udvikle koden på én platform og afvikle den på en anden,« siger Thomas Ammitzbøll-Bach.

»Vi bruger primært GCC til vores C-kode, og kvaliteten af den oversatte kode er meget høj,« tilføjer han.

Derfor er Prevas indtil videre forsigtig med at bevæge sig væk fra GCC, når det gælder virksomhedens C-kode.

»Hver gang man tager et nyt værktøj i brug, indfører man en ny usikkerhedsparameter. Men vi kigger hele tiden på nye teknologier, og der er da meget, der ser lovende ud omkring LLVM,« siger Thomas Ammitzbøll-Bach.

FreeBSD minder om UNIX uden dog at være en UNIX-klon, og systemet kendes bl.a. også fra Apples Mac OS X, der låner dele af FreeBSD-koden i kernen.

Siden 2005 har Apple haft en fast gruppe udviklere i gang med at arbejde på LLVM.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Esben Nielsen

Ja, det er utroligt, som FreeBSD folkene kan hjælpe Microsoft, GreenHill og andre, der føler sig pressede af Linux, til at sprede FUD omkring GPL. Jeg kan godt se at et lille garage firma måske kan have lidt svært ved at overholde GPL; men for et hver seriøst firma, som har styr på sin versionsstyring, er der altså ikke noget problem. Og GPLv3 er altså ikke stort anderledes en GPLv2, man kan blot ikke lade GPLv3 kode være "låst" på f.eks. en mobiltelefon. Men den forskel er jo ikke relavant for GCC...

  • 0
  • 0
Helge Svendsen

"Ja, det er utroligt, som FreeBSD folkene kan hjælpe Microsoft, GreenHill og andre, der føler sig pressede af Linux, til at sprede FUD omkring GPL"

Sikke en gang ævl.

Bare fordi nogen tillader sig at tænke lidt anderledes end man lige gør i GPL regi. Præcis det sådan GPL folket selv ser sig ift. eks. Microsoft.

GPL != OSS.

Måske du burde bide mærke i, at der var målt en 20-30% hastighedsforskel. Det er noget der batter, når man taler om en kernel compiler.

  • 0
  • 0
Lars Lundin

llvm har en gcc kompatibel front-end, så det er nemt at afprøve llvm, hvis man allerede bruger gcc.

Den software jeg arbejder lader jeg hver nat oversættte på en halv snes forskellige systemer, bl.a. en Ubuntu 8.04 med llvm 1.8 og siden i forgårs en Ubuntu 9.04 beta med den seneste llvm 2.5.

Fordelen ved det er, at llvm kan give advarsler om problematisk kode, som gcc uden videre accepterer.

  • 0
  • 0
Lars Balker

Det er altid en god ide at lade flere compilere massere samme kode (og gerne samme compiler med flere forskellige optimeringsflag osv.) for at ryge underlige bugs ud.

Det hjælper selvf. hvis man har en fornuftig test-suite ;-)

  • 0
  • 0
Esben Nielsen

Nu er det altså dig som ævler. Jeg skriver intet om at LLVM er en dårlig compiler, at jeg ikke vil bruge den fordi den ikke er distribueret under GPL. Hvis den er bedre forventer jeg da, at den også bliver brugt i diverse Linux distributioner.

Jeg skælder ud over er at nogle FreeBSD folk aktivt spreder løgne og forvirring om GPL netop i stedet for at samarbejde med andre OSS folk. Det er som om, at nogle FreeBSD er misundelige over Linux's succes, at de må ty til skræmmekampagner over GPL i samarbejde med leverandøre af propriatære systemmer.

Og din bibemærkning "og især GPL 3 gør det" er af den type: Lige pludselige er GPLv3 noget meget værere i FreeBSD end GPLv2. Uuh, hvor skal vi være bange! Vrøvl: De passer lige dårligt ind i FreeBSD, som jo netop frit skal kunne modificeres og redistribueres i sit fulde uden at skulle sende source koden med.

  • 0
  • 0
Helge Svendsen

"Jeg skælder ud over er at nogle FreeBSD folk aktivt spreder løgne og forvirring om GPL netop i stedet for at samarbejde med andre OSS folk. Det er som om, at nogle FreeBSD er misundelige over Linux's succes, at de må ty til skræmmekampagner over GPL i samarbejde med leverandøre af propriatære systemmer."

Jeg bruger både FreeBSD og linux.

Men efter at have læst det her vil jeg da helt klart overveje om linux måske var en fejltagelse.

"Og din bibemærkning "og især GPL 3 gør det" er af den type: Lige pludselige er GPLv3 noget meget værere i FreeBSD end GPLv2...."

Ikke min kommentar. Men godt gået alligevel.

Signing off.

  • 0
  • 0
Thomas Ammitzbøll-Bach

Okay Esben, jeg vil gerne svare.

Jeg er selv Linux-mand. Jeg har brugt Linux siden 1994, og jeg bruger Ubuntu som dagligt operativsystem. Det er egentligt revnende ligegyldigt, hvad jeg bruger eller ikke bruger, men nu er beskyldningerne allerede fløjet gennem luften, så jeg vil lige præcisere, at jeg er ikke en af "de grimme" BSD'ere eller "de onde" Microsoft-tilhængere.

BSD-licensen og GPL-licensen har to forskellige formål. BSD-licensen har til formål at sikre, at alle kan bruge kildeteksterne til BSD-software til det, de vil. GPL-licensen har til formål at sikre softwarebrugere kan få kildeteksten til det compilet software, de bruger, og selv kan udnytte det i andre sammenhænge.

Der er nogen, der tror, at GPL sikrer, at den oprindelige udvikler har ret til ændringer i hans kildetekster. Det sikrer GPL sådan set ikke. Den sikrer, at dem, der aftager software omfattet af GPL, kan få kildeteksterne til netop den version, de har aftaget. Hvis Ole distribuerer SuperVision under GPL, hvorefter Michael videreudvikler det til SuperVisionPlus og sælger resultatet til Anders, så har Anders ret til at få kildeteksterne til SuperVisionPlus under GPL, men hverken Michael eller Anders behøver at give kildeteksterne til SuperVisionPlus tilbage til Ole. Men Michael kan ikke forhindre Anders i at bruge SuperVisionPlus-kildeteksterne eller give dem til andre, herunder Ole.

BSD-udviklerne ser det ikke som noget tab, at andre bruger deres kildetekster uden at videregive dem. Hvis nogen laver et afledt produkt under en anden licens (bare man angiver copyright og acceptere ansvarsfraskrivelsen), så er det helt cool. Faktisk er formålet netop, at alle kan bruge BSD så frit som muligt. Udviklerne mener ikke, at der går skår af dem, for de udvikler jo ikke for at revolutionere verden, men for at lave det BSD så godt som muligt.

Fordi målet er et så frit anvendeligt system som muligt, er GPL faktisk en klods om benet på deres mål. At der er software (herunder GCC) i BSD, der under GPL, det har de lært at leve med (og respekterer!), men det er ikke spor odiøst i, at de ønsker en compiler med en anden licens.

Enhver, der udvikler software, har ret til at bestemme, hvilke vilkår de stiller for at anvende deres software. Hvis du ønsker at frigive under GPL, så gør dog det. Hvis jeg ønsker at frigive under BSD, så gør jeg det. Hvis jeg ikke kan bruge dit software, fordi det forhindrer mig i at frigive det under BSD, så har jeg ret til at vælge det fra, sådan er det. Den, der betaler musikken, må også bestemme, hvad den skal spille.

FUD er en forkortelse for "Fear, uncertainty and doubt". Jeg har aldrig mødt en BSD'er, der fortalte, at GPL var farligt, uforudsigeligt eller utroværdigt. Det, som BSD'erne siger, er, at GNU har et andet mål end BSD. Det er ikke FUD!

Thomas

PS: Hvis man søger lidt i historien, så vil man se, at jeg tidligere har debatteret for GNU-udvikleres ret til at frigive under GPL og bevare retten til sin software. Jeg er ikke "for" eller "imod" den ene eller den anden licens. Jeg er tilhænger af personlig frihed til at frigive sit eget software med den licens, der passer en.

  • 0
  • 0
Lars Balker

Tak Thomas. Jeg gad ikke helt skrive så meget om situationen :-)

Bemærk at GPL forhindrer at Linux kan bruge spændende teknologier som ZFS og dtrace, og at det på en eller anden måde er Suns skyld.

Tænk desuden over hvor dårligt internettet formentligt ville fungere, hvis der kun var lavet IP-stakke med propriætære licenser eller GPL, istedet for at Microsoft og mange andre firmaer bare kunne bruge BSDs.

  • 0
  • 0
Esben Nielsen

Jeg er ret træt af, at folk skyder mig noget i skoene. I læser jo ikke, hvad jeg skriver; men en hel masse jeg ikke har skrevet! Jeg har udemærket forstået principperne bag både GPL og BSD licensen, og kender forskellen. Og jeg forstår, hvorfor FreeBSD folk ikke bryde sig om at have GPL kode med i distributionen. Hvis du havde gidet læse den sidste sætning mit sidste indlæg, ville du vide det.

Jeg er bare træt af at nogle BSD folk ikke vil (eller kan) forstå GPL og gør problemerne størrer end de er.

"FUD er en forkortelse for "Fear, uncertainty and doubt". Jeg har aldrig mødt en BSD'er, der fortalte, at GPL var farligt, uforudsigeligt eller utroværdigt."

Jeg har mødt sådanne BSD folk. Og hvis jeg havde tid kunne jeg finde eksempler på nettet.

Jeg siger det igen, når du ikke forstod det før: Bemærkningen om at GPLv3 skulle være særlig slem for FreeBSD, kommer som taget direkte ud af en FUD kampagne om GPL.

Jeg vil vedstå, at jeg i mit første indlæg burde have skrevet "nogle BSD folk" istedet for "FreeBSD folkene". Men derudover holder min kritik: Nogle *BSD folk understøtter FUD kampagner mod GPL.

  • 0
  • 0
Erik Cederstrand

Ærgerligt, at det skulle blive en krig om licenser i stedet for en diskussion af LLVM.

Selvfølgelig betyder licensen noget for FreeBSDs valg af compiler. Der accepteres som udgangspunkt ikke andre licenser end BSD i styresystemet, og GPL er ikke kompatibel med BSD. Derfor har GCC længe været en torn i øjet, ikke fordi det er en dårlig compiler, men netop på grund af licensen. GCC er heldigvis en fremragende compiler, og derfor har realiteterne vundet over ideologien.

Nu bliver bøtten måske vendt på hovedet, idet LLVM er ved at blive en teknisk bedre løsning end GCC. Det er jo glædeligt for alle, uanset licens-tilhørsforhold.

Jeg er sikker på at der findes talrige eksempler på software-gratister, der drager fordel af BSD-licensen, men som jeg ser det, er LLVM et prima eksempel på BSD-licensen "in action". Der kom først rigtig gang i LLVM, da Apple hyrede en af hovedkræfterne bag. Og det gjorde de kun, fordi licensen tillader Apple at distribuere LLVM med deres produkter uden at skulle publicere deres egne modifikationer. Apple bidrager nu massivt til udviklingen af LLVM til glæde for alle andre (jeg vil tro at mindst halvdelen af alle commits kommer fra Apple), og får samtidig glæde af universitetsforskning, Google Summer-of-Code projekter og andre bidrag. Både kapitalisterne og anarkisterne er glade.

For mig er det mest interessante ved LLVM (og den tilhørende Clang frontend) nu stadig på det tekniske plan. Overskueligt, modulært design, mulighed for optimering på tværs af source-filer, statisk analyse og imponerende resultater for både kompileringstid og den kompilerede kode.

  • 0
  • 0
Thomas Ammitzbøll-Bach

Ja, jeg svarer lige lidt tilbage, Esben.

Jeg er ked af, du er så træt. Du er træt af mig og du er træt af nogle BSD-folk. Jeg fornemmer også, at det er en meget gammel vrede, der kommer op i dig, og det er derfor, du kører på, som du gør. Det er okay, jeg tager det ikke personligt.

Det, der gør GPLv3 sværere for BSD-projektet er flere ting, men først og fremmest begrebet "Tivoization". GPLv3 begrænser muligheden for at bruge (lukket) hardware-validering af binære kørselsfiler. Uden at gå ind i en lang tirade om det, betyder det, at man ikke må bruge GPLv3-programmer på sådanne platforme, uanset om kildeteksterne er modificerede eller ej, med mindre der er en klar måde at selv installere en anden hardwarenøgle.

Hvis der er dele af afviklingssystemet (altså ikke compileren, som artiklen handler om) i BSD, der er under GPLv3, kan de dele ikke anvendes på sådanne platforme, offentliggjorte kildetekster eller ej.

Igen er det jo et spørgsmål om forskellige mål, og det er da et legitimt mål for GNU at bekæmpe sådanne platforme; men at påstå, at GPLv3 ikke øger kløften mellem BSD og GNU, det er direkte usandt.

BSD-udviklerne er ikke bange for GPLv3, de router bare udenom. I ryggen har de faktisk Linus Torvalds, som ligeledes er uenig i problemet med Tivoization.

Thomas

PS: En præcisering i forhold til min udtalelse i selve artiklen. Prevas er meget tilfreds med GCC og er, bl.a. fordi vi har stor tillid til kvaliteten af maskinkoden, GCC's back-end producerer, til den brede vifte af platforme, som vi udvikler til. GCC er kendt teknologi, og vi kender de (meget få) knirk, den har.

LLVM er imidlertid meget lovende, og den kan på længere sigt godt vise sig, qua sin stærke intermediære arkitektur, at blive den bedste cross-compiler. Det tester vi løbende, internt.

  • 0
  • 0
Jesper Louis Andersen

LLVM er egentlig en stor værktøjskasse som sprogudviklere kan få del i og udnytte til at lave forskellige programmeringssprog. Ideen baserer sig på at man skriver til en virtuel maskine, som så kan oversættes til maskinkode på et utal af platforme. Forskellen, set i forhold til andre virtuelle maskiner, såsom Javas JVM eller Microsofts CIL i .NET er at den virtuelle maskine stort set er en statisk typet assembler.

Der er så et projekt, clang, der giver oversættelse af (blandt andet) C til LLVMs bytecode. Den kan så oversættes videre til maskinkode, fortolkes, etc.

Det fede ved LLVM er at du har masser af værktøjer til at arbejde direkte med LLVM bytecoden, og det gør det nemt at udvikle sprog. Det har den konsekvens at det er nemmere at bygge skræddersyede programmeringssprog til et givent formål og så samtidigt få dem til at køre hurtigt. Det har tidligere været meget tidskrævende at opnå.

LLVMs største svaghed pt er at deres Garbage Collection intrisics godt kunne være lidt stærkere end de er. Men koden er jo heldigvis åben, så hvis der ikke er andre som fixer det inden jeg rammer den flaskehals, så... :)

  • 0
  • 0
Esben Nielsen

"Jeg er ked af, du er så træt. Du er træt af mig og du er træt af nogle BSD-folk. Jeg fornemmer også, at det er en meget gammel vrede, der kommer op i dig, og det er derfor, du kører på, som du gør. Det er okay, jeg tager det ikke personligt."

Nej, du tager helt fejl. Jeg tog det ikke personligt. Det var der tilgengæld andre i dette forum, som gjorde. Jeg blev først gal, da jeg blev beskyldt for at sige en masse, som jeg slet ikke har sagt.

Og ganske rigtigt: GPLv3 indfører yderligere restriktioner i forhold til GPLv2; men jeg kan simpelthen ikke se, at det gør nogen stor forskel i FreeBSD sammenhæng, hvor det væsentlige er, at koden ikke skal distribueres til modtageren, som ikke har krav på, at få tingene som open source. Jo, hvis nogen, vil tage en fuld FreeBSD og bruge den i en mobiltelefon, har det relavans; MEN nu startede snakken altså fra en compiler, og hvem bruger en compiler i en mobiltelefon?

Ja, for at FreeBSD skal opnå de mål, som de gerne vil skal de holde GPL - både v2 og v3 samt LGPL - ude af deres runtimesystem.

På Android (så vidt jeg forstod) også valgt glibc fra for at undgå (fremtigdige) LGPLv3 restriktioner; men det er jo altså også direkte rettet mod mobiltelefoner.

Personligt, synes jeg værdier af Open Source falder uden GPLv3 restriktionerne: Jeg kan ikke se nogen speciel OSS-markedsværdi i en Linux baseret telefon, hvis jeg ikke kan rette i koden alligevel. Og hvorfor skulle jeg så som udvikler (indirekte) bidrage til et sådant projekt? Men her er jeg jo så bare helt uenig med FreeBSD folket. Linus Torvalds ligger et sted midt imellem: Han mener problemet ikke bør rettes i licensen; men i at man blot ikke skal købe sådanne telefoner.

Jeg har generelt ikke nogen holdning til FreeBSD. Jeg kunne godt finde på at bruge det. Det har helt sikkert nogle tekniske fordele over Linux, og på andre punkter er det underlegent. Der, hvor jeg bliver sur, er tonen fra nogle fra *BSD lejren, som hakker Linux ned ved f.eks at sprede FUD om GPL.

  • 0
  • 0
Poul-Henning Kamp Blogger

Og ganske rigtigt: GPLv3 indfører yderligere restriktioner i forhold til GPLv2; men jeg kan simpelthen ikke se, at det gør nogen stor forskel i FreeBSD sammenhæng,[...]

Esben,

Kan du slet ikke selv se, hvor hoven og arrogant den udtalelse er ?

Poul-Henning

  • 0
  • 0
Alexander Færøy

I Irssi projektet (en IRC-klient) har vi op til vores seneste release begyndt at bruge en masse nye værktøjer hvor et af dem kommer fra LLVM, og det er deres static-analyzer.

De har bl.a. gjort at det passer perfekt ind i projekter, der allerede bruger autotools (som ret mange OSS-projekter bruger (på godt og ondt)) som buildsystem, ved hjælp af et lille værktøj, der kører dit configure-script med de rigtige parametre og i sidste ende får du en bunke HTML filer som du kan sidde og læse i din webbrowser eller dele med de andre i projektet via en webserver. Dette gør det også perfekt til automatisk at sætte en maskine til at bygge dit projekt via LLVMs static-analyzer kl. 2 hver nat, og så har du friske resultater hver morgen.

En af kollegaerne fra projektet har et halvgammelt resultat fra sådan et build liggende på http://www.stack.nl/~jilles/irc/scan-build/ hvis folk har lyst til at kigge på det.

I øvrigt, lad os nu snakke LLVM og ikke licenser! LLVM er langt sjovere end licenser..

  • 0
  • 0
Simon Andreas Frimann Lund

Hørt! Den static-analyser ser fantastisk brugbar ud! Hvad er der ellers af lækre tools i LLVM kassen?

Er der nogle der kan svare på om LLVM / Clang understøtter C++0x "nye" generiske programmerings tiltag (Concepts, mm.)?

Jeg syntes at læse fra en post i ovenstående at LLVM er bedre til at give fejlbeskeder. Det er noget der er hårdt brug for på de områder da GCC og ConceptGCC (http://www.generic-programming.org/languages/conceptcpp/) kan pumpe en 3-4 fulde skærmlængder med uforståelige fejlbeskeder hvis man har lavet en simpel tastefejl i en type deklaration.

  • 0
  • 0
Alexander Færøy

Der er desværre langt igen for Clangs C++ support; jeg tror, at det var i går, at de fik support for at kalde metoder i klasseinstanser, så vi ser desværre nok ikke store ting som concepts i Clang det næste stykke tid.

De har så vidt jeg ved ikke engang gået rigtigt igang med templates endnu :(

I øvrigt tvivler jeg også stærkt på at vi ser concepts i GCC (Ikke ConceptGCC) i laaaang tid :( Concepts er virkelig den tunge fætter for C++1x.

Se eventuelt http://clang.llvm.org/cxx_status.html for Clangs C++ status.

Hvis du vil se lidt nærmere på nogle af Clangs næsten smukke fejlmeddelelser, så kig her: http://clang.llvm.org/diagnostics.html

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