# KDE kompiliert seit fast 48 Stunden!?

## Chr!s

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:

```

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.

```

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?

```

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

----------

## Shagrath

-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

----------

## Aproxx

Ich will ja nicht angeben, aber auf meinem Dual Opteron hat kde 3.3.2 1.5 Stunden gebraucht.

----------

## STiGMaTa_ch

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  :Cool: 

----------

## /dev/blackhawk

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

----------

## morbus

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

----------

## Chr!s

 *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...  :Wink: 

 *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]

----------

## /dev/blackhawk

 * 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  :Very Happy: .

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

```
-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.
```

----------

## c07

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: 

```
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.

----------

## pablo_supertux

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)

----------

## Sonic Lux

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.

----------

## tam

 *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.

----------

## c07

 *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.

----------

## ank666

Kann man jetzt irgendwie ne allgemeine Aussage ala

"emerge kde mit folgenden Flags dann rennt es wie sau" machen?

----------

## Chr!s

 *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?".

----------

## Jinidog

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

----------

## Sonic Lux

df -h   :Very Happy: 

Schau mal, irgendwo gibts "Das Linuxbuch" oder so

----------

## Sonic Lux

 *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  :Rolling Eyes:  und dazu das total veraltete nbench.

und dann noch synthetische benchs .. und und und 

--> völlig unaussagekräftig.

----------

## Jinidog

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.

----------

## c07

 *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.

----------

## Jinidog

 *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.

----------

## c07

 *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:

```
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:

```
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
```

----------

## pir187

mein p2-400 (512mb ram) braucht gute 36h für den kompletten durchgang. allerdings mit o2...

mfg, pir187

----------

## dma147

 *c07 wrote:*   

> [...]
> 
> Für genauere Abschätzungen: 
> 
> ```
> ...

 

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:

```
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.

----------

## Shagrath

 *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?!
> ...

 

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.

----------

## Chr!s

 *Shagrath wrote:*   

>  *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?!
> ...

 

Danke für die Hilfe hier... KDE ist auch schon seit gestern 22 Uhr fertig...

sollte ich es noch einmal kompilieren oder zu wenig performance haben,

werde ich auf jeden Fall mit -Os kompilieren...

Jetzt muss ich das erstmal alles zum laufen bekommen... 

aber wohl besser in einem neuen Thread?

```

Fatal server error:

Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices

```

----------

## c07

 *Shagrath wrote:*   

> Der gcc produziert bei zu aggressiver Optimierung kaputten Code.

 

Er hat halt Bugs, vor allem bei Optionen, die weniger gebräuchlich und damit weniger getestet sind (dazu gehört eher -Os als -O3). Mit aggressiver Optimierung hat das wenig zu tun. Und dann gibts noch Programme, die nicht nach den aktuellen Standards programmiert sind und dadurch insbesondere mit -fstrict-aliasing (in -O2) Probleme haben.

 *Shagrath wrote:*   

> 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.

 

Die absolute Performance ist eher nebensächlich. Entscheidend ist, ob sie relativ zu den anderen Komponenten einen Flaschenhals darstellt oder nicht.

 *dma147 wrote:*   

> basc-1.5.8 ist momentan noch ~KEYWORD, was aber nicht unstable bedeutet, sondern eher "testing".

 

Ok, das ist wohl korrekter. Ich gebrauch "unstable" hier einfach in der Bedeutung "nicht unbedingt stable", wie es bei Testversionen öfters getan wird. Ich hab ja selber 1.5.8 ohne irgendwelche Probleme.

 *dma147 wrote:*   

> Zum installieren muss man Folgendes tun: 
> 
> ```
> echo "app-portage/basc" >> /etc/portage/package.keywords && emerge -av basc
> ```
> ...

 

Da fehlt aber noch ein " ~x86" hinter "app-portage/basc" bzw. halt das passende Keyword.

----------

## Shagrath

 *c07 wrote:*   

>  *Shagrath wrote:*   Der gcc produziert bei zu aggressiver Optimierung kaputten Code. 
> 
> Er hat halt Bugs, vor allem bei Optionen, die weniger gebräuchlich und damit weniger getestet sind (dazu gehört eher -Os als -O3). Mit aggressiver Optimierung hat das wenig zu tun. Und dann gibts noch Programme, die nicht nach den aktuellen Standards programmiert sind und dadurch insbesondere mit -fstrict-aliasing (in -O2) Probleme haben.

 Das versteh ich nicht ganz. -Os und -O3 sind doch Metaflags, nur das der gcc bei -Os ein paar auslässt um ein schlankeres Binary zu erreichen. Eigentlich sollte das dann doch sogar fehlerfreieren Code produzieren?Last edited by Shagrath on Tue Feb 01, 2005 3:09 pm; edited 1 time in total

----------

## ScarKS

Bei mir hat kde über nacht kompiliert. Waren glaube ich 10 Stunden oder so.

Hab aber auch nen athlon xp 2400+ (2000mhz) 256 ddrram und 1,5 gb swap.

Scar

----------

## c07

 *Shagrath wrote:*   

> -Os und -O3 sind doch Metaflags, nur das bei -Os ein paar auslässt um ein schlankeres Binary zu erreichen.

 

-O3 AFAIK schon, aber -Os hat ebenso wie -O1 viele Stellen im Code, wo es mit "if (optimize_size)" o.Ä. direkt getestet wird, ohne dass das Verhalten mit eigenen Flags steuerbar wär; insbesondere im architekturspezifischen Code. -O2 wird an ganz wenigen Stellen direkt getestet.

----------

## fennex

Zurück zum Thema, 

ich hab auch nen PIII 500 MHz und den PC wegen des lauten Lüfters 3 Tage im Keller stehen für ein KDE update. An ein World gar nicht zu denken. Es ist bestimmt schon mehr als ein Jahr her, dass ich das letzte Mal "emerge -u world" eingegeben hab.

Also nicht verzagen und den Hubschrauber pfeifen lassen...

Fennex

----------

## Lenz

Bei schwachen Rechnern würde ich da distcc empfehlen, vorausgesetzt man hat ein Netzwerk.

----------

## kurt

halo,

optimirung könnt ihr hier nach lessen

http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Optimize-Options.html#Optimize-Options

-Os oder -O3 zu verwenden ohne zu wissen was man tut ist misst, abgesehen davon dauert das compilieren länger.

gruss

kurt

----------

## Linuxstrolch

 *ScarKS wrote:*   

> Bei mir hat kde über nacht kompiliert. Waren glaube ich 10 Stunden oder so.
> 
> Hab aber auch nen athlon xp 2400+ (2000mhz) 256 ddrram und 1,5 gb swap.
> 
> Scar

 

Ich habs auch letzte Nacht kompilieren lassen. Aber nur kdebase, kdenetwork und kdeadmin. Hat auch wohl etwa 10 Stunden gedauert. Und ich hab auch nen Athlon XP 2400+ mit 256 MB DDR Ram, aber nur 512 MB Swap, 1,5 bräucht ich nie.

----------

## dma147

 *c07 wrote:*   

> [...]
> 
>  *dma147 wrote:*   Zum installieren muss man Folgendes tun: 
> 
> ```
> ...

 

Nur theoretisch. Portage fügt das fehlende ~arch selbst hinzu.

Es ist also nur wirklich notwendig, wenn man für eine andere arch crosscompiled, weil portage dort dann dennoch die eigene ~arch eintragen wollen würde.

----------

## Chr!s

 *fennex wrote:*   

> Zurück zum Thema, 
> 
> ich hab auch nen PIII 500 MHz und den PC wegen des lauten Lüfters 3 Tage im Keller stehen für ein KDE update. An ein World gar nicht zu denken. Es ist bestimmt schon mehr als ein Jahr her, dass ich das letzte Mal "emerge -u world" eingegeben hab.
> 
> Also nicht verzagen und den Hubschrauber pfeifen lassen...
> ...

 

Da mein großer Windows-Rechner 3 laute Lüfter hat und dieser immer durch lief, stört es mich nicht so arg neben meiner Linux-Kiste 

zu schlafen.

Da ich der großen Kiste, sobald ich einen neuen CPU habe eine 

Wasserkühlung verpassen werde, schaue ich mich gleich noch nach 

super-silent Lüftern für den alten um... diese sollte es mittlerweile über

eBay recht güntig geben...

```

emerge --sync

emerge --update --deep world

```

führe ich zur Zeit noch jeden Tag so aus... und es hält sich relativ in

Grenzen.

----------

## Jinidog

Ein Blick http://packages.gentoo.org/archs/x86/stable/ zeigt, welche Packete für die x86 Plattform letztens auf stable gesetzt wurden.

Ich mache höchstens einmal einen SYNC, wenn es sich denn lohnt, was ich dank dieser Liste überprüfen kann.

Wenn da nicht viel los ist, und Programme neu kommen oder geupdatet werden, die ich gar nicht verwende, dann kann ich mit einem SYNC schon einige Zeit warten.

Entlastet die SYNC-Server, was die Administratoren freut.

----------

