Geschwindigkeit von Vergleichsoperationen
-
Also wenn man an solch einer Stelle optimieren will dann ist an einer anderen etwas gehörig schief gelaufen!
-
Ich behaupte mal, dass beide Methoden gleich schnell sind.
Zumindest denke ich, dass der Compiler so schlau ist, um aus
!( ro1.y < r2.y + r2.h )
das hier
ro1.y >= r2.y + r2.h
zu machen.Aber wenn Du wirklich Deine Anwendung optimieren möchtest, dann solltest du an anderen Stellen suchen. Sollte der Compiler das nicht wegoptimieren (was ich nicht glaube), dann würde die 2. Methode schneller sein, da hier ja das Negieren wegfallen würde.
-
Das ist Unsinn. Es gibt für beide Möglichkeiten die passenden jmp-Befehle:
jge (jump if greater equal)
jlt (jupm if less than)die brauchen genau gleich lange.
MfG Jester
-
kingruedis argument zaehlt: der compiler wird das if-kontrukt eh optimieren
-
ich wollte nur die Falschaussage das eine sei ohne Optimierung schneller, weil die Negation nicht durchgeführt wird nicht einfach so stehen lassen.
Ehrlich gesagt habe ich mir über solche Probleme nie Gedanken gemacht.MfG Jester
-
Warum ist das eine Falschaussage? Es ist doch ohne weiteres denkbar, dass für beide Ausdrücke unterschiedlicher Code generiert wird. Der Compiler müsste schon schlau genug sein, !(a<b) im Syntaxbaum oder Zwischencode zu a>=b umzuschreiben. Alle ernsthaften Compiler beherrschen das zwar, aber von selbst kommt das nicht.
-
Jester schrieb:
Das ist Unsinn. Es gibt für beide Möglichkeiten die passenden jmp-Befehle:
jge (jump if greater equal)
jlt (jupm if less than)die brauchen genau gleich lange.
MfG Jester
nichts anderes habe ich ausdrücken wollen.
Nur !(... < ...) wären doch (rein theoretisch und ohne Optimierung) 2 Befehle, oder nicht?
Dass der Compiler daraus so oder so >= machen wird, ist mir auch klar.Korbinian schrieb:
kingruedis argument zaehlt: der compiler wird das if-kontrukt eh optimieren
kingruedis argument ???
-
Es gibt auch noch so Sachen wie jnge (jump if not greater or equal).
Es gibt sozusagen jede Menge von den Teilen.MfG Jester
-
kingruedi schrieb:
die machen keinen Sinn, weil das
1. vom Compiler abhängt (und den benutzen Compiler Flags) und dem restlichen Code
ich implizierte damit die optimierung (z.b. -O flags beim gcc)
-
lol, hät ich nicht gedacht, dass es sowas gibt
hab assembler aufm Motorola 68k gelernt, da gabs sowat feines nicht
Obwohl das wohl auch nur vom verwendetem Assembler abhänigig ist, da der erzeugte Maschinencode von "jnge" und "jlt" ja letzt endlich der gleiche bleibt.