wie laufzeit am genausten messen?



  • Wäre es nicht sinnvoll den Code mit "g++ -s" zu kompilieren und dann das Assembly auszuwerten. Da kann man dann doch genau zählen wie viele Schritte der Prozessor für deine Funktion benötigt.
    Dann ist egal, was dein Rechner zum Zeitpunkt der Messung noch zutun hat und mit dem richtigen Script funktioniert die Auswertung auch viel schneller.

    - so meine Theorie. Klärt mich bitte auf, wenn ich falsch liege.



  • Du liegst falsch, weil das Zählen nicht viel hilft.

    Generell gilt zwar: weniger Schritte sind besser als mehr. Aber die Schritte sind einerseits nicht gleich schnell und andererseits können moderne Prozessoren ggf. mehrere Schritte zur selben Zeit ausgeführen. Dann gibts noch so Dinge wie einen Branch-Predictor. Außerdem musst du noch schauen, welche Daten gerade im Cache sind. Kurzum: wenn du deinen Prozessor ganz exakt kennst, mag es mit viel Aufwand möglich sein, alle Effekte genau zu erkennen und den Code zu analysieren. Aber wer kennt seinen Rechner schon so exakt?

    Also ist messen die bessere Alternative.


  • Global Moderator

    Wie viele CPU-Schritte braucht denn folgender Code?

    push    rbp
            mov     rbp, rsp
            mov     DWORD PTR [rbp-4], edi
            mov     eax, DWORD PTR [rbp-4]
            imul    eax, DWORD PTR [rbp-4]
            pop     rbp
            ret
    

    Die Antwort ist nicht 7.

    (Bevor jemand fragt: Ich weiß die Antwort auch nicht (genau), ich weiß nur mit Sicherheit, dass sie nicht 7 ist.)



  • Das bringt auch nichts, weil man oft schleifen hat usw. Und Code, der alle möglichen anderen Funktionen aufruft. Wenn du Millionen von Datensätzen verarbeitest, wie willst du in Assembler erkennen, dass ein Hash Lookup viel bringen würde gegenüber einer linearen Suche?



  • SeppJ schrieb:

    Wie viele CPU-Schritte braucht denn folgender Code?

    push    rbp
            mov     rbp, rsp
            mov     DWORD PTR [rbp-4], edi
            mov     eax, DWORD PTR [rbp-4]
            imul    eax, DWORD PTR [rbp-4]
            pop     rbp
            ret
    

    Die Antwort ist nicht 7.

    (Bevor jemand fragt: Ich weiß die Antwort auch nicht (genau), ich weiß nur mit Sicherheit, dass sie nicht 7 ist.)

    Ich hab 22 bis 26 gezählt bei AMD K7 xD



  • Arcoth schrieb:

    hustbaer schrieb:

    Eine mMn. gute Variante ist die Messung so lange zu wiederholen, bis nach N (z.B. 100) Versuchen kein schnellerer Durchlauf mehr gefunden wurde als in allen Versuchen davor.

    Vom lieben Volkard, diese Methode.

    Hab ja auch gar nicht behauptet es erfunden zu haben 😃

    Ja, ich glaub ich hab das beim volkard das erste mal gesehen. IIRC hat es aber auch camper mal gepostet. Wo er es her hat weiss ich natürlich nicht, kann sein auch von volkard übernommen kann sein von woanders bzw. selbst ausgedacht.


  • Global Moderator

    Zeus schrieb:

    Ich hab 22 bis 26 gezählt bei AMD K7 xD

    Das ist ja auch noch geradezu eine einfache Architektur 😃 🙂



  • Oder nehmen wir 68K, da gibt's super einfache Zyklen Tabellen. Damit lässt sich alles exakt bestimmen. Also so lange wir nicht Shiften oder Dividieren oder ... ach, Mist 🤡



  • also unter windows gibts den performancecounter mit einer genauigkeit von (bei mir) 250 ns. das reicht normalerweise aus.
    unter linux gibts clock_gettime.

    wenn du dem prozess dann auch noch echtzeitprioritäten gibst, sollte sich die anzahl der extremen ausreißer sehr gering halten.



  • hustbaer schrieb:

    IIRC hat es aber auch camper mal gepostet.

    Und wenn ich mich recht erinnere, hat Volkard dann gefragt, ob camper es denn von ihm hat, und er meinte, das wäre möglich. Kann den Thread natürlich nicht finden.