gcc-4.1.1 braucht mehr als 700MB Haupspeicher

[bookwood]

Ich habe ein Dell Latitude 810C Notebook mit 512MB (mehr geht nicht) Hauptspeicher. Ich nutze auf ihm seit drei Jahren begeistert Gentoo Linux. Ich habe jetzt auf gcc-4.1.1 upgegradet und mit emerge -e [system/world] alles neu kompiliert. Das einzige Packet das nicht mehr durchläuft ist kmail. Es läuft teilweise mehrere Tage und der Laptop swappt sich dum und dämlich. Im Top bekomme ich in der "Virt" Spalte, Werte von über 700 Megabyte angezeigt. Schalte ich den Swap aus stürzt der Kompiliervorgang nach wenigen Minuten mit einer

[mrsteven]

Jo, das USE-Flag kdeenablefinal kann sehr viel RAM brauchen. Entweder du schaltest es ab, oder du richtest dir ein Swapfile ein:

[moe]

Er hast doch eine swap-Partition..
Ja in den CFlags kannst du aus -O2 -Os machen, das einzige was nicht verändert werden darf, ist die Prozessorarchitektur. kdeenablefinal würde ich wirklich in deinem Fall nicht benutzen, mein Standrechner hat 1GB und fängt damit auch beim Kompilieren an zu swappen..

Gruss Maurice
_________________
Signaturen sind doof.

[Carlo]

[bookwood]

Danke Kollegen.
Das kdeenablefinal Flag hatte ich vor Ewigkeiten aktiviert als ich mit unsermake experimentierte und hatte es dann aus den Augen verloren. Ich habe gerade nochmal danach gesucht und gelesen das dieses Flag unteranderem diesen grossen Speicherverbrauch verursacht. Ich werde es jetzt deaktivieren und nochmal einen "emerge -NDu world" laufen lassen. Das Ergebniss werde ich dann hier Posten. Wenn das auch nicht hilft, baue ich das System mit -O2 neu.

[Anarcho]

Eventuell kann man noch RAM während des compilierens sparen wenn du -pipe rausnimmst.
_________________
...it's only Rock'n'Roll, but I like it!

[Fauli]

Also hier lässt sich kdepim 3.5.4 mit gcc 4.1.1, CFLAGS="-march=athlon-xp -O3 -fomit-frame-pointer -pipe" und USE="kdeenablefinal" auf 512 MB RAM plus 518 MB Swap ohne Probleme kompilieren.

Du kannst kdeenablefinal ruhig herausnehmen, das Kompilier-Ergebnis ist dasselbe. Es beschleunigt lediglich das Kompilieren, aber natürlich nur dann, wenn dein Rechner nicht deshalb anfängt zu swappen.

Bei kdeenablefinal werden die Quellcode-Dateien eines Unterprojektes aneinandergehängt und dann nur diese eine große Datei kompiliert. Das geht schneller, weil die Header-Dateien in diesem Fall nur einmal gelesen und verarbeitet werden müssen. Aber der GCC braucht zum Kompilieren der riesigen Dateien auch sehr viel Arbeitsspeicher.
_________________
Do your part to beautify the web! Turn off link underlining!

[bookwood]

Es war das Useflag kdeenablefinal. Nachdem ich es entfernt hatte lief alles sauber durch - auch kmail. kdeenablefinal sollte man also nur mit mehr als einem GB Hauptspeicher verwenden.

[schachti]

Naja, 1 GB braucht man nicht, ich habe KDE komplett mit 768 MB kompiliert, ohne daß mein Rechner wild am swappen war.
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.

How-To: Daten verschlüsselt auf DVD speichern.

[energyman76b]

naja, hast du eienn amd64 braucht kmail an der einen kritischen Stelle (es sind eigentlich sogar zwei) etwas über 800mb nur für den einen gcc-Prozess.

Was wirklich hilft ist MAKEOPTS="-j1".

Auf einer single-core Maschiene ist jeder höhere Wert sowieso unsinn. Die CPU ist so oder so IMMER ausgelastet.

Wenn man das Kompilieren beschleunigen will, sollte man PORTAGE_NICENESS auf 19 setzen. Klingt komisch, ist aber so. Der Compilierprozess kommt dann zwar nicht so oft dran, aber die Zeit die er hat ist länger - und nicht dauernd den cache und pipelines flushen zu müssen und mal eine 'zeitlang ungestört' zu sein, hilft viel.
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

I identify as a dirty penismensch.

[mrsteven]

[energyman76b]

Hi,

nöh, also das letzte, was ich gelesen hatte war, daß Prozesse mit einer hohen niceness zwar seltener drankommen, aber dafür die timeslices länger werden. Also im Endeffekt sich alles ausgleicht.

hmhm

was ist nun richtig? *kratz*
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

I identify as a dirty penismensch.

[bookwood]

Ich sprach die ganze Zeit von einem einzelnen GCC Prozess. Bei gesetztem kdeenablefinal wuchs der Speicher auf über 700 MB an und das Kompilieren lief bei mir 2 Tage - bis ich es mit STRG-C abbrach weil ich mit dem Laptop arbeiten musste. Bei ein AMD K8 den ich testweise, mit einer Crossdev Umgebung über distcc zur Hilfe nahm, war der Speicherverbrauch ebenso verherend (über 700MB). Nach dem Entfernen des kdeenablefinal Useflags lief er, wie schon gesagt, ohne Probleme durch - um 23:00 gestartet - morgens um 6:00 war alles fertig - ohne distcc und ccache - nur auf dem Laptop.

[energyman76b]

naja, bei mir läuft kdepim mit kdeenablefinal in 1h8min durch.

Im Durchschnitt...
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

I identify as a dirty penismensch.

[mrsteven]

[energyman76b]

öhm, Quelle ist gut

war in irgendeiner mail auf gentoo-user. Von einem der gentoo-devs, glaub ich *kratz*

hm,
- batch scheduling. A significant proportion of computing-intensive tasks
benefit from batch-scheduling, where timeslices are long and processes
are roundrobin scheduled. The new scheduler does such batch-scheduling
of the lowest priority tasks - so nice +19 jobs will get
'batch-scheduled' automatically. With this scheduler, nice +19 jobs are
in essence SCHED_IDLE, from an interactiveness point of view.

in /usr/src/linux/Documentation/sched-design.txt


EDIT:

was ich damit sagen will: ich habe wohl einiges falsch verstanden (unter anderem den gentoo-dev) und du hast sicher recht, aber +19 sollte trotzdem helfen.
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

I identify as a dirty penismensch.

[oscarwild]