GPUによる多倍長整数乗算の高速化手法の提案とその評価

大阪府立大学
大学院理学系研究科情報数理科学専攻
☆北野晃司藤本典幸

 現在主流の整数型
◦ 32bit
◦ 64bit
 多倍長整数演算
◦ 1ワードに収まらない整数を対象とした演算
◦ 研究が盛ん
 GPGPU
◦ GPUによる汎用計算
◦ 近年注目されている

2 大阪府立大学北野晃司 Next⇒動機・目的

 多倍長整数演算は時間がかかる
◦ 特に積、商、平方根の演算
 商、平方根
◦ ニュートン法を用いて高速化可能
 高速な乗算が使える場合
 GPUを用いて多倍長整数乗算を高速に解く手法を提
案
※ニュートン法による逆数を求める漸化式⇒Xn+1=2*Xn－a*Xn^2
平方根を求める漸化式⇒Xn+1=(Xn + a/Xn) /2 aは適当な初期
値

3 大阪府立大学北野晃司
Next⇒提案内容

 積表という並列処理に適した
データ構造とその処理法の提案

 ２つの多倍長整数の和を高速に求める
アルゴリズムの実装方法

4 大阪府立大学北野晃司 Next⇒発表の流れ

 GPUによる並列処理の概要時間の都合により割愛

 提案手法

 評価実験

 まとめと今後の課題


 GPUによる並列処理の概要
 提案手法
◦ 積表
◦ 積表に対する効率的な処理法の提案
 概要とその利点
 具体的な処理の流れ
◦ 列総和配列から積への変換
◦ 多倍長整数の和を求めるアルゴリズムの実装方法
 評価実験


• 10進数における積
 積表
◦ – 筆算を元に得られた表
右図のような筆算で求めることが可
能 2 0
– 下位からの桁上げ値をその値が
必要な列自身に計算させる？
縦方向に並列に計算できるか？
– 列ごとの総和が他の列の演算と縦の総和から積への変
換
⇒主な問題が２つ
は独立に行える

1. 各値が下位からの桁上げ値を
必要とすること
2. 縦方向に総和計算を行うだけでは
正しい積の１桁にならないこと
後半で解決

7 大阪府立大学北野晃司 Next⇒積表の構成

 多倍長整数A×Bの積表
◦ Aは5桁、Bは3桁
◦ BASEは多倍長整数の基数
◦ BASE=10なら10進数
◦ A[0]がAの1の位の数
～～～～～～～～～～～～～～～～～～～
 要素の規則性
◦ 2行ごとに添字が1変わる
◦ 桁数を変えても同様

8 大阪府立大学北野晃司 Next⇒積表の一般化

 多倍長整数A×Bの積表
◦ Aはa桁、Bはb桁（a≧b）
 赤と緑の部分
◦ 列数は共にb列
◦ 行数は1列毎に2行ずつ増減
 黄の部分
◦ 列数はa－b列
◦ 行数はb×2行

9 大阪府立大学北野晃司 Next⇒積表の単純な処理法

：1スレッ
 積表の処理ド
◦ 1列に1スレッドの割り当て
◦ 列ごとの総和計算

 この処理の欠点
◦ スレッド毎の演算回数の差
◦ 処理が早く終わったスレッド
はただ待つだけ
◦ 演算器が遊んでフルに性能が
発揮できない

10 大阪府立大学北野晃司 Next⇒積表の再構成

 欠点を解決するための変形
◦ 緑の部分を赤の部分に結合
◦ 列数は(a-b)+b=a列
◦ 行数はb×2行

11 大阪府立大学北野晃司 Next⇒再構成した積表の要素

A[0]×B[0]%BASE
α列

• 積表内の要素は、同色内で
A[α]×B[0]%BASE
は上下の順番は結果に無関 A[a-1]×B[0]/BASE
係 A[α-1]×B[0]/BASE
A[a-1]×B[1]%BASE
A[α-1]×B[1]%BASE
• 適切に並び替え、
次の性質を持たせる A[a-2]×B[1]/BASE ・
• 右からα列目では0行目でAの A[α-2]×B[1]/BASE
添字αの要素を参照
・
• 行が下に行くと、2行間隔で A[a-2]×B[2]%BASE
A[α-2]×B[2]%BASE ・
参照するAの添字は1減少・
• Aの添字がマイナスになる時 A[a-3]×B[2]/BASE
・
は0-1⇒a-1として参照・
• どの列においても、β行ではB
の添字⌊β/2 ⌋を参照
• 偶数行では基数で割った剰余、
奇数行では基数で割った商
Next⇒再構成した積表の具体

 5桁×3桁での例
◦ 赤と緑、黄、の2種類の長方形

• 列総和計算に必要な演算回数
– どの列も同じ(2×b 回)
• 赤と緑の長方形
– 赤の総和と緑の総和が個別に必要なことに注意
13 大阪府立大学北野晃司 Next⇒効率的な処理法の提

 提案手法
◦ 積表
 評価実験


 水色の領域
◦ 赤のみを含む・緑のみを
含む・境界を含むの3種類
◦ 1ブロックが1領域を担当

領域分けによって利点が
２つ生まれる

※BLOCK_SIZE=１ブロック中のスレッド数

15 大阪府立大学北野晃司 Next⇒領域分けによる利点

512列
b列
・
GPU GTX480では・
例え
最大23040スレッドが・
ば・・・
同時にアクティブになれ
る 1
b×
0 ・
2
2 512スレッド並
・
4
行
これは並列性の低い手法行列・
領域分けは並列性を高める
Aは1024桁 Bは512桁とな
る
例：BLOCK_SIZE=16な
ら
16 16384スレッド並列
大阪府立大学北野晃司 Next⇒領域分けによる利点

 1つの領域内で列総和計算に必要なAの要素数が
BLOCK_SIZE×2、Bの要素数がBLOCK_SIZE
◦ sharedメモリに乗せることが可能なデータ数
◦ sharedメモリの使用によりデバイスメモリの参照回数が
減少

今回の実験環境の場合 GTX480

1MPが使用するsharedメモ
リは最大18KB＜48KB sharedメモリ 48KB設
定
1MP:最大1536スレッドアクティブ

BLOCK_SIZE=256
１ブロック：sharedメモリ 3KB使用

17 大阪府立大学北野晃司 Next⇒具体的な処理の流れ

 提案手法
◦ 積表
 評価実験


列総和計算に必要なAとBの要素を
すべてsharedメモリに載せる

sharedメモリ上の要素を用いて赤と緑
の部分の列総和を個別に求めていく

求めた列総和を列総和配列の
適切な場所へ足し込む

19 大阪府立大学北野晃司 Next⇒最初の処理について

列総和計算に必要なAとBの要素を
すべてsharedメモリに載せる

BLOCK_SIZE×2
a-1 10 AのBLOCK_SIZE×2要素
A ・・・ BのBLOCK_SIZE要素が必要
BLOCK_SIZE
b-1 10
B ・・・これら要素はすべて
A、B内で連続した要
コアレスアクセ
ス素
可能

20 大阪府立大学北野晃司 Next⇒２つ目の処理につい

sharedメモリ上の要素を用いて赤と緑
の部分の列総和を個別に求めていく
↓Aの要素を格納したsharedメモリ
・・・

・・ ←1ウォー
・プ
・・・
↑Bの要素を格納したsharedメモリ
バンクコンフリクトを
回避
21 大阪府立大学北野晃司 Next⇒最後の処理について

求めた列総和を列総和配列の
適切な場所へ足し込む
・
• 列colを計算するスレッド・総
• 赤の部分の総和・列
和
• 列総和を格納する配列Sの添字col 総
の
へ足し込む和
足
• 緑の部分の総和し
計
• 配列Sの添字col+a(Aの桁数)へ込
算
足し込むみ

S ・・・・・
・・・・
22 大阪府立大学北野晃司 Next⇒黄の長方形の処理

 先と同様に領域分け
◦ 赤のみ（緑のみ）に対する処理
と同様
 それらとの違い
◦ 参照するAやBの添字
◦ 総和を足し込むSの添字

Next⇒列総和配列から積への変換

 提案手法
◦ 積表
 評価実験


• 列総和配列Sの一例（10進数での例）
S 6 18 45 98 48 34 15 78 64 57

• Sのそれぞれの要素を基数で割った商を配列S2に格納
• Sは基数で割った剰余に変更
S 6 8 全要素が基数に収まる 8
5 8多倍長整数 5
8 4 4 7
S2 0 1 4 9 ように処理が必要 6
4多倍長整数 7
3 1 5 0

• 多倍長整数和S+S2の計算
S+S2 0 8 3 5 3 1 6 3 4 9 7

以上の結果S+S2が多倍長整数AとBの積とな
る

大阪府立大学北野晃司
25 Next⇒多倍長整数和を求めるアルゴリズムの実装方法

 提案手法
◦ 積表
 評価実験


 対応する１桁同士の和を並列に計算し、
繰り上がりの処理すると・・・
 連続した繰り上がりの伝播が性能を下げ
る・・
伝播・伝播
伝播繰り上がり
伝播繰り上がり
＋＋＋＋＋＋＋
・
・・・
・・
遂次性の強い計算

Next⇒伝播も考慮したアルゴリズ

 様々な方法が存在
 今回実装するのは全加算器の実装方法
carry skip adderと本質的に同じ

 ただし
◦ 伝播が少ない場合にはより高速に計算できるように
工夫
◦ さらに、基数を大きくして伝播の確率を下げる

28 大阪府立大学北野晃司 Next⇒実装するアルゴリズ

X 1 5 8 6 6 2 5 3 3 9
X、Y、繰り上がり情報
 多倍長整数和X＋Yを求める
 繰り上がり情報が2であ
Y 2 6 1 3 2 9 4 9 4 5
 XとYの各桁から繰り上がり
る部分を書き換える
配列Zの3配列の要素を
 情報の配列Zを得る
2の前が1なら1、0なら0 Z
足し合わせる 0 1 2 2 0 1 2 1 0 1 0
 に
得られた配列の全要素
 2が連続しているなら下
を基数で割った剰余に 0 1 2 0 0 1 1 1 0 1 0
位から上位へ遂次的に処
 繰り上がり情報
理 Z 0 1 0 0 0 1 1 1 0 1 0
◦ 1:各桁の和≧基数
1:繰り上がりあり
2:各桁の和＝基数-1（例では
◦ 2:伝播の可能性あり
◦ 9）
0:繰り上がりなし
◦ 0:いずれでもない X+Y 4 1 9 9 9 2 0 2 8 4

29 大阪府立大学北野晃司 Next⇒評価実験

 提案手法
 評価実験
◦ CPUによる多倍長演算ライブラリとの比較
◦ GPUによる既存の研究との比較


 NTL（A Library for doing Number Theory）
◦ CPUによる多倍長演算ライブラリ（SIMD命令未使用）
◦ 出典：http://www.shoup.net/ntl/

 GMP(The GNU Multiple Precision Arithmetic Library)
◦ CPUによる多倍長演算ライブラリ（SSE2命令およびMMX命令使
用）
◦ NTLよりも一般的に高速
◦ 出典：http://gmplib.org/

 NTL、GMPと提案手法の比較
◦ 6種類のbit数において36通りの組み合わせの
多倍長整数乗算の実行時間

31 大阪府立大学北野晃司 Next⇒実験環境

 CPU
◦ 2.93GHz Intel Core i3（1コアのみ使
用）
 GPU
◦ NVIDIA GeForce GTX480
※GMPはWindowsを公式に
 OS
◦ 64bit Windows7 Professional SP1
はサポートしていないため、
GMPプログラムのみ
 コンパイラ OS：64bit Linux (ubuntu 11.04)
◦ Visual Studio 2008 Professional コンパイラ：g++ 4.5.2
 CUDA を使用
◦ Ver 3.2
 ディスプレイドライバ
◦ Ver 285.62

32 大阪府立大学北野晃司 Next⇒NTLとの実験結果

多倍長整数積A×Bの計算時間
 単位はミリ秒

※左は提案手法、右はNTLによる結果

参考：256Kbits=262144bits≒10進数80
33 大阪府立大学北野晃司 Next⇒NTLに対する速度向上率

 下表はNTLに対する、提案手法の速度向上率
 実験したすべての場合において提案手法はNTLを上回る速
度
 最大で70倍を超える速度向上率

Next⇒GMPとの実験結果

多倍長整数積A×Bの計算時間
 単位はミリ秒

※左は提案手法(再掲)、右はGMPによる結果

35 大阪府立大学北野晃司 Next⇒GMPに対する速度向上率

 下表はGMPに対する、提案手法の速度向上率
 実験したすべての場合において提案手法はGMPを上回る速
度
 最大で10倍を超える速度向上率

大阪府立大学北野晃司
36 Next⇒GPUによる既存研究と比較

 提案手法
 評価実験
◦ CPUによる多倍長演算ライブラリとの比較
◦ GPUによる既存の研究との比較




出典[3]： Emmart, N. and Weems, C., “High Precision Integer Multiplication
with a GPU,” IEEE Int'l Parallel & Distributed Processing Symposium (IPDPS),
pp.1781-1787 , May 2011.

38 大阪府立大学北野晃司 Next⇒比較実験結果

 右表はGPUによるFFT乗算の実行結果

 GPUによるFFT乗算の255Kbits×255Kbits
VS
提案手法の255Kbits×255Kbits

0.207ミリ秒 VS 0.590ミリ
秒
FFT乗算提案手
法提案手法が約三倍遅い

出典[3]
Next⇒考察（計算量）

 提案手法の計算量はM桁×N桁においてО（M
N）
 FFT乗算は同一桁数であることを条件とし、
N桁×N桁においてO（N log N log log N）
特に、Nが2の累乗の時にはО（N log N）
同一bit数（桁数）では計算量的に不
利

40 大阪府立大学北野晃司 Next⇒考察（FFT乗算の欠

 異なる2つのbit数を扱う際には大きい方に合わせ
てパディングを行うため性能が低下
 また、2393216進数（384Kbits）なのでbit数が
393216の倍数でないときも同様に性能が落ちる

 255Kbits×255Kbitsの方が
383Kbits×383Kbitsより遅い
 510Kbitsと766Kbitsでも同
様
出典[3]

41 大阪府立大学北野晃司 Next⇒考察（異なるbit

 提案手法では8Kbits×255Kbitsを
0.0451ミリ秒で実行
 FFT乗算では0.207ミリ秒より
遅くなると予想できる

出典[3]
提案手法はGPUによるFFT乗算に対し、異な
るbit数の乗算では4倍以上の性能が出せる

42 大阪府立大学北野晃司 Next⇒まとめと今後の課

 提案手法
 評価実験


 実装したアルゴリズムはCPUによる既存の多倍長演
算ライブラリを上回る速度
 GPUによる既存研究のうち最速のものと比較すると、
異なるbit数の乗算では4倍以上の速度

 より小さい整数に対する効率的な手法が必要
◦ 実際の問題で扱う整数は数Kbits程度が主流
◦ 提案手法では十分な並列性が得られない


GPUによる多倍長整数乗算の高速化手法の提案とその評価

More Related Content

What's hot (20)

Similar to GPUによる多倍長整数乗算の高速化手法の提案とその評価 (11)

GPUによる多倍長整数乗算の高速化手法の提案とその評価