Compilation distribuée avec distcc / dmucs

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
4
sept.
2006
Technologie
Imaginez un monde où les compilations seraient partagées entre tous les ordinateurs et permettraient d'optimiser la durée de ces dites compilations pour être minimales.

C'est ce que propose Distcc qui permet de compiler des sources sur plusieurs machines. Cependant distcc nécessite de déclarer l'ensemble des serveurs pouvant accueillir la compilation, ce qui est lourd pour une architecture réseau mouvante...

DMUCS apporte une réponse à ce problème en proposant un serveur central de référencement pour distcc. Je vais donc vous présenter distcc, puis crossdev et enfin DMUCS.

Distcc
Distcc est un programme pour réaliser des compilations distribuées de code en C, C++, Objective C ou Objective C++, sur plusieurs machines au travers d'un réseau. Distcc doit en principe générer le même résultat qu'une compilation locale, il est simple à installer et sa configuration n'est pas très compliquée. Ce système permet normalement de réaliser des compilations plus rapidement.

Comment cela fonctionne t-il ? eh bien, relativement simplement :
  • Vous téléchargez distcc.
  • Vous le compilez, l'installez via l'incontournable "triptyque" ./configure,make,make install
  • Pour les serveurs de compilations (ceux qui vont donc effectuer les compilations) lancez distccd --daemon (utilisez --allow adressIpClient1 adressIpClient2 ... si vous souhaitez n'autoriser que les machines listées).
  • Pour les machines qui vont lancer des compilations il faut ici lancer la commande
    distcc-config --set-hosts adresseIpSrv1 adresseIpSrv2 etc.
  • Ensuite il faut compléter quelques variables d'environnement:
    • DISTCC_LOG="/var/log/distcc" (c'est un exemple)
    • DCCC_PATH="/usr/lib/distcc/bin"
    • DISTCC_VERBOSE="0"
    • DISTCC_DIR="/var/tmp/distcc" (c'est un exemple)

    pour créer ces variables vous pouvez faire export DCCC_PATH="/usr/lib/distcc/bin". Ou les placer comme ci dessus dans un script ou dans les fichiers d'environnement.
  • Ensuite il suffit de lancer une compilation (je rappelle que les clients peuvent aussi faire office de serveur) et de vérifier que tout se passe bien avec distccmon-text 5


Crossdev
Crossdev permet de compiler des application 64 bits, powerpc, sparc ou autres sur une machine x86. L'inverse est aussi vrai pour les autres architectures. Crossdev nécessite que gcc soit déjà installé.
Pour l'installation de crossdev le principe est habituel. On télécharge le tar.gz puis on le décompresse, ./configure && make && make install. Une fois installé, on exécute crossdev -t x86_64-pc-linux-gnu-gcc pour activer par exemple le support 64 bits à la compilation.

DMUCS
DMUCS est un système qui permet à un groupe d'utilisateurs de partager ses compilations avec les autres de façon dynamique. Concernant ce dernier, je n'ai pas réussi à le compiler (il semblerait qu'il y ait quelques erreurs dans les scripts d'installation), cependant c'est un projet prometteur.

Comment installer DMUCS?
  • Téléchargez les sources...
  • ./configure, puis make CPPFLAGS=-DSERVER_MACH_NAME=\\\”\\\”,
    et enfin, make install
  • Créez ensuite le fichier /usr/local/share/dmucs/hosts-info contenant quelque chose comme ceci:

    #machine number-of-cpus power-index
    linux-comp-1 4 10
    solaris-comp-1 2 5
    solaris-comp-2 2 5
    old-linux-comp-1 1 4
    old-solaris-comp-3 1 2
    169.144.80.25 1 2

  • lancez dmucs sur votre serveur.
  • sur les clients, lancez loadavg puis distccd
  • sur le serveur l'exécutable dmucs doit vous montrer les clients qui se connectent.
  • Ensuite, il ne reste plus qu'à lancer la compilation.

DMUCS n'est pas encore au point, mais c'est un projet à surveiller.

P.S. : comme vous pourrez le constater la documentation Gentoo est très au point concernant ce système et vous pouvez trouver plus d'information sur les wikis français et anglais

Aller plus loin

  • # DMUCS, pourquoi faire?

    Posté par  (site web personnel) . Évalué à 4.

    Il existe des patchs pour distcc pour utiliser zeroconf, c'est rigolo cette fascination pour le serveur centrale sous Linux.
    Avahi, le maitre du zeroconf sous Linux propose même des lib de compatibilité pour les projets developpé avec howl ou autre implementation zeroconf. Donc, plutot que d'utiliser un serveur centrale qui compile pas, un bon zeroconf me semble plus sain.

    • [^] # Re: DMUCS, pourquoi faire?

      Posté par  . Évalué à 5.

      Pour utiliser zeroconf il faut avoir confiance dans toutes les machines de ton réseau.

  • # En fait DMUCS...

    Posté par  (site web personnel) . Évalué à 10.

    ...c'est une sorte de Gentoo@home:
    "Aidons les gentooiste à ne pas passer 7 mois à mettre à jour OO.org!" :o)

    • [^] # Re: En fait DMUCS...

      Posté par  . Évalué à -10.

      C'est sympa de ta part, mais

      $ genlop -t openoffice
      Sat Jul 8 01:33:21 2006 >>> app-office/openoffice-2.0.3
      merge time: 3 hours, 31 minutes and 57 seconds.

      sans distcc, ou toute autre méthode de compilation distribuée

    • [^] # Re: En fait DMUCS...

      Posté par  . Évalué à 1.

      Quand tu as le temps pour Gentoo, tu as aussi le temps de devenir le MOTKU de troff, ça compile 300x plus vite qu'OOo pour le meme rendu.

  • # distcc pas toujours avantageux

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Distcc c'est bien, mais n'imaginez pas recycler vos 15 vieilles bécanes pour faire de la compilation distribuée. J'ai fait diverses experiences, et en fait, la machine principale (plus puissante que mes autres veilles babasses) passe plus son temps à attendre le résultat des autres bécanes qu'à vraiment compiler (surtout dans le cas de sources avec makefile recursifs comme c'est le cas dans Mozilla).

    Utiliser un truc comme distcc n'est avantageux que pour un ensemble de machines esclaves de puissances équivalentes (ou plus puissantes) que la machine maîtresse.

    • [^] # Re: distcc pas toujours avantageux

      Posté par  . Évalué à 3.

      cela dépend de comment tu règles ton niveau de parallélisme avec le -j pour make.
      La latence réseau impact beaucoup plus en terme d'efficacité

      • [^] # Re: distcc pas toujours avantageux

        Posté par  . Évalué à 2.

        Je confirme qu'avec des bécanes moins puissantes (du quart) que la principale, quelque soit le débit du réseau, ca sert pas à grand chose, ca ralentit même le processus... Ou alors peut-être en mettant j = 0.5 ;-)
        C'est pour ca que je ne m'étais pas interessé à ce genre de solutions pour compiler KDE pour mes trois machines sous Gentoo...

    • [^] # Re: distcc pas toujours avantageux

      Posté par  . Évalué à 1.

      Dans un endroit ou tout le monde fait du développement, et créer des groupes de 3 machines utilisés pour qu'elles compilent ensemble...
      C'est un peu plus rapide quand meme !

      Par contre pour des fermes de compilations, ce n'est pas trop le truc ...(Peut-etre plus avec ccache ? pourquoi l'article n'en parle pas ... :-( )

      • [^] # Re: distcc pas toujours avantageux

        Posté par  . Évalué à 1.

        c'est vrai que cette article n'est pas complé mais il présenté surtout comment faire de la compilation distribué et ccache étant plus de l'optimisation locale je pensé que ce n'été pas tout à fait le sujet.

        Mais je l'utilise!!!

        P.S.: distcc+crossdev marche trés bien en compile entre mon i686 et mon x86_64 c'est même étonnant.

    • [^] # Re: distcc pas toujours avantageux

      Posté par  . Évalué à 2.

      Il me semble que sur la page du projet de distcc le gars conseille d'une part de mettre un flag -j n avec n legerement superieur au nombre de CPU dont tu disposes (machine locale + distantes) et qu'a plus de 3 machines la courbe d'efficacité redescend.
      Genre, j'ai un monopro, en distant il y a un bipro et un autre monopro, je vais compiler avec du make -j 5 ou 6.

      Et le frontend graphique avec les petites courbes qui avancent, ca c'est vraiment un truc sympa.

      Le probleme, c'est effectivement la latence reseau. On peut tester avec netPipe pour mesurer ces latences.

      • [^] # Re: distcc pas toujours avantageux

        Posté par  (site web personnel) . Évalué à 2.

        En il y a un gros problème selon la manière dont le makefile est écrit. Si il utilise des makefiles recursif, il y a très peu de parralélisme visible par make.

        Si tout est "a plat", logiquement tous les *.c sont compilables séparement et donc en parrallèle. Reste ensuite le link.

        "La première sécurité est la liberté"

  • # autre alternative: icecream

    Posté par  . Évalué à 3.

    il existe une autre alternative à distcc (qui est d'ailleurs basé dessus):
    icecream (http://en.opensuse.org/Icecream)

    • [^] # Re: autre alternative: icecream

      Posté par  (site web personnel) . Évalué à 2.

      icescream a ete developpe par un gourou KDE (Stephan Kulow) et marche super bien. Pas une seule reuninon KDE ou les developpeurs ne commencent pas par deployer du icescream partout. Je suis surpris de ne pas le voir cite.

      La page web: http://en.opensuse.org/Icecream
      (l'url du commentaire plus haut a une parenthese en trop)

      Petite copie de la partie interessante :
      ============================================
      I use distcc, why should I change?

      If you're sitting alone home and use your partner's computer to speed up your compilation and both these machines run the same Linux version, you're fine with distcc (as 95% of the users reading this chapter will be, I'm sure). But there are several situations, where distcc isn't the best choice:

      * you're changing compiler versions often and still want to speed up your compilation (see the ICECC_VERSION support)
      * you got some neat PPC laptop and want to use your wife's computer that only runs intel (see the cross compiler section)
      * you don't know what machines will be on-line at compile time.
      * most important: you're sitting in a office with several co-workers that do not like if you overload their workstations when they play doom (distcc doesn't have a scheduler)
      * you like nice compile monitors :)
      ============================================

  • # Question de béotien flémard : quid des sources ?

    Posté par  (site web personnel) . Évalué à 2.

    Excusez la question probablement ridicule, mais l'article ne présente pas un point qui me semble important dans distcc : comment les machines s'échangent les sources ?

    Si quelqu'un a la réponse (et je pense que vous êtes nombreux vu les retours d'expérience exprimés).

    • [^] # Re: Question de béotien flémard : quid des sources ?

      Posté par  . Évalué à 2.

      par réseau... autremment dit au travers du protocole tcp/ip de façon général.
      Si ça ne répond pas à ta question merci de préciser.

      • [^] # Re: Question de béotien flémard : quid des sources ?

        Posté par  (site web personnel) . Évalué à 2.

        par réseau... autremment dit au travers du protocole tcp/ip de façon général.
        Si ça ne répond pas à ta question merci de préciser.


        Effectivement, j'aurais besoin d'une précision.

        Le transfert des sources (et des résultats de compilation) est-il fait via un protocole spécifique (fait main) ?

        Pourquoi ma question ? Parce qu'aujourd'hui il y a plusieurs solutions pour synchroniser des arborescences (NFS, rsync...). Je voulais donc savoir si distcc utilisait ce genre de techno ou si il refaisait lui-même le boulot.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.