# ccache oder tmpfs? Oder beides? Oder nix?

## Jimini

Aloha.

Ich habe soeben /var/tmp als 10G große tmpfs-Partition gemountet. Zusätzlich habe ich ccache eingerichtet, dessen Ordner unter /var/ccache auf einer ext3-Partition liegt. Da kam mir die Frage, ob sich die Geschwindigkeitsvorteile der beiden Maßnahmen vielleicht ins Gehege kommen bzw. teilweise aufheben. Hat sich da schonmal jemand eingehender mit beschäftigt?

Wie wirken sich Festplattenverschlüsselungen auf diese Maßnahmen aus, könnte das Kompilieren durch einen vermeintlichen "Turbo" dadurch letztendlich sogar ausgebremst werden?

MfG Jimini

----------

## Christian99

hi, jetzt nichts direkt zu deiner frage, aber zur geschwindigkeit:

10GB tmpfs? heißt das, du hast mehr als 10GB ram? wenn nicht, fängt das tmpfs das swappen an, wenn der arbeitsspeicher voll ist. und das ist maximal so schnell wie ein festplattenzugriff, ich glaub ich hab mal gelesen es ist sogar wesentlich langsamer. außerdem verbraucht es ram, den du nicht mehr für andere anwendung nutzen kannst, die dann eher das swappen anfangen. und DAS bremst erheblich.

Schöne Grüße

Christian

----------

## Jimini

Hm. Ich hatte das so verstanden, dass tmpfs swappt, und da dennoch nen Geschwindigkeitsvorteil bieten soll. Oder ist tmpfs einfach nur sowas wie eine Ramdisk?

MfG Jimini

----------

## Christian99

naja, ob tmpfs jetzt schneller oder langsamer ist, wenn es swappt, als dateizugriff weiß ich nicht genau, aber wenn es swappt ist der arbeitsspeicher voll, und dann swappen auch andere Programme. Und das ist soweit ich weiß auf jeden fall langsamer.

----------

## Jimini

Was mich halt wundert, ist, dass die tmpfs-Partition absolut leer ist, also 10G freien Speicherplatz bereithält. Ich habe (natürlich ;) ) _keine_ 10G RAM, sondern lediglich 4. Oder wird bei der Speicherplatzbelegung einfach möglicher Swapspace mit eingerechnet?

MfG Jimini

----------

## Hollowman

Hi

Ich hab 6 GB RAM im Rechner. Hab auch /var/tmp im RAM. Das tmpfs ist aber nur halb so Groß wie der RAM. Das was er halt automatisch macht.

CCache hab ich auch installiert. Das geht wesentlich schneller wie compilieren. Es sei denn du hast nen ne richtig dicke CPU. Lass ccache auf jeden Fall drin.

Das swappen fängt er ja erst an wenn dein RAM voll ist. Ich hab mit 2-3GB /var/tmp noch nie Probleme gehabt. Also nimm einfach die Größenangabe bei der tmpfs Partition aus der fstab raus und gut ist.

Sebastian

----------

## Klaus Meier

Nach meinen Erfahrungen bringt beides nichts. Ich habe 4GB Speicher. Der Kernel ist schon so schlau, dass er die Dateien erst mal im Speicher hält und diese beim nächsten Schritt des Kompilierens diese genutzt werden. Die Daten werden zwar irgendwann mal auf die Platte geschrieben, aber das interessiert den gcc nicht. Der liest die nicht von der Platte.

Ccache ist ja ganz nett, wenn man das gleiche Paket mehrmals hintereinander mit den gleichen Einstellungen übersetzt. Aber das macht man ja wohl eher nicht. Im normalen Betrieb hab ich da keine relevante Beschleunigung feststellen können.

Wir sind hier nicht mehr bei DOS. Der Kernel regelt das schon recht optimal, wer für was Speicher bekommt. Und das dynamisch. Das bekommst du mit einer manuellen Vergabe nicht hin. Alles, was mal im Speicher war, bleibt so lange drin, bis neuer Platz gebraucht wird.

----------

## franzf

Ich hatte das für einen Rechner mit 4GB DDR3-1333-7-7-21 + Athlon II X3 435 mal über tmpfs gemacht. Es war spür- und messbar schneller als auf Festplatte, jedoch sowas von egal, weil ein langes world-update statt 20min nur noch 18-19 braucht. Vorteil ist aber, dass die Festplatte entlastet wird. Die häufigen Schreib- und Löschvorgänge entfallen.

Wenn du testing fährst, und oftmals mehrere Gentoo-Revisionen mitnimmst (xyz-1.1-r1, xyz-1.1-r2, ...), bringt ccache sicher auch was. Bei stable ist es eher ein Overhead.

----------

## Jimini

Den mit Abstand meisten Kram baue ich auf meinem Desktop, der mit einem Core i5 750 und 4 GB RAM recht fix unterwegs ist. Entsprechend der vielen Software, die ich auf der Kiste baue, sieht mein ccache aus:

```
jimini@Deimos ~ $ ccache -s

cache directory                     /var/ccache

cache hit                          41547

cache miss                        196755

called for link                    21448

multiple source files                 31

compile failed                      5034

ccache internal error                  2

preprocessor error                  2032

not a C/C++ file                   18310

autoconf compile/link              20058

unsupported compiler option         5856

no input file                      12300

files in cache                    393510

cache size                           5.4 Gbytes

max cache size                       6.0 Gbytes
```

Die Kiste ist gerade mal 2 Monate jung. Aufgrund der Anzahl der Zugriffe dachte ich bisher, dass ccache Portage ganz gut unterstützen würde.

Kann man die Kompilierzeit eigentlich irgendwie exakt messen? Dann wäre es ja eigentlich kein Problem, da mal ein bisschen zu vergleichen.

MfG Jimini

----------

## firefly

 *Jimini wrote:*   

> Den mit Abstand meisten Kram baue ich auf meinem Desktop, der mit einem Core i5 750 und 4 GB RAM recht fix unterwegs ist. Entsprechend der vielen Software, die ich auf der Kiste baue, sieht mein ccache aus:
> 
> ```
> jimini@Deimos ~ $ ccache -s
> 
> ...

 

Auf den cache wird oft zugegriffen nur das Verhältnis zwischen "cache hit" und "cache miss" ist 1:4. Sprich für jeden erfolgreichen zugriff kommen 4 zugriffe die nicht erfolgreich waren.

Insgesammt wurden 238302 (cahce hit + chache miss) zugriffe auf den cache gemacht.

Davon waren aber nur 41547 (~17,43 %) erfolgreich -> Der cache konnte bisher nur für 17,43 % der zugriffe nützlich sein.

----------

## Klaus Meier

Die Frage ist, wa du mit exakt meinst. Ansonsten time emerge xyz

----------

## Josef.95

Hi

Ich denke das was du suchst ist ccache-3

dieses unterstützt nun auch den "direct mode"

Zitat aus den postinstall_messages  *Quote:*   

> To make optimal use of the new direct mode, please set
> 
>         CCACHE_BASEDIR="${PORTAGE_TMPDIR}/portage"
> 
> in your /etc/make.conf

 

Zu beachten ist jedoch das ccache-3 noch nicht im portage verfügbar ist und somit noch als leicht experimentell anzusehen ist.

Ich hab es hier nun seit ca drei Wochen im Einsatz und es funktioniert bisher einwandfrei.

Verfügbar ist ccache-3 zb im "mv" Overlay

Zu beachten ist auch das der bisherige Cache von ccache-2 bei der Umstellung auf Version 3 einmal vollständig gelöscht werden muss, bisherige files sind somit also erst mal verloren.

 *Jimini wrote:*   

> Kann man die Kompilierzeit eigentlich irgendwie exakt messen? Dann wäre es ja eigentlich kein Problem, da mal ein bisschen zu vergleichen.

 Ja dafür kann man zb genlop verwenden, zb 

```
genlop -t Paket
```

Ein Beispiel: (Auszug von genlop -t kdelibs)

```
     Thu Jun 10 22:01:11 2010 >>> kde-base/kdelibs-4.4.4

       merge time: 31 minutes and 35 seconds.                                                                                               

     Wed Jun 16 01:33:02 2010 >>> kde-base/kdelibs-4.4.4

       merge time: 10 minutes and 5 seconds.
```

 Der erste build war der erste mit ccache-3, der Zweite dann  nach Umstellung einer Use-Flag wo das Paket also noch mal neu übersetzt wurde,

ich denke doch das Ergebnis kann sich sehen lassen.

Aber wie schon erwähnt, ccache lohnt sich eigentlich nur wenn man Pakete wiederholt neu baut, zb nach Umstellung von Use-Flags, bauen von Paketen mit anderen Flags auch für andere Rechner/Systeme, usw

----------

## musv

Das was franzf sagt. 

Ich hatte gaaanz früher ccache im Einsatz. 

Openoffice gebaut (war ein Athlon XP): 12 Stunden. 

Openoffice neu gebaut wegen Wechsel eines Use-Flags: 1.5 Stunden. 

Ich hab mir dann aber mal die Tabelle (siehe oben) mit den Cache-Misses und Cache-Hits angesehen. Der Trefferanteil liegt im o.g. Beispiel bei 17,4%. Ich hab für mich entschieden, dass mir der Speicherplatz dann lieber ist. Negativ ist noch, dass die für den CCache verwendete Platte logischerweise schneller fragmentiert. Hatte den CCache mal gelöscht (damals Reiserfs). Das hat durchaus ein paar Minute gedauert. 

Seit ich 4 GB Ram hab, compilier ich im tmpfs. Es verringert die Plattenzugriffe spürbar. Nur KDELibs und OpenOffice reichen 2 GB tmpfs nicht. 

CCache und tmpfs zusammen funktioniert übrigens nicht bzw. bringt keinen Geschwindigkeitsvorteil.

----------

## mv

 *Josef.95 wrote:*   

> Ich denke das was du suchst ist ccache-3
> 
> dieses unterstützt nun auch den "direct mode"
> 
> Zitat aus den postinstall_messages  *Quote:*   To make optimal use of the new direct mode, please set
> ...

 

Die Meldung ist vielleicht etwas missverständlich. CCACHE_BASEDIR hat mit dem direct mode nur indirekt zu tun. Der "direct mode" bedeutet i.W. nur, dass die Zeit zum Entscheiden, ob ein Cache-Hit oder ein Cache-Miss vorliegt, etwas kürzer wird (technischer Grund: Anstelle eines Präprozessor-Laufs werden Datum und Filelänge des Files und der inkludierten Files verglichen). Durch Setzen von CCACHE_BASEDIR kann man die Wahrscheinlichkeit eines Cache-Hits erhöhen, auch (und gerade) beim Direct-Mode, wo viele der inkludierten Files im CCACHE_BASEDIR (oder Unterdirectories davon) stehen (technischer Grund: Anstelle der absoluten Filenamen werden für die Files in CCACHE_BASEDIR nur die relativen Dateinamen genommen: Dies ist wichtig, weil sich der absolute Pfad bei portage bei jedem Paketupgrade änderte).

Mit Ramdisk hat das Ganze überhaupt nichts zu tun; da besteht weder ein Zusammenhang zum "direct mode" noch zu CCACHE_BASEDIR.

Wichtiger ist, dass ccache-3 auch komprimieren kann und somit vermutlich ca. das Dreifache an cache im selben Speicher bereitstellt. Bei 4G Speicher erhöht das die "Hit"-Zahl schon deutlich. Natürlich bedeutet es leider auch, dass im "Miss"-Fall Zeit für das Komprimieren verloren geht, aber das ist kaum spürbar (und kann bei Rechnern mit langsamem IO sogar schneller sein als ohne Komprimierung). Ich würde nicht empfehlen, die Komprimierung abzuschalten.

 *Quote:*   

> Zu beachten ist auch das der bisherige Cache von ccache-2 bei der Umstellung auf Version 3 einmal vollständig gelöscht werden muss, bisherige files sind somit also erst mal verloren.

 

Deshalb lohnt es sich, die Umstellung parallel mit einem Major-Upgrade dse gcc vorzunehmen. Wer sich also noch nicht entschlossen hat, auf gcc-4.5 zu wechseln, kann jetzt beides tun   :Wink: 

 *Quote:*   

> Aber wie schon erwähnt, ccache lohnt sich eigentlich nur wenn man Pakete wiederholt neu baut

 

Es lohnt sich auch, wenn man eine neue Release eines Paketes baut, bei der sich nicht viel geändert hat. Insbesondere für große Projekte wie kdelibs, xulrunner, seamonkey usw. hat man da bei Upgrades von Minor releases oft enorm Zeitersparnis. Grundsätzlich auch fast immer bei Gentoo-releases (upgrade auf *-r1 oder *-r2 usw).

 *Quote:*   

>  zb nach Umstellung von Use-Flags, bauen von Paketen mit anderen Flags auch für andere Rechner/Systeme, usw

 

...kommt darauf an, was Du unter "anderen Flags" verstehst. Für "andere USE-Flags" oder "andere LDFLAGS" ist die Aussage richtig, für "andere CFLAGS" oder "andere CXXFLAGS" ist sie falsch (und für andere Rechner/Systeme will man ja häufig -march=... ändern): Bei Ändern der CFLAGS/CXXFLAGS kann ccache nicht mehr als sonst helfen (also nur, wenn Du schon früher einmal die entsprechenden Source-Files mit diesen CFLAGS/CXXFLAGS übersetzt hast).

----------

## mv

 *musv wrote:*   

> Negativ ist noch, dass die für den CCache verwendete Platte logischerweise schneller fragmentiert.

 

Das vermute ich nicht, da die von ccache benutzten Dateien nicht so ungewöhnlich klein sind.

 *Quote:*   

> Hatte den CCache mal gelöscht (damals Reiserfs). Das hat durchaus ein paar Minute gedauert.

 

Weil viele Dateien weiterverstreut auf der Platte liegen. Das hat aber mit Fragmentierung der Files nix zu tun.

----------

## Hollowman

 *Quote:*   

> Nach meinen Erfahrungen bringt beides nichts. Ich habe 4GB Speicher. Der Kernel ist schon so schlau, dass er die Dateien erst mal im Speicher hält und diese beim nächsten Schritt des Kompilierens diese genutzt werden. Die Daten werden zwar irgendwann mal auf die Platte geschrieben, aber das interessiert den gcc nicht. Der liest die nicht von der Platte.
> 
> Ccache ist ja ganz nett, wenn man das gleiche Paket mehrmals hintereinander mit den gleichen Einstellungen übersetzt. Aber das macht man ja wohl eher nicht. Im normalen Betrieb hab ich da keine relevante Beschleunigung feststellen können. 

 

Das will ich sehen wie der Kernel so schlau ist. Compilier mal ein Paket und achte auf deine Festplattenlampe oder benutze IOTOP. Dann mach das ganze nochmal mit tmpfs. Du wirst dich wundern. Ich merke zwischen tmpfs und nicht tmpfs nen gewaltigen Unterschied. Je lahmer die Platte, desto größer ist der Unterschied.

Bei Ccache spielen die Einstellungen keine Rolle. Bei einem geänderten USE Flag wird ja nicht der gesammte Code des Paketes verändert. Das sind ja nur Teile. Die muss man neu bauen, aber den Rest kann man aus dem Cache holen.

Ich hab ne Trefferquote von ca 26%

```

cache directory                     /root/.ccache

cache hit                         101377

cache miss                        278076

called for link                    31834

multiple source files                 12

compile failed                      8717

ccache internal error                  3

preprocessor error                  3791

cache file missing                     1

not a C/C++ file                   20958

autoconf compile/link              46397

unsupported compiler option         9838

no input file                      21484

files in cache                    180457

cache size                           1.8 Gbytes

max cache size                       2.0 Gbytes

```

Sebastian

----------

## mv

 *Hollowman wrote:*   

> Das will ich sehen wie der Kernel so schlau ist. Compilier mal ein Paket und achte auf deine Festplattenlampe oder benutze IOTOP. Dann mach das ganze nochmal mit tmpfs. Du wirst dich wundern. Ich merke zwischen tmpfs und nicht tmpfs nen gewaltigen Unterschied. Je lahmer die Platte, desto größer ist der Unterschied.

 

Das hängt sehr vom Filesystemtreiber und den Einstellungen des Filesystems ab, bei ext2|3|4 beispielsweise, ob man barriers gesetzt hat und was max_batch_time ist. Mit entsprechenden Optionen - falls das Ganze tatsächlich im Speicher gehalten werden kann - wird der Kernel durchaus bis zum Ende des emerges puffern. Ich würde solche mount-Optionen aber höchstens für eine separate /tmp-Partition empfehlen.

----------

## 69719

 *Klaus Meier wrote:*   

> 
> 
> Ccache ist ja ganz nett, wenn man das gleiche Paket mehrmals hintereinander mit den gleichen Einstellungen übersetzt. Aber das macht man ja wohl eher nicht. Im normalen Betrieb hab ich da keine relevante Beschleunigung feststellen können.

 

Das kann ich nicht behaupten, hier mal meine Statistiken anhand www-client/mozilla-firefox-3.6.4.

ohne ccache, use flags: alsa dbus java startup-notification

```

Wed Jun 30 10:35:27 2010 >>> www-client/mozilla-firefox-3.6.4

       merge time: 1 minute and 22 seconds.

```

mit ccache, use flags: alsa dbus java startup-notification

```

Wed Jun 30 10:36:43 2010 >>> www-client/mozilla-firefox-3.6.4

       merge time: 59 seconds.

```

mit ccache, use flags: alsa bindist custom-optimization dbus ipc java libnotify startup-notification system-sqlite

```

Wed Jun 30 10:51:49 2010 >>> www-client/mozilla-firefox-3.6.4

       merge time: 1 minute and 8 seconds.

```

oder auch kde-base/kdelibs-4.4.4

ohne ccache, use flags: alsa bzip2 jpeg2k mmx nls opengl semantic-desktop sse sse2 ssl

```

Wed Jun 30 11:35:08 2010 >>> kde-base/kdelibs-4.4.4                                                                                                                                                                                                  

       merge time: 9 minutes and 38 seconds.

```

mit ccache, use flags: alsa bzip2 jpeg2k mmx nls opengl semantic-desktop sse sse2 ssl

```

Wed Jun 30 11:41:59 2010 >>> kde-base/kdelibs-4.4.4                                                                                                                                                                                                  

       merge time: 4 minutes and 35 seconds.

```

Die Compiler Zeite verkürzen sich schon enorm auf eine masse an Paketen gesehen, egal ob sich die USE Flags ändern oder nicht.Last edited by 69719 on Wed Jun 30, 2010 9:43 am; edited 1 time in total

----------

## Klaus Meier

Ist ja sehr interessant, was es für unterschiedliche Erfahrungen gibt. Das die Laufwerkslampe blinkt, habe ich nie bestritten, ich habe ja auch gesagt, die Dateien werden irgendwann mal geschrieben. Nur macht es bei mir Null Unterschied von der Geschwindigkeit her.

Ich nutze ext4, wenn ich mich recht entsinne soll es da ja auch einen verbesserten Umgang mit temporären Dateien geben. Also bei mir tut sich da Null.

----------

## Hollowman

Hi

Ich nutze auch ext4 mit ner schnellen SSD. Selbst da merk ich das noch. Sicher das er dein tmpfs richtig mountet?

Sebastian

----------

## Klaus Meier

 *Hollowman wrote:*   

> Hi
> 
> Ich nutze auch ext4 mit ner schnellen SSD. Selbst da merk ich das noch. Sicher das er dein tmpfs richtig mountet?
> 
> Sebastian

 

Was kann man da denn falsch machen? Es steht ja so schon inder fstab drin, hab da nur das noexec entfernt.

```
shm                     /dev/shm        tmpfs           nodev,nosuid    0 0

```

Muss man da noch etwas anderes machen? Ach so, noch eins: PORTAGE_TMPDIR=/dev/shm habe ich auch gesetzt.

----------

## Necoro

Das ist der SharedMemory ... und was anderes ^^

du müsstest schon ein tmpfs nach /var/tmp/portage mounten ... zB so:

```
tmpfs         /var/tmp/portage tmpfs   noatime,size=1500M      0 0
```

----------

## Josef.95

Grade bei größeren Paketen wo viel Compiliert werden muss bringt ccache schon einen enormen Schub..

grad gestern gab es das Update auf firefox-3.3.6

Auch hier rannte xulrunner nur so durch (erstmals mit dem neuen ccache-3) 

```
     Thu Jun 24 15:49:15 2010 >>> net-libs/xulrunner-1.9.2.4

       merge time: 23 minutes and 53 seconds.                                                                                               

     Tue Jun 29 16:11:45 2010 >>> net-libs/xulrunner-1.9.2.6

       merge time: 7 minutes and 3 seconds.
```

Ich hab nun leider keinen direkten Vergleich zwischen ccache-2 und Version 3 , ich meine aber schon das ccache-3 noch ein gutes Stück Performance zusätzlich brachte (rein subjektiv!)

/ lauft hier auf ext4

ccache läuft auf einer anderen Platte/Partition mit reiserfs-3

und das schon seit langer Zeit ohne groß zu fragmentieren.

@mv

Danke für deine Richtigstellung und die ausführlichen Erklärungen!

----------

## franzf

@Josef.95: Schau dir mal die Liste der gefixten Bugs an. Genau einer  :Wink:  Es gibt also kaum Änderungen am Sourcecode, das Release war eine schnelle Reaktion auf einen kritischen Bug (~1 Woche nach 3.6.4). Und bei kaum Änderung ist ccache natürlich auch verdammt fix.

----------

## mv

 *Necoro wrote:*   

> Das ist der SharedMemory ... und was anderes ^^

 

Es ist nichts anderes: Es ist eine ganz normale Ramdisk im Verzeichnis /dev/shm. Dass diese Ramdisk zusätzlich von glibc genutzt werden kann, ändert an dieser Tatsache nichts.

----------

## Necoro

 *mv wrote:*   

>  *Necoro wrote:*   Das ist der SharedMemory ... und was anderes ^^ 
> 
> Es ist nichts anderes: Es ist eine ganz normale Ramdisk im Verzeichnis /dev/shm. Dass diese Ramdisk zusätzlich von glibc genutzt werden kann, ändert an dieser Tatsache nichts.

 

Oh ok ... hatte als ich den Post geschrieben hatte, auch nicht gesehen, dass PORTAGE_TMPDIR entsprechend angepasst wurde.

----------

## Klaus Meier

Aber ich kann machen was ich will, ich bekomme es mit keinem TMPDIR schneller. Kann es daran liegen, dass ich -pipe verwende?

----------

## mv

 *Necoro wrote:*   

>  *mv wrote:*    *Necoro wrote:*   Das ist der SharedMemory ... und was anderes ^^ 
> 
> Es ist nichts anderes: Es ist eine ganz normale Ramdisk im Verzeichnis /dev/shm. Dass diese Ramdisk zusätzlich von glibc genutzt werden kann, ändert an dieser Tatsache nichts. 
> 
> Oh ok ... hatte als ich den Post geschrieben hatte, auch nicht gesehen, dass PORTAGE_TMPDIR entsprechend angepasst wurde.

 

Übrigens hast Du natürlich recht, dass man /dev/shm nicht als PORTAGE_TMPDIR nutzen sollte, und zwar aus dem selben Grund, weshalb man /tmp nicht als PORTAGE_TMPDIR nutzen sollte: Portage erstellt in dieses Directory Files/Unterdirectories mit vorhersagbaren Namen. Daher könnte jeder Benutzer dieses Rechners eine Symlink-Attacke starten.

----------

## think4urs11

Keine direkte Supportfrage und auf Antrag des Threadstarters moved from Deutsches Forum (German) to Diskussionsforum.

----------

## Necoro

Gerade gesehen: http://blog.flameeyes.eu/2010/07/12/debunking-ccache-myths-redux  :Smile: 

----------

