| 1 |
Am Freitag, 1. Oktober 2004 11:00 schrieb Thorsten Dikmann: |
| 2 |
> Hmm also spontan fällt mir nur distcc dafür ein, aber dann ist |
| 3 |
> wahrscheinlich deine ADSL Leitung im Weg ... glaube ich zumindest, |
| 4 |
> selbst nie benutzt. |
| 5 |
|
| 6 |
DistCC ist IMHO nur dann sinnvoll, wenn alle beteiligten Rechner |
| 7 |
ziemlich schnell sind. Und ich meine nicht nur CPU. |
| 8 |
Wir hatten mal ein Setup mit einem Dual-P4 (iirc 3 GHz) mit |
| 9 |
wasweissichwieviel RAM und mein Laptop mit Centrino-1300 MHz. Also |
| 10 |
alles einigermassen neu. Und da ging es verdammt schnell mit DistCC. |
| 11 |
|
| 12 |
Andererseits habe ich auch schon einen alten Rechner mit eingebunden mit |
| 13 |
der Auffassung "naja, langsam aber besser als nichts" und das |
| 14 |
kompilieren hat doppelt so lange gedauert, weil immer wieder auf den |
| 15 |
altn gewartet werden musste. Selbiges übrigens wenn der ältere die |
| 16 |
Aufträge startet. Ein K6-350 MHz ist *zu langsam* das von meinem |
| 17 |
besagten Laptop kompilierte Material in echtzeit bereitzustellen und |
| 18 |
neues zu besorgen. Das merke ich daran, dass mein Laptop nur immer mal |
| 19 |
wieder kurz kompiliert und dann nichts mehr zu tun hat. Auch wenn der |
| 20 |
host-Rechner garnichts zu kompilieren hat (localhost nicht in den |
| 21 |
distcc-hosts drin). |
| 22 |
|
| 23 |
Ergo: Wenn du distcc mit sehr unterschiedlich schnellen Rechnern nimmst |
| 24 |
und dann noch eine nlangsame Leitung hast, kannst du vermutlich grade |
| 25 |
lokal auf dem langsamen Rechner kompilieren. |
| 26 |
|
| 27 |
|
| 28 |
> Mal eine generelle Frage: Es muss doch möglich sein, dass ich auf |
| 29 |
> einem Athlon System auch hochoptimierte Programme für den Pentium 4 |
| 30 |
> kompiliere, indem ich die entsprechenden cflags setze ... ich mein |
| 31 |
> das sind ja letztlich nur anweisungen wie der compiler das übersetzen |
| 32 |
> soll, hat ja mit dem Prozessor der aktuell in der Maschine rennt |
| 33 |
> nichts zu tun.... |
| 34 |
|
| 35 |
Nein. |
| 36 |
Also, ja, generell schon. :) |
| 37 |
Aber mit den Bibliotheken hast du halt das Problem. Der Gcc kann das |
| 38 |
schon alles, das war ja die Idee mit dem chroot. Aber dein System kann |
| 39 |
die Bibliotheken nicht nutzen, die für den anderen Prozessor gemacht |
| 40 |
wurden. Gleichzeitig musst du diese anderen Bibliotheken aber im system |
| 41 |
haben, damit der Compiler das in die Binaries für das andere System |
| 42 |
einbauen kann. |
| 43 |
|
| 44 |
Wenn man kein extra-Platz für ein identisches System hergeben will, |
| 45 |
könnte ich mir auch vorstellen, dass sowas funktioniert: |
| 46 |
* VPN aufbauen und dann mit NFS das root-FS des anderen mounten. |
| 47 |
* Folgende Verzeichnisse mittels mount -o bind von lokal drübermounten: |
| 48 |
- /usr/portage[/distfiles] |
| 49 |
- /var/tmp/portage |
| 50 |
* chroot in den mountpoint des anderen Rechners |
| 51 |
|
| 52 |
Lokal habe ich das alles schon gemacht, normal kommen so nur ganz wenige |
| 53 |
Zugriffe über das NFS zu stande, ich denke das könnte auch über ein VPN |
| 54 |
klappen. Da NFS UDP ist, wird's mit SSH-Tunnel halt schwierig. |
| 55 |
|
| 56 |
cu, Bernd |
| 57 |
|
| 58 |
-- |
| 59 |
The hardness of the butter is proportional to the softness of the bread. |
Archives