Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
KDE kompiliert seit fast 48 Stunden!?
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
Chr!s
n00b
n00b


Joined: 26 Jan 2005
Posts: 35

PostPosted: Mon Jan 31, 2005 5:33 pm    Post subject: KDE kompiliert seit fast 48 Stunden!? Reply with quote

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
View user's profile Send private message
Shagrath
n00b
n00b


Joined: 24 Aug 2004
Posts: 32
Location: Vor meinem Monitor ^_^

PostPosted: Mon Jan 31, 2005 5:37 pm    Post subject: Reply with quote

-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
View user's profile Send private message
Aproxx
Apprentice
Apprentice


Joined: 25 Jul 2003
Posts: 272

PostPosted: Mon Jan 31, 2005 5:38 pm    Post subject: Reply with quote

Ich will ja nicht angeben, aber auf meinem Dual Opteron hat kde 3.3.2 1.5 Stunden gebraucht.
Back to top
View user's profile Send private message
STiGMaTa_ch
Veteran
Veteran


Joined: 28 Dec 2004
Posts: 1686
Location: Rüti ZH / Schweiz

PostPosted: Mon Jan 31, 2005 5:39 pm    Post subject: Reply with quote

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 8)
Back to top
View user's profile Send private message
/dev/blackhawk
Guru
Guru


Joined: 12 Feb 2004
Posts: 380
Location: Germany

PostPosted: Mon Jan 31, 2005 5:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
morbus
Tux's lil' helper
Tux's lil' helper


Joined: 10 May 2004
Posts: 139
Location: Munich

PostPosted: Mon Jan 31, 2005 5:45 pm    Post subject: Reply with quote

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
View user's profile Send private message
Chr!s
n00b
n00b


Joined: 26 Jan 2005
Posts: 35

PostPosted: Mon Jan 31, 2005 6:08 pm    Post subject: Reply with quote

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
View user's profile Send private message
/dev/blackhawk
Guru
Guru


Joined: 12 Feb 2004
Posts: 380
Location: Germany

PostPosted: Mon Jan 31, 2005 7:00 pm    Post subject: Reply with quote

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? :wink:) 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 :D.

-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
View user's profile Send private message
c07
Veteran
Veteran


Joined: 25 Oct 2002
Posts: 1091

PostPosted: Mon Jan 31, 2005 7:07 pm    Post subject: Reply with quote

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:
Code:
emerge basc
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
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2585
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Mon Jan 31, 2005 7:10 pm    Post subject: Reply with quote

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
View user's profile Send private message
Sonic Lux
Guru
Guru


Joined: 07 Mar 2004
Posts: 375
Location: Dresden / Germany

PostPosted: Mon Jan 31, 2005 7:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
tam
Guru
Guru


Joined: 04 Mar 2003
Posts: 569
Location: freiburg.de

PostPosted: Mon Jan 31, 2005 7:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
c07
Veteran
Veteran


Joined: 25 Oct 2002
Posts: 1091

PostPosted: Mon Jan 31, 2005 7:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
ank666
Guru
Guru


Joined: 12 May 2004
Posts: 319
Location: CO/BY/DE

PostPosted: Mon Jan 31, 2005 8:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
Chr!s
n00b
n00b


Joined: 26 Jan 2005
Posts: 35

PostPosted: Mon Jan 31, 2005 8:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
Jinidog
Guru
Guru


Joined: 26 Nov 2003
Posts: 593
Location: Berlin

PostPosted: Mon Jan 31, 2005 8:17 pm    Post subject: Reply with quote

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".
http://forums.gentoo.org/viewtopic.php?t=288063
_________________
Just unused Microsoft-Software is good Microsoft-Software
Back to top
View user's profile Send private message
Sonic Lux
Guru
Guru


Joined: 07 Mar 2004
Posts: 375
Location: Dresden / Germany

PostPosted: Mon Jan 31, 2005 8:39 pm    Post subject: Reply with quote

df -h :D

Schau mal, irgendwo gibts "Das Linuxbuch" oder so
Back to top
View user's profile Send private message
Sonic Lux
Guru
Guru


Joined: 07 Mar 2004
Posts: 375
Location: Dresden / Germany

PostPosted: Mon Jan 31, 2005 8:42 pm    Post subject: Reply with quote

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".
http://forums.gentoo.org/viewtopic.php?t=288063


An einem Programm :roll: und dazu das total veraltete nbench.
und dann noch synthetische benchs .. und und und
--> völlig unaussagekräftig.
Back to top
View user's profile Send private message
Jinidog
Guru
Guru


Joined: 26 Nov 2003
Posts: 593
Location: Berlin

PostPosted: Mon Jan 31, 2005 8:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
c07
Veteran
Veteran


Joined: 25 Oct 2002
Posts: 1091

PostPosted: Mon Jan 31, 2005 8:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
Jinidog
Guru
Guru


Joined: 26 Nov 2003
Posts: 593
Location: Berlin

PostPosted: Mon Jan 31, 2005 8:54 pm    Post subject: Reply with quote

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
View user's profile Send private message
c07
Veteran
Veteran


Joined: 25 Oct 2002
Posts: 1091

PostPosted: Tue Feb 01, 2005 3:17 am    Post subject: Reply with quote

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
View user's profile Send private message
pir187
Guru
Guru


Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland

PostPosted: Tue Feb 01, 2005 6:57 am    Post subject: Reply with quote

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
View user's profile Send private message
dma147
n00b
n00b


Joined: 20 Jun 2004
Posts: 35
Location: Berlin

PostPosted: Tue Feb 01, 2005 9:18 am    Post subject: Reply with quote

c07 wrote:
[...]
Für genauere Abschätzungen:
Code:
emerge basc
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
View user's profile Send private message
Shagrath
n00b
n00b


Joined: 24 Aug 2004
Posts: 32
Location: Vor meinem Monitor ^_^

PostPosted: Tue Feb 01, 2005 10:26 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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