Jest to temat bliski mojemu sercu i niedawnym badaniom, więc przyjrzę się mu pod kilkoma kątami: historia, kilka uwag technicznych (głównie akademickich), wyniki testów na moim pudełku, a na koniec próba odpowiedzi na twoje pytanie, kiedy i gdzie {2]} może mieć sens.

Częściowo jest to wywołanie , aby udostępnić wyniki - jeśli możesz uruchomić Tinymembench i udostępnić wyniki wraz ze szczegółami konfiguracji procesora i pamięci RAM, byłoby świetnie. Zwłaszcza jeśli masz konfigurację 4-kanałową, skrzynkę Ivy Bridge, skrzynkę serwera itp.

Historia i oficjalne porady

Historia wydajności szybkich instrukcji kopiowania ciągów była trochę sprawą schodową - tj. okresy stagnacji wydajności na przemian z dużymi ulepszeniami, które wprowadziły je do linii lub nawet szybciej niż konkurencyjne podejścia. Na przykład, nastąpił skok wydajności w Nehalem (głównie celowanie kosztów ogólnych) i ponownie w Ivy Bridge (większość celowania ogółem przepustowość dla dużych kopii). W tym wątku można znaleźć dziesięcioletni wgląd w trudności związane z implementacją instrukcji rep movsod inżyniera Intela.

Konkretny wariant realizacji jest wybierany w czasie realizacji na podstawie układu danych, wyrównania i wartości licznika (ECX). Na przykład, MOVSB/STOSB z prefiksem REP powinien być używany z licznikiem wartość mniejsza lub równa 3 dla najlepszej wydajności.

Więc dla kopii 3 lub mniej bajtów? Nie potrzebujesz do tego prefiksu rep, ponieważ przy deklarowanym opóźnieniu uruchamiania wynoszącym ~9 cykli jesteś prawie na pewno lepiej z prostym DWORDEM lub QWORD mov z odrobiną przekręcania bitów, aby zamaskować nieużywane bajty(lub może z 2 jawnymi bajtami, word movs, jeśli wiesz, że rozmiar jest dokładnie trzy).

Mówią dalej:

String MOVE/STORE instrukcje mają wiele ziarnistości danych. Na efektywny przepływ danych, większe ziarnistości danych są preferowane. Oznacza to, że lepszą wydajność można osiągnąć poprzez rozkładanie dowolna wartość licznika na liczbę podwójnych słów plus jeden bajt porusza się z wartość zliczania mniejsza lub równa 3.

To z pewnością wydaje się złe na obecnym sprzęcie z ERMSB, gdzie rep movsb jest co najmniej tak szybki, lub szybszy, niż warianty movd lub movq dla dużych kopii.

Ogólnie rzecz biorąc, ta sekcja (3.7.5) obecnego przewodnika zawiera zestaw rozsądnych i bardzo przestarzałych porad. Jest to powszechna przepustowość podręczników Intela, ponieważ są one aktualizowane w sposób Przyrostowy dla każdej architektury (i rzekomo obejmują prawie dwie dekady wartości stare sekcje często nie są aktualizowane w celu zastąpienia lub wprowadzenia warunkowych porad, które nie mają zastosowania do bieżącej architektury.

Następnie przejdą do ermsb wyraźnie w sekcji 3.7.6.

Nie będę wyczerpująco omawiać pozostałych porad, ale podsumuję dobre części w "Dlaczego z nich korzystać" poniżej.

Inne ważne twierdzenia z przewodnika to to, że na Haswell, rep movsb został ulepszony do korzystania z operacji 256-bitowych wewnętrznie.

Względy Techniczne

Jest to tylko krótkie podsumowanie podstawowych zalet i wad, które mają rep instrukcje z punktu widzenia implementacji .

Zalety dla rep movs

1. Po wydaniu rep instrukcji movs, procesorwie , że cały blok o znanym rozmiarze ma zostać przesłany. Może to pomóc zoptymalizować działanie w sposób, który nie może z dyskretnym instrukcje, na przykład:

   • unikanie żądania RFO, gdy wie, że cała linia bufora zostanie nadpisana.
   • wysyłanie żądań prefetch natychmiast i dokładnie. Wstępne ustawianie sprzętowe dobrze sprawdza się w wykrywaniu wzorców podobnych do memcpy, ale nadal wymaga kilku odczytów, aby zacząć i "przepełni" wiele linii pamięci podręcznej poza końcem kopiowanego regionu. rep movsb zna dokładnie rozmiar regionu i może prefetch dokładnie.

2. Najwyraźniej nie ma gwarancji zamawiania wśród sklepów w³ pojedynczy rep movs, który może pomóc uprościć ruch spójny i po prostu inne aspekty ruchu bloków, w porównaniu z prostymi mov instrukcjami, które muszą być zgodne z dość ścisłym porządkiem pamięci⁴.

3. W zasadzie Instrukcja rep movs może wykorzystywać różne sztuczki architektoniczne, które nie są eksponowane w ISA. Na przykład, architektury mogą mieć szersze wewnętrzne ścieżki danych, które Isa ujawnia⁵ i rep movs przydałoby się to wewnętrznie.

Wady

1. rep movsb musi zaimplementować konkretny semantyczny, który może być silniejszy niż podstawowe wymagania programowe. W szczególności memcpy zabrania nakładania się regionów, więc może ignorować tę możliwość, ale rep movsb dopuszcza je i musi przynieść oczekiwany rezultat. Na obecnych implementacjach wpływa głównie na uruchomienie napowietrznych, ale prawdopodobnie nie do dużych przepustowości bloków. Podobnie, {[2] } musi obsługiwać kopie bajtowo-ziarniste, nawet jeśli używasz go do kopiowania dużych bloków, które są wielokrotnością pewnej dużej mocy 2.

2. Oprogramowanie może posiadać informacje o wyrównaniu, rozmiarze kopii i możliwym aliasingu, których nie można przekazać sprzętowi, jeśli używa się rep movsb. Kompilatory mogą często określać wyrównanie bloków pamięci⁶ i tak można uniknąć wielu prac startowych, które rep movs musi wykonywać na każde wywołanie.

Wyniki Testów

Oto wyniki testów dla wielu różnych metod kopiowania z tinymembench na moim i7-6700HQ przy 2.6 GHz (szkoda, że mam identyczny Procesor więc nie dostajemy nowego punktu danych...):

 C copy backwards                                     :   8284.8 MB/s (0.3%)
 C copy backwards (32 byte blocks)                    :   8273.9 MB/s (0.4%)
 C copy backwards (64 byte blocks)                    :   8321.9 MB/s (0.8%)
 C copy                                               :   8863.1 MB/s (0.3%)
 C copy prefetched (32 bytes step)                    :   8900.8 MB/s (0.3%)
 C copy prefetched (64 bytes step)                    :   8817.5 MB/s (0.5%)
 C 2-pass copy                                        :   6492.3 MB/s (0.3%)
 C 2-pass copy prefetched (32 bytes step)             :   6516.0 MB/s (2.4%)
 C 2-pass copy prefetched (64 bytes step)             :   6520.5 MB/s (1.2%)
 ---
 standard memcpy                                      :  12169.8 MB/s (3.4%)
 standard memset                                      :  23479.9 MB/s (4.2%)
 ---
 MOVSB copy                                           :  10197.7 MB/s (1.6%)
 MOVSD copy                                           :  10177.6 MB/s (1.6%)
 SSE2 copy                                            :   8973.3 MB/s (2.5%)
 SSE2 nontemporal copy                                :  12924.0 MB/s (1.7%)
 SSE2 copy prefetched (32 bytes step)                 :   9014.2 MB/s (2.7%)
 SSE2 copy prefetched (64 bytes step)                 :   8964.5 MB/s (2.3%)
 SSE2 nontemporal copy prefetched (32 bytes step)     :  11777.2 MB/s (5.6%)
 SSE2 nontemporal copy prefetched (64 bytes step)     :  11826.8 MB/s (3.2%)
 SSE2 2-pass copy                                     :   7529.5 MB/s (1.8%)
 SSE2 2-pass copy prefetched (32 bytes step)          :   7122.5 MB/s (1.0%)
 SSE2 2-pass copy prefetched (64 bytes step)          :   7214.9 MB/s (1.4%)
 SSE2 2-pass nontemporal copy                         :   4987.0 MB/s

Kilka kluczowych rzeczy:

• metody rep movs są szybsze niż wszystkie inne metody, które nie są "nie-czasowe"⁷, i znacznie szybciej niż zbliża się "C" które kopiują 8 bajtów na raz.
• metody "nie-temporalne" są szybsze, nawet o około 26% od metod rep movs - ale to znacznie mniejsza delta niż ta, którą zgłosiłeś(26 Gb / s vs 15 GB/s = ~73%).
• jeśli nie używasz magazynów nie-temporalnych, używanie 8-bajtowych kopii z C jest prawie tak samo dobre jak 128-bitowe load/stores SSE. Dzieje się tak dlatego, że dobra pętla kopiująca może wygenerować wystarczająco dużo ciśnienia pamięci, aby nasycić przepustowość (np. 2.6 GHz * 1 store/cycle * 8 bajtów = 26 GB / s dla sklepów).
• W tinymembench nie ma jawnych 256-bitowych algorytmów (z wyjątkiem prawdopodobnie "standardowego" memcpy), ale prawdopodobnie nie ma to znaczenia ze względu na powyższą uwagę.
• zwiększona przepustowość nie-czasowego podejścia do przechowywania w stosunku do czasowych wynosi Około 1.45 x, co jest bardzo zbliżone do 1.5 x, którego można oczekiwać, jeśli NT eliminuje 1 z 3 transferów (tj. 1 odczyt, 1 zapis dla NT vs 2 odczyty, 1 zapis). rep movs podejścia leżą pośrodku.
• The połączenie dość niskiego opóźnienia pamięci i skromnej przepustowości 2-kanałowej oznacza, że ten konkretny układ jest w stanie nasycić przepustowość pamięci z jednego wątku, co zmienia zachowanie dramatycznie.
• rep movsd wydaje się używać tej samej magii co rep movsb na tym chipie. To ciekawe, ponieważ ERMSB tylko jawnie celuje movsb i wcześniejsze testy na wcześniejszych łukach z ERMSB pokazują movsb działanie znacznie szybciej niż movsd. Jest to głównie akademickie, ponieważ movsb jest bardziej ogólne niż movsd w każdym razie.

Haswell

Patrząc na Haswell wyniki uprzejmie przedstawione przez iwillnotexist w komentarzach, widzimy te same ogólne trendy (najbardziej istotne wyniki wyodrębnione):

 C copy                                               :   6777.8 MB/s (0.4%)
 standard memcpy                                      :  10487.3 MB/s (0.5%)
 MOVSB copy                                           :   9393.9 MB/s (0.2%)
 MOVSD copy                                           :   9155.0 MB/s (1.6%)
 SSE2 copy                                            :   6780.5 MB/s (0.4%)
 SSE2 nontemporal copy                                :  10688.2 MB/s (0.3%)

Kiedy należy stosować rep movs?

Wreszcie zadajesz sobie pytanie: kiedy i dlaczego powinieneś go używać? Czerpie z powyższego i wprowadza kilka nowych pomysłów. Niestety nie ma prostej odpowiedzi: będziesz musiał wymienić różne czynniki, w tym niektóre, których prawdopodobnie nie możesz dokładnie wiedzieć, takie jak przyszłe wydarzenia.

Zwróć uwagę, że alternatywą dla rep movsb może być zoptymalizowany libc memcpy (w tym kopie kompilator), lub może to być ręcznie rozwijana wersja memcpy. Niektóre z poniższych korzyści mają zastosowanie tylko w porównaniu do jednej lub drugiej z tych alternatyw (np. "prostota" pomaga w przypadku wersji ręcznie zwijanej, ale nie w przypadku wbudowanej memcpy), ale niektóre odnoszą się do obu.

Ograniczenia dotyczące dostępnych instrukcji

W niektórych środowiskach istnieje ograniczenie dotyczące pewnych instrukcji lub korzystania z niektórych rejestrów. Na przykład w jądrze Linuksa użycie rejestrów SSE/AVX lub FP jest ogólnie zabronione. W związku z tym większość zoptymalizowanych wariantów memcpy nie może być używana, ponieważ opierają się one na rejestrach SSE lub AVX, a zwykła 64-bitowa Kopia mov jest używana na x86. W przypadku tych platform użycie rep movsb pozwala na większość wydajności zoptymalizowanego memcpy bez łamania ograniczeń kodu SIMD.

Bardziej ogólnym przykładem może być kod, który musi być adresowany do wielu generacji sprzętu i który nie używa wysyłania specyficznego dla sprzętu (np. używając cpuid). Proszę. może być zmuszony do używania tylko starszych zestawów instrukcji, co wyklucza wszelkie AVX, itp. rep movsb może być dobrym podejściem, ponieważ umożliwia "Ukryty" dostęp do szerszych ładunków i sklepów bez użycia nowych instrukcji. Jeśli celujesz w sprzęt pre-ERMSB, musisz sprawdzić, czy wydajność rep movsb jest tam akceptowalna...

Miłym aspektem rep movsb jest to, że może, w teorii wykorzystać ulepszenia architektoniczne na przyszłych architekturach, bez zmiany źródła, że jawne ruchy nie mogą. Na przykład, gdy wprowadzono 256-bitowe ścieżki danych, rep movsb był w stanie z nich skorzystać (jak twierdzi Intel) bez żadnych zmian w oprogramowaniu. Oprogramowanie wykorzystujące 128-bitowe ruchy (co było optymalne przed Haswellem) musiałoby zostać zmodyfikowane i przekompilowane.

Jest to więc zarówno korzyść z utrzymania oprogramowania (nie ma potrzeby zmiany źródła), jak i korzyść dla istniejących binariów (nie ma potrzeby wdrażania nowych binariów, aby skorzystać z poprawa).

To, jak ważne jest to, zależy od Twojego modelu konserwacji (np. jak często nowe pliki binarne są wdrażane w praktyce) i bardzo trudnego do oceny, Jak szybkie będą te instrukcje w przyszłości. Przynajmniej Intel jest swego rodzaju przewodnikiem w tym kierunku jednak, zobowiązując się do co najmniej rozsądne wydajność w przyszłości (15.3.3.6):

REP MOVSB i REP STOSB będą nadal działać w miarę dobrze on przyszłych procesorów.

Nakładanie się na kolejne prace

Ta korzyść nie pojawi się oczywiście w prostym memcpy benchmarku, który z definicji nie ma kolejnych prac, które nakładają się na siebie, więc wielkość korzyści musiałaby być starannie mierzona w rzeczywistym scenariuszu. Maksimum korzyści może wymagać zmiany organizacji kodu wokół memcpy.

Na tę korzyść zwraca uwagę firma Intel w podręczniku optymalizacji (sekcja 11.16.3.4) i w ich słowach:

Gdy liczba jest znana jako co najmniej tysiąc bajtów lub więcej, używając enhanced REP MOVSB / STOSB może zapewnić kolejną zaletę amortyzacji koszt nie zużywającego się kodu. Heurystyka może być rozumiana użycie wartości Cnt = 4096 i memset () jako przykład:

• 256-bitowa implementacja SIMD memset() będzie musiała wydać / wykonać wycofanie 128 przypadków 32-bajtowej pracy magazynu z VMOVDQA, przed nie zużywający sekwencje instrukcji mogą przejść do emerytura.

• instancja enhanced REP STOSB o ECX= 4096 jest dekodowana jako długi przepływ mikro-op zapewniany przez sprzęt, ale rezygnuje jako jeden Instrukcja. Istnieje wiele operacji store_data, które muszą zostać zakończone zanim wynik memset() zostanie wykorzystany. Ponieważ dopełnienie operacji przechowywania danych jest odłączany od programu-zlecenie wycofania, a znaczna część nie zużywającego się strumienia kodu może przetwarzać poprzez na wydanie/wykonanie i wycofanie, zasadniczo bez kosztów, jeśli nie zużywająca Sekwencja nie konkuruje o zasoby bufora magazynu.

Więc Intel mówi, że po wszystkich UOPs kod po rep movsb został wydany, ale podczas gdy wiele sklepów jest nadal w locie, a rep movsb jako całość nie wycofała się jeszcze, UOPs z wykonywania instrukcji może zrobić większy postęp przez maszynerię out-of-order niż mogliby gdyby ten kod przyszedł po pętli kopiowania.

Uops z explicit load I store loop muszą faktycznie przejść na emeryturę oddzielnie w kolejności programów. To musi się zdarzyć, aby zrobić miejsce w ROB na śledzenie uops.

Wydaje się, że nie ma zbyt wielu szczegółowych informacji o tym, jak bardzo długo działają mikrokodowane instrukcje, takie jak rep movsb. Nie wiemy dokładnie, w jaki sposób oddziały mikro-kodu żądają innego strumienia UOPs od sekwencera mikrokodu, ani jak uops odchodzi na emeryturę. Jeśli poszczególne uops nie muszą osobno przejść na emeryturę, być może cały Instrukcja zajmuje tylko jedno miejsce w ROB?

Kiedy front-end, który zasila maszynę OoO, widzi instrukcję rep movsb w pamięci podręcznej uop, aktywuje ROM sekwencera mikrokodu (MS-ROM), aby wysłać mikrokody uops do kolejki, która zasila etap wydania/zmiany nazwy. Prawdopodobnie nie jest możliwe, aby jakikolwiek inny uops mieszał się z tym i wydawał/wykonywał⁸ podczas gdy rep movsb jest nadal wydawane, ale kolejne instrukcje mogą być pobierane/dekodowane i wydawane zaraz po ostatnim rep movsb uop robi, podczas gdy część kopii nie została jeszcze wykonana. Jest to przydatne tylko wtedy, gdy przynajmniej część kodu nie zależy od wyniku memcpy (co nie jest niczym niezwykłym).

Teraz rozmiar tej korzyści jest ograniczony: co najwyżej możesz wykonać N instrukcji (w rzeczywistości uops) poza powolną instrukcją rep movsb, w którym momencie przeciągniesz, gdzie N to Rozmiar ROB . Przy obecnych rozmiarach ROB ~200 (192 na Haswell, 224 na Skylake), to maksymalna korzyść ~200 cykli darmowej pracy dla kolejnego kodu z IPC równym 1. W ciągu 200 cykli możesz skopiować około 800 bajtów z prędkością 10 Gb / s, dzięki czemu w przypadku kopii tego rozmiaru możesz uzyskać bezpłatną pracę zbliżoną do kosztu kopii(dzięki czemu kopia jest bezpłatna).

Ponieważ rozmiary kopii stają się znacznie większe, względne znaczenie tego szybko maleje (np. jeśli zamiast tego kopiujesz 80 KB, Darmowa praca stanowi tylko 1% kosztu kopii). Mimo to jest to dość interesujące jak na skromne egzemplarze.

Pętle kopiowania nie należy też całkowicie blokować wykonywania kolejnych instrukcji. Intel nie wdaje się w szczegóły dotyczące wielkości korzyści, ani tego, jakiego rodzaju kopie lub otaczający kod jest najbardziej korzystny. (Hot or cold destination or source, high ILP or low ILP high-latency code after).

Rozmiar Kodu

Rozmiar wykonanego kodu (kilka bajtów) jest mikroskopijny w porównaniu do typowej, zoptymalizowanej procedury memcpy. Jeśli wydajność jest w ogóle ograniczona przez i-cache (w tym pamięć podręczną uop), Zmniejszony rozmiar kodu może być korzystny.

Ponownie, możemy powiązać wielkość tej korzyści na podstawie wielkości kopii. W rzeczywistości nie będę pracować nad tym numerycznie, ale intuicja jest taka, że zmniejszenie dynamicznego rozmiaru kodu O B bajty może zapisać co najwyżej C * B Cache-misses, dla pewnej stałej C. każde wywołanie do memcpy pociąga za sobą koszt miss cache (lub korzyść) raz, ale zaletą wyższej skali przepustowości z liczbą skopiowanych bajtów. Więc dla dużych transferów, wyższe przepływność zdominuje efekty pamięci podręcznej.

Ponownie, nie jest to coś, co pojawi się w prostym benchmarku, gdzie cała pętla bez wątpienia zmieści się w pamięci podręcznej uop. Do oceny tego efektu potrzebny będzie test w rzeczywistym świecie.

Optymalizacja Specyficzna Dla Architektury

Zgłosiłeś, że na twoim sprzęcie, rep movsb był znacznie wolniejszy niż platforma memcpy. Jednak nawet tutaj istnieją doniesienia o odwrotnym wyniku na wcześniejszym sprzęcie (jak Ivy Most).

Jest to całkowicie prawdopodobne, ponieważ wydaje się, że operacje przenoszenia strun są okresowo popularne - ale nie w każdym pokoleniu, więc może być szybsze lub przynajmniej wiązane (w tym momencie może wygrać na podstawie innych zalet) na architekturach, na których został zaktualizowany, tylko po to, aby pozostawać w tyle w kolejnych sprzętach.

Cytując Andy Glew, który powinien wiedzieć co nieco o tym po zaimplementowaniu ich na P6:

The big słabością wykonywania szybkich ciągów w mikrokodach było [...] the mikrokody wypadały z każdą generacją, coraz wolniej i wolniej, dopóki ktoś go nie naprawił. Just like a library men Kopia wypada z gry. Przypuszczam, że jest możliwe, że jeden z utraconych możliwości było wykorzystanie 128-bitowych obciążeń i sklepów, gdy stał się dostępny, i tak dalej.

W takim przypadku może to być postrzegane jako kolejna" specyficzna dla platformy " optymalizacja do zastosowania w typowych every-trick-in-the-book memcpy procedury można znaleźć w standardowych bibliotekach i kompilatorach JIT: ale tylko do użytku na architekturach, gdzie jest to lepsze. W przypadku skompilowanych elementów JIT lub AOT jest to łatwe, ale w przypadku skompilowanych statycznie binariów wymaga to wysyłki specyficznej dla platformy, ale często już istnieje (czasami zaimplementowane w czasie połączenia), lub argument mtune może być użyty do podjęcia statycznej decyzji.

Prostota

Nawet na Skylake, gdzie wydaje się, że jest w tyle bezwzględnie najszybsze techniki nie-temporalne, jest jeszcze szybsze niż większość podejść i jest bardzo proste . Oznacza to mniej czasu na walidację, mniej tajemniczych błędów, mniej czasu na strojenie i aktualizowanie implementacji monster memcpy (lub odwrotnie, mniejsze uzależnienie od kaprysów implementatorów bibliotek standardowych, jeśli na tym polegasz).

Platformy Związane Z Opóźnieniami

Algorytmy związane z przepustowością pamięci⁹ może faktycznie działać w dwóch głównych systemy: Wiązanie przepustowości pamięci DRAM lub współbieżność/opóźnienie.

Pierwszy tryb jest Tym, który prawdopodobnie znasz: podsystem DRAM ma pewną teoretyczną przepustowość, którą można łatwo obliczyć na podstawie liczby kanałów, szybkości/szerokości danych i częstotliwości. Na przykład mój system DDR4-2133 z 2 kanałami ma maksymalną przepustowość 2.133 * 8 * 2 = 34.1 GB / s, to samo co zgłoszone na ARK.

Nie wytrzymasz więcej niż ta szybkość z DRAM (i zwykle nieco mniej ze względu na różne nieefektywności) dodawane we wszystkich rdzeniach na gnieździe (tj. jest to globalny limit dla Systemów z pojedynczymi gniazdami).

Drugi limit jest narzucany przez liczbę jednoczesnych żądań, które rdzeń może faktycznie wydać podsystemowi pamięci. Wyobraź sobie, że rdzeń może mieć tylko 1 żądanie na raz, dla 64-bajtowej linii pamięci podręcznej - po zakończeniu żądania możesz wydać kolejne. Załóżmy również bardzo szybkie opóźnienie pamięci 50ns. Wtedy mimo dużej pamięci DRAM 34,1 GB/s przepustowość, w rzeczywistości otrzymałbyś tylko 64 bajty / 50 ns = 1,28 GB / s, czyli mniej niż 4% maksymalnej przepustowości.

W praktyce rdzenie mogą wysyłać więcej niż jedno żądanie na raz, ale nie nieograniczoną liczbę. Zwykle przyjmuje się, że pomiędzy L1 i resztą hierarchii pamięci jest tylko 10 buforów wypełnienia linii na rdzeń, a być może 16 buforów wypełnienia między L2 i DRAM. Prefetching konkuruje o te same zasoby, ale przynajmniej pomaga zmniejszyć efektywne opóźnienia. Po więcej szczegółów zajrzyj do jednego ze świetnych postów Dr. Bandwidth napisał na ten temat, głównie na forach Intela.

Mimo to, większość ostatnich procesorów jest ograniczona przez ten czynnik, a nie przepustowość pamięci RAM. Zazwyczaj osiągają 12 - 20 GB/s na rdzeń, podczas gdy przepustowość pamięci RAM może wynosić 50+ GB/s (w systemie 4-kanałowym). Tylko niektóre najnowsze rdzenie "klienta" 2-kanałowego gen, które wydają się mieć lepszy uncore, być może więcej buforów liniowych może osiągnąć limit pamięci DRAM na jeden rdzeń, a nasze chipy Skylake wydają się być jednym z nich.

Dlaczego ciągle o tym mówię? Ponieważ najlepsza memcpy implementacja często zależy od reżimu, w którym działasz. Po ograniczeniu pamięci DRAM BW (tak jak nasze chipy, ale większość z nich nie ma jednego rdzenia), używanie zapisów nie-czasowych staje się bardzo ważne, ponieważ oszczędza odczyt dla własności, który zwykle marnuje 1/3 przepustowości. Widzisz to dokładnie w wynikach testów powyżej: implementacje memcpy, które nie używają, tracą 1/3 swojej przepustowości.

Jeśli jednak jesteś ograniczony współbieżnością, sytuacja wyrównuje się i czasami odwraca, jednak. Masz wolne pasmo DRAM, więc sklepy NT nie pomagają i mogą nawet zaszkodzić, ponieważ mogą zwiększyć opóźnienie, ponieważ czas przekazania bufora linii może być dłuższy niż scenariusz, w którym prefetch przenosi linię RFO do LLC (lub nawet L2), a następnie sklep kończy się w LLC dla efektywnego niższego opóźnienia. W końcu, serwer uncores mają zazwyczaj dużo wolniejsze sklepy NT niż klienckie (i dużą przepustowość), co podkreśla to efekt.

Więc na innych platformach może się okazać, że sklepy NT są mniej przydatne (przynajmniej jeśli zależy ci na wydajności jednowątkowej) i być może rep movsb wygrywa gdzie (jeśli dostanie to, co najlepsze z obu światów).

Referencje

Inne dobre źródła informacji nie zintegrowane w powyższym.

Komp.Arch investigation of rep movsb versus alternatives. Wiele dobrych notatek na temat przewidywania gałęzi i implementacji podejścia, które często sugerowałem dla małych bloków: używanie nakładających się pierwszych i / lub ostatnich odczytów / zapisów zamiast próbować pisać tylko dokładnie wymaganą liczbę bajtów (na przykład, implementowanie wszystkich kopii od 9 do 16 bajtów jako dwóch 8-bajtów kopie, które mogą nakładać się na siebie w maksymalnie 7 bajtach).

¹ prawdopodobnie intencją jest ograniczenie go do przypadków, w których, na przykład, rozmiar kodu jest bardzo ważny.

² Patrz sekcja 3.7.5: przedrostek REP i przenoszenie danych.

³ ważne jest, aby pamiętać, że dotyczy to tylko różnych sklepów w obrębie samej pojedynczej instrukcji: po zakończeniu, blok sklepów nadal wydaje się uporządkowany w odniesieniu do wcześniejszych i późniejszych sklepy. Tak więc kod może widzieć sklepy z rep movs out of order w stosunku do siebie , ale nie w stosunku do poprzednich lub kolejnych sklepów (i to jest ta ostatnia gwarancja, której zwykle potrzebujesz). Będzie to problem tylko wtedy, gdy użyjesz końca miejsca docelowego kopii jako flagi synchronizacji, zamiast oddzielnego magazynu.

⁴ zauważ, że nie-czasowe dyskretne sklepy również unikają większości wymagań porządkowych, chociaż w praktyce rep movs ma jeszcze większą swobodę od nadal istnieją pewne ograniczenia dotyczące zamawiania w sklepach WC/NT.

⁵ było to powszechne w drugiej części ery 32-bitowej, gdzie wiele układów miało 64-bitowe ścieżki danych (np. do obsługi FPU, który miał wsparcie dla typu 64-bit {78]}). Obecnie" wykastrowane " chipy, takie jak marki Pentium czy Celeron, mają wyłączony AVX, ale przypuszczalnie rep movs microcode może nadal korzystać z 256b obciążeń / sklepów.

⁶ np. ze względu na reguły wyrównania języka, atrybuty wyrównania lub operatory, Zasady aliasingu lub inne informacje określone w czasie kompilacji. W przypadku osiowania, nawet jeśli nie można określić dokładnego osiowania, mogą one przynajmniej być w stanie podnieść kontrole osiowania z pętli lub w inny sposób wyeliminować zbędne kontrole.

⁷ zakładam, że " standard "memcpy wybiera podejście nie-czasowe, co jest bardzo prawdopodobne dla tej wielkości bufora.

⁸ niekoniecznie jest to oczywiste, ponieważ może to być przypadek, że strumień uop generowany przez rep movsb po prostu monopolizuje wysyłkę i wtedy wyglądałby bardzo podobnie do przypadku jawnego mov. Wydaje się jednak, że to tak nie działa - uops z kolejnych instrukcji może mieszać się z UOPs z mikrokodowanego rep movsb.

⁹ na przykład, te, które mogą wysyłać dużą liczbę niezależnych żądań pamięci, a tym samym nasycać dostępną przepustowość pamięci DRAM-to-core, z czego {14]} byłoby potomkiem plakatu (i jak to się do obciążeń związanych wyłącznie z opóźnieniem, takich jak ściganie wskaźnikiem).