Ich habe mal gehört, dass der C++ Compiler als Zwischencode erst C- und dann Assembler erzeugt. Kann man den C-Code beim GCC anzeigen lassen?
Cpp schrieb: > Ich habe mal gehört, dass der C++ Compiler als Zwischencode erst > C- und > dann Assembler erzeugt. > Kann man den C-Code beim GCC anzeigen lassen? Das war mit den ersten Versionen von C++. Ist ungefähr 25 Jahre her. Also nein
Kommt auf den Übersetzer an. Der gcc hat die Option -S, auch -E ist manchmal wertvoll.
>was erwartest du dir davon?
Ich will die Ausführungsgeschwindigkeit optimieren.
Cpp schrieb: > Ich will die Ausführungsgeschwindigkeit optimieren. Dann solltest du das in C++ machen.
>Dann solltest du das in C++ machen.
Und Du solltest vielleicht etwas nachdenken.
Cpp schrieb: >>was erwartest du dir davon? > > Ich will die Ausführungsgeschwindigkeit optimieren. von was? von deinem ganzen Projekt? nicht"Gast" schrieb: > Cpp schrieb: >> Ich will die Ausführungsgeschwindigkeit optimieren. > > Dann solltest du das in C++ machen. Seh ich genauso. C++ bietet so unglaublich viel verfügbare libraries(boost etc.), damit kann man die meisten standardprobleme richtig gut umsetzen. Dann noch -o3, und der Assembler der ausgeführt wird, ist schneller, als du das per Hand jemals hinkriegen würdest.
Cpp schrieb: >>Dann solltest du das in C++ machen. > > Und Du solltest vielleicht etwas nachdenken. Eher du. Deine Fragestellung zeigt bereits deutlich dass du über kein derartiges Spezialwissen verfügst, um besser optimierten Code als der GCC zu erzeugen.
>Deine Fragestellung zeigt bereits deutlich dass du über kein >derartiges Spezialwissen verfügst, um besser optimierten Code als der >GCC zu erzeugen. Deine Antwort zeigt wie üblich Deine Überheblichkeit und mangelndes Fachwissen. Du verfügst über keinerlei Informationen mein Optimierungsproblems, musst aber wie immer die Klappe auf reisen.
Cpp schrieb: >>Deine Fragestellung zeigt bereits deutlich dass du über kein >>derartiges Spezialwissen verfügst, um besser optimierten Code als der >>GCC zu erzeugen. > > Deine Antwort zeigt wie üblich Deine Überheblichkeit und mangelndes > Fachwissen. > > Du verfügst über keinerlei Informationen mein Optimierungsproblems, > musst aber wie immer die Klappe auf reisen. Dann sag doch was dein Problem ist, vielleicht hilft dir dann auch jemand, der die aktuellen C++ Konzepte gut versteht und dir näher bringen kann
Cpp schrieb: >>Deine Fragestellung zeigt bereits deutlich dass du über kein >>derartiges Spezialwissen verfügst, um besser optimierten Code als der >>GCC zu erzeugen. > > Deine Antwort zeigt wie üblich Deine Überheblichkeit und mangelndes > Fachwissen. > > Du verfügst über keinerlei Informationen mein Optimierungsproblems, > musst aber wie immer die Klappe auf reisen. Da hat das Lördchen schon recht. Anhand der Fragestellung (und der nicht durchgeführten google-Suche) sieht man doch dass du dich auf einem Niveau bewegst auf dem absehbar ist dass du den gcc-Optimierer nicht toppen kannst. Unabhängig vom konkreten Problem. Das ist ja keine böse Kritik sondern eigentlich ein guter Rat. Stell einfach -03 ein und gut ists.
Benji schrieb: > Anhand der Fragestellung (und der nicht durchgeführten google-Suche) > sieht man doch dass du dich auf einem Niveau bewegst auf dem absehbar > ist dass du den gcc-Optimierer nicht toppen kannst. > Unabhängig vom konkreten Problem. Ich glaube nicht, dass er versucht die Optimierungen vom gcc zu toppen. Es geht eher um langsamen C++ Code, den der gcc nicht optimiert bekommt, weil versteckte "new" u.s.w. Mein wortkarger Ratschlag war eigentlich eher gemeint, sich mit der Sprache C++ zu beschäftigen, als es über trial and error zu versuchen.
Falls Du gcc benutzt - schau Dir mal die Seite an: https://panthema.net/2013/0124-GCC-Output-Assembler-Code/ Damit bekommst Du ganz brauchbaren .s Assembler Output. Ich finde es durchaus sinnvoll, den ASM-output anschauen zu können. das fördert das Verständnis, was der Compiler und die eingestellten Optimierungen eigendlich macht. Gruß, Stefan
Cpp schrieb: >>Deine Fragestellung zeigt bereits deutlich dass du über kein >>derartiges Spezialwissen verfügst, um besser optimierten Code als der >>GCC zu erzeugen. > > Deine Antwort zeigt wie üblich Deine Überheblichkeit und mangelndes > Fachwissen. Inwieweit zeigt sich hier mein mangelndes Fachwissen? > Du verfügst über keinerlei Informationen mein Optimierungsproblems, > musst aber wie immer die Klappe auf reisen. Dein konkretes Problem ist hierbei unerheblich. ist es trivial, so kann es der GCC sowieso besser als du. Ist es derart speziell dass der GCC scheitert, so wirst du es nicht besser optimieren können.
>Inwieweit zeigt sich hier mein mangelndes Fachwissen?
Ganz einfach: Die Performance bestimmter Konstrukte ist stark
MCU-Architektur abhängig. Da hast Du nun einmal deutliche Lücken.
Ja was willst Du nun, aus C++ C-Code machen weil es für Dein Target keinen C++ Compiler gibt ? Alles andere macht wenig Sinn. Und ein aktueller C++ Compiler optimiert auch entsprechend selber so das eigene Optimierungen nicht wirklich besser sein dürften.
Cpp schrieb: >>Inwieweit zeigt sich hier mein mangelndes Fachwissen? > > Ganz einfach: Die Performance bestimmter Konstrukte ist stark > MCU-Architektur abhängig. Und du denkst der GCC ignoriert die jeweilige Architektur? Ich habe eine Überraschung für dich: Die Assemblerausgabe JEDEN Compilers ist stark (MCU-)Architektur abhängig. > Da hast Du nun einmal deutliche Lücken. Ja das sagtest du bereits... Kannst du denn mal ein Beispiel zeigen, wo der GCC nicht gut genug für eine bestimmte Architektur optimiert hatte und DEINE bessere Lösung dazu?
:
Bearbeitet durch User
cppler schrieb: > Und ein aktueller C++ Compiler optimiert auch entsprechend selber so das > eigene Optimierungen nicht wirklich besser sein dürften. Das ist stimmt zum Teil, aber: - GCC ist kein moderner Compiler. - Compiler werden überlicherweise besseren Maschinencode erzeugen wenn man das Gesamtergebnis betrachtet. Einfach weil sie eine bessere Übersicht haben. - Compiler sehen leider nicht alles. Für den Compiler ist es z.b. nicht bekannt ob zwischen zwei Registerzugriffen jeder Takt wichtig ist. Kann er auch nicht wissen, weil Hochsprachen so eine Beschreibung eigentlich nicht kennen. Der Compiler wird im Scope fleissig umsortieren wenn er darin keinen semantischen Bruch erkennt. - C++ erlaubt viel zu viele Konstrukte die unnötigerweise in dynamischem Code an der falschen Stelle oder erhöhrem RAM-Bedarf führen. Um C++ auf Embeddedsystemen einzusetzen muss man deutlich mehr Verständnis für die Sprache haben als bei C. - Auch moderne Compiler wie der clang brauchen eine Hilfestellung, wie z.b. profile guided optimization. Wenn man die letzten 3 Taktzyklen aus einer ISR kitzeln will kann man schon mal zu Assembler zurückkehren. Das ist natürlich nur an sehr speziellen stellen möglich.
Matthias schrieb: > - GCC ist kein moderner Compiler. Das musst du jetzt aber mal ausführen. Eine sehr merkwürdige Behauptung. Matthias schrieb: > - Compiler sehen leider nicht alles. Für den Compiler ist es z.b. nicht > bekannt ob zwischen zwei Registerzugriffen jeder Takt wichtig ist. Kann > er auch nicht wissen, weil Hochsprachen so eine Beschreibung eigentlich > nicht kennen. Der Compiler wird im Scope fleissig umsortieren wenn er > darin keinen semantischen Bruch erkennt. Ja, so was sollte man dann mit inline Assembler machen. Das kann C auch nicht leisten. Ich wage aber mal zu behaupten, dass es kein Standardfall ist. Matthias schrieb: > - C++ erlaubt viel zu viele Konstrukte die unnötigerweise in dynamischem > Code an der falschen Stelle oder erhöhrem RAM-Bedarf führen. Um C++ auf > Embeddedsystemen einzusetzen muss man deutlich mehr Verständnis für die > Sprache haben als bei C. Da die Sprache deutlich Umfangreicher ist als C ist das zutreffend. Aber das kann jetzt kein Argument sein oder? Man sollte sich doch immer weiter entwickeln und in der Lage sein, etwas dazu zu lernen.
Matthias schrieb: > - GCC ist kein moderner Compiler. Quelle? Verglichen mit welchen anderen Compilern? Auf welchen Architekturen? > - C++ erlaubt viel zu viele Konstrukte die unnötigerweise in dynamischem > Code an der falschen Stelle oder erhöhrem RAM-Bedarf führen. Das ist keine Eigenschaft der Sprache, sondern eine Eigenschaft der STL. Es gibt Embedded-STLs, die auf dynamischen Speicher verzichten (und dafür gewisse Funktionalität nicht bieten, logisch). Da wurde vor einigen Tagen ein gutes Video hier im Forum verlinkt. > Wenn man die letzten 3 Taktzyklen aus einer ISR kitzeln will kann man > schon mal zu Assembler zurückkehren. Das ist natürlich nur an sehr > speziellen stellen möglich. Ersetze "möglich" durch "nötig", dann stimme ich dir zu. ;-)
S. R. schrieb: > Da wurde vor > einigen Tagen ein gutes Video hier im Forum verlinkt. Welches Video meinst du?
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.