# ccache-Nutzen

## Klaus Meier

Gesplittet aus [gcc]gcc-4.3: -fdirectives-only -- Finswimmer

ccache habe ich ziemlich schnell wieder weggeschmissen, weil laut log so gut wie kein Code aus dem Cache genommen wurde. Hat bei mir nichts gebracht.

Viel insteressanter finde ich, dass endlich die Unterstützung für den Core2 kommt, das kitzelt bestimmt 2% mehr Performance raus.

----------

## schachti

Also bei mir bringt der ccache eine ganze Menge, auch laut Statistik...

----------

## Klaus Meier

Bei dem einen ist Ext3 schneller, bei dem anderen reiser, bei dem einen bringt ccache was, beim anderen.... Ist das nicht irgendwie schön? Was wäre die Welt langweilig, wenn alles einfach zu erklären wäre   :Rolling Eyes: 

----------

## Mr. Anderson

hrhr. Du hast hoffentlich nicht an den CFLAGS rumgespielt. Dann kann ccache afaik nämlich nichts bringen. ^^

----------

## Klaus Meier

Soll ichs mal wieder versuchen? Habs bestimmt zwei Jahre nicht mehr getan.

----------

## Mr. Anderson

 *Klaus Meier wrote:*   

> Soll ichs mal wieder versuchen? Habs bestimmt zwei Jahre nicht mehr getan.

 

Ich werd Dich nicht abhalten  :Wink: 

Hier mal meine Statistik:

```
$ ccache -s

cache directory                     /var/tmp/ccache

cache hit                          50185

cache miss                        309007

called for link                    31558

multiple source files                 91

compile failed                      4843

preprocessor error                  3151

not a C/C++ file                   13483

autoconf compile/link              43662

unsupported compiler option         8179

no input file                      16306

files in cache                    299094

cache size                           5.5 Gbytes

max cache size                       6.0 Gbytes
```

----------

## Klaus Meier

 *Mr. Anderson wrote:*   

>  *Klaus Meier wrote:*   Soll ichs mal wieder versuchen? Habs bestimmt zwei Jahre nicht mehr getan. 
> 
> Ich werd Dich nicht abhalten 
> 
> Hier mal meine Statistik:
> ...

 

Komme bei dir auf ein cache miss / cache hit Verhältnis von ca. 15%. Finde ich noch nicht so spannend.

----------

## Mr. Anderson

Was erwartest Du? Ich übersetz mein System ja nicht ständig neu  :Wink: 

----------

## Klaus Meier

Also so ab 25%, eher 30%, würde ich darin einen Vorteil sehen. Weil ccache ja auch Performance kostet. Der Cache muß angelegt werden, es muß im Cache nachgesehen werden, ob der Code schon drin ist usw. Das heißt, jedes emerge läuft langsamer, auch wenn der Code nicht im Cache gefunden wird. Bei mir lag das Verhältnis immer so bei ca. 10%. Also von den Ergebnissen her liegen wir ähnlich, wir unterscheiden uns nur darin, wie wir sie interpretieren.

----------

## Necoro

die Menge an zusätzlich benötigtem Plattenplatz (hier 6GB) ist auch nicht zu vernachlässigen (zu mindestens nicht auf meinem Laptop  :Razz: ) - genauso die damit nun notwendig werdenden Festplattenzugriffe (ich kompiliere sonst normalerweise komplett im RAM)

----------

## 69719

```

cache directory                     /root/.ccache

cache hit                         135161

cache miss                        199525

called for link                    23978

multiple source files                 91

compile failed                      7083

preprocessor error                  7374

bad compiler arguments                 2

not a C/C++ file                   14687

autoconf compile/link              79843

unsupported compiler option         5044

no input file                      29909

files in cache                     98504

cache size                           1.8 Gbytes

max cache size                       2.0 Gbytes

```

wenn ich richtig liege? 67%

----------

## schachti

 *escor wrote:*   

> 
> 
> ```
> 
> cache directory                     /root/.ccache
> ...

 

So ähnlich sah meine Statistik bis vor kurzem auch aus, was bei mir darin begründet liegt, dass ich ein testing System fahre und oft Bugfix-Releases (-r1 etc.) installiere. Dabei ändert sich in der Regel kaum was am Code, so dass man stark vom ccache profitiert. Wenn man hingegen ein stable System fährt und nur 1 x pro Monat ein Update macht, sinkt der Nutzen von ccache natürlich gewaltig.

Aber wir schweifen vom ursprünglichen Thema ab - vielleicht könnte mal ein Mod die entsprechenden Postings in einen ccache-Diskussions-Thread abspalten - danke!   :Wink: 

----------

## Klaus Meier

Hab mir jetzt auch mal ccache draufgetan, weil ich dafür noch was nützliches entdeckt habe. Ich habe doch zweimal Gentoo auf der Platte, einmal Gnome, einmal KDE. Und da verlinkt das zweite /usr/portage auf das Erste, spart Platz und die Zeit fürs syncen. Distfiles hab ich separat, weil sonst eclean-dist zu viel wegschmeißen würde. Hatte dann überlegt, wie man identische emerge Läufe in beiden Gentoos zusammenfassen könnte. Und ich denke, da ist ein gemeinsames ccache Verzeichnis schon einen Versuch wert.

Obwohl, ist gerade ein neues xorg rausgekommen, und nachdem der erste Durchlauf ja den Cache gefüllt hat, hat der Zweite ne ziemlich schlechte Quote. Habs vergessen zu notieren, fiel mir dann nur so am Ende auf. Wohingegen die ganzen Pakete von gstreamer, obwohl sie nur einmal durchgingen, ne Quote von ca. 1:1 erreicht haben. Da soll einer schlau draus werden.

----------

## schachti

 *Klaus Meier wrote:*   

> Obwohl, ist gerade ein neues xorg rausgekommen, und nachdem der erste Durchlauf ja den Cache gefüllt hat, hat der Zweite ne ziemlich schlechte Quote. Habs vergessen zu notieren, fiel mir dann nur so am Ende auf. Wohingegen die ganzen Pakete von gstreamer, obwohl sie nur einmal durchgingen, ne Quote von ca. 1:1 erreicht haben. Da soll einer schlau draus werden.

 

Verwendest Du evtl. verschiedene USE flags oder verschiedene Einstellungen für VIDEO_CARDS bzw. INPUT_DEVICES? Oder unterscheiden sich evtl. die CFLAGS zwischen den Rechnern bzw. zwischen den Compiler-Läufen?

----------

## Klaus Meier

[quote="schachti"] *Klaus Meier wrote:*   

> Verwendest Du evtl. verschiedene USE flags oder verschiedene Einstellungen für VIDEO_CARDS bzw. INPUT_DEVICES? Oder unterscheiden sich evtl. die CFLAGS zwischen den Rechnern bzw. zwischen den Compiler-Läufen?

 

Ok, die Flags sind nicht identisch, ist halt eins Gnome und eins KDE. Aber ansonsten ist es identisch. Und beim xorg-server sind die Flags identisch.

----------

## mv

 *Klaus Meier wrote:*   

> Distfiles hab ich separat, weil sonst eclean-dist zu viel wegschmeißen würde.

 

Schau Dir mal trickyfetch an. Ist erstens zuverlässiger als eclean-dist (weil es hundertprozentig genau die für eine Reinstallation benötigten Files beibehält) und zweitens kannst Du das problemlos für mehrere chroots (mit verschiedenen Source-Archiven) machen: Nach Installation einfach Files nach $DISTDIR/.obsolete verschieben, auf jedem der chroots ein emerge --with-bdeps -feD world ausführen (was leider etwas dauert); der Rest in $DISTDIR/.obsolete ist dann für alle chroots obsolet und kann gelöscht werden (falls Du nicht spezielle Gründe hast, das nicht zu tun).

----------

## mv

 *Klaus Meier wrote:*   

> Und beim xorg-server sind die Flags identisch.

 

Auch die CFLAGS/CXXFLAGS/LDFLAGS? Und Du bist sicher, dass Du das selbe ccache-Directory benutzt?

Dann kann es eigentlich nur an irgendwelchen Header-Files liegen: Wenn sich eines der Basis-Headerfiles unterscheidet (etwa verschiedene glibc oder gcc Versionen oder ev. auch mit verschiedenen Flags installiert) wirst Du fast nur "misses" haben...

BTW: Ich komme bei mir auf 44% Hit-Rate, und auf der 32-Bit chroot sogar auf knapp 55% (Größe jeweils 2GB). Ich benutze ccache allerdings auch beim Kernel-Kompilieren und bin außerdem anscheinend ab und an mal der erste, der auf irgendwelche Bugs in Paketen stößt: Beim Schreiben von Patches brauche ich meistens mehrere Kompilationsversuche hintereinander.

----------

## Klaus Meier

 *mv wrote:*   

>  *Klaus Meier wrote:*   Distfiles hab ich separat, weil sonst eclean-dist zu viel wegschmeißen würde. 
> 
> Schau Dir mal trickyfetch an. Ist erstens zuverlässiger als eclean-dist (weil es hundertprozentig genau die für eine Reinstallation benötigten Files beibehält) und zweitens kannst Du das problemlos für mehrere chroots (mit verschiedenen Source-Archiven) machen: Nach Installation einfach Files nach $DISTDIR/.obsolete verschieben, auf jedem der chroots ein emerge --with-bdeps -feD world ausführen (was leider etwas dauert); der Rest in $DISTDIR/.obsolete ist dann für alle chroots obsolet und kann gelöscht werden (falls Du nicht spezielle Gründe hast, das nicht zu tun).

 

Sehe da jetzt noch nicht den Vorteil. Ich habe jetzt einen Ordner /ust/portage ohne distfiles, den zwei Gentoos gemeinsam benutzen. Und die Distfiles speichere ich außerhalb von /usr/portage für jede Installation separat. Hätte Interesse an einer Lösung, wo ich nur noch einen Ordner Distfiles bräuchte und mit irgendeinem Befehl nur die Files gelöscht werden, die in beiden Installationen nicht mehr gebraucht werden.

Bei trickyfetch werden ja auch separate Distfiles benutzt oder hab ich das noch nicht verstanden?Last edited by Klaus Meier on Sat Feb 02, 2008 7:24 pm; edited 1 time in total

----------

## Klaus Meier

 *mv wrote:*   

>  *Klaus Meier wrote:*   Und beim xorg-server sind die Flags identisch. 
> 
> Auch die CFLAGS/CXXFLAGS/LDFLAGS? Und Du bist sicher, dass Du das selbe ccache-Directory benutzt?
> 
> Dann kann es eigentlich nur an irgendwelchen Header-Files liegen: Wenn sich eines der Basis-Headerfiles unterscheidet (etwa verschiedene glibc oder gcc Versionen oder ev. auch mit verschiedenen Flags installiert) wirst Du fast nur "misses" haben...
> ...

 

Bei mir sind beide make.conf absolut identisch (da rüberkopiert) und danach nur noch mit ufed bearbeitet. Und beide Installationen sind von der Buildumgebung her absolut identisch, da sie ja ein gemeinsames /usr/portage benutzen.

Habe es ja jetzt erst mal 24 Stunden am laufen, muß sich der Cache ja erst mal aufbauen. War halt nur komisch, dass ich Hits hatte, wo ich keine erwartet habe und keine Hits, wo ich sie erwartete. Aber kann mir doch eigentlich egal, warum mir ccache nutzt, solange es mir nutzt   :Rolling Eyes: 

----------

## mv

 *Klaus Meier wrote:*   

> Bei trickyfetch werden ja auch separate Distfiles benutzt

 

Nein, eben nicht. Du hast ein $DISTDIR (auf das Du natürlich von beiden chroot's aus zugreifen können musst).

Dann machst Du (nachdem Du die make.conf in beiden Installationen für trickyfetch entsprechend angepasst hast) 

```
cd $DISTDIR

mkdir .obsolete

mv * .obsolete

emerge --with-bdeps=y -feD world
```

Das letzte Kommando führst du anschließend (oder auch gleichzeitig) in Deiner chroot aus.

Dadurch werden alle (in mindestens einer der beiden Installationen) benötigten Files von $DISTDIR/.obsolete wieder nach $DISTDIR geholt, und in $DISTDIR/.obsolete bleibt dasjenige, das von keinen der beiden chroots aktuell mehr benötigt wird.

----------

## Klaus Meier

 *mv wrote:*   

>  *Klaus Meier wrote:*   Bei trickyfetch werden ja auch separate Distfiles benutzt 
> 
> Nein, eben nicht. Du hast ein $DISTDIR (auf das Du natürlich von beiden chroot's aus zugreifen können musst).
> 
> Dann machst Du (nachdem Du die make.conf in beiden Installationen für trickyfetch entsprechend angepasst hast) 
> ...

 

Ok, ja, jetzt hab ich es verstanden. Mußt dann nur zum aufräumen immer wieder die jeweiligen Kommandos ausführen.

----------

## schachti

 *Klaus Meier wrote:*   

> Ok, ja, jetzt hab ich es verstanden. Mußt dann nur zum aufräumen immer wieder die jeweiligen Kommandos ausführen.

 

Stimmt - aber das läßt sich ja per cronjob automatisieren. Und gegenüber anderen Lösungen hat trickyfetch den Vorteil, dass es tatsächlich funktioniert - bei allen anderen Lösungen, die ich bisher probiert habe, wurde die eine oder andere Abhängigkeit falsch berechnet, mal wurde zu viel gelöscht, mal zu wenig.

----------

## Klaus Meier

Was sich bei mir jetzt so die Frage stellt, ist der Sinn von den bdeps. Warum wird das bei emerge -e auf y und bei emerge -u auf n gesetzt? Hat es einen Nachteil, wenn man es fest auf y setzt?

Hat mich ja mal bei einer Neuinstallation voll geschreddert, weil da teilweise neuere, nicht funktionierende Versionen installiert wurden als beim Update.

Und wenn man nach der Anleitung trickyfetch ausführt, dann hat man ja die Files für eine Neuinstallation auf der Platte, aber nicht unbedingt die, die zum laufenden System gehören.

----------

## schachti

Ich habe in meiner /etc/make.conf global

```

EMERGE_DEFAULT_OPTS="--with-bdeps y"

```

gesetzt und bisher noch keine Probleme damit gehabt.

----------

## mv

 *Klaus Meier wrote:*   

> Was sich bei mir jetzt so die Frage stellt, ist der Sinn von den bdeps. Warum wird das bei emerge -e auf y und bei emerge -u auf n gesetzt?

 

Den Default für --with-bdeps=n habe ich auch noch nie verstanden: Die meisten Leute sind nur verwirrt, wenn nicht alle Upgrades eingespielt werden, und es kann ja sogar eine Sicherheitslücke sein, wenn nicht alle installierten Pakete ge-updated werden. Ich persönlich habe ebenfalls EMERGE_DEFAULT_OPTS="--with-bdeps y" gesetzt, weil alles andere Unfug ist.

Der Wert --with-bdeps=n ist nur in Ausnahmefällen sinnvoll: Nämlich wenn man ein System hat, in dem man nur Binary-Pakete einspielt, die man auf einem anderen System vorkompiliert (etwa ein Laptop, den man grundsätzlich vom Desktop aus "versorgt", oder wenn man an einem PC-Pool die Rechner von einem "Master" aus updated). Sinnvoll wäre daher höchstens eine Kopplung des Defaults --with-bdeps=n an die Option -k o.ä.

Der Grund, weshalb ich es oben sicherheitshalber explizit mit angegeben habe, ist, dass ich davon ausgehe, dass Du die Sourcen von allen Paketen beibehalten willst; auch von denjenigen Paketen, die Du nur dazu brauchst, um andere zu installieren.

 *Quote:*   

> Hat mich ja mal bei einer Neuinstallation voll geschreddert, weil da teilweise neuere, nicht funktionierende Versionen installiert wurden als beim Update.

 

Das ist kein Bug von --with-bdeps y. Eher ist es ein Bug von --with-bdeps n, dass nicht alle Deine Pakete ge-upgradet wurden - wenn Du das viele Jahre so gemacht hättest, wären beim Update vermutlich so veraltete Tools benutzt worden, dass dieses schon alleine deswegen fehlgeschlagen wäre. Dass Du gerade das Pech hattest, dass die aktuellen (stabilen) Versionen dieser Tools Ärger machten, ist ungewöhnlich (und natürlich ein Problem das für die betreffenden Tools auf bugzilla gehört).

 *Quote:*   

> Und wenn man nach der Anleitung trickyfetch ausführt, dann hat man ja die Files für eine Neuinstallation auf der Platte, aber nicht unbedingt die, die zum laufenden System gehören.

 

trickyfetch sollte man natürlich nach dem Updaten ausführen, nicht vorher. Und nach dem Updaten sollte das installierte System mit dem übereinstimmen, was emerge --with-bdeps y -De world liefert - sonst hast Du sowieso etwas "falsch" gemacht. Sicherheitshalber kannst Du ja mit "world test" (das "world" script gibt es ebenfalls auf obiger Seite) vergleichen, ob dem tatsächlich so ist: Hin und wieder findet man da noch Pakete installiert, die von nichts mehr benötigt werden. Die sollten dann am Besten gleich von der Platte fliegen - das sind nämlich die, die auch emerge --distclean liefern würde (wobei Letzteres manche der Pakete "übersehen" hat, z.B. ältere Slots; ich weiß nicht, ob dieser Bug inzwischen behoben wurde). Natürlich muss man bei Löschen die selbe Vorsicht walten lassen, wie bie emerge --distclean, also insbesondere ggf. ein revdep-rebuild vorher aufrufen, falls ein vorher compiliertes Paket noch gegen die (aus dem ebuild schon entfernte) Abhängigkeit linkt.

Edit: Eigentlich ist es egal, ob man trickyfetch vor oder nach dem update ausführt - die Pakete, die es holt, sind die selben. Nur - insofern hast Du Recht - sollte man sich darüber im Klaren sein, dass man danach nur die Sourcen für das Update hat und nicht die für das laufende System - was ja normalerweise sinnvoll ist. Nur wenn man das Update dann nachschiebt und es macht Ärger und man will wieder "Downgraden", hat man die Sourcen u.U. natürlich zu früh gelöscht. Aber man kann die alten Sourcen ja noch bis zum Update in $DISTFILES/.obsolete stehen lassen und erst hinterher löschen.

Noch'n Edit: Natürlich kann man mit trickyfetch alternativ (oder zusätzlich) die Sourcen vom laufenden System behalten: Man muss dann halt ein 

```
world installed | sed s/^/=/ | xargs emerge -f --nodeps
```

 statt des (bzw. zusätzlich zum) 

```
emerge --with-bdeps y -feD world
```

 ausführen.Last edited by mv on Sun Feb 03, 2008 1:40 pm; edited 1 time in total

----------

## Klaus Meier

Hatte mal ein Problem mit nasm, welches emerge -e world, was ich immer nach der Grundinstallation mache, um alles mit dem aktuellen gcc zu übersetzen, in der Version 2.0 installieren wollte, emerge -uDN world blieb aber bei der 0.irgendwas. Und mit der Version 2.0 gab es massive Probleme.

Und das hat mich dann etwas genervt, bis ich das rausgefunden hatte.

----------

## Klaus Meier

 *mv wrote:*   

> Edit: Eigentlich ist es egal, ob man trickyfetch vor oder nach dem update ausführt - die Pakete, die es holt, sind die selben. Nur - insofern hast Du Recht - sollte man sich darüber im Klaren sein, dass man danach nur die Sourcen für das Update hat und nicht die für das laufende System - was ja normalerweise sinnvoll ist. Nur wenn man das Update dann nachschiebt und es macht Ärger und man will wieder "Downgraden", hat man die Sourcen u.U. natürlich zu früh gelöscht. Aber man kann die alten Sourcen ja noch bis zum Update in $DISTFILES/.obsolete stehen lassen und erst hinterher löschen.

 

Es ging mir dabei speziell um die bdeps. Wenn ich normal update halt mit bdeps n und dann ein emerge -ef mache, mit bdeps y, dann sind Sources und installierte Anwendungen inkonsistent. Habe jetzt in der make.conf bdeps auf y gesetzt und damit ist dann doch alles in Ordnung. Man spart sich dann sogar etwas Tipperei.

----------

## mv

 *Klaus Meier wrote:*   

> Hatte mal ein Problem mit nasm [...] Und mit der Version 2.0 gab es massive Probleme.

 

Die "saubere" Lösung wäre natürlich die Maskierung der neuen Version und nicht, darauf zu hoffen, dass die neue Version "zufälligerweise" nicht geupdated wird, nur weil sie keine direkte Dependency von einem Deiner Pakete im world-File ist. Aber natürlich muss man erst mal darauf kommen, dass das nasm-Update die Ursache dafür ist. Das sind halt die Nachteile von ~ARCH (nasm-2 ist immer noch ~x86 - vermutlich wohl, weil immer noch nicht alle Pakete dafür angepasst sind).

----------

