Xung đột ngân hàng là gì? (Lập trình Cuda / OpenCL)


95

Tôi đã đọc hướng dẫn lập trình cho CUDA và OpenCL, và tôi không thể tìm ra xung đột ngân hàng là gì. Họ chỉ đi sâu vào cách giải quyết vấn đề mà không cần giải thích chi tiết về chủ đề. Ai có thể giúp tôi hiểu nó? Tôi không có ưu tiên nếu trợ giúp trong bối cảnh CUDA / OpenCL hoặc chỉ là xung đột ngân hàng nói chung trong khoa học máy tính.

Câu trả lời:


105

Đối với nvidia (và amd cho vấn đề đó) gpus bộ nhớ cục bộ được chia thành các ngân hàng bộ nhớ. Mỗi ngân hàng chỉ có thể giải quyết một tập dữ liệu tại một thời điểm, vì vậy nếu một nửa chập cố gắng tải / lưu trữ dữ liệu từ / đến cùng một ngân hàng thì quyền truy cập phải được tuần tự hóa (đây là xung đột ngân hàng). Đối với gt200 gpus, có 16 ngân hàng (32 ngân hàng cho fermi), 16 hoặc 32 ngân hàng cho AMD gpus (57xx trở lên: 32, mọi thứ bên dưới: 16)), được xen kẽ với độ chi tiết là 32 bit (vì vậy byte 0-3 nằm trong ngân hàng 1, 4-7 trong ngân hàng 2, ..., 64-69 trong ngân hàng 1, v.v.). Để có hình dung tốt hơn, về cơ bản nó trông như thế này:

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

Vì vậy, nếu mỗi luồng trong halfwarp truy cập các giá trị 32bit liên tiếp thì không có xung đột ngân hàng. Một ngoại lệ từ quy tắc này (mọi luồng phải truy cập vào ngân hàng riêng của nó) là các chương trình phát sóng: Nếu tất cả các luồng truy cập cùng một địa chỉ, giá trị chỉ được đọc một lần và được phát sóng cho tất cả các luồng (đối với GT200, nó phải là tất cả các luồng trong halfwarp truy cập cùng một địa chỉ, iirc fermi và AMD gpus có thể thực hiện việc này đối với bất kỳ số luồng nào truy cập cùng một giá trị).


3
Cảm ơn ngọt ngào cho hình ảnh và lời giải thích. Tôi không biết về chương trình phát sóng và đó có vẻ như là một chút thông tin quan trọng :) Làm cách nào để xác minh rằng tải và lưu trữ của tôi không gây ra xung đột ngân hàng trong bộ nhớ dùng chung? Tôi có phải lấy mã lắp ráp bằng cách nào đó hay có những cách khác?
lậuPancakes

3
vì khả năng xảy ra xung đột ngân hàng là một suy nghĩ nào đó sẽ được xác định trong thời gian chạy (có nghĩa là trình biên dịch không biết về nó, sau khi hầu hết các địa chỉ được tạo trong thời gian chạy), việc lấy phiên bản đã biên dịch sẽ không giúp được gì nhiều. Tôi thường làm điều này theo cách thời trang cũ, tôi lấy giấy bút và bắt đầu suy nghĩ về những gì mã của tôi lưu trữ ở đâu. Sau tất cả các quy tắc chi phối khả năng xảy ra xung đột ngân hàng không quá phức tạp. Nếu không, bạn có thể sử dụng hồ sơ OpenCL nvidia (nên được đóng gói với sdk, iirc). Tôi nghĩ rằng nó có một bộ đếm để nối tiếp sợi dọc.
Grizzly

1
Cảm ơn vì đã chỉ ra các serialize dọc. Một trong những tập tin văn bản readme mà đi kèm với các hồ sơ tính toán nói điều này,
smuggledPancakes

1
Ack, miễn bình luận ở trên, vì một số lý do nên mình không thể biên tập lại. Dù sao đi nữa, tôi đã tìm thấy điều này trong readme của trình biên dịch tính toán, "warp_serialize: Số lượng chuỗi cong lên tuần tự trên các xung đột địa chỉ với bộ nhớ được chia sẻ hoặc không đổi." Điều này thật tuyệt mà tôi có thể dễ dàng nhận ra nếu có xung đột chỉ bằng cách nhìn vào đầu ra hồ sơ. Làm thế nào để bạn tìm ra nếu có xung đột ngân hàng trên giấy bút. Bạn có học được từ bất kỳ ví dụ hoặc hướng dẫn nào không?
lậuPancakes

1
Như tôi đã nói, việc ánh xạ từ các địa chỉ đến các ngân hàng tương đối đơn giản, vì vậy không khó để tìm ra các truy cập nào sẽ đến ngân hàng nào và do đó nếu có xung đột ngân hàng. Bài báo chỉ dành cho các mẫu truy cập xung đột hơn, nơi mà tôi không thể làm điều đó nếu không có.
Grizzly

13

Bộ nhớ dùng chung có thể được truy cập song song được chia thành các mô-đun (còn gọi là ngân hàng). Nếu hai vị trí bộ nhớ (địa chỉ) xảy ra trong cùng một ngân hàng, thì bạn sẽ gặp xung đột về ngân hàng trong đó việc truy cập được thực hiện nối tiếp, làm mất đi lợi thế của truy cập song song.


Vì vậy, điều này có liên quan đến khi một nửa dọc muốn lưu trữ hoặc tải bộ nhớ? 16 luồng sẽ cố gắng thực hiện một giao dịch bộ nhớ và do đó việc truy cập vào cùng một ngân hàng với nhiều hơn một luồng gây ra quá trình xử lý tuần tự? Ngoài ra, làm cách nào để đảm bảo rằng bạn không lưu trữ / tải dữ liệu trong cùng một ngân hàng?
lậuPancakes

10

Nói một cách đơn giản, xung đột ngân hàng là trường hợp khi bất kỳ mẫu truy cập bộ nhớ nào không phân phối IO qua các ngân hàng có sẵn trong hệ thống bộ nhớ. Các ví dụ sau đây làm rõ khái niệm: -

Giả sử chúng ta có mảng số nguyên 512x512 hai chiều và hệ thống DRAM hoặc bộ nhớ của chúng ta có 512 ngân hàng trong đó. Theo mặc định, dữ liệu mảng sẽ được bố trí theo cách arr [0] [0] chuyển đến ngân hàng 0, arr [0] [1] chuyển đến ngân hàng 1, arr [0] [2] đến ngân hàng 2…. arr [0] [511] chuyển đến ngân hàng 511. Để tổng quát hóa arr [x] [y] chiếm ngân hàng số y. Bây giờ một số mã (như được hiển thị bên dưới) bắt đầu truy cập dữ liệu theo kiểu cột chính tức là. thay đổi x trong khi giữ y không đổi, thì kết quả cuối cùng sẽ là tất cả các truy cập bộ nhớ liên tiếp sẽ đạt cùng một ngân hàng - do đó xung đột ngân hàng.

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

Những vấn đề như vậy, thông thường, được trình biên dịch tránh bằng cách đệm mảng hoặc sử dụng số nguyên tố của các phần tử trong mảng.


7

(Xung đột ngân hàng CUDA) Tôi hy vọng điều này sẽ giúp ích .. đây là lời giải thích rất tốt ...

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


1
Lưu ý rằng không khuyến khích các câu trả lời chỉ liên kết, các câu trả lời SO phải là điểm cuối của quá trình tìm kiếm giải pháp (so với một điểm dừng khác của các tài liệu tham khảo, có xu hướng cũ dần theo thời gian). Vui lòng xem xét thêm một bản tóm tắt độc lập ở đây, giữ liên kết làm tài liệu tham khảo.
kleopatra

Vui lòng giải thích rõ hơn về liên kết nhằm nỗ lực hỗ trợ OP tốt hơn.
Peter Foti

1
Video này thực sự hữu ích! Và tôi không biết tại sao bỏ phiếu xuống! Đó là một đầu vào rất tốt! +1
Gabriel

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.