• naur
    link
    fedilink
    Polski
    arrow-up
    1
    ·
    13 days ago

    Dziwne, że autor posta skupił się na zerowaniu pamięci, a nie na dodatkowym wywołaniu alokatora przez wektor.

    Ale w sumie lepsze to niż dyskusja o rodzajach inicjalizacji w C++.

    • サぺルOPM
      link
      fedilink
      Polski
      arrow-up
      1
      ·
      13 days ago

      Mam nieodparte wrażenie, że już o tym rozmawialiśmy. Tylko ja liczyłem na to, że istnieje jakaś instrukcja przygotowująca linię cache do zapisu.

      Z drugiej strony chciałbym zobaczyć na ile to prawda i przygotować jakiś benchmark. Wydaje mi się to trudne. Za dużo nie wiem co może zaburzyć pomiar.

      • naur
        link
        fedilink
        Polski
        arrow-up
        1
        ·
        13 days ago

        Chyba gadaliśmy kiedyś o niskim narzucie instrukcji, które wielokrotnie modyfikują tę samą linie cache’u.
        Pamiętam, że uzyskałem kiedyś spory przyrost wydajności w dekompresorze LZ4 poprzez kopiowanie 16 albo 32 bajtów, niezależnie od tego, ile danych faktycznie miało być skopiowane.
        Jedna z operacji w LZ4 polega na skopiowaniu jakiegoś fragmentu już zdekompresowanych danych. Często są to małe obszary, rzędu 3-4 bajtów. Ja zawsze kopiowałem wtedy dane nadrmiarowo, do pełnej szerokości rejestru SIMD i tylko inkrementowałem wskaźnik do następnego zapisu o prawidłowy rozmiar danych.
        To powoduje, że kilka razy nadpisuje się te same obszary w pamięci ale nadal jest to bardziej efektywne od precyzyjnego przycinania kopiowanych bajtów.

        • サぺルOPM
          link
          fedilink
          Polski
          arrow-up
          1
          ·
          13 days ago

          Pisaliśmy nawet o tym, że nie powinno się zapisywać i odczytywać pamięci w krótkich odstępach czasu. Bo to ląduje w osobnych kolejkach. Od tego czasu dużo się zmieniło. Kolejka odczytu stała się tablicą, a w AMD są rejestry mapowane na pamięć. By trza to zweryfikować.