Beschleunigung der Image-Erstellung durch Doppelkern

  • Hallo liebe Dreambox-Gemeinde!


    Ich habe mal ausprobiert, was ein Doppelkern für Vorteile beim Erstellen eines OE-Images für die Dreambox bringt.
    Ich selbst habe einen AMD Athlon X2 mit 2300 MHz. Bei OE-Version 1.5 kann man mit der Zeile:
    PARALLEL_MAKE = "-j n"
    in build/conf/local.conf make n-Mal parallel laufen zu lassen.
    Beim neuen bitbake 1.8.12 gibt es noch eine 2. Möglichkeit. Mit der Zeile:
    BB_NUMBER_THREADS = "n"
    kann man n bb-files gleichzeitig bearbeiten.
    Mit dem neuen OE 1.6 habe ich ein Image für die Dreambox 7020 erstellt und dabei alle Varianten ausprobiert. Hier die Ergebnisse:


    Ohne die beiden Zeilen (nur 1 Prozess aktiv): 3h:45m
    mit PARALLEL_MAKE = "-j 2": 2h:37m
    mit PARALLEL_MAKE = "-j 3": 2h:32m
    mit BB_NUMBER_THREADS = "2": 2h:01m
    mit BB_NUMBER_THREADS = "3": 2h:14m


    Wahrscheinlich kann PARALLEL_MAKE bei 3 Prozessen die Pausen ausnutzen, wo der Prozessor z.B auf die Festplatte wartet. Bei 4 Prozessen gibt es keine weitere Steigerung mehr, bei 5 Prozessen wird es sogar wieder langsamer. Zum Spaß habe ich das auch mal auf einem älteren Athlon XP mit 2000 MHz ausprobiert. Die Image-Erstellung dauert hier über 4 Stunden. Mit PARALLEL_MAKE = "-j 2" kann man das auch hier um wenige Minuten verkürzen.


    BB_NUMBER_THREADS hat wahrscheinlich einen größeren Verwaltungsaufwand, so das man die Zahl der vorhandenen Prozessorkerne nicht überschreiten sollte.


    Dann habe ich beide Zeilen kombiniert:
    mit BB_NUMBER_THREADS = "2" und PARALLEL_MAKE = "-j 2": 1h:44m
    mit BB_NUMBER_THREADS = "2" und PARALLEL_MAKE = "-j 3": 1h:41m


    Adenins Skript sollte also unbedingt um die Zeile PARALLEL_MAKE = "-j [Anzahl der CPU-Kerne]" erweitert werden, eventuell sogar [Anzahl der CPU-Kerne]+1.
    Die OE-Erstellung lässt sich also ganz gut auf 2 Kerne verteilen. Es wäre interessant zu erfahren, ob das auch noch auf einen Quad-Prozessor zutrifft.

  • Mit "Q9550, 2833 MHz (8.5 x 333)" + "4 x 2 Gb DDR2-800 (400 MHz)" unter "Ubu-8.10 64 Bit Reiserfs" + "BB_NUMBER_THREADS = "4"" +"vorhandene sourcen", ist ein "OE-1.6-dm7025" in "2h:40m" durch.


    PARALLEL_MAKE stosse ich heut Nacht an.

    Kathrein EXR 508/T | Schwaiger 100er-Alu | Goldedition Quatro 0,3 dB | Gent-st1 | Sidu-akt | Ubun-akt | ... | Q9550 | 8 GB | DS-107+

    2 Mal editiert, zuletzt von dreg ()

  • man sollte vorallem achten, das psyco installiert ist.


    das bringt zusätzlich mehr power beim backen :)

  • Erster Test ist durch.


    Distri:

      Ubu-8.10 | 64 Bit | Reiserfs | mit GUI

    Hardware:

      Q9550, 2833 MHz (8.5 x 333)
      4 x 2 Gb DDR2-800 (400 MHz)
      Proz-Last Ø 4 x 90%

    OE:

      OE-Git-1.6-dm7025 (sourcen vorhanden)
      BB_NUMBER_THREADS = "4"
      PARALLEL_MAKE = "-j 5"

    Zeit:

      0h:50m
      ohne PARALLEL_MAKE: 02h:40m


    ismail.demir,


    Zitat

    man sollte vorallem achten, das psyco installiert ist.


    ist aber nur für 32 Bit. :)

    Kathrein EXR 508/T | Schwaiger 100er-Alu | Goldedition Quatro 0,3 dB | Gent-st1 | Sidu-akt | Ubun-akt | ... | Q9550 | 8 GB | DS-107+

    Einmal editiert, zuletzt von dreg ()

  • dreg: trotzdem :winking_face:


    @all
    IMHO sollte man BB_NUMBER_THREADS nicht benützen, denn
    sobald ein thread (befehl) nicht ausgeführt werden kann oder nicht
    erfolgreich beendet wird (!), ist der nächste thread schon am laufen.


    normalerweise müssen die befehle ja schrittweise ausgeführt werden, da
    ist aber nicht der fall, weil eben der nächste oder übernächste gleichzeitig
    gestartet werden.


    sinnvoller wäre, wenn alle kerne denselben befehl gleichzeitig abarbeiten
    und nicht 4 befehle pro 4 kerne gleichzeitig.


    ps: ... hat aber enorme geschwindigkeit !






    die meiste zeit vergeht eh beim herunterladen, wenn mal die server down sind ...



  • Zweiter Test ist durch.


    Distri:

      Ubu-8.10 | 64 Bit | Reiserfs | mit GUI

    Hardware:

      Q9550, 2833 MHz (8.5 x 333)
      4 x 2 Gb DDR2-800 (400 MHz)
      Proz-Last Ø 4 x 70%

    OE:

      OE-Git-1.5-dm7025 (sourcen vorhanden)
      BB_NUMBER_THREADS = "4"
      PARALLEL_MAKE = "-j 5"

    Zeit:

      1h:40m
      ohne PARALLEL_MAKE: 02h:10m

    Kathrein EXR 508/T | Schwaiger 100er-Alu | Goldedition Quatro 0,3 dB | Gent-st1 | Sidu-akt | Ubun-akt | ... | Q9550 | 8 GB | DS-107+

  • Distri:

      Kubuntu-8.10 | 32 Bit | ext3 | mit GUI

    Hardware:

      Q9650, 3000 MHz (9.0 x 333)
      2 x 1 Gb DDR3-1333 (333 MHz)
      Proz-Last:

    OE:

      OE-Git-1.5-dm800 (von grund auf)
      BB_NUMBER_THREADS = "4"
      PARALLEL_MAKE = "-j 4"

    Zeit:

      2h:04m
      von erstellen "env.source" bis hin zu image datei

  • Vielen Dank für die Antworten.



    Hier noch weitere Daten von mir:


    Distri:
    Suse 11.1 | 32 Bit | ext3 | mit GUI


    Hardware:
    Athlon X2 4400, 2300 MHz
    2 x 1 Gb DDR2-800 (200 MHz)


    Ich habe jeweils das gesamte Verzeichnis build/tmp gelöscht and dann neu kompiliert.


    Beim Vergleich der PCs muss man bedenken, dass das Image für die DM7020 schneller geht als das für die Mipsel-Boxen. Es sind weniger Paktete zu kompilieren.


    Ich werde es demnächst mal mit 64 Bit probieren.

  • @ Hein Holz, ich habe gerade mal die DM7020 angestoßen mit:


    Code
    echo 'BB_NUMBER_THREADS = "4"' >> $@
    	echo 'PARALLEL_MAKE = "-j 4"' >> $@


    /tmp Ordner und cache komplett gelöscht. Sourcen liegen auf der Platte.
    Hoffe bleibt niergends hängen, dann muss ich erst fixen und neu machen :)
    Ich berichte!

    Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. <br>
    Mahatma Gandhi

  • Distri:
    Debian | 32 Bit | ext3 | mit GUI


    Hardware:
    T7600, Dual 2,33 GHz, 4GB Cache
    2 x 2 Gb DDR2-6400 (800MHz) <---wegen 32Bit werden nur 3GB erkannt


    Ich habe jeweils das gesamte Verzeichnis DM7020 OE-1.5 git build/tmp und cache gelöscht und dann neu kompiliert.


    unter:

    Code
    #	echo 'BB_NUMBER_THREADS = "3"' >> $@
    #	echo 'PARALLEL_MAKE = "-j 3"' >> $@


    Zeit:2h:13m


    unter:

    Code
    BB_NUMBER_THREADS = "2"
    PARALLEL_MAKE = "-j  2"


    Zeit:1h:37m


    unter:

    Code
    BB_NUMBER_THREADS = "3"
    PARALLEL_MAKE = "-j  3"


    Zeit:1h:36m


    unter:

    Code
    BB_NUMBER_THREADS = "4"
    PARALLEL_MAKE = "-j  4"


    Zeit:1h:40m

    Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. <br>
    Mahatma Gandhi

    Einmal editiert, zuletzt von Schaedelmeister ()

  • Hallo,


    bin ja nett der "Computerprofi", aber die ganze Beschleunigung sollte doch nur effektiv
    was bei 64bit-Systemen was bringen, oder liege ich da Falsch?


    Zumindest das 32bit-Linuxsystem ist doch eigentlich nicht für "Mehrkern" gedacht und wird ja meist
    nur empfohlen weil da der Poolauswahl der debfiles usw. größer ist :face_with_rolling_eyes:

    MfG EgLe :]

    Linux will Benutzer, die Linux wollen. Linux ist nicht Windows


    Kernel : 5.4.2-1-MANJARO LTS
    GUI : KDE 5.64.0 / Plasma 5.17.4
    Machine : Intel NUC8i7HVK
    Graphics : Radeon RX Vega M GH
    CPU : Intel Core i7-8809G @ 8x 4.2GHz
    RAM : Gskill F4-3000C16S-16GRS Speicherkarte so D4 3000 16GB C16 Rip

  • Weil es bisher noch keiner angemerkt hat:
    BB_NUMBER_THREADS kann (nicht muss) auch schädlich sein, man sollte ggf. den Vorgang bei einem Fehler erneut anstossen.


    Hier der Fall gewesen als er do_populate_staging und do_install bei freetype für die dm7020 gleichzeitig ausführen wollte, der erstere aber von letzterem abhängig ist.


    *EDIT* Und etwas anderes wurde aus dem Thread nicht klar:
    PARALLEL_MAKE ist eine Option die sich nur auf gnu make auswirkt und (quasi) angibt, wie viele Dateien er gleichzeitig kompilieren soll.
    BB_NUMBER_THREADS gibt an, wie viele Threads bitbake verwendet (also z.B. gleichzeit mehrere Pakete bauen).


    Interessant - und vermutlich auch was sich im Testszenario von Hein Holz so negativ ausgewirkt hat - wird wenn man beide kombiniert und nun mehrere do_compile Tasks gleichzeitig ausgeführt werden.
    Dann wird im Prinzip in n*m Threads, wobei n = Anzahl bb Threads und m = Anzahl make Threads, gearbeitet und da können die sich schonmal gegenseitig die Rechenzeit stehlen.

    Homescreen eurer Apple-Geräte noch nicht voll genug?


    dreaMote: Fernbedienung für Enigma2, Enigma, Neutrino, VDR und TitanNit
    My Home Remote: Fernkontrolle für Homematic CCU/CCU2 optimiert für mobile Benutzung
    Mobile WOL: Wake-on-LAN Client für iPhone und iPad mit optionalem Widget

    Einmal editiert, zuletzt von ritzMo ()

  • Ich denke du meinst den ersten Abschnitt vor dem Edit:
    Dann hast du PARALLEL_MAKE und BB_NUMBER_THREADS aber vertauscht :winking_face:


    Und auch dann war das ungenau - das Problem ist ja nicht direkt ein Fehler bei der Ausführung der zu einem falschen Endprodukt führt sondern eben eine unbeachtete Abhängigkeit die einen Schritt nicht ausführen lässt. Behoben ist es ja wie gesagt ganz schnell indem man bitbake einfach neu startet (da der do_install task in meinem Beispiel ja gefinished wird und somit beim nächsten mal do_populate_staging nicht mehr fehlschlägt).

    Homescreen eurer Apple-Geräte noch nicht voll genug?


    dreaMote: Fernbedienung für Enigma2, Enigma, Neutrino, VDR und TitanNit
    My Home Remote: Fernkontrolle für Homematic CCU/CCU2 optimiert für mobile Benutzung
    Mobile WOL: Wake-on-LAN Client für iPhone und iPad mit optionalem Widget

  • Zitat

    Original von ritzMo
    Ich denke du meinst den ersten Abschnitt vor dem Edit:
    Dann hast du PARALLEL_MAKE und BB_NUMBER_THREADS aber vertauscht :winking_face:


    da hast du recht.
    letzteres hatte ich vor dem editieren BB_NUMBER_THREADS geschrieben :)


    als bei mir mit PARALLEL_MAKE gleichzeitige bb files ausgeführt wurde
    (siehe zitat) hab ich umbenannt auf PARALLEL_MAKE.


    edit: ich schau mi nochmals an

  • Trotzdem haste mitgetestet :winking_face:

    Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. <br>
    Mahatma Gandhi

  • also am besten PARALLEL_MAKE benutzen, schließlich machts
    BB_NUMBER_THREADS im moment eh kein sinn, da er nur mit opendreambox 1.6
    in frage kommt.


    wer BB 1.6.8 für normale oe images verwendet, profitiert sowieso nicht.
    ich hab umgestellt auf PARALLEL_MAKE.


    das verhalten von BB_NUMBER_THREADS könnt ihr nachvollziehen, indem ihr
    das laufende prozess mit STRG+C abbricht.
    dann werden die anderen threads weiter ausgeführt.