评价此页
non_blockingpin_memory() 在 PyTorch 中的应用"

PyTorch 中 non_blockingpin_memory() 的使用指南#

创建日期:2024年7月31日 | 最后更新:2026年4月1日 | 最后验证:2024年11月5日

作者Vincent Moens

简介#

在许多 PyTorch 应用中,将数据从 CPU 传输到 GPU 是基础操作。用户了解设备间数据传输最有效的工具和选项至关重要。本教程将探讨 PyTorch 中设备间数据传输的两种关键方法:pin_memory() 和带有 non_blocking=True 选项的 to() 方法。

您将学到什么#

通过异步传输和内存锁定(memory pinning),可以优化张量从 CPU 到 GPU 的传输过程。然而,这里有一些重要的注意事项。

  • 使用 tensor.pin_memory().to(device, non_blocking=True) 可能比直接使用 tensor.to(device) 慢两倍。

  • 通常情况下,tensor.to(device, non_blocking=True) 是提高传输速度的有效选择。

  • 虽然 cpu_tensor.to("cuda", non_blocking=True).mean() 可以正确执行,但尝试使用 cuda_tensor.to("cpu", non_blocking=True).mean() 将导致错误的输出。

前言#

本教程中报告的性能基于构建本教程时所使用的系统。尽管结论适用于不同系统,但具体观察结果可能会根据可用硬件的不同(特别是在较旧的硬件上)而略有差异。本教程的主要目标是提供理解 CPU 到 GPU 数据传输的理论框架。然而,任何设计决策都应根据具体情况进行调整,并以基准测试的吞吐量测量以及任务的具体需求为指导。

import torch

assert torch.cuda.is_available(), "A cuda device is required to run this tutorial"

本教程需要安装 tensordict。如果您的环境中尚未安装 tensordict,请在单独的单元格中运行以下命令进行安装:

# Install tensordict with the following command
!pip3 install tensordict

我们首先概述这些概念背后的理论,然后进入这些功能的具体测试示例。

背景#

内存管理基础#

当在 PyTorch 中创建 CPU 张量时,该张量的内容需要放置在内存中。我们在这里讨论的内存是一个相当复杂的概念,值得仔细研究。我们区分由内存管理单元处理的两种内存类型:RAM(为简化起见)和磁盘上的交换空间(可能是硬盘,也可能不是)。磁盘和 RAM(物理内存)中的可用空间共同构成了虚拟内存,它是对可用资源总量的抽象。简而言之,虚拟内存使得可用空间比仅在 RAM 中能找到的空间更大,并创造出主内存比实际更大的错觉。

在正常情况下,常规 CPU 张量是可分页的(pageable),这意味着它被划分为称为“页面”的块,这些块可以存在于虚拟内存中的任何位置(无论是在 RAM 还是磁盘上)。如前所述,这样做的好处是内存看起来比实际主内存要大。

通常,当程序访问不在 RAM 中的页面时,会发生“页面错误”(page fault),操作系统(OS)随后会将此页面带回 RAM(“换入”或“页面调度入”)。反过来,OS 可能不得不换出(或“页面调度出”)另一个页面,为新页面腾出空间。

与可分页内存相反,锁定内存(pinned memory,也称为页锁定或不可分页内存)是一种不能被换出到磁盘的内存类型。它允许更快且更可预测的访问时间,但缺点是它比可分页内存(即主内存)更受限。

CUDA 与(非)可分页内存#

要了解 CUDA 如何将张量从 CPU 复制到 CUDA,让我们考虑上述两种情况:

  • 如果内存是页锁定的,设备可以直接访问主内存中的数据。内存地址定义明确,需要读取这些数据的函数可以得到显著加速。

  • 如果内存是可分页的,则必须在发送到 GPU 之前将所有页面带入主内存。此操作可能需要时间,并且比在页锁定张量上执行时更不可预测。

更准确地说,当 CUDA 将可分页数据从 CPU 发送到 GPU 时,它必须在进行传输之前首先创建该数据的页锁定副本。

异步与同步操作及 non_blocking=True (CUDA cudaMemcpyAsync)#

当执行从主机(如 CPU)到设备(如 GPU)的复制时,CUDA 工具包提供了相对于主机同步或异步执行这些操作的模式。

在实践中,当调用 to() 时,PyTorch 总是会调用 cudaMemcpyAsync。如果 non_blocking=False(默认值),则会在每次 cudaMemcpyAsync 之后调用 cudaStreamSynchronize,使得 to() 的调用在主线程中阻塞。如果 non_blocking=True,则不会触发同步,主机上的主线程也不会被阻塞。因此,从主机角度来看,可以同时将多个张量发送到设备,因为线程不需要等待一个传输完成才能启动另一个。

注意

通常,传输在设备端是阻塞的(即使在主机端不是):在执行其他操作时,设备上的复制无法发生。然而,在某些高级场景下,复制和内核执行可以在 GPU 端同时进行。如下例所示,必须满足三个要求才能实现这一点:

  1. 设备必须至少有一个空闲的 DMA(直接内存访问)引擎。现代 GPU 架构(如 Volterra、Tesla 或 H100 设备)具有不止一个 DMA 引擎。

  2. 传输必须在独立的、非默认的 CUDA 流上完成。在 PyTorch 中,可以使用 Stream 处理 CUDA 流。

  3. 源数据必须在锁定内存中。

我们通过对以下脚本运行性能分析来演示这一点。

import contextlib

from torch.cuda import Stream


s = Stream()

torch.manual_seed(42)
t1_cpu_pinned = torch.randn(1024**2 * 5, pin_memory=True)
t2_cpu_paged = torch.randn(1024**2 * 5, pin_memory=False)
t3_cuda = torch.randn(1024**2 * 5, device="cuda:0")

assert torch.cuda.is_available()
device = torch.device("cuda", torch.cuda.current_device())


# The function we want to profile
def inner(pinned: bool, streamed: bool):
    with torch.cuda.stream(s) if streamed else contextlib.nullcontext():
        if pinned:
            t1_cuda = t1_cpu_pinned.to(device, non_blocking=True)
        else:
            t2_cuda = t2_cpu_paged.to(device, non_blocking=True)
        t_star_cuda_h2d_event = s.record_event()
    # This operation can be executed during the CPU to GPU copy if and only if the tensor is pinned and the copy is
    #  done in the other stream
    t3_cuda_mul = t3_cuda * t3_cuda * t3_cuda
    t3_cuda_h2d_event = torch.cuda.current_stream().record_event()
    t_star_cuda_h2d_event.synchronize()
    t3_cuda_h2d_event.synchronize()


# Our profiler: profiles the `inner` function and stores the results in a .json file
def benchmark_with_profiler(
    pinned,
    streamed,
) -> None:
    torch._C._profiler._set_cuda_sync_enabled_val(True)
    wait, warmup, active = 1, 1, 2
    num_steps = wait + warmup + active
    rank = 0
    with torch.profiler.profile(
        activities=[
            torch.profiler.ProfilerActivity.CPU,
            torch.profiler.ProfilerActivity.CUDA,
        ],
        schedule=torch.profiler.schedule(
            wait=wait, warmup=warmup, active=active, repeat=1, skip_first=1
        ),
    ) as prof:
        for step_idx in range(1, num_steps + 1):
            inner(streamed=streamed, pinned=pinned)
            if rank is None or rank == 0:
                prof.step()
    prof.export_chrome_trace(f"trace_streamed{int(streamed)}_pinned{int(pinned)}.json")

在 Chrome 中加载这些分析追踪(chrome://tracing)显示了以下结果:首先,让我们看看如果 t3_cuda 上的算术运算在可分页张量被发送到主流中的 GPU 之后执行,会发生什么。

benchmark_with_profiler(streamed=False, pinned=False)
/usr/local/lib/python3.10/dist-packages/torch/profiler/profiler.py:272: UserWarning: Warning: Profiler clears events at the end of each cycle.Only events from the current cycle will be reported.To keep events across cycles, set acc_events=True.
  _warn_once(

使用锁定张量不会改变追踪太多,两个操作仍然是连续执行的。

benchmark_with_profiler(streamed=False, pinned=True)

将可分页张量发送到独立流上的 GPU 也是一个阻塞操作。

benchmark_with_profiler(streamed=True, pinned=False)

只有将锁定张量复制到独立流上的 GPU 才能与在主流上执行的另一个 CUDA 内核重叠。

benchmark_with_profiler(streamed=True, pinned=True)

PyTorch 视角#

pin_memory()#

PyTorch 提供了通过 pin_memory() 方法和构造函数参数创建并将张量发送到锁定内存的可能性。在初始化了 CUDA 的机器上,CPU 张量可以通过 pin_memory() 方法转换为锁定内存。重要的是,pin_memory 在主机的主线程上是阻塞的:它将等待张量被复制到锁定内存,然后才执行下一个操作。新张量可以直接使用诸如 zeros()ones() 等构造函数在锁定内存中创建。

让我们检查一下固定内存和将张量发送到 CUDA 的速度。

import torch
import gc
from torch.utils.benchmark import Timer
import matplotlib.pyplot as plt


def timer(cmd):
    median = (
        Timer(cmd, globals=globals())
        .adaptive_autorange(min_run_time=1.0, max_run_time=20.0)
        .median
        * 1000
    )
    print(f"{cmd}: {median: 4.4f} ms")
    return median


# A tensor in pageable memory
pageable_tensor = torch.randn(1_000_000)

# A tensor in page-locked (pinned) memory
pinned_tensor = torch.randn(1_000_000, pin_memory=True)

# Runtimes:
pageable_to_device = timer("pageable_tensor.to('cuda:0')")
pinned_to_device = timer("pinned_tensor.to('cuda:0')")
pin_mem = timer("pageable_tensor.pin_memory()")
pin_mem_to_device = timer("pageable_tensor.pin_memory().to('cuda:0')")

# Ratios:
r1 = pinned_to_device / pageable_to_device
r2 = pin_mem_to_device / pageable_to_device

# Create a figure with the results
fig, ax = plt.subplots()

xlabels = [0, 1, 2]
bar_labels = [
    "pageable_tensor.to(device) (1x)",
    f"pinned_tensor.to(device) ({r1:4.2f}x)",
    f"pageable_tensor.pin_memory().to(device) ({r2:4.2f}x)"
    f"\npin_memory()={100*pin_mem/pin_mem_to_device:.2f}% of runtime.",
]
values = [pageable_to_device, pinned_to_device, pin_mem_to_device]
colors = ["tab:blue", "tab:red", "tab:orange"]
ax.bar(xlabels, values, label=bar_labels, color=colors)

ax.set_ylabel("Runtime (ms)")
ax.set_title("Device casting runtime (pin-memory)")
ax.set_xticks([])
ax.legend()

plt.show()

# Clear tensors
del pageable_tensor, pinned_tensor
_ = gc.collect()
Device casting runtime (pin-memory)
pageable_tensor.to('cuda:0'):  0.3699 ms
pinned_tensor.to('cuda:0'):  0.3164 ms
pageable_tensor.pin_memory():  0.1097 ms
pageable_tensor.pin_memory().to('cuda:0'):  0.4305 ms

我们可以观察到,将锁定内存张量转换为 GPU 确实比可分页张量快得多,因为在底层,可分页张量在发送到 GPU 之前必须先复制到锁定内存中。

然而,与普遍看法相反,在将可分页张量转换为 GPU 之前对其调用 pin_memory() 不应该带来任何显著的加速;相反,此调用通常比直接执行传输要慢。这是合乎逻辑的,因为我们实际上是在要求 Python 执行一个 CUDA 在将数据从主机复制到设备之前无论如何都会执行的操作。

注意

PyTorch 对 pin_memory 的实现依赖于通过 cudaHostAlloc 在锁定内存中创建全新的存储,在极少数情况下,这可能比 cudaMemcpy 按块转换数据更快。同样,观察结果可能会根据可用硬件、发送的张量大小或可用 RAM 量而有所不同。

non_blocking=True#

如前所述,许多 PyTorch 操作可以选择通过 non_blocking 参数相对于主机异步执行。

为了准确评估使用 non_blocking 的好处,我们将设计一个稍微复杂的实验,因为我们要评估在调用和不调用 non_blocking 的情况下将多个张量发送到 GPU 的速度。

# A simple loop that copies all tensors to cuda
def copy_to_device(*tensors):
    result = []
    for tensor in tensors:
        result.append(tensor.to("cuda:0"))
    return result


# A loop that copies all tensors to cuda asynchronously
def copy_to_device_nonblocking(*tensors):
    result = []
    for tensor in tensors:
        result.append(tensor.to("cuda:0", non_blocking=True))
    # We need to synchronize
    torch.cuda.synchronize()
    return result


# Create a list of tensors
tensors = [torch.randn(1000) for _ in range(1000)]
to_device = timer("copy_to_device(*tensors)")
to_device_nonblocking = timer("copy_to_device_nonblocking(*tensors)")

# Ratio
r1 = to_device_nonblocking / to_device

# Plot the results
fig, ax = plt.subplots()

xlabels = [0, 1]
bar_labels = [f"to(device) (1x)", f"to(device, non_blocking=True) ({r1:4.2f}x)"]
colors = ["tab:blue", "tab:red"]
values = [to_device, to_device_nonblocking]

ax.bar(xlabels, values, label=bar_labels, color=colors)

ax.set_ylabel("Runtime (ms)")
ax.set_title("Device casting runtime (non-blocking)")
ax.set_xticks([])
ax.legend()

plt.show()
Device casting runtime (non-blocking)
copy_to_device(*tensors):  19.1453 ms
copy_to_device_nonblocking(*tensors):  14.8832 ms

为了更好地了解这里发生了什么,让我们对这两个函数进行分析。

from torch.profiler import profile, ProfilerActivity


def profile_mem(cmd):
    with profile(activities=[ProfilerActivity.CPU]) as prof:
        exec(cmd)
    print(cmd)
    print(prof.key_averages().table(row_limit=10))

首先让我们看看使用常规 to(device) 的调用堆栈。

print("Call to `to(device)`", profile_mem("copy_to_device(*tensors)"))
copy_to_device(*tensors)
-------------------------  ------------  ------------  ------------  ------------  ------------  ------------
                     Name    Self CPU %      Self CPU   CPU total %     CPU total  CPU time avg    # of Calls
-------------------------  ------------  ------------  ------------  ------------  ------------  ------------
                 aten::to         4.10%     999.084us       100.00%      24.338ms      24.338us          1000
           aten::_to_copy        12.41%       3.021ms        95.90%      23.339ms      23.339us          1000
      aten::empty_strided        19.08%       4.644ms        19.08%       4.644ms       4.644us          1000
              aten::copy_        26.86%       6.538ms        64.40%      15.674ms      15.674us          1000
    cudaStreamIsCapturing         1.85%     451.324us         1.85%     451.324us       0.451us          1000
          cudaMemcpyAsync        15.31%       3.726ms        15.31%       3.726ms       3.726us          1000
    cudaStreamSynchronize        20.37%       4.959ms        20.37%       4.959ms       4.959us          1000
-------------------------  ------------  ------------  ------------  ------------  ------------  ------------
Self CPU time total: 24.338ms

Call to `to(device)` None

现在是 non_blocking 版本。

print(
    "Call to `to(device, non_blocking=True)`",
    profile_mem("copy_to_device_nonblocking(*tensors)"),
)
copy_to_device_nonblocking(*tensors)
-------------------------  ------------  ------------  ------------  ------------  ------------  ------------
                     Name    Self CPU %      Self CPU   CPU total %     CPU total  CPU time avg    # of Calls
-------------------------  ------------  ------------  ------------  ------------  ------------  ------------
                 aten::to         5.11%       1.006ms        99.88%      19.670ms      19.670us          1000
           aten::_to_copy        14.87%       2.928ms        94.77%      18.665ms      18.665us          1000
      aten::empty_strided        22.73%       4.476ms        22.73%       4.476ms       4.476us          1000
              aten::copy_        35.46%       6.984ms        57.18%      11.261ms      11.261us          1000
    cudaStreamIsCapturing         2.40%     473.409us         2.40%     473.409us       0.473us          1000
          cudaMemcpyAsync        19.31%       3.804ms        19.31%       3.804ms       3.804us          1000
    cudaDeviceSynchronize         0.12%      23.581us         0.12%      23.581us      23.581us             1
-------------------------  ------------  ------------  ------------  ------------  ------------  ------------
Self CPU time total: 19.694ms

Call to `to(device, non_blocking=True)` None

当使用 non_blocking=True 时,结果无疑更好,因为所有传输都是在主机端同时启动的,并且只进行了一次同步。

收益将取决于张量的数量和大小,以及所使用的硬件。

注意

有趣的是,阻塞的 to("cuda") 实际上执行与带有 non_blocking=True 的相同的异步设备转换操作(cudaMemcpyAsync),只是在每次复制后都有一个同步点。

协同效应#

既然我们已经指出将已在锁定内存中的张量传输到 GPU 比从可分页内存传输更快,并且我们知道异步执行这些传输也比同步执行更快,我们可以对这些方法的组合进行基准测试。首先,让我们编写几个新函数,它们将对每个张量调用 pin_memoryto(device)

def pin_copy_to_device(*tensors):
    result = []
    for tensor in tensors:
        result.append(tensor.pin_memory().to("cuda:0"))
    return result


def pin_copy_to_device_nonblocking(*tensors):
    result = []
    for tensor in tensors:
        result.append(tensor.pin_memory().to("cuda:0", non_blocking=True))
    # We need to synchronize
    torch.cuda.synchronize()
    return result

使用 pin_memory() 的好处对于较大规模的大型张量批次更为显著。

tensors = [torch.randn(1_000_000) for _ in range(1000)]
page_copy = timer("copy_to_device(*tensors)")
page_copy_nb = timer("copy_to_device_nonblocking(*tensors)")

tensors_pinned = [torch.randn(1_000_000, pin_memory=True) for _ in range(1000)]
pinned_copy = timer("copy_to_device(*tensors_pinned)")
pinned_copy_nb = timer("copy_to_device_nonblocking(*tensors_pinned)")

pin_and_copy = timer("pin_copy_to_device(*tensors)")
pin_and_copy_nb = timer("pin_copy_to_device_nonblocking(*tensors)")

# Plot
strategies = ("pageable copy", "pinned copy", "pin and copy")
blocking = {
    "blocking": [page_copy, pinned_copy, pin_and_copy],
    "non-blocking": [page_copy_nb, pinned_copy_nb, pin_and_copy_nb],
}

x = torch.arange(3)
width = 0.25
multiplier = 0


fig, ax = plt.subplots(layout="constrained")

for attribute, runtimes in blocking.items():
    offset = width * multiplier
    rects = ax.bar(x + offset, runtimes, width, label=attribute)
    ax.bar_label(rects, padding=3, fmt="%.2f")
    multiplier += 1

# Add some text for labels, title and custom x-axis tick labels, etc.
ax.set_ylabel("Runtime (ms)")
ax.set_title("Runtime (pin-mem and non-blocking)")
ax.set_xticks([0, 1, 2])
ax.set_xticklabels(strategies)
plt.setp(ax.get_xticklabels(), rotation=45, ha="right", rotation_mode="anchor")
ax.legend(loc="upper left", ncols=3)

plt.show()

del tensors, tensors_pinned
_ = gc.collect()
Runtime (pin-mem and non-blocking)
copy_to_device(*tensors):  388.2546 ms
copy_to_device_nonblocking(*tensors):  308.4157 ms
copy_to_device(*tensors_pinned):  316.7515 ms
copy_to_device_nonblocking(*tensors_pinned):  299.6886 ms
pin_copy_to_device(*tensors):  564.9504 ms
pin_copy_to_device_nonblocking(*tensors):  325.8962 ms

其他复制方向(GPU -> CPU,CPU -> MPS)#

到目前为止,我们一直在假设从 CPU 到 GPU 的异步复制是安全的。这通常是正确的,因为当张量位于可分页内存中时,CUDA 会自动处理同步,以确保在读取时所访问的数据是有效的。

然而,在其他情况下,我们不能做同样的假设:当张量放置在锁定内存中时,在调用主机到设备传输后改变原始副本可能会损坏 GPU 上接收到的数据。同样,当传输在相反方向(从 GPU 到 CPU)或从任何不是 CPU 或 GPU 的设备到任何不是 CUDA 处理的 GPU 的设备(如 MPS)时,无法保证在没有显式同步的情况下读取 GPU 上的数据是有效的。

在这些场景中,这些传输不保证在访问数据时复制已完成。因此,主机上的数据可能是不完整或错误的,实际上使其变为垃圾数据。

让我们首先用一个锁定内存张量来演示这一点。

DELAY = 100000000
try:
    i = -1
    for i in range(100):
        # Create a tensor in pin-memory
        cpu_tensor = torch.ones(1024, 1024, pin_memory=True)
        torch.cuda.synchronize()
        # Send the tensor to CUDA
        cuda_tensor = cpu_tensor.to("cuda", non_blocking=True)
        torch.cuda._sleep(DELAY)
        # Corrupt the original tensor
        cpu_tensor.zero_()
        assert (cuda_tensor == 1).all()
    print("No test failed with non_blocking and pinned tensor")
except AssertionError:
    print(f"{i}th test failed with non_blocking and pinned tensor. Skipping remaining tests")
1th test failed with non_blocking and pinned tensor. Skipping remaining tests

使用可分页张量总是有效的。

i = -1
for i in range(100):
    # Create a tensor in pageable memory
    cpu_tensor = torch.ones(1024, 1024)
    torch.cuda.synchronize()
    # Send the tensor to CUDA
    cuda_tensor = cpu_tensor.to("cuda", non_blocking=True)
    torch.cuda._sleep(DELAY)
    # Corrupt the original tensor
    cpu_tensor.zero_()
    assert (cuda_tensor == 1).all()
print("No test failed with non_blocking and pageable tensor")
No test failed with non_blocking and pageable tensor

现在让我们演示 CUDA 到 CPU 在没有同步的情况下也无法产生可靠的输出。

tensor = (
    torch.arange(1, 1_000_000, dtype=torch.double, device="cuda")
    .expand(100, 999999)
    .clone()
)
torch.testing.assert_close(
    tensor.mean(), torch.tensor(500_000, dtype=torch.double, device="cuda")
), tensor.mean()
try:
    i = -1
    for i in range(100):
        cpu_tensor = tensor.to("cpu", non_blocking=True)
        torch.testing.assert_close(
            cpu_tensor.mean(), torch.tensor(500_000, dtype=torch.double)
        )
    print("No test failed with non_blocking")
except AssertionError:
    print(f"{i}th test failed with non_blocking. Skipping remaining tests")
try:
    i = -1
    for i in range(100):
        cpu_tensor = tensor.to("cpu", non_blocking=True)
        torch.cuda.synchronize()
        torch.testing.assert_close(
            cpu_tensor.mean(), torch.tensor(500_000, dtype=torch.double)
        )
    print("No test failed with synchronize")
except AssertionError:
    print(f"One test failed with synchronize: {i}th assertion!")
0th test failed with non_blocking. Skipping remaining tests
No test failed with synchronize

通常,仅当目标是 CUDA 启用设备且原始张量在可分页内存中时,到设备的异步复制在没有显式同步的情况下才是安全的。

总而言之,使用 non_blocking=True 从 CPU 复制数据到 GPU 是安全的,但对于任何其他方向,仍然可以使用 non_blocking=True,但用户必须确保在访问数据之前执行了设备同步。

实际建议#

我们现在可以根据观察结果总结一些初步建议。

通常,无论原始张量是否在锁定内存中,non_blocking=True 都能提供良好的吞吐量。如果张量已经在锁定内存中,传输可以被加速,但从 Python 主线程手动将其发送到锁定内存是一个主机端的阻塞操作,因此会抵消使用 non_blocking=True 的大部分好处(因为 CUDA 无论如何都会执行 pin_memory 传输)。

现在人们可能会合理地询问 pin_memory() 方法有什么用。在下一节中,我们将进一步探讨如何利用它来进一步加速数据传输。

附加考虑事项#

众所周知,PyTorch 提供了一个 DataLoader 类,其构造函数接受 pin_memory 参数。考虑到我们之前关于 pin_memory 的讨论,您可能想知道如果内存锁定本质上是阻塞的,DataLoader 如何设法加速数据传输。

关键在于 DataLoader 使用单独的线程来处理从可分页内存到锁定内存的数据传输,从而防止了主线程中的任何阻塞。

为了说明这一点,我们将使用来自同名库的 TensorDict 原语。调用 to() 时,默认行为是将张量异步发送到设备,随后在之后进行一次对 torch.device.synchronize() 的调用。

此外,TensorDict.to() 包括一个 non_blocking_pin 选项,它会启动多个线程在进行 to(device) 之前执行 pin_memory()。如下例所示,这种方法可以进一步加速数据传输。

from tensordict import TensorDict
import torch
from torch.utils.benchmark import Timer
import matplotlib.pyplot as plt

# Create the dataset
td = TensorDict({str(i): torch.randn(1_000_000) for i in range(1000)})

# Runtimes
copy_blocking = timer("td.to('cuda:0', non_blocking=False)")
copy_non_blocking = timer("td.to('cuda:0')")
copy_pin_nb = timer("td.to('cuda:0', non_blocking_pin=True, num_threads=0)")
copy_pin_multithread_nb = timer("td.to('cuda:0', non_blocking_pin=True, num_threads=4)")

# Rations
r1 = copy_non_blocking / copy_blocking
r2 = copy_pin_nb / copy_blocking
r3 = copy_pin_multithread_nb / copy_blocking

# Figure
fig, ax = plt.subplots()

xlabels = [0, 1, 2, 3]
bar_labels = [
    "Blocking copy (1x)",
    f"Non-blocking copy ({r1:4.2f}x)",
    f"Blocking pin, non-blocking copy ({r2:4.2f}x)",
    f"Non-blocking pin, non-blocking copy ({r3:4.2f}x)",
]
values = [copy_blocking, copy_non_blocking, copy_pin_nb, copy_pin_multithread_nb]
colors = ["tab:blue", "tab:red", "tab:orange", "tab:green"]

ax.bar(xlabels, values, label=bar_labels, color=colors)

ax.set_ylabel("Runtime (ms)")
ax.set_title("Device casting runtime")
ax.set_xticks([])
ax.legend()

plt.show()
Device casting runtime
td.to('cuda:0', non_blocking=False):  390.0167 ms
td.to('cuda:0'):  309.1665 ms
td.to('cuda:0', non_blocking_pin=True, num_threads=0):  321.1233 ms
td.to('cuda:0', non_blocking_pin=True, num_threads=4):  301.4280 ms

在此示例中,我们正在将许多大型张量从 CPU 传输到 GPU。此场景非常适合利用多线程 pin_memory(),这可以显著提高性能。但是,如果张量很小,与多线程相关的开销可能会超过好处。同样,如果只有少量张量,在单独线程上锁定张量的优势也会变得有限。

另外需要说明的是,虽然创建持久缓冲区在锁定内存中来穿梭从可分页内存传输到 GPU 之前的张量似乎很有利,但这种策略并不一定能加快计算速度。将数据复制到锁定内存所引起的固有瓶颈仍然是一个限制因素。

此外,将位于磁盘上的数据(无论是共享内存还是文件)传输到 GPU 通常需要将数据复制到锁定内存(位于 RAM 中)的中间步骤。在此上下文中为大型数据传输利用 non_blocking 会显著增加 RAM 消耗,可能导致不利影响。

在实践中,没有“一刀切”的解决方案。结合 non_blocking 传输使用多线程 pin_memory 的有效性取决于多种因素,包括特定的系统、操作系统、硬件以及所执行任务的性质。以下是在尝试加快 CPU 和 GPU 之间的数据传输,或跨场景比较吞吐量时需要检查的因素列表:

  • 可用核心数

    有多少 CPU 核心可用?系统是否与其他可能争夺资源的用户或进程共享?

  • 核心利用率

    CPU 核心是否被其他进程大量占用?应用程序是否在执行数据传输的同时执行其他 CPU 密集型任务?

  • 内存利用率

    当前正在使用多少可分页和页锁定内存?是否有足够的可用内存来分配额外的锁定内存而不影响系统性能?请记住,没有什么是免费的,例如 pin_memory 会消耗 RAM,并可能影响其他任务。

  • CUDA 设备能力

    GPU 是否支持多个 DMA 引擎用于并发数据传输?所使用的 CUDA 设备的具体能力和限制是什么?

  • 要发送的张量数量

    在典型操作中传输了多少张量?

  • 要发送的张量大小

    所传输张量的大小是多少?少数大型张量或许多小型张量可能无法从相同的传输程序中获益。

  • 系统架构

    系统架构如何影响数据传输速度(例如,总线速度、网络延迟)?

此外,在锁定内存中分配大量张量或相当大的张量会占用很大一部分 RAM。这减少了其他关键操作(如分页)的可用内存,这可能会对算法的整体性能产生负面影响。

结论#

在本教程中,我们探讨了从主机发送张量到设备时影响传输速度和内存管理的几个关键因素。我们了解到,使用 non_blocking=True 通常会加速数据传输,并且如果实施得当,pin_memory() 也可以提高性能。然而,这些技术需要仔细的设计和校准才能有效。

请记住,分析代码并关注内存消耗对于优化资源使用和获得最佳性能至关重要。

更多资源#

如果您在使用 CUDA 设备时遇到内存复制问题,或者想了解更多关于本教程中讨论的内容,请查看以下参考资料:

脚本运行总时间:(1 分钟 3.110 秒)