c-code Schneller in Assembler?

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?

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:
> 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.

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

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!

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.

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.

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.

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:

> 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.

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

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.

hate hate hate

Bei einer Anweisung geht das in die gleiche Zeile, dann aber auch ohne 
geschweiften Codeblock.