C/C++, vorkompilierte Dateien?



  • "Ich würde die Übertaktung wieder rückgängig machen. Nicht jeder Fehler den die CPU bei zu hohem Takt macht muss in nem SIGSEGV enden."

    Bin bin es eigentlich gewöhnt, dass dabei der Rechner einfriert! 😉 (Das Problem mit diesem Fehler hängt aber 100% mit der Übertaktung zusammen, vorher ging's x mal ständig gut...)

    "Nachdem der Gewinn durch Übertaktung sowieso so gering ist, ... wäre es mir das Risiko nicht wert."

    Volle Zustimmung, jetzt mit dem "ccache" geht's ja ohnehin ab wie die Post! 🙂



  • @jmar83 sagte in C/C++, vorkompilierte Dateien?:

    "Ich würde die Übertaktung wieder rückgängig machen. Nicht jeder Fehler den die CPU bei zu hohem Takt macht muss in nem SIGSEGV enden."

    Bin bin es eigentlich gewöhnt, dass dabei der Rechner einfriert! 😉 (Das Problem mit diesem Fehler hängt aber 100% mit der Übertaktung zusammen, vorher ging's x mal ständig gut...)

    Hi! Ich bin hier zwar etwas spät dran, aber das ist wohl ein Problem das sich ohnehin nicht so schnell in Luft auflöst.

    Scheinbar wurde hier im Thread noch nicht erwähnt, dass sich make mit der Option -j<N> auch parallel betreiben lässt. Das würde ich zuerst versuchen, bevor du solche abenteuerlichen Sachen wie "CPU übertakten" machst. Versuch es erstmal mit make -j8 für eine 4-Kern-CPU mit Hyperthreading.

    Es gibt kaum etwas, das so gut von massiver Parallelisierung profitiert wie die meisten Build-Prozesse. Abhängigkeitsprobleme in den Makefiles sind hier allerdings kontraproduktiv und können den Parallel-Build auch unmöglich machen. Einen Versuch sollte es dennoch wert sein.



  • Hallo Finnegan

    Danke für Deinen Beitrag!

    Da das Raspi (3B+) zwar 4 Kerne hat jedoch kein Hyper-Threading (gibt's doch nur bei x86/x64/PC-kompatiblen CPUs?) habe ich mit der Option "-j4" kompiliert. Scheint zu klappen.

    (Hyper-Threading macht auf einen phys. Kern 2 virtuelle, so habe ich es zumindest im Windows-Gerätemanager beobachtet, bin mir aber noch 100% sicher ob meine Vorstellung stimmt?)

    Ob ein Zuwachs an Geschwindigkeit gegeben ist, sehen ich am Schluss des Build-Prozess. (Zeitdifferenz messen im Shell-Skript)

    Aktuell bin ich immer noch beim Raspi geblieben (statt cross-compile auf einem PC), da mir "ccache" die ganze Sache extrem beschleunigt hat.

    Ich schreibe dann noch mal einen Beitrag wenn es fertig ist! 🙂



  • Super, hat geklappt, Ziel erreicht - vielen vielen Dank!!

    Nun bin ich bei 17 Minuten statt bei 19-20 Minuten wie vorher.

    Wobei eh ein grosser Teil der Zeit gebraucht wird um das .deb-File zu packen (dpkg -b ...), aber dazu habe ich gelesen dass "dpkg-deb" (statt "dpkg") es zulassen würde die Kompressionsmethode sowie -stufe anzupassen. Na ja, das Packen (build) und das Entpacken (install) wäre damit schneller, die Datei allerdings grösser zum downloaden. Man muss halb abwägen...

    Und, nur so nebenbei: Die Option "--force-unsafe" bei "dpkg" scheint auch nicht viel zu bringen, ist evtl. nur zum Installieren geeignet statt zum Builden per "dpkg"... Warnung (in Kombination mit dem Parameter "-b") bekomme ich aber keine...



  • @jmar83 Kann es sein dass du ein tipp-fehler hast? Denn --force-unsafe gibt es nicht als parameter für dpkg. Meintest du eher --force-unsafe-io?

    https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slow_when_using_new_filesystems_such_as_btrfs_or_ext4.3F



  • Oh ja, "--force-unsafe-io" ist korrekt, so ist es auch in meinem Skript hinterlegt.



  • @jmar83 sagte in C/C++, vorkompilierte Dateien?:

    Kompressionsmethode

    Probier mal aus wie gross der Unterschied ist (Zeit und Filegrösse). Oft bringt das Runterschalten der Kompressionsstuft viel Zeit, kostet aber gleichzeitig nicht viel. Und das wäre vielleicht auch was wo man während der Entwicklungsphase andere Einstellungen verwenden könnte wie dann für's Bauen des Release.



  • Werde die Sache mit der Kompression bei Gelegenheit testen, aktuell war ich gerade wieder mal mit einem Problem beschäftigt welches mich irritiert hat: Nach einer Änderung der C/C++-Quelltexte war der Computer (Raspi 3B+ inkl. "ccache") x Minuten bei 90%, kurze Zeit später ist das System komplett abgestürzt. Keine SSH-Verbindung mehr etc. Auch das Einloggen am lok. Rechner ist gescheitert.

    Anschliessend habe ich die Werte für das Swapfile angepasst in /etc/dphys-swapfile:

    CONF_SWAPSIZE=4096
    CONF_MAXSWAP=8192

    ...damit hat es dann geklappt. (Während dessen ständig überprüft mit "free -m") Sicher genug und ausreichend virt. Speicher! 😉



  • @hustbaer: Zur Kompression: Also mit "dpkg-deb --nocheck -Zgzip -z2 -Srle -b ./xyz;" wird der Pack-Vorgang um ein x-faches schneller (in etwa: weniger als eine Minute statt ein paar im Vergleich zu vorher) Die .deb-Datei ist rund 3x so gross wie vorher (150MB statt wenig grösser als 50)

    Natürlich könnte man noch lange mit den Einstellungen spielen, am schnellsten wäre wohl unkomprimiert, aber das wird dann doch irgendwie zu gross... also lasse ich den Befehl mal so, wie er ist.

    Und das .gzip-Format hat den Vorteil, dass es sich wohl problemlos (werde es morgen anschauen) mit den gängigen Windows-Packern (7Zip, WinZip, WinRAR) entpacken lässt - im Ggs. zu dem dpkg-eigenen Format ("xz" steht unter http://man7.org/linux/man-pages/man1/dpkg-deb.1.html, "ar" musste ich bei einer Java-Anwendung mit den "Apache Commons Compress" auswählen... hmmm...??) Wobei ich aktuell unter Windows 7Zip klar bevorzuge.

    Es loht sich schon, die Vorgabewerte zu ändern falls es zu langsam geht - definitiv. Insbesondere während den Entwickeln (und Testen) ist dies sicher von Vorteil.



  • ...und noch was:

    "-> Die Tipps zum Übertakten habe ich von hier: https://miguelangelantolin.com/raspberry-pi-3-b-overclocking/ (-> Einfach "1550" mit "1500" ersetzen!!)"

    Wenn schon übertakten, dann wenigstens den GPU-Speicher auf das Minimum (?) von 16MB setzen, damit ein wenig mehr zum Kompilieren übrig bleibt! 😉

    (Siehe vorletzter Post)

    Und mit den Übertakten habt ihr recht, damit muss man vorsichtig sein... habe das Raspi (im Gehäuse, aber ohne Deckel) nun in den Serverraum gestellt wo es ein wenig wärmer ist. Und schon macht das Ding Stress. (Exakt gleiches Netzteil & USB-Stromkabel, daran kann es schon mal nicht liegen...)


Anmelden zum Antworten