Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
Hast du (falls du einen Dualcore/HT-Rechner hast) das Programm auch an eine CPU gebunden?
|
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
Zitat:
Ich habe keinen DualCore Recher, aber ich bin mir der Problematik, die negaH in diesem Beitrag beschrieben hat, bewußt. Das Problem DualCore betrifft m.W. nicht nur den direkten Zugriff auf den TSC ( mit RDTSC ) sondern auch QPC. Wer also Performancemessungen mit hoher Präzision auf DualCore-Rechnern durchführen will, muß sich Gedanken machen, wie er das Problem löst. (Warum bei DualCore/QuadCore-Rechnern kein "globaler" TSC verfügbar ist, ist mir schleierhaft) |
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
Zitat:
|
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
Zitat:
|
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
Allerdings muß man dazu sagen, das sich die Problematik mit den verschiedenen TSC in den Cores eigentlich nicht mehr stellt. Zum einen gibt es von M$ bereits einen Fix zu diesem Thema (damals flippten verschiedene Games eben wegen dieser doppelten TSC's aus) - ich hab das nicht analysiert, mich würde es aber nicht wundern, wenn M$ die API-Routinen für QPC auf Core 0 (der immer existiert) lenkt.
Zum zweiten kann man auch dafür sorgen, das das Meßprogramm nur auf einem Core läuft. @amateurprofi: Die Routine "test2" zum Beweis der differenz zwischen QPC und TSC würde ich nochmal genauer beäugen. Bei der QPC-Messung mißt du sämtlichen Laufzeit-Overhead von GetTickCount z.B. mit. Kein Wunder, das sich hier Differenzen auftun. Besser wäre:
Delphi-Quellcode:
Und dies für die anderen Meßmethoden genauso.
queryperformancecounter(qpc);
sleep(2000); queryperformancecounter(qpc1); |
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
Zitat:
Welche Unterschiede würdest du denn da erwarten ? Hast du das denn mal ausprobiert ? Der "sämtliche Laufzeit-Overhead von GetTickCount" beträgt ganze 12 CPU-Ticks. Glaubst du enrsthaft, diese 12 Ticks verfälschen die Differenz wenn QPC im MHz-Bereich und TSC im GHz-Bereich tickt. Ich würde das noch mal genauer beäugen (deine Worte)...... |
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
Delphi-Quellcode:
so wäre es besser. Der Meßfehler von GetTickCount(), TimeStamp und QPC nivelliert sich so ein bischen, relativ zueinander gesehen.
queryperformancecounter(qpc);
tsc:=timestamp; tick:=GetTickCount; sleep(2000); queryperformancecounter(qpc1); tsc1:=timestamp; tick1:=GetTickCount; Einzelmessungen der art
Delphi-Quellcode:
wären dagegen falsch. Der Aufrufoverhead jeder Funktion verursacht einen wesentlich kleineren Meßfehler als das Sleep(2000). Dieses kann +-20ms bedeuten.
queryperformancecounter(qpc);
sleep(2000); queryperformancecounter(qpc1); tsc:=timestamp; sleep(2000); tsc1:=timestamp; tick:=GetTickCount; sleep(2000); tick1:=GetTickCount; Noch besser ist es so:
Delphi-Quellcode:
Das Sleep(0) "erzwingt" einen anstehenden Task/Threadswitch und so reduziert sich die Wahrscheinlichkeit drastisch das innerhalb den nachfolgenden drei Funktionsaufrufen dieser anstehende Switch durchgeführt wird. Dieser würde dann dafür sorgen das die Messung komplett untauglich ist.
sleep(0);
queryperformancecounter(qpc); tsc:=timestamp; tick:=GetTickCount; sleep(2000); queryperformancecounter(qpc1); tsc1:=timestamp; tick1:=GetTickCount; Gruß Hagen |
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
@negaH:
Hagen, jetzt auch noch du ? Es ging nicht darum, zu prüfen, ob der TSC einige Ticks/s mehr bringt als der QPC sondern er ging darum, aufzuzeigen, daß QPC im einstelligen MegaHertz-Bereich tickt, TSC aber im einstelligen GigaHertz Bereich. In diesem Zusammenhang ist die Anordung völlig irrelevant. Und glaube mir, ich habe mir schon Gedanken gemacht, in welcher Reihenfolge ich die verschiedenen Counter aufrufe. Was bewirkt meine Anordung ?! 1) Für QPC wird das Ergebnis etwas begünstigt. 2) TSC (mein Kandidat) wird etwas benachteiligt. Genau diese unsinnige Diskussion, die jetzt aufkam, wollte ich damit vermeiden...... |
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
Naja, das kannst du einfacher haben, einfach QueryPerformanceFrequency() aufrufen und in einer MessageBox anzeigen, zb. in MHz. Dann aus der Registry die Taktfrequenz der Cores auslesen und ebenfalls anzeigen. Der QPC sollte um die 3.6MHz anzeigen, so wars bei mir bisher.
Allerdings, und das ist entscheidend, sagt dies nichts darüber aus woher der QPC seine Zeitbasis nimmt. Es könnte auch der Timestamp sein den das OS runterskaliert auf 3.6Mhz. Auf meinem Laptop läuft der TSC im Verhältnis synchon zum QPC, und das auch wenn ich per APC die Prozessoren manuell verlangsamme. Ergo: QPC bezieht seine Timebasis aus dem Timestamp und wird skaliert. Hm :) und nun fragt sich welche der beiden Diskussionen ist flüssiger als Luft ? Ich wollte nur aufzeigen wie man die besten Meßresultate erreicht unabhängig davon was man damit später macht :) Gruß Hagen |
Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen
ich will auch ... ich will auch ...
Bei mir läuft der TSC ja mit'm Prozessortakt und was dabei ganz nett ist ... mein Prozessor ist dynamisch getacktet (hohe CPU-Auslastung = hohe Taktfrequenz und niedrige CPU-Auslastung = kleine Taktfrequenz). Und jetzt rate mal was der TSC da für einen "Mist" messen kann, wenn sich die TSC-Frequenz ständig ändert. :zwinker: [add] Ach ja und noch mehr Spaß hast du auf Multiprozessorsystemen. Standardmäßig legst du ja nicht fest auf welchem Prozessor dein Programm laufen soll, also kann es sein daß der Startwert auf Einer und der Endwert auf einer anderen CPU gemessen wird. Jede CPU hat ja (war doch so?) ihren eigenen TSC und somit ihre eigene Zeit. Es könnte also sozusagen passieren das die Differenz aus zwei verschiedenen Uhren errechnet wird.
Code:
Dauer wird da bestimmt nichtmal annähernd 5 Minuten ergeben
Start = Uhrzeit_in_Deutschland
5 Minuten Warten Dauer = Uhrzeit_in_Japan - Uhrzeit_in_Deutschland |
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz