Speicher beschreiben - SSE ?



  • Hallo zusammen...

    Wenn ich viel Speicher beschreiben will, lohnt es sich auf SSE zu setzen?

    Man könnte ja

    mov dword ptr [SPEICHER], EAX
    

    oder

    mov qword ptr [SPEICHER], RAX
    

    oder eben

    movntdq oword ptr [SPEICHER], XMM0
    ;bzw
    movaps oword ptr [SPEICHER], XMM0
    

    Also V2 ist natürlich schneller als V1 bei einem x64 OS. Aber wie sieht es mit SSE aus? Weil der Speicherbus ist ja immer gleich (64bit)...



  • LOL, was für ein jämmerlicher Code.



  • hustbear schrieb:

    LOL, was für ein jämmerlicher Code.

    LOL, was für ein jämmerlicher Beitrag.



  • Wenn du die volle Geschwindigkeit haben willst must du aufpassen das deine Daten auch entsprechend der Registergröße ausgerichtet sind.



  • Jaja, sicher, meine Frage ist nur, ob:

    "16byte Align - 128bit SSE-Register"
    oder
    "8byte Align - 64bit Universal-Register"
    schneller ist.

    Weil wenn der Systembus nur 64bit breit ist, sollte es da ja keinen Unterschied geben oder?
    Nun weiß ich leider nicht, ob SSE bzw. neuere Techniken andere Methoden besitzen um z.B. auf einen Schlag 128bit zu transportieren...

    Gruß



  • Zwischen Register und Speicher liegt mindestens noch ein Cache.
    Der hauptsaechliche Vorteil des Alignments ist, dass die gesamten 128Bit in der gleichen Cache-Line liegen.



  • Oh jou, den Cache hab ich ganz vergessen!
    Aber wenn der Speicher noch nicht im Cache liegt...?



  • Dann wird der Speicher in den Cache geladen - ueblicherweise so 64 Byte.
    Erst wenn das Laden abgeschlossen ist kommen die Daten ins Register.
    Weil der Cache weiss auf welche Adressen Du schon zugegriffen hast, versucht er zu erraten, welche Du als naechstes brauchst.



  • Hm...okay macht Sinn 🙂

    Aber angenommen es gäbe keinen Cache. Dann wäre die 128bit Variante gleich schnell, korrekt?



  • 2 x Schreiben und 2 x Lesen versus 1 x Schreiben und 1 x Lesen



  • __username schrieb:

    Aber angenommen es gäbe keinen Cache. Dann wäre die 128bit Variante gleich schnell, korrekt?

    Seit der Erfindung von Dual-Channel ist die Speicheranbindung ja quasi 128 Bit breit.
    Und der Cache ist ja deswegen da, damit es eben nicht "gleich schnell" ist...



  • Dual-Channel

    , danke, das war mein Stichwort 🙄

    Okay, danke !



  • Also ich hab letztens n bisschen mit sse2 rumgespielt um Speicher auf 0 zu setzen (movdqa in meinem Fall).
    Ergebniss eines kleinen Vergleichs: (die Angaben sind cpu-cycles, gemittelt aus jeweils 1 Million Durchläufen 😉 )

    ; ------------- Sample size = 16 bytes ---------------------
    RtlZeroMemory - Microsoft: 32
    memfill - masm32 lib: 9
    crt_memset - msvcrt: 34
    ZeroMemSse2: 105
    ; ------------- Sample size = 64 bytes ---------------------
    RtlZeroMemory - Microsoft: 40
    memfill - masm32 lib: 17
    crt_memset - msvcrt: 43
    ZeroMemSse2: 30
    ; ------------- Sample size = 256 bytes ---------------------
    RtlZeroMemory - Microsoft: 88
    memfill - masm32 lib: 68
    crt_memset - msvcrt: 92
    ZeroMemSse2: 44
    ; ------------- Sample size = 1024 bytes ---------------------
    RtlZeroMemory - Microsoft: 122
    memfill - masm32 lib: 278
    crt_memset - msvcrt: 125
    ZeroMemSse2: 83

    Das waren aber Tests mit aligntem Speicher (die sse2 funktion prüft das auch)



  • Also ist memfill wohl bis 256byte am schnellsten und danach ZeroMemSse2.

    Wie hast denn die CPU-cycles gefunden? Kann man das unter Windows wirklich exakt bestimmen? Wie bemerkst du denn, wenn Zwischenzeitlich ein TaskSwitch aufkommt und die Cycles für ein anderes Programm draufgehen?

    Oder werden die Cycles pro Anwendung gezählt?



  • 100% exakt gehts nicht, es kann immer ein Context switch oder Interrupt dazwischen kommen, allerdings läuft das ganze mit hoher Priorität was das etwas unwahrscheinlicher macht.

    Gemessen mit den Timing Makros aus dem masm32 Forum http://www.masm32.com/board/index.php?topic=770.0


Anmelden zum Antworten