C/C++, vorkompilierte Dateien?
-
Heißer Tipp: Compilier nicht auf einem Raspberry Pi, sondern für einen Raspberry Pi. Auf einem normalen Desktoprechner sollte das um ein Vielfaches schneller gehen. Crosscompiling (wie man das nennt) ist zwar nicht ganz einfach und wird bei den ersten Versuchen bestimmt oft schief gehen, aber für so eine beliebte Plattform wirst du bestimmt viele Anleitungen oder gar fertige Werkzeuge finden. Ich brauchte bei Google bloß 'cros' einzugeben und es wurde mir schon 'cross compiling raspberry pi' vorgeschlagen. Ich bin also wohl nicht der Erste mit dieser Suchanfrage
-
Vielen Dank für den Tipp. Daran habe ich auch schon gedacht, aber die ganze Konfiguration hat mich vom Thema abgehalten.
Na ja, vielleicht ist es ja doch nicht soooooo schwierig, werde es wohl bei der nächsten Gelegenheit ausprobieren. (Aber aktuell hab ich der Belegschaft und dem Chef schon mitgeteilt, dass mein Projekt (im Grossen und Ganzen) fertig ist und es nun genutzt werden kann..)
P.S.: Nun klappt's auch mit der Mail-Benachrichtigung wenn jemand im Forum hier antwortet - ebenfalls vielen Dank!
-
@jmar83 sagte in C/C++, vorkompilierte Dateien?:
- Nachdem Übertakten auf 4x 1.55Ghz meldete der Compiler mittendrin einen "segfault"...
- Nach dem Anpassen der Übertaktung von 4x 1.55GHz auf 4x 1.5Ghz war der "segfault" weg und es dauerte noch ca. 1 Stunde
- Nach der 2. Kompilation mit "ccache" dauerte es noch ca. 5.5 Minuten!!!!!
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. Wenns blöd hergeht erzeugt das Ding ein Programm das auch anscheinend das macht was es soll, aber dann irgendwo doch nicht richtig funktioniert. Nachdem der Gewinn durch Übertaktung sowieso so gering ist, ... wäre es mir das Risiko nicht wert.
-
"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
makemit 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 mitmake -j8fü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?
-
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...)
