Geschwindigkeit von Vergleichsoperationen
-
Ich schreibe gerade an einer Kollisionserkennung und da kam bei mir die Frage auf, was schneller ist. 1 oder 2. Ich würde ja auf erstens tippen, habe aber ehrlich gesagt keine Ahnung.
if ( ro1.y > r1.y && !( ro1.y < r2.y + r2.h ) ) .....if ( ro1.y > r1.y && ro1.y >= r2.y + r2.h ) .....
-
Probiers aus, aber ich behaupte, dass es keine Unterschiede gibt.
-
Regel:
Fragen die mit "Was ist schneller" anfangen oder sich darauf reduzieren lassen, machen idr. wenig Sinn.
-
Wieso machen die keinen Sinn?
Ich möchte es doch halt Wissen, daß ist doch der Sinn der Frage.Oder meinst du, weil das keiner weiß?
-
Die machen keinen Sinn, weil du in der Zeit, in der du hier Fragst schon längst selbst herausgefunden haben könntest, was schneller ist. Wir schreiben sowieso keine Tests für dich.
-
Ja, meine Güte. Hat ja keiner verlangt.
Aber, wenn es eben einer weiß, weil er es zum Bsp. schonmal probiert oder es irgendwo gelesen, gelernt dann kann ich mir das ja sparen und einfach die Antwort nehmen.
Ansonsten teste ich das mir schon selber aus, irgendwann, wenn Zeit ist.
-
Natürlich. Wir haben hier alle jedes erdenkliche Problem in jeglicher Variation auf geschwindigkeit überprüft. Wir sind besser als jeder Profiler. Wir müsse uns nur mal kurz den Code angucken. Dann sagen wir: "So hab ich's auch mal versucht. Allerdings habe ich 10(9999999) verschiedene andere Lösungen gefunden, die schneller waren."
-
die machen keinen Sinn, weil das
1. vom Compiler abhängt (und den benutzen Compiler Flags) und dem restlichen Code
2. ist das nicht der richtige Weg ein Programm zu optimieren
3. kannst du die Frage dir selber am schnellsten beantworten, wenn du es doch für nötig hälst an der Stelle zu optimieren
-
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.