3. Speed, Speed, SPEEEED!!!

Speed, Speed, SPEEEED!!!

  • R

    @Mastha
    auf welcher basis triffst du die Aussagen über die Geschwindigkeit zB. das mit strcmp? Hast du eine Zauber-Kugel? Hast du das an deiner C++-Implementierung gemessen? Oder einfach mal geratten?

    0
  • S

    string s("hallo");
    string s2("test");

    if(s==s2)
    dürfte signifikant schneller sein als
    if(!strcmp("hallo", "test"))

    bei der for schleife ist signed auf Intel Architekturen bedeutend schneller als unsigned

    also bitte:

    1. auf sowas nicht so antworten - sondern so wie ich und kingruedi und Maxi
    2. keinen blödsinn verzapfen
    0
  • J

    Shade Of Mine schrieb:

    string s("hallo");
    string s2("test");

    if(s==s2)
    dürfte signifikant schneller sein als
    if(!strcmp("hallo", "test"))

    Warum das?

    0
  • S

    Jester schrieb:

    Shade Of Mine schrieb:

    string s("hallo");
    string s2("test");

    if(s==s2)
    dürfte signifikant schneller sein als
    if(!strcmp("hallo", "test"))

    Warum das?

    Ein string kennt seine Länge, ich implementiere den op== somit so:

    bool operator==(string const& a, string const& b)
{
  return a.size()==b.size() && !memcmp(a.value, b.value, a.size());
}

    also in meinem beispiel wird nur ein int vergleich durchgeführt.
    und memcmp ist schneller als strcmp - warum, dürfte klar sein.

    0
  • J

    Shade Of Mine schrieb:

    Vielleicht solltest du erstmal das Programm fertigstellen und dich dann erst mit Optimierung befassen. 'Premature Optimization is the root of all evil'

    'on the other hand we cannot ignore efficiency' 😃

    0
  • J

    Also meine STL-Implementierung macht da aber nicht memcmp, sondern geht über die char_traits<char>::compare. Und da wird jedes für sich verglichen.

    Aber die bekannte Länge ist sicher ein Vorteil.

    0
  • B

    memcmp ist schneller als strcmp - warum, dürfte klar sein.

    Nein ist nicht klar, Beweise bitte.

    0
  • B

    *mist*

    0
  • J

    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.

    0
  • S

    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.

    0
  • B

    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)

    0
  • S

    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.

    0
  • T

    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.

    0
  • R

    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

    0
  • C

    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

    0
  • W

    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.

    0
  • C

    Hi,

    ich nehme für Schleifen grundsätzlich unsigned long und hatte noch nie Performanceprobleme. 😉

    ChrisM

    0
  • S

    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"

    0
Anmelden zum Antworten