Moin,
ich hab ein relative grosses Arduino RP2040 Projekt, mit ner compilezeit von ca. 15 sec. getestet auf verschiedenen aehnlichen Rechner.
Was dauert da so lange 150kb Programm zu erzeugen.
Da das Projekt viel try and error ist, was wie könnte man beschleunigen ?
wie sieht das auf nem modernen Rechner aus ?
Moin,
ich hab ein relative grosses Arduino RP2040 Projekt, mit ner compilezeit
von ca. 15 sec. getestet auf verschiedenen aehnlichen Rechner.
Was dauert da so lange 150kb Programm zu erzeugen.
Da das Projekt viel try and error ist, was wie könnte man beschleunigen
?
wie sieht das auf nem modernen Rechner aus ?
gruss,
Björn
Moin,
Mir ist aufgefallen, daß Arduino Kompilieren unter Mint Linux in meiner VM Umgebung mindestens fünf mal schneller als im Host W10X64 System abläuft. W10 braucht da deutlich mehr Zeit. Allerdings spreche ich hier nur von AVR GCC. Wie das beim RP2040 ist, kann ich nicht beurteilen.
Vielleicht unternehme etwas Ähnliches. Virtual Machine Player ist frei für Non-Commercial Use und Mint lässt sich dort leicht installieren. Dann kannst Du ja den Unterschied messen.
Dann kannst Du zum Kompilieren einfach, wenn nötig, schnell auf Linux umschalten, wenn Mint bei Nichtgebrauch im Dornröschenschlaf (Suspend Mode) verbleibt. Das Hochfahren dauert nur ein paar Sekunden.
Auch im WSL geht der Build viel schneller. Es ist aber nicht nur das reine Kompilieren, der Linker braucht auch Zeit, es wird ja ein großer Brocken vom Core dazugelinkt.
Mit WSL geht das mittlerweile sehr gut, ohne eine VM installieren zu müssen. USB ist etwas fummelig, geht mit usbipd aber auch sehr gut, vor allem mit aktueller Version 4.0.
Keine Ahnung ob das immer noch ein Problem ist, aber früher zumindest war da oft der Virenscanner schuld. Beim Compilieren werden haufenweise Source-files/includes gelesen und auch viele temporäre Objekt-Dateien angelegt, die alle einen OnAccess-Scan anstoßen.
Abschalten, testen, falls es dann besser ist: Schauen wie man eine Ausnahmeregel für die Arduino-Ordner festlegen kann.
Ich habe mehrfach beobachtet, daß der Compiler in der Arduino-Umgebung viel schneller ist als die Ausgabe im Arduino-Fenster.
Das kann man leicht nachvollziehen: Übersetzen und gleich aufs Target laden lassen. Das Target fängt schon mit dem neuen Programm an zu blinken, währenddem durch das Ausgabefenster noch der Text des Compilers kriecht.
Und das habe ich auch bei Projekten nahezu trivialer Größe beobachtet (win10x64 auf hinreichend leistungsfähigem PC ohne Schlangenöl).
Hinter der Arduino-IDE steckt ja ein GCC. Und der ist unter Windows auf dem gleichen Rechner erheblich langsamer als unter Linux. Warum das so ist erschließt sich mir aber auch nicht. Auf meinem Testsystem war damals "nur" der Windows Defender aktiv.
Das kann man leicht nachvollziehen: Übersetzen und gleich aufs Target
laden lassen. Das Target fängt schon mit dem neuen Programm an zu
blinken, währenddem durch das Ausgabefenster noch der Text des Compilers
kriecht.
Das ist mir auch aufgefallen.
V 2.3.2 ist zwar deutlich schneller geworden als die 1.x, es dauert aber trotzdem seine Zeit. Für 80 KB braucht mein WIN10 PC ca. 4 s.
Testweise werde ich mal den Virenscanner abschalten.
Die lange Compile-time der Arduino IDE ist mit ein Grund warum ich lieber mit PICs als AVRs arbeite.
Es geht einfach viel schneller.
Das Compilieren von Marlin (3D-Drucker Betriebssystem am Arduino Mega) nimmt mal gerne >5 Minuten in Anspruch...
Selbst mein neuer Laptop, ein HP Pavilion mit Ryzen 5 konnte das nicht maßgeblich verbessern, ich weiß nicht woran es liegt.
Der CCS C-Compiler (Microchip) braucht selbst bei sehr großen Programmen selten länger als 5s, erstellt aber sicher 8-10 Files in der Zeit. Beim Klick auf den Build-Button ist das Programm schon quasi auf dem Controller.
Wenn ich dort auch so lange warten müsste wie bei der Arduino IDE, ich hätte das Hobby vor 10 Jahren aufgegeben...
Das übliche -Os braucht also die 6-fache Zeit wie -O0.
Spielt man noch an der Debug-Info rum (-g0 statt -g3) dann wird's nochmal 15% schneller.
Das ist jetzt nur die Zeit um ein Modul ohne LTO zu compilieren. Mit LTO gehen die Compile-Zeiten dann massiv runter, dafür geht die Link-Zeit (was ja die Zeit für LTO-Bytecode Compile enthält) durch die Decke.
Das Compilieren von Marlin (3D-Drucker Betriebssystem am Arduino Mega)
nimmt mal gerne >5 Minuten in Anspruch...
Ja, das ist natürlich völlig inakzeptabel. Wenn man 20 mal täglich das Betriebssystem komplett neu kompilieren muß, behindert das den workflow doch ganz beträchtlich.
Das der gcc unter Windows deutlich langsamer agiert als unter Linux, auch und gerade bei solchen Winzprogramme, die auf einen AVR passen, ist altbekannt.
gcc arbeitet beim Compilieren halt mit unzähligen Dateien, und dieses Dateihandling ist bei Windows nicht sonderlich effizient.
vielen Dank für die Links! Da habe ich zumindest schon mal einen Ansatz, wo die Schrauben zum Drehen sind. Die Arduino-IDE für den 'Normalnutzer' ist ja doch recht beschränkt.
Da ich mit dem RP2040 spiele, hat ein Update auf Version 2.3.0 schon eine deutliche Beschleunigung gebracht. Hinzu kommt bei dem Controller, daß immer noch der USB-Stack dazugepackt wird, sodaß selbst ganz einfache Programme rund 60 kB groß werden. Das Kompilieren dauert dann rund 4 s, sodaß man recht schnell (Fehler)-meldungen bekommt. Mal sehen, ob sich da noch etwas beschleunigen läßt.
Da ich in der Regel fertige Programmmodule auf Arduino portiere, muß ich nicht jedes Detail neu überprüfen.
Beim AVR sind die Programme deutlich kleiner und ob da das Kompilieren nun 0,15 s oder 1,3 s dauert, wäre mir egal. Eine Maschine, die immer zu schnell reagiert, kann auch Stress machen. Es muß immer noch Zeit bleiben, in der man sich durch den Kopf gehen läßt, was man da gerade gemacht hat.
Eben mal probiert:
Beim RP2040 ist kein -flto zu finden. Die Optimierung steht auf -Os und eine Änderung auf -O0 reduziert die Übersetzungszeit unmerklich (Kopftimer). Vielleicht müßten alle Projektdateien neu kompiliert werden, um einen deutlichen Unterscheid zu spüren.
Bei AVR funktioniert die delay Routine der Standard Bibliothek nicht richtig, wenn man den Optimizer mitteln -O0 ganz deaktiviert. Es kann auch passieren, dass zeitkritische Registerzugriffe (die direkt nacheinander stattfinden müssen) nicht mehr funktionieren - es sei denn, man implementiert sie in Assembler.
Es kann
auch passieren, dass zeitkritische Registerzugriffe (die direkt
nacheinander stattfinden müssen) nicht mehr funktionieren - es sei denn,
man implementiert sie in Assembler.
Daher gibt es dafür in der avrlibc passende Makros, die genau das für einen erledigen.