Schnelles Vergleichen von BYTE-Variablen



  • Was willst du genau erreichen? Was ist bei dir ein BYTE? Warum eine Intel Befehlserweiterung aus den 90ern?

    Implementier wie es am besten verständlich ist und guck was der Compiler raus macht. Wenn das nicht reicht, guck nach Optimierungen 😉



  • Das Codebeispiel triftt noch nicht ganz das Original, sollte aber reichen. Das Programm läuft einwandfrei nur wird es durch
    die vielen Vergleiche immer langsamer. Jeden Tag wird es ein BYTE mehr. Ich muss alle bVars auswerten und statistisch
    verarbeiten.

    Es muss nicht MMX sein, das ist ja meine Frage. Welche Möglichkeiten gibt es noch?



  • @WhiteWolf

    sollte aber reichen

    Dann noch viel Spaß mit deinem Problem...



  • was willst du denn überhaupt vergleichen bzw. was soll der vergleich bringen? ein minimum oder maximum? wenn ja: speichere das maximum doch und vergleich den neuen wert damit.



  • @Schlangenmensch
    Welche Sorte Optimierungen könnte man da vorschlagen?
    Nebenbei: Ein BYTE ist bei mir ein Speicherbereich der Platz für Werte zwischen entweder -127 bis 128 oder 0 bis 256 bereitstellt.

    @manni66
    Vielen Dank für die Ermutigung!

    @Wade1234
    Nein ist kein minimum/maximum. Eine der Auswertungen listet Objekte mit gleichen bVars auf.

    @Alle

    Mein Problem mit MMX ist folgendes:

    __m64 mMMXArray1 = _mm_set_pi8(Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Samstag, Sonntag, 0);
    __m64 mMMXArray2 = _mm_set_pi8(Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Samstag, Sonntag, 0);
    
    __m64 mResult = _mm_cmpeq_pi8(_mMMXArray1, _mMMXArray2);
    

    Dann hab ich in mResult sowas oder?

    00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111

    Dann brauch ich ja hinterher trotzdem eine if-Abfrage für jedes Element?
    Oder hab ich was übersehen?



  • Was passiert denn bei Gleichheit?

    Manni fragt nach dem richtigen Code, weil du in deinem abgewandelten Beispiel halt in der Schleife einfach immer den gleichen Vergleich machst.

    Edit: ich schlage vor, sauberen Code zu schreiben, den Compiler die Optimierungen machen zu lassen und wenn das nicht reicht über eine Parallelisierung nachzudenken. (evt. mit openMP)



  • Du hast recht, irgendwas übersieht man immer. Das muss natürlich so aussehen:

    for(iter1980 = vec1980.begin(); iter != vec1980.end(); ++iter)
       for(UNIT uiIndex = 0; uiIndex < 7; ++uiIndex)
         {...}
    

    Bei Gleichheit wird es vorerst mit der WinAPI-Funktion TextOut() auf ein Fenster geschrieben. Bei Ungleichheit nicht.

    OpenMP? Eine Threading-Library? Einen zweiten Thread zur Berechnung hat das Programm schon. Aber ich werd da mal weiter drüber nachdenken.



  • @WhiteWolf und was willst du damit insgesamt feststellen? ob der wert schonmal vorhanden war, wann der wert schonmal vorhanden war, wie oft der wert schonmal vorhanden war? in diesem fall hast du - sofern ich mich nicht irre - etwa 256 möglichkeiten durchzuprüfen und das sollte ein 286er locker in hinnehmbarer zeit schaffen.



  • Ausgabe ist halt auch immer teuer.

    Ich glaube nicht, dass du mit manuellem direkten Aufruf von speziellen Chipsatzbefehlen deutlich besser wirst, als das was dir dein Compiler optimiert. Ich denke, dass es vor allem algorithmische Verbesserungen gibt, aber dazu kann niemand was sagen, weil wir nicht wissen, was dein Ziel ist.

    Wenn es nur darum geht zu überprüfen ob ein Wert schon mal vorgekommen ist und dann eine Ausgabe zu machen, kannst du auch einfach den Wert z.B. in eine Map oder einen Vektor schreiben und gucken ob der schon mal vorgekommen ist.
    Wenn du jeden Tag von jedem Jahr miteinander vergleichen willst, hast du halt auch einige Kombinationen.

    Wenn es dir um einen schnellen Vergleich von deinem Typ "BYTE" geht, wäre hilfreich zu wissen, wie du den == operator aktuell implementiert hast? Oder was für ein Typ dahinter steckt. Ist das einfach ein alias auf ein uint8_t?



  • @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.


Anmelden zum Antworten