計算的歷史已經證明，用計算機硬件實現的相對簡單的算法所能實現的是無限的。但計算機用有限大小的數字表示的“真相”基本上是近似的。正如大衛·戈德伯格所寫，“ 將無限多個實數壓縮成有限位數需要一個近似表示 。”浮點是實數最廣泛使用的表示形式，在許多處理器中都有實現，包括 GPU 。它之所以受歡迎，是因為它能夠代表一個大的動態范圍的價值觀，并權衡范圍和精度。

不幸的是，浮點的靈活性和范圍可能會在某些應用程序中造成麻煩，因為在固定范圍內的精度更為重要：想想美元和美分。二進制浮點數不能準確地代表每一個十進制值，它們的近似值和舍入可能會導致累積錯誤，例如，在會計計算中可能是不可接受的。此外，添加非常大和非常小的浮點數可能會導致截斷錯誤。由于這些原因，許多貨幣和會計計算都是使用定點十進制算法實現的，該算法存儲固定數量的小數位數。根據所需的范圍，定點算法可能需要更多的位。

NVIDIA GPU 不在硬件中實現定點算法，但 GPU 加速的軟件實現可能是高效的。事實上， RAPIDS cuDF 庫已經提供了高效的 32 位和 64 位定點十進制數和計算。但是 RAPIDS cuDF 和 GPU 加速的 Apache Spark 的一些用戶需要 128 位小數提供的更高范圍和精度，現在 NVIDIA CUDA 11.5 提供了對 128 位整數類型(int128)的預覽支持，這是實現 128 位十進制算法所需的。

在本文中，在介紹 CUDA 新的 int128 支持后，我們將詳細介紹如何在其上實現十進制定點算法。然后，我們將演示 RAPIDS cuDF 中的 128 位定點支持如何使關鍵的 Apache Spark 工作負載完全在 GPU 上運行。

介紹 CUDA __int128

在 NVIDIA CUDA 11.5 中， NVCC 離線編譯器在主機編譯器支持的平臺上為有符號和無符號__int128數據類型添加了預覽支持。nvrtc JIT 編譯器還增加了對 128 位整數的支持，但需要一個命令行選項--device-int128來啟用這種支持。算術、邏輯和位運算都支持 128 位整數。請注意， DWARF 調試對 128 位整數的支持目前還不可用，并將在后續的 CUDA 版本中提供。在 11.6 版本中， cuda gdb 和 Nsight Visual Studio Code Edition 增加了對檢查這種新變量類型的支持。

NVIDIA GPU 以 32 位的數量計算整數，因此 128 位整數用四個 32 位無符號整數表示。加法、減法和乘法算法非常簡單，使用內置的 PTX addc / madc 指令處理多個精度值。除法和余數使用簡單的 O （ n ^ 2 ）除法算法實現，類似于 Brent 和 Zimmermann 的書 現代計算機算法 中的算法 1.6 ，并進行了一些優化，以改進商選擇步驟并最小化校正步驟。 128 位整數的一個令人振奮的用例是使用它們實現十進制定點算法。的 21.12 版本中包含 128 位十進制定點支持 RAPIDS libcudf .繼續閱讀，了解更多關于定點算法的信息，以及__int128如何用于實現高精度計算。

不動點算法

定點數字通過存儲小數部分的固定位數來表示實數。定點數字也可用于“省略”整數值的低階數字（即，如果你想表示 1000 的倍數，你可以使用一個 10 進制的定點數字，其刻度等于 3 ）。記住定點和浮點之間區別的一個簡單方法是，對于定點數字，小數點是固定的，而在浮點數字中，小數點可以浮動（移動）。

定點數字背后的基本思想是，即使所表示的值可以有小數位數（也就是 1.23 中的 0.23 ），實際上也可以將值存儲為整數。例如，為了表示 1.23 ，可以用scale = -2和值 123 構造一個fixed_point數字。通過將數值乘以小數位數，可以將這種表示轉換為浮點數。在我們的例子中， 1.23 是通過 123 （值）乘以 0.001 （ 10 （基數）乘以 -2 （刻度）的冪）得到的。當構造一個定點數時，會出現相反的情況，您可以“移位”該值，以便將其存儲為整數（如果使用的是小數點 -2 （ 0.001 （ 10 （基數）與 -2 （小數點）的冪之比），則浮點數為 1.23 時，您將除以 0.001 ）。

請注意，定點表示不是唯一的，因為可以選擇多個比例。對于 1.23 的示例，可以使用小于 -2 的任何比例，例如 -3 或 -4 。唯一的區別是存儲在磁盤上的數字不同； 123 表示刻度 -2 ， 1230 表示刻度 -3 ， 12300 表示刻度 -4 。當您知道您的用例只需要一組小數位時，您應該使用 least precise （又名最大）刻度來最大化可表示值的范圍。使用 -2 刻度時，范圍約為 -2000 萬至+ 2000 萬（小數點后兩位），而使用 -3 刻度時，范圍約為 -2 萬至+ 200 萬（小數點后三位）。如果你知道你是在為錢建模，而且不需要小數點后三位，那么 scale-2 是一個更好的選擇。

定點類型的另一個參數是 base 。在本文的例子中，以及在 RAPIDS cuDF 中，我們使用 10 進制，或十進制定點。十進制定點是最容易考慮的，因為我們對十進制（以 10 為基數）數字很熟悉。定點數的另一個常用基數是基數 2 ，也稱為二進制定點。這僅僅意味著，不是將數值按 10 的冪移動，而是將數值按 2 的冪移動。您可以在后面的“示例”部分中看到一些二進制和十進制定點值的示例。

定點與浮點

表 1 ：浮點和定點的比較。

絕對誤差是實際值與其計算機表示（以定點或浮點表示）之間的差值。相對誤差是絕對誤差與代表值之比。

為了演示定點可以解決的浮點表示問題，讓我們看看浮點是如何表示的。浮點數不能完全代表所有值。例如，與值 1.1 最接近的 32 位浮點數為 1.10000002384185791016 （ 看浮子。讓我們想象一下 ）。在執行算術運算時，尾隨的“不精確”可能會導致錯誤。例如， 1.1 + 1.1 的收益率為 2.2000000476837158231 。

圖 1 ：浮點 1.1 的可視化。

相比之下，使用定點表示時，使用整數存儲 exact 值。為了使用比例等于 -1 的定點數字表示 1.1 ，存儲值 11 。算術運算是在基礎整數上執行的，因此將 1.1 + 1.1 作為定點數相加，只需將 11 + 11 相加，就可以得到 22 ，正好代表值 2.2

為什么定點運算很重要？

如前一個例子所示，定點算法避免了浮點數固有的精度和舍入誤差，同時還提供了表示小數的能力。通過保持相對誤差恒定，浮點提供了更大的值范圍。然而，這意味著，當添加非常大和非常小的數字時，它可能會出現較大的絕對（截斷）錯誤，并會遇到舍入錯誤。固定點表示法總是有相同的 absolute 錯誤，代價是能夠表示縮小的值范圍。如果您知道小數點/二進制點后需要特定精度，則定點允許您在不截斷這些數字的情況下保持其精度，即使值增長到范圍的極限。如果你需要更多的范圍，你必須添加更多的位。因此，小數 128 對一些用戶來說變得很重要。

表 2 ：小數點 32 的范圍，小數點= 2 。

fixed_point編號有許多應用程序和用例。您可以找到使用fixed_point數字 on Wikipedia 的實際應用程序列表

fixed_point inRAPIDSlibcudf

概述

RAPIDS lib cuDF ` fixed _ point `類型的核心是一個簡單的類模板。

template 
class fixed_point { Rep _value; scale_type _scale;
}

fixed_point類的模板是：

• Rep:表示fixed_point數字（例如，使用的整數類型）
• Rad:數字的Radix（例如，基數 2 或基數 10 ）

decimal32和decimal64類型分別使用int32_t和int64_t作為 Rep ，并且都有Radix::BASE_10.。scale是一個強類型的運行時變量（請參見下面的運行時刻度和強類型小節等）。

fixed_point類型有幾個構造函數（請參見下面的“構造方法”小節）、可轉換為整型和浮點型的顯式轉換運算符，以及完整的運算符（加法、減法等）。

規模的跡象

在大多數 C ++定點實現（包括 RAPIDS LIbcUDF ）中，negative scale指示小數位數。positive scale表示可表示的倍數（例如，如果scale = 2表示decimal32，則可以表示 100 的倍數）。

auto const number_with_pos_scale = decimal32{1.2345, scale_type{-2}}; // 1.23
auto const number_with_neg_scale = decimal32{12345, scale_type{2}}; // 12300

建設者

libcudf中提供了以下（簡化的）構造函數：

fixed_point(T const& value, scale_type const& scale)
fixed_point(scaled_integer s) // already "shifted" value
fixed_point(T const& value) // scale = 0
fixed_point() // scale = 0, value = 0

其中，Rep是有符號整數類型，T可以是整數類型或浮點數。

設計與動機

libcudf 的fixed_point類型有許多設計目標。這些措施包括：

• 需要運行時量表
• 與潛在標準 C ++固定點類型的一致性
• 強類型

下面詳細介紹了這些設計動機。

運行時規模和第三方定點庫

在設計階段，我們研究了八個現有定點 C ++庫。不使用第三方庫的主要原因是，所有現有的定點類型/庫都是以scale作為編譯時參數設計的。這不適用于 RAPIDSlibcudf，因為它需要 scale 作為運行時參數。

雖然RAPIDS?libcudf是一個 C ++庫，可以在 C ++應用程序中使用，它也是后端RAPIDS cuDF，這是一個 Python 庫。 Python 是一種解釋（而非編譯，如 C ++）語言。此外， cuDF 必須能夠從其他數據源讀取或接收定點數據。這意味著我們不知道編譯時定點值的scale。因此，我們需要在fixed_pointRAPIDS 中輸入fixed_point類型，該類型具有運行時刻度參數。

我們引用的主要庫是CNL，John McFarlane的組成數字庫，目前是[VZX97 ]向C++標準中添加定點類型的參考。我們的目標是使 RAPIDSlibcudf fixed_point類型盡可能與潛在的標準化類型相似。下面是 RAPIDSlibcudf和CNL之間的一個簡單比較。

CNL （Godbolt Link）

using namespace cnl;
auto x = fixed_point{1.23};

RAPIDS libcudf

using namespace numeric;
auto x = fixed_point{1.23, scale_type{-2}};

或者：

using namespace numeric;
auto x = decimal32{1.23, scale_type{-2}};

這里需要注意的最重要的區別是，在 CNL 示例中，-2作為模板（又稱編譯時參數），而在 cuDF lib cuDF 示例中，scale_type{-2}作為運行時參數。

強類型

fixed_point類型的設計中融入了強類型。這方面的兩個例子是：

• 將scoped enumeration與direct-list-initialization對于刻度盤類型
• 對Radix使用作用域枚舉而不是整數類型

RAPIDS lib cuDF 堅持強類型最佳實踐和強類型API，因為強類型提供了保護和表達能力。與強大的打字相比，我不會進入較弱的兔子洞，但是如果你想了解更多關于它的信息，那么有很多很棒的資源，包括Jonathon Bocarra的VC++上的流暢的C++帖子。

添加對decimal128的支持

RAPIDSlibcudf21.12 將 CUDA 添加為受支持的fixed_point類型。這需要進行一些更改，第一個是添加依賴于decimal12811.5 提供的__int128類型的decimal128類型別名。

using decimal32 = fixed_point;
using decimal64 = fixed_point;
using decimal128 = fixed_point<__int128_t, Radix::BASE_10>;

這需要進行一些內部更改，包括更新類型特征函數__int128_t對某些函數的專門化，以及添加支持，以便cudf::column_view和朋友使用decimal128。以下簡單示例演示了 lib cuDF API 與decimal128的配合使用（注意，所有這些示例對decimal32和decimal64的作用相同）。

例子

簡單貨幣

一個簡單的貨幣示例使用libcudf提供的decimal32類型，其刻度為 -2 ，正好代表 17.29 美元：

auto const money = decimal32{17.29, scale_type{-2}};

大數和小數之和

當求大值和小值之和時，定點非常有用。作為一個簡單的玩具示例，下面的代碼將指數 -2 到 9 的 10 的冪相加。

template 
auto sum_powers_of_10() { auto iota = std::views::iota(-2, 10); return std::transform_reduce( iota.begin(), iota.end(), T{}, std::plus{}, [](auto e) -> T { return std::pow(10, e); });
}

比較 32 位浮點和十進制定點可以得出以下結果：

sum_powers_of_10(); // 1111111168.000000
sum_powers_of_10(); // 1111111111.11

其中decimal_type是 32 位的 10 進制定點類型。使用 Godbolthere上的 CNL 庫可以看到一個例子。

避免浮點舍入問題

下面是一段代碼（見Godbolt中），舉例說明浮點值遇到問題（在 C ++中）：

std::cout << std::roundf(256.49999) << '
'; // prints 257

RAPIDS lib cuDF 中的等效代碼不會有相同的問題（請參見Github上的內容）：

auto col = // decimal32 column with scale -5 and value 256.49999
auto result = cudf::round(input); // result is 256

256.4999 的值不能用 32 位二進制浮點表示，因此在調用 std :： roundf 函數之前，將其舍入到 256.5 。使用定點表示法可以避免這個問題，因為 256.4999 可以用任何具有五個或五個以上精度分數值的 10 進制（十進制）類型來表示。

二進制與十進制定點

// Decimal Fixed Point
using decimal32 = fixed_point;
auto const a = decimal32{17.29, scale_type{-2}}; // 17.29
auto const b = decimal32{4.2, scale_type{ 0}}; // 4
auto const c = decimal32{1729, scale_type{ 2}}; // 1700 // Binary Fixed Point
using binary32 = fixed_point;
auto const x = binary{17.29, scale_type{-2}}; // 17.25
auto const y = binary{4.2, scale_type{ 0}}; // 4
auto const z = binary{1729, scale_type{ 2}}; // 1728

小數 128

// Multiplying two decimal128 numbers
auto const x = decimal128{1.1, scale_type{-1});
auto const y = decimal128{2.2, scale_type{-1}};
auto const z = x * y; // 2.42 with scale equal to -2 // Adding two decimal128 numbers
auto const x = decimal128{1.1, scale_type{-1});
auto const y = decimal128{2.2, scale_type{-1}};
auto const z = x * y; // 3.3 with scale equal to -1 

DecimalType和 RAPIDS Spark

Apache Spark SQL 中的 DecimalType 是一種可以表示 Java BigDecimal 值的數據類型。對財務數據進行操作的 SQL 查詢大量使用十進制類型。與定點十進制數的 RAPIDS lib cuDF 實現不同， Spark 中的 DecimalType 可能的最大精度限制為 38 位。小數點后的位數也被限制在 38 。這個定義是 C ++刻度的否定。例如，像 0.12345 這樣的十進制值在 Spark 中的刻度為 5 ，但在 libcudf 中的刻度為 -5 。

Spark 嚴格遵循 Apache Hive 操作精度計算規范，并為用戶提供配置十進制操作精度損失的選項。 Spark SQL 在執行聚合、窗口、強制轉換等操作時積極提高結果列的精度。這種行為本身就是使小數 128 與現實世界的查詢極其相關的原因，它回答了一個問題：“為什么我們需要支持高精度的小數列？”。考慮下面的例子，特別是哈希骨灰，它有一個乘法表達式，涉及一個十進制 64 列，價格，和一個非十進制列，數量。 Spark 首先將非十進制列強制轉換為適當的十進制列。然后確定結果精度，該精度大于輸入精度。因此，即使涉及小數 64 個輸入，結果精度也是小數 128 的情況也很常見。

scala> val queryDfGpu = readPar.agg(sum('price*'quantity))
queryDfGpu1: org.apache.spark.sql.DataFrame = [sum((price * quantity)): decimal(32,2)] scala> queryDfGpu.explain
== Physical Plan ==
*(2) HashAggregate(keys=[], functions=[sum(CheckOverflow((promote_precision(cast(price#19 as decimal(12,2))) * promote_precision(cast(cast(quantity#20 as decimal(10,0)) as decimal(12,2)))), DecimalType(22,2), true))])
+- Exchange SinglePartition, true, [id=#429] +- *(1) HashAggregate(keys=[], functions=[partial_sum(CheckOverflow((promote_precision(cast(price#19 as decimal(12,2))) * promote_precision(cast(cast(quantity#20 as decimal(10,0)) as decimal(12,2)))), DecimalType(22,2), true))]) +- *(1) ColumnarToRow +- FileScan parquet [price#19,quantity#20] Batched: true,DataFilters: [], Format: Parquet, Location: InMemoryFileIndex[file:/tmp/dec_walmart.parquet], PartitionFilters: [], PushedFilters: [], ReadSchema: struct

隨著在 lib cuDF 中引入了新的小數 128 數據類型， Spark 的 RAPIDS 插件能夠利用更高的精度，并將計算保持在 GPU 上，而之前需要返回到 CPU 上。

作為一個例子，讓我們來看一個在以下模式下運行的簡單查詢。

{ id : IntegerType // Unique ID prodName : StringType // Product name will be used to aggregate / partition price	: DecimalType(11,2) // Decimal64 quantity : IntegerType // Quantity of product }

此查詢計算 totalCost 上的無界窗口，即總和（價格*數量）。然后，它會在排序后由 prodName 對結果進行分組，并返回最小總成本。

// Run window operation
val byProdName = Window.partitionBy('prodName)
val queryDfGpu = readPar.withColumn( "totalCost", sum('price*'quantity) over byProdName).sort( "prodName").groupBy( "prodName").min( "totalCost")

RAPIDS Spark 插件設置為僅當所有表達式都可以在 GPU 上計算時，才在 GPU 上運行運算符。讓我們先看看下面這個查詢的物理計劃，不支持小數 128 。）

如果不支持十進制 128 ，每個運算符都會返回 CPU ，因為無法支持包含十進制 128 類型的子表達式。因此，包含 exec 或父表達式的表達式也不會在 GPU 上執行，以避免低效的行到列和列到行轉換。

== Physical Plan ==
*(3) HashAggregate(keys=[prodName#18], functions=[min(totalCost#66)])
+- *(3) HashAggregate(keys=[prodName#18], functions=[partial_min(totalCost#66)]) +- *(3) Project [prodName#18, totalCost#66] +- Window [sum(_w0#67) windowspecdefinition(prodName#18, specifiedwindowframe(RowFrame, unboundedpreceding$(), unboundedfollowing$())) AS totalCost#66], [prodName#18] +- *(2) Sort [prodName#18 ASC NULLS FIRST], false, 0 +- Exchange hashpartitioning(prodName#18, 1), true, [id=#169] +- *(1) Project [prodName#18, CheckOverflow((promote_precision(cast(price#19 as decimal(12,2))) * promote_precision(cast(cast(quantity#20 as decimal(10,0)) as decimal(12,2)))), DecimalType(22,2), true) AS _w0#67] +- *(1) ColumnarToRow +- FileScan parquet [prodName#18,price#19,quantity#20] Batched: true, DataFilters: [], Format: Parquet, Location: InMemoryFileIndex[file:/tmp/dec_walmart.parquet], PartitionFilters: [], PushedFilters: [], ReadSchema: struct

啟用小數 128 支持后的查詢計劃顯示，所有操作現在都可以在 GPU 上運行。由于沒有 ColumnarToRow 和 RowToColumnar 轉換（在查詢中顯示為 collect 操作），因此通過在 GPU 上運行整個查詢，可以獲得更好的性能。

== Physical Plan ==
GpuColumnarToRow false
+- GpuHashAggregate(keys=[prodName#18], functions=[gpumin(totalCost#31)]),
filters=ArrayBuffer(None)) +- GpuHashAggregate(keys=[prodName#18], functions=[partial_gpumin(totalCost#31)]), filters=ArrayBuffer(None)) +- GpuProject [prodName#18, totalCost#31] +- GpuWindow [prodName#18, _w0#32, gpusum(_w0#32, DecimalType(32,2)) gpuwindowspecdefinition(prodName#18, gpuspecifiedwindowframe(RowFrame, gpuspecialframeboundary(unboundedpreceding$()), gpuspecialframeboundary(unboundedfollowing$()))) AS totalCost#31], [prodName#18] +- GpuCoalesceBatches batchedbykey(prodName#18 ASC NULLS FIRST) +- GpuSort [prodName#18 ASC NULLS FIRST], false, com.nvidia.spark.rapids.OutOfCoreSort$@3204b591 +- GpuShuffleCoalesce 2147483647 +- GpuColumnarExchange gpuhashpartitioning(prodName#18, 1), true, [id=#57] +- GpuProject [prodName#18, gpucheckoverflow((gpupromoteprecision(cast(price#19 as decimal(12,2))) * gpupromoteprecision(cast(cast(quantity#20 as decimal(10,0)) as decimal(12,2)))), DecimalType(22,2), true) AS _w0#32] +- GpuFileGpuScan parquet [prodName#18,price#19,quantity#20] Batched: true, DataFilters: [], Format: Parquet, Location: InMemoryFileIndex[file:/tmp/dec_walmart.parquet], PartitionFilters: [], PushedFilters: [], ReadSchema: struct

對于乘法運算，數量列轉換為小數 64 （精度= 10 ），價格列（已為小數 64 類型）轉換為精度 12 ，使兩列的類型相同。結果列的大小調整為精度 22 ，這是小數 128 類型，因為精度大于 18 。這顯示在上面計劃的 GpuProject 節點中。

對 sum （）的窗口操作也將精度進一步提升到 32 。

我們使用 NVIDIA 決策支持（ NDS ）來衡量加速比， NDS 是 Spark 客戶和提供商經常使用的 TPC-DS 數據科學基準的一種改編。 NDS 包含與行業標準基準相同的 100 多個 SQL 查詢，但修改了數據集生成和執行腳本的部分。? NDS 的結果與 TPC-DS 不可比。

NDS 查詢子集的初步運行表明，由于支持小數 128 ，性能顯著提高，如下圖所示。它們在八個節點組成的集群上運行，每個節點有一個 A100 GPU 和 1024 CPU 內核，在 Spark 3.1.1 上運行 16 個內核的執行器。每個執行器在內存中使用 240GiB 。這些查詢顯示了接近 8 倍的出色加速，這可以歸因于以前的操作回到了現在在 GPU 上運行的 CPU ，從而避免了行到列和列到行的轉換以及其他相關的開銷。所有 NDS 查詢的端到端運行時間平均提高了 2 倍。這（希望）只是一個開始！

圖 2 :NDS 查詢子集的性能評估.

隨著 Spark Spark 插件的 21.12 版本發布，大多數操作員都可以使用十進制 128 支持。需要對溢出條件進行一些特殊處理，以保持 CPU 和 GPU 之間的結果兼容性。這項工作的最終目標是通過 RAPIDS for Spark 插件，讓零售和金融查詢充分受益于 GPU 的加速。

總結

RAPIDS libcudf 中的固定點類型、 DecimalType 的添加以及 Spark 的 RAPIDS 插件的 decimal128 支持，使得以前只有在 CPU 上才可能在 GPU 上運行的激動人心的用例成為可能。

關于作者

Conor Hoekstra 是 NVIDIA 的高級圖書館軟件工程師，在 RAPIDS 團隊工作。他對編程語言、算法和漂亮的代碼非常熱衷。他是編程語言虛擬 Meetup 的創始人和組織者，他有一個 YouTube 頻道，他是兩個播客的主持人：算法+數據結構=程序和 ArrayCast 。康納還是 CPPNNorth 會議的項目主席，也是一位熱心的會議發言人。

Kuhu Shukla 是 NVIDIA Spark- GPU 團隊的高級軟件工程師。在此之前，她是雅虎 Hadoop 核心團隊的成員！在伊利諾伊州香檳市的 Apache Tez 、 Thread 和 HDFS 等大數據平臺上工作。她是 Apache Tez 項目的 PMC 。她在北卡羅來納州立大學獲得了計算機科學碩士學位。

Mark Harris 是 NVIDIA 杰出的工程師，致力于 RAPIDS 。 Mark 擁有超過 20 年的 GPUs 軟件開發經驗，從圖形和游戲到基于物理的模擬，到并行算法和高性能計算。當他還是北卡羅來納大學的博士生時，他意識到了一種新生的趨勢，并為此創造了一個名字： GPGPU （圖形處理單元上的通用計算）。

審核編輯：郭婷