View previous topic :: View next topic |
Author |
Message |
Beforegod Bodhisattva
Joined: 10 Apr 2002 Posts: 1494 Location: Frankfurt/Main
|
Posted: Thu Oct 31, 2002 10:50 am Post subject: SU und Optimierungen |
|
|
So da diese Fragen ziemlich häufig auftauchen und bestimmt auch noch einige Male auftauchen werden.
Sollte einem der Zugriff zu su verwährt werden :
Bitte überprüfen ob der Benutzer in der Gruppe 'wheel' ist.
Wenn nicht bitte in der Faq nachsehen wie das geht!
https://forums.gentoo.org/faq.php#0
Zum zweiten :
Da im Moment die große Update Welle auf GCC 3.x anläuft sollte man folgenden Aspekt beachten :
Quote: |
- Aggressive Optimierungen (-march=athlon -O3) sollten vermieden werden. Wird das -march Flag gesetzt sollte ab gcc-3.1 nur noch die Option -O2 verwendet werden. -O3 funktioniert zwar bei dem größten Teil der Programme, allerdings gibt es bei Systemnahen oder größeren Programmen Probleme.
|
|
|
Back to top |
|
|
Egnat n00b
Joined: 17 Sep 2002 Posts: 14 Location: Saarlouis, Germany
|
Posted: Fri Nov 01, 2002 10:02 am Post subject: Re: SU und Optimierungen |
|
|
Beforegod wrote: |
Da im Moment die große Update Welle auf GCC 3.x anläuft sollte man folgenden Aspekt beachten :
Quote: |
- Aggressive Optimierungen (-march=athlon -O3) sollten vermieden werden. Wird das -march Flag gesetzt sollte ab gcc-3.1 nur noch die Option -O2 verwendet werden. -O3 funktioniert zwar bei dem größten Teil der Programme, allerdings gibt es bei Systemnahen oder größeren Programmen Probleme.
|
|
Hmm, aus meiner /etc/make.conf:
Code: |
CFLAGS="-pipe -O3 -fomit-frame-pointer -fstrength-reduce -frerun-cse-after-loop -frerun-loop-opt -fexpensive-optimizations -fschedule-insns2 -march=athlon-xp -mcpu=athlon-xp -mfpmath=sse -mmmx -msse -m3dnow -momit-leaf-frame-pointer"
|
Mein System läuft sehr stabil mit diesen Flags. |
|
Back to top |
|
|
Dimitri Guru
Joined: 24 Jul 2002 Posts: 373 Location: Niederbayern/Germany
|
Posted: Fri Nov 01, 2002 5:48 pm Post subject: |
|
|
Moi aussi,
hab folgende wohl auch etwas agressive Flags:
-w -march=athlon-xp -O3 -pipe -m3dnow -mmmx -msse -fomit-frame-pointer -mfpmath=sse -funroll-loops -falign-functions=4 -frerun-cse-after-loop -frerun-loop-opt -ffast-math -fforce-addr
Mein System (KDE 3.1b2, glibc2.3.1, XF4.2.1 und Kernel 2.4.19) läuft absolut stabil und schnell. (Kernel ist gepacht mit XFS und Superpage und auch mit diesen Flags übersetzt)
Dim |
|
Back to top |
|
|
Beforegod Bodhisattva
Joined: 10 Apr 2002 Posts: 1494 Location: Frankfurt/Main
|
Posted: Sun Nov 03, 2002 1:31 pm Post subject: |
|
|
Ich habe ja nicht geschrieben das es bei allen zu Probleme kommt.
Bei mir z.B. funktionierte der pppd erst nachdem ich ihm mit -O2 kompiliert habe. Desweiteren streikte bei mir manchmal auch Portage und einige Mathematische Anwendungen (sogar die fileutils!)..
Allerdings denke ich das es am gcc 3.1 liegt! |
|
Back to top |
|
|
chh Tux's lil' helper
Joined: 16 May 2002 Posts: 131 Location: Germany
|
Posted: Wed Nov 06, 2002 8:06 am Post subject: Geschwindigkeitsänderungen |
|
|
Hallo,
eine Sache würde mich da mal interessieren.
Im Moment sind meine CFLAGS: march=athlon-xp -O3 -pipe
Hat irgendjemand Erfahrungen wie sich die Geschwindigkeit der Programme aber auch die Zeit des Kompilierens verändert wenn ich das auf -O2 ändere??
Gruß
Christian |
|
Back to top |
|
|
Dimitri Guru
Joined: 24 Jul 2002 Posts: 373 Location: Niederbayern/Germany
|
Posted: Wed Nov 06, 2002 10:40 am Post subject: |
|
|
Je mehr Optimierungen Du drinnen hast desto länger dauert es natürlich. Wie lange genau hab ich noch nie gemessen. Aber bei grossen Paketen (kdelibs, kdebase etc...) schon spürbar.
Mit dem wechsel von -O3 auf O2 kommt es sicherlich darauf an welche Programme du damit kompilierts. Kate wird darum wohl auch nicht schneller starten, aber beim kernel, der glibc usw. wird es sicher etwas schneller. (Wobei ich mit dem Kernel und -O3 manchmal Probleme hatte. Alle anderen Flags von mir funktionieren)
Dim |
|
Back to top |
|
|
mikegr n00b
Joined: 20 Aug 2002 Posts: 11 Location: Linz, Austria
|
Posted: Thu Nov 07, 2002 7:51 pm Post subject: su und -O3 |
|
|
Ich rate ebenfalls von der Verwendung von -O3 ab. Bei mir klappt dadurch mit su nicht und auch die KDE-Anwendungen mit Rootrechten wollen als normaler User nicht.
Mike |
|
Back to top |
|
|
mikegr n00b
Joined: 20 Aug 2002 Posts: 11 Location: Linz, Austria
|
Posted: Thu Nov 07, 2002 7:57 pm Post subject: su und -O3 |
|
|
Ich rate ebenfalls von der Verwendung von -O3 ab. Bei mir klappt dadurch mit su nicht und auch die KDE-Anwendungen mit Rootrechten wollen als normaler User nicht.
Mike |
|
Back to top |
|
|
kl@us n00b
Joined: 21 Aug 2002 Posts: 45 Location: Germany / Schwerte
|
Posted: Fri Nov 15, 2002 8:00 am Post subject: Re: Geschwindigkeitsänderungen |
|
|
chh wrote: | Hallo,
eine Sache würde mich da mal interessieren.
Im Moment sind meine CFLAGS: march=athlon-xp -O3 -pipe
Hat irgendjemand Erfahrungen wie sich die Geschwindigkeit der Programme aber auch die Zeit des Kompilierens verändert wenn ich das auf -O2 ändere??
Gruß
Christian |
Hi chh,
weil´s gerade so gut zu meiner Situation passt -durfte Gentoo aufgrund eines Hirnblackouts noch einmal von Stage1 installieren- hier ein kleiner Erfahrungsbericht:
Ich hatte mein altes Gentoo (1.4rc1) mit "march=athlon-xp -O3 -pipe -hau rein -gib alles -lauf du Sau -hier kommen noch 10 Zeilen" compiliert.
Alles, aber wirklich alles, lief ohne Fehlermeldund durch; nur die Geschwindigkeit, die ich alleine aufgrund meiner Hardware erwartet habe, war nicht signifikant anders als die einer SuSE o. RedHat Distri.
Habe einen XP 2400+ mit 768MB Ram + eine GForce 4600.
Gestern habe ich das Basissystem mit "march=athlon-xp -O3 -pipe -fomit-frame-pointer" compiliert. Dann aber xfree, kde, gnome & mozilla mit "O2". Was sol ich sagen, außer daß es in einer Höllengeschwindigkeit getan war -kde komplett in 328min., xfree in 74 min., etc.- hat es den überaus angenehmen Vorteil das kde und gnome jetzt _wirklich_ schnell sind. Gnome startet schneller als unser Kanzler Steuern eintreibt; dachte ich vorher immer ich müßte kde anschubsen, so staune ich jetzt nur noch . Ich kam vor Lachen kaum zum schlafen...
Mozilla, dieses Monster, macht Spass! Und das schon beim starten.
Auch ich dachte bis gestern, wenn nicht wenigstens 10 Zeilen Cflags folgen, kann´s ja nix sein.
Ok, ein wirklicher Vergleich kann ja nur erfolgen, wenn man das System mindestens ein 2tes Mal mit anderen Flags compiliert hat. Also, solltet ihr euer System ´mal zerschiessen, habt den Mut "nur O2" zu nehmen. Aus vielen NG und Foren ist zu entnehmen, daß "fomit-frame-pointer" wesentlichen Speed gibt, von daher habe ich es dringelassen. Hier, und im Mandrake-Forum gibt es einen interessanten Thread zum Thema Mandrake 9.0 -KDE & Gnome schneller als Gentoo, etc.- Auch die bauen ihre Binaries mit "O2"! Also, muß nicht für jeden passen, aber es ist einen Versuch wert.
...und man schreibt sich nicht die Finger in der "/etc/make.config" blutig!
Gruß
Klaus _________________ "warum heissen eigentlich alle frauen mit nachnamen jpg ?" [Frage an das Internet Orakel] |
|
Back to top |
|
|
Beforegod Bodhisattva
Joined: 10 Apr 2002 Posts: 1494 Location: Frankfurt/Main
|
Posted: Fri Nov 15, 2002 11:25 am Post subject: |
|
|
Das wichtigste ist ab gcc 3.x die -march Optimierungen..
Meine Optimierungen belaufen sich auf :
-march=athlon-xp -m3dnow -mmmx -O2
und alles läuft superschnell
Mein GNOME 2 läuft schneller als auf vergleichbaren Systemen mit SuSE und RedHat |
|
Back to top |
|
|
maystorm Apprentice
Joined: 02 Jun 2002 Posts: 222 Location: Germany, not far away
|
Posted: Sun Dec 01, 2002 12:26 am Post subject: |
|
|
Na ja, solange es keine verlässlichen Benchmarks gibt, die die verschiedenen Optimierungsoptionen miteinander vergleichen, bleiben die ganzen Diskussionen über den "superlangsamen Mozilla" bis hin zum "sauschnellen Starten von KDE/Gnome" doch nur reine Spekulation.
Zu viele Faktoren spielen hierbei einfach eine Rolle: CPU-Hersteller und -Takt, Mainboard und Chipsatz, Festplatte(n) und ihre Einstellung(en) (hier besonders DMA-Zugriff, PIO-Modus, 32-bit-Zugriff und dgl.), Art und Größe des verfügbaren RAM-Speichers, usw. usw.
Compiler-Optionen, die auf einem bestimmten Rechner A eine höhere Performance ergeben, müssen dies nicht auch zwangsläufig auf einem anderen Rechner B tun.
YMMV. _________________ Linux user #216018 |
|
Back to top |
|
|
Lasker Guru
Joined: 17 Jul 2002 Posts: 445
|
Posted: Sun Dec 01, 2002 11:02 am Post subject: Re: Geschwindigkeitsänderungen |
|
|
kl@us wrote: |
Gestern habe ich das Basissystem mit "march=athlon-xp -O3 -pipe -fomit-frame-pointer" compiliert. Dann aber xfree, kde, gnome & mozilla mit "O2". Was sol ich sagen, außer daß es in einer Höllengeschwindigkeit getan war -kde komplett in 328min., xfree in 74 min., etc.- hat es den überaus angenehmen Vorteil das kde und gnome jetzt _wirklich_ schnell sind. |
Es gibt einen gigantischen thread über das Thema in CFLAGS Central:
https://forums.gentoo.org/viewtopic.php?t=5717&highlight=cflags
Darin fand ich einen interessanten Beitrag zum Unterschied zwischen O2 und O3.
Der Author vertritt darin die Ansicht, dass bei moderner Hardware der Engpass die Festplatte wäre:
Mit anderen Worten, während Geschwindigkeitsvorteile bei den laufenden Programmen zwischen mit O2 und O3 compilierten
Programmen kaum noch spürbar wären, würde die O3 Compilierung längeren Code erzeugen und die daraus resultierende
längere Ladezeit durchaus spürbar sein.
Vermutlich ist also der Rat, besser mit O2 zu optimieren, nicht von der Hand zu weisen.
Nichts desto trotz sehen meine CFLAGS so aus (gentoo 1.4, gcc 3.2):
CFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer -funroll-loops -fexpensive-optimizations -mmmx -m3dnow"
EDIT:
...und inzwischen (seit einiger Zeit schon) sehen sie so aus:
CFLAGS="-march=athlon-tbird -O2 -pipe"
Ohne einen spürbaren Unterschied übrigens...
/EDIT
Ich behaupte nicht, dass das der Weisheit letzter Schluss wäre; auf jeden Fall geht meine Kiste jetzt ab wie Zäpfchen und läuft absolut stabil.
Last edited by Lasker on Thu Jan 02, 2003 8:52 pm; edited 1 time in total |
|
Back to top |
|
|
Headhunter123 Guru
Joined: 19 Oct 2002 Posts: 509
|
|
Back to top |
|
|
olafk n00b
Joined: 19 Dec 2002 Posts: 1 Location: Berlin, Germany
|
Posted: Fri Dec 20, 2002 12:03 am Post subject: Re: Geschwindigkeitsänderungen |
|
|
Quote: | Ich hatte mein altes Gentoo (1.4rc1) mit "march=athlon-xp -O3 -pipe -hau rein -gib alles -lauf du Sau -hier kommen noch 10 Zeilen" compiliert.
[...]
|
heh ...
Quote: | Gestern habe ich das Basissystem mit "march=athlon-xp -O3 -pipe -fomit-frame-pointer" compiliert. Dann aber xfree, kde, gnome & mozilla mit "O2". Was sol ich sagen, außer daß es in einer Höllengeschwindigkeit getan war -kde komplett in 328min., xfree in 74 min., etc.- hat es den überaus angenehmen Vorteil das kde und gnome jetzt _wirklich_ schnell sind. Gnome startet schneller als unser Kanzler Steuern eintreibt; dachte ich vorher immer ich müßte kde anschubsen, so staune ich jetzt nur noch 8-) . |
ich habe jetzt ein paar postings hier gelesen (zum thema compiler flags). um die sache ggf endlich mal aufzuklaeren: also es ist doch eigentlich ganz einfach. wenn man von etwas UE-BER-HAUPT keine ahnung hat, dann liesst man doch erst einmal die bedienungsanleitung, oder meinet wegen das manual. in diesem waere es die bedienungsanleitung des kompilers den man da verwendet.
dann wird man folgende erkenntnis erlangen:
[...]
-O2 turns on all optional optimizations except for loop unrolling, function inlining, and register renaming. It also turns on the
-fforce-mem option on all machines and frame pointer elimination on machines where doing so does not interfere with debugging.
[...]
-O2 implementiert also alle optimierungen, bis auf die oben genannten (omit frame pointer eingeschlossen, da stehts auch). -fomit-frame-pointer im zusammenhang mit -O2 oder -O3 ist nicht ratsam. man kann aber durch zusaetzliches anbegen dieses parameters praktisch einen override vornehmen und nochmal etwas an performance dazu geiwnnen. wenn es allerdings sicher ist -fomit-frame-pointer ohne verlust der debug funktionalitaet zu benutzen, dann passiert das bei -O2 automatisch.
-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore
frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.
[...]
-O2 schon implimentiert -fomit-frame-pointer, aber nur gg. dem f. das es ein dubuggen des codes nicht unmoeglich macht. solche sachen sind stark arch abhaengig und man sollte sich zunaehst ein wenig mit x86 Assembler und pointern, heap und stack auseinander setzen um zu verstehen was dort auf maschinen ebene eigentlich passiert. dieses blinde optimieren und flags raten finde ich ehrlich gesagt zeihmlich unsinnig. lesen wir weiter ...
[...]
-O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers
options.
[...]
-O2 + die bei -O2 ausgeschlossenen optionen -frename-registers und -finline-functions werden also von -O3 implementiert.
-frename-registers
Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization
will most benefit processors with lots of registers. It can, however, make debugging impossible, since variables will no longer stay in a
``home register''.
-finline-functions
Integrate all simple functions into their callers. The compiler heuristically decides which functions are simple enough to be worth inte-
grating in this way.
[...]
wie einer meiner vorredner bereits sehr richtig bemerkte, ist der unterschied zwischen -O2 und -O3 kaum spuerbar, groesserer code laed nur laenger. die performance misst man dann auch eher zur laufzeit, also wenn sich das programm bereits im speicher befindet. ggf bemerkt man einen performance gewinn von ein paar usec beim starten wenn man das ganze von, sagen wir einer ramdisk, aus startet.
desweiteren habe ich beim aktuellen stage3-athlon.tbird-hastenichtgesehen tarball, sowie in vielen postings hier, einige unstimmigkeiten bemerkt. ein deklarieren von -march UND -mcpu zusammen finde ich ziehmlich unsinnig, da -march -mcpu implementiert, jedoch noch weiter geht und die combability zu anderen cpus bricht. wie genau sich gcc verhaelt wenn man beides nacheinander deklariert, ich weiss es nicht. wahrscheinlich applied er nur den letzten der sich wiedersprechenden parameter, in diesem fall -mcpu. ich hab mir den kram dann lieber von stage1 an nochmal selber gebaut.
nur was sagt uns das? immer erstmal lesen. man gcc ist dein freund. in diesem sinne,
messer, schere, licht, sind fuer kleine kinder nicht ...
oder etwas serioeser ausgedrueckt: ich empfehle dringend die weiterfuehrende dokumentation zum compiler und den einzelnen optimierungsmoeglichkeiten zu studieren, bevor der zu kompilierende code willkuerlich veroptimiert wird. ich denke minimale voraussetzungen fuer solche optimierungen sind grundkenntnisse der x86 arch, sowie x86 assembler und in C.
s/x86/$your_arch/g;
Quote: |
Ich kam vor Lachen kaum zum schlafen...
|
selbsterkenntnis ist der erste weg zur besserung |
|
Back to top |
|
|
Dimitri Guru
Joined: 24 Jul 2002 Posts: 373 Location: Niederbayern/Germany
|
Posted: Thu Jan 02, 2003 7:54 pm Post subject: |
|
|
Ich bereue alles. *g*
Nach einigen "Modifikationen" (hehe) war ich mal wieder soweit mich zu entscheiden ein kaputtes System zu reparieren oder komplett neu zu installieren. Und ich hab mich (wie üblich eigentlich) für eine Neuinstallation entschieden. Und das ganze nur mit -O2 -pipe -fomit-frame-pointer. Und ich muss sagen die ganzen Optimierungen (siehe oben) waren eigentlich für die Katz. Was meinen Erfahrungen nach wirklich was gebracht hat, ist der Upgade auf glib 2.3.1, gcc 2.3.x und der Superpage Patch für Athlon. Alles andere ist nur Augenwischerei. Na ja fast alles: Man kann schon mal versuchen den Kernel mit härteren Optionen zu kompilieren. Bringt beim starten ca. 2 Sekunden. Ansonsten überhaupt nichts. Und ich hab wirklich viel ausprobiert.
Dim _________________ Visit kde-forum.de |
|
Back to top |
|
|
ajordan Guru
Joined: 10 Sep 2002 Posts: 320 Location: Hannover / Germany
|
|
Back to top |
|
|
KiLLaCaT Guru
Joined: 24 Jul 2002 Posts: 306 Location: Linz, Austria
|
Posted: Thu Jan 02, 2003 10:49 pm Post subject: |
|
|
genau das hab ich mich auch gefragt. schau mal hier nach!
mfg, jakob |
|
Back to top |
|
|
amiga n00b
Joined: 15 Jan 2003 Posts: 9
|
Posted: Thu Jan 16, 2003 10:55 am Post subject: |
|
|
bei mir läufts mit -march=athlon-xp und -O3 auch ganz gut. Aber mal eine Frage: in der make.defaults steht schon -O2. Wird das ignoriert wenn man in der make.conf -O3 angibt ? |
|
Back to top |
|
|
Dimitri Guru
Joined: 24 Jul 2002 Posts: 373 Location: Niederbayern/Germany
|
Posted: Thu Jan 16, 2003 11:26 am Post subject: |
|
|
Kurz gesagt: Ja
Änderungen sollten auch nur in der make.conf gemacht werden.
Dim _________________ Visit kde-forum.de |
|
Back to top |
|
|
Tox n00b
Joined: 15 Jan 2003 Posts: 5
|
Posted: Fri Jan 17, 2003 6:41 pm Post subject: |
|
|
Ich habe einen Duron 1300 (Morgan-Core).
Welche Optimierung ist empfehlenswert? "Duron" oder "Athlon-XP"?
Eigentlich hat der Prozzi ja einen Athlon-XP-Core, andererseits weniger Cache und ist deshalb eben auch ein Duron...
Hat jemand mal 'nen Benchmark laufen lassen? |
|
Back to top |
|
|
Dimitri Guru
Joined: 24 Jul 2002 Posts: 373 Location: Niederbayern/Germany
|
Posted: Sat Jan 18, 2003 9:00 am Post subject: |
|
|
Hi,
wichtig ist der Befehlssatz nicht der Cache. Ich würd also athlon-xp nehmen.
Dim _________________ Visit kde-forum.de |
|
Back to top |
|
|
Tox n00b
Joined: 15 Jan 2003 Posts: 5
|
Posted: Sat Jan 18, 2003 1:21 pm Post subject: |
|
|
So sehe ich das eigentlich auch. Nur stellt sich dann die Frage, wieso überhaupt eine Option "Duron" existiert... weil der Duron ja bekanntermaßen keinen eigenen Befehlssatz hat... |
|
Back to top |
|
|
Dimitri Guru
Joined: 24 Jul 2002 Posts: 373 Location: Niederbayern/Germany
|
Posted: Sat Jan 18, 2003 3:34 pm Post subject: |
|
|
Ich kenn mich da nicht so aus, kann mir aber Vorstellen, das der Duron in etwa sowas ist wie damals ein 368 DX und 386 SX als mal mit und mal ohne Coprozessor. (Klar hat der Duron eine FPU nur vom Prinzip her)
Wär interessant zu wissen, ob mit athlon-xp compilierte Programme auf einem Duron laufen...
Dim _________________ Visit kde-forum.de |
|
Back to top |
|
|
Tox n00b
Joined: 15 Jan 2003 Posts: 5
|
Posted: Sun Jan 19, 2003 8:18 am Post subject: |
|
|
naja, soweit ich weiß ist der einizige Unterschied die Cache-Größe.
LAUFEN tun für Athlon-XP optimierte Programme, die Frage ist halt nur, ob sie auch OPTIMAL laufen... |
|
Back to top |
|
|
Donnergurgler Apprentice
Joined: 17 Jan 2003 Posts: 202 Location: Schnongs-Zone
|
Posted: Fri Jan 31, 2003 9:27 pm Post subject: |
|
|
Ich würde den CFLAGS noch "-s" hinzufügen.
man gcc:
-s Remove all symbol table and relocation information from the exe-
cutable
Meine Flags:
CFLAGS="-s -march=k6-3 -O2 -pipe -m3dnow -mmmx"
CXXFLAGS="${CFLAGS}"
Just my 2 zsents. |
|
Back to top |
|
|
|