|
|
Forum: Mikrocontroller und Digitale Elektronik c-code Schneller in Assembler?Hallo ich habe ein kleines Problem. Ich Programmierte schon Immer in Basic oder C... Nun komme ich aber bei einer Sache an die Rechen/zeit Grenze eines Mc`s... habe folgenden Code:
gibt es eine Möglichkeit diesen Code wesentlich schneller durch zu rechnen? lg Demont :
Gesperrt durch User
Demont schrieb: > gibt es eine Möglichkeit diesen Code wesentlich schneller durch zu > rechnen? wenn du uns sagst was das überhaupt werden soll, kann man bestimmt etwas machen. if (R==126) {G--;} if (R==126) {B++;} sieht schon sehr merkwürdig aus, warum 2 vergleiche? Demont schrieb: > if (G==126) > {R++; B--;} > if (R==126) > {G--;B++;} > > > if (B==126) > {R--; G++;} > > > > Zusammenfassen? 126 in Variable? :
Bearbeitet durch User
Hier war einfach die frage ob die IF anweisung schneller Möglich ist z.b. in Essabler. Wenn ja Wie? Es ist egal was damit bezweckt wird Man hat die die 3 Variablem die in/de-decrementiert werden über einfache if anweisungen Demont schrieb: > gibt es eine Möglichkeit diesen Code wesentlich schneller durch zu > rechnen? Solcher Code ist bereits sehr schnell. Fürs de- und inkrementieren besitzen die meisten Controller einen eigenen Befehl und solche Vergleiche können auch sehr einfach umgesetzt werden. Die beiden Werte werden subtrahiert und wenn danach das Zero Flag gesetzt ist, sind die beiden Werte identisch. Schau mal den generierten Assembler an. Wie kommst du auf die Idee, dass genau dieser Codeabschnitt dafür sorgt, dass dein Programm zu langsam ist? Muss dieser Codeabschnitt tausende Male pro Sekunde durchlaufen werden? Peter II schrieb: > if (R==126) {G--;} > if (R==126) {B++;} > > sieht schon sehr merkwürdig aus, warum 2 vergleiche? Weil er beide Farbkanäle unabhängig voneinander ändern will. Nutze mal lieber die Präfix-Operatoren (z.B. --G oder ++B), da dort keine Kopie erzeugt wird. Ansonsten, beschleunigen kannste immer über: - Wertetabelle mit vorberechneten Werten - zu verarbeitende Daten reduzieren (muss denn voller Bereich genutzt werden?) - algorithmisch clevere Lösungen über Farbräume :
Bearbeitet durch User
Demont schrieb: > Hier war einfach die frage ob die IF anweisung schneller Möglich ist ja in dem man sie durch ein anders rangehen komplett weglässt. be stucki schrieb: > Demont schrieb: >> gibt es eine Möglichkeit diesen Code wesentlich schneller durch zu >> rechnen? > > Solcher Code ist bereits sehr schnell. Fürs de- und inkrementieren > besitzen die meisten Controller einen eigenen Befehl und solche > Vergleiche können auch sehr einfach umgesetzt werden. Die beiden Werte > werden subtrahiert und wenn danach das Zero Flag gesetzt ist, sind die > beiden Werte identisch. Schau mal den generierten Assembler an. > > Wie kommst du auf die Idee, dass genau dieser Codeabschnitt dafür sorgt, > dass dein Programm zu langsam ist? Muss dieser Codeabschnitt tausende > Male pro Sekunde durchlaufen werden? Ja das wird er... mir fehlen 3µS für eine Passende sync :/ Ohne diese Abfrage geht es, mit 5 dieser If Abfragen klappt es auch nur mit der 6 Dauert es zu lange :/ Hast Du alle Optimierungsmöglichkeiten /O? ausgenutzt. Ich sehe oft, dass "C", wenn man eine Variable mehrfach vergleicht, diese auch mehrfach holt. So etwas sieht man in Assembler sofort bzw. macht man erst gar nicht. Hilf Deinem Compiler etwas, indem Du, wenn schon nötig, Vergleiche auf die gleiche Variable, dicht hintereinander schreibst. Die Optimierung über mehrere Zeilen hinweg bedingt eine Umformatierung des Quelltextes – keine Ahnung wie Klever der Compiler dabei ist. Aber die aktuellen Compiler optimieren meist recht gut. Keine Ahnung welchen Compiler und welches System Du benutzt, aber rund ums Gnu ist die Mischung von C und Assembler kein Problem. Falk Schilling schrieb: > Peter II schrieb: >> if (R==126) {G--;} >> if (R==126) {B++;} >> >> sieht schon sehr merkwürdig aus, warum 2 vergleiche? > > Weil er beide Farbkanäle unabhängig voneinander ändern will. Nutze mal > lieber die Präfix-Operatoren (z.B. --G oder ++B), da dort keine Kopie > erzeugt wird. > > Ansonsten, beschleunigen kannste immer über: > - Wertetabelle mit vorberechneten Werten > - zu verarbeitende Daten reduzieren (muss denn voller Bereich genutzt > werden?) > - algorithmisch clevere Lösungen über Farbräume Also anstelle von g-- dann --g kk probiere ich Wertetabellen... (leider nicht mehr genug Speicher vorhanden) V Daten reduzieren... Schon auf minimum (daher die if abfragung) Alg.... Hier die schnellste und beste variante gewählt die mir einfällt. Ich habe hier ein voll Modulares System das pro Durchgang die Farbe,Die position und den datenwert ändert. Tiny und 800KBit datenübertragung auf einem normalen Port mit Live berechnung des Codes... wie gesagt das alles ist schon recht Optimiert... mir fehlt nur da ein paar nano sekunden Demont schrieb: > Ohne diese Abfrage geht es, mit 5 dieser If Abfragen klappt es auch > nur mit der 6 Dauert es zu lange :/ dann lass doch eine weg. if (G==126) {R++;} if (R==126) {G--;} if (R==126) {B++;} if (B==126) {R--;} if (B==126) {G++;} if (G==126) {B--;} die beiden abfragen kannst du einfach zusammenlegen, es ändert nicht am ergebniss. if (G==126) {R++;} if (R==126) {G--; B++; } if (B==126) {R--; G++; } if (G==126) {B--;} liefert genau das gleiche. Peter II schrieb: > Demont schrieb: >> Ohne diese Abfrage geht es, mit 5 dieser If Abfragen klappt es auch >> nur mit der 6 Dauert es zu lange :/ > > dann lass doch eine weg. > > if (G==126) {R++;} > > if (R==126) {G--;} > if (R==126) {B++;} > > if (B==126) {R--;} > if (B==126) {G++;} > > if (G==126) {B--;} > > die beiden abfragen kannst du einfach zusammenlegen, es ändert nicht am > ergebniss. > > if (G==126) {R++;} > if (R==126) {G--; B++; } > if (B==126) {R--; G++; } > if (G==126) {B--;} > > liefert genau das gleiche. Sry hatte leider den Falschen Code gepostet Sry :( Hatte das schon so optimiert gehabt hatte sich aber noch nicht mit dem anderen Pc sync gehabt (1pc zum Proggen und einen zum Arbeiten) War schon so gewesen ... Die Mmstellung (b-- auf --b)gab leider keine besserung... Kann mir eventeull jemand sagen wie das Mit dem ASM code funktioniert mit dieser vergleichs if anweisung die ich dort verwendet habe? lg demont >Sry hatte leider den Falschen Code gepostet Sry :( Trottel. Viel Rauch um nichts. Pass beim nächsten mal besser auf. >Kann mir eventeull jemand sagen wie das Mit dem ASM code funktioniert >mit dieser vergleichs if anweisung die ich dort verwendet habe? Wozu? Bringt nichts mehr. Kauf dir nen schnelleren Controller. Hi, man kann sich soviel ich weiß den erzeugten ASM-Code anschauen. Ich weiß nur grad nicht mehr welche Dateien. Evt. kannst auch versuchen einen Sprung wegzuoptimieren. Die sind relativ aufwendig, da viele Register gesichert werden müssen. Gruß Peter holger schrieb: >>Sry hatte leider den Falschen Code gepostet Sry :( > > Trottel. Viel Rauch um nichts. Pass beim nächsten > mal besser auf. > >>Kann mir eventeull jemand sagen wie das Mit dem ASM code funktioniert >>mit dieser vergleichs if anweisung die ich dort verwendet habe? > > Wozu? Bringt nichts mehr. Kauf dir nen schnelleren Controller. Trottel weil ich vergessen habe das optimierte rein zu stellen anstelle von dem optimiertem? Obwohl die Problematik beim Optimierten code besteht... Deine Geistige Auffassungsgabe ist ja beachtlich... du hast dich der in diesem Thema somit erfolgreich selbst ausgeschlossen... Einfache Frage, und du haust so ein shit raus kopfschüttel @ Peter Z Danke für den Tipp ich schaue es mir mal an ^^ >Deine Geistige Auffassungsgabe ist ja beachtlich... Du willst einen LED Stripe mit W28shit Controller mit einem Tiny befeuern. Das RAM reicht nicht und deshalb musst du alles online berechnen. Soviel mal zu meiner Auffassungsgabe. Nimm einen Controller mit mehr RAM dann geht das auch. holger schrieb: >>Deine Geistige Auffassungsgabe ist ja beachtlich... > > Du willst einen LED Stripe mit W28shit Controller mit einem > Tiny befeuern. Das RAM reicht nicht und deshalb musst du alles > online berechnen. Soviel mal zu meiner Auffassungsgabe. > > Nimm einen Controller mit mehr RAM dann geht das auch. WOW und das war ja jetzt so schwehr aus den Informationen zu erfassen -.- Ich habe mit den Infos die ich gegeben habe, diese Schlussfolgerung jedem Fast ins Gesicht geklatscht. Aja du kennst natürlich die Umgebung in der das System verwendet wird. In verwendung habe ich einen Tiny85 2000 Zeilen Programmcode (von knapp 6000 optimiert),96,4% Progammspeichernutzung, alle i/o Pins genutzt. Ich habe dort wo ich es verwende kaum bist keinen Platz. Alles Funktioniert wie es soll... Dieser Part dort oben ist nur ein Autonomer Modus der somit als zusätzliche Option zur Verfügung stehen sollte. u.s.w. Aber tut mir leid das ich dir wiederspreche, da du ja Absolut genau weist WAS ich vor habe und wie ich dies umsetzten will unter welchen Bedingungen GZ. Kopfschüttel irgendwie werden Werte berechnet und dann mit 126 verglichen, wenn der Eingangswert 126 ist, überspringt er die 126, besser mit > oder < testen. Bei mir gibt es ein Fenster Disassamly mit dem Maschinencode. caste mal alles zu chars (auch die konstanten!).... kann wunder wirken. lutz h. schrieb: > besser mit > oder < schon versucht damit ist er sogar noch um ein vielfaches Langsamer Das einzige was Du an diesen Befehlen 'optimieren' könntest wäre 126 durch 0 zu ersetzen. Eine 0-Abfrage ist schneller. Aber vermutlich macht Dir das den Rest kaputt. Was wird denn mir RG und B gemacht? Edit: noch zum Tiny Bereits 12 Autonome Programme drauf 3 Steuerbare Programme Leds die Betrieben werden können ( getestet 600 LEDs in Reihe bei 50 Änderungen die Sekunde... mehr hatte ich nicht da) SO VIEL ZU MIT TINY KLAPPT DAS NICHT! Falk Schilling schrieb: > Nutze mal > lieber die Präfix-Operatoren (z.B. --G oder ++B), da dort keine Kopie > erzeugt wird. Macht sicherlich keinen Unterschied im erzeugten Maschinencode. lalala schrieb: > Das einzige was Du an diesen Befehlen 'optimieren' könntest wäre 126 > durch 0 zu ersetzen. Eine 0-Abfrage ist schneller. Aber vermutlich macht > Dir das den Rest kaputt. Was wird denn mir RG und B gemacht? Probiere ich morgen mal aus danke ^^ Falk Schilling schrieb: > Nutze mal > lieber die Präfix-Operatoren (z.B. --G oder ++B), da dort keine Kopie > erzeugt wird. Das bringt wirklich etwas? Habe gerade keinen GCC hier zum testen, auf dieses Phänomen (sollte es existieren) aber auch noch nie geachtet. Walter Tarpan schrieb: > Das bringt wirklich etwas? nein macht es nicht. Auf keine Fall bei einfachen Datentypen. Bei C++ mit überlanden Operatoren kann es durch aus einen unterschied machen. Demont schrieb: > Trottel weil ich vergessen habe das optimierte rein zu stellen anstelle > von dem optimiertem? Weil du anderen, die dir freiwillig und ohne Gegenleistung helfen wollen, unnötig Arbeit machst. Und weil du erstmal geschrieben hast, daß uns nicht zu interessieren hat, wofür du das brauchst und wir gefälligst deine Frage beantworten sollen. Oft (aber natürlich auch nicht immer) ergibt sich aber auch aus dem Gesamtzusammenhang eine Alternative. Algorithmisch läßt sich halt in der Regel mehr rausholen als durch Mikrooptimierungen an einzelnen if-Abfragen oder Inkrementierungen. Demont schrieb: > mir fehlen 3µS für eine Passende sync :/ > Ohne diese Abfrage geht es, mit 5 dieser If Abfragen klappt es auch > nur mit der 6 Dauert es zu lange :/ Mit welcher Taktrate läuft der µC denn? Bei den eingebauten 8 Mhz z.B. wären 3 µs ja 24 Taktzyklen. Es wäre etwas verwunderlich, wenn eine einzelne if-Abfrage mit Inkrementierung so viel brauchen würde, vor allem, wenn durch die vorherigen Abfragen eh schon alle Variablen in Registern liegen. Mehr als 3 Taktzyklen darf das eigentlich nicht brauchen, wenn's in 8 Bit gerechnet wird und die Variablen nicht grad alle volatile sind. Generell kam ja auch schon der Tipp, sich mal den generierten Assembler-Code anzuschauen. Poste den doch mal, damit man sieht, was der Compiler daraus macht. Rolf Magnus schrieb: > Poste den doch mal, damit man > sieht, was der Compiler daraus macht. Und wenn du schon am posten bist ... dann bitte gleich etwas mehr aus der Umgebung der Codestelle. Die Datentypen der Variablen, die generelle Strategie, ... eigentlich am besten alles. Was Du suchst um zu sehen wie der C-Code in Assembler aussieht ist übrigens die .lss Datei, eventuell muss man noch Aktivieren, dass die erzeugt wird. Peter II schrieb: > Walter Tarpan schrieb: >> Das bringt wirklich etwas? > > nein macht es nicht. Auf keine Fall bei einfachen Datentypen. Bei C++ > mit überlanden Operatoren kann es durch aus einen unterschied machen. Kommt auf den Compiler und die Architektur an. Und selbst wenn es nix bringt, ist es guter Stil, bewusst auf die implizite Kopie zu verzichten, auch bei POD. @Demont: Sind deine Increments um 1 so wichtig oder kannste auch in größeren Schritten erhöhen, dafür aber seltener? Rolf Magnus schrieb: > Demont schrieb: >> Trottel weil ich vergessen habe das optimierte rein zu stellen anstelle >> von dem optimiertem? > > Weil du anderen, die dir freiwillig und ohne Gegenleistung helfen > wollen, unnötig Arbeit machst. Und weil du erstmal geschrieben hast, daß > uns nicht zu interessieren hat, wofür du das brauchst und wir gefälligst > deine Frage beantworten sollen. Rolf, ist Dir nicht aufgefallen, wie viele, sonst sehr hilfsbereite, Forenbenutzer sich bei diesem Thread deutlich zurückhalten ? Warum wohl ? /IRONY ON Aber vielleicht fehlt es ja auch nur an den speziellen Kenntnissen in: Demont schrieb: > z.b. in Essabler. /IRONY OFF Oder vielleicht, weil sie immer noch auf das Asm-Listing und die immer noch "geheimen" Compilersettings warten ? Wer weiss .... ;-) Grüße Andreas Rolf Magnus schrieb: > Mit welcher Taktrate läuft der µC denn? Bei den eingebauten 8 Mhz z.B. > wären 3 µs ja 24 Taktzyklen. Er läuft mit internen 16Mhz über den Pll. ... ohne diese if anweisungen Klappt alles wunder bar. Diese If Anweisungen brauchen leider zu viel Zeit und die funktion funktioniert dadurch nicht mehr. Rolf Magnus schrieb: > Generell kam ja auch schon der Tipp, sich mal den > generierten Assembler-Code anzuschauen. Ok ich versuche die Stelle zu finden wenn ich wieder zuhause bin. Karl Heinz schrieb: > Und wenn du schon am posten bist ... dann bitte gleich etwas mehr aus > der Umgebung der Codestelle. Die Datentypen der Variablen, die generelle > Strategie, ... eigentlich am besten alles. jo 2000 Zeilen schon komprimierter und Optimierter Programmcode viel spaß. Das System habe ich Modular programmiert. Wie ich schon sagte funktioniert ALLES. Das einzige was zeitlich nicht Funktioniert ist dieser weitere Modus und das ist die einzige stelle an der ich noch Optimieren kann. Falk Schilling schrieb: > Kommt auf den Compiler und die Architektur an. Und selbst wenn es nix > bringt, ist es guter Stil, bewusst auf die implizite Kopie zu > verzichten, auch bei POD. AVR Studio 6 verwende ich Die Datei wird erstellt und ich weis auch wo diese ist, nur gestern war es schon spät, werde heute mal den Assebler code durchforsten und schauen ob ich den Passus finde. Falk Schilling schrieb: > @Demont: > Sind deine Increments um 1 so wichtig oder kannste auch in größeren > Schritten erhöhen, dafür aber seltener? Seltener geht nicht da ich immer: Phasenverschiebungsschleife// Anzahlschleife// Sende->berechne->Sende->berechne ... Diese Berechnung funktioniert bei meinen Anderen Modis hervorragen. nur hier fehlt mir ein wenig Zeit. Demont schrieb: > ... ohne diese if anweisungen Klappt alles wunder bar. Vielleicht optimiert der Compiler aber viel Code weg wenn diese Anweisungen nicht mehr da sind. D.h. es kann sein, dass diese Anweisungen nicht das Problem sind. Demont schrieb: > jo 2000 Zeilen schon komprimierter und Optimierter Programmcode viel > spaß. Man komprimiert keinen Code! Demont schrieb: > der ich noch > Optimieren kann. Betonung liegt auf 'ich'. Vielleicht können andere woanders etwas optimieren. Demont schrieb: > Karl Heinz schrieb: >> Und wenn du schon am posten bist ... dann bitte gleich etwas mehr aus >> der Umgebung der Codestelle. Die Datentypen der Variablen, die generelle >> Strategie, ... eigentlich am besten alles. > > jo 2000 Zeilen schon komprimierter und Optimierter Programmcode viel > spaß. Dann eben nicht. Es ist dein Code und wenn der so aussieht wie der Abschnitt da oben, dann wundert mich gar nichts mehr. 2000 Zeilen. Du glaubst echt, sowas schreckt mich? Ich arbeite jeden Tag mit einem Programmsystem das aus rund 2.5 Millionen Lines of Code besteht. Denkst du echt, dass mich 2000 Zeilen schrecken? Aber behalt ihn für dich. Der wird schon so aussehen, dass man ihn am liebsten in die Tonne treten möchte. :
Bearbeitet durch User
Karl Heinz schrieb: > 2000 Zeilen. Du glaubst echt, sowas schreckt mich? 2000 Zeilen "optimierter und komprimierter" Code sollten jeden schrecken... Oliver Haters gonna hate... waren ü13.000 gewesen die ich auf 6.000 runter kürzen und auf 2000 Optimiren konnte. nun genug darüber gehatet... Es ist Traurig wie eine einfache Frage so auseinander genommen werden kann ohne auch nur eine teilweiese Antwort zu geben :( Einfache frage: WENN R==128 DANN G++,B-- und das in ASM Aber bisher hat es keiner der sich posierenden Experten hinbekommen. (Karl Heinz ,lalala ,Andreas H ,Holger) Gratulation. Demont schrieb: > Einfache frage: > > WENN R==128 > DANN G++,B-- > > und das in ASM weil das der Compiler so schon gut kann, das man es selber nicht besser machen kann. Demont schrieb: > waren ü13.000 gewesen die ich auf 6.000 runter kürzen und auf 2000 > Optimiren konnte :-) Oliver schrieb: > Karl Heinz schrieb: >> 2000 Zeilen. Du glaubst echt, sowas schreckt mich? > > 2000 Zeilen "optimierter und komprimierter" Code sollten jeden > schrecken... Du hast noch nie den Code gesehen, den ich 'geerbt' habe. Seit dem schreckt mich nichts mehr :-) Demont schrieb: > Es ist Traurig wie eine einfache Frage so auseinander genommen werden > kann ohne auch nur eine teilweiese Antwort zu geben :( Traurig ist deine Lern- bzw. Beratungsresistenz. Demont schrieb: > Es ist Traurig wie eine einfache Frage so auseinander genommen werden > kann ohne auch nur eine teilweiese Antwort zu geben :( Das einzig traurige ist, dass du nicht verstehst, dass es an dieser Stelle nichts zu 'optimieren' gibt. Was willst du denn da optimieren? Einen Vergleich? Du hälts wohl Compilerbauer für komplette Vollidioten. Wenn sich was verbessern lässt, dann muss man im größeren Kontext ansetzen. Aber das willst du ja nicht. :
Bearbeitet durch User
Peter II schrieb: > weil das der Compiler so schon gut kann, das man es selber nicht besser > machen kann. Danke das ist mal eine gute Antwort ^^ Karl Heinz schrieb: > Oliver schrieb: >> Karl Heinz schrieb: >>> 2000 Zeilen. Du glaubst echt, sowas schreckt mich? >> >> 2000 Zeilen "optimierter und komprimierter" Code sollten jeden >> schrecken... > > Du hast noch nie den Code gesehen, den ich 'geerbt' habe. Seit dem > schreckt mich nichts mehr :-) SPAM Hanno schrieb: > Demont schrieb: > >> Es ist Traurig wie eine einfache Frage so auseinander genommen werden >> kann ohne auch nur eine teilweiese Antwort zu geben :( > > Traurig ist deine Lern- bzw. Beratungsresistenz. SPAM Karl Heinz schrieb: > Das einzig traurige ist, dass du nicht verstehst, dass es an dieser > Stelle nichts zu 'optimieren' gibt. Das erste Nützliche von dir. Das ist eine Aussage mit der man Arbeiten kann. Leider schon von Peter II beantwortet somit SPAM Für mich ist if (R==126) {G--;}
schon schlimm genug. Furchtbar,die Einsparung von Zeichen im Quellcode.
Bei kleinen Projekten wie diesen ist es aber iO.
Wenn der Pfosten es geschafft hätte sich mal das ASM-Listing dazu anzuschauen, wüsste er es selber das da mit ASM per Hand nichts zu holen ist. Soviel zu seiner "Code-Optimierung" der fantastillionen Zeilen... lutz h. schrieb: > Für mich ist if (R==126) {G--;} > > schon schlimm genug. Furchtbar,die Einsparung von Zeichen im Quellcode. hatte ich nur gemacht damit man den doppelten Vergleich sieht. Schreibe es sonst auch mehrzeilig. Bei einer Anweisung geht das in die gleiche Zeile, dann aber auch ohne geschweiften Codeblock. > hate hate hate
OK. Lukas
Nachdem von dir anscheinend sowieso nichts kommt, mit dem man arbeiten
könnte, um im Code das bischen noch fehlende Zeit zu finden, mach ich
dicht.
:
Bearbeitet durch User
|
|
Thread beobachten
Seitenaufteilung abschalten