[compiler] GCC 3.3, al iemand ervaringen? - Linux en overige clients

maandag 19 mei 2003 11:42

Acties:

Sound is no voodoo!

Topicstarter

Zoals jullie misschien al weten is sinds 14 mei is eindelijk GCC versie 3.3 uit. Helaas heeft gentoo nog geen ebuild dus ik wacht nog even met emergen. Zelf installeeren zie ik niet zo zitten omdat het dan een zooitje word met gentoo...

Meer info vind je hier:
- http://gcc.gnu.org/gcc-3.3/
- http://gcc.gnu.org/gcc-3.3/changes.html

Vooral interessant is de beschrijvingstaal van de processorpipelines waardoor de compiler beter kan optimaliseren:
- http://gcc.gnu.org/news/dfa.html

Maar misschien zijn er al wel mensen die hem al wel getest hebben... Post hier dan je bevindingen. Vooral interressant zijn bevindingen m.b.t. performance-verbeteringen/verslechteringen, kernel compilaties, problemen, compatibiliteit, e.d.

$_/-\o_$

[ Voor 3% gewijzigd door voodooless op 19-05-2003 11:44 ]

Do diamonds shine on the dark side of the moon :?

maandag 19 mei 2003 12:12

Acties:

AlterEgo

http://forums.gentoo.org/viewtopic.php?t=50679

draft ebuild, en een hoop discussie.

maandag 19 mei 2003 13:10

Acties:

_JGC_

Laatste prerelease van gcc 3.3 die ik probeerde kon Gnome 2.2 niet compileren terwijl gcc-3.2.3 dat nog wel kon.
Verder lees ik in #LFS veel over source die niet werkt met gcc-3.3 en gepatched moet worden. Voor zover ik me kan indenken zal dat allemaal deprecated prut geweest zijn die nog wel in 3.2 zat maar in 3.3 is verwijderd.

maandag 19 mei 2003 13:44

Acties:

Infern0

Hou die ontzettende rust!!

De kernel van 2.4.20 compileert ook nog niet met gcc-3.3, maar dat is al wel gefixed in de upstream. Dit betreft de scsi driver voor de adaptec 2940 en consorten. Bij debian zit gcc-3.3 al een tijdje in unstable.

http://www.bsdfreaks.nl Home site: http://rob.lensen.nu /me was RobL

maandag 19 mei 2003 14:01

Acties:

voodooless

Sound is no voodoo!

Topicstarter

Tja, probleem met veel sources is dat ze idd nog oude zooi gebruiken die vaak niet aan de standaard voldoet. Probeer maar eens een keer iets met de vlag "-ansi" te bouwen. Dat zal bijna niet lukken. Toch probeert gcc mensen er met kleine stapjes toe te dwingen zich steeds beter aan de standaarden te houden. Op zich een goeie zaak, maar het brengt wel af en toe problemen met zich mee, die dan weer gepatched moeten worden.

btw. gentoo heeft nu wel een officieele ebuild, dus ik ga nu bouwen

Do diamonds shine on the dark side of the moon :?

maandag 19 mei 2003 14:08

Acties:

Verwijderd

en benchmarks? (b.v. kernel compile time)

maandag 19 mei 2003 14:44

Acties:

Creepy

Tactical Espionage Splatterer

Verwijderd schreef op 19 May 2003 @ 14:08:
en benchmarks? (b.v. kernel compile time)

Naar ik heb begrepen is 3.3 langzamer met compileren dan 3.2 (en dat zegt dus niks over de snelheid van de geompileerde code.. die als het goed is sneller zou moeten zijn

. De compileer snelheid zou dacht ik worden verbeterd in de 3.4.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

maandag 19 mei 2003 18:00

Acties:

_JGC_

Als je dan toch bezig bent, sloop linuxthread er dan uit en ga aan de slag met npthread, die is tig keren sneller dan linuxthread (native posixthread).

Waar linuxthread een kwartier voor nodig heeft qua processen spawnen, doet npthread dat in een paar minuten. Ideaal voor drukke webservers of forkbommen

maandag 19 mei 2003 18:13

Acties:

FCA

Ik draai het al een weekje of anderhalf, erg tevreden. Meeste dingen compilen wel goed (alleen glibc had een patch nodig), alleen Openoffice wil niet bij mij compilen.
Ik weet niet of het echt sneller is, maar hij schijnt stabieler te zijn met veel optimalisaties, zo heb ik nu GCC zichzelf laten compilen met een hele zooi optimalizatie flags, terwijl GCC 3.2.x dit echt niet wou doen.
Ik ben nog aan het uitvogelen hoe ik de profiler goed aan de praat krijg, deze zorgt ervoor dat programma's na een tijdje gedraaid te hebben, nog beter gecompiled kunnen worden.
Trouwens:
XFree 4.3.0, KDE uit de CVS, Mozilla uit CVS, Phoenix uit CVS, iptables en Lame 3.93.1 compilen allemaal zonder problemen. Glibc 2.3.1 met deze patch ook perfect.

Verandert z'n sig te weinig.

maandag 19 mei 2003 19:37

Acties:

voodooless

Sound is no voodoo!

Topicstarter

hier een klein testje met lame:
Een audio track van wav naar mp3, standaard lame instellingen:

CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer"

gcc 3.2:

code:

LAME version 3.93 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 15115 Hz - 15648 Hz
Encoding 3.wav to 3.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  7639/7641  (100%)|    0:15/    0:15|    0:15/    0:15|   12.622x|    0:00
average: 128.0 kbps   LR: 833 (10.90%)   MS: 6808 (89.10%)
 

Writing LAME Tag...done

gcc 3.3:

code:

LAME version 3.93 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 15115 Hz - 15648 Hz
Encoding 3.wav to 3.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  7639/7641  (100%)|    0:15/    0:15|    0:15/    0:15|   12.743x|    0:00
average: 128.0 kbps   LR: 833 (10.90%)   MS: 6808 (89.10%)
 
Writing LAME Tag...done

en nogmaals 3.3 met andere CFLAGS:

CFLAGS="-march=athlon-mp -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -ffast-math -fprefetch-loop-arrays"

code:

LAME version 3.93 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 15115 Hz - 15648 Hz
Encoding 3.wav to 3.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  7639/7641  (100%)|    0:14/    0:14|    0:14/    0:14|   13.668x|    0:00
average: 128.0 kbps   LR: 833 (10.90%)   MS: 6808 (89.10%)
 
Writing LAME Tag...done

Hier is in ieder geval geen signifikant verschil te zien met de zelfde CFLAGS met lame. Bedenk echter wel dat lame veel assembler inserts beval waardoor de snelheid minder processorafhankelijk is. Toch is te zien dat er met enkele extra flags er toch nog wat snelheid uit te halen valt :8

[ Voor 6% gewijzigd door voodooless op 19-05-2003 19:38 ]

Do diamonds shine on the dark side of the moon :?

maandag 19 mei 2003 21:25

Acties:

XTerm

_JGC_ schreef op 19 May 2003 @ 18:00:
Als je dan toch bezig bent, sloop linuxthread er dan uit en ga aan de slag met npthread, die is tig keren sneller dan linuxthread (native posixthread).

Waar linuxthread een kwartier voor nodig heeft qua processen spawnen, doet npthread dat in een paar minuten. Ideaal voor drukke webservers of forkbommen

Volgens mij gaat snellere thread code je niet helpen bij een fork bomb hoor

maandag 19 mei 2003 23:53

Acties:

_JGC_

XTerm schreef op 19 May 2003 @ 21:25:
[...]

Volgens mij gaat snellere thread code je niet helpen bij een fork bomb hoor

Je systeem is alleen een beetje eerder plat

de simpelste "fork"bomb is een bashscript wat zich 3x in de background aanroept, daar helpt ie wel aardig bij zo snel mogelijk het maximum aantal processen te halen

dinsdag 20 mei 2003 10:07

Acties:

XTerm

Heb gcc 3.3 net draaien op m'n laptop. Nog niets echts mee gecompiled, behalve wat kleine zooi van mezelf....

TRAAAAAAAAG

Maar hij voelt wel fris aan

dinsdag 20 mei 2003 10:17

Acties:

voodooless

Sound is no voodoo!

Topicstarter

TRAAAAAAAAG

Op zich vind ik het compileren zelf niet echt veel tragen, misschien een beetje (of ik merk het niet op mijn systeem

)

Intussen is Xfree 4.3 ook gelukt met gcc 3.3. De rest van de probeersels werken ook naar behoren tot nu toe.

Do diamonds shine on the dark side of the moon :?

dinsdag 20 mei 2003 10:57

Acties:

M@rijn

Bij mij wil vmware niet goed compileren, ik moet dus ff GCC 2.x.x hebben

woensdag 21 mei 2003 21:17

Acties:

voodooless

Sound is no voodoo!

Topicstarter

MozillaFirebird 0.6 compileert ook goed met 3.3

En is nog verrekte snel ook (starten binnen een seconde

), stuk beter dan mozilla. Alleen jammer dat ie nogal buggy is met sommige dingen...

Anyway, alles wat ik tot nu toe geprobeert heb werkt naar behoren

Do diamonds shine on the dark side of the moon :?

vrijdag 23 mei 2003 13:34

Acties:

voodooless

Sound is no voodoo!

Topicstarter

Ah, nog een testje gedaan met mp1e: http://sourceforge.net/projects/zapping

ik gebruik het om video te capturen van mijn TV-kaart (full resolution 720x576@8Mbit). met gcc 3.2 had ik een systeem load van rond de 20%, nu met gcc 3.3 heb ik maar 5 tot 10 % belasting. Een tamelijk groot verschil

Do diamonds shine on the dark side of the moon :?

vrijdag 23 mei 2003 14:49

Acties:

Verwijderd

Het compilen van mozilla met de nieuwste gcc is een slecht idee. Dan moeten plugins ook met die gcc gecomiled zijn...en java van sun wordt met gcc 2.95 gecomiled (als ik 't goed onthouden heb.) en blackdown heeft een gcc 3.2 versie.

vrijdag 23 mei 2003 20:07

Acties:

Verwijderd

deepspace schreef op 19 May 2003 @ 19:37:
hier een klein testje met lame:
Een audio track van wav naar mp3, standaard lame instellingen:

CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer"

gcc 3.2:
code:
1
2
3
4
5
6
7
8
9
10
11
LAME version 3.93 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 15115 Hz - 15648 Hz
Encoding 3.wav to 3.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  7639/7641  (100%)|    0:15/    0:15|    0:15/    0:15|   12.622x|    0:00
average: 128.0 kbps   LR: 833 (10.90%)   MS: 6808 (89.10%)
 

Writing LAME Tag...done
gcc 3.3:
code:
1
2
3
4
5
6
7
8
9
10
LAME version 3.93 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 15115 Hz - 15648 Hz
Encoding 3.wav to 3.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  7639/7641  (100%)|    0:15/    0:15|    0:15/    0:15|   12.743x|    0:00
average: 128.0 kbps   LR: 833 (10.90%)   MS: 6808 (89.10%)
 
Writing LAME Tag...done
en nogmaals 3.3 met andere CFLAGS:

CFLAGS="-march=athlon-mp -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -ffast-math -fprefetch-loop-arrays"
code:
1
2
3
4
5
6
7
8
9
10
LAME version 3.93 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 15115 Hz - 15648 Hz
Encoding 3.wav to 3.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  7639/7641  (100%)|    0:14/    0:14|    0:14/    0:14|   13.668x|    0:00
average: 128.0 kbps   LR: 833 (10.90%)   MS: 6808 (89.10%)
 
Writing LAME Tag...done
Hier is in ieder geval geen signifikant verschil te zien met de zelfde CFLAGS met lame. Bedenk echter wel dat lame veel assembler inserts beval waardoor de snelheid minder processorafhankelijk is. Toch is te zien dat er met enkele extra flags er toch nog wat snelheid uit te halen valt :8

hmm, dit is wel interessant ja.. waar haal je die extra flags vandaan? misschien dat ik ook nog wat kan optimaliseren voor m'n athlon-xp (nu op gentoo met "-march=athlon-xp -O3 -pipe -fomit-frame-pointer")

edit:
Never mind, ik moet eerder Google gebruiken: http://www.freehackers.org/gentoo/gccflags/flag_gcc3opt.html

[ Voor 4% gewijzigd door Verwijderd op 23-05-2003 20:09 . Reden: Reeds gevonden @ google ]

zaterdag 24 mei 2003 16:53

Acties:

voodooless

Sound is no voodoo!

Topicstarter

Wat mij opvalt is dat de meeste grote projecten goed compileren, terwijl de kleinere programma's toch wat vaker fout gaan, waarschijnlijk omdat er niet zo clean geprogrammeerd wordt.

Do diamonds shine on the dark side of the moon :?

zaterdag 24 mei 2003 17:30

Acties:

Hans

Ik kreeg gcc-3.3 niet gecompiled met gcc-3.2.1

Moest terug naar 2.95.4

[ Voor 20% gewijzigd door Hans op 24-05-2003 17:30 ]

zaterdag 24 mei 2003 19:35

Acties:

AlterEgo

Hans schreef op 24 mei 2003 @ 17:30:
Ik kreeg gcc-3.3 niet gecompiled met gcc-3.2.1
Moest terug naar 2.95.4

Het lijkt beter om gcc 3.3 heel conservatief te compileren (weinig flags) met een andere versie van gcc, en evt. bij een tweede compileer sessie (dus: gcc 3.3 compleren met gcc 3.3) de flags aan te scherpen. bron