View previous topic :: View next topic |
Author |
Message |
Chr!s n00b
Joined: 26 Jan 2005 Posts: 35
|
Posted: Mon Jan 31, 2005 5:33 pm Post subject: KDE kompiliert seit fast 48 Stunden!? |
|
|
Hallo,
ich habe am Samstag mit 'emerge KDE' begonnen. Dies läuft, stand Montag
18:00 Uhr, noch immer... Ich hatte mal etwas von 11 Stunden gelesen...
Wie lange hat es bei euch gebraucht?
Hier meine Rechnerdaten:
Code: |
DeluxeSrv / # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 501.353
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 985.08
|
Ram hat das gute (alte) Stück 320 MB.
Code: |
top - 18:27:09 up 1 day, 19:39, 4 users, load average: 2.09, 2.10, 2.03
Tasks: 56 total, 3 running, 53 sleeping, 0 stopped, 0 zombie
Cpu(s): 94.9% us, 5.1% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 321200k total, 244608k used, 76592k free, 93592k buffers
Swap: 524656k total, 96k used, 524560k free, 46616k cached
|
Gibt es vielleicht auch eine Testmöglichkeit, ob meine /etc/make.conf
Einstellungen optimal sind?
Code: |
DeluxeSrv proc # cat /etc/make.conf | grep '#' -v
USE="mmx sse gtk -gnome qt kde dvd alsa cdr wifi samba apache2"
CHOST="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
ACCEPT_KEYWORDS="~x86"
MAKEOPTS="-j2"
|
Danke,
CHR!s |
|
Back to top |
|
|
Shagrath n00b
Joined: 24 Aug 2004 Posts: 32 Location: Vor meinem Monitor ^_^
|
Posted: Mon Jan 31, 2005 5:37 pm Post subject: |
|
|
-O3 und -O2 sind bei so extrem großen Paketen wie KDE äußerst unklug. -Os wäre hier eine bessere Wahl, auch im Anbetracht dessen, dass KDE bei einem -O3 relativ stark fragil werden könnte. Zudem dauerts einfach viel kürzer zu kompilieren.
Last edited by Shagrath on Mon Jan 31, 2005 5:39 pm; edited 2 times in total |
|
Back to top |
|
|
Aproxx Apprentice
Joined: 25 Jul 2003 Posts: 272
|
Posted: Mon Jan 31, 2005 5:38 pm Post subject: |
|
|
Ich will ja nicht angeben, aber auf meinem Dual Opteron hat kde 3.3.2 1.5 Stunden gebraucht. |
|
Back to top |
|
|
STiGMaTa_ch Veteran
Joined: 28 Dec 2004 Posts: 1686 Location: Rüti ZH / Schweiz
|
Posted: Mon Jan 31, 2005 5:39 pm Post subject: |
|
|
Nur die Ruhe.
Je nachdem was du alles noch dazugepappt hast, dauert es halt ne weile!
Ausserdem ist dein Kistchen ja wirklich nicht mehr der jüngste! Das dauert halt!
Nur so zum Vergleich:
Auf meinem Dell Centrino Laptop hat das kompilieren der nötigsten Pakete von KDE gute 12h gedauert.
Man beachte aber, dass ich:
- einen mehr als drei mal schnelleren Prozessor habe
- Viermal soviel Cache wie du besitze
- und etwas mehr als 3 mal mehr RAM drinn habe...
Von daher.....
Take it easy |
|
Back to top |
|
|
/dev/blackhawk Guru
Joined: 12 Feb 2004 Posts: 380 Location: Germany
|
Posted: Mon Jan 31, 2005 5:44 pm Post subject: |
|
|
Mein alter Celeron (333 Mhz, 512 MB Ram) hat für eine komplett Installation von Stage 1 weg mit Gnome so ca. 3 Tage gebraucht. Da Du mit '-O3' kompilierst sieht das doch ganz OK aus.
Was ich eigentlich damit sagen will ist, dass das für ich mich völlig in Ordnung aussieht. Ich würde nur in der make.conf das 'ACCEPT_KEYWORDS="~x86"' auskommentieren. Außer Du möchtest immer unstable/testing Pakete verwenden, was ich persönlich nur bei bestimmten/einzeln ausgewählten Paketen tun würde.
MFG
/dev/blackhawk _________________ My Work-Station:
AMD AthlonXP 1700+ @ 2450 Mhz
Epox - 8RDA3i
ATI Radeon 9800 XT @ 460 Mhz
Gentoo v.1.4; Kernel 2.6.10 Stage 1 |
|
Back to top |
|
|
morbus Tux's lil' helper
Joined: 10 May 2004 Posts: 139 Location: Munich
|
Posted: Mon Jan 31, 2005 5:45 pm Post subject: |
|
|
Außerdem wenn du ein emerge kde eingegeben hast, wirt höchstwahrscheinlich xorg und qt etc. auch noch mit gemerged, falls du das noch nicht drauf hast. und dann dauert das locker diese zeit mit O3 |
|
Back to top |
|
|
Chr!s n00b
Joined: 26 Jan 2005 Posts: 35
|
Posted: Mon Jan 31, 2005 6:08 pm Post subject: |
|
|
Shagrath wrote: | -O3 und -O2 sind bei so extrem großen Paketen wie KDE äußerst unklug. -Os wäre hier eine bessere Wahl, auch im Anbetracht dessen, dass KDE bei einem -O3 relativ stark fragil werden könnte. Zudem dauerts einfach viel kürzer zu kompilieren. |
Okay... ich versuche das jetzt noch einmal nachzuvollziehen...:
O3 und -O2 ist nichts für große Pakete?!
Ich bin bei meinen USE-Flags relativ sturr nach der Anleitung gegangen...
Quote: |
Die zweite ist das -O Flag (das ist ein grosses O, keine Null), welches für eine gcc Optimierungsklasse steht. Mögliche Klassen sind s (schlankes Kompilat, engl. size-optimized), 0 (eine Null für keine Optimierung), 1, 2 oder 3 für auf höhere Geschwindigkeit optimierte Flags (jede Klasse erbt die Flags der kleineren, zuzüglich ein paar Extras.)
|
Ist dann wohl in der Anleitung nicht so ganz richtig!?
Was bedeutet -Os detailiert?
Ich bin zwar sehr gut deutsch, aber "dass KDE bei einem -O3 relativ stark
fragil werden könnte" verstehe ich nicht ganz... bitte um klärung...
Quote: |
Ich würde nur in der make.conf das 'ACCEPT_KEYWORDS="~x86"' auskommentieren. Außer Du möchtest immer unstable/testing Pakete verwenden, was ich persönlich nur bei bestimmten/einzeln ausgewählten Paketen tun würde.
|
Oh... wusste ich nicht... werde ich sobald KDE endlich fertig ist, wieder
rausnehmen...
[OT]
Dies sind meine ersten "richtigen" Schritte auf Linux und ich muss sagen
dass es sehr interesant ist sein eigenes System von Grund auf zu erstellen.
Man verseht einige zusammenhänge viel besser und erlernt die durchaus
SEHR MÄCHTIGE Shell um einiges schneller und besser.
Es ist sogar schon in Plannung einen Alpha-Server mit Gentoo aufzusetzen.
[/OT]
Liebe Grüße,
Chr!s[/quote] |
|
Back to top |
|
|
/dev/blackhawk Guru
Joined: 12 Feb 2004 Posts: 380 Location: Germany
|
Posted: Mon Jan 31, 2005 7:00 pm Post subject: |
|
|
wrote: | Ich würde nur in der make.conf das 'ACCEPT_KEYWORDS="~x86"' auskommentieren. Außer Du möchtest immer unstable/testing Pakete verwenden, was ich persönlich nur bei bestimmten/einzeln ausgewählten Paketen tun würde.
Oh... wusste ich nicht... werde ich sobald KDE endlich fertig ist, wieder
rausnehmen... |
OK. Aber das wird zur Folge haben, das Portage dann alle Pakete wieder auf die stable Versionen downgraden will. Kommt aber bei Dir ja nicht mehr in Frage.(über 50 Stunden kompilier Zeit möchtest Du sicher nicht nochmal warten, oder? ) Ich persönlich würde jetzt einfach warten, bis die bereits installierten Pakete stable werden, also nicht downgraden, und alle neuen Sachen die hinzukommen aus dem stable tree nehmen. Es gibt sicherlich noch andere, evtl. "schönere" Lösungen. Ich hoffe da auf einfach mal auf passende Vorschläge der Anderen .
-Os bedeutet, wie Du schon selbst zitiert hast, dass die Binaries auf Größe Optimiert sind. D.h. gcc versucht, mit bestimmten Einstellungen für die Optimierung, möglichst kleine Binaries zu erzeugen. Bei so großen Sachen wie z.B. KDE macht es deshalb Sinn, die Optimierungsstufe kurzzeitig für einzelne Pakete zu wechseln.
[Edit:] Hier nochmal was zur Verdeutlichung der gcc Optimierungs Stufen:
Code: | -O0 or no -O option (default)
At this optimization level GCC does not perform any optimization and compiles the source code in the most straightforward way possible. Each command in the source code is converted directly to the corresponding instructions in the executable file, without rearrangement. This is the best option to use when debugging a program. The option -O0 is equivalent to not specifying a -O option.
-O1 or -O
This level turns on the most common forms of optimization that do not require any speed-space tradeoffs. With this option the resulting executables should be smaller and faster than with -O0. The more expensive optimizations, such as instruction scheduling, are not used at this level. Compiling with the option -O1 can often take less time than compiling with -O0, due to the reduced amounts of data that need to be processed after simple optimizations.
-O2
This option turns on further optimizations, in addition to those used by -O1. These additional optimizations include instruction scheduling. Only optimizations that do not require any speed-space tradeoffs are used, so the executable should not increase in size. The compiler will take longer to compile programs and require more memory than with -O1. This option is generally the best choice for deployment of a program, because it provides maximum optimization without increasing the executable size. It is the default optimization level for releases of GNU packages.
-O3
This option turns on more expensive optimizations, such as function inlining, in addition to all the optimizations of the lower levels -O2 and -O1. The -O3 optimization level may increase the speed of the resulting executable, but can also increase its size. Under some circumstances where these optimizations are not favorable, this option might actually make a program slower.
-funroll-loops
This option turns on loop-unrolling, and is independent of the other optimization options. It will increase the size of an executable. Whether or not this option produces a beneficial result has to be examined on a case-by-case basis.
-Os
This option selects optimizations which reduce the size of an executable. The aim of this option is to produce the smallest possible executable, for systems constrained by memory or disk space. In some cases a smaller executable will also run faster, due to better cache usage. |
_________________ My Work-Station:
AMD AthlonXP 1700+ @ 2450 Mhz
Epox - 8RDA3i
ATI Radeon 9800 XT @ 460 Mhz
Gentoo v.1.4; Kernel 2.6.10 Stage 1
Last edited by /dev/blackhawk on Mon Jan 31, 2005 7:09 pm; edited 1 time in total |
|
Back to top |
|
|
c07 Veteran
Joined: 25 Oct 2002 Posts: 1091
|
Posted: Mon Jan 31, 2005 7:07 pm Post subject: |
|
|
Wenn es nur KDE war, kommt mir 48 Stunden für das System etwas viel vor (aber bei -O3 noch im Rahmen). Bei mir (Duron 700 MHz) brauchen die größeren Pakete (kde{libs,base,pim,multimedia,network,graphics}) je um die 3 bis 5 Stunden (kdeedu IIRC noch länger, aber das hab ich nicht mehr).
Für genauere Abschätzungen: und dann http://gentoo-stats.org/ (momentan würd ich gleich Version 1.5.8 (noch unstable) nehmen, weil die eine neue Berechnung einführt).
Bei deinem System (schwache CPU, reichlich Speicher und Cache) würd ich schon eher -O3 nehmen. Das verlängert zwar die Compilierzeiten u.U. deutlich, lohnt aber im Betrieb gerade bei den großen Paketen, wenn nicht Speicher und/oder Cache der Flaschenhals ist.
-Os ist im Prinzip -O2 ohne ein paar wenige Optimierungen, die Platz kosten. -O3 macht selten was instabil. Die Optimierungen, die häufiger zu Problemen führen, sind alle auch in -O2 und -Os drin oder müssen extra angegeben werden. |
|
Back to top |
|
|
pablo_supertux Advocate
Joined: 25 Jan 2004 Posts: 2944 Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)
|
Posted: Mon Jan 31, 2005 7:10 pm Post subject: |
|
|
bei Pentium 3 ist das normal, ich hab auch P3 und hab letztes Mal 4 Tage gebraucht (weil ich ab und zu aus ausschalten musste) _________________ A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth! |
|
Back to top |
|
|
Sonic Lux Guru
Joined: 07 Mar 2004 Posts: 375 Location: Dresden / Germany
|
Posted: Mon Jan 31, 2005 7:11 pm Post subject: |
|
|
bedeutet das er bei 03 den code oprimiert aber er dadurch sehr stark aufbläht.
ich nehm immerO2, da wird auch oprimiert jedoch ohne dieses (wie ich finde) perfomanzelastige aufblähren des codes. |
|
Back to top |
|
|
tam Guru
Joined: 04 Mar 2003 Posts: 569
|
Posted: Mon Jan 31, 2005 7:12 pm Post subject: |
|
|
Chr!s wrote: | O3 und -O2 ist nichts für große Pakete?! |
Würd ich so nicht behaupten. O2 ist vollkommen in Ordung. Wenn ein Paket aus welchen Gründen auch immer was anderes verlangt, passiert dies ohne Dein Zutun sowieso. |
|
Back to top |
|
|
c07 Veteran
Joined: 25 Oct 2002 Posts: 1091
|
Posted: Mon Jan 31, 2005 7:55 pm Post subject: |
|
|
Sonic Lux wrote: | bedeutet das er bei 03 den code oprimiert aber er dadurch sehr stark aufbläht. |
Was den Code groß macht, ist nur -finline-functions, das bei -O3 dabei ist. Bei gcc 3.3 war das relativ extrem, während gcc 3.4 sehr viel sparsamer ist. Man kann auch mit "--param max-inline-insns-auto=X" steuern, wie groß eine Funktion sein darf, damit sie inline genommen wird. Standard für X ist in 3.3 300 und in 3.4.3 100. |
|
Back to top |
|
|
ank666 Guru
Joined: 12 May 2004 Posts: 319 Location: CO/BY/DE
|
Posted: Mon Jan 31, 2005 8:04 pm Post subject: |
|
|
Kann man jetzt irgendwie ne allgemeine Aussage ala
"emerge kde mit folgenden Flags dann rennt es wie sau" machen? _________________ Auf der Verpackung stand benötigt Windows 9x/2000/XP oder BESSER, deshalb hab ich Linux installiert |
|
Back to top |
|
|
Chr!s n00b
Joined: 26 Jan 2005 Posts: 35
|
Posted: Mon Jan 31, 2005 8:07 pm Post subject: |
|
|
tam wrote: | Chr!s wrote: | O3 und -O2 ist nichts für große Pakete?! |
Würd ich so nicht behaupten. O2 ist vollkommen in Ordung. Wenn ein Paket aus welchen Gründen auch immer was anderes verlangt, passiert dies ohne Dein Zutun sowieso. |
ich habe eben noch einmal auf die shell geschaut (mein Monitor-Switch
ist unterwegs...)... Als ich KDE angefangen habe, habe ich noch -O2 in der
make.conf stehen gehabt...
Habe es zwar geändert, aber noch kein env-update gemacht.
Habe die Änderung gleich rückgängig gemacht... bevor sie greift...
Gibt es irgendwo eine nette Webseite mit Linux-basics...? Z.b. ermitteln
des Plattenspeichers, ... einfach ein "Wo finde ich was?". |
|
Back to top |
|
|
Jinidog Guru
Joined: 26 Nov 2003 Posts: 593 Location: Berlin
|
Posted: Mon Jan 31, 2005 8:17 pm Post subject: |
|
|
Anstatt hier immer nur zu philosophieren, ob jetzt -O2 oder -O3 schneller ist, habe ich wenigstens einen kleinen Benchmark zwischen -Os und O3 gemacht.
Wenigstens mal ein paar verlässliche Daten, statt immer nur zu "denken".
https://forums.gentoo.org/viewtopic.php?t=288063 _________________ Just unused Microsoft-Software is good Microsoft-Software |
|
Back to top |
|
|
Sonic Lux Guru
Joined: 07 Mar 2004 Posts: 375 Location: Dresden / Germany
|
Posted: Mon Jan 31, 2005 8:39 pm Post subject: |
|
|
df -h
Schau mal, irgendwo gibts "Das Linuxbuch" oder so |
|
Back to top |
|
|
Sonic Lux Guru
Joined: 07 Mar 2004 Posts: 375 Location: Dresden / Germany
|
Posted: Mon Jan 31, 2005 8:42 pm Post subject: |
|
|
Jinidog wrote: | Anstatt hier immer nur zu philosophieren, ob jetzt -O2 oder -O3 schneller ist, habe ich wenigstens einen kleinen Benchmark zwischen -Os und O3 gemacht.
Wenigstens mal ein paar verlässliche Daten, statt immer nur zu "denken".
https://forums.gentoo.org/viewtopic.php?t=288063 |
An einem Programm und dazu das total veraltete nbench.
und dann noch synthetische benchs .. und und und
--> völlig unaussagekräftig. |
|
Back to top |
|
|
Jinidog Guru
Joined: 26 Nov 2003 Posts: 593 Location: Berlin
|
Posted: Mon Jan 31, 2005 8:44 pm Post subject: |
|
|
Ich halte einen synthetischen Aussagebench für weitaus besser, als das sonstige Luftdenken, dass man oft hier antrifft.
Das besteht meist aus "ich denke" und "ich glaube" und wird nicht im geringsten belegt.
Ein zugegeben synthetischer Benchmark ist besser als gar nichts. _________________ Just unused Microsoft-Software is good Microsoft-Software |
|
Back to top |
|
|
c07 Veteran
Joined: 25 Oct 2002 Posts: 1091
|
Posted: Mon Jan 31, 2005 8:47 pm Post subject: |
|
|
Chr!s wrote: | Habe es zwar geändert, aber noch kein env-update gemacht. |
Das wirkt automatisch spätestens beim nächsten emerge, u.U. auch schon beim nächsten Paket. Die tatsächlich verwendeten Flags kannst du in /var/db/pkg/*/*/CFLAGS überprüfen (können auch vom Ebuild verändert worden sein).
Jinidog wrote: | Anstatt hier immer nur zu philosophieren, ob jetzt -O2 oder -O3 schneller ist, habe ich wenigstens einen kleinen Benchmark zwischen -Os und O3 gemacht. |
Wobei solche Benchmarks meistens weitgehend im Cache ablaufen und ihnen deshalb die Codegröße ziemlich egal ist. |
|
Back to top |
|
|
Jinidog Guru
Joined: 26 Nov 2003 Posts: 593 Location: Berlin
|
Posted: Mon Jan 31, 2005 8:54 pm Post subject: |
|
|
Quote: |
Wobei solche Benchmarks meistens weitgehend im Cache ablaufen und ihnen deshalb die Codegröße ziemlich egal ist. |
nbench ist bei mir, je nach Flags, 37 bis 73 KB groß.
Das braucht nur am Anfang geladen werden und passt sogar in den L2-Cache.
Aber ich denke, wenn man sieht das 30% Performancesteigerung auch 30% größere Binaries nach sich zieht, kann man das schon in Relation setzen.
Die Größe der Binaries dürfte bei den meisten Rechnern mit ausreichend RAM sowieso nur bei den Ladezeiten eine Rolle spielen.
Was wirklich mal interessant wäre, wäre ein identisches System mal mit verschiedenen CFLAGS zu mergen und dann diverse Startzeiten zu stoppen.
Aber das ist sehr umständlich. _________________ Just unused Microsoft-Software is good Microsoft-Software |
|
Back to top |
|
|
c07 Veteran
Joined: 25 Oct 2002 Posts: 1091
|
Posted: Tue Feb 01, 2005 3:17 am Post subject: |
|
|
Jinidog wrote: | Die Größe der Binaries dürfte bei den meisten Rechnern mit ausreichend RAM sowieso nur bei den Ladezeiten eine Rolle spielen. |
Das Problem ist normalerweise der Cache. Kompakter Code erspart da u.U. Ladezeiten. Andererseits kann insbesondere beim Athlon der Cache u.U. effektiver genutzt werden, wenn Sprungziele auf den Anfang einer Cachezeile ausgerichtet sind, was -Os unwahrscheinlicher macht.
Für die Abschätzung der Wirkung im Alltagsbetrieb kann man den gcc selber als Benchmark nehmen. Bei mir compiliert er etwa gleich schnell, egal ob er mit -O2 oder -O3 gebaut ist (je mit -fomit-frame-pointer; -O2 ist geringfügig schneller). Mit -Os (ohne -fomit-frame-pointer, das bei -Os sinnlos ist, weil es bei x86 den Code aufbläht) braucht er knapp 10% länger.
Wer das selber überprüfen will: Da ist etwas Handarbeit gefragt. Die Ebuilds für gcc filtern viele Flags, insbesondere auch -O3 und -fomit-frame-pointer. Außerdem ist für einfache Tests der volle gcc-Bootstrap übertrieben. Also baut man manuell, ungefähr wie folgt:
Code: | ebuild /pfad/gcc-irgendwas.ebuild unpack
cp -r /var/tmp/portage/gcc-irgendwas/work/gcc-* /tmp
mkdir /tmp/O2
cd /tmp/O2
../gcc-*/configure --enable-languages=c
make CFLAGS="-pipe -march=athlon-tbird -O2 -fomit-frame-pointer" all-gcc |
Auf diese Weise kann man sich mehrere gcc mit unterschiedlichen CFLAGS bauen. Um sie zu testen, muss man sie was compilieren lassen (Achtung: Dafür dann immer die gleichen CFLAGS nehmen, damit die geleistete Arbeit vergleichbar ist!). Z.B. die Bash 3.0, die auch BAS/c nimmt:
Code: | cd /tmp
tar xzf $DISTDIR/bash-3.0.tar.gz
cd bash-3.0
DIR=/tmp/O2/gcc; export CC=$DIR/xgcc CFLAGS="-B$DIR -pipe -march=athlon-tbird -O3 -fomit-frame-pointer" CFLAGS_FOR_BUILD=-B$DIR
./configure
time make |
|
|
Back to top |
|
|
pir187 Guru
Joined: 19 Feb 2004 Posts: 309 Location: Papstdorf : Sachsen : Deutschland
|
Posted: Tue Feb 01, 2005 6:57 am Post subject: |
|
|
mein p2-400 (512mb ram) braucht gute 36h für den kompletten durchgang. allerdings mit o2...
mfg, pir187 _________________ Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
Back to top |
|
|
dma147 n00b
Joined: 20 Jun 2004 Posts: 35 Location: Berlin
|
Posted: Tue Feb 01, 2005 9:18 am Post subject: |
|
|
c07 wrote: | [...]
Für genauere Abschätzungen: und dann http://gentoo-stats.org/ (momentan würd ich gleich Version 1.5.8 (noch unstable) nehmen, weil die eine neue Berechnung einführt).
[...] |
basc-1.5.8 ist momentan noch ~KEYWORD, was aber nicht unstable bedeutet, sondern eher "testing". Es wird getestet, ob es als stable eingestuft werden kann, genau das bedeutet es. Wenn es unstable wäre, hätte es entweder gar kein Keyword, oder wäre in der package.mask.
Zum installieren muss man Folgendes tun:
Code: | echo "app-portage/basc" >> /etc/portage/package.keywords && emerge -av basc |
Davon abgesehen ist basc-1.5.8 inzwischen seit über einer Woche im Umlauf, es wird aktuell von 137 Usern verwendet (siehe: http://www.gentoo-stats.org/index.php?c=bascstats), es wurden seitdem aber absolut keine Bugs reportet. _________________ Alexander Mieland
LiSt - Linux Statistics
My system overview
Registered User #249600 |
|
Back to top |
|
|
Shagrath n00b
Joined: 24 Aug 2004 Posts: 32 Location: Vor meinem Monitor ^_^
|
Posted: Tue Feb 01, 2005 10:26 am Post subject: |
|
|
Chr!s wrote: | Shagrath wrote: | -O3 und -O2 sind bei so extrem großen Paketen wie KDE äußerst unklug. -Os wäre hier eine bessere Wahl, auch im Anbetracht dessen, dass KDE bei einem -O3 relativ stark fragil werden könnte. Zudem dauerts einfach viel kürzer zu kompilieren. |
Okay... ich versuche das jetzt noch einmal nachzuvollziehen...:
O3 und -O2 ist nichts für große Pakete?!
Ich bin bei meinen USE-Flags relativ sturr nach der Anleitung gegangen... |
Muss man relativ sehen. Der gcc produziert bei zu aggressiver Optimierung kaputten Code. Und -O3 wird generell nicht mehr empfohlen; auf die freehackersseite brauchst du da erst garnicht hören, die wurde schon ewig nicht mehr aktualisiert.
Zudem wäre bei dir -Os aus dem Grund besser, da deine Festplatte wahrscheinlich auch in die Zeit deines Prozessors passen wird und sie demnach für heutige Verhältnisse doch recht lahm ist. Was daraus resultiert (wegen -O3) sind riesige Binarys die ewig geladen werden müssen -> kein Pervormancevorteil, weder in der Laufzeit, noch beim laden. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|