# [OT] Distcc: ne vale la pena?

## canduc17

Ciao a tutti.

Seguendo le 2 guidehttp://www.gentoo.org/doc/it/distcc.xml

http://www.gentoo.org/doc/it/cross-compiling-distcc.xmled il topichttps://forums.gentoo.org/viewtopic-t-711941-highlight-distcc.htmlsono riuscito a configurare distcc con cross-compilazione.

A vedere distccom-gui tutto sembra funzionare bene e col mio desktop (Intel Core 2 Duo, arch i686) aiuto nella compilazione il mio portatile (Intel Core 2 Duo, arch x86_64) nella rete locale di casa mia.

Per curiosità ho fatto un po' di test, compilando gli stessi pacchetti con e senza distcc e questi sono i risultati:

emerge media-video/vlc

senza distcc --> 15 min 05 sec

con distcc ----> 20 min 10 sec

emerge media-gfx/inkscape

senza distcc --> 15 min 02 sec

con distcc ----> 11 min 16 sec

emerge x11-libs/qt

senza distcc --> 13 min 17 sec

con distcc ----> 12 min 06 sec

emerge net-libs/xulrunner

senza distcc --> 28 min 38 sec

con distcc ----> 26 min 37 sec

emerge $(qlist -IC python)

senza distcc --> 33 min 54 sec

con distcc ----> 34 min 14 sec

Per ottenere questi risultati ho eseguito comandi del tipo:

```
candell ~ # echo "#vlc SENZA distcc" >> tempi_distcc && date >> tempi_distcc && emerge vlc && date >> tempi_distcc

# riconfiguro opportunamente /etc/make.conf e poi...

candell ~ # echo #vlc CON distcc" >> tempi_distcc && date >> tempi_distcc && emerge vlc && date >> tempi_distcc
```

e poi facevo la differenza dei due tempi, all'inizio ed alla fine dell'installazione.

Come potete vedere i risultati non sono proprio entusiasmanti: qualche pacchetto addirittura viene installato in meno tempo senza distcc.

Okkei che non tutti i pacchetti sono ottimizzati per la compilazione distribuita e che questo è un campione un po' piccolo per fare delle statistiche, ma volevo comunque sapere le vostre opinioni/esperienze/suggerimenti...

La domanda insomma mi sorge spontanea: vale davvero la pena usare distcc? A voi la parola...

----------

## cloc3

stai utilizzando due computer identici, tranne che per l'architettura?

in genere, distcc è consigliabile nei casi di asimmetria, per trasportare sulla macchina lenta le prestazioni di quella superiore.

i ritardi di trasmissione sulla rete, altrimenti, hanno un effetto importante.

in ogni caso, quando utilizzavo distcc (adesso, in genere, preferisco limitarmi all'uso della compilazione da remoto), qualche vantaggio lo vedevo.

hai verificato che distcc utilizzi entrambe le macchine, e non solo una di esse?

per misurare i tempi, perchè non usi genlop?

```

s939 ~ # genlop -t mozilla-firefox|tail -n 7

     Thu Aug 13 16:26:57 2009 >>> www-client/mozilla-firefox-3.5.2-r1

       merge time: 1 minute and 38 seconds.

     Mon Aug 31 14:15:21 2009 >>> www-client/mozilla-firefox-3.5.2-r2

       merge time: 4 minutes and 22 seconds.

```

----------

## canduc17

 *cloc3 wrote:*   

> stai utilizzando due computer identici, tranne che per l'architettura? 

 Sì, però il processore del Desktop arriva a 2,4GHz, mentre quello del portatile a 2GHz.

 *cloc3 wrote:*   

> hai verificato che distcc utilizzi entrambe le macchine, e non solo una di esse? 

 Come ho detto sopra, distccom-gui mi fà vedere che entrambe le macchine compilano, anche se c'è una gran disparità: il Desktop lavora molto meno rispetto al portatile (che è la machina che lancia emerge). E poi dipende dai pacchetti: inkscape e le qt erano i pacchetti meglio parallelizzati, tutti i pacchetti python sono stati invece una ciofeca, forse perchè molti di questi sono piccoli.

 *cloc3 wrote:*   

> distcc è consigliabile nei casi di asimmetria, per trasportare sulla macchina lenta le prestazioni di quella superiore

 Ok, ma anche se le macchine sono identiche, dovrebbero spartirsi il lavoro ed il tempo di installazione risultante dovrebbe essere inferiore...o sbaglio?

 *cloc3 wrote:*   

> per misurare i tempi, perchè non usi genlop?
> 
> ```
> s939 ~ # genlop -t mozilla-firefox|tail -n 7
> ```
> ...

   :Embarassed:  Hem...perchè non lo conoscevo...grazie della dritta!

----------

## mrfree

Potresti fare un po' di tuning di distcc per sfruttarne al meglio le potenzialità. Per esempio nel file di configurazione degli host puoi indicare quanti job vuoi che vengano fatti girare su ogni macchina che partecipa alla compilazione, in aggiunta ti consiglio di esplorare il pump-mode introdotto nella versione 3 di distcc che sposta ulteriore carico di lavoro sulle macchine remote.

Naturalmente per una migliore riuscita della compilazione parallela dovresti combinarla con le nuove feature di portage riguardanti l'emerge parallelo (leggi il man, in particolare l'opzione --jobs) una volta configurato il tutto dai un bel: 

```
pump emerge ...
```

 io lo uso da un po' senza problemi un po' aiuta ma non ho mai fatto test approfonditi  :Wink: 

----------

## Peach

ciao io uso distcc per portare su delle embedded i pacchetti necessari e direi che e' abbastanza fondamentale.

Da quello che so io, tra architetture diverse (x86 e x86_64) occorrerebbe usare il crosscompiling oltre a distcc (c'e' la guida su gentoo.org)

Seconda cosa... stai usando un valore adeguato in MAKEOPTS? ricorda che e' il numero di cpu+1, in questo caso, il numero di tutte le cpu/core coinvolte nella compilazione

ciao

----------

## canduc17

@ mrfree:

Grazie mille, erano proprio informazioni del genere che cercavo...cose che non ci sono nelle guide ufficiali perchè un po' approfondite.

Indagherò e vi farò sapere.

@ Peach:

 *Peach wrote:*   

> occorrerebbe usare il crosscompiling oltre a distcc

 Sì, lo uso, se no non andrebbe una mazza.

 *Peach wrote:*   

> stai usando un valore adeguato in MAKEOPTS? ricorda che e' il numero di cpu+1, in questo caso, il numero di tutte le cpu/core coinvolte nella compilazione 

 Sì...ti posto la parte di make.conf relativa:

```
1 #MAKEOPTS="-j3"

2 MAKEOPTS="-j5" # per distcc

3 FEATURES="distcc"
```

Avendo dei Core 2 Duo ho 2 core per processore quindi 2+2+1 = 5 con distcc, 3 senza.

Quello che ho fatto durante i test è stato appunto commentare riga 1 quando usavo distcc, commentare righe 2 e 3 e ripristinare la 1 quando non lo usavo...

----------

## Peach

sinceramente strano... a meno che entrambe le macchine siano concorrentemente impegnate a compilare, direi che e' strano.

mi viene da pensare ad un collo di bottiglia nella rete o nel processing delle queues di compilazione.

----------

## canduc17

Ho provato i suggerimenti di mrfree: quello che ho cambiato è stato il file /etc/distcc/hosts, dove ho aggiunto il parametro cpp per il "distcc pump mode", la compressione LZO ed il limite di job massimo per macchina (che ho impostato a 6). Questo l'ho fatto sia sul server che sul client.

/etc/distcc/hosts client (portatile):

```
localhost/6,cpp,lzo 192.168.0.2/6,cpp,lzo
```

/etc/distcc/hosts server (desktop):

```
localhost/6,cpp,lzo 192.168.0.5/6,cpp,lzo
```

Inoltre ho modificato il lancio di emerge, utilizzando il comando pump e il flag -j, per lanciare più build in contemporanea (il numero dei job contemporanei non lo imposto, in modo che lo scelga lui). Quest'ultima opzione però mi pare di capire che non serva se installo un pacchetto alla volta, ma solo se "emerge" coinvelge più pacchetti.

I risultati sugli stessi pacchetti, sono i seguenti (copio pari pari quelli sopra per fare un confronto):emerge media-video/vlc

senza distcc --> 15 min 05 sec

con distcc ----> 20 min 10 sec

pump emerge -j vlc  ----> 15 min 00 sec

emerge media-gfx/inkscape

senza distcc --> 15 min 02 sec

con distcc ----> 11 min 16 sec

pump emerge -j inkscape  ----> 19 min 41 sec

emerge x11-libs/qt

senza distcc --> 13 min 17 sec

con distcc ----> 12 min 06 sec

pump emerge -j qt  ----> 13 min 35 sec

emerge net-libs/xulrunner

senza distcc --> 28 min 38 sec

con distcc ----> 26 min 37 sec

pump emerge -j qt  ----> 29 min 5 sec

emerge $(qlist -IC python)

senza distcc --> 33 min 54 sec

con distcc ----> 34 min 14 sec

pump emerge -j $(qlist -IC python)  ----> 24 min 42 sec

C'è un piccolo problema di fondo però: la compilazione distribuita non funziona più! Vengono passati job all'altra macchina (molti meno rispetto a prima del tuning, in realtà), ma vengono costantemente bloccati ed a fine compilazione ottengo messaggi tipo questo:

```
candell ~ # pump emerge -j 6 inkscape

__________Using distcc-pump from /usr/bin

__________Using 2 distcc servers in pump mode

Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) media-gfx/inkscape-0.46-r5

>>> Installing (1 of 1) media-gfx/inkscape-0.46-r5

>>> Jobs: 1 of 1 complete                           Load avg: 1.87, 3.88, 3.92

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

__________Warning: 24 pump-mode compilation(s) failed on server, but succeeded locally.

__________Distcc-pump was demoted to plain mode.  See the Distcc Discrepancy Symptoms section in the include_server(1) man page.

__________Shutting down distcc-pump include server
```

L'incremento di prestazioni che ho avuto, dove c'è stato, è stato tutto in locale...Ho guardato la pagina di man suggerita, ma non da indicazioni utili per risolvere il problema.

Qualcuno ha dei suggerimenti? mrfree, puoi postare le tue configurazioni?

----------

## Kernel78

piccolo OT

per avere i tempi di esecuzione di un comando puoi benissimo usare time

```
time emerge nomepacchetto
```

----------

## canduc17

 *Kernel78 wrote:*   

> per avere i tempi di esecuzione di un comando puoi benissimo usare time
> 
> ```
> time emerge nomepacchetto
> ```
> ...

 Ok, proverò anche quello.

Per il fatto che distcc non va più con le nuove configurazioni, invece, qualcuno ha idee?

----------

