[Gentoo] Ervaring met CFLAGS="-march=athlon-tbird" ?

[Verwijderd]

Zijn er mensen die ervaring hebben met deze CFLAGS instelling?

Na een fikse upgrade van KDE van 3.0.4 naar 3.0.5a werkt alles weer goed, behalve KMail, dat gedurig crasht tijdens het opstarten. Ik wijt het aan deze CFLAGS, daar KMail ook crasht als ik alle config files en de Mail/ directory tijdelijk verplaats (Ik krijg dan wel een dialoogje, maar daarna crasht hij alsnog).

Ik heb ergens gelezen dat athlon-tbird ook de goede instelling is voor de Duron, die ik heb, maar vraag me toch af of het aan deze CFLAGS kan liggen?

Iemand een idee?

[Verwijderd]

Is dit je hele CFLAGS die je hebt neergezet? Volgens deze thread: http://www.freehackers.or...002/08/27/21,0,1,1,0.html zou je voor een Duron Athlon optimalisatie moeten gebruiken ipv athlon-tbird.

Zie voor ervaringen van andere mensen: http://forums.gentoo.org/...&highlight=cflags&start=0
Of http://www.freehackers.org/gentoo/gccflags/ voor veilige en minder veilige optimalisatie instellingen.

[Wilke]

$ cat /etc/make.conf | grep "CFLAGS"
CFLAGS="-mcpu=athlon-tbird -O3 -pipe"

$ cat /proc/cpuinfo | grep "name"
model name : AMD Duron(tm) processor

Ik weet niet of het veel uitmaakt, maar misschien is '-mcpu' proberen in plaats van '-march' toch een beter optie dan - ik heb namelijk nergens last van.

Gebruik je toevallig nog dingen als Mosfet's Liquid of andere dingen die problemen zouden kunnen veroorzaken?

Over Athlon/athlon t-bird, ik zie in dat lijstje hierboven staan dat er geen verschil is tussen de ingeschakelde opties bij 'athlon' en 'athlon-tbird'.

[ Voor 16% gewijzigd door Wilke op 05-01-2003 18:13 ]

[Verwijderd]

Wilke, je weet dat je redelijk veilig een -fomit-frame-pointer bij jouw instellingen kan zetten zonder dat je compiles in de soep lopen?

Verder is eerst cat-en en dan erop grep-en wel een beetje dubbelop he

[AlterEgo]

Niet helemaal:

Duron (Morgan-core; dat is Duron >1 Gig geloof ik) bevat dezelfde CPU-vlaggen als de Athlon-XP, alleen minder cache. De optimale vlaggen daarvoor zijn dus ook de -march=athlon-xp (gcc 3.x ).
Voor de oudere Durons heeft Wilke gelijk .

Na deze mier te hebben geneukt:
bij problemen met applicaties is het eerste dat je kan proberen: omlaag met die C(XX)FLAGS: emerge kdenetwork eens met: # CFLAGS="-march=i686 -O2" en kijk dan eens of de Kameel wil starten. Verder optimaliseren gaat beter vanuit een werkende situatie.

En als je ECHT Flags wil gaan testen, dan raad ik je freebench aan (www.freebench.org/): een platform-onafhankelijke set performance-metingen, die je precies kunnen vertellen welke FLAGS op jouw doos het beste werken. Ook kernel patches kun je vergelijken met freebench (maar KonTest lijkt me daarvoor toch geschikter).
Je kunt de resultaten online vergelijken, maar dit deel staat nog een beetje in de kinderschoenen.

Als eerbetoon aan mijn inmiddels dode Duron :
Duron 1200 (9*133) KT333 512 MB DDR PC 2700 Gentoo linux 1.4RC1 GCC 3.2.1 kernel 2.4.20. De low-latency kernel patch is volgens freebench de effectiefste.

Optimaal voor de meeste tests (hoogste score):
-march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse -O3 -pipe -fomit-frame-pointer -funroll-loops -fforce-addr -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4

[ Voor 23% gewijzigd door AlterEgo op 05-01-2003 18:24 ]

[Wilke]

balou: ja, dat weet ik (allebei). Ach ja, als je toch al 'cat blaat' hebt staan om te kijken waar je op moet greppen, ben ik te lui om dan die regel opnieuw in te tikken (pijltje omhoog | grep blaat is sneller )

Volgende keer als ik rebuild maar eens wat meer optimalisaties aanzetten.

Ik zou wel eens willen weten hoeveel het nou echt uitmaakt, maar hoe zou je dat uberhaupt objectief kunnen meten (opstarttijd, tijd om een nieuw window te openen in Konqueror ofzo...dat soort dingen)?

AlterEgo: je linkje werkt niet, staat nog een tekentje achter ofzo.

[ Voor 8% gewijzigd door Wilke op 05-01-2003 18:31 ]

[Verwijderd]

Dank voor de reacties!

Ik had -march=athlon-tbird -O3 -pipe. Ik heb nu die -tbird eraf gehaald, en ben nu kdenetwork aan het emergen met {C,CXX}FLAGS="-O3 -pipe" in de environment, kijken wat dat oplevert.

Hij crasht trouwens met signal 11, en hier staat een backtrace daarvan.

[Verwijderd]

Wilke schreef op 05 januari 2003 @ 18:21:
balou: ja, dat weet ik (allebei). Ach ja, als je toch al 'cat blaat' hebt staan om te kijken waar je op moet greppen, ben ik te lui om dan die regel opnieuw in te tikken (pijltje omhoog | grep blaat is sneller )

Je kan na de cat blaat ook typen grep zoekwoord !$ doe ik altijd, dan vult de bash history het laatste argument van het vorige commando in.
Hoewel ik meestal o ipv cat gebruik, en o is een alias naar less in less 'grep' ik dan met "/".

Ik zou wel eens willen weten hoeveel het nou echt uitmaakt, maar hoe zou je dat uberhaupt objectief kunnen meten (opstarttijd, tijd om een nieuw window te openen in Konqueror ofzo...dat soort dingen)?

Volgens mij maakt het in dat soort dingen weinig uit.

De opstarttijd van applicaties is voor ruim 60% de tijd die de linker nodig heeft voor de runtime linking, vooral C++ apps zoals KDE hebben hier veel last van (prelink kan dit enorm versnellen, ben ik aan het proberen). De rest wordt vooral bepaald door de snelheid van je schijf volgens mij.

[AlterEgo]

Verwijderd schreef op 05 January 2003 @ 19:08:
De opstarttijd van applicaties is voor ruim 60% de tijd die de linker nodig heeft voor de runtime linking, vooral C++ apps zoals KDE hebben hier veel last van (prelink kan dit enorm versnellen, ben ik aan het proberen). De rest wordt vooral bepaald door de snelheid van je schijf volgens mij.

In de praktijk: absoluut !
Maar in theorie bepalen die flags de kwaliteit en grootte van je code. Dat heeft weinig met de snelheid van je disks te maken, en imho niets met runtime linking.
Daarom is freebench (zie mijn post hierboven) een aardige meetmethode.
Prelink is het proberen meer dan waard overigens, en het effect daarvan is behalve zichtbaar ook goed meetbaar: LS_DEBUG=statistics konqueror is een mooie:
je ziet dat je relocaties "verdwenen" zijn na prelinking, en je ziet dat het aantal CPU-cycles dat benodigd is enorm is afgenomen.

[Verwijderd]

hoe kan je prelinking gebruiken/aanzetten?

[AlterEgo]

Verwijderd schreef op 05 January 2003 @ 20:35:
hoe kan je prelinking gebruiken/aanzetten?

zoiets :?
(voor de gentoo-ers onder ons)

[Verwijderd]

OK Gelukt! Dank. inderdaad loste het verwijderen van -tbird het probleem op. Phew! Ik kan weer bij mijn post! [om dan 5 windhoos virussen in mijn inbox te vinden ze vieren weer hoogtij momenteel, na al die leuke 'Christmas Greetings']

Re: prelinking: Hoe je prelinking aan kan zetten? Werkt alleen als je binutils >= 2.13.90 en glibc >=2.3.1 schijnt te hebben. Het bestaat uit het installeren van het programma'tje 'prelink' en dan runnen. Het verandert al je libraries zo, dat ze een eigen plaats in het virtuele geheugen krijgen bij het laden, en al je binaries zo dat die gelijk 'weten' waar de libraries die ze nodig hebben in het geheugen staan, zodat de linker dat niet meer hoeft te doen tijdens het starten van een applicaties.

Zie (speciaal voor gebruik onder Gentoo): http://www.gentoo.org/doc/en/prelink-howto.xml

Maar ik zou het niet klakkeloos gaan doen, eerst even zeker weten dat het gaat werken (juiste versies van de stuff etc.). Het wordt momenteel in Portage geïntegreerd, maar sowieso is het niet moeilijk. Gewoon na elke update van een library draaien.

[ Voor 28% gewijzigd door Verwijderd op 05-01-2003 20:46 ]

[Verwijderd]

Bedankt, voor de link/uitleg. Dacht dat het een gcc optie was dus zat al druk te zoeken naar de juiste flag daarvoor.

[XTerm]

-march=(athlon* | pentium4) is *NIET* stabiel met gcc 3.2. Ik heb dit reeds meerdermalen ondervonden
-mcpu -mmmx -msse is het meest productieve dat je kan gaan.

Opnieuw compilen die hap want het is niet te betrouwen.

[Verwijderd]

/edit: oh ik dacht dat je ook echt een tunderbird had, laat dan maar zitten
ik gebruik zelf wel tbird maar ik heb dan ook een tbird

bedankt voor die prelinking guide, heel dat prelinking gebeuren was me nooit opgevallen

[ Voor 150% gewijzigd door Verwijderd op 05-01-2003 23:28 . Reden: sorry ]

[_Squatt_]

Verwijderd schreef op 05 January 2003 @ 20:41:
Re: prelinking: Hoe je prelinking aan kan zetten? Werkt alleen als je binutils >= 2.13.90 en glibc >=2.3.1 schijnt te hebben.

Met glibc 2.2.5+patch en binutils 2.12.nogiets kon het ook al.

Hier staat ook nog wat (inclusief wat cijfers).

[Wilke]

Verwijderd schreef op 05 januari 2003 @ 23:17:
bedankt voor die prelinking guide, heel dat prelinking gebeuren was me nooit opgevallen

Wel mee oppassen, is nog experimenteel.

Dus niet doen op je echte 'werkcomputer' waarvan het zuigt als je hem opnieuw moet installeren

[Verwijderd]

hm ik heb het nu al gedaan, maar je kan het veilig weer ongedaan maken, en ik heb er verder nog geen problemen mee gehad, we zullen zien bij een volgende reboot..

nou ja dat prelinking was me wel opgevallen, maar niet dat het al zo ver was