---

Hej,

Jeg har tidligere skrevet at jeg ikke kunne bruge GCC 3.0 til C++ på
grund af håbløse compile-tider, og generelt dårligere kode i forhold
til GCC 2.95. Jeg har lige prøvet igen med GCC 3.0.2, og med "-O2" er
den nu lige så hurtig (indenfor måleusikkerheden) som GCC 2.95, og det
samme gælder den genererede kode.

Jeg kan derfor godt anbefale folk der har "gemt" GCC 3.0 at prøve
igen, den er trods alt langt bedre i overensstemmelse med C++
standarden end Gcc 2.95.

Mvh,

Per Abrahamsen

---

On Tue, 27 Nov 2001 20:14:18 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> Hej,
>
> Jeg har tidligere skrevet at jeg ikke kunne bruge GCC 3.0 til C++ på
> grund af håbløse compile-tider, og generelt dårligere kode i forhold
> til GCC 2.95. Jeg har lige prøvet igen med GCC 3.0.2, og med "-O2" er
> den nu lige så hurtig (indenfor måleusikkerheden) som GCC 2.95, og det
> samme gælder den genererede kode.

GCC 3.0 har noget af potentialet til at blive en udmaerket compiler.
Personligt ville jeg dog aldrig udvikle på den, men det er en anden
sag...

--
Jesper

---

jlouis@dvalin.diku.dk (Jesper Louis Andersen) writes:

> On Tue, 27 Nov 2001 20:14:18 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>> Hej,
>>
>> Jeg har tidligere skrevet at jeg ikke kunne bruge GCC 3.0 til C++ på
>> grund af håbløse compile-tider, og generelt dårligere kode i forhold
>> til GCC 2.95. Jeg har lige prøvet igen med GCC 3.0.2, og med "-O2" er
>> den nu lige så hurtig (indenfor måleusikkerheden) som GCC 2.95, og det
>> samme gælder den genererede kode.
>
> GCC 3.0 har noget af potentialet til at blive en udmaerket compiler.

Og min pointe er at den for C++ allerede med 3.0.2 har indfriet nok af
dette potentialle til at det er den compiler jeg vil anbefale under
Unix.

Med de ting der er på vej, og som udviklerne håber når at komme med i
3.1, såsom en ny C++ parser, meget bedre inline heruistics, og
pre-processerede headers tror jeg på at den for alvor vil sparke røv.

> Personligt ville jeg dog aldrig udvikle på den, men det er en anden
> sag...

På den eller med den?

---

On Wed, 28 Nov 2001 12:36:16 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> jlouis@dvalin.diku.dk (Jesper Louis Andersen) writes:

> Med de ting der er på vej, og som udviklerne håber når at komme med i
> 3.1, såsom en ny C++ parser, meget bedre inline heruistics, og
> pre-processerede headers tror jeg på at den for alvor vil sparke røv.
>
>> Personligt ville jeg dog aldrig udvikle på den, men det er en anden
>> sag...
>
> På den eller med den?

På den...

Jeg vil nok stadig gerne udvikle med den. Ulempen er bare, at den er alt
for centreret omkring x86arkitekturen. Så vidt jeg ved er
registerallokering i GCC en optimering, hvilket mildest talt ikke er for
kønt.

Tiden er inde til at have mere end små 8 registre at rode i som
compiler. Samtidigt bliver det nok temmeligt svært at få IA64 til at
spille ordentligt med det GCC...

Men man kan blive dejligt overrasket til tider. I andre tilfælde har det
vist sig, at man kan mutere software fra noget skidt til noget godt.

--
Jesper

---

jlouis@brok.diku.dk (Jesper Louis Andersen) writes:

> Ulempen er bare, at den er alt for centreret omkring
> x86arkitekturen.

Øh, bøh, GCC er grundlæggende designet til "32-bit processorer med
masser af generelle registre", med VAX og m68k som de to første
implementeringer. Den passede også fint på de tidlige RISC
processorer, men ia32 falde ikke ligefrem i målgruppen.

> Så vidt jeg ved er registerallokering i GCC en optimering, hvilket
> mildest talt ikke er for kønt.

Internt tror GCC den har uendelig mange registre, at få GCC's
registermodel til at give tålelig kode på ia32 har været noget af en
kamp.

> Samtidigt bliver det nok temmeligt svært at få IA64 til at
> spille ordentligt med det GCC...

VLIW er en helt anden kategori af cpu-arkitekturer, jeg har ingen ide
om hvordan eller hvor godt det er lykkedes at få GCC til at generere
kode til ia64. Men ia64 er altså et understøttet target i 3.0.

....

Hvor har du fået den ide at GCC er ia32 centrisk? Understøttelse af
den arkitektur har traditionelt været GCC's svage punkt, ud over de
arkitektoniske grunde også fordi det indtil fornyligt har været svært
at få penge til udvikle ia32 understøttelsen, hvorimod understøttelsen
af andre processorer typisk er blevet sponsoreret dirkete af
fabrikanten. Der er ikke meget ved at komme ud med ny en embeded chip
uden GCC understøttelse, GCC ejer det marked.

---

On Wed, 28 Nov 2001 18:19:17 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> jlouis@brok.diku.dk (Jesper Louis Andersen) writes:
>> Så vidt jeg ved er registerallokering i GCC en optimering, hvilket
>> mildest talt ikke er for kønt.
>
> Internt tror GCC den har uendelig mange registre, at få GCC's
> registermodel til at give tålelig kode på ia32 har været noget af en
> kamp.

Ja, det gør stort set alle compilere.

>> Samtidigt bliver det nok temmeligt svært at få IA64 til at
>> spille ordentligt med det GCC...
>
> VLIW er en helt anden kategori af cpu-arkitekturer, jeg har ingen ide
> om hvordan eller hvor godt det er lykkedes at få GCC til at generere
> kode til ia64. Men ia64 er altså et understøttet target i 3.0.

Det er jeg udmærket klar over. En ting er ikke hvorvidt man har
understøttelse, men også om understøttelsen leverer gode resultater.

> Hvor har du fået den ide at GCC er ia32 centrisk? Understøttelse af
> den arkitektur har traditionelt været GCC's svage punkt, ud over de
> arkitektoniske grunde også fordi det indtil fornyligt har været svært
> at få penge til udvikle ia32 understøttelsen, hvorimod understøttelsen
> af andre processorer typisk er blevet sponsoreret dirkete af
> fabrikanten. Der er ikke meget ved at komme ud med ny en embeded chip
> uden GCC understøttelse, GCC ejer det marked.

Tjoh... Bare det at man har _forsøgt_ at optimere til en arkitektur som
ia32 er jo under al kritik ;). Jeg har bare hørt det fra anden kilde og
har derfor ikke et gyldigt bevis. Jeg synes nu stadig kun at det eneste
imponerende ved GCC er dens evne til at compile til så mange forskellige
arkitekturer. Tager vi en standard alpha 21164 på 533 mhz og sætter vi
DEC's referencecompiler op mod gcc, så taber gcc stort i stort set alle
tests. En alpha af den alder må vel anses som værende så gammel, at
ordentlige optimeringer burde kunne have været lavet.

Jeg kunne forestille mig, at det samme gør sig gældende på powerpc, hvor
GCC så vidt jeg ved kun kender 10% af det samlede antal instruktioner.
Selvfølgeligt ikke at alle disse ekstra instruktioner kan anvendes (som
regel noget DSPagtigt specialsnask).

--
Jesper

---

In <rjitbwhvqt.fsf@ssv2.dina.kvl.dk>, Per Abrahamsen wrote:

> Jeg kan derfor godt anbefale folk der har "gemt" GCC 3.0 at prøve igen,
> den er trods alt langt bedre i overensstemmelse med C++ standarden end
> Gcc 2.95.
Det lyder rigtig godt, men har du prøvet stc++ og tråde med gcc 3.02 ?

2.95 kom med SGI STL 3.2 som ikke altid havde det så godt med tråde, men
en lille opdatering til 3.3 (som er på SGI's hjemme side) gjorde
udslaget. Det kan man jo ikke med gcc 3, da den har ejen STL.

/BL

---

"Bo Lorentsen" <bl@no.LUE.DK.spam> writes:

> Det lyder rigtig godt, men har du prøvet stc++ og tråde med gcc 3.02 ?

Nej, men der er blevet rettet en del threading relaterede fejl. Jeg
ved dog ikke hvilke releases de er/vil komme med i.

---

jlouis@brok.diku.dk (Jesper Louis Andersen) writes:

> On Wed, 28 Nov 2001 18:19:17 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>> jlouis@brok.diku.dk (Jesper Louis Andersen) writes:
>>> Samtidigt bliver det nok temmeligt svært at få IA64 til at
>>> spille ordentligt med det GCC...
>>
>> VLIW er en helt anden kategori af cpu-arkitekturer, jeg har ingen ide
>> om hvordan eller hvor godt det er lykkedes at få GCC til at generere
>> kode til ia64. Men ia64 er altså et understøttet target i 3.0.
>
> Det er jeg udmærket klar over. En ting er ikke hvorvidt man har
> understøttelse, men også om understøttelsen leverer gode resultater.

Det aner jeg ikke. Men jeg vil ikke give ia32 skylden hvis det ikke
lykkedes, GCC's model af en CPU ligner mest en simpel RISC computer,
hvilket er langt fra VLIW.

> Tjoh... Bare det at man har _forsøgt_ at optimere til en arkitektur som
> ia32 er jo under al kritik ;).

Der er en del hooks i "middle-enden" som ia32 benytter, men jeg har nu
aldrig hørt de øvrige back-end folk brokke sig over at de hooks gør
deres arbejde væsentligt sværere. Det giver selvfølgelig noget ekstra
vedligeholdesle i middle-enden. Det er mit indtryk at der kommer
flere problemer fra at GCC skal generere kode til både 16, 32 og 64
bit targets.

> Jeg synes nu stadig kun at det eneste imponerende ved GCC er dens
> evne til at compile til så mange forskellige arkitekturer.

Den har også fået opbygget en fin samling front-ends efterhånden, og
den compiler ikke alene _til_ men også _på_ en imponerende samling
systemer.

> Tager vi en standard alpha 21164 på 533 mhz og sætter vi DEC's
> referencecompiler op mod gcc, så taber gcc stort i stort set alle
> tests. En alpha af den alder må vel anses som værende så gammel, at
> ordentlige optimeringer burde kunne have været lavet.

Sidst jeg hørte nåede GCC heller ikke Intels compilere til
sokkeholderne på ia32. Generelt skal en arkitektur være død i mange
år før GCC slår fabrikantens egen compiler. GCC er vist nok #1 på
m68k, jeg tror heller ikke Motorola udvikler deres egen compiler der.

> Jeg kunne forestille mig, at det samme gør sig gældende på powerpc, hvor
> GCC så vidt jeg ved kun kender 10% af det samlede antal instruktioner.
> Selvfølgeligt ikke at alle disse ekstra instruktioner kan anvendes (som
> regel noget DSPagtigt specialsnask).

Jeg tror ikke GCC får brug for PowerPC's BCD instruktioner før COBOL
front-enden er færdig