Làm thế nào để Volkov và Demmel xác định bằng thực nghiệm độ trễ, kích thước dòng và kích thước trang của GPU?


8

Trong "Các yếu tố LU, QR và Cholesky sử dụng khả năng Vector của GPU", của Vasily Volkov và James Demmel , có một cách thú vị để diễn giải độ trễ, kích thước dòng và kích thước trang của bộ đệm từ biểu đồ như thế này:

Hình 1 từ bài báo

Rõ ràng, kích thước dòng là nơi bộ đệm bắt đầu lên cao nguyên (khoảng 32 byte trong ví dụ này). Thứ đó đã đến từ đâu?

Và làm thế nào để chúng ta biết rằng kích thước trang là nơi cao nguyên thứ hai bắt đầu cho bộ nhớ toàn cầu?

Hơn nữa, tại sao độ trễ cuối cùng lại đi xuống với độ dài sải chân đủ lớn? Họ không nên tiếp tục tăng?

Nếu điều này thực sự hoạt động, và dường như, điều đó thật tuyệt vời vì chúng ta có thể nhận được rất nhiều dữ liệu không có giấy tờ về bộ nhớ cache của GPU.


John, tôi hy vọng tôi đã trả lời câu hỏi của bạn một cách hữu ích. Bạn có thể vui lòng chỉnh sửa câu hỏi của bạn để cung cấp cho nó một tiêu đề có ý nghĩa / tìm kiếm hơn một chút, cũng như đưa ra một tài liệu tham khảo và trích dẫn thích hợp cho bài báo bạn đang trích dẫn? Nó được coi là hình thức khá kém trong khoa học và toán học (và trang web này) để sử dụng một hình ảnh từ một bài báo mà không liệt kê các tác giả và tiêu đề.
Aron Ahmadia

Câu trả lời:


8

Nếu điều này thực sự hoạt động, và dường như, điều đó thật tuyệt vời vì chúng ta có thể nhận được rất nhiều dữ liệu không có giấy tờ về bộ nhớ cache của GPU.

Một khía cạnh bực bội của nghiên cứu điện toán hiệu năng cao là đào sâu tất cả các tập lệnh và tính năng kiến ​​trúc không có giấy tờ khi cố gắng điều chỉnh mã. Trong HPC, bằng chứng nằm trong điểm chuẩn, cho dù đó là Linpack hiệu suất cao hay STREAM. Tôi không chắc đây là "tuyệt vời", nhưng chắc chắn là các đơn vị xử lý hiệu suất cao được đánh giá và đánh giá như thế nào.

Rõ ràng, kích thước dòng là nơi bộ đệm bắt đầu lên cao nguyên (khoảng 32 byte trong ví dụ này). Thứ đó đã đến từ đâu?

Bạn dường như đã quen thuộc với các khái niệm hiệu suất của hệ thống phân cấp bộ đệm, được mô tả là "núi bộ nhớ" trong Hệ thống máy tính của Bryant và O'Hallaron : Quan điểm của lập trình viên , nhưng câu hỏi của bạn cho thấy sự thiếu hiểu biết sâu sắc về cách mỗi cấp độ của bộ đệm làm.

núi nhớ

Hãy nhớ lại rằng bộ đệm chứa "dòng" dữ liệu, đó là các dải bộ nhớ liền kề được hài hòa với một vị trí bộ nhớ ở đâu đó trong cửa hàng chính. Khi truy cập bộ nhớ trong một dòng, chúng ta có "hit" bộ đệm và độ trễ liên quan đến việc truy xuất bộ nhớ này được gọi là độ trễ cho bộ đệm cụ thể đó. Ví dụ, độ trễ bộ đệm L1 10 chu kỳ cho biết rằng mỗi khi địa chỉ bộ nhớ được yêu cầu đã ở một trong các dòng bộ đệm L1, chúng tôi sẽ mong đợi truy xuất nó trong 10 chu kỳ.

Như bạn có thể thấy từ mô tả của điểm chuẩn đuổi theo con trỏ, nó có những bước tiến có độ dài cố định thông qua bộ nhớ. Lưu ý: Điểm chuẩn này sẽ KHÔNG hoạt động như mong đợi trong nhiều CPU hiện đại có các đơn vị tìm nạp trước "phát hiện luồng" không hoạt động như bộ đệm đơn giản.

Điều đó có ý nghĩa sau đó, rằng cao nguyên hiệu suất đáng chú ý đầu tiên (bắt đầu từ bước 1), là một bước tiến không thể sử dụng lại từ các lỗi bộ nhớ cache trước đó. Một sải chân phải mất bao lâu trước khi nó bước hoàn toàn qua dòng bộ đệm đã lấy trước đó? Độ dài của dòng bộ đệm!

Và làm thế nào để chúng ta biết rằng kích thước trang là nơi cao nguyên thứ hai bắt đầu cho bộ nhớ toàn cầu?

Tương tự, cao nguyên tiếp theo của bước sử dụng lại sẽ là khi trang bộ nhớ do hệ điều hành quản lý phải được hoán đổi với mỗi lần truy cập bộ nhớ. Kích thước trang bộ nhớ, không giống như kích thước dòng bộ đệm, thông thường là một tham số có thể được đặt hoặc quản lý bởi người lập trình.

Hơn nữa, tại sao độ trễ cuối cùng lại đi xuống với độ dài sải chân đủ lớn? Họ không nên tiếp tục tăng

Đây chắc chắn là phần thú vị nhất trong câu hỏi của bạn và nó giải thích cách các tác giả quy định cấu trúc bộ đệm (tính kết hợp và số lượng bộ) dựa trên thông tin họ đã lượm lặt được trước đó (kích thước của các dòng bộ đệm) và kích thước của bộ làm việc dữ liệu họ đang sải bước. Nhớ lại từ thiết lập thử nghiệm mà các bước "bao quanh" mảng. Đối với một bước tiến đủ lớn, tổng số lượng dữ liệu mảng cần được giữ trong bộ đệm (bộ được gọi là bộ làm việc), nhỏ hơn vì nhiều dữ liệu trong mảng bị bỏ qua. Để minh họa điều này, bạn có thể tưởng tượng một người liên tục chạy lên xuống một bộ cầu thang, chỉ thực hiện mỗi bước thứ 4. Người này đang chạm vào tổng số bước ít hơn so với ai đó thực hiện cứ sau 2 bước. Ý tưởng này có phần lúng túng được nêu trong bài báo:

Khi sải chân rất lớn, bộ làm việc sẽ giảm cho đến khi nó phù hợp với bộ đệm, lần này tạo ra xung đột bỏ lỡ nếu bộ đệm không hoàn toàn liên kết.

Như Bill Barth đã đề cập trong câu trả lời của mình, các tác giả nêu cách họ thực hiện các tính toán này trong bài báo:

Dữ liệu trong Hình 1 cho thấy TLB 16 mục nhập hoàn toàn (không có chi phí TLB cho mảng 128 MB, sải chân 8 MB), bộ đệm L1 kết hợp 20 chiều (mảng 20KB ở sải chân 1KB phù hợp với L1) và 24 chiều đặt bộ đệm L2 kết hợp (trở lại độ trễ nhấn L2 cho mảng 768KB, sải chân 32KB). Đây là những con số hiệu quả và việc thực hiện có thể khác nhau. Sáu bộ đệm L2 kết hợp 4 chiều cũng khớp với dữ liệu này.


0

Tôi muốn nói rằng đoạn trên trang 3 bắt đầu "Độ trễ lớn hơn biểu thị nhiều lỗi nhớ cache hơn." giải thích hầu hết những gì bạn yêu cầu khá tốt.

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.