# [Ccache] Vraiment utile avec un quad-core ?

## HazeC5

Salutation les gentoïstes  :Wink: 

Voilà je m'interroge, j'ai remarqué que sur ce quad-core ccache ne me fait rien gagner du tout par rapport à une re-compilation d'un paquet et d'une même version qu'une déjà compilée.

Déjà sur le prescott 3Ghz ou le P-IV 2,8Ghz le gain était vraiment minime.

Mes questions sont donc:

- Est-il nécessaire de le garder ? Ou bien je peux définitivement m'en passer ?

- Et vous, avec 1 core 2 duo ou 1 quad-core, utilisez vous ccache ?

J'ai ouverts un sondage, afin de voir quelle sera la réponse dominante  :Exclamation:   :Exclamation: 

Par avance merci bien.  :Cool: 

@ bientôt.

----------

## boozo

ccache cause souvent plus de pb de compil qu'il n'en résoud au niveau perfs - au moins d'expérience personnelle je dirais - mais après si tu es joueur tu pourras essayer la version 3.x  :Wink: 

/off : Je croyais bien avoir vu un sabotage en règle (honteux!) de geekounet en pris les doigts en train de supprimer sauvagement des posts du forums mais non... effectivement, c'est mieux avec l'option sondage   :Razz: 

Edit: /off[off] : marrant çà j'avais jamais fait attention : le fil se nomme "sondage" devient "poll" une fois logué chez moi - foutues $ d'env !  

----------

## geekounet

Oui ce n'est pas moi qu'ai supprimé le topic précédent.  :Wink:  D'ailleurs ça aurait été mieux de l'éditer plutôt que de le supprimer/recréer, enfin bref.

Avec ou sans bon processeur, ccache c'est juste non pour moi, je préfère que ça prenne un peu plus de temps à compiler tout seul dans son coin, plutôt que de perdre du temps à régler les nombreux problèmes que ça cause.

----------

## kwenspc

sans parler des accès disques que ça génère en plus.

----------

## Ezka

M'en passe trés bien, j'ai pas trop essayé remarque, mais ça à l'air casse gueule ...

----------

## gglaboussole

avec un i7 920 je compile openoffice en 42 min sans ccache, 12 min avec... donc oui c'est utile...

Il ne m'est arrivé qu'une seule fois un problème de compilation où j'ai du désactiver ccache pour passer le paquet (le message d'erreur était compréhensible, il se plaignait de ne pas trouver un truc dans /ccache/bla bla bla...)

----------

## Tom_

Perso, je n'ai quasiment jamais eu de problème avec ccache.   :Rolling Eyes: 

----------

## Ezka

Je dis ptêtre une connerie mais avec ccache tu ne compiles plus totalement ton paquet si ? il garde les sources pour ne recompiler que ce qui a changer en gros ? Principe que je comprend bien mais il faudrait voir à ne pas confondre "je compile openoffice en 42mn sans ccache" donc c'est ton temps de compilation de TOUT oo et "12 mn avec" qui correspond à la re-compilation d'environ un tiers.

Bref oui ça te fait gagner du temps sur un emerge, mais sur la compil tu ne gagnes que ce que tu ne recompile pas =D (ce qui est pas si mal quand même). Maintenant je ne sais pas vous mais les 3/4 de mes maj se font sur des petits paquets et je ne suis pas certains que sur autre chose que des gros binaire type ooo ou thunderbird (une plait en ce moment celui-là) le gain soit si significatif.

----------

## gglaboussole

tu as raison ccache n'apporte un plus qu'en cas de recompilation(même si c'est pas les sources qui sont conservées mais des portions de binaire plutôt) la toute première est aussi rapide avec ou sans, mais si j'ai conservé cette feature c'est que j'y trouve un intérêt notamment lorsque qu'une mise à jour de librairie te pète ton binaire...ou encore lorsqu'il y a juste un changement de USE décidé par les dev sans changement de version...j'ai pris l'ex d'openoffice mais des "gros" binaire il y en a d'autres... glibc, xulrunner,gcc,qtlibs...etc...

Vu que je n'ai eu qu'une seule fois un problème facilement repérable et corrigible le rapport bénéfice/risque me paraît acceptable..

----------

## boozo

Je ne dis pas que je veux revoir mes positions mais des crash plus étranges que la ressource indisponible en cache j'en ai eu avec dans le passé ; ceci-dit ze zouais plus avec les optimisations et les ldflags à l'époque...

Or donc, faites péter vos $ccache -s pour voir un peu   :Wink: 

----------

## xaviermiller

Aucun souci avec ccache depuis des années, après des soucis d'instabilité, lors du passage de GCC 3 à 4 et glibc.

Depuis 2 ans au moins : stabilité maximum.

Je me demande si ccache n'aide pas certaines compilations 100% neuves telles OpenOffice ?

Compiler demande des I/O, ccache aussi. Alors, le troll de "ccache bourre le disque dur" a la dent dure selon moi  :Wink: 

```
CCACHE_DIR=/var/tmp/ccache/ ccache -s

cache directory                     /var/tmp/ccache/

cache hit                          38433

cache miss                         56669

called for link                     6109

multiple source files                 17

compile failed                      1708

preprocessor error                   782

not a C/C++ file                    2319

autoconf compile/link               9213

unsupported compiler option          171

no input file                       6097

files in cache                    113338

cache size                           1.6 Gbytes

max cache size                       2.0 Gbytes
```

----------

## gglaboussole

Bon moi pour les I/O je compile en tmpfs....alors j'peux faire un peu gratter mon dur avec ccache   :Laughing: 

```

cache directory                     /home/.ccache

cache hit                         404373

cache miss                        854387

called for link                   107633

multiple source files                124

compile failed                     23114

preprocessor error                 10492

not a C/C++ file                   47403

autoconf compile/link             149094

unsupported compiler option        41350

no input file                      70472

files in cache                    240367

cache size                           3.7 Gbytes

max cache size                       4.0 Gbytes

```

Par contre j'avoue ne jamais regarder ces stats et man ccache n'en apprend pas bcp là dessus, alors boozo, si ça te parle plus qu'à moi ...  :Wink: 

----------

## boozo

Holà ! Je ne suis pas un expert en compilateur pour faire un bench digne de ce nom (il existe des outils pour çà d'ailleurs ?) mais ces stats donnent une tendence à l'utilisation malgré tout i.e. le nombre de touches vs ceux d'échec, erreurs, etc

Bien que la taille de vos cache ne soit pas identique, elle n'est pas directement corrélé à ces valeurs pour Xavier et toi. Vous en faites une utilisation plutôt différente me semble-t-il.

Selon moi, il y a plusieurs explications possible : déjà ccache ne gère que peu de cflags donc si on joue avec on en tire pas partie. Ensuite vu les critères pris en compte pour générer les hashs de code afin qu'ils soient réutilisables :

 *Quote:*   

>     * the pre-processor output from running the compiler with -E
> 
>     * the command line options
> 
>     * the real compilers size and modification time
> ...

 

l'impact va plus se sentir sur les portions de code "génériques" et le nombre et la fréquence des touches doivent vraiment varier d'un user à l'autre il me semble ce qui doit également se ressentir en terme de perfs selon le code des applications d'une part, le contenu du world, etc.

Et puis bon vu que chez nous, tout bouge tout le temps au niveau sources (y compris pour gcc), il doit falloir vider le cache de façon adaptée par rapport aux upgrade pour en trier davantage profit ; dans la mesure où c'est à la recompilation de code à "l'identique" que cela joue uniquement   :Sad: 

Bref, je peux me tromper mais même si le gain est réel dans certains CU çà je n'en doute pas, la fenêtre d'utilisation optimale sur @world n'est pas super large à mon avis   :Sad: 

Après Xavier à peut être un peu raison aussi : mon utilisation et mes problèmes avec date de cette époque là donc je suis sans doute resté sur une mauvaise impression c'est possible - faudrait que je lui redonne une chance pour voir - m'enfin, b.g.o ramène aussi quelques problèmes avec malgré tout   :Rolling Eyes: 

A voir... si on arrive à faire des tests clairs genre sur @system histoire d'avoir un panel de souces et avec une optimisation minimale, généraliste puis en ajoutant des paramètres au compilateur,... jouable non ?

----------

## gglaboussole

Merci pour ces précisions

En ce qui concerne l'upgrade de gcc, j'ai toujours vidé mon cache en suivant, me doutant bien qu'à version différente risque de codes générés différents...

Pour le reste je m'en occupe pas... je l'avais simplement déplacé sur mon vaste /home et augmenté sa taille car j'avais remarqué qu'en le laissant sur /, j'avais un pourcentage de fragmentation phénoménal lors des fsck automatiques au boot (+de 20%)...

ça me génait juste "visuellement".. en tous cas pour la partoche système... le /home m'en fou un peu

----------

## HazeC5

Salut.   :Cool: 

Merci pour vos réponses. Je constate que le sondage est assez mitigé , 28% de "sans réponse" et 28% de "oui".

La majorité étant largement le non, ce qui m'étonne quand même , aux vues des réponses postées dans ce topic !

Pour ma part je compile aussi en TMPFS donc les accès disque c'est pas trop la priorité.

Je ne connaissais pas non plus la méthode pour voir les stats de ccache.

Du coup après l'avoir supprimé pendant une dizaine de jour, je vais le remettre et voir un peu ce que cela donne, et sur le disque SATA cette fois-ci !

D'ailleurs je viens de constater que quelques heures après avoir posté ce message j'ai eu à recompiler openoffice aussi , et avec ccache il a mis 43 mn contre 1h 18 pour la première compile de cette même version , la 3.2.0.

Donc c'est qu'il n'est pas si inutile que ça, même avec un quad-core.

Merci @ vous, bonne fin de soirée et @ bientôt !   :Cool:   :Wink: 

----------

