AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language Delphi Schnellster Stringmatching-Algorithmus in ASM übersetzen

Schnellster Stringmatching-Algorithmus in ASM übersetzen

Offene Frage von "Sereby"
Ein Thema von alzaimar · begonnen am 5. Dez 2007 · letzter Beitrag vom 3. Jul 2008
Antwort Antwort
Seite 6 von 8   « Erste     456 78   
Dax
(Gast)

n/a Beiträge
 
#51

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 9. Dez 2007, 22:29
Hast du (falls du einen Dualcore/HT-Rechner hast) das Programm auch an eine CPU gebunden?
  Mit Zitat antworten Zitat
Amateurprofi

Registriert seit: 17. Nov 2005
Ort: Hamburg
1.076 Beiträge
 
Delphi XE2 Professional
 
#52

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 10. Dez 2007, 00:09
Zitat von Dax:
Hast du (falls du einen Dualcore/HT-Rechner hast) das Programm auch an eine CPU gebunden?
@Dax:
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)
Gruß, Klaus
Die Titanic wurde von Profis gebaut,
die Arche Noah von einem Amateur.
... Und dieser Beitrag vom Amateurprofi....
  Mit Zitat antworten Zitat
Muetze1
(Gast)

n/a Beiträge
 
#53

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 10. Dez 2007, 01:15
Zitat von Amateurprofi:
(Warum bei DualCore/QuadCore-Rechnern kein "globaler" TSC verfügbar ist, ist mir schleierhaft)
Wie du selber wohl weisst, wird der TSC mit jedem Takt um eins erhöht. Durch diesen Fakt wird der TSC gerne genutzt, um die Taktrate des Kerns zu ermitteln. Und bei einem Quad- bzw. DualCore kann jeder Kern mit einem eigenen Takt betrieben werden bzw. zum energiesparen herunter getaktet werden. Welcher Takt zählt denn nun bei einem globalen TSC? Der TSC ist bisher in den Cores und somit tritt überhaupt das Problem auf. Deine Lösung/Vorschlag ist auch nicht 100%ig umsetzbar bzw. nachvollziehbar.
  Mit Zitat antworten Zitat
Amateurprofi

Registriert seit: 17. Nov 2005
Ort: Hamburg
1.076 Beiträge
 
Delphi XE2 Professional
 
#54

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 10. Dez 2007, 01:29
Zitat von Muetze1:
Zitat von Amateurprofi:
(Warum bei DualCore/QuadCore-Rechnern kein "globaler" TSC verfügbar ist, ist mir schleierhaft)
Wie du selber wohl weisst, wird der TSC mit jedem Takt um eins erhöht. Durch diesen Fakt wird der TSC gerne genutzt, um die Taktrate des Kerns zu ermitteln. Und bei einem Quad- bzw. DualCore kann jeder Kern mit einem eigenen Takt betrieben werden bzw. zum energiesparen herunter getaktet werden. Welcher Takt zählt denn nun bei einem globalen TSC? Der TSC ist bisher in den Cores und somit tritt überhaupt das Problem auf. Deine Lösung/Vorschlag ist auch nicht 100%ig umsetzbar bzw. nachvollziehbar.
Ja, da bin ich wohl zu kurz gehopst, über die variable Taktrate der einzelnen Kerne habe ich nicht nachgedacht.
Gruß, Klaus
Die Titanic wurde von Profis gebaut,
die Arche Noah von einem Amateur.
... Und dieser Beitrag vom Amateurprofi....
  Mit Zitat antworten Zitat
OlafSt

Registriert seit: 2. Mär 2007
Ort: Hamburg
284 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#55

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 10. Dez 2007, 11:24
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:
   queryperformancecounter(qpc);
   sleep(2000);
   queryperformancecounter(qpc1);
Und dies für die anderen Meßmethoden genauso.
  Mit Zitat antworten Zitat
Amateurprofi

Registriert seit: 17. Nov 2005
Ort: Hamburg
1.076 Beiträge
 
Delphi XE2 Professional
 
#56

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 10. Dez 2007, 16:51
Zitat von OlafSt:

@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:
   queryperformancecounter(qpc);
   sleep(2000);
   queryperformancecounter(qpc1);
Und dies für die anderen Meßmethoden genauso.
@OlafSt:
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)......
Gruß, Klaus
Die Titanic wurde von Profis gebaut,
die Arche Noah von einem Amateur.
... Und dieser Beitrag vom Amateurprofi....
  Mit Zitat antworten Zitat
Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#57

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 11. Dez 2007, 12:11
Delphi-Quellcode:
   queryperformancecounter(qpc);
   tsc:=timestamp;
   tick:=GetTickCount;
   sleep(2000);
   queryperformancecounter(qpc1);
   tsc1:=timestamp;
   tick1:=GetTickCount;
so wäre es besser. Der Meßfehler von GetTickCount(), TimeStamp und QPC nivelliert sich so ein bischen, relativ zueinander gesehen.
Einzelmessungen der art

Delphi-Quellcode:
   queryperformancecounter(qpc);
   sleep(2000);
   queryperformancecounter(qpc1);

   tsc:=timestamp;
   sleep(2000);
   tsc1:=timestamp;

   tick:=GetTickCount;
   sleep(2000);
   tick1:=GetTickCount;
wären dagegen falsch. Der Aufrufoverhead jeder Funktion verursacht einen wesentlich kleineren Meßfehler als das Sleep(2000). Dieses kann +-20ms bedeuten.

Noch besser ist es so:

Delphi-Quellcode:
   sleep(0);
   queryperformancecounter(qpc);
   tsc:=timestamp;
   tick:=GetTickCount;
   sleep(2000);
   queryperformancecounter(qpc1);
   tsc1:=timestamp;
   tick1:=GetTickCount;
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.

Gruß Hagen
  Mit Zitat antworten Zitat
Amateurprofi

Registriert seit: 17. Nov 2005
Ort: Hamburg
1.076 Beiträge
 
Delphi XE2 Professional
 
#58

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 11. Dez 2007, 14:37
@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......
Gruß, Klaus
Die Titanic wurde von Profis gebaut,
die Arche Noah von einem Amateur.
... Und dieser Beitrag vom Amateurprofi....
  Mit Zitat antworten Zitat
Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#59

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 11. Dez 2007, 18:05
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
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.122 Beiträge
 
Delphi 12 Athens
 
#60

Re: Schnellster Stringmatching-Algorithmus in ASM übersetzen

  Alt 11. Dez 2007, 18:22
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.


[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:
Start = Uhrzeit_in_Deutschland
5 Minuten Warten
Dauer = Uhrzeit_in_Japan - Uhrzeit_in_Deutschland
Dauer wird da bestimmt nichtmal annähernd 5 Minuten ergeben
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PosEx im Delphi viel seltener praktiziert.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:52 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