Prova di distcc con un athlon xp e un athlon 64

[flapane]

Avevo necessità di compilare sull'athlon xp di là l'ultima versione di wine per via di un problema con photoshop, e visto che per gutsy non è mai stata pacchettizzata, l'ho dovuto fare a mano. Visto che ieri ho dimenticato di installare le librerie di sviluppo alsa e di conseguenza wine non sfruttava alsa, non avevo voglia di aspettare un'altra ora e passa per ricompilarlo da capo (athlon xp mobile@2ghz, 512mb ram).
Ho cercato in giro qualcosa per la cross compilazione, e visto che cygwin mi sembrava un gran casino (o almeno capire cosa installare senza scaricare centinaia di mb di roba), ho preferito far partire una live di un vecchio kubuntu sul mio pc (x2 3800+@2.7ghz e 2gb di ram), configurando distcc come host seguendo una qualsiasi guida sul web.
Purtroppo, per un problema di cui mi sono accorto solo alla fine, la live riconosceva solo uno dei due core, amen.
Sfruttando quindi un solo core del mio a64 e il core dell'athlon xp, il risultato è che si è scesi da circa 1:10 h a 25 minuti, non male e comodo se si compila spesso su computer lenti (non di certo il mio caso).
Dall'athlon xp partivano diverse centinaia di mb verso il mio pc.

Questo quello che si vedeva sul server (athlon xp):


E questo sul mio athlon 64 con la live:



è tutto
In tutto questo credo ci sia stata la limitazione della rete che è a 10mbit e non a 100mbit, perchè vedevo il compilatore occupare la cpu a sprazzi sull'a64.

[mccarver]

Originariamente inviato da flapane

In tutto questo credo ci sia stata la limitazione della rete che è a 10mbit e non a 100mbit, perchè vedevo il compilatore occupare la cpu a sprazzi sull'a64.

Credo che il grosso limite sia la tecnica che distcc usa per distribuire la compilazione: l'impressione è che invii un sorgente e attenda la compilazione remota, solo dopo ne invia un altro.
In questo modo le cpu non locali sono sempre impegnate 'a sprazzi' dal momento che 1) è raro incrociare file corposi da compilare (tutt'altro, la maggior parte dei sorgenti sono pochissimi kilobytes) e 2) i tempi morti non dipendono dalle dimensioni dei sorgenti ma sono più o meno costanti. Con questo sistema i pc in rete passano più tempo a ricevere e a trasmettere files che non a compilarli..

Ciononostante rimane un'ottima soluzione per chi ha una manciata di pc in rete (o anche solo 2), magari accompagnandola a ccache.

[flapane]

eh, dovevo vedere anche la questione ccache, solo che mi è letteralmente uscito di mente .
In effetti se si tratta di tanti, tanti file da pochi kb, c'è il rischio che si perda troppo tempo a passare file ai vari computer in rete, io inizialmente mi aspettavo un uso della cpu fisso al 100%...

1:10h-->1 athlon xp

1:10h-->se fossero due athlon xp uguali-->35min

1:10h-->athlon xp+athlon 64-->25min (su 1:10h, è come se l'athlon xp compilasse 25min e l'athlon 64 si prendesse carico dei teorici rimanenti 45min svolgendo il compito in 25min, con una efficienza quasi del 100% dell'a64 rispetto ad un vecchio athlon xp dovuta ad architettura, ram e frequenza).

p.s cos'è l'avatar, donkey cong del c64? :P

[mccarver]

Originariamente inviato da flapane

1:10h-->athlon xp+athlon 64-->25min (su 1:10h, è come se l'athlon xp compilasse 25min e l'athlon 64 si prendesse carico dei teorici rimanenti 45min svolgendo il compito in 25min, con una efficienza quasi del 100% dell'a64 rispetto ad un vecchio athlon xp dovuta ad architettura, ram e frequenza).

p.s cos'è l'avatar, donkey cong del c64? :P

Complessivamente possiamo dire che distcc rockeggia
Sarebbe però necessario fare compilazione con il solo Athlon 64, per vedere quanto quest'ultimo 'soffre' a trovarsi al di là del cavo di rete con distcc..

Per l'avatar hai azzeccato gli 8 bit! Trattasi di Jumpman.

[Gimli[2BV!2B]]

Mi è sfuggito un dettaglio del primo post, HO risposto con cose inutili...

[flapane]

uh?