NVIDIA cuDSS Advances Solver Technologies for Engineering and Scientific Computing
NVIDIA cuDSS
is a first-generation sparse direct solver library designed to accelerate engineering and scientific computing. cuDSS is increasingly adopted in data centers and other environments and supports single-GPU, multi-GPU and multi-node (MGMN) configurations.
cuDSS has become a key tool for accelerating computer-aided engineering (CAE) workflows and scientific computations across multiple domains such as structural engineering, fluid dynamics, electromagnetics, circuit simulation, optimization, and AI-assisted engineering problems.
This post highlights some of the key performance and usability features delivered in
cuDSS v0.4.0
and
cuDSS v0.5.0
, as summarized in Table 1. cuDSS v0.4.0 achieves a significant performance boost for factorization and solve steps, while also introducing several new features, including the memory prediction API, automatic hybrid memory selection, and variable batch support. cuDSS v0.5.0 adds
host execution mode
, which is particularly beneficial for smaller matrices, and demonstrated substantial performance improvements using
hybrid memory mode
and host multithreading for analysis phase, an area that is typically challenging to parallelize effectively.
cuDSS v0.4.0 release
cuDSS v0.5.0 release
PIP wheel and Conda support
Factorization and solve performance improvements (up to 10x) for single and multi-GPU when factors have dense parts
Memory prediction API
Automatic normal/hybrid memory mode selection
Variable (non-uniform) batch support (variable N, NNZ, NRHS, LD)
Host execution mode (parts of computations on the host) for smaller matrices
Host multithreading (currently only for the reordering) with user-defined threading backend
New pivoting approach (static pivoting with scaling)
Improved performance and memory requirements for hybrid memory mode
Table 1. cuDSS features in releases v0.4.0 and v0.5.0
Feature highlights
This section focuses on notable usability enhancements and performance improvements.
Memory prediction API
The memory prediction API is important for users who need to know the precise amount of device and host memory required by cuDSS before reaching the most memory-intensive phase (numerical factorization).
It is especially useful in scenarios where device memory may be insufficient—either when solving large linear systems or when the application has a limited memory budget for cuDSS. In either case, it is recommended to enable
hybrid memory mode
before the analysis phase.
Note that if hybrid memory mode is enabled but everything fits within the available device memory (whether based on the user-defined limit or GPU capacity), cuDSS will automatically detect this and switch to the faster default memory mode.
A typical call sequence for solving a linear system with cuDSS is as follows:
Analysis (reordering and symbolic factorization)
Numerical factorization (where the values of the factors are allocated and computed)
Solving
With the introduction of memory prediction, users can now query the amount of device and host memory required for the chosen mode (either default or hybrid memory) after the analysis phase, as well as the minimum memory required for hybrid memory mode. As the sample below demonstrates, the query is a single call of
cudssDataGet
with
CUDSS_DATA_MEMORY_ESTIMATES
that writes an output in a small fixed-size array.
/*
 * After cudssExecute(..., CUDSS_PHASE_ANALYSIS, ,,,)
 */
int64_t memory_estimates[16] = {0};
cudssDataGet(cudssHandle, solverData, CUDSS_DATA_MEMORY_ESTIMATES,
    &memory_estimates, sizeof(memory_estimates);
/* memory_estimates[0] - permanent device memory
 * memory_estimates[1] - peak device memory
 * memory_estimates[2] - permanent host memory
 * memory_estimates[3] - peak host memory
 * memory_estimates[4] - minimum device memory for the hybrid memory mode
 * memory_estimates[5] - maximum host memory for the hybrid memory mode
 * memory_estimates[6,...,15] - reserved for future use
 */
To see the
full sample code
that makes use of this feature, visit the NVIDIA/CUDALibrarySamples GitHub repo.
Non-uniform batch API
In scenarios where the application requires solving multiple linear systems, and each system individually is not large enough to fully saturate the GPU, performance can be enhanced through batching. There are two types of batching: uniform and non-uniform. Unlike uniform batches, non-uniform batches do not impose restrictions on the dimensions or sparsity patterns of the matrices.
cuDSS v0.4.0 introduces support for non-uniform batches. The opaque
cudssMatrix_t
objects can represent either a single matrix or a batch of matrices and thus the only part that needs to be changed is how the matrix objects are created and modified.
To create batches of dense or sparse matrices, v0.4.0 introduced new APIs
cudssMatrixCreateBatchDn
or
cudssMatrixCreateBatchCsr
. For modifying the matrix data are the similarly added APIs
cudssMatrixSetBatchValues
and
cudssMatrixSetBatchCsrPointers
as well as
cudssMatrixGetBatchDn
and
cudssMatrixGetBatchCsr
. cuDSS v0.5.0 modifies
cudssMatrixFormat_t
which can now be queried using
cudssMatrixGetFormat
to determine whether
cudssMatrix_t
object is a single matrix or a batch.
Once the batches of matrices are created, they can be passed to the main calls of
cudssExecute
in the exact same way as if they were single matrices. The sample below demonstrates the use of new batch APIs to create batches of dense matrices for the solution and right-hand sides, and a batch of sparse matrices for As.
/*
 * For the batch API, scalar arguments like nrows, ncols, etc.
 * must be arrays of size batchCount of the specified integer type
 */
cudssMatrix_t b, x;
cudssMatrixCreateBatchDn(&b, batchCount, ncols, nrhs, ldb, batch_b_values, CUDA_R_32I, CUDA_R_64F, CUDSS_LAYOUT_COL_MAJOR);
cudssMatrixCreateBatchDn(&x, batchCount, nrows, nrhs, ldx, batch_x_values, CUDA_R_32I, CUDA_R_64F, CUDSS_LAYOUT_COL_MAJOR);
cudssMatrix_t A;
cudssMatrixCreateBatchDn(&A, batchCount, nrows, ncols, nnz, batch_csr_offsets, NULL, batch_csr_columns, batch_csr_values, CUDA_R_32I, CUDA_R_64F, mtype, mview, base);
/*
 * The rest of the workflow remains the same, incl. calls to cudssExecute() with batch matrices A, b and x
 */
To see the
full sample code
that makes use of this feature, visit the NVIDIA/CUDALibrarySamples GitHub repo.
Host multithreading API
Although most of the compute- and memory-intensive parts of cuDSS are executed on the GPU, some important tasks are still executed on the host. Prior to v0.5.0, cuDSS did not support multithreading (MT) on the host, and host execution was always single-threaded. The new release introduces support for arbitrary user-defined threading runtimes (such as
pthreads, OpenMP, and thread pools
), offering flexibility similar to how support was introduced for user-defined communication backends in the
MGMN mode
in cuDSS v0.3.0.
Among the tasks executed on the host, reordering (a critical part of the analysis phase) often stands out, as it can take a significant portion of the total execution time (analysis plus factorization plus solve). To address this common bottleneck in direct sparse solvers, cuDSS v0.5.0 introduces both general MT support on the host and a multithreaded version of reordering. Note that this is available only for the
CUDSS_ALG_DEFAULT
reordering algorithm.
As with the MGMN mode, the new MT mode is optional and does not introduce any new dependencies to the user application if not used. Enabling this feature in your application is simple—just set the name of the shim threading layer library using
cudssSetThreadingLayer
and (optionally) specify the maximum number of threads that cuDSS is allowed to use, as shown in the following sample:
/*
 * Before cudssExecute(CUDSS_PHASE_ANALYSIS)
 * thrLibFileName - filename to the cuDSS threading layer library
 * If NULL then export CUDSS_THREADING_LIB = ‘filename’
 */
cudssSetThreadingLayer(cudssHandle, thrLibFileName); 
/*
 * (optional)Set number of threads to be used by cuDSS
 */
int32_t nthr = ...;
cudssConfigSet(cudssHandle, solverConfig, CUDSS_CONFIG_HOST_NTHREADS,
    &nthr, sizeof(nthr);
To see the
full sample code
that makes use of this feature, visit the NVIDIA/CUDALibrarySamples GitHub repo.
Host execution
While the primary objective of cuDSS is to enable GPU acceleration for sparse direct solver functionality, for tiny and small matrices (which typically don’t have enough parallelism to saturate a GPU) an extensive use of the GPU can bring a non-negligible overhead. This can sometimes even dominate the total runtime.
To make cuDSS a more universal solution, v0.5.0 introduces the
host execute mode,
which enables factorization and solve phases on the host. When enabled, cuDSS will use a heuristic size-based dispatch to determine whether to perform part of the computations (during factorization and solve phases) on the host or on the device.
Additionally, when hybrid execution mode is enabled, users can pass host buffers for the matrix data which saves the needless memory transfers from the host to the device. Host execution mode doesn’t give cuDSS capabilities of a fully-fledged CPU solver, but helps to optionally remove the unwanted memory transfers and improve performance for small matrices.
The following sample demonstrates how to turn on hybrid execution mode.
/*
 * Before cudssExecute(CUDSS_PHASE_ANALYSIS)
 */
int hybrid_execute_mode = 1;
cudssConfigSet(solverConfig, CUDSS_CONFIG_HYBRID_EXECUTE_MODE,                                                                                     
        &hybrid_execute_mode, sizeof(hybrid_execute_mode);
To see the
full sample code
that makes use of this feature, visit the NVIDIA/CUDALibrarySamples GitHub repo.
Performance improvements of cuDSS v0.4.0 and v0.5.0
cuDSS v0.4.0 and v0.5.0  introduced significant performance improvements across several types of workloads.
In v0.4.0, the factorization and solve steps are accelerated by detecting when parts of the triangular factors become dense and leveraging more efficient dense BLAS kernels for those parts. The speedup achieved through this optimization depends largely on the symbolic structure of the factors, which in turn is influenced by the original matrix and the reordering permutation.
Figure 1 illustrates the performance improvement of v0.4.0 over v0.3.0, based on a large collection of matrices from the
SuiteSparse Matrix Collection
, analyzed on the NVIDIA H100 GPU.
Figure 1.  Performance improvement for the factorization and solve phases of cuDSS v0.4.0 over v0.3.0 for a variety of matrices from SuiteSparse Matrix Collection
As shown in the chart, both the factorization and solve phases saw substantial improvements, with geometric means of 1.74 and 2.0, respectively. Some matrices with relatively sparse triangular factors did not show significant speedups. However, matrices like
Serena
,
conf5_4_8x8_20
and
atmosmodd
(which come from various types of HPC applications) experienced speedups of more than 8x in the factorization phase and more than 6x in the solve phase.
The analysis phase also saw significant speedup, thanks to the multithreaded reordering introduced in cuDSS v0.5.0. Figure 2 compares the performance of the analysis phase between v0.5.0 and v0.4.0, using the same set of matrices from the SuiteSparse Matrix Collection.
The performance improvement arises from the fact that v0.4.0 used a single-threaded reordering implementation, while v0.5.0  leverages multiple CPU threads (cores) on the host. While it’s well-known that state-of-the-art reordering algorithms are notoriously difficult to parallelize efficiently, cuDSS v0.5.0 makes good use of multiple CPU cores, resulting in a solid geometric mean speedup of 1.98, with the maximum improvement reaching 4.82.
Note that the analysis phase includes both the (optionally multithreaded) reordering and symbolic factorization, which is performed on the GPU. Therefore, the actual speedup for the reordering part is likely even higher than what the chart indicates.
Figure 2. Performance improvement (analysis phase only) of cuDSS v0.5.0 over v0.4.0 for a variety of matrices from SuiteSparse Matrix Collection using host multithreading feature released in v0.5.0
cuDSS v0.5.0 further optimizes the performance of the
hybrid memory mode,
which was first introduced in v0.3.0 This feature allows part of the internal arrays used within cuDSS to reside on the host, enabling the solution of systems that don’t fit into the memory of a single GPU. It works particularly well on
NVIDIA Grace
-based systems, thanks to the significantly higher memory bandwidth between the CPU and GPU.
Figure 3 presents the performance speedup for the factorization and solve phases with cuDSS 0.5.0, comparing an NVIDIA Grace Hopper system (Grace CPU plus NVIDIA H100 GPU) against an x86 system (Intel Xeon Platinum 8480CL, 2S) plus NVIDIA H100 GPU, using a set of large matrices.
Figure 3. Performance improvement of cuDSS v0.5.0 with hybrid memory mode for a variety of matrices
As previously mentioned, v0.5.0 introduces the
hybrid execution mode
, which improves performance of cuDSS for small matrices. Figure 4 shows the speedup of the hybrid execution mode against the CPU solver (Intel MKL PARDISO) for the factorization and solve phases.
Figure 4. Performance improvement of cuDSS v0.5.0 with hybrid execution (enabling host execution) against the CPU solver for a variety of matrices
Finally, Figure 5 shows the speedup of the new hybrid execution mode (cuDSS v0.5.0) compared to the default mode (cuDSS v0.4.0) for the factorization and solve phases on a set of small matrices. While the speedup of the factorization phase is significant only for really small matrices, the solve phase delivers speedups for systems with up to 30K equations. This can be explained by the fact that the solve phase has less work compared to the factorization phase and cannot make good use of a GPU for the tested matrices.
Figure 5. Performance improvement of cuDSS v0.5.0 with hybrid execution for a variety of matrices
Summary
NVIDIA cuDSS v0.4.0 and v0.5.0 releases provide several new enhancements that significantly improve performance. Highlights include general speedups in factorization and solving, a hybrid memory and execution mode, host multithreading, and support for non-uniform batch sizes. In addition to our continued investment in performance, we will consistently enhance our APIs to expand functionality, providing users with greater flexibility and fine-grained control.
Ready to get started?
Download NVIDIA cuDSS v0.5.0
.
To learn more, check out the
cuDSS v0.5.0 release notes
and the following previous posts:
NVIDIA cuDSS Library Removes Barriers to Optimizing the US Power Grid
Spotlight: Honeywell Accelerates Industrial Process Simulation with NVIDIA cuDSS
Join the conversation and provide feedback in the
NVIDIA Developer Forum
.
NVIDIA cuDSS 提高工程和科学计算中的求解器技术
NVIDIA cuDSS
是第一代稀疏直接求解器库，旨在加速工程和科学计算。cuDSS 正越来越多地应用于数据中心和其他环境，并支持单 GPU、多 GPU 和多节点（MGMN）配置。
cuDSS 已成为加速多个领域 (例如结构工程、流体动力学、电磁学、电路模拟、优化和 AI 辅助工程问题) 的计算机辅助工程 (CAE) 工作流程和科学计算的关键工具。
本文重点介绍了
cuDSS v0.4.0
和
cuDSS v0.5.0
中提供的一些关键性能和可用性功能 (如表 1 中总结的内容)，cuDSS v0.4.0 可显著提升分解和求解步骤的性能，同时还引入了一些新功能，包括内存预测 API、自动混合内存选择和可变批量支持。cuDSS v0.5.0 增加了主机执行模式，这对较小的矩阵特别有利，并且在分析阶段使用混合内存模式和主机多线程实现了显著的性能提升，而有效并行化通常是一个具有挑战性的领域。
cuDSS v0.4.0 版本
cuDSS v0.5.0 版本
PIP wheel 和 Conda 支持在因子具有密集部分时，对单 GPU 和多 GPU 进行分解并解决性能提升 (高达 10 倍) 内存预测 API 自动选择正常/混合内存模式可变 (非均匀) 批量支持 (变量 N、NNZ、NRHS、LD)
较小矩阵的主机执行模式 (部分主机计算模式) 带有用户定义线程后端的主机多线程 (目前仅用于重新排序) 新的透视方法 (通过扩展进行静态透视) 提高了混合内存模式的性能和内存需求
表 1.版本 v0.4.0 和 v0.5.0 中的 cuDSS 功能
功能亮点
本节重点介绍显著的可用性增强和性能改进。
内存预测 API
对于需要在达到显存密集型阶段（数值分解）之前了解 cuDSS 所需设备和主机显存的精确数量的用户而言，内存预测 API 非常重要。
在设备显存不足的情况下，无论是求解大型线性系统，还是应用程序的 cuDSS 显存预算有限时，此功能尤其有用。在这两种情况下，建议在分析阶段之前启用混合显存模式。
请注意，如果混合显存模式已启用，但一切都适合可用设备显存 (无论是基于用户定义的限制还是 GPU 容量)，cuDSS 将自动检测到这一点并切换到更快的默认显存模式。
使用 cuDSS 求解线性系统的典型调用序列如下所示：
分析 (重新排序和符号分解)
数值分解（分配并计算因子值）
求解
引入 memory prediction 后，用户现在可以在分析阶段结束后查询所选模式（默认或 hybrid memory）所需的 device 和 host memory 数量，以及 hybrid memory 模式所需的最小 memory。如下示例所示，查询是使用
CUDSS_DATA_MEMORY_ESTIMATES
对
cudssDataGet
进行的一次调用，可将输出写入固定大小的小型数组中。
/*
 * After cudssExecute(..., CUDSS_PHASE_ANALYSIS, ,,,)
 */
int64_t memory_estimates[16] = {0};
cudssDataGet(cudssHandle, solverData, CUDSS_DATA_MEMORY_ESTIMATES,
    &memory_estimates, sizeof(memory_estimates);
/* memory_estimates[0] - permanent device memory
 * memory_estimates[1] - peak device memory
 * memory_estimates[2] - permanent host memory
 * memory_estimates[3] - peak host memory
 * memory_estimates[4] - minimum device memory for the hybrid memory mode
 * memory_estimates[5] - maximum host memory for the hybrid memory mode
 * memory_estimates[6,...,15] - reserved for future use
 */
要查看使用此功能的
完整示例代码
，请访问 NVIDIA/CUDALibrarySamples GitHub 存储库。
不均匀批处理 API
在应用程序需要求解多个线性系统，且每个系统单独不够大，无法使 GPU 完全饱和的情况下，可以通过批处理来提高性能。有两种类型的批处理：uniform 和 non-uniform。与 uniform 批量不同，non-uniform 批量不会对矩阵的维度或稀疏模式施加限制。
cuDSS v0.4.0 引入了对不均匀批量的支持。不透明的
cudssMatrix_t
对象可以表示单个矩阵，也可以表示批量矩阵，因此唯一需要更改的部分是创建和修改矩阵对象的方式。
为创建密集或稀疏矩阵的批量，v0.4.0 引入了新的 API
cudssMatrixCreateBatchDn
或
cudssMatrixCreateBatchCsr
、添加的类似 API
cudssMatrixSetBatchValues
和
cudssMatrixSetBatchCsrPointers
以及
cudssMatrixGetBatchDn
和
cudssMatrixGetBatchCsr
可用于修改矩阵数据。cuDSS v0.5.0 修改
cudssMatrixFormat_t
，现在可以使用
cudssMatrixGetFormat
查询 tg_10，以确定
cudssMatrix_t
对象是单个矩阵还是批量对象。
创建矩阵批量后，它们可以像单个矩阵一样以完全相同的方式传递给
cudssExecute
的主要调用。以下示例演示了如何使用新的批量 API 为解和右侧创建批量密集矩阵，并为 As 创建批量稀疏矩阵。
/*
 * For the batch API, scalar arguments like nrows, ncols, etc.
 * must be arrays of size batchCount of the specified integer type
 */
cudssMatrix_t b, x;
cudssMatrixCreateBatchDn(&b, batchCount, ncols, nrhs, ldb, batch_b_values, CUDA_R_32I, CUDA_R_64F, CUDSS_LAYOUT_COL_MAJOR);
cudssMatrixCreateBatchDn(&x, batchCount, nrows, nrhs, ldx, batch_x_values, CUDA_R_32I, CUDA_R_64F, CUDSS_LAYOUT_COL_MAJOR);
cudssMatrix_t A;
cudssMatrixCreateBatchDn(&A, batchCount, nrows, ncols, nnz, batch_csr_offsets, NULL, batch_csr_columns, batch_csr_values, CUDA_R_32I, CUDA_R_64F, mtype, mview, base);
/*
 * The rest of the workflow remains the same, incl. calls to cudssExecute() with batch matrices A, b and x
 */
要查看使用此功能的
完整示例代码
，请访问 NVIDIA/CUDALibrarySamples GitHub 存储库。
托管多线程 API
虽然 cuDSS 的大多数计算和内存密集型部分都在 GPU 上执行，但一些重要任务仍然在主机上执行。在 v0.5.0 之前，cuDSS 不支持主机上的多线程 (MT)，并且主机执行始终是单线程的。新版本引入了对任意用户定义线程运行时 (
例如 pthreads、OpenMP 和线程池
) 的支持，其灵活性与 cuDSS v0.3.0 中在
MGMN 模式
下引入对用户定义通信后端的支持类似。
在主机上执行的任务中，重新排序 (分析阶段的关键部分) 通常非常突出，因为它可能占用总执行时间 (分析加分解加解) 的很大一部分。为解决直接稀疏求解器中的常见瓶颈，cuDSS v0.5.0 在主机上引入了通用 MT 支持和多线程版本的重新排序。请注意，此功能仅适用于
CUDSS_ALG_DEFAULT
重排序算法。
与 MGMN 模式一样，新的 MT 模式是可选的，如果不使用，不会向用户应用引入任何新的依赖项。在应用中启用此功能非常简单 – 只需使用
cudssSetThreadingLayer
设置 shim 线程层库的名称，并 (可选) 指定允许 cuDSS 使用的最大线程数，如下例所示：
/*
 * Before cudssExecute(CUDSS_PHASE_ANALYSIS)
 * thrLibFileName - filename to the cuDSS threading layer library
 * If NULL then export CUDSS_THREADING_LIB = ‘filename’
 */
cudssSetThreadingLayer(cudssHandle, thrLibFileName); 
/*
 * (optional)Set number of threads to be used by cuDSS
 */
int32_t nthr = ...;
cudssConfigSet(cudssHandle, solverConfig, CUDSS_CONFIG_HOST_NTHREADS,
    &nthr, sizeof(nthr);
要查看使用此功能的
完整示例代码
，请访问 NVIDIA/CUDALibrarySamples GitHub 存储库。
主机执行
虽然 cuDSS 的主要目标是为稀疏直接求解器功能实现 GPU 加速，但对于微小的矩阵 (通常没有足够的并行度使 GPU 饱和)，广泛使用 GPU 会带来不可忽略的开销。有时，这甚至会主宰总运行时间。
为使 cuDSS 成为更通用的解决方案，v0.5.0 引入了
主机执行模式
，该模式可在主机上启用分解和求解阶段。启用 cuDSS 后，cuDSS 将使用基于大小的启发式分配来确定是否在主机或设备上执行部分计算 (在分解和求解阶段)。
此外，启用混合执行模式后，用户可以为矩阵数据传递主机缓冲区，从而节省从主机到设备的不必要的内存传输。主机执行模式无法提供成熟 CPU 求解器的 cuDSS 功能，但有助于选择性地消除不需要的内存传输，并提高小型矩阵的性能。
以下示例演示了如何开启混合执行模式。
/*
 * Before cudssExecute(CUDSS_PHASE_ANALYSIS)
 */
int hybrid_execute_mode = 1;
cudssConfigSet(solverConfig, CUDSS_CONFIG_HYBRID_EXECUTE_MODE,                                                                                     
        &hybrid_execute_mode, sizeof(hybrid_execute_mode);
要查看使用此功能的
完整示例代码
，请访问 NVIDIA/CUDALibrarySamples GitHub repo。
cuDSS v0.4.0 和 v0.5.0 的性能提升
cuDSS v0.4.0 和 v0.5.0 为多种类型的工作负载引入了显著的性能提升。
在 v0.4.0 中，通过检测三角形因子的某些部分何时变得密集，并为这些部分利用更高效的密集 BLAS 内核，可加速分解和求解步骤。通过此优化实现的加速在很大程度上取决于因子的符号结构，而符号结构又会受到原始矩阵和重新排序排列的影响。
根据 SuiteSparse 矩阵集合中的大量矩阵集合，并在 NVIDIA H100 GPU 上进行分析，图 1 展示了 v0.4.0 相较于 v0.3.0 的性能提升。
图 1. cuDSS v0.4.0 相对于 v0.3.0 对 SuiteSparse Matrix Collection 中各种矩阵的分解和求解阶段的性能有所提升
如图所示，分解阶段和求解阶段均有显著改进，几何均值分别为 1.74 和 2.0、一些三角形因子相对稀疏的矩阵并未显示出显著的加速。但是，
Serena
、
conf5_4_8x8_20
和
atmosmodd
(来自各种类型的 HPC 应用) 等矩阵在分解阶段的速度提升超过 8 倍，在求解阶段的速度提升超过 6 倍。
得益于 cuDSS v0.5.0 中引入的多线程重排序，分析阶段的速度也得到了显著提升。图 2 使用来自 SuiteSparse 矩阵集合的同一组矩阵，比较了 v0.5.0 和 v0.4.0 分析阶段的性能。
性能提升的原因是，v0.4.0 使用了单线程重排序实现，而 v0.5.0 则利用主机上的多个 CPU 线程 (cores)。众所周知，先进的重排序算法很难高效并行化，而 cuDSS v0.5.0 可以很好地利用多个 CPU cores，从而实现 1.98 的几何平均加速，最大提升可达 4.82。
请注意，分析阶段包括 (可选多线程) 重排序和符号分解，这在 GPU 上执行。因此，重新排序部分的实际加速可能甚至高于图表所示。
图 2、对于使用 v0.5.0 中发布的主机多线程功能的 SuiteSparse 矩阵集合中的各种矩阵，cuDSS v0.5.0 的性能比 v0.4.0 得到提升 (仅限分析阶段)
cuDSS v0.5.0 进一步优化了
混合显存模式
（最初在 v0.3.0 中引入）的性能。此功能允许 cuDSS 中使用的部分内部数组驻留在主机上，从而为不适合单个 GPU 内存的系统提供解决方案。由于 CPU 和 GPU 之间的内存带宽显著增加，它在基于
NVIDIA Grace
的系统上的运行效果尤为出色。
图 3 展示了 cuDSS 0.5.0 下分解和求解阶段的性能提升情况，并使用一组大型矩阵比较了 NVIDIA Grace Hopper 系统 (Grace CPU 加 NVIDIA H100 GPU) 与 x86 系统 (Intel Xeon Platinum 8480CL，2S) 加 NVIDIA H100 GPU 的性能提升情况。
图 3、cuDSS v0.5.0 借助混合显存模式，性能得到提升
如前所述，v0.5.0 引入了
混合执行模式
，可提高 cuDSS 在处理小型矩阵时的性能。图 4 显示了在分解和求解阶段，混合执行模式相对于 CPU 求解器 (Intel MKL PARDISO) 的加速情况。
图 4、cuDSS v0.5.0 通过混合执行 (启用主机执行) 相较于 CPU 求解器在各种矩阵中的性能提升
最后，图 5 显示了与默认模式 (cuDSS v0.4.0) 相比，新的混合执行模式 (cuDSS v0.5.0) 在一组小矩阵上分解和求解阶段的速度提升情况。虽然分解阶段的加速仅适用于非常小的矩阵，但求解阶段可为方程高达 30K 个的系统提供加速。这可以解释为，与分解阶段相比，求解阶段的工作量较少，并且无法充分利用 GPU 来测试矩阵。
图 5、cuDSS v0.5.0 的性能提升，支持各种矩阵的混合执行
总结
NVIDIA cuDSS v0.4.0 和 v0.5.0 版本提供了多项新的增强功能，可显著提高性能。亮点包括分解和求解方面的一般加速、混合内存和执行模式、主机多线程，以及对非均匀批量大小的支持。除了持续投资性能之外，我们还将持续增强 API 以扩展功能，为用户提供更高的灵活性和细粒度控制。
准备好开始使用了吗？下载 NVIDIA cuDSS v0.5.0。
如需了解更多信息，请查看
cuDSS v0.5.0 版本说明
以及之前的以下帖子：
NVIDIA cuDSS 库消除了优化美国电网的障碍
聚焦：Honeywell 借助 NVIDIA cuDSS 加速工业流程模拟
在
NVIDIA 开发者论坛
中加入对话并提供反馈。