Dycoonの日記

■ OpenCLの簡単なプログラムを書いてみて速度比較してみるなど 19:11

OpenCLの簡単なプログラムを書いてみてCPUとGPUの速度比較してみるなど。

基本的な感触をつかんでみた。

ソースコードなどはこちらに置きました。

https://github.com/dycoon/dycoon_simple/tree/master/OpenCL/SimpleTest

SimpleTest : 整数配列から奇数と偶数がいくつあるか数える

VMMultTest : 3次元ベクトルのアフィン変換の総和を返す

VertexBlendingTest : 3次元ベクトルを4つのアフィン変換で変換し均等にブレンディングしたものの総和を返す

それぞれの計算では、OpenCLによる処理と、C++で書かれたCPU上での処理の結果とかかった時間を返します。

処理内容はだいたい同じですが、OpenCLによる処理では並列処理を行うことを考慮した書き方になっているためその点で違いがあります。

CPUの処理ではシングルスレッドで処理しています。

計測は、

CPU : Core i7-2600 3.40GHz

GPU : NVIDIA Quadro 600

でおこなった。

OpenCLのSDKはNVIDIA GPU Computing SDK 4.0

Windows7で64bitの実行ファイルで、コンパイラはVC2008

プログラム	GPUバッファ転送時間(ms)	GPU計算時間(ms)	GPU処理時間(GPUバッファ転送時間 + GPU計算時間)(ms)	CPU処理時間(ms)
SimpleTest	177	127	304	84
VMMultTest	55	46	101	37
VertexBlendingTest	55	55	110	147

SimpleTestとVMMultTestではメモリーの量に対して処理が簡単すぎるためかメモリー転送を除いた

単純に計算している時間でみてもOpenCLによる計算のほうが遅くなっている。

VertexBlendingTestだと、メモリーの量に対して処理がそこそこ複雑なためか

OpenCLの処理のほうが勝っている。

もっとメモリーの量に対して処理が多ければどうなるのかというのは興味深いが、

現在は試していない。

OpenCLの処理を記述するに当たっては速度を上げるためにいろいろ試行錯誤した。

• 一度に処理する要素数(呼び出すOpenCL関数内のループの回数でこれを書いたときは5000)
• clEnqueueNDRangeKernelのlocal_work_sizeの値(これを書いたときは16)
• __localを使用する(SimpleTestなどではかえって遅くなることも)

あと、引っかかったポイントとしては

• clBuildProgramでCL_INVALID_BINARYを返してコンパイルが失敗する

以下のようにして最適化を無効にすることで動作するようにはなるようだ、

clBuildProgram(program, 0, NULL, "-cl-opt-disable", NULL, NULL);

ただ、これだと速度が下がってしまう場合があったので

変数を__localにしてみるなど、あてずっぽうに処理を書き換えて今回は対処した。

また、x64では起こらないがWin32では起こるという傾向があった。

• 構造体の代入は要素ごとにおこなう

構造体を代入すると、コンパイルエラーが返るわけでもエラーコードが返るわけでもないが、

計算結果が正しくない。

こう書いていたのを

r[gid] = sumR;

以下のようにするなど

r[gid].x = sumR.x;
r[gid].y = sumR.y;
r[gid].z = sumR.z;

レイトレースの処理や当たり判定などの処理に使ってみたいという気がします。

それより前にいろいろやらねばならないことがあるので

私がそこら辺をやるのはかなり先の話になりそうですが。

■ 明けましておめでとうございます。うさぎみたいのを描いたり。 23:27

sculptrisでうさぎみたいのを描いてみました。

体の部分や足の部分が適当になってしまいました。

Blenderに持って行ってYafaRayでレンダリングしてみたのが下のものです。

3D Model SNS CG にも同じものを置いてみたり。

http://www.cg-site.net/products/102802

今年もよろしくお願いします。

■ blenderで作ったボーンのアニメーションつきデータをPapervision3Dで表示 21:20

ちょっと急ぎでFlash上で3Dを表示しなければいけない状態になった

と思ったらそうでもなくなったのですが、

blenderで作ったボーンのアニメーションつきデータをPapervision3Dで表示させてみました。

blenderは2.49bを使ったいました。

このバージョンまでのColladaエクスポーターだと

ボーンのアニメーションをPapervision3Dで読み込むことができないもようです。

（いろんなところで最終的にあきらめている様子）

（補間がLinearなのがいけないのだろうか？と思っているが原因は究明していない）

blenderでfbxを出力してから以下においてある

http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=10775855

FBX 2011.3 Converter for Windows でColladaを出力させると

ボーンアニメーションが表示されるようになった代わりに

テクスチャーが表示されなくなってしまいました。

ただ、これをPapervision3Dで表示されるように修正するのは比較的簡単であったので

方法を書いておきます。

とりあえず、表示しているFlashはこちら

http://www.rmake.net/dycoon/files/papervisionsample/index.html

ソースコードやデータなどのファイル一式は以下においてあります。

http://www.rmake.net/dycoon/files/papervisionsample/PapervisionSample.zip

Papervision3DのライブラリはPapervision3D_2.1.932.swcを使いました。

http://code.google.com/p/papervision3d/downloads/detail?name=Papervision3D_2.1.932.swc&can=2&q=

詳細は以下のとおりです。

続きを読む

■ Rmakeのjavascript対応とパーサーをクラス化したkmyacc用定義ファイル 15:18

先日Rmakeのjavascript版をテストで実装しました。

HTML5で動作するノベルゲームのエンジンを作ってみた

http://d.hatena.ne.jp/akasata/20100810/1281439398

それにともない、Rmakeのゲームの挙動を記述するスクリプト言語(Arrp)をjavascriptでも実行できるようにしました。

このときパーサーをクラスで出力できるようにしたかったのでkmyacc用定義ファイルを編集して、

パーサーがクラスになるように（つまり、メンバーとして扱うものの前にthis.をつけた）しました。

動作するテストプログラムはここを見てください。

http://www.rmake.net/dycoon/files/kmyaccjs/scripttest/kmyacctest.html

入力欄に書いた四則演算の数式を、runボタンを押したときに解釈し、

結果を出力します。

定義ファイルなどは以下に置きました。

http://www.rmake.net/dycoon/files/kmyaccjs/scripttest.zip

Windowsでkmyaccへのパスが通してあれば、makeコマンドを呼ぶことでパーサーを生成することができます。

kmyaccなどについては以下が参考になるかと思います。

kmyacc - 多言語対応LALRパーサー生成系

http://www005.upp.so-net.ne.jp/kmori/kmyacc/

ActionScriptのyaccを作ったよ

http://d.hatena.ne.jp/yukoba/20080220/p1

■ C++ STLのアロケーター(allocator)とか調べたりの問題まとめ 14:59

マイクロソフトさんといくらかやり取りをしたり、

自分なりに対策などを考えてみました。

その結果の自分の見解を書いてみたいと思います。

あらすじ(2010/08/08追加)

問題があるコードを例としてブログに書いておくのもどうかと思ったので

過去の日記を消しました。

過去の日記の文章はこちらにおいておきます。

http://www.rmake.net/dycoon/files/stlallocator/OldStlAllocatorDiary.txt

量が多いのでかいつまんで話すと、

• static変数にメモリー管理クラスを保存するSTL用のアロケータークラスを作ったりいろいろ検証してみたりした。
• VS2008のReleaseモードでメモリーの確保量が増えることや、メモリーを開放するとき確保したのとは別のメモリー管理クラスへ開放しようとすることに気づく（gccやデバッグモードで起きない）
• サポートに連絡してみる。
• 問題の発生にstd::_Aux_contが関係しているのに気づく。
• 回避方法などを考えてみた。

という感じです。

サポートからの返事などがありましたので私が理解した範囲のことを書いてみます。

C++の規格に準拠していない

とりあえず

「アロケータークラスにstatic変数を持たせるのは

C++の規格に準拠していない」

ということがわかりました。

つまり、私が書いたコードがC++の規格に準拠してないということです。

たとえば、

alloc<T>のコンストラクタの引数にalloc<U>が渡された場合
alloc<T>::mem = alloc<U>::mem
見たいな処理をしていた場合、

//例1
alloc<T0> a00;
alloc<T1> a10;

a00, a10からの確保処理

alloc<T1> a11(a00);
alloc<T0> a01(a10):

a00, a10へのの開放処理

以上おこなうとallocのstaticなメンバーが

書き換わってしまうため

確保と開放の整合性が取れなくなります。

そのため、規格としてこのような動作は禁止されているものと思われます。

「C++の規格でアローケーターがrebindableでなければならない」というのは

この点をひとつさしています。

メモリーを分割して管理

そもそも、メモリーを分割して管理をおこなうということをSTL上でおこないたかったというのには

大きなものでは以下の動機があります。

• サーバーアプリにおける長時間起動によるメモリーのフラグメンテーションによるアプリケーションの死および性能劣化対策
• メモリーが限られた環境でのメモリーフラグメンテーションによっておきるアプリケーションの死をさける
• STLやboostを使うことで便利な関数を使えること
• STLやboostを使える技術者をつかまえることは、独自実装のライブラリの技術者をつかまえることより容易。

フラグメンテーションを抑えるため、あるいは確保できるメモリーの量を保障する方法には以下のものがあります。

• たとえばひとつの型やその配列に対し固定長の配列を用意してどの配列を使用しているか管理する方法
• 作成と削除が同時期のオブジェクト一塊に対して固定長の配列を用意しててどの配列を使用しているか管理する方法

しかしSTLの規格では状態つきアロケーターは必ずしも実装されていなければいけないものではないので

一つ目の方法をとるしかないのかなと判断しました。

そこでアロケーターにstatic変数を持たせ、

そこにメモリー管理クラスのインスタンスへのポインタを入れるようにしました。

メモリーを分割して管理する場合はどのコンテナがどのアロケーターを使っているかなどを

考えながら操作するため例1で起こるような問題は避けるように書いておりました。

そのため、問題を避けることはできますが、

それはSTLの使い方を理解しているという範囲の知識を超えるものですので

ほかの人が使うのには戸惑うことがあるだろうと思われます。

規格外としているのもここら辺を踏まえてだと思います。

アロケーター関連の日記の移動

アロケーターに関する今までの一連の記事は

よく読む人には有用な部分もあるかと思いますが、

間違った利用方法を広める可能性もあるため

hatena上からは削除して別の場所に移動しようと思います。

今回のアロケーターに関する記事は削除して、

こちらにテキストを保管しておこうと思います。

http://www.rmake.net/dycoon/files/stlallocator/OldStlAllocatorDiary.txt

ソースコードなどはこちらにおいてあります。

http://www.rmake.net/dycoon/files/stlallocator/STLAllocatorSample20100228.zip

http://www.rmake.net/dycoon/files/stlallocator/AllocatorVectorTest.zip

http://www.rmake.net/dycoon/files/stlallocator/AllocatorTypeTest.zip

http://www.rmake.net/dycoon/files/stlallocator/AllocatorTypeAvoidedTest20100801.zip

2番目のAllocatorVectorTest.zipが再現用に書いたコードなので、

これを見ると悪い例がわかりやすいかと思います。

そのほか

VisualStudio2008が採用しているC++の規格は以下で入手できる模様。

http://www.webstore.jsa.or.jp/webstore/top/index.jsp

ISO/IEC 14882:2003

35,910円

http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=ISO%2FIEC+14882%3A2003&dantaiCd=ISO&status=1&pageNo=0