SSD zum Kompilieren

[Xin]

Klever gemacht, vielleicht sollte man erst nachfragen, dann handeln, aber ich wollte es mal ausprobieren.

Den aktuellen Flaschenhals beim Kompilieren in meiner Konfiguration sehe ich in meiner Festplatte. 2010 Jahr habe ich auf einen i7 aufgerüstet, welcher den Kompiliervorgang von damals 50 Sekunden auf flauschige 8 Sekunden drückte.

Allerdings habe ich damals auch noch mehrere Repositorys für unterschiedliche Programme. Diese habe ich inzwischen zusammengeführt und natürlich weiterentwickelt. Nun lande ich wieder bei um die 30 Sekunden für ein Rebuild. Das ist mir zu lang, aber die auch die Makeskripte sind schon optimiert worden.

Da 8 Buildvorgänge gleichzeitig an der Festplatte ziehen, hoffe ich nun mit einer SSD was reißen zu können. Hat da jemand schon Erfahrungen mit gesammelt?

[Xin]

ForceGT 120GB bestellt, heute bespielt. Die Compilierzeit auf 14 Sekunden verkürzt.

Klevererweise habe ich erst heute festgestellt, dass ich keinen richtigen Sata III-Anschluss habe. Mainboard ist schon zu alt. :-/

[Xin]

Noch ein paar andere Testwerte.
In meinem Arbeitsrechner ist eine Samsung 753LJ HDD drin (750GB), auf der bisher auch Windows 7 installiert war.

Booten bis zur Kennworteingabe: 23,8s mit HDD, 16,7s mit SDD.
Visual Studio starten: 11s mit HDD, 4s mit SSD
Mein Projekt öffnen: 11,9s mit HDD, 3,1s mit SSD
Opera nach Neustart öffnen: 6,1s mit HDD, 1,5s mit SSD

[fat-lobyte]

Interessant. Klingt so, als ob der Bottleneck heutzutage bei der Festplatte liegt. Da fragt ich mich, ob man nicht auch Steinzeit Systeme mit geschicktem caching und etwas Kernel-Zauberei ein wenig beschleunigen könnte.

[turbo]

Hallo,

hast Du schon mal über eine Ramdisk nachgedacht?

Da Du Linux verwendest, wäre das vielleicht ein Weg:
tmpfs für die Ramdisk, die RAM dynamisch allokiert
(g)rsync, um die Daten von SSD auf die Ramdisk zu schieben, evtl. auch um wieder auf SSD zurückzuschieben

Meine Ramdisk ist um den Faktor 30/70 schneller beim lesen/schreiben als die SSD.

[Xin]

"Turbo"... den Usernamen entsprechend dem Posting gewählt?

Willkommen im Forum.

hast Du schon mal über eine Ramdisk nachgedacht?

Yupp, als die SSDs noch einiges teurerer waren habe ich darüber auch nachgedacht, aber nicht umgesetzt.

Das habe ich so vor 15 Jahren auch automatisiert gemacht. Allerdings hing sich dabei auch gerne mal das ganze System auf.
Dann waren die geänderten Quellen weg.

Allerdings muss ich dafür die Quellcodes in den RAM schieben.

Da Du Linux verwendest, wäre das vielleicht ein Weg:
tmpfs für die Ramdisk, die RAM dynamisch allokiert
(g)rsync, um die Daten von SSD auf die Ramdisk zu schieben, evtl. auch um wieder auf SSD zurückzuschieben

Das wäre dann allerdings erst beim herunterfahren?

Linux ist wesentlich stabiler als AmigaOS, dass ich damals noch verwendete. Da könnte man über das Risiko durchaus nachdenken.

Meine Ramdisk ist um den Faktor 30/70 schneller beim lesen/schreiben als die SSD.

Hast Du dafür schon Skripte?
Bzw. Lust einen Artikel dazu für's Wiki zu schreiben und den Weg dahin soweit zu erklären?

[turbo]

Hallo xin,

ich habe von C wenig Ahnung. Aber ich vermute, dass man die Verzeichnisse für die Quellen dem Compiler mitgeben kann.

Plan A für genügend RAM:
Ich würde nach dem Login des Programmierusers mit Rsync eine Kopie der C-Quellen auf die Ramdisk machen. Mit grsync gibt es auch eine GUI. Siehe http://wiki.ubuntuusers.de/rsync

Die Quelldatei, die gerade bearbeitet wird, würde ich dann mit dem Compileraufruf auf die Ramdisk schieben.

So würde man nur mit Kopien arbeiten und hätte keine Probleme, wenn der Strom ausfällt.

Code: Alles auswählen

# mit Root-Rechten eintragen in /etc/fstab
# bei Ubuntu z.B. mit: gksudo nautilus

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
tmpfs	/tmp	tmpfs	nosuid,size=16G	0	0

Mit diesem Befehl habe ich die Ramdisk auf maximal 16 GiB begrenzt (size=128M für 128 MiB). Genutzt wird nur soviel Speicher, wie benötigt wird. Wieviel das ist, kann man sich mit dem Befehl df im Terminal ansehen:

Code: Alles auswählen

df -m

Dateisystem           1M‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
tmpfs                    16384      1540     14845  10% /tmp

So sieht dann z.B. die RAM-Nutzung in MiB aus:

Code: Alles auswählen

free -m

                    total       used       free     shared    buffers     cached
Mem:         24159      10123      14035          0        244       7243
-/+ buffers/cache:       2635      21523
Swap:            0          0          0

Plan B für großzügig dimensionierten Hauptspeicher:
Wenn man viel RAM hat, kann man auch für den Input die Laufwerkspuffer statt der Ramdisk nutzen. Das ist pflegeleichter.
Man kopiert einfach die Quelldateien in die Lesepuffer. Das geht z.B. so:

Code: Alles auswählen

cp -R /quellen /dev/null

Diese Kopie der Quellen kann frühzeitig erfolgen, wenn RAM danach nicht anderweitig verwendet wird. Die Quellen werden in's Nirwana geschrieben, aber sie bleiben im Lesepuffer. Die zuletzt geänderte Datei steht ohnehin schon im Puffer. Die Ramdisk würde dann nur noch das Compilat oder temporäre Dateien aufnehmen.

Die Datenübertragungsraten vom Lesepuffer auf die Ramdisk betragen auf einem i7-950 ca. 10 GiB/s.

Solche Aktionen machen natürlich keinen Sinn, wenn aufgrund von RAM-Engpässen swap genutzt wird.

[Xin]

ich habe von C wenig Ahnung. Aber ich vermute, dass man die Verzeichnisse für die Quellen dem Compiler mitgeben kann.

Kann man.

Das Problem ist hier - denke ich - das viele hinzugelinkte Libs noch auf der Festplatte liegen.
Und das komplette System auf die RAM-Disk zu synchronisieren ist vielleicht etwas übertrieben, das erhöht massiv die Bootzeiten.

Plan A für genügend RAM:
Ich würde nach dem Login des Programmierusers mit Rsync eine Kopie der C-Quellen auf die Ramdisk machen. Mit grsync gibt es auch eine GUI. Siehe http://wiki.ubuntuusers.de/rsync

Die Quelldatei, die gerade bearbeitet wird, würde ich dann mit dem Compileraufruf auf die Ramdisk schieben.

So würde man nur mit Kopien arbeiten und hätte keine Probleme, wenn der Strom ausfällt.

Heißt, die Datei wird nach dem Editieren auf der HDD geschrieben und sofort(?) automatisch ins RAM kopiert? Das könnte man mal ausprobieren.

Code: Alles auswählen

# mit Root-Rechten eintragen in /etc/fstab
# bei Ubuntu z.B. mit: gksudo nautilus

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
tmpfs	/tmp	tmpfs	nosuid,size=16G	0	0

Mit diesem Befehl habe ich die Ramdisk auf maximal 16 GiB begrenzt (size=128M für 128 MiB). Genutzt wird nur soviel Speicher, wie benötigt wird. Wieviel das ist, kann man sich mit dem Befehl df im Terminal ansehen:

Um ein ausgechecktes Repository zu synchronisieren, müssten eigentlich 10-20MB reichen.

Plan B für großzügig dimensionierten Hauptspeicher:
Wenn man viel RAM hat, kann man auch für den Input die Laufwerkspuffer statt der Ramdisk nutzen. Das ist pflegeleichter.
Man kopiert einfach die Quelldateien in die Lesepuffer. Das geht z.B. so:

Code: Alles auswählen

cp -R /quellen /dev/null

Das würde ja bedeuten, dass der zweite Kompiliervorgang massiv schneller wäre, weil die Dateien schon im RAM liegen würden. Trotzdem rödelt die Festplatte.
Das scheint so also nicht zu funktionieren.

[turbo]

Lass uns mal hinten anfangen:

Plan B für großzügig dimensionierten Hauptspeicher:
Wenn man viel RAM hat, kann man auch für den Input die Laufwerkspuffer statt der Ramdisk nutzen. Das ist pflegeleichter.
Man kopiert einfach die Quelldateien in die Lesepuffer. Das geht z.B. so:

Code: Alles auswählen

cp -R /quellen /dev/null

Das würde ja bedeuten, dass der zweite Kompiliervorgang massiv schneller wäre, weil die Dateien schon im RAM liegen würden. Trotzdem rödelt die Festplatte.
Das scheint so also nicht zu funktionieren.

Bei mir funktioniert das so: Wenn ich ein DVD-ISO von Platte auf Ramdisk kopiere, dauert es das 1. Mal lange. Beim 2. Mal ist ist es ca. 1 Sekunde.

Sag mal bitte etwas zu Deinem System: Linuxdsitribution, RAM und ein free -m nach einem Reboot.

[Xin]

Sag mal bitte etwas zu Deinem System: Linuxdsitribution, RAM und ein free -m nach einem Reboot.

Debian Stable, 8GB, 'free -m' muss warten bis ich wieder an diesem Rechner sitze.