logo
Welcome, Guest. Please Login or Register.
24. July 2024, 23:57:03


Home Help Search Login RegisterWIKIUHSDR Download

Amateurfunk Sulingen
Diskussions- und Newsboard des DARC-Ortsverbandes I40  |  allgemeine Kategorie  |  mcHF Projekt Deutsch / English (here you can discuss everything related to mcHF) (Moderators: DF8OE, DL1PQ)  |  Topic: arm-none-eabi-gcc Code Optimierung mittels Compiler <- zurück vorwärts ->
Pages: [1] 2 Go Down Print
   Author  Topic: arm-none-eabi-gcc Code Optimierung mittels Compiler  (Read 5027 times)
dl8mby
alter Hase
****

Offline

Posts: 363



Ich liebe dieses Forum!

View Profile
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

 mchf_obj_code_size_after_gcc_optimization.pdf
Logged
dl8mby
alter Hase
****

Offline

Posts: 363



Ich liebe dieses Forum!

View Profile
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
 mchf_obj_code_size_after_gcc_optimization.xls.txt
Logged
dl8mby
alter Hase
****

Offline

Posts: 363



Ich liebe dieses Forum!

View Profile
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

 mchf_obj_code_size_after_gcc_optimization2.pdf
Logged
DF8OE
Administrator
*****

Offline

Posts: 6265



Stellvertr. OVV I40, Jugend / Nachwuchsreferent

View Profile WWW
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #3 on: 28. November 2016, 12:11:11 »

Die unterschiedlichen Optimierungseinstellungen erzeugen selbstverständlich alle unterschiedliche Binaries. Je nachdem, was für Optimierungen durchgeführt werden, ist das Binary mal größer, mal kleiner, mal läuft es schneller, mal langsamer.

Wir haben den "besten Kompromiss" zwischen "kleinem Code" und "schnellem Code" gewählt 

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!

View Profile
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
DF8OE
Administrator
*****

Offline

Posts: 6265



Stellvertr. OVV I40, Jugend / Nachwuchsreferent

View Profile WWW
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #5 on: 28. November 2016, 12:28:03 »

Richtig. Und nicht nur auf die Wasserfalldarstellungen.

Es ist nun absolut müssig, für jede neue Version eine Abschätzung zu machen, welche Optimierung denn nun für diese Version die Beste ist. Das ist ABM und nur was für die "1%-Kratzer". Wir haben mit Bedacht die vorhandene Optimierungseinstellung gewählt und mussten sie noch nie ändern bzw. überdenken. Der Zeit/Nutzen-Quotient wäre verheerend...

Die alte SW von Clint hatte ein paar auswirkungsreiche Bugs, die aber erst bei Aktivierung irgendeiner Optimierung "so richtig" zugeschlagen haben. Im Ergebnis ist das einer der Hauptgründe, warum die alte SW im Vergleich zur neuen dramatisch träger ist. Natürlich würde sie jetzt ohne Optimierung auch die Grenze überschreiten, bei der man die größere MCU braucht.

Letztendlich denken wir nicht mehr über einen Vergleich oder eine Änderung des gewählten Optimierungsmodes nach.

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! <<<<
DB4PLE
positron
Urgestein
*****

Offline

Posts: 1278





View Profile
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





View Profile
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!

View Profile
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: 6265



Stellvertr. OVV I40, Jugend / Nachwuchsreferent

View Profile WWW
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!

View Profile
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
DF8OE
Administrator
*****

Offline

Posts: 6265



Stellvertr. OVV I40, Jugend / Nachwuchsreferent

View Profile WWW
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #11 on: 29. November 2016, 11:31:52 »

Es ist mittlerweilen in der Tat umfangreich...

Mit diesem Zusammenhang wird auch für mich aus der Sache mit dem QEMU ein Schuh

Leider sehe ich keine sinnvolle Möglichkeit, mit dem QEMU hier was weiterführendes zu bewirken.

Man kann das mit dem STLINK machen, oder man kann bei zu untersuchenden Funktionen am Beginn einen GPIO einschalten und am Ende wieder aus (so zur Zeit in FreeDV mit der grünen LED geschehen). Das ist zwar umständlich, da man sich jeweils eine "spezielle" FW bauen muss - aber dafür braucht man zur Überprüfung des Ergebnisses lediglich ein Scope (oder irgendwas, womit man Pulslängen möglichst exakt messen kann)...

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!

View Profile
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: 6265



Stellvertr. OVV I40, Jugend / Nachwuchsreferent

View Profile WWW
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!

View Profile
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 Go Up Print 
Diskussions- und Newsboard des DARC-Ortsverbandes I40  |  allgemeine Kategorie  |  mcHF Projekt Deutsch / English (here you can discuss everything related to mcHF) (Moderators: DF8OE, DL1PQ)  |  Topic: arm-none-eabi-gcc Code Optimierung mittels Compiler <- zurück vorwärts ->
Jump to: 


Login with username, password and session length

 Es wird die Verwendung von Browsern die auf der "Blink"-Engine basieren und mindestens
1024x768 Pixel Bildschirmauflösung für die beste Darstellung empfohlen
 
Amateurfunk Die Beiträge sind, sofern nicht anders vermerkt, unter der folgenden Lizenz veröffentlicht:
GNU Free Documentation License 1.3 GNU Free Documentation License 1.3
verbindet!
Powered by MySQL Powered by PHP Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2004, YaBB SE Dev Team. All Rights Reserved.
- modified by Andreas Richter (DF8OE)
Impressum & Disclaimer
Valid XHTML 1.0! Valid CSS!