Speed, Speed, SPEEEED!!!
-
memcmp ist schneller als strcmp - warum, dürfte klar sein.
Nein ist nicht klar, Beweise bitte.
-
*mist*
-
Abgesehen davon ist der Vergleich von compare und op== irgendwie so wie mit den Äpfeln und den Birnen. Compare muß sich auch jedes Zeichen anschauen, auch wenn beide verschieden lang sind.
-
Bashar schrieb:
memcmp ist schneller als strcmp - warum, dürfte klar sein.
Nein ist nicht klar, Beweise bitte.
strcmp muss sowohl für a als auch für b auf 0 testen während memcmp das alignement ausnützen kann und nur einen int testen muss.
der vorteil heirbei ist: das alignment. memcmp kann auf Intel Architekturen mit 4 Byte Blöcken arbeiten, strcmp kann es nicht. das ist auch der grund warum strcpy langsamer als memcpy ist.
OK, Beweisen kann ich es nicht, weil mem* kein Alignment ausnutzen müssen - ich gehe einfach von einer idealen Implementierung aus.
-
Gewonnen. Meine ersten Tests waren etwas unausgereift. Neueste Ergebnisse:
memcmp 3.81 s
strcmp 5.78 s
std::string 4.56 s(Es wird 50 Millionen mal "Hallo Welt!" mit einem String gleichen Inhalts verglichen, das Ergebnis des Vergleichs jeweils einer volatile bool-Variablen zugewiesen, g++-3.2.2 mit -O Flag)
-
Bashar schrieb:
Gewonnen.
:p
Ich habe früher sehr viel solcher minimal Optimierungen gemacht, bis ich irgendwann kapiert habe, dass ich mit einem besseren Algorithmus wesentlich mehr rausholen lässt, also mit solchen Optimierungen.
-
Vielleicht erzählst du mal WAS für ein Programm du schreiben willst, für das du so ewig viel Speed brauchst.
Ohne das zu wissen ist es blödsinn darüber zu blabbeln was schneller oder weniger schnell ist.
Und wie eben schon gesagt : Ein bessere Algorithmus ist wesentlich schneller als die kleinen Codeoptimierungen.
-
TeeJay schrieb:
Vielleicht erzählst du mal WAS für ein Programm du schreiben willst, für das du so ewig viel Speed brauchst.
Mein Tipp eine Computerspiel oder eine 3d Engine
SCNR
-
Hi,
selbst da liegt der Bottleneck beim Rendern, bei der Physik/KI und der dazugehörigen Mathematik (dieser Teil sollte sehr gut optimiert sein, evtl. sogar pur in Assembler mit zuhilfenahme von MMX/3D Now geschrieben werden!).
Aber bestimmt nicht bei so trivialen Dingen wie Stringvergleich oder auch z.B. Einsatz von Exceptions oder RTTI. Mag ja sein, dass Exceptions 5% Overhead bringen, aber die CPU muss wahrscheinlich sowieso mit dem Rendern auf die GPU warten, also was soll's...
ChrisM
-
Shade Of Mine schrieb:
bei der for schleife ist signed auf Intel Architekturen bedeutend schneller als unsigned
Wieso soll der increment bei signed bedeutend schneller sein? Oder meinst du den Vergleich? Ich glaube nicht, dass das so viel ausmacht.
-
Hi,
ich nehme für Schleifen grundsätzlich unsigned long und hatte noch nie Performanceprobleme.
ChrisM
-
MaSTaH schrieb:
Wieso soll der increment bei signed bedeutend schneller sein? Oder meinst du den Vergleich? Ich glaube nicht, dass das so viel ausmacht.
Sorry, mein Fehler. Ich hab signed geschrieben, aber unsigned gemeint.
Siehe "AMD Athlon(tm) Processor - x86 Code Optimization Guide"