TadaoYamaokaの開発日記

個人開発しているスマホアプリや将棋AIの開発ネタを中心に書いていきます。

将棋AIの進捗 その18(スケーラビリティ)

AWSのp3.8xlargeインスタンスを試験的に借りてGPUを増やした場合の性能を測定しました。
Linuxだとマルチスレッドの性能がでないので、OSはWindowsです。

p3.8xlargeのマシンスペックは以下の通りです。

Tesla V100 GPUs 4
vCPUs 32
Main Memory 244GiB

GPUに割り当てる探索スレッド255として、GPUを増やしながら平手初期局面での探索速度(シミュレーション/秒)を測定しました。

GPU枚数 探索速度(シミュレーション/秒)
1 6344
2 7545
3 7757
4 8168

f:id:TadaoYamaoka:20180404230913p:plain
GPUを増やすほど、探索速度が上がっていますが線形には伸びていません。

スレッド数

GPU4枚で、GPUあたりの探索スレッドを変えて測定しました。

スレッド数 探索速度(シミュレーション/秒)
255 8168
192 8790
168 8923
128 8179

スレッド数が168のときに最大となりました。

スレッド数を変えてGPU枚数変更

スレッド数を168として、GPU枚数を変更しました。

GPU枚数 探索速度(シミュレーション/秒)
1 5839
2 9696
3 8921
4 8923

GPU2枚が最大となりました。

GPU2枚でスレッド数を変更

GPU2枚でスレッド数を変えて測定しました。

スレッド数 探索速度(シミュレーション/秒)
255 7545
192 9118
168 9696
128 7263

スレッド数168のときが最大となりました。

考察

GPU枚数とスレッド数を単純に増やしても探索速度は上がりませんでした。
GPU枚数とスレッド数のバランスが取れている時が探索速度が最大となっています。
スケーラビリティが頭打ちになった原因は、スレッド間でノード情報を共有するツリー並列化を行っているため、スレッド数が増えるほど競合が発生するため、効率が悪くなったためと推測できます。
ツリー並列化の方式では、GPUは2枚以上にしても探索速度の向上は期待できそうにないことがわかりました。

スケーラビリティを上げるには、マルチプロセスまたはマルチノードでルート並列化を行う必要がありそうです。

なお、AWSではなく2枚のGPU(Titan Vと1080Ti)にCore i9 10コアのPCだと、GPUあたりの探索スレッド数255で、10779シミュレーション/秒の速度がでています。
5月の大会はGPU2枚のPCでの参加の方向になりそうです。

将来的には、マルチノード構成を検討することにします(5月の大会には間に合いそうにない)。

2018/4/5 追記

自己対局をp3.8xlargeでGPU数のプロセスで実行した場合の生成速度は、7.61+8.85+9.08+6.56=32.1局面/秒となった。
GPU2枚のPCだと2プロセスで11.26+8.40=19.66局面/秒なので、AWSを使うと1.63倍の速度で生成できる。

LinuxとWindowsのマルチスレッド性能

将棋AIをAWSで動かそうとLinux対応しましたが、Linuxでマルチスレッドの性能がでないため、いろいろ実験してみました。

検証している将棋AIではGPUの計算が終わったら、待機中の複数の探索スレッドに通知する処理を行っています。
それを、以下のような処理で実装していましたが、Linux(Ubuntu 16.04)ではWindowsの1/10以下の探索速度になってしまいます。

探索スレッド側
while (uct_node[child_index].evaled == 0)
	this_thread::sleep_for(chrono::milliseconds(0));
GPUスレッド側
uct_node[index].evaled = 1;

探索スレッド数は255です。evaled はatomicです。

探索速度(シミュレーション/秒)の比較は、以下の通りです。

Windows 6305
Linux 561

sleep時間変更

はじめ、GPUまわりのコードを疑いましたが、GPUの処理を外しても変わらないため、マルチスレッドに起因する問題と推測し、探索スレッド側でビジーループしている箇所を0ミリ秒のsleepから1ミリ秒のsleepに変更してみました。
すると以下の通り少しだけ改善されました。

Windows 5190
Linux 1354

Windowsでは逆に探索速度が落ちています。

yieldに変更

今度は、0ミリ秒のsleepの代わりにyiledに変更してみました。

while (uct_node[child_index].evaled == 0)
	this_thread::yield();

今度はだいぶ改善されました。

Windows 6301
Linux 2258

Windowsは0ミリ秒のスリープと変わりません。
Linuxはだいぶ改善されましたが、Windowsの半分以下です。

condition_variableに変更

通知の処理を、ビジーループからcondition_variableに変更しました。

探索スレッド側
std::unique_lock<std::mutex> lk(mtx);
while (uct_node[child_index].evaled == 0)
	cond.wait(lk);
GPUスレッド側
uct_node[index].evaled = 1;
cond.notify_all();

探索速度は、以下の通りとなりました。

Windows 1823
Linux 2769

Linuxは今までで一番よい値になりましたが、やはりWindowsのビジーループの場合の半分以下です。
Windowsはcondition_variableを使うと、ビジーループの場合の29%まで落ち込みました。

考察

以上の実験結果から、Linuxではビジーループよりもcondition_variableの方がマルチスレッドの性能がよさそうです。
しかし、Windowsでビジーループする場合の半分以下の性能しかでません。
Windowsでは、condition_variableを使うと、ビジーループよりも性能が低下します。

LinuxWindowsと同等のマルチスレッドの性能を出す方法は今のところ不明です。
AWSを借りる場合、料金は上がりますが、Windowsを借りることになりそうです・・・。
どなたかLinuxでもマルチスレッドの性能について知見をお持ちの方がいたらアドバイスいただけると嬉しいです。

将棋AIの進捗 その17(AWS対応を検討)

世界コンピュータ選手権の参加者のマシンスペックをみると、マシンスペック高すぎです( ゚Д゚)

GPUを2枚詰んだ個人のPCで参加しようと思っていましたが、GPU8枚とかで来られたらモデルと探索の性能ではどうにもならなそうです。
モンテカルロ木探索は並列化の効果が高く、私の実験でも、GPUを2枚にするだけで、GPSfishに対して勝利が40%から75%(R+261)に上がっています。
8枚になると単純計算で、R+2088です(実際は線形には伸びませんが)。

ということで、AWSでp3.16xlargeを借りて参加することを検討しています。

AWSで参加することを考慮して、cuDNN対応したコードをLinuxで動かせるようにしました。
しかし、Ubuntu 16.04 LTSをCore i9で動かすと、マルチスレッドの性能がでず、探索速度がWindowsの半分になります。
GPUの推論処理をコメントアウトしても変わらないので、Ubuntu 16.04 LTSのカーネルが古いためCore i9に対応していないためと予想しています。
AWSXeonなので、性能劣化しないと思っていますが、事前に実験しておく必要がありそうです。
GPUインスタンスは高いので実験するにもお財布が痛みます・・・


あと、AWSを使う場合は、参加者の皆さんはどのように実行されているのでしょうか。
現地にノートPCを持ち込んで、ノートPC上でsshコマンドをバッチファイルにして、将棋所に登録すればよいと思っていますが、どういう方法がメジャーなのでしょうか。
ノートPCを経由するので多少のラグはありますが、大会のサーバがLAN内にあると、AWSから直接というわけにもいかないと思うので、この方法になるのではないかと思っています。

2018/4/3 追記

AWSを試験的に使ってみたのですが、AWSでも遅かったので原因を調べたところ、Linuxで遅くなる原因が判明しました。
ニューラルネットワークの実行を待機する処理を

	while (uct_node[current].evaled == 0)
		this_thread::sleep_for(chrono::milliseconds(0));

のように記述していましたが、これがWindowsだとスレッドの実行をスイッチしてくれますが、LinuxだとCPUを100%消費してスレッドが切り替わらないためでした。

	while (uct_node[current].evaled == 0)
		this_thread::sleep_for(chrono::milliseconds(1));

にすると、速くなったのですが、1ミリ秒のスリープが無駄なのでスピンロックするのはやめて、condition_variableを使った実装に修正する予定です。

2018/4/4 追記

Twitterでの開発者同士のやり取りで以下の方法で可能ということなので、情報を載せておきます。
SSHのコマンドをバッチファイルに記述することで、リモートでUSIエンジンを動かせるようです。
http://ai65536.hatenablog.com/entry/2015/03/31/190904ai65536.hatenablog.com

将棋AIの進捗 その16(マルチGPU)

将棋AIをChainerを使用した実装からcuDNNを使用した実装に変更できたので、マルチGPUでの性能を測定した。

Chainerを使用した場合

Python経由でChainerを使用しているPythonのGIL機構によってマルチスレッドの性能に制限がある。
Chainerを使用した場合の、マルチGPUによる効果は1.33倍程度であった。

playout/sec
シングルGPU(Titan V) 5724
マルチGPU(Titan V+GeForce 1080 Ti) 7640

cuDNNを直接使用した場合

cuDNNを直接使用した場合の測定結果は、以下の通りであった。

playout/sec
シングルGPU(Titan V) 6266
マルチGPU(Titan V+GeForce 1080 Ti) 10779

cuDNNを直接使用した場合、マルチGPU化により1.72倍の高速化の効果があった。
ChainerをシングルGPUで使用した場合と比べると、1.88倍になった。

棋力への影響

棋力にどれだけ影響しているかを確認してみた。
十分な対局数がこなせていないが、elmoで深さ8で生成した11億局面を学習したモデルで、GPSfishと1手3秒で5戦したところ、全勝だった。
CPUはCore i9 10コアなのでGPSfishに不利な条件ではない。
なお、GPSfishは定跡ありで、dlshogi側は定跡を使用していない。
シングルGPUのときは、GPSfishへの勝率は、40%程度だったので探索速度の向上によって棋力が上がっていそうである。
もっと対局数を増やして検証したい。
f:id:TadaoYamaoka:20180327220515p:plain

アピール文章書かないと・・・

2018/3/28 追記

48回連続対局を行ったところ、
dlshogi 36勝(75%) GPSfish 12勝(25%)
という結果だった。
cuDNNを使ったマルチGPU対応により、有意に強くなったことが確認できた。
GPSfishのeloレーティングを2800とすると、dlshogiのeloレーティングは2990.8となる。
\displaystyle
\begin{eqnarray}
R_{dlshogi}&=&R_{GPSfish}-400 \log{10} (\frac{1}{E_{dlshogi}} - 1) \\
&=&2800 - 400\log_{10}(\frac{1}{0.75} - 1) \\
&=&2990.8
\end{eqnarray}

探索の高速化は、まだ改良の余地があるので、もう少し高速化を行いたい。
自己対局による強化学習の方も、cuDNN対応を行う予定。

将棋AIの進捗 その15(cuDNNを使用)

モデルの学習にディープラーニングフレームワークのChainerを使用していますが、対局時にChainerで推論を行うと、Python経由で呼び出すためマルチGPUで動かす際、Python経由だとGILによってマルチスレッドの性能が出なくなる。
また、実行環境にPythonが必要になるため、実行バイナリを配布しても利用者側で環境構築が必要になってしまう。

それらの問題を解決するため、対局時にはChainerを使用しないで、cuDNNを直接しようして推論を行えるようにした。
実装方法の詳細は以下の記事を参照してほしい。
Chainerで学習したモデルを使ってcuDNNで推論する - TadaoYamaokaの開発日記
Chainerで学習したモデルを使ってcuDNNで推論する(時間計測) - TadaoYamaokaの開発日記
Chainerで学習したモデルを使ってcuDNNで推論する(BatchNormalization) - TadaoYamaokaの開発日記
Chainerで学習したモデルを使ってcuDNNで推論する(dropout) - TadaoYamaokaの開発日記
Chainerで学習したモデルを使ってcuDNNで推論する(ResNet) - TadaoYamaokaの開発日記
Chainerで学習したモデルを使ってcuDNNで推論する(マルチGPU) - TadaoYamaokaの開発日記

はじめ、キューに溜まっている要求がバッチサイズ未満でも固定のバッチサイズで推論を行うように実装したら、Python経由でChainerを呼び出すよりも遅くなってしまった。

初期局面の探索速度
playout/sec
Chainer 4542
cuDNN 4095

期待した結果にならなかったので、バッチサイズを可変にして、キューに溜まっているサイズのバッチサイズで推論を行うようにしたところ、Python経由でChainerを使用する場合を上回った。

初期局面の探索速度
playout/sec
Chainer 4542
cuDNN 4854

GPUの並列性を期待して、バッチサイズによらず速度は一定と考えたが、メモリの転送時間とかの影響があるため、バッチサイズは可変にした方が良いことがわかった。

しかし、MNISTの推論で比較した場合に比べて、期待したほど速度が向上していない。
ChainerはPythonで実行している分無駄があるので、もっと差が出てよさそうである。
Chainerは、速度を出すためにチューニングしているため、素朴な実装だとGPUの性能が出せていないと思われる。
速度を出すには、メモリ転送をStreamを使うなどチューニングが必要そうだ。
CUDAのチューニングノウハウをほとんど持っていないので、Chainerのソースをみるなどしてもう少し調査してみるつもりだ。

マルチGPUについては、効果があるはずなので、別途測定を行う予定。

2018/3/27 追記

メモリ転送をストリームを使って並列化してみたが、

playout/sec
直列 4853
ストリーム 4202

という結果になり、かえって遅くなってしまった。

GPU計算中にメモリ転送できる箇所が入力層と出力層に一部しかなく、cudaStreamSynchronizeを実行する分、遅くなってしまったようだ。
ストリームに対応させる際に、ホストメモリの確保をC++のデフォルトヒープから、cudaHostAllocによって割り当てられるピンメモリに変更したが、そのことによって速くなることはなかった。

以上から、推論の実行時間のほとんどはGPUの計算に費やされており、Python経由でChainerから実行しても、cuDNNで直接実行しても差は限定的ということが言えそうだ。それでも、Chainerよりも7%程速くなっているので、少しは効果があった。

Chainerで学習したモデルを使ってcuDNNで推論する(マルチGPU)

前回実装した、Chainerで学習したモデルを使用してcuDNNで推論するコードを、マルチGPUで並列に動作するようにした。

cuDNNをマルチスレッドで、スレッドに別々のGPUを割り当てて使用する場合、それぞれのスレッドでcudaSetDevice()を呼び出し、GPU IDを指定する。
cudaSetDevice()を呼び出し後に、cudnnCreate()を呼び出しcuDNNのハンドルを取得し、スレッドごとに異なるcuDNNのハンドルを使用する。

前回までのコードは、cudnnCreate()をNNクラスの静的クラス変数の初期化で呼び出していたが、上記の仕様に対応するため、NNクラスの初期化時に呼び出し、
スレッドごとにNNクラスのインスタンスを作成するように変更した。

以上の変更で、マルチGPUで動作できるようになった。

マルチGPUによって、高速化の効果があるか確認するために、以下の通り測定を行った。

測定条件

  • スレッド内で初期化処理は時間に含めず、推論のみの時間を測定
  • MNISTのtest set images(1000画像)のすべてを20回推論するのに要する時間を測定
  • 3回測定した平均時間
  • ミニバッチサイズは、100
  • モデルは畳み込み1層+畳み込み1層のResNetブロック1つ+畳み込み1層+全結合層2層、BatchNormalizationあり
  • GPUは2枚(TitanVとGeForce GTX 1080 Ti)
  • CUDA 9.0、cuDNN 7.0を使用

測定結果

Chainer(シングルGPU) 4767 ms
シングルGPU 1657 ms
マルチGPU 915 ms

比較対象として、Chainerでシングルスレッドで推論した時間、cuDNNでシングルスレッドシングルGPUで推論した時間を記載している。

マルチGPUは、シングルGPUの約1.8倍高速になっている。

以前に将棋AIの推論でChainerを使ってマルチGPUに対応させたが、マルチGPU化の効果はほとんどなかった。
ChainerをPython経由で使用しているため、PythonのGIL機構によりマルチスレッドでの性能がでないためである。

cuDNNを直接使用するとPythonの制約がないため、マルチGPUにより高速化できている。

GPUごとの推論時間

マルチGPUの場合の、GPUごとの推論時間も計測した。

mnistCUDNN\mnistCUDNN>..\x64\Release\mnistCUDNN.exe 2
There are 2 CUDA capable devices on your machine :
device 0 sms 80 Capabilities 7.0, SmClock 1455 Mhz, MemSize (Mb) 12288, MemClock 850 Mhz, Ecc=0, boardGroupID=0
device 1 sms 28 Capabilities 6.1, SmClock 1670.5 Mhz, MemSize (Mb) 11264, MemClock 5505 Mhz, Ecc=0, boardGroupID=1
gpu:0
1000 iterations
867 [ms]
gpu:1
1000 iterations
751 [ms]
total time = 894 [ms]

gpu:0がTitan Vで、推論に867 [ms]を使っている。
gpu:1がGeForce GTX 1080 Tiで、推論に751 [ms]を使っている。
Titan Vの方が遅いため、トータルの時間は、Titan Vの実行時間+αになっている。

Titan Vの方が遅いのは、クロック数の違いによる。

ベースクロック (MHz) メモリクロック (MHz)
Titan V 1200 850
Geforce GTX 1080 Ti 1480 1100

モデルのサイズ、バッチサイズが小さい場合は、Geforce GTX 1080 Tiの方が高速に動作する。
Titan Vの性能を引き出せるのは、サイズの大きいモデルでバッチサイズを大きくして学習する場合である。
推論の速度だけであれば、モデルによってはクロック数の高いGeforce GTX 1080 Tiを複数枚用意した方がよさそうである。


測定に使用したソースコードを公開しました。
github.com

Chainerで学習したモデルを使ってcuDNNで推論する(ResNet)

前回実装した、Chainerで学習したモデルを使用してcuDNNで推論するコードを、Residual Network(ResNet)構成にした。

推論時には、テンソルの加算を行うだけで特に難しいことはない。

ネットワーク定義(Chainer)

ResNetは1ブロックのみで、ブロック内の畳み込み層は1層のみとした。

nn.py
from chainer import Chain
import chainer.functions as F
import chainer.links as L

# ネットワーク定義
k = 16
fcl = 256
class NN(Chain):
    def __init__(self):
        super(NN, self).__init__()
        with self.init_scope():
            self.conv1 = L.Convolution2D(in_channels = 1, out_channels = k, ksize = 3, pad = 1)
            self.conv2 = L.Convolution2D(in_channels = k, out_channels = k, ksize = 3, pad = 1)
            self.conv3 = L.Convolution2D(in_channels = k, out_channels = k, ksize = 3, pad = 1)
            self.l4    = L.Linear(7*7*k, fcl)
            self.l5    = L.Linear(fcl, 10)
            self.bn1   = L.BatchNormalization(k)
            self.bn2   = L.BatchNormalization(k)

    def __call__(self, x):
        h = self.conv1(F.reshape(x, (len(x), 1, 28, 28)))
        h = self.bn1(h)
        h1 = F.relu(h)

        # resnet block
        h = self.conv2(h1)
        h = self.bn2(h)

        h = h + h1
        h = F.max_pooling_2d(F.relu(h), 2)
        h = self.conv3(h)
        h = F.max_pooling_2d(F.relu(h), 2)
        h = F.relu(self.l4(h))
        h = F.dropout(h, ratio=0.4)
        return self.l5(h)

テンソル加算の実装(C++)

cuDNNを使用してテンソルの加算を行うクラスを追加した。

layers.h
class Add {
public:
	void operator() (cudnnHandle_t handle, cudnnTensorDescriptor_t xDesc, float* x, float* y) {
		const float alpha = 1.0f;
		const float beta = 1.0f;
		checkCUDNN(cudnnAddTensor(handle, &alpha, xDesc, x, &beta, xDesc, y));
	}
};

ネットワーク定義(C++)

ResNet構成のネットワーク定義を以下の通り実装した。

nn.h
class NN {
public:
	typedef float x_t[batch_size][1][IMAGE_H][IMAGE_W];
	typedef float y_t[batch_size][10];

	NN();
	~NN();

	void load_model(const char* filename);

	void foward(x_t x, y_t y);

private:
	static CudnnHandle cudnnHandle;
	static CublasHandle cublasHandle;
	static const int k = 16;
	static const int fcl = 256;

	ConvLayer<k, 1, 3, 1> conv1;
	Bias<k, 1, 1> bias1;
	ConvLayer<k, k, 3, 1> conv2;
	Bias<k, 1, 1> bias2;
	ConvLayer<k, k, 3, 1> conv3;
	Bias<k, 1, 1> bias3;
	Linear<7 * 7 * k, fcl> l4;
	Bias<fcl, 1, 1> bias4;
	Linear<fcl, 10> l5;
	Bias<10, 1, 1> bias5;
	BatchNormalization<k> bn1;
	BatchNormalization<k> bn2;

	ReLU relu;
	MaxPooling2D<2> max_pooling_2d;
	Add add;

	CudnnTensorDescriptor xDesc;
	CudnnTensorDescriptor h1Desc;
	CudnnTensorDescriptor h2Desc;
	CudnnTensorDescriptor h3Desc;
	CudnnTensorDescriptor h4Desc;
	CudnnTensorDescriptor h5Desc;
	CudnnTensorDescriptor h6Desc;
	CudnnTensorDescriptor yDesc;

	float* x_dev;
	float* h1_dev;
	float* h1_bn_dev;
	float* h2_dev;
	float* h2_bn_dev;
	float* h3_dev;
	float* h4_dev;
	float* h5_dev;
	float* h6_dev;
	float* y_dev;
};
nn.cpp
NN::NN()
{
	conv1.get_xdesc(xDesc, batch_size, IMAGE_H, IMAGE_W);

	const int h1_h = conv1.get_yh(IMAGE_H);
	const int h1_w = conv1.get_yw(IMAGE_W);
	conv1.get_ydesc(h1Desc, batch_size, h1_h, h1_w);

	const int h3_h = max_pooling_2d.get_yh(h1_h);
	const int h3_w = max_pooling_2d.get_yw(h1_w);
	conv3.get_xdesc(h3Desc, batch_size, h3_h, h3_w);

	const int h4_h = conv3.get_yh(h3_h);
	const int h4_w = conv3.get_yw(h3_w);
	conv3.get_ydesc(h4Desc, batch_size, h4_h, h4_w);

	const int h5_h = max_pooling_2d.get_yh(h4_h);
	const int h5_w = max_pooling_2d.get_yw(h4_w);
	max_pooling_2d.get_desc(h5Desc, batch_size, k, h5_h, h5_w);

	l4.get_ydesc(h6Desc, batch_size);
	l5.get_ydesc(yDesc, batch_size);

	// init conv layers
	conv1.init(cudnnHandle, xDesc, h1Desc);
	conv2.init(cudnnHandle, h1Desc, h1Desc);
	conv3.init(cudnnHandle, h3Desc, h4Desc);

	// malloc
	checkCudaErrors(cudaMalloc((void**)&x_dev, conv1.get_xsize(batch_size, IMAGE_H, IMAGE_W)));
	checkCudaErrors(cudaMalloc((void**)&h1_dev, conv1.get_ysize(batch_size, h1_h, h1_w)));
	checkCudaErrors(cudaMalloc((void**)&h1_bn_dev, conv1.get_ysize(batch_size, h1_h, h1_w)));
	checkCudaErrors(cudaMalloc((void**)&h2_dev, conv2.get_ysize(batch_size, h1_h, h1_w)));
	checkCudaErrors(cudaMalloc((void**)&h2_bn_dev, conv2.get_ysize(batch_size, h1_h, h1_w)));
	checkCudaErrors(cudaMalloc((void**)&h3_dev, conv3.get_xsize(batch_size, h3_h, h3_w)));
	checkCudaErrors(cudaMalloc((void**)&h4_dev, conv3.get_ysize(batch_size, h4_h, h4_w)));
	checkCudaErrors(cudaMalloc((void**)&h5_dev, batch_size * k * h5_h * h5_w * sizeof(float)));
	checkCudaErrors(cudaMalloc((void**)&h6_dev, batch_size * fcl * sizeof(float)));
	checkCudaErrors(cudaMalloc((void**)&y_dev, batch_size * 10 * sizeof(float)));
}

NN::~NN() {
	checkCudaErrors(cudaFree(x_dev));
	checkCudaErrors(cudaFree(h1_dev));
	checkCudaErrors(cudaFree(h1_bn_dev));
	checkCudaErrors(cudaFree(h2_dev));
	checkCudaErrors(cudaFree(h2_bn_dev));
	checkCudaErrors(cudaFree(h3_dev));
	checkCudaErrors(cudaFree(h4_dev));
	checkCudaErrors(cudaFree(h5_dev));
	checkCudaErrors(cudaFree(h6_dev));
	checkCudaErrors(cudaFree(y_dev));
}

Chainerで学習したモデルの読み込み(C++)

前回までの畳み込みの読み込みと同じでResNet構成によって特別な処理はない。

void NN::load_model(const char* filepath)
{
	// load nn params
	ParamMap params;
	load_npz(filepath, params);

	conv1.set_param(params["conv1/W.npy"].data);
	bias1.set_bias(params["conv1/b.npy"].data);
	conv2.set_param(params["conv2/W.npy"].data);
	bias2.set_bias(params["conv2/b.npy"].data);
	conv3.set_param(params["conv3/W.npy"].data);
	bias3.set_bias(params["conv3/b.npy"].data);
	l4.set_param(params["l4/W.npy"].data);
	bias4.set_bias(params["l4/b.npy"].data);
	l5.set_param(params["l5/W.npy"].data);
	bias5.set_bias(params["l5/b.npy"].data);
	bn1.set_param(params["bn1/gamma.npy"].data, params["bn1/beta.npy"].data, params["bn1/avg_mean.npy"].data, params["bn1/avg_var.npy"].data);
	bn2.set_param(params["bn2/gamma.npy"].data, params["bn2/beta.npy"].data, params["bn2/avg_mean.npy"].data, params["bn2/avg_var.npy"].data);
}

推論(C++)

ResNetブロックの処理とテンソルの加算処理を追加した。

void NN::foward(x_t x, y_t y)
{
	// input
	checkCudaErrors(cudaMemcpy(x_dev, x, sizeof(x_t), cudaMemcpyHostToDevice));

	// conv1
	conv1(cudnnHandle, xDesc, x_dev, h1Desc, h1_dev);
	bias1(cudnnHandle, h1Desc, h1_dev);
	bn1(cudnnHandle, h1Desc, h1_dev, h1_bn_dev);
	relu(cudnnHandle, h1Desc, h1_bn_dev);

	// resnet block
	conv2(cudnnHandle, h1Desc, h1_bn_dev, h1Desc, h2_dev);
	bias2(cudnnHandle, h1Desc, h2_dev);
	bn2(cudnnHandle, h1Desc, h2_dev, h2_bn_dev);

	add(cudnnHandle, h1Desc, h1_bn_dev, h2_bn_dev);
	relu(cudnnHandle, h1Desc, h2_bn_dev);
	max_pooling_2d(cudnnHandle, h1Desc, h2_bn_dev, h3Desc, h3_dev);

	// conv3
	conv3(cudnnHandle, h3Desc, h3_dev, h4Desc, h4_dev);
	bias3(cudnnHandle, h4Desc, h4_dev);
	relu(cudnnHandle, h4Desc, h4_dev);
	max_pooling_2d(cudnnHandle, h4Desc, h4_dev, h5Desc, h5_dev);

	// fcl
	l4(cublasHandle, batch_size, h5_dev, h6_dev);
	bias4(cudnnHandle, h6Desc, h6_dev);
	relu(cudnnHandle, h6Desc, h6_dev);
	l5(cublasHandle, batch_size, h6_dev, y_dev);
	bias5(cudnnHandle, yDesc, y_dev);

	// output
	checkCudaErrors(cudaMemcpy(y, y_dev, sizeof(y_t), cudaMemcpyDeviceToHost));
}

テンソル加算の実際の処理は、layers.hのAddクラスのoperator()に実装している。
1層目の畳み込み層の活性化関数の出力h1_bn_devをResNetブロックの入力にして、ResNetブロックの出力h2_bn_devをh1_bn_devに加算している。
ResNetブロックの入力と出力のテンソルのサイズは変わらないため、テンソルディスクリプタは1層目の畳み込み層と共通のh1Descを使用している。

実行結果

Chainerで推論した結果と完全に一致することを確認した。


ソースをGitHubで公開しました。
github.com