Pages: [1] 2 
|
 |
|
|
Author
|
Topic: arm-none-eabi-gcc Code Optimierung mittels Compiler (Read 5308 times)
|
|
dl8mby
alter Hase
 Offline
Posts: 363
Ich liebe dieses Forum!
|
 |
arm-none-eabi-gcc Code Optimierung mittels Compiler
« on: 28. November 2016, 11:58:06 »
|
|
Hallo Forum,
ich habe etwas mit den Switches des gcc Compilers gespielt
und dabei eine Liste erstellt für die einzelnen Objektfilegrößen
bei unterschiedlichen Optimierungsstufen.
Compiliert wurde mit einem arm-none-eabi-gcc in Version 5.4.1
gcc version 5.4.1 20160609 (release) [ARM/embedded-5-branch revision 237715] (openSUSE 5.4.0_20160622-3.20)
Möglicherweise kann die Tabelle pdf/xls den Experten von Euch
weiter helfen, falls nicht, war es eine kleine bash Skript-Übung.
Falls Interesse besteht, kann ich auch die verschiedenen mchf.bin
Files zum spielen hochladen.
vy73
Markus
DL8MBY
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #1 on: 28. November 2016, 12:00:38 »
|
|
Nachtrag,
Tabelle als xls Format.
Bitte Suffix .txt entfernen.
Musste die Forum-SW überlisten.
Markus
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #2 on: 28. November 2016, 12:10:41 »
|
|
Tschuldigung,
musste das Pdf nochmals erzeugen, da die Blatt-
einteilung für die Tabelle ungünstig war.
Ich hoffe so kann man jetzt die Tabelle besser deuten.
Markus
DL8MBY
|
|
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #4 on: 28. November 2016, 12:19:53 »
|
|
Hallo Andreas,
da ich Eure Ergebnisse diesbezüglich nicht kenne und
auch nicht mit den selben Werkzeugen hantiere, habe
ich mir die Mühe gemacht mal selber den Compiler-
Output zu betrachten.
Bei der Vielzahl der Möglichkeiten, die der GCC bietet,
ist es fast unmöglich alle Optionen durchzutesten.
Wie sind die Erfahrungen bei Inlinefunktionen, Loop-
optimierungen, Branch-Optimierungen?
An die FPU habe ich mich noch nicht mal rangetraut,
da ich bei ARM nicht so viele Erfahrung habe.
Mir ist aber sehr wohl aufgefallen, das verschiedene
Compilate z.B eine Auswirkung auf die Geschwindigkeit
der Wasserfalldarstellung haben - nur so als Beispiel.
vy73
Markus
DL8MBY
|
|
 Logged
|
|
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #6 on: 28. November 2016, 16:37:22 »
|
|
Hallo,
bei Compileroptimierung für normale Anwendungsfälle ist Pragmatismus angesagt.
-O0 -> keine Optimierung -> Das geht nicht, denn dann darf der Compiler nicht mal die simpelsten Dinge machen sondern exakt das, was die Programmiersprache vorgibt und der Programmier hinschreibt. d.h. jede Variable wird ordentlich im Haupspeicher angelegt, obwohl sie eigentlich nur mal so zwischendurch verwendet wird.
-O1 -> geht immer, der erzeugte Code ist noch recht nah am ursprünglichen Code, aber schon deutlich schneller in vielen Fällen und braucht auch weniger RAM.
-O2 -> Guter Kompromiss zwischen Performance und Speicherverbrauch (Flash aber auch RAM)
-O3 -> Recht agressiv, schneller aber auch mehr Programmcode, aber nicht viel.
Deswegen nehmen wir -O2 und gut ist.
------------- Schwafel-Mode Ein -------------
Wenn man das optimieren ernsthaft betreiben will, dann hilft eigentlich nur eine Hotspot-Analyse und das gezielte An- (und Ab-)schalten von dutzenden von Einzeloptionen, deren Auswirkung man entweder kennt oder erprobt, teilweise auch nur für bestimmte Abschnitte. Das lohnt sich nur für Ausnahmefälle.
Ohne jemanden zu nahe zu treten (und auch auf mich bezogen): Niemand der mcHF Entwickler, die aktuell an dem Code arbeiten hat da genug Zeit und Erfahrung.
Es gibt natürlich grobe Richtlinien wie performanter Code so sein sollte, die im Prinzip an den Stellen, wo es weh tut inzwischen im mcHF umgesetzt werden. Da ist sicher noch jede Menge Potential für experimentierfreudige Menschen, ausgestattet mit Profiling-Erfahrung und viel Geduld.
Wenn aber nur noch Experten verstehen, warum der Code so aussieht, wie er aussieht, macht es den meisten keinen Spass mehr reinzuschauen. Auch hier ist Pragmatismus hilfreich.
Im übrigen wird aktuell die meisten Zeit im ARM DSP Code (den wir als binäre Bibliothek einbinden, das wäre zu prüfen, ob da Selbstkompilieren was bringt) oder ggfs. in FreeDV verbracht, d.h. nicht mal in "unserem" Code. Bei den FreeDV Optimierungen, die uns jetzt die Nutzung auf dem mcHF erlauben, waren es zu 100% Veränderungen am Code, die die Performance gebracht haben (und zwar ordentlich) und zu 0% Anpassungen an den Compilerschaltern.
Der eigentliche Performanceproblem im Alltag ist nicht performant gestalteter Code und nicht der 100st. Schalter, der nochmal 0.1% rausholt.
Aber mit Open Source: jeder ist eingeladen etwas beizutragen, was er oder sie beitragen möchte.
------------- Schwafel-Mode Aus -------------
In jedem Fall ein nettes Bash-Skript, Markus! Es wäre sehr interessant, das Skript für einen anderen Zweck zu nutzen und zwar zum Monitoring über die Zeit: Wenn ein .o File plötzlich deutlich größer (oder kleiner) wird, kann man schauen, ob man sich hier ein Problem eingehandelt hat.
73
Danilo
|
| « Last Edit: 28. November 2016, 17:49:48 by DB4PLE » |
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #7 on: 29. November 2016, 07:31:51 »
|
|
Hallo Markus and alle andere Mitstreiter,
im Nachgang erscheint mir mein Posting vor diesem nicht unbedingt gelungen. Der technische Inhalt ist korrekt, aber ich bin mir nicht sicher, ob es die richtige Botschaft vermittelt.
Ich begrüße es, wenn jemand Lust zum Experimentieren hat und das und die Ergebnisse des Experiments mit uns teilen will. Genau so mache ich es auch und es macht mir Spass. Und deshalb sollte kein Posting so geschrieben sein, das es jemanden den Spaß versauen könnte. Ich denke inzwischen, das mein Posting so verstanden werden kann. So war es nicht gedacht, im Gegenteil.
Werde mich bemühen in Zukunft Anspruch und Posting enger beieinander zuhalten, aber Fehler macht man immer mal. Muss man auch zugeben können.
73
Danilo
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #8 on: 29. November 2016, 09:05:25 »
|
|
Hallo OM's,
hallo Andreas,
hallo Danilo,
ich sehe das nicht so eng, entweder man hat Spaß
am Pfriemeln, oder nicht.
Für meinen Fall, ist es eben interessant auszuprobieren,
ob diverse Compilerschalter noch was an Performance
herauskitzeln oder nicht.
Da ich mit meinen 429/439 MC's neben der originalen
Bestückung mit 407/409 meinen mcHF betreibe, macht
es Sinn zu sehen ob ein -Ofast was bringt, wenn der
Flash und das RAM noch nicht am Anschlag sind.
Der genannte Kompromiss von Andreas, hat wohl seine
Berechtigung, da er alle Fälle der vorhandenen HW
berücksichtigen muss.
Für mich war es mal interessant zu sehen, wie sich die
einzelnen Compilerschalter auf die Objektdateien und die
Binaries auswirken.
Ich habe natürlich noch nicht all Resultate in den mcHF
hochgeladen um den Resultat am Objekt beobachten zu
können, werde es aber mal am nächsten WE versuchen.
Bis dahin wünsch ich frohes und erfolgreiches Weiter-
entwickeln, damit wir alle gemeinsam unsere Freude
am mchf haben.
Bin schon gespannt auf die weiteren Fortschritte in den
digitalen Mod.-arten.
vy73
Markus
DL8MBY
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #9 on: 29. November 2016, 09:19:02 »
|
|
Hallo Markus,
genauso, wie wir immer noch händeringend "Dokumentierer" suchen (weil es eben nicht mal eben aus dem Ärmel geschüttelt werden kann sondern auch seine Zeit braucht) - genauso sind auch solche Untersuchungen sehr aufwändig.
Die Optimierung anhand von Compilerschaltern wäre ebenfalls ein Fulltime-Job.
Um hier wirklich gezielt vorzugehen und nicht irgendwelche "gemittelten Zufallsergebnisse" zu bekommen, müssten Laufzeiten von "kritischen Modulen/Funktionen" ermittelt werden. Dann kann man diese mit unterschiedlichen Schaltern optimieren. Ich nehme stark an, dass das je nach Modul unterschiedliche Schalter sein werden und diese in Präprozessoranweisungen in der jeweiligen Datei gewählt werden (müssen).
Ob das den Aufwand wert ist kann man nicht vorher sagen. Daher kann ich nur aus meiner bisherigen Erfahrung im Bereich "embedded systems" berichten, dass es den Aufwand bei einer Projektgröße wie die des mcHF bislang noch nie wert war. Keines meiner bisherigen Projekte hat auch nur annähernd den Umfang des mcHF erreicht. Und je komplexer die Aufgabenstellung, desto mehr Möglichkeiten für Optimierungen gibt es....
Du müsstest also zunächst eine Möglichkeit haben, bestimmte Abläufe quantitativ zu messen, damit Du bei Änderungen kalre Ergebnisse bekommst.
Es ist ein "Fulltime-Job" . Wer das angeht, wird nicht nebenbei Programmieren oder Dokumentieren können 
vy 73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #10 on: 29. November 2016, 11:17:20 »
|
|
Hallo Andreas,
das war mir klar, das die unterschiedlichen Module/Objekte
unterschiedliche Optimierungen benötigen, da jedes
Modul unterschiedliche Algorithmen/Funktionen/etc. abarbeitet,
weshalb einen generelle Optimierungs-Einstellung über alle
Module auch nur ein Kompromiss ist.
Das war ja der Grund, weshalb ich alle Object-Files betrachtet
habe, um zu sehen, wie die einzelnen Switches die jeweiligen
Module/Programmteile beeinflussen.
Die Timeinganalyse wäre das nächste, was mich interessiert,
weshalb ich auch mich für die QEMU Geschichte interessiert
habe, um zu sehen, wo welche Codeteile wie lange brauchen.
Da man den bestehenden Code/Source nicht sofort ohne
lange Einarbeitung und vor allem genaues Drüberlesen ver-
stehen wird, ich zumindest, muss man erst langsam einen
Überblick über das Ganze bekommen - um überhaupt
mitreden zu können.
Deshalb meine kleinen und langsamen Versuche das Ganze
Schritt für Schritt zu begreifen und zu durchschauen.
Wird wohl noch eine Weile dauern ;-)
vy73
Markus
DL8MBY
|
|
Logged
|
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #12 on: 29. November 2016, 12:23:50 »
|
|
Hallo Andreas,
ST-Link lässt keine Automatisierung zu.
Mit ARM-GCC + QEMU kann man über Nacht alle Compiler-Switches,
zumindest die relevanten, durchlaufen lassen und die Laufzeit
der bin/elf-Files vom Start zum Brackpoint testen und tabellarisch
erfassen.
Danach hätte man eine Übersicht, welche Module wie viel Zeit
benötigen. Da es sich um eine relative Messung handelt,
ist die Absolute Laufzeit nicht so wichtig.
Wie und ob man das mit ST-Link macht, kann ich nicht sagen.
Den realen MC dauernd mit Binaries zu flashen ist auch
nicht optimal und zudem zeitintensive.
Man muss nur nachdenken, wie man externe Ereignisse
an ein bin-Image, das im QEMU läuft bringt, um den
Programmablauf zu steuern.
War nur so ein Gedanke von mir, den ich hier mal poste.
vy73
Markus
DL8MBY
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #13 on: 29. November 2016, 13:18:07 »
|
|
Das Problem bei der Sache mit der Emulation ist, dass Du das Binary ebenfalls ändern müsstest - weil viele Abläufe davon abhängen, was i/o mäßig am STM passiert. Es ist nicht möglich (denke ich...) eine Umgebung für den Emulator zu bauen, der diese Sachen in das Binary "füttert". Folglich müsstest Du verschiedene Daten "injezieren" - was den Ablauf schon wieder an empfindlicher Stelle verändert. Ich denke nur an die I2S-Abarbeitung, die dazugehörigen Puffer, die damit verbundenen Interrupts...
Ich vermute daher, dass ein automatisierter, simulierter Ablauf nicht mit den uns zur Verfügung stehenden Mitteln realisierbar ist. Gerne lasse ich mich eines Besseren überzeugen - habe aber noch nicht mal Ansätze für sowas...
vy 73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #14 on: 29. November 2016, 14:11:29 »
|
|
Hallo Andreas,
ich meinet folgendes,
Loop:
Compilerlauf <Makefile mit verschiedenen Schalter-komb. aus Liste>
if (GCC == SUCCESS, oder mchf.elf exist, oder so ähnlich)
qemu-system-arm
-machine ...
-nographic -monitor null -serial null
-kernel mchf.elf -gdb
{ hier wird es etwas komplizierter ;-)
automatisch im Debugger Breakpoint setzen
run vom Image
? wieviel Zeit ist verstrichen
Ergebnis notieren in File mit Switch-Kombination.
}
end if
decrement compiler-switch-liste um aktuelle Parameter Komb.
exit loop if liste leer
Jump Loop;
Soweit meine Ablauf.
Ob das so klappt muss ich erst mal testen,
doch dazu brauche ich eine lauffähige QEMU
Installation für cortex-m4.
vy73
Markus
DL8MBY
|
|
Logged
|
|
|
|
Pages: [1] 2 
|
|
|
|
|
|
|
mchf_obj_code_size_after_gcc_optimization.pdf
