3. Optimierung, Templates

Optimierung, Templates

  • C

    hustbaer schrieb:

    @CStoll:
    MSVC's std::string hat nen eingebauten Puffer ("SSO") für IIRC 16 Character (oder 16 Bytes? - egal, in dem Fall das selbe).
    Der String von cooky ist ausreichend kurz -> booyah 🙂

    MSVC's schlimmste Bremse, der relativ langsame Heap, kommt dadurch nicht zum Zuge.

    EDIT: Alles Blödsinn. Hier wird ja sowieso nix kopiert, bloss die Länge auf furchtbar komplizierte Art und Weise ausgerechnet. Und die CLOCKS_PER_SEC Sache muss erstmal bereinigt werden, bevor man irgendwas vergleichen kann.
    Eigentlich müsste MSVC hier langsamer sein, wegen der ollen Checked-Iterators.

    Wow! Tatsache, MSVC macht von "123456789abcdef" auf "123456789abcdefZ" einen Sprung von 543 auf 25545 ms! Den GCC interessiert das gar nicht. Schon lustig, wie unterschiedlich gut die Compiler optimieren.

    Edit:
    Dein Edit war wohl nix. :p

    hustbaer schrieb:

    Du kannst std::clock() Differenzen verschiedener Compiler nicht unbedingt miteinander vergleichen.

    Ist mir schon bewusst, ich habe nur noch nie erlebt, dass clock() unter Windows etwas anderes als ms zurückgegeben hat (wie auch hier). Ist natürlich trotzdem nicht ganz korrekt, aber ist ja auch nur dreckiger Testcode. 🙂

    0

  • OK, alles zurück, DA wird ja doch kopiert

    int bar(std::string::const_iterator begin, 
   std::string::const_iterator end) 
 { 
   int b = 0; 
   for (int i = 0; i < 25000000; ++i) 
     b += foo(std::string(begin, end));  // <------ DAAAAAAA :)
   return b; 
 }
    0

  • cooky451 schrieb:

    Wow! Tatsache, MSVC macht von "123456789abcdef" auf "123456789abcdefZ" einen Sprung von 543 auf 25545 ms! Den GCC interessiert das gar nicht. Schon lustig, wie unterschiedlich gut die Compiler optimieren.

    Was hat das mit Optimieren zu tun 😕
    Tu mal bei MSVC die Checked Iterator Dingens deaktivieren. Mach mal ein

    #define _SECURE_SCL 0

    in dein Precompiled-Header File rein (stdafx.h), oder falls du keins verwendest, eben irgendwo wo es vor allem anderen steht, und für alle .cpp Files gilt.

    Und dann vergleich nochmal.

    0
  • C

    hustbaer schrieb:

    Und dann vergleich nochmal.

    Kein Unterschied. Hätte mich jetzt auch etwas überrascht, es werden doch überall Iteratoren verwendet?

    hustbaer schrieb:

    Was hat das mit Optimieren zu tun 😕

    Na ja, dass std::pair<> viel schneller als std::pair<> const& ist, finde ich schon komisch. Ich hätte erwartet, dass dem Compiler das egal ist.

    0

  • Das sollte einen Unterschied machen, gerade WEIL Iteratoren verwendet werden.

    Und nochwas: die Aufslöung von clock() mag 1 msec sein, aber die Genauigkeit von clock() ist auf Windows Systemen üblicherweise max. 15~17 msec.
    D.h. ein Unterschied von 1 vs. 17 oder 20 sagt ... nicht sehr viel bis gar nix.

    -> QueryPerformanceCounter

    EDIT:
    Und dann ist der ganze Test eigentlich sowieso Schmarrn, denn bis auf den Aufruf von "foo", wo der String kopiert werden muss, sollte ein guter Compiler das sowieso alles zu (fast) Nichts optimieren.

    0
  • C

    hustbaer schrieb:

    Und dann ist der ganze Test eigentlich sowieso Schmarrn, denn bis auf den Aufruf von "foo", wo der String kopiert werden muss, sollte ein guter Compiler das sowieso alles zu (fast) Nichts optimieren.

    Hatte ich auch erwartet, ist aber wohl nicht der Fall. Bzw. der GCC macht das. VS aber nicht. Wenn man ihn bis 429496729 iterieren lässt, braucht pair<> immer noch 1ms, die anderen drei Version ~244ms. Nimmt man übertriebenderweise mal 4294967295U, braucht VS für alles 0 Sekunden, außer für "direct", da braucht er 3680ms. Der GCC optimiert weiterhin alles völlig weg. Ich versteh das nicht, also vor allem nicht, was VS da veranstaltet.

    (Der eigentliche Ziel war ja eh nur std::string, aber irgendwie interessiert mich das jetzt..)

    0
  • C

    cooky451 schrieb:

    Nimmt man übertriebenderweise mal 4294967295U, braucht VS für alles 0 Sekunden, außer für "direct", da braucht er 3680ms.

    Dafür hast du hoffentlich den Typ der Schleifenvariable korrigiert.

    Ich versteh das nicht, also vor allem nicht, was VS da veranstaltet.

    Wenn du ein wenig tiefer in die Materie einsteigen willst, schau dir doch mal den Maschinen/Assembler-Code an, den die Compiler hinten ausspucken.

    0
  • C

    CStoll schrieb:

    Dafür hast du hoffentlich den Typ der Schleifenvariable korrigiert.

    Latürnich! 🙂

    CStoll schrieb:

    Wenn du ein wenig tiefer in die Materie einsteigen willst, schau dir doch mal den Maschinen/Assembler-Code an, den die Compiler hinten ausspucken.

    Nun ja, wie geahnt baut der Compiler außer bei der pair<> Version noch echte Schleifen ein. Bei 4294967295U sind sie dann (außer bei direct) aber weg. Ich frage mich nur, warum er das macht. (Also warum er zwei Schleifen bei 429496729 drin lässt.)

    0

  • Hihi, OK, hast Recht, das ist einigermassen Schräg.
    Ich kann dir auch nicht beantworten was da abgeht.

    0
Anmelden zum Antworten