# Kompilieren von Paketen - Tempo beschleunigen

## GentooNeuling

Hallo!

Den erfahrenen Usern wird meine Frage zwar seltsam anmuten, aber ich wage sie trotzdem   :Embarassed:   (habe noch nicht mit Gentoo gearbeitet)

Wenn man mit "emerge" ein Paket über das Internet besorgt und dieses anschließend kompiliert wird, wird es da vorher auf die Festplatte gespeichert und von dort wieder zum Prozessor zwecks Kompilierung befördert, oder wird es nur im Arbeitsspeicher (soferne dieser groß genug ist) "zwischengelagert"? Das Ziel meiner Frage: ich will mir einen neuen PC aufbauen. Ist es, um den ganzen Prozess zu beschleunigen, sinnvoller, eine schnelle Festplatte (evtl. auch Raid-Verbund) zu haben oder einen schnellen Speicher/einen Speicher mit kurzen Latenzen?

Könnt Ihr mir da helfen?

Danke, viele Grüße

----------

## nikaya

http://de.gentoo-wiki.com/Emerge_beschleunigen

----------

## ichbinsisyphos

ja die pakete werden komprimiert lokal gespeichert, solange bis du sie löscht. ich glaub trotzdem dass die festplatte dich nicht bremsen wird. cpu und speicher sind ausschlaggebend.

----------

## Klaus Meier

Ich würde mal sagen, zu 99% hängt die Geschwindigkeit von der CPU ab. In verschiedenen Benchmarks hat sich gezeigt, daß die Geschwindigkeit des Speichers kaum Einfluß auf die Performance hat. Also diese ganzen wassergekühlten Riegel mit Beleuchtung bringen vielleicht 2% mehr. Bei der Festplatte würde ich schon etwas auf die Geschwindigkeit schauen, zu einem Raid würde ich dir aber nur raten, wenn du wirklich weißt, was du da tust. Es gibt hier dutzende von Threads, wo da eher weniger an Durchsatz bei raus kam.

Gut, wenn Geld keine Rolle spielt, dann natürlich von allem das Schnellste. Wenn dir aber nur eine Summe X zur Verfügung steht, dann normalen Speicher, eine halbwegs schnelle Platte und den Rest in die CPU. Und noch eins zum Speicher: 2GB vom billigsten bringen mehr als 1GB HyperGamerVerarschung.

----------

## GentooNeuling

 *Klaus Meier wrote:*   

> Und noch eins zum Speicher: 2GB vom billigsten bringen mehr als 1GB HyperGamerVerarschung.

 

 :Shocked:   Aha, das überrascht mich aber etwas. Klar, ewiges Herumspielen bei den Latenzen bringt den Aufwand nicht herein; aber ein DDR2-533-Modul müsste doch um einiges langsamer sein als ein (über das Bios korrekt eingestelltes) DDR2-800-Modul, oder ist auch hier der Unterschied marginal?

Und 2GB Hauptspeicher braucht am dringensten Windows Vista, habe ich gedacht, und nicht unbedingt Linux...  :Rolling Eyes: 

----------

## Klaus Meier

 *GentooNeuling wrote:*   

> Aha, das überrascht mich aber etwas. Klar, ewiges Herumspielen bei den Latenzen bringt den Aufwand nicht herein; aber ein DDR2-533-Modul müsste doch um einiges langsamer sein als ein (über das Bios korrekt eingestelltes) DDR2-800-Modul, oder ist auch hier der Unterschied marginal?

 

Bringt ca. 2%.

----------

## slick

 *GentooNeuling wrote:*   

> Und 2GB Hauptspeicher braucht am dringensten Windows Vista, habe ich gedacht, und nicht unbedingt Linux... 

 

Vista (ver-) braucht das auch. Bei Linux ist es nur nice to have   :Wink: 

----------

## think4urs11

 *GentooNeuling wrote:*   

> Und 2GB Hauptspeicher braucht am dringensten Windows Vista, habe ich gedacht, und nicht unbedingt Linux... 

  *slick wrote:*   

> Vista (ver-) braucht das auch. Bei Linux ist es nur nice to have  

 

Hatte da neulich einen sehr umfangreichen Test über Vista gelesen (link missing). Lt. diesem Test 'beschleunigt' Vista im Bereich 0.5 - 3GB deutlich (mit durchschnittlich 'leichten' Anwendungen), erst darüber hinaus bringt mehr RAM keine nennenswerten Performancesteigerungen mehr.

Und 2GB PC2100 CL3 sind definitiv besser geeignet um einen PC schneller zu machen als 1GB 'PC3200 CL2 3-2-5, overclocked, watercooled and personally signed by the pope'. (gleiches gilt natürlich für alle die DDR2 haben)

----------

## Carlo

Die entpackten Dateien werden selbstverständlich im Arbeitsspeicher gehalten, solange genug da ist. Ausreichend Arbeitsspeicher, eine schnelle CPU mit möglichst großen Caches und möglichst vielen Cores sind relevant. Die Geschwindigkeit von Arbeitsspecher und Festplatte sind dagegen vernachlässigbar.

 *GentooNeuling wrote:*   

> aber ein DDR2-533-Modul müsste doch um einiges langsamer sein als ein (über das Bios korrekt eingestelltes) DDR2-800-Modul, oder ist auch hier der Unterschied marginal?

 

Zum einen ändert die Bandbreite nichts an der Latenz des Arbeitsspeichers, zum anderen ist dieser in jedem Fall um Faktoren langsamer als die CPU. Die CPU greift daher nicht wahllos auf die Daten zu, sondern nutzt hierarchische Caches, verschiedene Cachestrategien und Sprungvorhersagetechniken um nach Möglichkeit die Daten schon im Cache zu haben, bevor sie benötigt werden. Desweiteren spielt die Speicheranbindung eine Rolle. Bei AMD ist die in die CPU gewandert, bei Intel nicht, was u.a. auch die unterschiedlichen Cache-Größen erklärt.

----------

## reptile

naja, die angabe (533 vs. 800) bezieht sich nicht auf die bandbreite, sondern auf die taktung des speichers. und wenn beide module jeweils 5 takte CL haben, dauern die bei 266 MHz (echtem) takt eben länger als bei 400 MHz. davon abgesehen sind die preisunterschiede zwischen 533 und 800 nicht _soo_ groß. ausserdem war es zumindest bei älteren chipsätzen so, dass die taktung des speichers zum fsb der cpu passen sollte. das ist inzwischen allerdings nicht mehr so erheblich wie früher. damals konnte es einem passieren, dass der rechner (mess-, nicht fühlbar) _langsamer_ wurde, wenn der speicher schneller eingestellt war als der fsb.

nichtsdestotrotz: zu ner aktuellen cpu würde ich vernünftigen speicher nehmen, paarweise (wg. dual-channel bei allen aktuellen chipsätzen), und dabei aber auf jeden fall die 'value'-reihen der markenhersteller, weil es die übertakter-module einfach nicht bringen (d. h. doch, sie bringen schon was, aber nicht dir, sondern dem hersteller). und ich schliesse mich den vorrednern an: size _does_ matter.

----------

## Carlo

 *reptile wrote:*   

> naja, die angabe (533 vs. 800) bezieht sich nicht auf die bandbreite, sondern auf die taktung des speichers

 

Hast ja recht, Datenübertragungsrate wäre der bessere Begriff gewesen, auch wenn "Bandbreite" oft synonym verwendet wird.

Bezüglich Festplatte: ext2 anstatt eines Journaling FS für /var/tmp/portage ist empfehlenswert.

----------

## McEnroe

Ich bin mir da nicht sicher, aber ich denke es wäre sinvoll dafür reiserfs zu nehmen, da es eher sehr viele kleine Dateien sind und dort dann noch (falls es überhaupt geht) das Journaling abzuschalten, oder?

----------

## firefly

ich habe z.b. den portage tree in ein image(mit 300MB größe) gepackt, welches mit reiserfs formatiert ist. Dadurch, das ich die blocksize auf 1024 Byte festgelegt habe (512Byte hatte zu einem absturz von mkreiserfs zu folge gehabt), sind in diesem image noch 82MB frei. Auf ner standard ext2/3 partition verbrauchte das /usr/portage verzeichniss 600MB. Und ich hatte auch probiert die blockcount bei ext2/3 zu verringern. Aber dann bekam ich das problem, das mir die inodes nach ca. 3/4 des kopierten /usr/portage verzeichnisses ausgingen.

----------

## Carlo

McEnroe: Nein, man kann Journaling bei reiserfs nicht abschalten und wie effizient die vielen kleinen Dateien abgelegt werden ist für den temporären Zweck unerheblich.

firefly: /usr/portage ist für's Compilieren irrelevant und dafür würde ich auch nie ext2 verwenden.

----------

## Necoro

 *McEnroe wrote:*   

> Ich bin mir da nicht sicher, aber ich denke es wäre sinvoll dafür reiserfs zu nehmen, da es eher sehr viele kleine Dateien sind und dort dann noch (falls es überhaupt geht) das Journaling abzuschalten, oder?

 

es ging um /var/tmp/portage - nicht um /usr/portage

(und /var/tmp/portage sitzt bei mir in ner RAM-Disk ^^ ... das sollte mit am schnellsten sein  :Wink: )

----------

## firefly

 *Carlo wrote:*   

> McEnroe: Nein, man kann Journaling bei reiserfs nicht abschalten und wie effizient die vielen kleinen Dateien abgelegt werden ist für den temporären Zweck unerheblich.
> 
> firefly: /usr/portage ist für's Compilieren irrelevant und dafür würde ich auch nie ext2 verwenden.

 

ups überlesen, das es sich ja hier um /var/tmp/portage geht   :Embarassed: 

----------

## McEnroe

 *Necoro wrote:*   

>  *McEnroe wrote:*   Ich bin mir da nicht sicher, aber ich denke es wäre sinvoll dafür reiserfs zu nehmen, da es eher sehr viele kleine Dateien sind und dort dann noch (falls es überhaupt geht) das Journaling abzuschalten, oder? 
> 
> es ging um /var/tmp/portage - nicht um /usr/portage
> 
> (und /var/tmp/portage sitzt bei mir in ner RAM-Disk ^^ ... das sollte mit am schnellsten sein )

 

Ich habe auch nichts anderes behauptet. Ein `ls -R | wc -l` liefert 8000 dateien auf 50MB...

----------

## mv

 *firefly wrote:*   

> ich habe z.b. den portage tree in ein image(mit 300MB größe) gepackt, welches mit reiserfs formatiert ist.

 

Sowohl von Geschwindigkeit als auch vom Platzbedarf her bislang ungeschlagen ist dafür squashfs+unionfs https://forums.gentoo.org/viewtopic-t-465367.html

----------

## firefly

 *mv wrote:*   

>  *firefly wrote:*   ich habe z.b. den portage tree in ein image(mit 300MB größe) gepackt, welches mit reiserfs formatiert ist. 
> 
> Sowohl von Geschwindigkeit als auch vom Platzbedarf her bislang ungeschlagen ist dafür squashfs+unionfs https://forums.gentoo.org/viewtopic-t-465367.html

 

ja nur das hierbei zusätzliche schritte notwendig sind das squashfs image beim shutdown zu aktuallisieren  :Wink:  bei meiner lösung ist das nicht notwendig.

----------

## mv

 *firefly wrote:*   

> ja nur das hierbei zusätzliche schritte notwendig sind das squashfs image beim shutdown zu aktuallisieren  bei meiner lösung ist das nicht notwendig.

 

Den Zeitvorteil hat man selbst dann, wenn man das Aktualisieren mitrechnet - emerge --sync geht einfach dermaßen viel schneller... Das größere Problem ist vielmehr, dass unionfs bei neuen Kernel-Versionen nicht immer gleich vorhanden ist und funionfs noch ein paar Probleme hat; das neue aufs geht derzeit nicht auf amd64.

Edit: Das Aktualisieren findet natürlich nur dann statt, wenn man ein emerge --sync ausgeführt hatte.

----------

## GentooNeuling

Dieses Thema habt Ihr wirklich ausführlich behandelt und aufgearbeitet   :Razz: 

----------

## Klaus Meier

Mal eine Frage zur Ramdisk. Bringt die wirklich was? Also ich stelle mir das so vor, besonders wenn ich beim gcc -pipe angebe, daß der ganze Vorgang sowieso im Speicher abläuft. Also Archiv wird ausgepackt und ist im Speicher und wird dann irgendwann mal auf die Platte geschrieben. Aber warum sollte dann der gcc auf die Platte zugreifen, die Dateien sind doch immer noch im Speicher. Und eine Ramdisk zwackt mir doch permanent etwas von meinem Speicher ab, was doch die allgemeine Performance verschlechtert. Und solange Speicher frei ist, hält Linux das Filesystem doch sowieso im Speicher.

----------

## nikaya

 *Klaus Meier wrote:*   

> Mal eine Frage zur Ramdisk. Bringt die wirklich was?

 

Bei mir definitiv ja.Ich lagere es nicht bei jedem emerge aus,aber bei größeren Brocken (glibc,gcc,xorg) schon.Der Kompileroutput läuft dann schon ein wenig schneller an einem vorbei.

 *Klaus Meier wrote:*   

> 
> 
>  Also ich stelle mir das so vor, besonders wenn ich beim gcc -pipe angebe, daß der ganze Vorgang sowieso im Speicher abläuft. Also Archiv wird ausgepackt und ist im Speicher und wird dann irgendwann mal auf die Platte geschrieben. Aber warum sollte dann der gcc auf die Platte zugreifen, die Dateien sind doch immer noch im Speicher.
> 
> 

 

 *http://de.gentoo-wiki.com/Emerge_beschleunigen#Tmpfs wrote:*   

> 
> 
> Man kann so /var/tmp/portage im Ram laufen lassen und beschleunigt dadurch emerge, da es temporäre Dateien nicht mehr in die vergleichsweise sehr lahme Festplatte schreiben muss.
> 
> [...]
> ...

 

Quelle:http://de.gentoo-wiki.com/Emerge_beschleunigen#Tmpfs

 *Klaus Meier wrote:*   

> 
> 
> Und eine Ramdisk zwackt mir doch permanent etwas von meinem Speicher ab, was doch die allgemeine Performance verschlechtert. Und solange Speicher frei ist, hält Linux das Filesystem doch sowieso im Speicher.

 

Ja,ein wenig surfen im Internet geht gerade noch.Größere Arbeiten nebenher sollte man nicht unternehmen.Ich mounte allerdings meistens 850MB von 1000MB nach tmpfs,man kann auch weniger nehmen.

Empfohlene Größen siehe hier:How much RAM will be used?

----------

## Klaus Meier

Hm, also außer bei einer Neuinstallation wäre mir das mit tmpfs zu nervig. Aber man sollte da vielleicht mal xfs probieren, da wird ja auch alles im Speicher gehalten und nur ganz selten auf die Platte geschrieben. Wäre für /var/tmp und /tmp vielleicht sowas wie eine Ramdisk on Demand. Für das normale war mir xfs dann doch zu anfälig, aber ich teste das jetzt mal an.

----------

