Name: Phân tích bộ nhớ với NVIDIA Nsight Compute | Công cụ phát triển CUDA (Memory Analysis with NVIDIA Nsight Compute | CUDA Developer Tools)
Uploaded: 2025-10-24T01:44:11.000Z
Duration: 18 min 23 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

Welcome to this chapter of our CUDA Developer tool series on NSight Compute.

Chào mừng bạn đến với chương này trong loạt bài về công cụ dành cho nhà phát triển CUDA của chúng tôi về NSight Compute.

Today we will take a look at the memory workload analysis.

Hôm nay chúng ta sẽ xem xét phân tích tải công việc bộ nhớ.

My name is Maximilian and I am a developer Technology engineer at Nvidia.

Tên tôi là Maximilian và tôi là kỹ sư công nghệ nhà phát triển tại Nvidia.

GPU workloads often suffer from being heavily memory bound with ever increasing compute, especially in content creation where video frames are being streamed through memory with sometimes little processing like a color adjustment filter.

Các tải công việc GPU thường bị giới hạn bộ nhớ nặng nề với khả năng tính toán ngày càng tăng, đặc biệt là trong việc tạo nội dung, nơi các khung hình video được truyền qua bộ nhớ với đôi khi ít xử lý như bộ lọc điều chỉnh màu sắc.

The Memory Workload analysis section of NSight compute helps to guide us to achieve the full memory bandwidth of our GPU and optimize data access patterns to increase the cache hit rate.

Phần phân tích tải công việc bộ nhớ của NSight Compute giúp hướng dẫn chúng ta đạt được băng thông bộ nhớ đầy đủ của GPU và tối ưu hóa các mẫu truy cập dữ liệu để tăng tỷ lệ cache hit.

If you've not seen the introduction to NSight Compute featuring the Speed of Light section, you might want to think about starting with Bob's video first, which is linked in the video description.

Nếu bạn chưa xem phần giới thiệu về NSight Compute với phần Tốc độ ánh sáng, bạn có thể muốn xem video của Bob trước, video này được liên kết trong phần mô tả video.

Besides that, I highly recommend watching the linked GTC presentation about the memory hierarchy and memory transactions of on an Nvidia GPU in more detail than I will cover in this video.

Bên cạnh đó, tôi thực sự khuyên bạn nên xem bài thuyết trình GTC được liên kết về hệ thống phân cấp bộ nhớ và các giao dịch bộ nhớ trên GPU Nvidia chi tiết hơn những gì tôi sẽ trình bày trong video này.

It is crucial to understand the way memory is requested and what cache lines and sectors are in the context of cuda.

Điều quan trọng là phải hiểu cách yêu cầu bộ nhớ và các dòng cache, phân vùng bộ nhớ là gì trong ngữ cảnh của CUDA.

We will start with a theoretical walkthrough of the memory analysis chart where we get an overview of hardware, memory locality and memory type.

Chúng ta sẽ bắt đầu với một hướng dẫn lý thuyết về biểu đồ phân tích bộ nhớ, nơi chúng ta có cái nhìn tổng quan về phần cứng, tính cục bộ của bộ nhớ và loại bộ nhớ.

The green elements denote logical units in software, eg texture memory with different ordering Alternative simple global local memory that refers to raw memory.

Các yếu tố màu xanh lá cây biểu thị các đơn vị logic trong phần mềm, ví dụ: bộ nhớ texture với các cách sắp xếp khác nhau, bộ nhớ toàn cục đơn giản cục bộ, đề cập đến bộ nhớ thô.

All physical units and hardware are colored blue.

Tất cả các đơn vị vật lý và phần cứng được tô màu xanh lam.

Arrow links between physical units denote the amount of read or written bytes across this connection.

Các mũi tên nối giữa các đơn vị vật lý biểu thị lượng byte được đọc hoặc ghi qua kết nối này.

The color of the arrow provides some insights into how far we are from the peak throughput of this interconnect via the drop down menu.

Màu của mũi tên cung cấp một số thông tin chi tiết về khoảng cách của chúng ta so với thông lượng đỉnh của kết nối này thông qua menu thả xuống.

We can also switch between the total bytes or the peak throughput percentage labeling of a connection.

Chúng ta cũng có thể chuyển đổi giữa nhãn tổng số byte hoặc phần trăm thông lượng đỉnh của kết nối.

Upon a memory request inside our kernel depicted on the left, we check if the requested sector behind an address is already present in L1.

Khi có yêu cầu bộ nhớ bên trong kernel của chúng ta được hiển thị ở bên trái, chúng ta kiểm tra xem phân vùng được yêu cầu sau một địa chỉ đã có trong L1 chưa.

If not, we fall through to L2 and check for the existence there.

Nếu không, chúng ta sẽ xuống L2 và kiểm tra sự tồn tại ở đó.

If none of the above contained this sector is fetched from Device memory.

Nếu không có thông tin nào ở trên chứa phân vùng này thì nó sẽ được lấy từ bộ nhớ Thiết bị.

Our L2 cache is the point of truth for all streaming multiprocessors.

Bộ nhớ cache L2 của chúng ta là điểm tham chiếu cho tất cả các bộ xử lý đa luồng.

What I mean by that is that all memory traffic has has to go through L2 including PCI copies or device memory writes.

Ý tôi là tất cả lưu lượng bộ nhớ phải đi qua L2 bao gồm cả các bản sao PCI hoặc ghi bộ nhớ thiết bị.

If a sector 2 rat is already present in L1, the L2 cache is not used.

Nếu một sector 2 rat đã có trong L1, bộ nhớ cache L2 sẽ không được sử dụng.

The L2 cache ensures that no SM reads invalid data from device memory that has not been written back as it is shared across the whole GPU.

Bộ nhớ cache L2 đảm bảo rằng không có SM nào đọc dữ liệu không hợp lệ từ bộ nhớ thiết bị chưa được ghi lại vì nó được chia sẻ trên toàn bộ GPU.

While L1 memory is local to one streaming multiprocessor, we can reduce the traffic between L2 and device memory by increasing L2 hit rate and we can following reduce the traffic between L1 and L2 with a higher L1 hit rate.

Trong khi bộ nhớ L1 cục bộ với một bộ xử lý đa luồng, chúng ta có thể giảm lưu lượng giữa L2 và bộ nhớ thiết bị bằng cách tăng tỷ lệ trúng L2 và chúng ta có thể giảm lưu lượng giữa L1 và L2 với tỷ lệ trúng L1 cao hơn.

Of course, traffic can also be reduced by changing the algorithm to simply require less data to be transferred.

Tất nhiên, lưu lượng cũng có thể được giảm bằng cách thay đổi thuật toán để đơn giản yêu cầu ít dữ liệu hơn được truyền đi.

Those hit rates are important to ensure low latency of memory requests, as fetches from device memory take many cycles.

Các tỷ lệ trúng này rất quan trọng để đảm bảo độ trễ thấp cho các yêu cầu bộ nhớ, vì việc lấy dữ liệu từ bộ nhớ thiết bị mất nhiều chu kỳ.

To understand more about the communication between the different types of memory and about how the hit rate is calculated, it is important to understand at what granularity the different units communicate.

Để hiểu rõ hơn về giao tiếp giữa các loại bộ nhớ khác nhau và cách tính tỷ lệ trúng, điều quan trọng là phải hiểu ở mức độ chi tiết nào các đơn vị khác nhau giao tiếp.

Cache lines are 128 bytes long in L1 and L2, but

Các dòng cache có độ dài 128 byte trong L1 và L2, nhưng

any communication on the GPU is done in sectors whose size is only 32 byte, while on newer hardware more than one sector can be communicated at once, a single sector is still the smallest communication possible in the memory system.

mọi giao tiếp trên GPU đều được thực hiện theo các sector có kích thước chỉ 32 byte, trong khi trên phần cứng mới hơn, nhiều sector có thể được giao tiếp cùng lúc, một sector đơn lẻ vẫn là giao tiếp nhỏ nhất có thể trong hệ thống bộ nhớ.

The concept of cache lines is important as we cannot allocate single sectors in cache, but

Khái niệm về các dòng cache rất quan trọng vì chúng ta không thể cấp phát các sector riêng lẻ trong cache, mà

always full cache lines into which we then read contiguous sectors.

luôn là các dòng cache đầy đủ mà sau đó chúng ta đọc các sector liền kề.

As a practical example why cache line allocation is important, we will assume a cache of only two cache lines.

Để làm ví dụ thực tế về tầm quan trọng của việc cấp phát dòng cache, chúng ta sẽ giả định một cache chỉ có hai dòng cache.

If we now read a picture in which each row is over 128 bytes long, we see the reading the first entry of the first row and the first of the second row, we would each allocate a cache line.

Nếu bây giờ chúng ta đọc một bức ảnh mà mỗi hàng có độ dài hơn 128 byte, chúng ta sẽ thấy việc đọc mục đầu tiên của hàng đầu tiên và mục đầu tiên của hàng thứ hai, mỗi lần sẽ cấp phát một dòng cache.

If we now read the third row, we have to invalidate a cache line to read the next.

Nếu bây giờ chúng ta đọc hàng thứ ba, chúng ta sẽ phải vô hiệu hóa một dòng cache để đọc dòng tiếp theo.

We would not be able to reuse any cache lines.

Chúng ta sẽ không thể tái sử dụng bất kỳ dòng cache nào.

This essentially lowers our possible cache storage to 25%.

Điều này về cơ bản làm giảm dung lượng lưu trữ cache có thể của chúng ta xuống còn 25%.

If we read the same memory in rows rather than columns, we read a full cache line, then the next, and

Nếu chúng ta đọc cùng một bộ nhớ theo hàng thay vì theo cột, chúng ta sẽ đọc một dòng cache đầy đủ, sau đó là dòng tiếp theo, và

After reading both full cache lines, we again have to invalidate, but

Sau khi đọc cả hai dòng cache đầy đủ, chúng ta lại phải vô hiệu hóa, nhưng

we were able to hold on to much more sectors and therefore more values much longer.

chúng ta đã có thể giữ lại nhiều sector hơn và do đó nhiều giá trị hơn trong thời gian dài hơn.

Especially with wider prefetches that transfer two sectors at a time.

Đặc biệt với các prefetch rộng hơn, truyền hai sector cùng lúc.

Chúng ta cũng tăng độ trễ của mình.

The previous explanation does hold for L2 and L1 cache.

Giải thích trước đó vẫn đúng cho cache L2 và L1.

If we would read 32 consecutive bytes in one SM, we would have a hit rate of 97% in L1.

Nếu chúng ta đọc 32 byte liên tiếp trong một SM, chúng ta sẽ có tỷ lệ hit là 97% trong L1.

Điều này sẽ dẫn đến 0% trong L2.

Because we send only one request to L2 and after that has been executed, all data is present in L1 and will be cached on further requests.

Bởi vì chúng ta chỉ gửi một yêu cầu đến L2 và sau khi yêu cầu đó được thực thi, tất cả dữ liệu sẽ có trong L1 và sẽ được cache cho các yêu cầu tiếp theo.

If we on the other hand have a kernel that reads values with a stride of 32 byte, meaning only the first value within one sector, we get 0% L1 cache hit rate.

Mặt khác, nếu chúng ta có một kernel đọc các giá trị với bước nhảy 32 byte, nghĩa là chỉ giá trị đầu tiên trong một sector, chúng ta sẽ có tỷ lệ hit cache L1 là 0%.

L2 will only have to reallocate a new cache line for every fourth value when reading with a 32 byte stride, but

L2 sẽ chỉ phải phân bổ lại một dòng cache mới cho mỗi giá trị thứ tư khi đọc với bước nhảy 32 byte, nhưng

has to request data from device memory on each request.

phải yêu cầu dữ liệu từ bộ nhớ thiết bị cho mỗi yêu cầu.

Nếu chúng ta giả định không có prefetch nào xảy ra.

In this case, the earlier we have a cache hit, the lower the memory latency is, with device memory clearly being the worst case because this memory is not on chip.

Trong trường hợp này, càng sớm có cache hit thì độ trễ bộ nhớ càng thấp, với bộ nhớ thiết bị rõ ràng là trường hợp xấu nhất vì bộ nhớ này không nằm trên chip.

We have not talked about shared memory yet and especially the improvements that it got with ampere.

Chúng ta vẫn chưa nói về bộ nhớ chia sẻ và đặc biệt là những cải tiến mà nó có được với Ampere.

Shared memory is per SM memory and is effectively L1 memory with the difference the this memory is not written back to device memory and is meant as a workspace memory.

Bộ nhớ chia sẻ là bộ nhớ trên mỗi SM và về cơ bản là bộ nhớ L1, với sự khác biệt là bộ nhớ này không được ghi lại vào bộ nhớ thiết bị và được dùng như bộ nhớ làm việc.

By Requesting Shared Memory 1 reduces the available L1 memory.

Bằng cách yêu cầu Bộ nhớ Chia sẻ, chúng ta giảm bộ nhớ L1 khả dụng.

This way data can be shared across threads in a block running on the same SM without going through L2.

Bằng cách này, dữ liệu có thể được chia sẻ giữa các luồng trong một khối chạy trên cùng một SM mà không cần đi qua L2.

This is also an effective measure to manage L1 cache manually.

Đây cũng là một biện pháp hiệu quả để quản lý bộ nhớ cache L1 thủ công.

If the desired caching is not achieved automatically.

Nếu việc lưu vào bộ nhớ cache mong muốn không đạt được tự động.

With ampere, the load global store shared instruction was introduced which allows to directly read data to shared memory without going through unmanaged L1 memory first.

Với Ampere, lệnh load global store shared đã được giới thiệu, cho phép đọc trực tiếp dữ liệu vào bộ nhớ chia sẻ mà không cần đi qua bộ nhớ L1 không được quản lý trước.

Just a brief Outlook Preloading data to shared memory is a commonly used pattern for sliding window operators like a convolution.

Chỉ một cái nhìn tổng quan ngắn gọn: Tải trước dữ liệu vào bộ nhớ chia sẻ là một mẫu phổ biến được sử dụng cho các toán tử cửa sổ trượt như tích chập.

All threads in the same CTA or also SM are used to preload data to sharp memory.

Tất cả các luồng trong cùng một CTA hoặc SM được sử dụng để tải trước dữ liệu vào bộ nhớ chia sẻ.

After that the data is accessed by all the other threads and the weights are persistent in L1 cache, for example.

Sau đó, dữ liệu được truy cập bởi tất cả các luồng khác và các trọng số được lưu trữ bền vững trong bộ nhớ cache L1, chẳng hạn.

This already brings us to the load and store address spaces used in our kernel, here shown as green boxes.

Điều này đã đưa chúng ta đến không gian địa chỉ tải và lưu trữ được sử dụng trong kernel của chúng ta, ở đây được hiển thị dưới dạng các hộp màu xanh lá cây.

The most basic loads are global and local loads that will load raw byte data.

Các lệnh tải cơ bản nhất là tải toàn cục và tải cục bộ sẽ tải dữ liệu byte thô.

For surface and texture loads we can possibly see different indexing schemes and for example for set ordered textures.

Đối với các lệnh tải bề mặt và kết cấu, chúng ta có thể thấy các lược đồ lập chỉ mục khác nhau và ví dụ đối với các kết cấu có thứ tự đã đặt.

Furthermore, we see the shared load operation for npm later GPUs that we talked about before.

Hơn nữa, chúng ta thấy hoạt động tải chia sẻ cho các GPU npm sau này mà chúng ta đã nói trước đó.

It is important to understand the difference between local and global load stores.

Điều quan trọng là phải hiểu sự khác biệt giữa các lệnh lưu trữ tải cục bộ và toàn cục.

Any local load and store is usually something we want to get rid of.

Bất kỳ lệnh tải và lưu trữ cục bộ nào thường là thứ chúng ta muốn loại bỏ.

The origin of these local operations is often due to register spilling for which I'll have a link in the video description.

Nguồn gốc của các hoạt động cục bộ này thường là do tràn thanh ghi mà tôi sẽ có một liên kết trong phần mô tả video.

This means the kernel is not able to keep its working data in the physical register file and has to write back to memory.

Điều này có nghĩa là kernel không thể giữ dữ liệu làm việc của nó trong tệp thanh ghi vật lý và phải ghi ngược trở lại bộ nhớ.

This has very strong performance implications.

Điều này có những tác động hiệu suất rất mạnh mẽ.

Finding the origin of those local operations can be done using this address space column of the memory chart or by using the Source page of NSight Compute and looking for LDL and STL instructions.

Việc tìm nguồn gốc của các hoạt động cục bộ đó có thể được thực hiện bằng cách sử dụng cột không gian địa chỉ này của biểu đồ bộ nhớ hoặc bằng cách sử dụng trang Nguồn của NSight Compute và tìm kiếm các lệnh LDL và STL.

The usage of this source page will be covered in a separate tutorial.

Cách sử dụng trang nguồn này sẽ được đề cập trong một hướng dẫn riêng.

Looking at it can be very helpful to identify the exact line of code that is responsible for this local access.

Xem xét nó có thể rất hữu ích để xác định chính xác dòng mã chịu trách nhiệm cho truy cập cục bộ này.

All absolute values that we see in the memory workload analysis chart are shown in the table below, which I will not go into detail about right now, but

Tất cả các giá trị tuyệt đối mà chúng ta thấy trong biểu đồ phân tích khối lượng công việc bộ nhớ được hiển thị trong bảng bên dưới, mà tôi sẽ không đi sâu vào chi tiết ngay bây giờ, nhưng

rather want to give some example usage on how to use this section.

thay vào đó muốn đưa ra một số ví dụ về cách sử dụng phần này.

The code for the following example can be found on GitHub and is linked in the video description we will profile this very simple program to convert an 8 bit PNG from RGBA to grayscale.

Mã cho ví dụ sau có thể được tìm thấy trên GitHub và được liên kết trong mô tả video, chúng ta sẽ phân tích cú pháp một chương trình rất đơn giản này để chuyển đổi PNG 8 bit từ RGBA sang thang độ xám.

What we do in our kernel we load four consecutive pixel values which are our corresponding RGBA values, apply a multiplier to each and add them up to a single grayscale float value.

Những gì chúng ta làm trong kernel của mình là tải bốn giá trị pixel liên tiếp, là các giá trị RGBA tương ứng của chúng ta, áp dụng một hệ số nhân cho mỗi giá trị và cộng chúng lại thành một giá trị float thang độ xám duy nhất.

Then we downcast and save it back to our output buffer.

Sau đó, chúng ta giảm cấp và lưu nó trở lại bộ đệm đầu ra của mình.

For now, I collapsed the optimized versions.

Hiện tại, tôi đã thu gọn các phiên bản được tối ưu hóa.

Please explore the code for those on GitHub.

Vui lòng khám phá mã cho những phiên bản đó trên GitHub.

First, let's make sure we have our theoretical values set.

Đầu tiên, hãy đảm bảo chúng ta đã thiết lập các giá trị lý thuyết của mình.

We are reading a 4 channel UN8 picture of size 3840 x 2160 and right at the same size but only 1 channel unit 8.

Chúng ta đang đọc một ảnh UN8 4 kênh có kích thước 3840 x 2160 và ngay lập tức có cùng kích thước nhưng chỉ 1 kênh đơn vị 8.

So we expect a load of around 33 megabyte and a store of around 8 MB.

Vì vậy, chúng ta kỳ vọng một lượt đọc khoảng 33 megabyte và một lượt ghi khoảng 8 MB.

While NSIGHT can give us a good measurement of how far we are from the CUDA device hardware limits, it cannot tell us if our processing approach is sub optimal.

Trong khi NSight Compute có thể cung cấp cho chúng ta một phép đo tốt về việc chúng ta còn cách xa giới hạn phần cứng thiết bị CUDA bao nhiêu, nó không thể cho chúng ta biết liệu cách tiếp cận xử lý của chúng ta có bị tối ưu hóa kém hay không.

This is something we should always keep in mind.

Đây là điều chúng ta nên luôn ghi nhớ.

I will use NSight Compute's capability to remotely profile using an SSH connection.

Tôi sẽ sử dụng khả năng của NSight Compute để cấu hình từ xa thông qua kết nối SSH.

We will start with creating a new project and establishing our connection.

Chúng ta sẽ bắt đầu bằng việc tạo một dự án mới và thiết lập kết nối của mình.

I usually name my project with a percent I in the name.

Tôi thường đặt tên dự án của mình với ký tự phần trăm I trong tên.

That way NSIGHT Compute will simply enumerate the profiles I take without overwriting an old file or me needing to remove an old file.

Bằng cách đó, NSight Compute sẽ đơn giản liệt kê các cấu hình tôi thực hiện mà không ghi đè tệp cũ hoặc tôi cần xóa tệp cũ.

To get the memory chart analysis, we have to either select the detailed profile or the full profile.

Để có được phân tích biểu đồ bộ nhớ, chúng ta phải chọn một trong hai tùy chọn: cấu hình chi tiết hoặc cấu hình đầy đủ.

I recommend simply going with the full profile.

Tôi khuyên bạn nên chọn cấu hình đầy đủ.

Furthermore, I also like to import the Source in the Others tab as it will allow me to track my source changes across my profiles in case I do not version them correctly.

Thêm vào đó, tôi cũng thích nhập Nguồn trong tab Khác vì nó sẽ cho phép tôi theo dõi các thay đổi nguồn của mình trên các hồ sơ của tôi trong trường hợp tôi không phiên bản chúng đúng cách.

Now we can simply hit the launch button on the first launch.

Bây giờ chúng ta có thể nhấn nút khởi chạy ngay lần khởi chạy đầu tiên.

It will upload all needed binaries which can actually take some time for me.

Nó sẽ tải lên tất cả các tệp nhị phân cần thiết mà thực tế có thể mất một thời gian đối với tôi.

I've done that already, so our baseline will straight pop up before we dive into our memory workload analysis.

Tôi đã làm điều đó rồi, vì vậy cơ sở của chúng ta sẽ hiện ra ngay trước khi chúng ta đi sâu vào phân tích khối lượng công việc bộ nhớ của mình.

We can already see in the Speed of light section that our memory speed of light is already at 8.

Chúng ta đã có thể thấy trong phần Tốc độ ánh sáng rằng tốc độ ánh sáng bộ nhớ của chúng ta đã là 8.

This usually indicates a very well performing kernel, but

Điều này thường cho thấy một kernel hoạt động rất tốt, nhưng

our compute speed of light is very low to me seems lower than expected.

tốc độ ánh sáng tính toán của chúng ta rất thấp, đối với tôi có vẻ thấp hơn mong đợi.

Looking at the Memory work node analysis section we see that the link to device memory is at very low peak utilization judging by its color, but

Nhìn vào phần phân tích nút công việc Bộ nhớ, chúng ta thấy rằng liên kết đến bộ nhớ thiết bị có mức sử dụng đỉnh rất thấp, xét theo màu sắc của nó, nhưng

the link between L2 and L1 shows much more data flow than we would expect given our pointwise operation.

liên kết giữa L2 và L1 cho thấy luồng dữ liệu nhiều hơn nhiều so với chúng ta mong đợi với phép toán điểm của mình.