# [distcc] Optimisation réseau ?

## Ulrar

Bonjour,

Mon PC au boulot est une antiquité (enfin, tout est relatif, mais c'est quand même ultra lent).

Il m'as fallu par exemple plus de 24h pour compiler libreoffice ..

Bref, j'ai un serveur, loin d'être une bête de course mais il compile quand même super bien.

Dessus, j'ai mis distcc et un coup de crossdev pour l'archi du PC au bureau (i686).

Bref, j'ai tout configuré tout bien, et quand je lance un emerge, ça envoie bien les fichier a la compilation sur le serveur.

Seulement, l'upload de la boite est assez classique (on a pas la fibre), et ça prend 20 bonnes secondes par fichier.

Autant dire que je n'ai pas de gain de vitesse, voir même de la perte (certes, au moins ça fait pas rammer le reste des programmes, mais quand même ..).

Bref, je me demande comment ça fonctionne.

Pour un temps d'upload aussi monstrueux par fichier, il doit uploader une bonne grosse partie des sources a chaque fois non ?

Genre pour compiler un seul .c il doit envoyer avec tout les .h, lib et compagnie dont il dépend je suppose ?

Du coup pas étonnant que ce soit si lent.

N'y a il pas un moyen de coller tout ça en cache ? Genre envoyer les sources une fois pour toute, et ensuite demander simplement la compilation d'un fichier sans avoir a les réenvoyer ?

(Parce que bon, à termes, j'aurai aimé aussi ajouté d'autres PC/serveur pour la compilation, j'ai l'air de rien une bonne puissance de calcule dispo over the internet, simplement, je peux pas me permettre d'uploader toutes les sources pour chaque fichier ..)

Ca n'as pas de rapport direct avec Gentoo mais ça rentre quand même un peu dans portage, je pense, non ?

(Et puis c'est quand même ici que j'ai le plus de chance de tomber sur des utilisateurs de distcc  :Smile:  )

----------

## xaviermiller

Salut,

En effet, pour compiler à distance, distcc envoie tous les fichiers nécessaires. Je ne sais pas s'il a une notion de cache, je pense qu'il s'occupe juste de rediriger les compilations.

Une autre alternative est de générer des paquets binaires sur une autre machine dans un chroot (emerge -k), puis de les récupérer et les installer (emerge -K)

----------

## Ulrar

Niveau optimisation de la conso réseau, c'est pas top comme système ça. C'est dommage !

Certes, je peux toujours générer des paquet mais, si je ne me trompe, ça implique de conserver un chroot "identique" a ma machine locale, sur le serveur.

Là je perd en disque dur, quand même, il est pas monstrueux sur le serveur ..

Et puis, j'avais dans l'idée, si ça avait fonctionner, de me servir de distcc pour d'autre compilations aussi.

Bref, si il n'est pas possible de mettre en cache les sources sur le serveur, je ne pourrait malheureusement pas utiliser distcc  :Sad: 

----------

## k-root

 *Ulrar wrote:*   

> Bref, j'ai tout configuré tout bien, et quand je lance un emerge, ça envoie bien les fichier a la compilation sur le serveur.
> 
> Seulement, l'upload de la boite est assez classique (on a pas la fibre), et ça prend 20 bonnes secondes par fichier.
> 
> Autant dire que je n'ai pas de gain de vitesse, voir même de la perte (certes, au moins ça fait pas rammer le reste des programmes, mais quand même ..).
> ...

 

si cela prend pas plus de 40 seconde de compiler ce fichier en local , pas la peine de l'envoyer sur ton cluster .

l'analyse est differente si tu as plusieur node distcc .. enfin l'analyse se complique.

 *Quote:*   

> 
> 
> Localhost has to do all of the preprocessing—a deliberate design choice that means you don't need to ensure that you have the same set of libraries and header files on each machine—and also all of the linking, which is often hugely processor-intensive on a large compile. There is also a certain small amount of processing overhead in managing shipping the files around the network to the other compilers. 

 

http://www.linuxjournal.com/article/9814

c'etait avant 2007 donc je n'avais pas lu cet article, mais j'etais arriver au meme conclusion ,et au meme screenshoot de distccmon-gui .. on, remarque que tous les nodes sont occupé, avec emerge + ebuild ce n'est pas le cas tout le temps .

la meilleure conf que j'avais trouvé avec comme setup 5 node et 1 client ( switch 1000 Mbit et des e5xxx intel en configuration bureautique standard) c'etait avec un make -j8 et en excluant le client du cluster (enfin , en excluant le fqdn du client de son fichier /etc/distcc/hosts ).. mais meme comme ca je me suis retrouver avec le client bloqué sur des e/s entré sortie disque et des nodes ildes car le client ne ditribue plus de taches..  avec 1 node (e5xxx) et un vieux celeron@1ghz (fsb 100mhz) , le temps   mesuré avec genlop apres un emerge etait minorer en fonction des packages de +5% a -40%.

distcc + emerge + internet @512k  ..  ca me semble pas viable.

un laptop puissant + livecd .. et tu te retrouve avec ton serveur sur le meme reseau que ta machine de bureau.

sinon ..

http://dev.gentoo.org/~vapier/CROSS-COMPILE-HOWTO

----------

## brubru

Pour être précis, un seul fichier est envoyé au serveur distcc: le source c avec tous les headers (.h) concaténés dedans, (le résultat du préprocesseur en fait), le serveur reçoit ce fichier, le compile, récupère le code objet (.o) et le renvoit au client, qui va tout rassembler et faire l'éditions de liens (création des lib, exe)

Donc si tu as deux sources qui utilisent le même headers, tu envois deux fois le contenu du header sur le réseau. Et l'inclusion des headers est récursive...

distcc a aussi un mode pour gérer le préprocesseur coté serveur (Pump Mode voir page man), jamais essayé.

----------

