GCC 4.0 belooft snellere open-sourcesoftware

Op 20 april is door lead-programmeur Mark Mitchell GCC 4.0 officieel vrijgegeven. Deze versie van de compilatiesoftware is de opvolger van GCC 3.x, dat gebruikt wordt voor het compileren van vrijwel alle open-sourcesoftware voor Linux. Een van de nieuwe features in versie 4.0 van de software is een nieuw optimalisatieframework. GCC 3 is in staat om kleine lokale gedeeltes uit een groter geheel van programmacode te optimaliseren. De nieuwe versie van de GNU Compiler Collection, zoals GCC voluit heet, is ook in staat om datastructuren te vinden in grotere stukken code. Hierdoor kan beter bepaald worden welke objecten in het on-chipgeheugen geladen moeten worden en welke delen in het tragere interne geheugen geladen moeten worden. De naam van deze technologie is Tree SSA, wat staat voor static single assignment.

Verder introduceert GCC 4.0 een feature genaamd Mudlap, waarmee in een programma gecontroleerd wordt op buffer overruns. Dit heeft echter een negatief effect op de performance van software en is daardoor met name interessant voor debugversies. Ten slotte zouden onder meer C(++)-programma's met de nieuwe compiler een performancewinst moeten laten zien. Een feature die waarschijnlijk in GCC 4.1 aanwezig zal zijn, is 'autovectorization'. Deze feature zorgt ervoor dat waar mogelijk floating-pointberekeningen automatisch worden omgezet naar vectorberekeningen, zodat gebruikgemaakt kan worden van de hardwarematige vectorunits die onderdeel zijn van processors met SIMD-optimalisaties. Denk hierbij onder andere aan SSE, SSE2 en SSE3 van Intel, Altivec van IBM en 3DNow van AMD. Verder zal in een latere versie ook functionaliteit voor de Fortran 95-programmeertaal worden toegevoegd. Deze programmeertaal wordt veel gebruikt bij de ontwikkeling van wetenschappelijke en technische programma's.

GCC logo GCC 4.0 is echter nog steeds in een 'work in progress' en het zal daarom nog wel enige tijd duren voordat performancevoordelen zichtbaar zullen worden, aldus Mitchell. Dit heeft er onder meer mee te maken dat de GCC-code nog niet voldoende is getweakt, zoals GCC 3 dat al wel is. Dat GCC 4.0 desondanks toch een goede compiler is, blijkt uit een review die auteur en programmeur Scott Ladd gepubliceerd heeft. Uit de resultaten van zijn onderzoek blijkt dat GCC 4.0 op dit moment vrijwel gelijk of iets langzamer presterende code produceert ten opzichte van GCC 3.4. Dat is volgens Ladd ook niet zo heel raar, omdat dit de eerste officiële release is van de GCC 4.0 en dat zeker in de toekomst, als in programma's meer gebruikgemaakt zal worden van de nieuwe mogelijkheden voor codeoptimalisatie, gebruik van GCC 4.0 zeker voordelen zal hebben.

Lees meer

Reacties (61)

ATS 7 mei 2005 19:23

Wat ook erg belangrijk is voor software ontwikkelaars (en Gentoo gebruikers

) is dat GCC 4 veel sneller compileert dan GCC 3.x. Dat kan soms wel de helft schelen. Dat zorgt ervoor dat je sneller kan werken als programmeur omdat je minder lang op je compilaties hoeft te wachten.

Liquidbit @ATS • 7 mei 2005 19:29

Ik zou niet erg vinden als mijn programma een week duurt met compileren... als die maar super snel is als executable !

Verwijderd @Liquidbit • 7 mei 2005 20:01

Precies. Om deze reden hebben compilers eigenlijk altijd een instelling waarmee je de verhouding optimalisatie/compilatietijd kan instellen. Zolang je nog aan het ontwikkelen bent compileer je met lage optimalisatie zodat je een kleine turnaround tijd hebt, echter voordat je het product uitbrengt compileer je het nog een keer met alle optimalisaties aan.

kidde @Verwijderd • 8 mei 2005 22:01

Met ALLE optimalisaties aan? Lijkt me een zeer slecht plan (uit ervaring). Ik neem aan dat je alle nuttige optimalisaties bedoelt.
Ik had nl. een keer geprobeerd met -feliminate-dwarf2-dups en -foptimize-register-loops, en -fpeephole te compilen (en nog 20 andere -f***), maar dan krijg je al snel errors.
Zeker meer dan -O3 lijkt me al helemaal een slecht plan.

ATS @Liquidbit • 7 mei 2005 19:36

Ik wel! Heb je wel eens geprobeerd daadwerkelijk een programma te ontwikkelen als je zo lang moet wachten op het compileren? Dat werkt dus echt niet.

Sharky K. @ATS • 7 mei 2005 19:44

Net zoals vroeger alles controleren voordat je daadwerkelijk gaat compilen... mooie code :-)
Vroeger moest je zeker zijn voordat je de hoofd computer van een software bedrijf ging gebruiken om te compilen.

Verwijderd @ATS • 7 mei 2005 19:47

Gelukkig hoef je alleen maar datgene opnieuw te compileren wat je gewijzigd hebt na de laatste compilatie, of wijzig je zo veel dat elke compilatie te lang duurt voor je?

TheekAzzaBreek @ATS • 7 mei 2005 20:29

Ja, zo heb ik het ook geleerd. Altijd volkomen onzin gevonden, een halve dag aan een desk-check besteden om er de syntax fouten uit te halen. Daar hebben we compilers voor.

YaPP @Liquidbit • 8 mei 2005 00:33

Ik zou niet erg vinden als mijn programma een week duurt met compileren... als die maar super snel is als executable !

een box die op de achtergrond aan het compilen is, is niet snel.

ik zie het nut van zelf compilen ook niet meer, binary packages zijn meestal ook (en netter/veiliger) geoptimaliseerd.

@Superstoned: ik doelde juist voornamelijk op gentoo

de meeste performance winst krijg je met "-march", en suse compileerd standaard ook alles met "-march=i568 -mcpu=i686 -O2", dus ik zie de voordelen niet meer.

rtgo @YaPP • 8 mei 2005 01:11

Er zijn ook mensen die thuis wel eens een programmatje schrijven.

Hoe doet GCC het eigenlijk ten opzichte van andere bekende compilers (van intel en borland)? Is het beter, slechter of maakt het niet veel uit?

Superstoned @YaPP • 8 mei 2005 13:05

gcc optimaliseerd wat minder goed dan die anderen. aan de andere kant, gcc is de compiler met de meeste hardware- en talen support in 1 compiler.

Superstoned @YaPP • 8 mei 2005 13:10

windows niet, nee. die kan niet multi-tasken. maar op een redelijk linux systeem, zeker gentoo (want dat is er nu eenmaal voor gemaakt) merk je er weinig van. en als je je systeem er echt een beetje voor optimaliseert dan merk je er gewoon helemaal niets van.

ik gebruik bijvoorbeeld altijd schedtool -B (batch) voor het compilen van een berg software. dat zorgt dat het process alleen toegang krijgt tot de processor wanneer er GEEN ENKEL ander proces is dat toegang uberhaupt kan gebruiken. Mijn kernel is gecompileerd met alle pre-emption opties aan die ik kon vinden (nou ja 2 dus) en ik gebruik con kolivas cpu-scheduler.

ofwel, je merkt er echt niets van. uiteindelijk gebruik je, ook als je bezig bent met bijv. wat ik dus nu doe, typen/browsen/muziek draaien niet continue 100% van je cpu. dankzij de Batchmode word de rest wel gebruikt. niet met een lage prioriteit (want dan kan een ander proces nog steeds moeten wachten op de compile) maar echt helemaal zonder prioriteit, zogezegd...

Verwijderd @ATS • 8 mei 2005 12:00

hier staat dat dat snelle allemaal wel meevalt: Gcc 4.0 review.

Verwijderd @ATS • 8 mei 2005 12:52

Het schijnt dat GCC 4.1 nog sneller wordt dan 4.0, aangezien de Bison parser die op dit moment gebruikt wordt om C code te parsen wordt vervangen door een handgeschreven parser.

Verwijderd @Verwijderd • 8 mei 2005 13:36

gcc 3.4 gebruikt de nieuwe parser al dus waarom 4.0 niet?

iKiddo @Verwijderd • 8 mei 2005 14:10

Omdat GCC 4.0 al zat andere nieuwigheden bevat, die ze eerst werkend wouden krijgen.

Verwijderd 7 mei 2005 19:00

Hoe zit het met 64 bit en multi-core processoren kan die daar ook optimaliseren .. of kunnen we dat pas in 5.0 verwachten..

Liquidbit @Verwijderd • 7 mei 2005 19:10

Volgens apple wel...
http://www.apple.com/macosx/features/64bit/
http://developer.apple.com/macosx/64bit.html/

Over de i386 architecture weet ik niet.

Verwijderd @Verwijderd • 7 mei 2005 19:14

Een compiler compileert threads apart, omdat zij geen aannames kan doen over welke thread precies wanneer draait. Voor de compiler is er geen verschil tussen multicore en dual processor. De compiler zal dus waarschijnlijk 'nooit' daarvoor optimaliseren.

Verwijderd @Verwijderd • 7 mei 2005 23:02

Een compiler compilet programmacode naar een uitvoerbaar bestand, ook wel bekend als een "executable".

Deze executable begint met 1 thread in 1 proces, waar ie meer threads kan aanmaken zoveel als ie zelf wil. Hij kan ook processen spawnen enz.

Een compiler KAN geen threads apart compilen.

Ik gok maar ff dat je het hebt over concurrent programming:

Bij concurrent programming moet de programmeur er zorg voor dragen dat de threads elkaar niet in de weg zitten. Dit doe je met mutexes, semaforen en messaging-systemen. De threads draaien wel tegelijk, maar door systemen die je het best kunt vergelijken met stoplichten lopen ze elkaar niet in de weg en niet door elkaar heen, en krijg je geen botsingen. Mits alle code de stoplichten gebruikt (niemand door rood rijdt) doet dat het perfect.

Overigens, je kunt niet automatisch detecteren wat onafhankelijk is van elkaar. In elk geval 80-90% van de talen heeft geen volautomatische parallelle uitvoering (talen als prolog zou je het kunnen proberen), en in 95% van de resterende talen heeft het waarschijnlijk minder nut dan het inbouwen van een cache voor al berekende resultaten. Het beste dat je kunt doen is een bruikbaarder en makkelijker interface maken zodat programmeurs automatisch met threads zullen gaan werken, in tegenstelling tot nu.

Mijzelf @Verwijderd • 8 mei 2005 12:54

Overigens, je kunt niet automatisch detecteren wat onafhankelijk is van elkaar.

Waarom niet? De Intel compiler kan het. http://www.intel.com/software/products/compilers/cwin/cwindows.htm#mul tithreading . In grote loops die alleen locale aanpassingen doet (bijvoorbeeld een kleurtemperatuuraanpassing in een foto) is dit eenvoudig. De Intel compiler kan overigens ingewikkelder situaties ook wel aan.

Superstoned @Verwijderd • 8 mei 2005 13:04

inderdaad. gcc is wat dat betreft nog niet zo ver. qua snelheid is de intel compiler zeker beter... maar ja, die werkt dan ook alleen op intel hardware

Mijzelf @Verwijderd • 8 mei 2005 14:03

Hm? Nee hoor. Werkt ook op een AMD of een VIA processor. Moet wel x86 compatible zijn. Dat wel.

iKiddo @Verwijderd • 8 mei 2005 14:07

De Intel compiler werkt zelfs op een AMD Opteron... (Of bedoel je met Intel hardware alle x86 compatibele hardware?)
De ICC (Intel Compiler Collection) is alleen niet open source, dus dat zal een bezwaar vormen voor een aantal mensen.

Verwijderd @Verwijderd • 9 mei 2005 12:23

jah want opensource is belangrijk zonder opensource is er niets

MBV @Verwijderd • 7 mei 2005 21:22

wel degelijk: Nooit gehoord van helper threads? Kwam laatst langs bij de introductie van dual core.

Je kan toch zoieso proberen te detecteren wat onafhankelijk van elkaar kan worden uitgerekend, en dat in threads opdelen zonder dat de programmeur eraan heeft gedacht? Of de compiler kan een warning geven dat je in functie X best wel eens meerdere threads zou kunnen gebruiken?

elteck @MBV • 8 mei 2005 18:56

(Ik ben dyslectich, dus let niet op m'n spelling.)

Kan me vergissen, maar waren helper threads niet een processor specifieke techniek? Tijdens de evaluatie van een conditionele jump (if - then - else) worden beide threads (then en else conditie) uitgevoert in de processor cache. Zodra de evaluatie klaar is wordt een van beide helper threads weggegooit. Op die manier hoef je de pijplijn niet te laten wachten.
Deze techniek zit in de Itanium en de HP processoren, maar of die ook in andere processoren zit, weet ik niet.

Volgens mij moet een compiler rekening houden dat een processor dit kan doen, maar is het geen compiler optimalisatie.

Verwijderd @MBV • 9 mei 2005 10:13

volgens mij ben je niet dyslectisch hoor

Robtimus 7 mei 2005 18:15

De titel is misleidend - je kunt er ook proprietary software mee compilen, niet alleen open source software.
Een betere titel is dus:
GCC 4.0 biedt mogelijk snellere software.

Olaf van der Spek @Robtimus • 7 mei 2005 18:18

De titel is misleidend - je kunt er ook proprietary software mee compilen, niet alleen open source software.

Nee hoor. Als ik zeg dat ik met de trein kan betekent dat toch ook niet dat andere personen niet met de trein kunnen?

Bovendien wordt voor proprietary software vaker een proprietary compiler gebruikt en misschien is die compiler al minstens even snel als gcc 4.

Robtimus @Olaf van der Spek • 7 mei 2005 20:36

Je hebt gelijk voor het eerste deel. De titel is niet misleidend, alleen te beperkend.

Voor het tweede deel kan je ook gelijk hebben, maar zonder cijfers doe ik daar geen uitspraken over. Feit blijft wel dat je met GCC wel degelijk proprietary software kan maken.

TheOneLLama @Olaf van der Spek • 9 mei 2005 01:22

Voor opensource software kun je ook een propriety compiler gebruiken. Voor opensource software op windows is dat ook vaak het geval.

Liquidbit 7 mei 2005 19:00

Ten eerste GCC is die enige compiler die voor alle hardware platformen beschikbaar is.
Een van de grootste voordelen (tenminste voor PowerPC's) van versie 4 is de compile-optimalisatie van Altivec vector functies, bekend als Autovectorization.

http://www.ppcnerds.org/Article308.html

_JGC_ 7 mei 2005 21:44

Enige nadeel van GCC 4.0.0 is dat er nog het een en ander niet helemaal goed gaat met de nieuwe optimalisatie code. Het KDE development team heeft deze compiler iig al geblacklist (configure breekt af met melding dat je een fatsoenlijk werkende compiler moet installeren) en levert geen support op KDE versies gecompileerd met deze versie van GCC.

freggy @_JGC_ • 7 mei 2005 23:42

De bug die dit probleem voor KDE veroorzaakte (en ook voor de Linuxkernel trouwens), is intussen in CVS opgelost. Distributies als Fedora en Mandriva die intussen alles aan het hercompileren zijn met gcc 4, hebben hun compilers al gepatcht, en gebruiken intussen wel KDE met gcc 4. Het ziet er naar uit dat héél binnenkort een gcc 4.0.1 uitkomt om deze en enkele andere belangrijke bugs te fixen.

Verwijderd @_JGC_ • 7 mei 2005 23:05

Binnen de OS development community is 4.0 ook al vervloekt, hij genereert voor sommige constructies geen geldige code en af en toe optimaliseert ie nuttige instructies uit de code, die op een normaal stuk software geen verschil zou moeten maken, maar binnen een OS elementair is.

Ook zijn de makers van GCC sinds 3.4 bezig sommige heldere logische constructies die ik soms nodig heb te verbieden omdat de optimalisatie-engine daar niet zo heel snel mee zou kunnen werken. Het kan me niet zo heel veel boeien of ie 2 nanoseconde sneller is als ik m'n code nog maar kan intypen en verwachten dat ie doet wat ik zou mogen verwachten.

sonix666 @Verwijderd • 8 mei 2005 05:00

Kun je een voorbeeld geven van nuttige instructies die GCC 4.0 weg optimaliseert, die voor OS wel nuttig zijn, maar voor normale software niet? Kan me namelijk absoluut niets komma noppes erbij voorstellen.

nhimf @Verwijderd • 8 mei 2005 19:10

GCC 3.0 werd ook vervloekt toen hij net uitkwam. Er werd aan alle kanten geadviseerd om de laatste 2.x te gebruiken.
Voordat alles overwas/begon over te stappen naar 3.x zaten ze eigenlijk al op 3.2

Dus als linux distro's nu al overstappen op 4.0, dan denk ik dat het allemaal wel meevalt met de bugs en compatibiliteit van 4.0

Baudje 8 mei 2005 05:04

Waarin wordt een compiler eigenlijk geschreven en waarmee gecompileerd?

freggy @Baudje • 8 mei 2005 10:53

Met zichzelf

Grofweg gebeurt het als volgt:

In een eerste fase compileer je de compiler met een oudere versie of zelfs een andere compiler. Vervolgens compileert de nieuwe compiler de source code van zichzelf. In een derde fase gaat het resultaat van deze compilatie, nogmaals zichzelf compileren, en worden tests gedaan met de compiler uit stap 2 en stap 3. Die tests moeten dezelfde resultaten opleveren. Als dat zo is, is je compiler nu klaar, gecompileerd met zichzelf.

Zie ook: http://gcc.gnu.org/install/build.html

scsirob @Baudje • 8 mei 2005 08:54

Met de vorige versie van diezelfde compiler

Verwijderd @scsirob • 8 mei 2005 11:37

bladiebla yacc

Verwijderd @Baudje • 8 mei 2005 14:11

kip-en-ei-vraag: hoe werd de allereerste compiler dan gecompileerd?

iKiddo @Verwijderd • 8 mei 2005 14:18

Simpel antwoord: Niet.
De allereerste compiler hoeft niet gecompileerd te zijn, want die kan je vrolijk in assembly schrijven. Probleem opgelost.

WinL @iKiddo • 8 mei 2005 21:33

Ook dat niet, niet in echte assembly.

Nee, veel erger met 1 en 0. Zodra je Engelstalige woorden gebruikt (of instructies zoals MOV), dan heb je een compiler nodig. De basis zal dus wel gelegd zijn via hardwarematig wat bits ergens in te zetten.

kidde @Verwijderd • 8 mei 2005 22:10

Met de hand

Als je nl een Z80 (antieke processor) assembly progje maakt (voor de TI83 bijv.), en je download de tabellen, is dat maar 16 pagina's. Je kan dan gewoon de instructies omzetten in hex-code. Ik ben er wel eens mee bezig geweest, toen ik nog niet doorhad dat daar ook programma's voor waren

Sterker nog, in de tijd van de eerste computers waren er zelfs mensen die niet in een programmeertaal, maar gewoon in hexadecimaal programmeerden (hoewel die mensen heel zeldsaam zijn).

psyBSD @Verwijderd • 9 mei 2005 11:15

[edit]
Overbodig, sorry.

Boudewijn @Baudje • 9 mei 2005 00:11

kom op man, kijk eens naar google.

een compiler schrijf je assembler ....
en nee dat compileer je niet.

Althans dat geldt voor de eerste compiler.
GCC4.0 zal wel met 3.4 zijn gecompileerd en dan evt wat performance tweaks in ASM.

ASM is heel nuttig als je voor ultieme controle gaat, of dit soort cases... software bouwen zonder compiler (je speelt gewoonz elf compiler)

jcvw 8 mei 2005 09:39

Verder introduceert GCC 4.0 een feature genaamd Mudlap, waarmee in een programma gecontroleerd wordt op buffer overruns. Dit heeft echter een negatief effect op de performance van software en is daardoor met name interessant voor debugversies.

Maar juist in productiesoftware wil je gecontroleerd hebben of er een bufferoverflow optreedt..

Vergelijking (even 100 jaar terug...): We bouwen een nieuw schip met, oh revolutionair, reddingsboten en zwemvesten voor de opvarenden. Tijdens de testvaarten wel te verstaan, want door al die reddingsversten en reddingsboten kunnen er minder passagiers mee. Dus tijdens het productievaren halen we die veiligheidsmaatregelen er maar uit...
[edit]: typefout

Gert @jcvw • 8 mei 2005 10:15

Als je testen niet overeenstemmen met productie gebruik dan moet je daar wat aan doen.

Verwijderd @jcvw • 8 mei 2005 11:44

Kijk hier staat hoe je bufferoverflows moet maken. Maar goed, die bufferoverflows kan je dus voorkomen door al je array's 'checked' te maken. Er wordt bij elke schrijf opdracht gecontroleerd of er niet voorbij het einde van de array geschreven wordt. Dit is niet zo efficiënt, dus soms wil je dit achterwege laten, dan gebruik je dus een standaard array en je checked niet. mudbla zal wel gewoon alle arrays vervangen door checked arrays. Dit soort dingen wil je eigenlijk zelf in de hand hebben, logischdat dit geen productie code opleverd.

Ofwel de vergelijking is meer: laten we onze boot van 30 cm dik geannodiseerd titanium maken en er stelten onder zetten zodat ie niet zinkt, hoeven we verder niet meer over zwemvesten na te denken ...

duur en lomp dus

Olaf van der Spek @jcvw • 8 mei 2005 13:07

Maar juist in productiesoftware wil je gecontroleerd hebben of er een bufferoverflow optreedt..

Het is ook de bedoeling dat je zelf ervoor zorgt dat die overflows niet optreden.
De automatische detectie is meer een manier om die punten te vinden waar je zelf tekort geschoten bent.

cc bcc 7 mei 2005 19:12

Dat weten we ook meteen waar een deel van de snelheidswinst van OS X 10.4 op 10.3 vandaan komt. 10.4 (Tiger) is ge-compiled met GCC 4.0 ipv GCC 3.x

StefSybo @cc bcc • 7 mei 2005 19:21

Uit de resultaten van zijn onderzoek blijkt dat GCC 4.0 op dit moment vrijwel gelijk of iets langzamer presterende code produceert ten opzichte van GCC 3.4.