
JAX 提供了强大的自动并行化能力,允许用户通过 sharding 机制将大型数组分布到多个设备(如 CPU、GPU 或 TPU)上进行计算。这种方法旨在通过并行处理来加速计算。然而,并非所有操作都能从 sharding 中获得同等益处,尤其是在处理具有强数据依赖性的操作时,不当的 sharding 策略甚至可能导致性能下降。本文将深入探讨在 JAX 分布式数组上执行离散差分 (jnp.diff) 操作时的性能考量。
JAX 中的 sharding 核心思想是将一个逻辑上的大数组物理地分割成多个小块(shard),并将这些小块分配给不同的计算设备。当对这些分片数组执行操作时,JAX 运行时会负责协调跨设备的计算和数据传输。jax.sharding.PositionalSharding 是一种常用的 sharding 方式,它允许用户根据设备的拓扑结构来定义数组的分片方式。
jnp.diff(x, n=1, axis=0) 函数计算数组 x 沿指定轴 axis 的 n 阶离散差分。例如,一阶差分 diff(x)[i] = x[i] - x[i-1]。这个定义明确指出,计算某个元素的差分需要访问其前一个元素。这种“相邻元素依赖”是理解 sharding 性能的关键。
为了探究 sharding 对 jnp.diff 性能的影响,我们设置了一个实验,使用 JAX 的自动并行化功能在多个 CPU 核心上测试不同 sharding 策略。实验代码如下:
import os
import jax as jx
import jax.numpy as jnp
import jax.experimental.mesh_utils as jxm
import jax.sharding as jsh
import timeit
# 设置 XLA 标志以强制 JAX 使用多个 CPU 设备
os.environ["XLA_FLAGS"] = (
f'--xla_force_host_platform_device_count=8'
)
# 定义离散差分核心函数
def calc_fd_kernel(x):
# 沿第一个轴计算一阶有限差分
# 使用 jnp.zeros 预填充,以保持输出形状与输入相同
return jnp.diff(
x, 1, axis=0, prepend=jnp.zeros((1, *x.shape[1:]))
)
# 编译差分核函数的工厂函数
def make_fd(shape, shardings):
# 使用 AOT (Ahead-Of-Time) 编译以获得最佳性能测量
return jx.jit(
calc_fd_kernel,
in_shardings=shardings,
out_shardings=shardings,
).lower(
jx.ShapeDtypeStruct(shape, jnp.dtype('f8'))
).compile()
# 创建一个 2D 数组进行分区
n = 2**12 # 4096
shape = (n, n,)
# 生成随机数据
x = jx.random.normal(jx.random.PRNGKey(0), shape, dtype='f8')
# 定义不同的 sharding 策略
# (1, 1): 无 sharding,单设备
# (8, 1): 沿第一个轴(差分轴)分片到 8 个设备
# (1, 8): 沿第二个轴(垂直于差分轴)分片到 8 个设备
shardings_config = {
(1, 1) : jsh.PositionalSharding(jxm.create_device_mesh((1,), devices=jx.devices("cpu")[:1])).reshape(1, 1),
(8, 1) : jsh.PositionalSharding(jxm.create_device_mesh((8,), devices=jx.devices("cpu")[:8])).reshape(8, 1),
(1, 8) : jsh.PositionalSharding(jxm.create_device_mesh((8,), devices=jx.devices("cpu")[:8])).reshape(1, 8),
}
# 将数据放置到不同 sharding 配置的设备上
x_sharded = {
mesh_spec : jx.device_put(x, shardings)
for mesh_spec, shardings in shardings_config.items()
}
# 为每种 sharding 配置编译差分函数
calc_fd_compiled = {
mesh_spec : make_fd(shape, shardings)
for mesh_spec, shardings in shardings_config.items()
}
print("开始性能测试:")
results = {}
for mesh_spec in shardings_config:
print(f"\n测试 sharding 配置 {mesh_spec}:")
stmt = f"calc_fd_compiled[{mesh_spec}](x_sharded[{mesh_spec}]).block_until_ready()"
# 使用 timeit 测量执行时间
# 转换为字符串以便 timeit 可以执行
time_taken = timeit.timeit(
stmt,
globals={
'calc_fd_compiled': calc_fd_compiled,
'x_sharded': x_sharded,
'mesh_spec': mesh_spec
},
number=10 # 运行次数
)
# timeit 返回的是总时间,这里除以 number 得到平均每次运行时间
avg_time_ms = (time_taken / 10) * 1000
results[mesh_spec] = avg_time_ms
print(f"平均运行时间: {avg_time_ms:.3f} ms")
print("\n--- 性能测试结果总结 ---")
for mesh_spec, time_ms in results.items():
print(f"Sharding {mesh_spec}: {time_ms:.3f} ms")
# 原始测试结果 (Jupyter %timeit 格式)
# (1, 1)
# 48.9 ms ± 414 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
# (8, 1)
# 977 ms ± 34.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
# (1, 8)
# 48.3 ms ± 1.03 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)观察到的性能结果:
实验结果清楚地表明,并非所有 sharding 策略都能带来性能提升,有时甚至会导致严重下降。
(8, 1) Sharding 导致性能下降的原因: 当数组沿 axis=0(即差分操作所在的轴)分片时,每个设备只拥有数组的一部分“行”。例如,设备 A 拥有 x[0...N/8-1, :],设备 B 拥有 x[N/8...2N/8-1, :]。为了计算 x[N/8, :] - x[N/8-1, :],设备 B 需要访问 x[N/8-1, :],而这部分数据位于设备 A 上。 这种跨设备的数据依赖性导致了频繁的设备间通信。每次需要从相邻设备获取数据时,都会产生显著的通信延迟,抵消了并行计算的潜在收益,甚至因为通信开销过大而导致整体性能急剧下降。这在分布式计算中被称为“边界交换”或“halo 交换”问题。
(1, 8) Sharding 未带来显著性能提升的原因: 当数组沿 axis=1(垂直于差分操作的轴)分片时,每个设备仍然拥有 axis=0 上的完整“列”或“切片”。例如,设备 A 拥有 x[:, 0...N/8-1],设备 B 拥有 x[:, N/8...2N/8-1]。计算 jnp.diff(x, axis=0) 时,每个设备可以在其本地数据上独立完成差分计算,无需与其他设备进行通信。 尽管避免了通信开销,但在此实验中,性能并未显著提升。这可能由以下原因造成:
从上述实验中,我们可以总结出在 JAX 中使用 sharding 的一些关键考量:
JAX 的 sharding 机制是实现大规模并行计算的强大工具,但其有效性高度依赖于具体的操作和所选的 sharding 策略。对于具有强数据依赖性的操作,如离散差分,沿依赖轴进行分片会导致昂贵的设备间通信,从而严重拖累性能。相反,如果能沿独立维度分片,则可以避免通信开销,尽管在某些情况下(如 CPU 上的特定操作),性能提升可能不明显。因此,在设计 JAX 分布式应用时,深入理解算法的数据依赖性、目标设备的特性以及仔细的性能测试是至关重要的。
以上就是JAX 分布式数组上的离散差分:性能考量与实践的详细内容,更多请关注php中文网其它相关文章!
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号