Hi, ich habe eine merkwürdige Beobachtung beim GCC gemacht. Daß -O3 aufs ganze Programm Geschwindigkeit kosten kann, kenne ich ja von x86 - Stichwort anwachsende Programmgröße vs. CPU-Cache. Also compiliere ich global gesehen mit -O2. Es gibt aber auch Pragmas, mit denen man den GCC zu Optimierung nur ausgewählter Code-Passagen anweisen kann. Das habe ich auch gemacht - nichts Wildes, nur z.B. eine oft aufgerufene Funktion mit einem Shellsort, die ich per Pragma auf -O3 gesetzt habe. Auf x86 bringt das eine meßbare Beschleunigung, weil die Routine klein genug bleibt, um kein Cacheproblem zu erzeugen. Auf ARM Cortex M4 hingegen bringt das eine Verlangsamung, obwohl der nichtmal einen Cache in dem Sinne hat. Ich habe auch ansonsten beim ARM-GCC auf Cortex-M4 noch kein Beispiel oder Codefragment gehabt, wo -O3 die Sache nicht gegenüber -O2 verlangsamt hätte. Ist das ein bekannter Defekt beim ARM-GCC? -O3 wäre damit ja eigentlich völlig sinnlos, weil es die Codegröße aufbläht UND den Code auch noch verlangsamt. Oder habe ich einfach nur die ganzen Pechtreffer gehabt, während andere da ein glücklicheres Händchen hatten? Wie sind Eure Erfahrungen mit ARM-GCC, -O3 und Cortex-M?
Nop schrieb: > Auf ARM Cortex M4 hingegen bringt das eine Verlangsamung, obwohl der > nichtmal einen Cache in dem Sinne hat. Die STM32F4 schon, da der langsame Flash Speicher den Code bremst. Versuch vielleicht mal den Vergleich bei Codeausführung im RAM, um diesen Effekt auszublenden.
Dr. Sommer schrieb: > Die STM32F4 schon, da der langsame Flash Speicher den Code bremst. Das kann natürlich sein, obwohl deren ART mit dem Prefetcher ja eigentlich diesen Effekt weitgehend ausschließt und GCC auch die Option -mslow-flash (oder so) kennt. > Versuch vielleicht mal den Vergleich bei Codeausführung im RAM, um > diesen Effekt auszublenden. Das wird die Sache nur noch mehr runterreißen. In ST-Foren habe ich das jedenfalls gelesen. Zwar hat das RAM keine Waitstaites, aber dann gehen Daten und Instruktionen letztlich über denselben Bus (weil: in denselben Speicherbereich), so daß die Architektur mit parallelem Daten- und Instruktionsbus nicht mehr geht wie geplant. Ergebnis ist Busverstopfung, weswegen RAM-Code eher langsamer läuft. ST empfiehlt das daher nicht. Natürlich mit der Ausnahme, daß man das Flash beschreiben will, dieser Code kann nur aus dem RAM laufen. Aber das ist dann ja nicht wegen der Geschwindigkeit.
Hast Du mal "-mslow-flash-data" probiert? Das kam mit gcc 4.9 Release. Flash ist bei Cortx M4 fast immer mit einem kleinen Cache beschleunigt. Nop schrieb: > Zwar hat das RAM keine Waitstaites, aber dann gehen > Daten und Instruktionen letztlich über denselben Bus Richtige(tm) MCUs haben dafür auch RAM im 0x10000000 Bereich, der über die Code/Daten Busse angesprochen wird. Dann bleibt der System Bus frei.
:
Bearbeitet durch User
Nop schrieb: > ich habe eine merkwürdige Beobachtung beim GCC gemacht. Daß -O3 aufs > ganze Programm Geschwindigkeit kosten kann Ist eine nicht ganz neue Erkenntnis. Die mitunter auch schon -Os schneller als -O1 werden liess. Die höheren Optimierungsgrade von GCC sind nicht speziell für Mikrocontroller implementiert worden, sondern kommen eher aus dem Bereich der Highend-Maschinen. Wobei auch da ein höherer Optimierungsgrad nur garantiert, dass der Compiler sich mehr Arbeit macht. Nicht aber, dass das Ergebnis wunschgemäss ausfällt. Wenn bei einem µCs -O3 langsamer als -O2 ausfällt, dass raubt das den Maintainern des Compilers garantiert nicht den Schlaf.
:
Bearbeitet durch User
Jim M. schrieb: > Hast Du mal "-mslow-flash-data" probiert? Das kam mit gcc 4.9 > Release. Klar, das hab ich drin, seitdem es das gibt; derzeit setze ich 5.3 Q2 ein. Allerdings sagt die Doku zu der Option, daß es das Laden von Immediates aus dem Flash minimiert. Klingt also so, als würde sich das eben nur auf Daten und nicht auf Code beziehen. Man bräuchte wohl auch noch ein "-mslow-flash-code". > Flash ist bei Cortx M4 fast immer mit einem kleinen Cache beschleunigt. Außer dem Prefetcher, der sich gleich 128bit auf einmal aus dem Flash zieht, gibt's auch noch den Dcache und den Icache, die man im Flash-ACR einstellen kann, ja. Nur, das sind keine Caches im Sinne von x86-CPUs, wo komplette nennenswerte Routinen reinpassen. Es werden nichtmal Caches im kB-Bereich sein. Aber hat mal jemand mit -O3 auf Cortex-M4 (speziell, in der Tat STM32F4) positive praktische Erfahrungen gemacht? Also daß es schneller wird?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.