Schnelles Vergleichen von BYTE-Variablen
-
@WhiteWolf sagte in Schnelles Vergleichen von BYTE-Variablen:
Bei Gleichheit wird es vorerst mit der WinAPI-Funktion TextOut() auf ein Fenster geschrieben. Bei Ungleichheit nicht.
Moment mal, kann es sein, dass es ein Problem ist, da diese Vergleiche bei jedem Neuzeichnen durchgeführt werden müssen? Evtl. ist dann double buffering schon die Lösung / (edit: bzw. alles zu speichern, was für die Ausgabe benötigt wird).
Bei weniger als 15.000 Tagen (nehme ich durch 1980 einfach mal an) sollten diese einzelnen Vergleiche, sofern sie einmalig durchgeführt werden, nicht ins Gewicht fallen.
Und wenn die alten Daten immer gleich bleiben und nur ein paar neue hinzukommen, könnte man diese alten evtl. auch geschickter speichern (neben anderen Werten,).
-
Jetzt muss ich nochmal auf MMX zurückkommen. Ist der Ablauf den ich weiter oben genannt habe richtig? Wenn ich jedes Element im Ergebnis mit einer if-Abfrage testen muß, dann ist die Beschleunigung ja wieder dahin.
-
@WhiteWolf sagte in Schnelles Vergleichen von BYTE-Variablen:
vector<CWeekday*>Tu als erstes mal die wahrscheinlich sinnlose Indirektion weg.
-
Jetzt muss ich aber nochmal auf MMX zurückkommen. Ist der Ablauf den ich weiter oben gennant habe korrekt? Wenn ich jedes Element in mResult mit einer if-Abfrage testen muss, ist die Beschleunigung ja wieder dahin.
-
@Swordfish
Also Stack-Objekte in den Vector schieben?
-
@WhiteWolf sagte in Schnelles Vergleichen von BYTE-Variablen:
Stack-Objekte
ich weiß nicht was das ist, aber ich meine den
*in@WhiteWolf sagte in Schnelles Vergleichen von BYTE-Variablen:
Stack-Objekte
ich weiß nicht was das ist, aber ich meine den Stern in
@WhiteWolf sagte in Schnelles Vergleichen von BYTE-Variablen:
vector<CWeekday*>wegmachen.
@WhiteWolf sagte in Schnelles Vergleichen von BYTE-Variablen:
Weekdays in 7er-Blöcken
habe ich nicht wirklich kapiert. Vielleicht zeigst du mal den vollständigen (funktionierenden) Code der Dir zu langsam ist.
-
@WhiteWolf: wie schon weiter oben vorgeschlagen wurde, könntest Du entweder das Ergebnis der Auswertung oder besser noch die fertige statistische Auswertung speichern. Dann brauchst Du nur noch den täglichen Schritt zu berechnen. Überlasse ansonsten erst mal dem Compiler die Optimierung auf die Fähigkeiten Deiner CPU. Schau Dir den ASM-Code an, den der Compiler bei verschiedenen Optimierungs-Stufen ausspuckt!
-
@WhiteWolf der Vector wird als dynamische Datenstruktur die Objekte wohl auch auf dem Heap speichern. Aber er kann die Objekte auch direkt verwalten. Es gibt eigentlich keinen Grund dafür die Objekte selbst zu verwalten und nur einen Pointer in dem Vektor zu speichern.
-
@WhiteWolf
Wie ist die Zeitkomplexität deines Algos? O(n^3)?Wenn du eine Funktion CompareBytes() oder operator=() schreibst, wie oft wird diese aufgerufen? Und wie oft wird diese Funktion unnütz aufgerufen, weil du am Tag zuvor beispielsweise die Bytes miteinander verglichen hast und die verantwortlichen Objekte sich nicht änderten?
-
Wir hatten hier vor einer Weile mal eine ähnliche Diskussion, und das Ergebnis war, das niemand zeigen konnte, das sowas wie MMX und darüber nötig ist um die gesamte verfügbare Speicherbreite auszunutzen selbst bei langem linearem Speichervergleich. In meinen Messungen war schon von 16Bit Schritten auf 32 Bit kaum ein Unterschied zu sehen. Je kleiner die zusammenhängenen Speicherbereiche der Bytes sind um so langsamer wird es, weil der Speicherzugriff weniger effizient ist.
Also Praxistipp, die vergleichenden Bytes linear im Speicher hintereinander anordenen zu möglichst wenigen grossen Blöcken und dann einfach irgendwie sinnvoll vergleichen wie z.b. durch memcmp. Darüber hinaus sind nur noch wenige Prozente drin, aber alles was nicht im Block liegt, ist Größenordnungen langsamer.
-
@WhiteWolf sagte in Schnelles Vergleichen von BYTE-Variablen:
MMX
Was willst Du mit MMX? Das ist doch nur im 32-Bit-Modus heutiger Betriebssysteme zugänglich.
Im 64-Bit-Modus sollte man SSE verwenden.
