Co to jest konflikt bankowy? (Programowanie Cuda / OpenCL)


96

Czytałem przewodnik programowania CUDA i OpenCL i nie mogę zrozumieć, co to jest konflikt bankowy. Po prostu zastanawiają się, jak rozwiązać problem, bez rozwijania samego tematu. Czy ktoś może mi pomóc to zrozumieć? Nie mam preferencji, czy pomoc jest w kontekście CUDA / OpenCL, czy tylko konflikty bankowe w ogóle w informatyce.

Odpowiedzi:


106

W przypadku procesorów graficznych nvidia (i amd) pamięć lokalna jest podzielona na banki pamięci. Każdy bank może adresować tylko jeden zestaw danych na raz, więc jeśli półwarp próbuje załadować / przechowywać dane z / do tego samego banku, dostęp musi zostać serializowany (jest to konflikt banku). Dla procesorów GT200 jest 16 banków (32 banki dla procesorów Fermi), 16 lub 32 banki dla procesorów AMD (57xx lub nowszy: 32, wszystko poniżej: 16)), które są przeplatane z ziarnistością 32-bitową (więc bajty 0-3 są w bank 1, 4-7 w banku 2, ..., 64-69 w banku 1 i tak dalej). Dla lepszej wizualizacji zasadniczo wygląda to tak:

Bank    |      1      |      2      |      3      |...
Address |  0  1  2  3 |  4  5  6  7 |  8  9 10 11 |...
Address | 64 65 66 67 | 68 69 70 71 | 72 73 74 75 |...
...

Więc jeśli każdy wątek w halfwarp uzyskuje dostęp do kolejnych 32-bitowych wartości, nie ma konfliktów bankowych. Wyjątkiem od tej reguły (każdy wątek musi mieć dostęp do własnego banku) są rozgłaszania: Jeśli wszystkie wątki mają dostęp do tego samego adresu, wartość jest odczytywana tylko raz i transmitowana do wszystkich wątków (w przypadku GT200 muszą to być wszystkie wątki w półwarstwie, które mają dostęp do ten sam adres, iirc fermi i AMD gpus mogą to zrobić dla dowolnej liczby wątków uzyskujących dostęp do tej samej wartości).


3
Słodkie dzięki za wizualizację i wyjaśnienie. Nie wiedziałem o transmisjach i wydaje mi się, że to ważna informacja :) Jak powinienem sprawdzić, czy moje obciążenia i sklepy nie powodują konfliktów bankowych w pamięci współdzielonej? Czy muszę jakoś dostać się do kodu asemblera, czy są inne sposoby?
przemycone

3
ponieważ wystąpienie konfliktu bankowego jest czymś, co zostanie ustalone w czasie wykonywania (co oznacza, że ​​kompilator nie wie o tym, ponieważ większość adresów jest generowana w czasie wykonywania), uzyskanie skompilowanej wersji niewiele by pomogło. Zazwyczaj robię to w stary, modny sposób, myśląc, że biorę długopis i kartkę papieru i zaczynam myśleć o tym, gdzie mój kod przechowuje gdzie. W końcu zasady regulujące występowanie konfliktów bankowych nie są tak skomplikowane. W przeciwnym razie możesz użyć profilera OpenCL nvidia (powinien być dołączony do sdk, iirc). Myślę, że ma licznik serializacji warp.
Grizzly

1
Dzięki za wskazanie serializacji warp. Jeden z plików tekstowych readme, które są dostarczane z profilerem obliczeniowym, powiedział:
przemyconePancakes

1
Potwierdź, wybacz powyższy komentarz, z jakiegoś powodu nie mogę go ponownie edytować. W każdym razie znalazłem to w pliku readme programu obliczeniowego, „warp_serialize: liczba wypaczeń wątków, które są serializowane w przypadku konfliktów adresów do pamięci współużytkowanej lub stałej”. To świetnie, że mogę łatwo sprawdzić, czy występują konflikty, po prostu patrząc na wyjście profilera. Jak dowiesz się, czy istnieją konflikty bankowe na papierze i długopisie. Czy nauczyłeś się z jakichś przykładów lub samouczków?
przemycono

1
Jak powiedziałem, mapowanie adresów do banków jest stosunkowo proste, więc nie jest trudno dowiedzieć się, które dostępy prowadzą do którego banku, a zatem czy występują konflikty między bankami. Artykuł dotyczy tylko bardziej konfliktowych wzorców dostępu, bez których nie mogę tego zrobić.
Grizzly

13

Pamięć współdzielona, ​​do której można uzyskać dostęp równolegle, jest podzielona na moduły (zwane także bankami). Jeśli dwie lokalizacje pamięci (adresy) występują w tym samym banku, pojawia się konflikt banku, podczas którego dostęp odbywa się szeregowo, tracąc zalety dostępu równoległego.


Czy jest to związane z sytuacją, w której pół-osnowa chce przechowywać lub ładować pamięć? 16 wątków będzie próbowało wykonać transakcję pamięci, a zatem dostęp do tego samego banku z więcej niż jednym wątkiem spowoduje serializowane przetwarzanie? Ponadto, w jaki sposób można upewnić się, że nie przechowujesz / nie ładujesz danych w tym samym banku?
przemycone

10

Mówiąc prościej, konflikt banków to przypadek, w którym jakikolwiek wzorzec dostępu do pamięci nie rozprowadza operacji we / wy w bankach dostępnych w systemie pamięci. Następujące przykłady rozwijają koncepcję:

Załóżmy, że mamy dwuwymiarową tablicę liczb całkowitych 512x512, a nasz DRAM lub system pamięci ma 512 banków. Domyślnie dane tablicy zostaną rozmieszczone w taki sposób, że arr [0] [0] trafia do banku 0, arr [0] [1] trafia do banku 1, arr [0] [2] do banku 2 .... arr [0] [511] trafia do banku 511. Aby uogólnić, arr [x] [y] zajmuje numer banku y. Teraz jakiś kod (jak pokazano poniżej) zaczyna uzyskiwać dostęp do danych w głównej kolumnie, tj. zmieniając x przy zachowaniu stałej y, wynikiem końcowym będzie to, że cały kolejny dostęp do pamięci trafi do tego samego banku - stąd konflikt banku.

int arr[512][512];
  for ( j = 0; j < 512; j++ ) // outer loop
    for ( i = 0; i < 512; i++ ) // inner loop
       arr[i][j] = 2 * arr[i][j]; // column major processing

Kompilatory zazwyczaj unikają takich problemów, buforując tablicę lub używając liczby pierwszej elementów tablicy.


8

(CUDA Bank Conflict) Mam nadzieję, że to pomoże ... to jest bardzo dobre wyjaśnienie ...

http://www.youtube.com/watch?v=CZgM3DEBplE


1
Należy pamiętać, że odradza się udzielanie odpowiedzi zawierających tylko łącze , odpowiedzi SO powinny być końcowym punktem poszukiwania rozwiązania (w porównaniu z kolejną przerwą w dostępie do odniesień, które z czasem stają się nieaktualne). Rozważ dodanie tutaj samodzielnego streszczenia, zachowując link jako odniesienie.
kleopatra

Proszę rozwinąć link, aby lepiej pomóc PO.
Peter Foti

1
Ten film jest naprawdę pomocny! I nie wiem, dlaczego głosowanie negatywne! To bardzo dobry wkład! +1
Gabriel

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.