2009年8月に◆Horo/.IBXjcg氏によって公開されました。
CUDAを使用しているので、GeForceシリーズのビデオカードと
181.20以降のドライバが必要です。
カードによっては600MTrips/sを超える速度を出すことも可能です。
ただ、GPUに高負荷がかかりシステムが不安定になる可能性があるので
使用の際には十分に注意して下さい。
なお、ソースコードは配布パッケージに同梱されています。
■入手先
ttps://skydrive.live.com/?cid=20e0a840474e1862&sc=documents&id=20E0A840474E1862%21420 記念にスレを立てました。これから少しずつ改造していく予定です。
【GPGPU】くだすれCUDAスレ pert4【NVIDIA】
ttp://hibari.2ch.net/test/read.cgi/tech/1291467433/
【mty】トリップ検索「まあ、待て屋。」 Part.1
ttp://hibari.2ch.net/test/read.cgi/software/1205766220/
使ってるグラボの種類が違ってて(Radeon とNVIDIA)、
ユーザー層が被らないので別スレでお願いします。
cudaTripper10Wiz7 は、CUDA Toolkit 4.0でビルドしたら、逆に遅くなったなぁ(*‘ω‘ *)
環境の違いかな
さんは、Windows7 64bitだったりします？
あと、4.0 でビルドしたやつは、実行時に表示される "Revision number" はいくつになるんでしょう？
CUDA4.0 64bitでコンパイルすると16.0%↑
compute_20,sm_21 に変更すると18.1%↑
ふむぅ
3.2だと64bitでも差は出なかった気がするけど、4.0だと出るのにゃ(´・ω・｀)
30%速くなってますね。"Revision number"はあとで確かめてみます。
表示されるRevision numberはCompute Capabilityでハードウェア依存だと思います。
使っているドライバのバージョンはいくつのものでしょうか？
270以降のものはXPでは結構トラブル報告があるみたいで悩みます。
パラメータはこんな感じです。
> CUDA SHA-1 Tripper 0.2.1
>
> Device 0: "GeForce GTX 580"
> Revision number: 2.0
> Total amount of global memory: 1535 Mbytes
> Number of multiprocessors: 16
> Number of cores: 128
> Clock rate: 1.54 GHz
>
> Use device 0, grid is 256 blocks
ttp://developer.nvidia.com/cuda-toolkit-40 > devdriver_4.0_winxp_32_270.81_general.exe
うちでは特に不具合は出てませんが…
どうも。
やはり環境によるのでしょうかね。
覚悟を決めて270系を試そうか悩みます。
うちでは未だになんの不都合もなく動いてます。
何も考えなかったのがかえって幸いしたみたいです…
XP専用 GeForce Driver Part62
ttp://hibari.2ch.net/test/read.cgi/jisaku/1310557070/
こんな感じで途中経過がスクロールせずに表示されます。
> 654.4MTrips/s [Total: 0.193TTrips, 0.084hours, Tripcodes: 0]
全然大したことはないのですが結構使い勝手が違います。
次は半角カタカナを含むキーを探索できるようにする予定。
出ました。
もともと772/1544/2004だったのでかなり無理をしています。
ファンは85%でこれ以上はMSI Afterburnerでは上げられないようです。
GPUの温度は68℃なので問題ないはずですが、ファンが掃除機のようです…
NT系でスクロールせずに表示というのは結構面倒ですよね？
どうやっているのか少し気になります。
1チップで800MTrips/sec超えですか・・・
GPUメモリ負荷が低いので、どうもFermi系では意外と消費電力少ないみたいです。
810.83M tripcodes/sが出ましたが、どうやらここらへんが
限界のようです。GPUの温度も80度を超えたし…
これ以上はファンを変えるか水冷化しないと無理ですね。
下の関数をprintfのあとに呼び出しています。
たしかに消費電力は少ないですね。
PSUはCorsair CX600なのでちゃんと動いてるのが不思議なぐらいです。
----
void resetCursorPos()
{
CONSOLE_SCREEN_BUFFER_INFO scrnBufInfo;
COORD cursorPos;
if (!GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &scrnBufInfo))
return;
cursorPos.X = 0;
cursorPos.Y = scrnBufInfo.dwCursorPosition.Y;
SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE), cursorPos);
}
ttp://yakin.38-ch.net/test/read.cgi/trip/1269695900 のですが、いつの間にかアップローダーが消えていたんですね。
とりあえずVS2010 SP1 + CUDA4.0でコンパイルした物を置いておきます。
ttp://loda.jp/uploader777/?id=2180.zip -xオプションの上限は36まで可能にしてあります。
ありがとうございます！ 後で落として試してみます。
GTX 580では-Xオプションは16が最適でした。
ttp://pastebin.com/bmhRc2t8 key[0]からkey[6]まではsha1trip_search()の外で決め打ちされてるので問題なし。
あとはkey[7]からkey[11]までだけど… いずれShift-JISにも対応させたいので結構悩むなあ
ttp://charset.7jp.net/sjis.html b64t[]に半角カナを足して大きさを128まで増やして、
無効な文字コードは飛ばすようにしただけです。後は残りをどうするかな…
Md[7]からMd[11]までには初期値として乱数が入っているので
効率は落ちないはず。
> #ifdef USE_KANA_IN_KEYS
> out->key[7] = indexToKeyCharTableForCUDA[(Md[7] + (Npass >> 5)) & 127];
> out->key[8] = indexToKeyCharTableForCUDA[(Md[8] + (blockIdx.x >> 6)) & 127];
> out->key[9] = indexToKeyCharTableForCUDA[(Md[9] + blockIdx.x ) & 127];
> out->key[10] = indexToKeyCharTableForCUDA[(Md[10] + (Npass & 31) * BLOCK_SIZE_Y + threadIdx.y) & 127];
> out->key[11] = indexToKeyCharTableForCUDA[(Md[11] + threadIdx.x ) & 127];
> #else
> out->key[7] = b64t_d[(Md[7] + (Npass >> 5)) & 63];
> out->key[8] = b64t_d[(Md[8] + (blockIdx.x >> 6)) & 63];
> out->key[9] = b64t_d[(Md[9] + blockIdx.x) & 63];
> out->key[10] = b64t_d[(Npass & 31) * BLOCK_SIZE_Y + threadIdx.y];
> out->key[11] = b64t_d[threadIdx.x];
> #endif
それをどこにほりこめばいいのですか？
ソースを配布したいのはやまやまなんですけど、どうしよう…
この後に入れそうになった
out->trip[11] = b64t_d[(c >> 24) & 63];
わかりました。
HyperTransportをOCしてもう一回最高速に挑戦してみました。
ほかの条件はと同じです。target.txtは7完3タゲ。
> 10.40T tripcodes were generated in 3.55 hours at:
> 812.86M tripcodes/s (current)
> 815.35M tripcodes/s (maximum)
> 813.56M tripcodes/s (average)
> 7 matches were found at 1.97 matches/h
ちょっと上がって結構嬉しいかも…
驚異的なスピードですです。
ほかの部品を全部足してもGTX 580よりずっと安いですｗ
頑張ってくれてます。
念のために数時間走らせてヒット率が落ちてないのを確認してから
Shift-JISへの対応に入る予定です。半角カナのときみたいに
変換テーブルが使えないので思案のしどころです。
580が、何ヶ月持ちますか？ いまだ460ですです。
ＧＰＵが７２度って普通ですよね。
うちのは85度で回し続けてるのでちょっと心配です。
買ったばかりなので今のところ大丈夫ですけど、
このペースで動かし続けたらわかりませんねえ。
なぜか乱数発生用に使われていたxor128()がうまくうごかなくなったので
CryptAPIを使うように変更。
ttp://msdn.microsoft.com/en-us/library/aa382375(v=vs.85).aspx 一応測ってみたけどスピードは落ちてないようです。
問題なのはここからで、実際にGPU内でSHA-1ハッシュを計算するときに
いかにに無効なキーを効率よく排除していくかが鍵になります。
できたトリップの85%がゴミという素敵な結果にorz
一応できたトリップは有効なようなので、あとは以下にスピードを殺さずに
効率を上げるかなんですが、かなり大変そう…
気になるうな。
CUDA SHA-1 Tripper 0.2.1
Device 0: "GeForce GTX 460"
Revision number: 2.1
Total amount of global memory: 961 Mbytes
Number of multiprocessors: 7
Number of cores: 56
Clock rate: 1.40 GHz
Use device 0, grid is 14 blocks
115 targets found, target_dw_num is 48
234867 kTrips in 2.044 sec - 114.906 MTrips/sec
現在鋭意修正中。最終的にはゴミはほとんどでなくなる予定です。
やっぱりGTX 460は色々違ってるみたいですね。
出来上がったらテストしていただけると有難いです。
ゴミは20%ぐらいまで減りました。ほんとは0%になるはずだったんだけど謎だ…
まだ見落としてる所があるのかしらん。あと副作用でちょっと早くなったみたいです。
2バイト文字を取り除くようにしたらShift-JIS対応は終了です。
( ﾟ∀ﾟ )/
ﾊ_ﾊ ⊂ ﾉ ﾊ_ﾊ
('(ﾟ∀ﾟ ∩ (つ ﾉ ∩ﾟ∀ﾟ)')
ﾊ_ﾊ ヽ 〈 (ノ 〉 / ﾊ_ﾊ
('(ﾟ∀ﾟ∩ ヽヽ_) (_ノ ノ ∩ﾟ∀ﾟ)')
O,_ 〈 〉 _,O
｀ヽ_) (_/ ´
ﾊ_ﾊ
⊂(｡Ａ。⊂＿､⊃ で き る よ ！！ ⊂´⌒⊃ﾟ∀ﾟ)⊃
V^V _ _
_ ,ハ ( ヽ,_
O´ 〈 _ _ 〉 `O
(.(｡Ａ｡∪ ﾉ ハ ( ヽヽ ∪｡Ａ｡).)
V^V / 〈 /ヽ 〉 ヽ V^V
(.(｡Ａ｡∪ ﾉ ⊂) ∪｡Ａ｡).)
V^V ( ⊃ V^V
/( ｡Ａ｡)
∪V^V
あと、CPU使うところでOpenMPとかSSEと思ったけど、
元のソース眺める限り、使えそうにないですね
> MappedMemory使ったほうが速度速くならないかな。
ありがとうございます！ ちょっと調べてみます。
いろいろバックグラウンドで動かしてたので速度は問題ないのですが、
ヒット率がかなり落ちてるのが気になります。
> 36.51T tripcodes were generated in 13.23 hours at:
> 745.08M tripcodes/s (current)
> 783.92M tripcodes/s (maximum)
> 766.35M tripcodes/s (average)
> 18 matches were found at 1.36 matches/h and 2028.26G tripcodes/match.
> 0% of generated tripcodes were invalid. (0, 18)
理論では (64^7)/3 ~= 1466G tripcodes/matchのはずなんですが…
実際半角カナ対応のバージョンと比べるとかなり差があります。
> 18.52T tripcodes were generated in 6.83 hours at:
> 770.46M tripcodes/s (current)
> 773.75M tripcodes/s (maximum)
> 753.27M tripcodes/s (average)
> 15 matches were found at 2.20 matches/h and 1234.67G tripcodes/match.
Shift-JISに対応しただけで効率が悪くなるなんてあるんだろうか…
ちょっと調べてみよう。
かなり真面目に計算しないといけないな、こりゃ。
ループの中に戻したらヒット率がもとに戻りました。
理由は全く謎です。もとに戻すと多少速度は落ちるのですが、仕方がありません。
なんにせよShift-JIS化そのものに問題はなくてほっとしました。
時間をかければ理論値に収束することがわかりました。
7完だと収束に時間がかかるだけだったようです。
おかげで最適化も進んで、速度もちょこっと上がりました。
あとは無効なShift-JISの文字を取り除くようにして、
ちゃんと2chで使えるトリップだけを表示するようにしました。
> ◆TEST/lg.8lRb #s羣ﾃMﾒｯ枸Uｻr (73 e3 b8 c3 4d d2 af 9e 6d 55 bb 72)
> ◆TEST/qu3MgY2 #s羣ﾃMﾒｲ遐｡ZA (73 e3 b8 c3 4d d2 b2 e7 a0 a1 5a 41)
> ◆TEST/ztT45Wl #s羣ﾃMﾒｻ俺Sｫｺ (73 e3 b8 c3 4d d2 bb 89 b4 53 ab ba)
> ◆TEST/SbWPY0p #s羣ﾃMﾒｿﾕ鋼dｱ (73 e3 b8 c3 4d d2 bf d5 8d 7c 64 b1)
> ◆TEST/xbsNm4G #s羣ﾃMﾒﾅn4ﾇﾙｧ (73 e3 b8 c3 4d d2 c5 6e 34 c7 d9 a7)
>
> Searching for 1 pattern with 5 characters.
> 0.17T tripcodes were generated in 0.06 hours at:
> 769.13M tripcodes/s (current)
> 794.81M tripcodes/s (maximum)
> 757.69M tripcodes/s (average)
> 161 valid matches were found at 2582.45 matches/h and 1.06G tripcodes/match.
> The maching rate is 13% higher than expected.
> 10% of matching tripcodes were invalid.
数日かかるかもしれませんが、しばしお待ちを。
CUDA SHA-1 Tripper 0.2.1 MERIKEN's branch 0.01 alpha 1
ttp://www.meriken2ch.com/files/CUDA_SHA-1_Tripper_MERIKEN0.01a1.zip 自画自賛ｗですが我ながら良く出来てると思うので使ってやって下さい。
動作報告をしていただけると大変嬉しいです。
・30%ほど速度が向上。
・Shift-JISに対応。
・画面表示の改善。
の3点です。
乙 さっそく
CUDA SHA-1 Tripper 0.2.1 MERIKEN's branch 0.01 alpha 1: A CUDA tripcode finder
Copyright (C) 2009 ◆Horo/.IBXjcg
Copyright (C) 2011 ◆MERIKEN4.k
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
PARAMETERS
Device: 0
Device Name: "GeForce GTX 460"
Compute Capability: 2.1
Clock Rate: 1.400GHz
Number of MPs: 7
Max. Threads per Block: 1024
Max. Thread Dimensions: {1024, 1024, 64}
Max. Grid Dimensions: {65535, 65535, 65535}
Number of Blocks: 112
TARGETS
84
TRIPCODES
◆TEST/lDsJ6jY #6ｽﾆﾎD0厂ｿ溺ﾃ (36 bd c6 ce 44 30 99 ca bf 93 4d c3)
STATUS
Searching for 85 patterns with 5 to 12 characters.
0.01T tripcodes were generated in 0.02 hours at:
173.27M tripcodes/s (current)
192.40M tripcodes/s (maximum)
182.93M tripcodes/s (average)
9 matches found at 570.27 matches/h and 1.15G tripcodes/match.
The matching rate is 9% lower than expected.
0% of matching tripcodes were invalid.
ありがとう
早速ありがとうございます。と比べると結構速度が上がってますねえ。
よかったよかった。
ソースは確かに色ついてないですねえ。これどうすればいいんでしょう。
実は開発に使ったVisual Studioは全く詳しくないのです…
わたしは、何もわかりませんので。
黒でもいいですよ。 ひらがなとか漢字なんか使うと色が変わったり・・
速いよホント
速度改善ですが、まだ試してみたい方法が残ってるので
もうちょっと速くなるかもしれません。
----
PARAMETERS
==========
Device: 0
Device Name: "GeForce GTX 580"
Compute Capability: 2.0
Clock Rate: 1.918GHz
Number of MPs: 16
Max. Threads per Block: 1024
Max. Thread Dimensions: {1024, 1024, 64}
Max. Grid Dimensions: {65535, 65535, 65535}
Number of Blocks: 256
STATUS
======
Searching for 3 patterns with 7 characters.
0.18T tripcodes were generated in 0.06 hours at:
821.42M tripcodes/s (current)
822.33M tripcodes/s (maximum)
820.92M tripcodes/s (average)
No matches were found yet.
これが今のところ最高ですね。やっぱ次はヒット判定を改善しようっと。
----
Searching for 1 pattern with 7 characters.
0.09T tripcodes were generated in 0.03 hours at:
834.90M tripcodes/s (current)
836.84M tripcodes/s (maximum)
836.08M tripcodes/s (average)
No matches were found yet.
STATUS
======
Searching for 3 patterns with 6 to 7 characters.
0.02T tripcodes were generated in 0.02 hours at:
271.91M tripcodes/s (current)
272.39M tripcodes/s (maximum)
271.85M tripcodes/s (average)
そこはやっぱちょっと問題ですよねえ。
でも配布する以上自分が書いた分のコードのライセンスを
指定しないわけにはいかなかったので…
もし原作者さんからクレームがきたらすぐに引っ込めます。
かなり違いますねえ。やっぱりタゲの数でぜんぜん違うんだな。
> お金＝速さ ですね・・
でも持ってるものを最大限活用することはできます！
自分もせっかく買ったこのカードを骨までしゃぶりつくすつもりです。
冬ならいいのにな。
そっちから連絡取って伺い立てんのが筋じゃねえの？
nvCUDA_sha1からコア部分のマクロとかを拝借したつってるから他のライセンスが絡んでる可能性もあるし。
ttp://yakin.38-ch.net/trip/ nvCUDA_sha1はクラックツールだからもともと法的には真っ黒ですけどね。
この件は原作者様にこのスレにお越しいただいて解決することにします。
ttp://yakin.38-ch.net/test/read.cgi/trip/1269695900/20 冬なら暖房いらないですね、これｗ 最近買ったんですけど、
こんなに熱くてうるさいもんだとは思いませんでした。
280M→440MTrip/s @GTX470
> GPUの拘束時間が長い？分重いですがすごい速くなってますね。
> 280M→440MTrip/s @GTX470
報告ありがとうございます。やはりカードによってかなり上昇率にばらつきがあるようですね。
できれば画面のパラメータ等を貼っていただけると有難いのですが…
一応PAUSEキーで一時停止できるようになっていますが、使用中はかなり重くなりますね。
いただきます。◆Horo/.IBXjcgには大変申し訳ないことをしました。謝罪させて頂きます。
ソースコードなし、再配布禁止の新しいバージョンを用意したので、今後ダウンロードされる
かたはこちらをご利用下さい。配布条件の違い以外は前のバージョンと同じです。
ttp://www.meriken2ch.com/files/CUDA_SHA-1_Tripper_MERIKEN0.01a2.zip なお、最初のバージョンは再配布しないでくださるようお願いします。
返す返すも申し訳ありませんでした。
今後の方針としては
(1) ◆Horo/.IBXjcg氏にGPLでの配布の許可をもらえるまで待つ。
(2) なるべくコードの書き換えを進めて、自分のコードにしてしまう。
の二本立てでいきたいと思います。どのみちターゲットを正規表現に対応させるために
大幅に書き換える予定だったので、かえって良かったのかもしれません。
最終目的は10桁のトリップに対応させることだけど、先は長い…
> オリジナルのコードに対するpatchとしてならば、公開しても問題ない…と思う
たしかにその手もありますね。ただ、自分のわかりやすいように変数名を
ほとんど変えてしまったのでいまのままだとパッチがまるごとソースコードに
なりかねませんorz
まあいいや。もうだいたいやり方は分かったから自分で1から書きなおそう。
CUDA用の10桁トリップ検索プログラムも作りたいし。
10桁のが完成するまでに◆Horo/.IBXjcg氏がここに来てくれるといいなあ。
ttp://slashdot.jp/it/comments.pl?sid=540425&cid=1996605 方向性は違うがこれと同レベルで痛いな。
ん? 別に自分で1から書き直す分には問題ないでしょう。
それともバイナリの配布が気に入らないのかしらん。
氏の書いたコードの再配布自体は構わないと仰られてますね。
> 7 ：ののたん ◆KiwamonoL. ：2010/10/24(日) 00:05:13.67 ID:oeeN+FrM0
>
> ソースをいじくりまわしたものを再配布してもいいのでしょうか？
ttp://yakin.38-ch.net/test/read.cgi/trip/1269695900/7 > 15 ： ◆Horo/.IBXjcg ：sage ：2011/06/20(月) 00:57:29.38 (p)ID:UnljLL3w0(3)
>
> わっちは構わぬのじゃが、他から拝借した部分があるからややこしいかもしれぬの。
>
> 確かnvCUDA_sha1とかいうのを改造しようとして、完全にはよう理解せなんだから
> コア部分のマクロとかを拝借した記憶があるの。
ttp://yakin.38-ch.net/test/read.cgi/trip/1269695900/15 もう一回GPLv3でソースを含めて配布することにします。
からんできてる名無しが問題にしてるのは再配布してることじゃなくて、
ライセンスを勝手に設定してることなんじゃないのか。
原作者はいじろうが再配布しようが気にしそうにはないけど。
つーか、パクったことを隠してバイナリだけを配布してる訳じゃないし。
ついでに俺様らしい意地悪なことも書いておこう。ｗｗｗ
許可を求めたのは俺様で、「構わぬ」という返事は俺様宛であって見ている人全員じゃないだろ。(和良
配布しても、元のコードの著作権は氏が保有してるわけですから
氏の権利が制限されることはありません。
> 「構わぬ」という返事は俺様宛であって
あの書き方を見る限り誰が再配布しても構わないようでしたけど。
GPLは改変したソースコードの公開を強制するライセンスですから
ライセンスなしやBSDで配布するより安全でしょう。
「元のライセンスがGPLと互換性がないのにGPLにしたら駄目だ」とかならまだ分かるけど
「元の作者が派生物にGPLをライセンスすることを意図していないかもしれないのに勝手にGPLにしたら駄目だ」なら理解できない
ライセンスの決定権は派生物作者にあるんだから、文句があるなら自分でプログラム書けという話。
ま、GPLは名無しが勝手に色々弄る場所に向いたライセンスとはあまり言えないと思うがね。ある意味非常に厳しいライセンスだし。
しかもバイナリ配布時にソースを添付しないといけない訳でも、ネット上でのソース公開を強制するものでも、バイナリ無償配布を強制するものでもない。
> 見ている人全員じゃない
2人がプライベートで話したのではなく、BBS上で公に書いた以上、それは解釈に無理があるだろう。
ん？GPLのプログラムを売ってはいけない決まりはないぞ。販売もフリーのライセンスだから。
もちろんそれは理解してますけど、GPLは商用ライセンスじゃないでしょう。
やっぱり理解してないな…
何でしばしばGPLと互換性があるライセンスなのかどうかが問題になるのか考えてみよう
ググれよ
ttp://ja.wikipedia.org/wiki/%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%81%AE%E4%BA%92%E6%8F%9B%E6%80%A7 GPLがviralだということは十分承知してますよ。だからこそGPLを選んだんですけど…
もちろん私がGPLv3で改変物を配布しても、◆Horo/.IBXjcg氏は自分のコードは好きに
できるので、別のライセンスを選んで配布することは自由です。
著作物なので氏がBSDライセンスやX11で配布することが出来ます。私がGPLを使うことに
反対されてる方々はここらへんを理解してないのでしょう。
ときに発生する問題であって、Tripperの著作権者である◆Horo/.IBXjcg氏には
あてはまりません。
というわけで自分はの方針で全く問題ないと考えるので、
今後この話は◆Horo/.IBXjcg氏との間だけでさせて頂きます。悪しからず。
sha_digest 2.2
ttp://users.physik.fu-berlin.de/~jtt/sha_digest.html GPLv2のSHA-1の実装です。これをCUDAに移植して最適化して
元のコードとまぜまぜすれば問題は解決するわけだ。
さて次の降臨はいつだ。ｗ
なんというかさすがソフトウェア板。
ライセンスがどうのに厳しいな。
待て屋スレその他でもいろいろいじめられたし。
結局ＧＰＬと言いながら要件を満たさないまま放置してる俺様カコイイ！
にもあるが、やっぱりベクトルは違うが理解してない度は同レベルだな
> 聞いたのが 2010/10/24 で返事が 2011/06/20 。
> さて次の降臨はいつだ。ｗ
今年はもう現れてくれないんじゃないですかｗ
もちろん来てくれることに越したことはないですけど…
> 結局ＧＰＬと言いながら要件を満たさないまま放置してる俺様カコイイ！
こりゃいかんがな (´・ω・｀)
知らない間に元のコードがなくなるぐらいになりますよｗ
次に考えてるのはCUDA内のヒット判定の最適化です。
trip[0]からtrip[4]までの6bits * 5 = 30bitsと
大きさが2^30bits = 128MBの巨大なビットマップを使って、
トリップがパターンにマッチするかどうかをほぼO(1)で
判定できるようにする予定です。
これで検索するターゲットの増加による速度低下はほぼ0になるはずですけど、
うまくいくかしらん。
いつまでたっても最初のサイクルが終わりませんでしたｗ
6完500タゲでも112M tripcodes/sという微妙すぎる結果に。
6完1タゲが788M tripcodes/sなのでえらい速度低下です。
これはなんとかしないと…
こりゃ遅くなるわけです。
「人と人とは理解し合えない」って偉い人が言ってたよ。
『事実』と『妄想』はきっちりわけて、
『妄想』はなるべく垂れ流さないようにしてる俺様だが、
あえて言おう。カｓ・・・・・おっと違う。ｗ
原作者はどうしようと文句言う気なんかないんじゃね？（妄想
つか、妄想で物言うヤツ大杉。
さっさと書き換えてソースを公開したいけど、用事ができてしまい時間がなかなかとれません。
その間にアイディアは溜まっていく一方で、ちょっともどかしいです。
あっさり通ったので、とりあえず生成したトリップを元に
新しいコードの検証をしてみたいと思います。
余計な部分を取り除いてから、CUDA Cに移植する予定。
そのソースをコンパイルしたバイナリをCUDA C（ｒｙ
用意された関数を呼び出したんですが、
Tripperとのコードで同じ結果が出ています。
> SHA1_Context context;
> BYTE digest[SHA1_HASH_SIZE];
> sha1_initialize(&context);
> sha1_add_bytes(&context, key, 12);
> sha1_calculate(&context, digest);
問題はこれからなんだけど…
> void sha1_generate_tripcode(UINT8 *key, UINT8 *digest)
Horo氏はSHA-1のマクロがよくわからんと書いてましたけど、
私もさっぱりわかりませんｗ まあ動いてるからいいや。
食事食べてからCUDA Cに移植しよっと。
使えるんだよな。
しかも元のコードより速くなっててテラワロスｗ
5パーセント近く遅くなってるな…
まあでも一発で動いただけでもよしとしなきゃな。
これから最適化するか…
あ、これは完全に遊びなので、そういう人に迷惑がかかることは
やらないのです。
ループの外に処理を追い出したり、配列の代わりに定数をつかうように
したりしただけですが…
コンパイラの最適化が甘いらしく、ちょっとしたことですぐに速度が
変わってきます。
なんにせよコードもすっきりしたし、言うことなしです。
ちょっと心配だったけどほっとしました。
最終確認をしてからソースを含めてうｐすることにします。
CUDA SHA-1 Tripper 0.2.1 MERIKEN's branch 0.01 alpha 5
ttp://bitly.com/r0jVWJ 出所不明のコードをGPLv2でライセンスされたもので置き換えてあります。
また、前のバージョンに比べて多少速度が上がって表示画面が見やすく
なっています。
ttps://sites.google.com/site/meriken2ch/files C:\Users\新しいフォルダー (9)>CUDA_SHA-1_Tripper_MERIKEN.exe
CUDA SHA-1 Tripper 0.2.1 MERIKEN's branch 0.01 alpha 5
Copyright (C) 2009 ◆Horo/.IBXjcg
Copyright (C) 2011 ◆MERIKEN4.k
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
CUDA DEVICE
===========
Device No.: 0
Device Name: "GeForce GTX 460"
Compute Capability: 2.1
Clock Rate: 1.400GHz
Number of MPs: 7
Number of Blocks: 56
TARGETS
=======
0: +trip.. (0xaedae2a4)
1: TEST/ (0x4c4493fc)
TRIPCODES
=========
C:\Users\新しいフォルダー (9)>
======
Searching for 2 patterns with 5 to 7 characters.
トリップがあるのですが、そのキーを忘れた場合はどのようにどうしたら良いのでしょうか？
専ブラの履歴もしくは、その専ブラのフォルダ内のいづれかのファイル内に残ってないの？
で、どうするかだけど、そのトリップは本当に貴方が使っていたものかどうか？というのが
分からないと、他人になり済まそうとしている可能性もあるわけで。
その辺、証明できるものはある？
Ver 0.01 RC011 と使い分けたら良いかもしれません。
【cudaTripper12Wiz7 - CUDA版12桁トリップ検索ツール】
アップデートしました（cudaTripper12Wiz7 Ver 0.01 RC012 by iincho）。
今回の変更は以下の１のようです。
なお、このバージョンを "current stable version candidate 2" とします。
１．前方一致・後方一致・位置指定なしで65536タゲまで指定できるようにしました。Ver 0.01 RC011よりは多タゲだと遅いです。
実行例：GTX460+Core i7 2600K
【Ver 0.01 RC011】
365.0MTrips/s (CPU:60.9M) [Total 0.0051TTrips, 0.003hours, 0Trips hits] … 1タゲ(前方一致)
343.9MTrips/s (CPU:41.6M) [Total 0.0042TTrips, 0.003hours, 5Trips hits] … 4096タゲ(前方一致)
【Ver 0.01 RC012】
379.0MTrips/s (CPU:61.9M) [Total 0.0081TTrips, 0.006hours, 0Trips hits] … 1タゲ(前方一致)
324.9MTrips/s (CPU:42.0M) [Total 0.0085TTrips, 0.006hours, 4Trips hits] … 4096タゲ(前方一致)
298.1MTrips/s (CPU:36.0M) [Total 0.0083TTrips, 0.006hours, 1Trips hits] … 65536タゲ(前方一致)
証明出来るもの自体がわからないんです。。
> 止まったがな・・
報告ありがとうございます。本当に助かります。どうもNumber of Blocksが
少ないと落ちてしまうみたいですね… ちょっと調べてみます。
あ、どうも〜 これだけタゲが増えても速度が落ちないのは凄いですねえ。
まだ発生します。とりあえず一安心ですが何が原因なんだろ。
CUDAのコードじゃないのかな…
コードを書き直す過程で混入していたみたいです。
◆GikoNekobgさん、ありがとうございました。
ttp://www.meriken2ch.com/files/CUDA_SHA-1_Tripper_MERIKEN0.01a6.zip 速度低下が激しく使い物になりませんでしたorz
やはり256個のスレッドが128MBのメモリにランダムアクセスするという
のは無理があったみたいです。もうちょっとテーブルを小さくすれば
使い物になるかな。
潰しました。
特に問題だったのが、で報告したターゲットの増加に伴う
速度低下の不具合でしたが、マッチ判定の部分をいじったらかなり
改善されました。
6完500タゲ 112M → 555M
6完5000タゲ 測定不能 → 162M
だいぶましになったけど、の数字と比べるとやっぱり
見劣りするなあ… どうしたものか。
===========
Device No.: 0
Device Name: "GeForce GTX 460"
Compute Capability: 2.1
Clock Rate: 1.400GHz
Number of MPs: 7
Number of Blocks: 56
TARGETS
=======
0: ＾trip.. (0x2bb6b8a9)
TRIPCODES
=========
STATUS
======
Searching for 1 pattern with 7 characters.
0.01T tripcodes were generated in 0.01 hours at:
266.77M tripcodes/s (current)
268.81M tripcodes/s (maximum)
266.43M tripcodes/s (average)
No matches were found yet.
> Searching for 1 pattern with 7 characters.
> 0.01T tripcodes were generated in 0.01 hours at:
> 266.77M tripcodes/s (current)
> 268.81M tripcodes/s (maximum)
> 266.43M tripcodes/s (average)
早速助かります。ちょっと数字が落ちてるのが気になりますね。もうちょっと調べてみます。
落ちるようになってしまいました。テーブルを大きくすると落ちるので、
メモリ周りが原因なのかしらん。
どうしてなんだろ…
6完500タゲ 112M → 555M → 721M
6完5000タゲ 測定不能 → 162M → 720M
Parallel Nsight使えば追えるだろ
どうやら落ちてるのは本体側のコードらしいので、
休憩してから追ってみます。
もし教えてもらえたらサブアドレス貼りますのでよかったら教えて下さいm(__)m
このスレまでこれたのなら、自力で何とか出来ないかお前。
逆引き? なんでしょうそれは…
似てるのならいくらでも作れるけど、完全一致となると無理ですねえ。
なってしまいました。ファンの回転数を調整して70度にしたら安定してきました。
うるさいですけど、やっぱりあまり無茶はできませんね。
6完500タゲ 112M → 555M → 721M → 727M
6完5000タゲ 測定不能 → 162M → 720M → 725M
あと、N=1の特殊なケースの際も性能が数％向上しています。
ただターゲットの数が多いケースではビットマップの効果が大きいのですが、
ターゲットが数が数個の場合はグラボのメモリに対する大量のランダムアクセスのおかげで
かえって性能が落ちるようです。できればランタイムで最適な方法をえらべるようにしたいところ
ですが…
まあいいや、無効な出力は処理しないで飛ばしてしまおう。
不明だったけど、こういうことだったんだな。
ほとんど速度が落ちてないですね。素晴らしい。
ちなみに256Kではプログラムが落ちてしまいましたｗ さすがに無茶ですね。
うーん、どうなるか楽しみだ…
てっきりメモリがどかっと書き換えられているのかと思ったら、
そうではなくて特定の数バイトだけがおかしくなっています。
ひょっとしたらこれ、グラボをオーバークロックしたからかもしれんな。
もとに戻して試してみよう。
メモリを頻繁にアクセスするようになったからこんなふうになったんだな。やれやれ。
２ちゃんねるの高校野球版でベスト8ん当てるスレがあるんですが…今まで生き残ってはいるもののトリップを忘れてしまい、証明が出来なくて。
泣けてきそうです(*_*)
トリップテスト版や本文に何も入れなくて試したんですが（80回）ほど時間がかかり過ぎて！
助けてもらえないでしょうか(>_<)
助けてあげたいのはやまやまですけど、どこにも残っていないなら復元は無理です。
そのためのトリップなんですから。スレ違いなのでもう返事はしないので、悪しからず。
応援してます、頑張ってください。
とりあえずこのまま続けて、問題が出てきたら変えるようにします。
色々付け足したい機能があるので当分の間はせっせと取り組むつもりです。
分岐させてたのですが、1つの分岐のコストがしゃれにならないので、
マクロを多用してケースごとに関数を作ることにしました。
可読性? なにそれおいしいの? という感じですが、
その結果ターゲットの数が少ない場合の速度がかなり改善されました。
こんどこそ最初のバージョン(0.01a1)より速くなってるはずです。
幾つかオプションを追加しました。
-b: ヒットしたらビープを鳴らす。
-i: 無効なキー(Unicode非対応)のトリップコードも出力する。
後やりたいのはターゲットの数の上限を取り払うことです。
ここまでできたら次のバージョンを"0.01 beta 1"として公開したいと思います。
後もうちょっとなんだけどなあ。
19万タゲで試してみましたが、速度低下も1タゲと比較して14%程度に抑えられています。
5日前のこと( )を考えると夢のようですｗ
この拡張は正規表現への対応の下準備なので、これぐらい性能に余裕があると安心です。
> Searching for 1 pattern with 7 characters.
> 0.096T tripcodes were generated in 0.032 hours at:
> 831.07M tripcodes/s (current)
> 845.02M tripcodes/s (maximum)
> 836.98M tripcodes/s (average)
> No matches were found yet.
最高速がやたらと大きいのは測定の間隔を短くしたためですが、
平均をと比べても微妙に速くなっています。
やはり1タゲだとかなり無茶ができます。
明日配布パッケージをまとめて、うｐしよっと。
0.01の正式版にすることにします。
CUDA SHA-1 Tripper MERIKEN's Branch 0.01 beta 1
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch ・ターゲット数の制限の撤廃。多ターゲット時の大幅な速度の向上。
ターゲット数が少ない場合の速度もちょっとだけ上がっています。
・正規表現による検索
・10桁トリップの検索
・CPU検索
・速度測定による動的な探索アルゴリズムの選択
(線形・2分探索、キービットマップの使用・不使用)
・GUIの実装
・元のコードの書き換え
正規表現への対応が、内部のデータ構造に与える影響が一番大きくて
頭をつかうので、これから手をつけようかな。9月からまた忙しくなるから
時間のあるうちに片付けておこう。これについてはずっと考えていて、
もう頭の中でアルゴリズムは出来上がってるので、後はせっせと
コーディングをするだけです。
うちでは絶好調で動いてますけど、環境が変わると違うから、ちと不安です。
さて、今日は正規表現への対応の下準備をしていました。
オリジナルのTripperでは、CUDAのコードではトリップの最初の5文字を
使って一致しているかどうか判定していて、残りはCPUが調べています。
いまやっているのは、この「最初の5文字」という制限を取り払って、
CUDAのコードで任意の位置の5文字を比較できるようにする、ということです。
そのために色々内部構造を拡張しているのですが、CPUとGPUの
アドレス空間の違いを常に意識しなければいけないのでかなりめんどくさいです。
このプログラムには余計な制限は一切付けない方針です。
あ、あともう一つ新しいオプションを付けました。
-w: 速度が急に低下したら警告する。
グラボをOCしてるときにひんぱんにpower throttlingがかかって
速度が低下したので、念のためこのオプションを追加しました。
反応が薄くても仕方ないよなｗ
やっぱ本命はあくまで正規表現と10桁対応だよな。この2つは今月中にぜひ
やり遂げたい。
C:\Users\>CUDA_SHA-1_Tripper_MERIKEN.exe
CUDA SHA-1 Tripper 0.2.1 MERIKEN's branch 0.01 beta 1
[compiled at 06:32:36 on Aug 13 2011]
Copyright (C) 2009 ◆Horo/.IBXjcg
Copyright (C) 2011 ◆MERIKEN4.k
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
CUDA DEVICE
===========
Device No.: 0
Device Name: "GeForce GTX 460"
Compute Capability: 2.1
Clock Rate: 1.400GHz
Number of MPs: 7
Number of Blocks: 56
TARGETS
TRIPCODES
=========
STATUS
======
Searching for 123 patterns with 7 to 11 characters.
0.012T tripcodes were generated in 0.014 hours at:
242.87M tripcodes/s (current)
258.06M tripcodes/s (maximum)
246.23M tripcodes/s (average)
No matches were found yet.
STATUS
======
Searching for 198173 patterns with 6 to 12 characters.
0.004T tripcodes were generated in 0.005 hours at:
241.56M tripcodes/s (current)
249.60M tripcodes/s (maximum)
244.38M tripcodes/s (average)
No matches were found yet.
Searching for 198173これぐらいがふつうですよね・・
と思ったら、ここにはまだか………。
CUDA 4.0でFermiに最適化したコードを吐かせると30%も速くなるのかや。
Mapped Memoryは面倒そうじゃが、上手くいったときのメリットも大きそうじゃな。
ただのパスワードクラッカーの作成や利用そのものが法に触れるような国はどこかの？
仮に法に触れるとすれば、それはそれでそんなものを参考にしてツールを作るのは倫理的にどうなんだという話になりかねんしの・・・
ヒット判定自体が重いことに加えて、ワープ・ダイバージェンスの問題も起きていそうじゃな・・・
理解できなんだのは別の部分なのじゃが、まああのマクロも1から書けと言われると厳しいの。
グローバルメモリへのアクセスは色々と面倒じゃから、ビットマップを使うという発想はなかったの。
早速見せてもらっているのじゃが、こういうマクロの使い方もあったとはの w
正規表現や10桁トリップへの対応は相当な作業量にならないかの。
分岐が多発する状況はかなり気を使う必要があって面倒じゃな。
GTX 580のOCは消費電力も凄そうじゃの・・・
いつもありがとうございます。そちらで無事に動いているのが
確認できてほっとしました。でも19万ターゲットは普通じゃないですｗ
複雑な正規表現が展開された時のことを見越して性能を上げておいたのです。
わざわざお越しいただいてありがとうございます。
公開してくださったコードのおかげで楽しく遊ばせていただいてますｗ
改変したものは、問題がないと判断してGPLv3で公開しましたが、
もし問題がありましたら、一言いただければ直ぐに対処させて頂きます。
> Mapped Memoryは面倒そうじゃが、上手くいったときのメリットも大きそうじゃな。
以前試したときには思ったほど効果は上がりませんでした。
ランダムアクセスが大量に発生するからかも知れません。
>
> ただのパスワードクラッカーの作成や利用そのものが法に触れるような国はどこかの？
> 仮に法に触れるとすれば、それはそれでそんなものを参考にしてツールを作るのは倫理的にどうなんだという話になりかねんしの・・・
アメリカではこんな話もあります。
ttp://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%9F%E3%83%AC%E3%83%8B%E3%82%A2%E3%83%A0%E8%91%97%E4%BD%9C%E6%A8%A9%E6%B3%95 >
> ヒット判定自体が重いことに加えて、ワープ・ダイバージェンスの問題も起きていそうじゃな・・・
なるほど、道理で… 条件文が入るとやたらと遅くなる理由がわかりました。
> グローバルメモリへのアクセスは色々と面倒じゃから、ビットマップを使うという発想はなかったの。
1バイトを1ビットとして扱う富豪的プログラミングですｗ
> 早速見せてもらっているのじゃが、こういうマクロの使い方もあったとはの w
あれはCのプリプロセッサが貧弱なので見た目がひどい事になってるだけですｗ
> 正規表現や10桁トリップへの対応は相当な作業量にならないかの。
正規表現対応のCUDA側の準備は終わったのでなんとか頑張ります。
10桁トリップももうコードがあるのでなんとかなるでしょう。
ttp://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/des.c > GTX 580のOCは消費電力も凄そうじゃの・・・
Tripperをはしらせるだけで200W近く跳ね上がります。部屋が暑いです…
----
てっきり当分来られないものだと思い込んでいたのでびっくりしましたｗ
わざわざコードまで読んでいただいて光栄です。
1年後とおっしゃらず、またぜひお越しください。お待ちしております。
＼ __ ／
＿ （ｍ） ＿ﾋﾟｺｰﾝ
|ミ|
／ ｀´ ＼
('A`)
ノヽノヽ
くく
さっきこんな感じでひらめいて、最小限の手間で
前方一致だけでなく任意の位置の文字列を探索する機能が実装できました。
後は本体側で正規表現を展開する処理を実装すればいいだけです。
まあ技術的に一番難しい部分は解決したわけだからいいか。
任意の位置で検索できるようにしました。速度は20％以上
落ちますがまあこれは仕方がない。あとは今後の最適化次第です。
楽しんでもらえて嬉しいでありんす。
わっちが書いた部分は構わぬというか、改造版を見て楽しんだりとかを考えるとライセンスの衝突が無ければその方が良さそうじゃの。
演算量に対してホスト・デバイス間のデータ転送量が十分に少ないから差が出にくいのかの。
DMCAは範囲が限定されておるが、それでもかなり議論になっておるの。
EUの方ではクラッキングツールの違法化を唱えておる者もおるみたいじゃが、愚かなことにならなければいいがの・・・
メモリ使用量的には富豪的とは思わぬが、グローバルメモリへのアクセス、それもランダムなのが気になるのじゃが
アクセスにかかる時間は大量のスレッドで隠蔽できておるということかの。
あの巨大なマクロは一部が異なる関数を多数作るのに利用しておるのかや？
DESベースのcryptをCUDAで実装するのは色々と苦労しそうじゃが、
主様はわっちよりかなり頭が良さそうじゃから期待していいのかの？ w
消費電力が増加分だけで200Wとはハイエンドのグラボとは怖ろしいものじゃの・・・
どうやっておるのか気になるの。
その方法を考えながら待つというのもまた楽しいがの w
> 楽しんでもらえて嬉しいでありんす。
> わっちが書いた部分は構わぬというか、改造版を見て楽しんだりとかを考えると
> ライセンスの衝突が無ければその方が良さそうじゃの。
そう言っていただけるとほんとうに有難いです。
> 演算量に対してホスト・デバイス間のデータ転送量が十分に少ないから差が出にくいのかの。
いったん準備が整ったらCPU側ではCUDAのメモリはいじらないですからね。
> DMCAは範囲が限定されておるが、それでもかなり議論になっておるの。
> EUの方ではクラッキングツールの違法化を唱えておる者もおるみたいじゃが、
> 愚かなことにならなければいいがの・・・
経済活動のために自由を制限しようという動きは活発ですからね。心配です。
> メモリ使用量的には富豪的とは思わぬが、グローバルメモリへのアクセス、
> それもランダムなのが気になるのじゃが
> アクセスにかかる時間は大量のスレッドで隠蔽できておるということかの。
これはアクセスするメモリの量によってだいぶ変わってきます。
最初は30bitのtarget_dwに直接対応する2^30=1GBのキー・ビットマップを試してみた
ですが、かえって遅くなったのでサイズを2^24=16MBに減らしました。
ビットマップのサイズは可変に出来るので、いずれは動的に最適化する予定です。
ビット単位で変えて速度を測定するのもいいかもしれません。
> あの巨大なマクロは一部が異なる関数を多数作るのに利用しておるのかや？
そうです。CUDAのコードのループの中に条件文を書きたくなかったのでああなりました。
あまりの大きさに、書いてて自分でも笑っちゃいましたけどｗ
> DESベースのcryptをCUDAで実装するのは色々と苦労しそうじゃが、
> 主様はわっちよりかなり頭が良さそうじゃから期待していいのかの？ w
この論文によればGT200シリーズで75.2Mkey/sがでたとあるので、
何とかできると思います。(5ページ目には実装の詳細があります)
Record Setting Software Implementation of DES Using CUDA
ttp://home.dei.polimi.it/barenghi/files/ITNG2010.pdf 10桁トリップの検索はどうしても欲しい機能なので、頑張りますです。
> どうやっておるのか気になるの。
> その方法を考えながら待つというのもまた楽しいがの w
数日中にα版を公開する予定なのでご期待くださいｗ
正規表現の"^"と"$"が使えるようになりました。
処理の枠組みはできたので、あとはごりごりとパーサの
残りを実装するだけです。
落とし所を見つけるつもりです。今のところ考えているのは
"."と"[]"と"[^]"と"*"と"+"と"()"と"|"ぐらいです。
このパーサの目的は、「可能な組み合わせをすべて出力する」ことなので、
「特定の文字列が街しているか調べる」普通のパーサとは
ちょっと趣が異なっています。
とりあえずあると便利そうなものから実装中。
"[:digit:]"と"[:alpha:]"と"[:alnum:]"と"[:punct:]"を扱えるようにしよう。
ttp://php-regex.blogspot.com/ こんな感じでパターンがかけます。
> ^[:digit:][:digit:][:digit:][:digit:][:digit:][:digit:][:digit:]/
この場合、10^7=1千万パターン(!)に展開されて、こんな感じで出力されます。
> ◆1953978/Kq7w #ｰ困ﾂﾞEl隣ﾍﾛﾀ (b0 8d a2 c2 de 45 6c 97 d7 cd db c0)
> ◆1971051/RdkX #ｰ困ﾂﾞEk澂浩ﾓ (b0 8d a2 c2 de 45 6b e0 4c 8d 5f d3)
> ◆6994841/7Fro #ｰ困ﾂﾞEjyｶEｱ3 (b0 8d a2 c2 de 45 6a 79 b6 45 b1 33)
>
> STATUS
> ======
> Searching for 10000000 patterns with 8 characters.
> 0.004T tripcodes were generated in 0.005 hours at:
> 190.77M tripcodes/s (current)
> 194.56M tripcodes/s (maximum)
> 191.42M tripcodes/s (average)
> 116 matches found at 22553.47 matches/h and 0.03G tripcodes/match.
> The matching rate is about the same as expected.
> 9% of matching tripcodes were invalid.
これは面白すぐる。
調子にのって1億パターンに挑戦してみましたが、
さすがにメモリ不足で怒られましたｗ
でもこれ、64bitでコンパイルして本体のメモリを
追加したらもっといけるんだろうな。わくわく…
コードをコピペしてちょちょっと変えただけですけが…
[:digit:]
[:alpha:]
[:lower:]
[:upper:]
[:alnum:]
[:punct:]
[:punct:]は"/"か"."にマッチするので特に便利かと思います。
例えば、"^TEST[:punct:][:punct:]"というパターンはこのように展開されます。
> ◆TEST..OjMvcT #/Mｻｪ罨ﾓｩﾔﾌｭd (2f 4d bb aa e3 aa d3 a9 d4 cc ad 64)
> ◆TEST..aiAWbN #2ﾏ夙餽d｡ｪH｡ｻ (32 cf 8f 67 e9 58 64 a1 aa 48 a1 bb)
> ◆TEST/.PruAhy #Z｣ﾆ儚FTBﾋｵxT (5a a3 c6 99 52 46 54 42 cb b5 78 54)
> ◆TEST//QQQWcT #☆熨W廠房ﾓﾂT (81 99 e0 91 57 8f b1 96 5b d3 c2 54)
> ◆TEST..kJu97D #ﾒ永ﾞv57ﾃpｸﾍg (d2 89 69 de 76 35 37 c3 70 b8 cd 67)
> ◆TEST/.dndcgU #ﾒ永ﾞv5ﾚW7儡6 (d2 89 69 de 76 35 da 57 37 99 53 36)
>
> STATUS
> ======
> Searching for 4 forward matching expanded patterns with 6 characters.
> 0.099T tripcodes were generated in 0.036 hours at:
> 748.98M tripcodes/s (current)
> 755.96M tripcodes/s (maximum)
> 754.48M tripcodes/s (average)
> 6 matches found at 165.20 matches/h and 16.44G tripcodes/match.
> The maching rate is 4% higher than expected.
> 0% of matching tripcodes were invalid.
CUDAのコードとは関係ないんだから最初にまじめに展開する必要がないような…
そのまま正規表現を残してもいいし、特殊な内部コードを使っても
いいんだよな。まあいいや、これはほかのを実装してから後で考えよっと。
> ^...\.\.\.\.\.\.
これをパターンとして設定すると、こんな具合になります。
このような比較的単純なパターンでも26万通りに展開されるので、
性能を上げておいてよかったです…
----
TRIPCODES
=========
◆Rrh......FsN #X訣閘ｰｰa悪O. (58 8c 8d e8 7d b0 b0 61 88 ab 4f 2e)
◆fmz......OWP #ｼ夾斎揮7Bｴｾｵ (bc 9a f1 8d d6 8a f6 37 42 b4 be b5)
◆eum......qNE #K趣q｢N5ﾛﾑrｼｨ (4b 8e ef 71 a2 4e 35 db d1 72 bc a8)
◆UWS......jbg #ｼsP鰲ﾔ馨i曚ﾄ (bc 73 50 e9 e0 d4 8a 5d 69 9e 43 c4)
STATUS
======
Searching for 262144 expanded patterns with 9 characters.
0.071T tripcodes were generated in 0.056 hours at:
351.55M tripcodes/s (current)
351.88M tripcodes/s (maximum)
349.15M tripcodes/s (average)
4 matches found at 71.31 matches/h and 17.63G tripcodes/match.
The maching rate is 290% higher than expected.
0% of matching tripcodes were invalid.
さて、'*'と'+'の実装も終わりました。ただ、このままだと
展開されるパターンの数が多すぎてまったくおいしくないことが判明。
今のところは次のようなパターンで12連のトリップを指定することぐらいしか
使い道がありません。
^.*$ # 12連
あんまりきれいな実装ではないですが、パターン用の特殊文字を
使うしかないようです。もしこれが実現すれば、次のようなパターンでも
きちんと検索できるはずです。
^[:digit:]*$ # 数字のみ
'.'を展開してから伸ばすんじゃなくって、'.'を伸ばしてから
展開するんだった。意外に難しいな…
演算子の優先順位を間違えてエライ目に遭いましたが、なんとか直せました。
あとはカッコと'|'と"[]"への対応が済めば、パーサは完成。色々試してみたいので楽しみです。
これさえ終われば、パターンの比較用に特殊文字を実装して最適化したら、
正規表現への対応は完了です。うまくやれば、みたいなケースでも
正規表現を展開せずに済むようになるはずです。今日はもう時間がないから
明日にしようっと。
（⌒,_, ,⌒て ,,_,)
! ﾉ U｡`ｙﾍ_,､_ﾉ !
し|~〜〜 ｡ ﾍ⌒iヽﾌ
|! ﾟo ｡.ﾟ（・ω|･ ) おつかれ
|! ｡oﾟ ⊂ ﾟ とﾉ
|i ｡ﾟ ﾟ o .ﾟ|.｡|. |
|i、..゜｡。ﾟ ﾟし|'Ｊ
. |,,._二二二_,!
。ﾟo
UINT8で2^24個というのはそういうことだったのかや w
巨大なビットマップで1byteに1bitは富豪的すぎるかも知れぬの。
しかしビットマップでヒットした場合に別の方法で改めて検索するというのはなかなか面白いの。
BitSlice DESをCUDAで実装すればGTX 260で373Mkey/sかや・・・
crypt()に応用したときにどのくらい速度が出るかも含めて気になるの。
あ、どうもｗ 美味しくいただきますです。
後方一致は正規表現の一部としてもうつけちゃったので、次に公開する版で
使えるようになります。最適化してないので前方一致ほどは速くないですけど…
CPU検索はWin32のスレッドの使い方さえわかればすぐに実装できるはずなので、
10桁への対応が終わったら取り掛かります。
あ、みえてたんですね。こんばんわ〜
>
> UINT8で2^24個というのはそういうことだったのかや w
> 巨大なビットマップで1byteに1bitは富豪的すぎるかも知れぬの。
>
> しかしビットマップでヒットした場合に別の方法で改めて検索するというのはなかなか面白いの。
最初は真面目に8bit全部使ってたんですけど、それだと速度的においしくないのでやめましたｗ
2段構えになっちゃったのは偶然ですけど、ほとんどのケースでO(1)でヒット判定ができるので
結構うまく動いてると思います。
> BitSlice DESをCUDAで実装すればGTX 260で373Mkey/sかや・・・
> crypt()に応用したときにどのくらい速度が出るかも含めて気になるの。
これはほんとうに楽しみです。正規表現を速く終わらせてこっちに取り掛からねば…
それだけで3M tripcodes/s以上速度が上がりました。やはりグローバルメモリへのアクセスは
なるべく避けたほうがいいみたいですね。
まだ最適化の余地があったのには驚きましが、ターゲットの数が少ない場合はスレッドの
ローカルメモリ(8K)かマルチプロセッサ内の共有メモリ(48K)をつかえば更に高速にできるかもしれません。
> 打倒mty！
10桁でGPU版待て屋を超えるのが目標ですけど、はたしてどうなるんでしょうねｗ
同じハードウェアならともかく。
CUDAにも大分慣れてきたし、わかりませんぞｗ
8bit全部使うと速度的にというのがよく分からんのじゃが、ビットのテストのコストが意外と大きいということかの？
バイナリサーチやリニアサーチを行う確率が1/(2^24)になるのは結構おいしそうじゃの。
グローバルメモリはアクセスに数百サイクルかかるのじゃったかの・・・
ローカルメモリ(8KB)はコンスタントメモリの間違いかの？
シェアードメモリはFermiでは48KBみたいじゃが、それ以前のものは16KBみたいじゃから
環境依存を減らすならそのあたりも気をつけたほうがいいかも知れぬの。
2^16分のビットマップを8KiBにしてシェアードメモリに乗せてみるのも面白いかも知れぬの。
その差は歴然だった。(同一バイナリでｗ)
まあ、AMD が OpenCL に力入れてるってのもあるかもしれんが。
あと某外人がやってるのを観察してるんだが、こんな感じだな。
GeForce GTX580 670M
Radeon HD 5770 680M
580でも5770に勝てないレベル
>
> 8bit全部使うと速度的にというのがよく分からんのじゃが、ビットのテストのコストが意外と大きいということかの？
何日か前に試してみたときにはそうでした。勘違いかもしれないので、ビットマップの最適化を
するときにもう一度調べてみます。
>
> グローバルメモリはアクセスに数百サイクルかかるのじゃったかの・・・
>
> ローカルメモリ(8KB)はコンスタントメモリの間違いかの？
per-threadのメモリのことだったんですけどサイズは16〜512Kの間違いでした。
> シェアードメモリはFermiでは48KBみたいじゃが、それ以前のものは16KBみたいじゃから
> 環境依存を減らすならそのあたりも気をつけたほうがいいかも知れぬの。
これは知りませんでした。危ない危ない…
> 2^16分のビットマップを8KiBにしてシェアードメモリに乗せてみるのも面白いかも知れぬの。
これは実に興味深いです。後で試してみます。
GPGPUはかなり奥が深いですね。
> OpenCL で作ったトリッパーをゲフォとラデで走らせてみたが、
> その差は歴然だった。(同一バイナリでｗ)
> まあ、AMD が OpenCL に力入れてるってのもあるかもしれんが。
うーん、OpenCLのことは何も知らないのでそこらへんはなんとも…
> GeForce GTX580 670M
これだけでたら大喜びですよｗ
> Radeon HD 5770 680M
これ、実際のところどうなんでしょ? 5770と待て屋の組み合わせだと100Mでてないですけど…
ttp://yy43.60.kg/test/read.cgi/tripageruo/1178031498/900n ttp://yy43.60.kg/test/read.cgi/tripageruo/1178031498/955n OpenCLは極限まで性能を引き出そうとすれば、アーキテクチャ毎にコードを書かなければならないとかいう噂もあるからの・・・
演算性能の理論値的にはRadeonの方が上みたいじゃが、良くも悪くもAMDは理想が高くて
Radeonのアーキテクチャもまた変更になるという話もあるからの。
ハッカーレベルの者やチャレンジャー以外は、CPUとGPUの開発環境レベルでの統合が落ち着くまで様子見というのも少なくないかも知れぬ。
per-threadというとローカルメモリじゃと思うが、ハードウェア的にはグローバルメモリと同じで
オフチップでグローバルメモリと変わらない、というか全スレッドで共有できない分
1スレッドが使えるメモリが減ってデメリットばかりの気もするの。
10桁版ならcrypt()じゃから100M出れば十分というか、それでも凄いと思いんす。
> per-threadというとローカルメモリじゃと思うが、ハードウェア的にはグローバルメモリと同じで
> オフチップでグローバルメモリと変わらない、というか全スレッドで共有できない分
> 1スレッドが使えるメモリが減ってデメリットばかりの気もするの。
なるほど… さっきN=1のケースで速くなったのは、配列へのアクセスが無くなった
せいかもしれません。もうちょっと調べてみます。
例えば"[Nn][Uu][Ll][Pp][Oo]"と指定すると、"nullpo"や"NULLPO"や"NuLuPo"や"nullPO"に
マッチします。ちゃんと'-'や'^'での文字範囲の指定もできます。
ようやくこれで'*'や'+'の使いやすくなりました。
鳥屋先生の皮算用ｗでは、SHA-1 なら DES の 5 倍は速度が出る、らしい。ｗ
まあそのスレ見てんなら知ってるだろうけど、
ttp://yy43.60.kg/test/read.cgi/tripageruo/1274911652/305 って状態だが。
OpenCL で作ったヤツは、同一バイナリで CPU でも動くんだがこれがやたらと速い。
たぶん、俺がなんかミスってるというオチの悪寒がするが。ｗ
> は SHA-1 での値。
ですよね〜 それにしても5770の数値が高すぎるような気がしますけど…
> 鳥屋先生の皮算用ｗでは、SHA-1 なら DES の 5 倍は速度が出る、らしい。ｗ
ほんとかなあｗ ますます580でDESの速度を試してみたくなりました。
> まあそのスレ見てんなら知ってるだろうけど、
>
ttp://yy43.60.kg/test/read.cgi/tripageruo/1274911652/305 > って状態だが。
このレスは読んでませんでした。なかなか面白い数値が出てますね。
やっぱデュアルコアの6990にシングルコアの580で対抗するためには
SLIにするしかないのかなあ。マザボと電源を変えなきゃいけないから
当分の間は無理ですけど…
> OpenCL で作ったヤツは、同一バイナリで CPU でも動くんだがこれがやたらと速い。
> たぶん、俺がなんかミスってるというオチの悪寒がするが。ｗ
ヒット率を理論値と較べてみると捗りますよ。
このプロジェクトが一段落したらほかのGPGPUの環境もしらべてみよう。
単一のバイナリでどの環境でも動けば最高だけど、実際どうなんだろう…
なんかここ最近で一番頭を使った気がするｗ
ようやく正規表現のパーサが出来ました。色々試してみたけど、かなり強力です。
例えば、
^([Hh]oge[Mm]oge|HOGEMOGE)[:digit:]*$
と指定してやると、”◆hogemoge1418"や"◆HOGEMOGE3241"や"◆HogeMoge9658"などに
ヒットします。かなり使いでがありそう…
しました。
> TARGETS
> =======
> ExpandRegexPattern(): regexPattern = `^([Hh]oge[Mm]oge|HOGEMOGE)[:digit:]*$'
>
> TRIPCODES
> =========
>
> STATUS
> ======
> Searching for 50000 patterns (5 chunks) with 12 characters.
> 0.189T tripcodes were generated in 0.071 hours at:
> 738.19M tripcodes/s (current)
> 744.15M tripcodes/s (maximum)
> 741.88M tripcodes/s (average)
> On average, it takes 4.0 years to find one match at this speed.
>
> No matches were found yet.
"On average . . ."以下に平均時間が表示されます。
の例では4年になるのでまず無理ですねｗ
正規表現の展開によるパターン数の指数関数的増加(、)を
抑えるために、内部用の特殊文字を導入したいのですが、
この変更ではかなりプログラムの内部構造に手を入れることになるので
ちと心配です。まあでもいまさらだからいいかｗ
数字だけのトリップがわさわさ採れます。
だいぶ気をつけてコーディングしたかいがあって、効果は抜群です。
今日はこれぐらいにして続きは明日やろう。
首尾よくいけば明日には正規表現対応のバージョン0.02b1を
うｐできるはずです。
----
TRIPCODES
=========
◆935340684724 #ﾂW/ｬ､W鎹ｯ3ﾗP (c2 57 2f ac a4 57 e8 50 af 33 d7 50)
◆955383526152 #茎ﾏﾓﾞ切催慙8 (8c 73 cf d3 de 90 d8 8d c3 9c cd 38)
◆934093551771 #2遖ｴﾕ近鰮c葢 (32 e7 a6 b4 d5 8b df e9 d9 63 e4 e2)
STATUS
======
Searching for 100000 patterns (100000 chunks) with 12 characters.
0.020T tripcodes were generated in 0.010 hours at:
540.20M tripcodes/s (current)
545.24M tripcodes/s (maximum)
544.47M tripcodes/s (average)
On average, it takes 8.7 seconds to find one match at this speed.
3 matches found at 294.37 matches/h and 6.66G tripcodes/match.
The matching probability is 29% lower than expected.
0% of matching tripcodes were invalid.
( ´･ω･)
( つ O
と＿)＿) 旦
|ﾍ⌒ヽﾌｽﾞｽﾞｰ
| ・ω・）
|つC□)
ありがとうございます。ほかの特殊文字も追加したら
大絶賛エンバク中ですｗ 今日中に治るといいなあ。
完全にバクを見逃してたよな。つけといてよかった。
理論値はかなり真面目に計算してるので、またぜひコードを
みてやってください。
こりゃヒット率が落ちるわけだ。
で、バクをひとつ直したと思ったら今度は謎のスピード低下。
すんなり行くかと思ったけど、やはり一筋縄ではいかないですね。
無茶させすぎてるせいかpower throttlingがかかりまくりです。
GPU-Zの特殊オプションでいちいち解除してるんですけど
メンドクサイので、GUIをつけるときには解除する機能を
つけたいです。
色々アイディアはあるんですけど… とりあえず必要な機能を
揃えてからですね。
特殊文字を使うと効率はよくなるのですが、次のような正規表現の場合に困った事になります。
NUL.PO
NULLPA
この場合どちらが先になるかわからないので、ヒット判定の時のCPU側のbinary searchの
ルーチンが正しく動作しません。これは正規表現に対応していないオリジナルにはなかった
問題ですが、'.'を展開するルーチンを組み込んで解決しました。思わないところで問題が
でてくるものですが、うまくいったと思います。
前方一致でない検索で極端に遅くなるケースが確認されましたが、
この問題への対処はランタイムでの最適化に対応するまで後回しにする予定です。
これから新しいバージョンのパッケージを用意するのでちょっと待っていて下さい。
.r ヾ
＿_|_| /￣￣￣/＿
＼/ /
それにあたります。(安定版の0.01は0.01bとまったく同じです)
これまで書いた通り、正規表現への対応等、かなり使い勝手が
よくなっています。使っていただけたら動作報告をしていただけると
非常に嬉しいです。
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch お待たせしましたｗ ぜひ楽しんでくださいな。
CUDA_SHA1_Tripper_MERIKEN: ERROR: There is an invalid character in a target pattern.
・・・・
> ども〜
>
> CUDA_SHA1_Tripper_MERIKEN: ERROR: There is an invalid character in a target pattern.
>
>
> ・・・・
早速助かります。これ、ターゲットには何を設定されました?
正規表現のターゲットは"target_regex.txt"にお願いします。
CUDA DEVICE
===========
Device: 0 ("GeForce GTX 460") with 7 multiprocessors at 1.400GHz
Compute Capability: 2.1
Number of Blocks: 56
TARGETS
=======
0: "TEST/"
No collisions were found.
TRIPCODES
=========
◆TEST/Z5dS7ky #9ｻ嵬ｮﾏ訊豆Xｨ (39 bb 9b ca ae cf 90 75 93 a4 58 a8)
◆TEST/0YfiOTH #｢貨ysﾉ3Kｫﾅ變 (a2 89 dd 79 73 c9 33 4b ab c5 9d cc)
◆TEST/iMX12Wp #者ﾒﾖkﾚp槹ﾟﾖｯ (8e d2 d2 d6 6b da 70 9e dd df d6 af)
STATUS
======
Searching for 1 pattern (1 chunk) with 5 characters.
0.006T tripcodes were generated in 0.013 hours at:
266.64M tripcodes/s (current)
273.12M tripcodes/s (maximum)
128.82M tripcodes/s (average)
On average, it takes 5.8 seconds to find one match at this speed.
3 matches found at 225.65 matches/h and 2.06G tripcodes/match.
The actual matching probability is 48% lower than expected.
0% of matching tripcodes were invalid.
正規表現もぜひぜひｗ試してみてください。
こんどからサンプルには面白そうな正規表現を入れておこう。
さて、ひと段楽したけど、これからどうしようかな…
もう一回スピードテストしてみようかな。
> Searching for 1 pattern (1 chunk) with 7 characters.
> 0.060T tripcodes were generated in 0.020 hours at:
> 845.63M tripcodes/s (current)
> 845.63M tripcodes/s (maximum)
> 843.56M tripcodes/s (average)
> On average, it takes 59.3 minutes to find one match at this speed.
最高速の推移: 810.83M → 815.35M → 836.84M → 845.02M → 845.63M
平均の推移: N/A → 813.56M → 836.08M → 836.98M → 843.56M
(過去の記録: )
速度測定の間隔を再調整したため今回は最高速はそれほどあがってませんが、
平均が6.5M TPSあがっているのは非常に大きいです。
Shift-JIS関連の条件文を一つ減らして、ヒット判定用の変数を
ひとつグローバルメモリからローカルメモリに移しただけなんですが…
やはりHoro氏がおっしゃられたように条件文とグローバルメモリへの
アクセスは相当なペナルティになるようです。ループ内でグローバル
メモリにアクセスしている場所は数箇所あるので、シェアードメモリを
うまく使ってやればまだまだ最適化の余地はありそうです。
STATUS
======
Searching for 136 patterns (136 chunks) with 5 to 9 characters.
1.086T tripcodes were generated in 1.187 hours at:
254.54M tripcodes/s (current)
258.04M tripcodes/s (maximum)
254.20M tripcodes/s (average)
On average, it takes 2.9 seconds to find one match at this speed.
944 matches found at 795.40 matches/h and 1.15G tripcodes/match.
The actual matching probability is 3% higher than expected.
9% of matching tripcodes were invalid.
> 小一時間ほどマワシテミタ
あ、いい感じですねえ。
> 3% higher
これが0%、
> 9% of matching tripcodes were invalid.
これが7%に近ければ近いほどよいということになってるので、
なかなかよい具合に収束しています。今回はプログラムの内部に
めちゃくちゃに手を加えたのでちと心配だったので、安心しました。
インデックスからShift-JISコードへの変換テーブルが無駄に大きい
ことが判明。気前よくグローバルメモリに65536バイトの配列を
3つ用意してたんですが、最初の400バイトちょっとしかアクセスして
ませんでしたｗ 余裕を持ってサイズを設定しても2Kすらいかないので、
こいつをシェアードメモリに移してやれば高速化できるかもしれません。
もうこのプログラムのことは手に取るようにわかるようになったので、
もう一回見直してみたらかなり無駄が省ける気がします。楽しみだ…
前方一致で正規表現を使わないなら数百万でも大丈夫じゃ
ないでしょうか。
使わない設定になっていました。おかしいと思ったんだよな…
明日不具合を修正したBeta 2をうｐします。
アクセスをもう2つ削除したら、さらに速くなりました。
> Searching for 1 pattern (1 chunk) with 7 characters.
> 0.063T tripcodes were generated in 0.021 hours at:
> 852.07M tripcodes/s (current)
> 852.50M tripcodes/s (maximum)
> 850.53M tripcodes/s (average)
> On average, it takes 58.8 minutes to find one match at this speed.
OC耐性も上がって(967/1934/2103)、非常においしい結果に。
まだまだいけそうです。
> Searching for 1 pattern (1 chunk) with 7 characters.
> 0.061T tripcodes were generated in 0.020 hours at:
> 852.18M tripcodes/s (current)
> 858.99M tripcodes/s (maximum)
> 852.42M tripcodes/s (average)
> On average, it takes 58.7 minutes to find one match at this speed.
OC耐性は落ちましたが(965/1930/2103)、確実に速くなっています。
まだまだ伸びそうですが、とりあえずこれが今日までのところの
最高速です。今日だけでmax, averageとも13M TPS以上伸びたので
上出来でしょう。
【CPU】i7 2600
【OS】Windows XP SP3 32bit
【バージョン】0.02 Beta 1
【オプション】-d 0 -x 8
【Display Driver】280.26
【速度】
263.08M tripcodes/s (current)
263.08M tripcodes/s (maximum)
262.46M tripcodes/s (average)
【その他】タゲは Nonotan のみ
同じマシン同じ条件で CUDA Toolkit v4.0 を使って、
-arch=sm_21 でコンパイルした CUDA SHA-1 Tripper 0.2.1
939524 kTrips in 3.594 sec - 261.415 MTrips/sec
939523 kTrips in 3.610 sec - 260.256 MTrips/sec
939524 kTrips in 3.609 sec - 260.328 MTrips/sec
939524 kTrips in 3.594 sec - 261.415 MTrips/sec
939523 kTrips in 3.609 sec - 260.328 MTrips/sec
同じまｓ（ｒ
俺様作の OpenCL トリッパーだとこんなもん。ｗ
112.728010Mtps
あ、どうもわざわざ助かります。1タゲだと意外にオリジナルと差が出ないですね。
最適化が進んだ次のバージョンだと違うのかなあ。”-arch=sm_21"が
効いているのかもしれません。あとで調べてみます。
あと、やっぱりOpenCLの共通のコードだと厳しいみたいですね。
コードを書くときはアーキテクチャにべったりですからねえ。
CUDA SHA-1 Tripper MERIKEN's Branch 0.02 Beta 2
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch 0.02 Beta 1にあったかなり大きなバグをいくつか修正したので、
Beta 1をダウンロードされた方もぜひこちらを再度ダウンロード
してください。このバージョンに特に問題がなければ、これを
正式版にする予定です。
"TEST/"のみ
7.7MTrips/sec
動いた＞＜
おつですおつです＞＜
動作報告、ありがとうございます。
オプションで"-x 2"とか"-x 4"とか指定するともうちょっと速くなる
かもしれません。ここらへんの設定は自動でできるようにする予定です。
作業をしています。必要なコードはほとんどすべて揃ってるので、
あとはメインループを書くだけなんですが、どうなるかしらん。
> Searching for 1 pattern (1 chunk) with 5 characters.
> 0.000T tripcodes were generated in 0.009 hours at:
> 3.50M tripcodes/s (current)
> 3.50M tripcodes/s (maximum)
> 3.43M tripcodes/s (average)
> On average, it takes 3.6 minutes to find one match at this speed.
1スレッドだけだし、最適化もへったくれもないんだけど、
GPUと比べるとちょっとね… 比較対照がほかにないので
どう判断していいものかさっぱりわかりません。
一応CPUはPhenom II x6 1100T @ 3.30GHzなんだけど、
6コア全部使わないとあんまりおいしくないですね、これ。
ちなみに手元のノートPCのCore 2 Duo T9550 @ 2.66GHzでは
平均が2.55M TPSでした。
乙
CUDA DEVICE
===========
Device: 0 ("GeForce GTX 460") with 7 multiprocessors at 1.400GHz
Compute Capability: 2.1
Number of Blocks: 56
TARGETS
=======
0: "Trip.."
TRIPCODES
=========
STATUS
======
Searching for 1 pattern (1 chunk) with 6 characters.
0.005T tripcodes were generated in 0.005 hours at:
268.81M tripcodes/s (current)
271.02M tripcodes/s (maximum)
265.08M tripcodes/s (average)
On average, it takes 3.0 minutes to find one match at this speed.
あ、どうも〜 いつも有難うございます。
ちょっぴり速くなってるみたいですね。よかったよかった。
> CPU検索ルーチンを実装。Core i7 2600K で1コアあたり
> 16MTrips/sくらいの検索速度(2タゲの場合)。
ttp://toki.2ch.net/test/read.cgi/qa/1299965026/168
ちょっとこれ、うちのと違いすぎる…
どういうこっちゃ。もうちょっと調べてみよう。
うちのPhenomではCPU検索は1タゲ前方一致で11.2M TPSぐらいでした。
ちょっと安心したけど、それでもえらい差だよな…
やっぱCDUAのコードを使いまわすだけじゃスピードでないよなあ。
うーん、これからどうしよう…
【CPU】i7 2600
【OS】Windows 7 SP1 32bit
【バージョン】[cudaTripper12Wiz7 version 0.01 RC012 by iincho]
[Target GPU ID] 0
[CUDA Assigned] blocks:28, threads:7168, resisters:32, constant memory:576
Target 1: ^Trip..
Target 2: ^////////
Total Target Number: about:2
[cudaTripper12Wiz7 version 0.01 RC012 by iincho]
[Current Options] blocks:4, device:0, cpuThreads:1, target:"target.txt", log:"lo
g.txt", optionFile:"option.ini", dumpDateAndHex:off, beep:off, fastMessage:off,
checkCollision:false, keyType:normal
検索開始:
0.0MTrips/s (CPU:0.0M) [Total 0.0009TTrips, 0.000hours, 0Trips hits]
◆Trip..rVV3HX #ﾌuｿﾕ_dｵﾗｱﾁIz 2011/08/20 19:16:07
299.9MTrips/s (CPU:11.3M) [Total 0.0045TTrips, 0.003hours, 1Trips hits]
◆Trip..TyMvSK #(ｼﾊ.ｱmｴﾚﾒLCｽ 2011/08/20 19:16:19
299.9MTrips/s (CPU:11.3M) [Total 0.0052TTrips, 0.003hours, 2Trips hits]
お、こっちのほうがだいぶ速いですね。CPU検索分の11M TPSを差し引いても
ここまで差は出ないはずですが、ブロック数の設定のせいかなあ。
オプションで"-x 4"を指定してやるといいかもしれません。
しかしこうなるとやっぱりランタイムの設定が必要ですねえ。
やはり改変したCUDA SHA-1 TripperのほうがCPU検索を含めても
速度が出ていました。しかしこんなことなら最新版をダウンロードして
おくんだったなあ。
思ったようには速度は上がってくれません。
> Searching for 1 pattern (1 chunk) with 5 characters.
> 0.001T tripcodes were generated in 0.091 hours at:
> 3.94M tripcodes/s (current)
> 4.07M tripcodes/s (maximum)
> 3.98M tripcodes/s (average)
> On average, it takes 3.1 minutes to find one match at this speed.
cudaTripper12Wiz7の11.2M TPSには遠いです。
やっぱSSEとか使わないと高速化は無理かなあ。
アセンブラは大昔にi386のをやったのが最後なのでどうしよう…
ちょっとオンラインでコードを探してみようかな。
SHA-1のならきっとあるはず。
ttp://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1/ とりあえずこれはとっておいて、32bit版のを探そう。
ttp://trac.aircrack-ng.org/svn/trunk/src/sha1-sse2.S ライセンスもPublic Domainだしちょうどいいや。
しかし、これをVisual C++のコードに組み込むのは
一手間かかりそうだな…
Cのコンパイラから直接SSE2の命令を使うことを検討中。
MMX, SSE, and SSE2 Intrinsics
ttp://msdn.microsoft.com/en-us/library/y0dh78ez(v=VS.90).aspx この機能を使って何とかアセンブラを使わずに高速化できないかなあ。
SHA-1のハッシュ値を計算するのに、仕様とかを見るとW[]のサイズが80に
なってるのに、オリジナルのTripperではW[]のサイズがたしか16だったので
不思議だったのですが、ようやくなぞが解けそうです。
> W[t] = ROTL(1, W[(t)-3]^W[(t)-8]^W[(t)-14]^W[(t)-16]);
が、こう
> W[t] = ROTL(2, W[(t)-6]^W[(t)-16]^W[(t)-28]^W[(t)-32]);
なって、こう
> movdqa W_TMP, W_minus_04
> pxor W, W_minus_28 ; W equals W[i-32:i-29] before XOR
; W = W[i-32:i-29] ^ W[i-28:i-25]
> palignr W_TMP, W_minus_08, 8 ; W_TMP = W[i-6:i-3], combined from
; W[i-4:i-1] and W[i-8:i-5] vectors
> pxor W, W_minus_16 ; W = (W[i-32:i-29] ^ W[i-28:i-25]) ^ W[i-16:i-13]
> pxor W, W_TMP ; W = (W[i-32:i-29] ^ W[i-28:i-25] ^ W[i-16:i-13]) ^ W[i-6:i-3])
> movdqa W_TMP, W ; 4 dwords in W are rotated left by 2
> psrld W, 30 ; rotate left by 2 W = (W >> 30) | (W << 2)
> pslld W_TMP, 2
> por W_TMP, W
> movdqa W, W_TMP ; four new W values W[i:i+3] are now calculated
> paddd W_TMP, [K_XMM] ; adding 4 current round's values of K
> movdqa [WK(i)], W_TMP ; storing for downstream GPR instructions to read
なるということらしいんだけど…
SSE2 IntrinsicsによるSHA-1の実装を見つけました。
ttp://www.openwall.com/john/ sse-initrinsics.cにおいしそうなコードがたんまりありました。
ライセンスもPublic Domainなので、これは使えそうです。
> * This software is Copyright © 2010 bartavelle,
> <bartavelle at bandecon.com>, and it is hereby released to
> the general public under the following terms:
> * Redistribution and use in source and binary forms, with or
> without modification, are permitted.
遅くなった？
STATUS
======
Searching for 328 patterns (292 chunks) with 6 to 9 characters.
0.008T tripcodes were generated in 0.012 hours at:
195.67M tripcodes/s (current)
196.33M tripcodes/s (maximum)
193.54M tripcodes/s (average)
On average, it takes 1.8 minutes to find one match at this speed.
No matches were found yet.
うーん、そうするとcudaTripperの新しいバージョンが
だいぶ速くなってたってことなのかなあ。それともGTX 460に
あわせて作ってあるってことなのかしらん。
とりあえず"sm_21"をつけてコンパイルしてみるので、
また次のバージョンでお願いします。たぶん速くなるはずです。
ありがたやありがたや…
"_mm_store_si128"でCPU保護例外が出てしまいます。
どうしてなんだろう… "_mm_storeu_si128"でもだめだったから
アラインメントの問題じゃないだろうし…
-x 4 とか減らしてどうする。
増やそうぜ。ｗ
つか、今見たら16までにしてるけど、明らかに小さすぎるな。
アナライザで見ると、こんな感じだからまだまだ伸びしろはあるんじゃないかな。ｗ
Active Blocks per SM: 5 (Maximum Active Blocks per SM: 8)
Active threads per SM: 640 (Maximum Active threads per SM: 1536)
Potential Occupancy: 0.416667 ( 20 / 48 )
Occupancy limiting factor: Registers
増やしたんですよ。460だと16以上でもいいのかな。もうちょっと増やしときます。
これまだ大分最適化の余地がありますね。
さっさとWindows 7に移行して、Parallel Nsightで真面目に解析してみようかなあ。
しかしこれ、物凄いくせがありますね。Intrinsicsをつかってるから
余計そう見えるのかもしれないけど…
SSE2の使用による速度の増加は3割ぐらいのようで思ったほど伸びてくれません。
謎の速度低下があったりして、とんとんといったところです。たぶんこれ、
全部アセンブラで書かないと速度がでないんだろうけど、ちと荷が重いので
CPU検索の最適化は後回しにして先に進むことにします。
> Searching for 1 pattern (1 chunk) with 5 characters.
> 0.001T tripcodes were generated in 0.062 hours at:
> 6.10M tripcodes/s (current)
> 6.16M tripcodes/s (maximum)
> 6.03M tripcodes/s (average)
> On average, it takes 2.0 minutes to find one match at this speed.
SSE2 Intrinsics使用による速度増加は5割強といったところです。
最初よりはだいぶましですが、cudaTripper12Wiz7の11M TPSに比べると
まだまだですね。
> SSE2なんて化石は投げ捨ててAVX使えば？
どんな環境でもお手軽に使えるプログラムを目指してるので、
とりあえずSSE2で高速化してみます。余裕ができたらぜひAVXも
挑戦してみたいですね。
ネットで拾ってきたSHA-1のSSE2 Intrinsicのコードが原因だと判明。
SSE2なしの元のコードに戻したら一応マルチスレッド化の効果が出ました。
Phenom II X6でこの数字はかなりしょっぱいですが、そこら辺は今後の
最適化しだいです。
----
Searching for 1 pattern (1 chunk) with 5 characters.
0.001T tripcodes were generated in 0.017 hours at:
20.73M tripcodes/s (current)
26.65M tripcodes/s (maximum)
22.34M tripcodes/s (average)
On average, it takes 33.2 seconds to find one match at this speed.
マルチスレッドかすると思わぬところで問題が出てきますねえ。
ともあれ、ようやくそれなりの数字が出てきたのでほっとしました。
あとはこれをCUDAでの検索と組み合わせるだけです。
----
STATUS
======
Searching for 1 pattern (1 chunk) with 5 characters.
0.002T tripcodes were generated in 0.019 hours at:
33.26M tripcodes/s (current)
35.64M tripcodes/s (maximum)
32.03M tripcodes/s (average)
On average, it takes 23.2 seconds to find one match at this speed.
【GPU】GTX 580 (OC: 962/1924/2103)
【CPU】Phenom II X6 1100T 3.30GHz
【OS】Windows XP SP3 32bit
【バージョン】0.03 Beta 1
【オプション】-x 16 -c -g
【Display Driver】270.81
【速度】
876.75M tripcodes/s (current; GPU: 852.1M TPS; CPU: 24.7M TPS)
877.48M tripcodes/s (maximum)
875.63M tripcodes/s (average)
【その他】7完1タゲ、5スレッド
CPU検索スレッドを6つ走らせるとかえって遅くなるので、5つにしぼってます。
OC耐性は落ちましたが、いい感じで前回に比べて20M TPSほどうわのせできて
ます。最適化を進めて、いずれぜひ900M TPSの大台に乗せたいところです。
バージョン0.03 Beta 1をうｐします。CPUだけでもちゃんと
検索できます。
CUDA SHA-1 Tripper MERIKEN's Branch 0.03 Beta 1
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch 変更点は以下の通りです。
・CPU検索に対応。対応するGPUがなくても動作します。GPUとCPUを両方使いたい
場合はオプションで"-c -g"と指定してください。
・"sm_21"をつけてコンパイルしたので、GTX 460では速くなっているはずです。
・"-x"オプションの上限を32まで増やしました。
ぜひお試しください。
失礼しました。
対応の作業に入ります。楽しみすぐる…
ここまで来るのに結構かかりましたが、CPU対応を先に済ませたのは、
これを先に終わらせておけば10桁用のコードを先にCPUで試せるからです。
10桁トリップを生成するコードさえ書いてしまえばすぐに検索できるはず
ですが、果たしてどうなることやら…
乙
-c -g
Number of Available CUDA Devices: 1
Device: 0 ("GeForce GTX 460") with 7 multiprocessors at 1.400GHz
Compute Capability: 2.1
Number of Blocks: 56
CPU
===
Number of Processors: 8
Number of Search Threads: 7
TARGETS
=======
0: "TEST/"
TRIPCODES
=========
◆TEST/9WwqZIa #ｵ幡COBﾀｼjbｙ (b5 94 a6 43 4f 42 c0 bc 6a 62 82 99)
◆TEST/nVAvFAi #７幽ｿxｨ堂oｪｦ (82 56 97 48 bf 78 a8 93 b0 6f aa a6)
◆TEST/WCmWdrG #昧ﾊjﾄﾆC廩俳5 (96 86 ca 6a c4 c6 43 9c 48 94 6f 35)
STATUS
======
Searching for 1 pattern (1 chunk) with 5 characters.
0.004T tripcodes were generated in 0.004 hours at:
287.56M tripcodes/s (current; GPU: 267.7M TPS; CPU: 19.8M TPS)
293.87M tripcodes/s (maximum)
283.76M tripcodes/s (average)
On average, it takes 2.6 seconds to find one match at this speed.
3 matches found at 721.83 matches/h and 1.42G tripcodes/match.
The actual matching probability is 24% lower than expected.
0% of matching tripcodes were invalid.
朝早くから有難うございます。意外にGPUのほうは伸びないですねえ。
"-x 16"とかそれ以上にするといいかもしれません。
思わぬところで時間を取られてえらい目にあいました。ともあれ、
これのおかげでプログラムの構造が大分すっきりしました。
メインのスレッドは他のスレッドがせっせと働いてるのを
のんびりと待って、たまに結果を表示するだけです。
副作用として、将来的に複数のグラボに対応するのも容易になりました。
予算ができたらぜひもう1枚グラボを追加したいところです。
マザボと電源も交換になるのでえらい出費ですが…
正規検索もいいけど、
を参考にGPU検索は cudaTripper12Wiz7 より20%以上高速化。できれば倍ほど高速化。
CPU検索は、少なくとも cudaTripper12Wiz7 よりは高速化。
を、めざしてみてょ(*‘ω‘ *)
楽しみにしています
トリップコードへの変換はうまくいきました。
ttps://aff4.googlecode.com/hg/libreplace/crypt.c 問題はこれからだけど、やっぱりSHA-1よりずいぶん計算量が多そうです。
まあなんとかなるかな…
うはｗ これはハードルが高いｗｗｗ
cudaTripper12Wiz7は良い目標になっているので本当にありがたいです。
10桁トリップ対応の後は、ランタイムでの診断を含めた全体的な最適化に
取り組む予定なので、何とか超えられるように頑張ります。
こりゃ先が長いわ…
bit-sliced DESを使わなきゃ速度でんよ(*‘ω‘ *)
『CUDAによるbit-slicedDESの実装』みたいな論文があるから読んでみれ(*‘ω‘ *)
ttp://www.darkside.com.au/bitslice/ これなら何とかなりそうな感じですね。
この大量にある変数を、なんとかレジスタとシェアードメモリに
押し込めればいいわけだ。光明が見えてきました。ありがとうございます！
【CPU】i7 860
【OS】Windows 7 SP1 32bit
【バージョン】CUDA SHA-1 Tripper MERIKEN's Branch 0.03 Beta 1
-c -g -x 20
STATUS
======
Searching for 1 pattern (1 chunk) with 7 characters.
0.041T tripcodes were generated in 0.039 hours at:
289.51M tripcodes/s (current; GPU: 270.0M TPS; CPU: 19.5M TPS)
296.82M tripcodes/s (maximum)
293.82M tripcodes/s (average)
教えてエロイ人
わざわざ試していただいて助かります。やっぱり速くなってますねえ。
これを見てからまさかと思って自分のPCで試してみたら、"-x 16"よりも
"-x 20"のほうが明らかに速いことが判明。前試してみて"-x 16"が
一番速かった( )はずなんですけど、何が起こったのやらorz
というわけで"-x"オプションの上限を可能なかぎり上げて色々試してみたところ、
GTX 580では"-x 48"が一番速いことがわかりました。間違いかと思ったけど
ヒット率もちゃんと安定してるし、問題はないようです。のお告げが無かったら
勘違いしたままでした。ありがたや、ありがたや。
> readme読んだだけではオプション指定の方法が分りませんorz
>
> 教えてエロイ人
普通に使う分に必要なのは"-x"だけです。"-x 16"とか”-x 32"というふうに、
マルチプロセッサあたりのブロック数を指定します。数字を変えて試してみると
よいようです。
後いろいろ付け足したのですが、まだ暫定的なものなので、次のバージョンをうｐするときに
まとめます。しばしおまちを。
用事があるので、あとで試してみよう。実に楽しみだ…
bitslice DESの概要はわかったのですが、saltの部分だけがどうしてもわからない…
現在UFC-cryptのソースを見ながら思案中です。
----
/*
* This is the only crypt change to DES:
* entries are swapped in the expansion table
* according to the bits set in the salt.
*/
saltbits = 0;
for(i = 0; i < 2; i++) {
long c=ascii_to_bin(s2[i]);
if(c < 0 || c > 63)
c = 0;
for(j = 0; j < 6; j++) {
if((c >> j) & 0x1)
saltbits |= BITMASK(6 * i + j);
}
}
/*
* Permute the sb table values
* to reflect the changed e
* selection table
*/
shuffle_sb(_ufc_sb0, current_saltbits ^ saltbits);
shuffle_sb(_ufc_sb1, current_saltbits ^ saltbits);
shuffle_sb(_ufc_sb2, current_saltbits ^ saltbits);
shuffle_sb(_ufc_sb3, current_saltbits ^ saltbits);
----
----
/*
* Process the elements of the sb table permuting the
* bits swapped in the expansion by the current salt.
*/
static void shuffle_sb(UINT32 *k, UINT32 saltbits)
{ UINT32 j;
UINT32 x;
for(j=4096; j--;) {
x = (k[0] ^ k[1]) & (UINT32)saltbits;
*k++ ^= x;
*k++ ^= x;
}
}
FIPS PUB 46-3, DATA ENCRYPTION STANDARD (DES)
ttp://www.ii.uib.no/~osvik/des/fips46-3.pdf これがうまくいって、変数を全部レジスタとシェアードメモリに
押し込めることができたらかなりスピードでそうだよな…
ちょっと疲れたのでいったん休憩します。
bitslice DESがcryptの実装に使えるのはわかってるんですけど、相当手ごわそうです。
他の実装を探してみたんですけど、見つかったのは"John the Ripper"だけで、これが
かなり複雑で容易に理解できそうにありません。ま、他の部分の最適化を進めながら
のんびりやるしかないか…
わかってない気がする(*‘ω‘ *)…
Bitslice DESのソース( )が一対一で対応しているのはわかったので、
以外に早く謎が解けるかもしれません。要はunsigned longのビット長の
数のケースを同時に処理してやることで効率を稼いでるだけで、
やってることは同じですからね。
Ln = Rn-1
Rn = Ln-1 ^ f(Rn-1,Kn)
上の演算が行われた直後にsaltに基づく値と排他的論理和をとればいいはずです。
上の処理は、25回行われるDESのイテレーション1回につき16回繰り返されるので
結構な回数ですが、コスト的にはそれほどでもないでしょう。
ためしてみることにします。これがうまくいけば、あとはBitslice DESにsaltの処理を
加えるだけです。salt用のテーブルはUFC-cryptのものを流用すればいいはずですが、
はたしてどうなることやら…
(*‘ω‘ *)単芝はやめとこうよ・・・
お気になされるのでしたらこのスレでは使うのはやめておきます。
(*‘ω‘ *)やめといたほうがいいと思うね
いまだに（藁 とか書く人みたいに感じる
(*‘ω‘ *)好きで使うならもちろん勝手だけど
昔草の根BBSとかで「(笑)」とか打ってたのの代わりです。
あんまり気にしないでくださいな。
さて、Bitslice DESを試そうと思ったのですが、なかなか思うように動いてくれません。
unsigned long k[56]の最初のビットに56bitのキーをアンロールして
p[]とc[]はゼロクリアしdeseval()を呼び出してやれば良いと思ったんだけど、ちがうのかな…
SHA-1とは比較にならない難敵ですね。
面白そうだったからほとんど何も考えずに始めたけど、無知とは恐ろしいｗ
今後の予定としては、Bitslice DESに取り組みつつ、既存のルーチンで10桁トリップへの
対応を進めながら同時に最適化もする、ということにしたいと思います。そろそろ
本業が忙しくなってくるけど、このプロジェクトは実に楽しいのでぜひ長く続けたいですね。
自動的に生成されてるから、かなり徹底して最適化がされてますね。
PS3用のcryptのコードもざっと見てみましたけど、s-box circuitsはPerlで
自動生成されています。
Breaking UNIX crypt() on the PlayStation 3
ttp://www.zorinaq.com/talks/breaking-unix-crypt.pdf ttp://www.zorinaq.com/cell-bf/ あと、これまではKwan氏のゲート回路( )が最速とされてたみたいですけど、
ごく最近になって記録が塗り替えられたようです。
17% Smaller DES S-box Circuits Found
ttp://it.slashdot.org/story/11/07/01/1734213/17-Smaller-DES-S-box-Circuits-Found こっちもあとで調べてみよう。
設定されたp[], k[], c[]の組み合わせが正しい場合にnon-zeroを返す
関数だったんですね。「なんでc[]に結果が入らねーんだ！」って
ブチギレてたけど、main.cを見てようやく間違いに気づきましたｗ
resultに代入されてる値を見たときに気づくべきだった…
これを実際にDESで暗号化する関数にかえるためには
resultをいじってる部分をパーミュテーションに変えれば
いいんだな。よし、希望の光が見えてきたぞ。
> salt は DES アルゴリズムに対し、16777216 通りまたは 4096 通り (つまり、24
> ビットまたは 12 ビット) 中の 1 通りという不規則性を導入します (salt の
> ビット i が設定されている場合、DES E-Box 出力中のビット i とビット i+24
> とが交換されます)。
ttp://www.jp.freebsd.org/cgi/mroff.cgi?sect=3&subdir=man&lc=1&cmd=&dir=jpman-7.2.2/man&man=crypt これでようやく最後の謎が解決しました。これならばdeseval()に組み込むのも
容易でしょう。
嘲笑的な語句は専ブラ設定でレス消去対象にしてるので、作者のレスの1/3位が消えてるわ
次のリンク先のDESのtextをビットにばらして引数として渡してやると、
ちゃんとciphertextが得られます。
ttp://www.rsa.com/rsalabs/node.asp?id=2105 後はsaltの処理を加えてこれを25回イテレートしてやればcryptと同等になるはずです。
ここまでまる二日かかりましたが、あともう少しでめどが立ちます。
残りはまた明日やろう。
うーん、単芝なんてしょっちゅう見かけるので特に気にせずに使ってましたけど…
この板は真面目な方が多いんでしょうねえ。やっぱりこのスレで使うのはやめておこう。
乱暴な語句や煽り・荒らしに使われる可能性のあるAAは大体消去対象なので、
このスレだと4割以上のレスが消えてる
ttp://www.asus.co.jp/Graphics_Cards/NVIDIA_Series/ENGTX580_DCII2DIS1536MD5/ ttp://pc.nikkeibp.co.jp/article/news/20110813/1034862/ > まあ、それを指摘したレスもAAと消去対象レスへのレスで引っ掛かって消去されてるんだけどね
> 乱暴な語句や煽り・荒らしに使われる可能性のあるAAは大体消去対象なので、
> このスレだと4割以上のレスが消えてる
なるほどなるほど。今後は気をつけます。
> こっちだ・・すごい値段。
>
>
ttp://pc.nikkeibp.co.jp/article/news/20110813/1034862/ それ、興味があって調べてたんですけど、さすがにその値段では手が
でないですねえ。性能的にはOCした2-way SLIの580と変わらないから、
5万以上割高ですからね。
こちらのほうがもっとわかりやすいですね。
ttp://www.dynamic.net.au/christos/crypt/Password.txt きれいに対応していました。同じページにある"Figure 2. Calculation of f(R, K)"の
左上にあるまるで囲まれた"E"が"E Box"のようです。これであとはごりごりと
コードを書くだけのはず…
どうも思ったように一致してくれません。LとRの値がいっしょになってくれないと
いけないんだけど、おかしいなあ。テストデータではsaltを".."に設定してあるから
挙動はおなじになるはずなんだけど…
libdesのcrypt()もコンパイルしてみました。
ttp://ftp.vim.org/security/coast/libs/libdes/ 関数定義が古いK&Rのスタイルだったので修正が必要でしたが、
大した手間もなくちゃんと動きました。John the Ripperのも
これぐらい簡単に動いてくれればよかったんですけど、
まあ文句を言っても始まりません。早速動作を検証してみよう。
最初は"AA"に設定してたのですが、saltbitsが0x000にならなかったので
ようやく気づいたわけですが…
UCF-cryptのほうが速いという結果に。
…やっぱりこりゃなんとしてもBitslice DESをつかってcrypt()を
実装するしかないですね。
スピードのためだから仕方が無いとは言え、これではアルゴリズムがわかりにくすぎる。
いっそのことcrytographyの教科書を一冊買おうかしらん。
Efficient Password and Key recovery using Graphic Cards
ttp://www.emsec.rub.de/media/crypto/attachments/files/2011/03/DA_Schober.pdf p. 18から始まる"4.1.2. The UNIX crypt Algorithm"に詳しいことが載っています。
こりゃ実装に入る前にもうちょっと色々調べたほうがいいかもしれません。
というか、この人すでにCUDAでBitslice DESの実装をしたみたいなんだけど、
ソースは手に入らないのかな…
Bruce Schneier. Applied Cryptography - Protocols, Algorithms, and Source
Code in C (2nd Ed.). Wiley, 1996.
ttp://www.amazon.com/dp/B000SEHPK6/ しかし便利な世の中になったもんですね。お昼を食べたら早速読んでみよう。
まあこの本は手元においておいてもいいから無駄にはなりませんけど、
それにしても弱ったな… 自分はDESがどのようにcrypt (3)で使われてるか
知りたいだけなのに。ひょっとしたらkeyのエンコーディングを間違えてるのかな。
ちょっと調べてみよう。
高いからまようなあ。これは最後の手段としてとっておこう。
A. Menezes, P. van Oorschot, and S. Vanstone. Handbook of Applied Cryp-
tography. CRC Press, 1996.
ttp://www.amazon.com/dp/0849385237 とりあえずUNIXのオリジナルのソースを見てみよう。
[Cryp] cryptDES C souce from 7th Edition Unix, provided by Henry Spencer
ttp://minnie.tuhs.org/cgi-bin/utree.pl?file=V7, found via ttp://google.com/codesearch/p#118goTAkg2o/usr/src/libc/gen/crypt.c [CryM] Linux Programmer’s Manual, CRYPT(3) man-page
ttp://www.kernel.org/doc/man-pages/online/pages/man3/crypt.3.html [MT79] R. Morris and K. Thompson. Password Security: A Case History. Bell Laboratories, 1979.
これなら大丈夫でしょう。
ttp://google.com/codesearch/p#ZWtxA-fyzBo/UnixArchive/PDP-11/Distributions/research/Henry_Spencer_v7/v7.tar.gz%7C118goTAkg2o/usr/src/libc/gen/crypt.c やっぱさすがに古すぎたか… コードは一番すっきりしてるだけに残念。
しかしこれからどうしようかな。
もう一回引っ張り出していじってたら、今度はなんとちゃんと動いているみたいです。
DES_BS_cmp_all()とDES_BS_cmp_one()に正しい変換結果を渡してやると
ちゃんとTRUEが返ってきます。これはひょっとしたらひょっとするかもしれんぞ…
DES_BS_cmp_all()とDES_BS_cmp_one()で何をやってるのかさっぱりわかりません。
コードも#ifdefの嵐だし、よくこんなのメンテナンスできるよな…
だということが判明。DESの最後のパーミュテーション(inverse initial permutation)を
行わずに、検索するciphertextにinitial permutationをかけて比較してたのには驚きました。
コメントを見ても「変数が全てキャッシュに乗るように
1つの構造体に全部まとめておいたから勝手にばらすんじゃねーぞ」とか、
「最適化されたコードに支障が出るから、構造体のメンバーの順番は入れ替えないように」
とか恐ろしげなことが平気で書かれています。
とにかくJohn the RipperのBitslice DESのコードが自機で確実に動いているという
証拠はつかんだので、続きはあしたやろうっと。一応速度だけ計測してみたら、
UCB-cryptの3倍ぐらい出たのでかなり楽しみです。
・オリジナルのBitslice DESのコードをcrypt (3)に対応させる作業は難航。
・その代わり、John the RipperのBitslice DESのコードを自機で動かすことに成功。
■明日の予定・目標
・John the Ripperの内部データを実際のトリップに変換する。
それではまた。
ttp://kie.nu/c8 cuda_sha1tripper-0.3.0_win32bin.zip -
ttp://kie.nu/c9 需要がどれだけあるのか分からぬが、とりあえず一段落といったところかの。
Windows用のバイナリはCUDA 3.2でのビルドで、動作確認は266.58ドライバのXP環境、
Linuxでのビルド・動作確認はKNOPPIX for CUDA 1.2a9ぐらいじゃから、テストはまあ手抜きじゃな。
それから1.1a7の方ではメモリ転送のタイミングが悪いのか正常に動作せなんだが、
CUDAもドライバもバージョンが古いからの・・・
次はビットマップを使った大量検索も試してみようかの。
【GPU】GTX 460
【CPU】i7 920
【OS】Windows XP SP3 32bit
【バージョン】CUDA SHA-1 Tripper 0.3.0
【オプション】-d 0
【Display Driver】280.26
【速度】
1409284 kTrips in 5.609 sec - 251.254 MTrips/sec
1409285 kTrips in 5.594 sec - 251.928 MTrips/sec
1409284 kTrips in 5.609 sec - 251.254 MTrips/sec
【その他】タゲは Nonotan のみ
CPU間違ってたことに今頃気づいた。ｗｗｗ
ソースはあとのお楽しみでまだ見てませんが、コア数が！
やっぱこうしますよね〜。
プロファイラで見ると
Active Blocks per SM: 8 (Maximum Active Blocks per SM: 8)
Active threads per SM: 1024 (Maximum Active threads per SM: 1536)
てな感じですね。というか、ゲフォはレジスタが厳しい！
お疲れさまです〜 こちらでも動作確認しました。ソースを見ましたけど、
SHA-1の部分を差し替えられたんですね。詳しい報告はまた後でさせて頂きます。
ラデのレジスタの数はブロック単位でとんでもないことになってるみたいですね。
実際1スレッドあたりどれぐらい使えるのか、非常に興味があります。
Bitslice DESの移植するときにはCUDAだとShared Memoryをつかわないと
かなり厳しいことになりそうなので…
それはそうと、さっき初めてComputer Visual Profilerの存在に気づいて
いま動かしてるんですけど、これって物凄い重いですね。結果が実にたのしみです。
でもとにかくJohn the RipperのBitslice DESのコードで
10桁トリップを生成することに成功しました！
∩( ・ω・)∩ばんじゃーい
素のCでかかれてることもあって速度はCPU1スレッドで550K TPSと
まだまだですが、UCB-cryptが330K TPSだったのと比べると差は
歴然としています。Bitslice DESのことを教えていただいて
本当にありがとうございました ＞
さて、これからJohn the Ripperのコードの余分な部分を削りまくって
綺麗なvanilla Cの実装にしてからCUDA Cに移植することにします。
途中でCPU検索に対応させるのがさきですけど…
【CPU】i7 860
【OS】Windows 7 SP１ 32bit
【バージョン】CUDA SHA-1 Tripper 0.3.0
【オプション】-d 0
Device 0: "GeForce GTX 460"
Compute Capability revision number: 2.1
Total amount of global memory: 993 Mbytes
Number of multiprocessors: 7
Number of cores: 336
Clock rate: 1.40 GHz
Use device 0, grid is 84 blocks, 12 blocks/SM (default is 12 blocks/SM)
71 targets found, target_int_num is 5
1409278 kTrips in 5.569 sec - 253.058 MTrips/sec
1409278 kTrips in 5.491 sec - 256.652 MTrips/sec
1409283 kTrips in 5.523 sec - 255.166 MTrips/sec
1409279 kTrips in 5.522 sec - 255.212 MTrips/sec
私も試してみました。調べてみたら、1SMあたりのコア数は
Compute Capabilityが1.xの場合は8、2.0の場合は32、2.1の場合は48の
ようです。これに応じて-xのデフォルトの値を変えてやると
よいかもしれません。私の版では次のバージョンで対応する予定です。
【GPU】GTX 580 (OC: 860/1720/2004)
【CPU】Phenom II X6 1100T 3.30GHz
【OS】Windows XP SP3 32bit
【バージョン】CUDA SHA-1 Tripper 0.3.0
【オプション】なし
【Display Driver】270.81
【速度】
2147476 kTrips in 3.156 sec - 680.442 MTrips/sec
2147479 kTrips in 3.157 sec - 680.228 MTrips/sec
2147472 kTrips in 3.171 sec - 677.223 MTrips/sec
2147471 kTrips in 3.157 sec - 680.225 MTrips/sec
【その他】配布パッケージのtrip.txt
Device 0: "GeForce GTX 580"
Compute Capability revision number: 2.0
Total amount of global memory: 1535 Mbytes
Number of multiprocessors: 16
Number of cores: 512
Clock rate: 1.72 GHz
Use device 0, grid is 128 blocks, 8 blocks/SM (default is 8 blocks/SM)
71 targets found, target_int_num is 5
ttp://ruffnex.oc.to/kenji/xrea/crypt.txt のサンプルを触っていたらPerlのcrypt()と結果が違うことがあって躓いていた。
両者の違いは、saltの2文字に0x21〜0x2Dまでの値(!から-まで)が含まれていた場合に、
サンプルのmain()→saltはそのまま
Perlのcrypt()→saltの該当文字を0x2E（.）に置き換える
ということだった。あーすっきりした。
俺が知っているCで書かれたcrypt()のサンプルはこれだけなので感謝してます。
しかも解説付きですからね。
現状Bitslice DESはまだまだまだ自分の手には負えなさそうなのでまずは
CUDAの勉強も兼ねてこっちの並列化を試みる。
> DESアルゴリズムでは64ビットの鍵をそのまま縮約型転置PC1にいれてましたが
> (結果DESでは8の倍数ビット目が削除されていた)crypt()では1,9,17...ビット目が
> 削除されることになっています。
道理でBitslice DESがそのままでは動かなかったわけだ…
この資料は本当に助かります。正直John the Ripperのコードは余計なものが
つきすぎてるので、できればオリジナルのBitslice DESを使いたいのです。
> Perlのcrypt()→saltの該当文字を0x2E（.）に置き換える
2chのサーバーではsaltの挙動は更に異なっているようです。
こちらの資料が参考になりました。
ttp://raccy.xrea.jp/ruby/trip.html 一緒に頑張りましょう！
やっぱりうごきませんねえ… のコードとじっくり取り組めば
謎は解けるんでしょうけど、今回は動いているJohn the Ripperの
コードで先に進むことにします。
しかしこのコード、今まで見た中で一番汚いんじゃないかというぐらいの
カオスっぷりです。いろんなプラットフォームに対応しつつスピードを
極限まで追求するとこんな感じなんでしょうか。
今動かし始めたところです。510K TPSぐらいしか出てないので
テストするにも時間がかかりますが、まあ仕方が無いです。
さて、どうなるかな…
ありがとうございます！リンク先の表で自分の理解でよかったのだと確信できました。
◆MERIKEN4.kさんはリアルタイムで過程を書き込んでくださるのですごく勉強になります。
一方俺はCUDA学習目的が5割、10桁トリップ走査目的が5割でやっており、
トリップ走査の高速化には全く貢献しえないので申し訳ないですが、進展があれば報告していきたいと思います。
いろいろ特殊な事が多いので、やはりノウハウの共有って大事ですよね。
またぜひいろいろ聞かせてください。
記念すべき10桁トリップ第一号です。
ttp://toki.2ch.net/test/read.cgi/qa/1313015047/837n
ここまで来るのに1ヶ月ちょいか。結構かかったな…
----
TRIPCODES
=========
ProcessPossibleMatch(): tripcode[] = `TEST0GahtM'
ProcessPossibleMatch(): key[] = `ｸJq矼ｰL､Lk'
◆TEST0GahtM #ｸJq矼ｰL､Lk (b8 4a 71 e1 e3 b0 4c a4 4c 6b)
STATUS
======
Searching for 10 patterns (10 chunks) with 5 characters.
0.000T tripcodes were generated in 0.004 hours at:
0.64M tripcodes/s (current)
0.52M tripcodes/s (average)
On average, it takes 2.4 minutes to find one match at this speed.
1 match found at 239.76 matches/h and 0.01G tripcodes/match.
The actual matching probability is 1265% higher than expected.
0% of matching tripcodes were invalid.
してたんですが、実際にちゃんと動いているのを見ると感無量です。
しかしで実際に作業を開始してから4日でようやくCPU検索が
動き始めたわけですから、想像以上の難物です。
最初は「ネットで適当なコードを拾ってくれば1日でGPU検索までできるだろう」
なんて思ってたので見通しが甘すぎですけど…
さて、今日はもうこれぐらいにして続きは明日にしよう。
■今日のまとめ(2011年8月28日)
・10桁トリップのCPU検索がようやく動く。
■明日の予定
・CPUで全位置検索ができるようにする。
・John the Ripper由来のコードのクリーンアップ。
それではまた〜
本格的にコードを綺麗にする前に、万一のことを考えて
トリップの出現確率を計算しているルーチンの修正を行いました。
10桁トリップの最後は情報量が4bitしかないため、次の16文字しか
出現しません。
.26AEIMQUYcgkosw
これに応じて出現確率の計算を修正し、出る可能性のないパターンを
削除するようにしました。これで正確な確率が出るようになったので、
テストをしながら思う存分コードを削れます。
していたのですが、10桁のトリップで同じことをやると
キーの異なっている同じトリップが大量生産されてしまいました。
crypt (3)はキーの各バイトの下位7bitしかみてないので
当然なんですけど、認証の仕組みとしては10桁トリップは
かなりいまいちのようです。まったく知らないで使ってたけど、
無知とは恐ろしい… まあ現実的には問題はないはずなので、
気を取り直して作業の続きに戻ることにします。
----
◆ifSxh4TST6 #ﾊ∀q･q，師 (ca 81 cd 71 a5 71 81 43 8e 74)
◆7TST0f7fAU #ﾋﾎHM蜴ｰｴ痺 (cb ce 48 4d e5 8e b0 b4 e1 83)
◆7TST3KSETA #ｭ掻7ﾀKv2ｩl (ad 91 7e 37 c0 4b 76 32 a9 6c)
◆7TST3KSETA #ｭ掻7ﾀﾋv2ｩl (ad 91 7e 37 c0 cb 76 32 a9 6c)
◆9TST73/Ir6 #M､ﾏ桶pg縲ﾇ (4d a4 cf 89 b1 70 67 e3 80 c7)
◆BL739TST16 #ﾔisｫpr7ｶﾙﾅ (d4 69 73 ab 70 72 37 b6 d9 c5)
◆BL739TST16 #ﾔisｫprｷｶﾙﾅ (d4 69 73 ab 70 72 b7 b6 d9 c5)
◆LL43TST6qM #4ｵd輛ﾀ8ｯ帋 (34 b5 64 e7 70 c0 38 af 9b e1)
◆LL43TST6qM #4ｵd輛ﾀｸｯ帋 (34 b5 64 e7 70 c0 b8 af 9b e1)
◆OhCs0TST8I #磆ﾏbﾛI･悼ﾁ (e1 f5 cf 62 db 49 a5 93 89 c1)
◆OhCs0TST8I #磆ﾏbﾛﾉ･悼ﾁ (e1 f5 cf 62 db c9 a5 93 89 c1)
気分は「汚物は消毒だ〜っ！！（AA略」という感じです。#ifdefにまみれた
4000行あるnonstd.cにはまだ手をつけていませんが、避けては通れません。とほほ…
みたら、単にアーキテクチャ毎にに最適化されたDESのS-Boxがずらずらと
並んでただけでした。使用するレジスタの数や特定のオペランドの
実行回数に応じて非常に細かく場合わけされています。
ここらへんのJohn the Ripperの性能へのこだわりには本当に
関心させられます。絶対にメンテしたくないコードですけど…
今はとりあえず適当なS-Boxの組み合わせを選んでおいて、
あとで手作業で実行時間を測定して、CPUとGPUに最適な組み合わせを
それぞれ調べることにします。
(*‘ω‘ *)つ ttp://toki.2ch.net/test/read.cgi/qa/1299965026/306
>
> (*‘ω‘ *)つ ttp://toki.2ch.net/test/read.cgi/qa/1299965026/306
衝突はほんとにすぐ起きますよね。
> キーはソルト分の2bitは固定
このへんはいまいちわかりませんでしたが…
素のCの実装と関係ない部分を削除して、8つあるS-Boxを8つのインクルードファイルに
追い出したのですが、随分とすっきりとしました。あとは残りの部分をきれいにして、
thread-safeにしてしまったら、GPUのルーチンの実装に取り掛かれます。
もうS-Boxのソースは当分見たくないです(笑)
> みんなどのツール使ってトリップ検索してるの？
VecTripper → Radeon版待て屋。 → CUDA SHA-1 Tripper
という流れでした。いま作っているTripperの改造板は、これらのツールの
良いところをすべて取り込む予定です。VecTripperはMac用なので
使っている人は少ないと思いますけど、機能的にもUIの面でも非常に
洗練されているのでぜひ見習いたいですね。
あれだけごちゃごちゃしてたJohn the RipperのBitslice DESのコードが、
500行ほどの１つにすっきり収まり結構感動しました(笑)
もちろん機種判別用の#ifdefは全て削除しました。
このルーチンはどのCコンパイラでも通るはずなので、
Tripperとは別の形でいずれ単独で公開したいと思います。
オリジナルよりもはるかに効率のよいS-Boxの実装を
手に入れることができたのでかえって良かったのかも知れません。
あとはこれがCUDA Cで動いてくれればいいんだけど…
Phenom II X6で2.71M TPSと笑っちゃうような数字ですが、John the Ripperは
もともとSSE2/AVX Intrinsicsに対応していたので、コードの最適化は比較的容易なはずです。
もともとCPU対応はおまけみたいな扱いなので、最適化は後の楽しみにとっておいて、
いよいよ本命のGPUによる10桁トリップ検索への対応の作業を始めることにします。
どれぐらいスピードが出るか、実に楽しみです。
John the Ripperのコードは本当に効率重視というかんじですけど、
この分岐の嵐ではCUDAでは性能がでないでしょう。
8 S-Boxes * 16 rounds * 25 iterationsだから当然か…
まあ分岐といってもwarp divergenceが発生するわけではないようなので、
とりあえずこのままにしておきます。
これ、GPU検索の前にコードの整理をしないと駄目だな。
共通のルーチンをインクルードファイルに押し込めて、
2つのファイルでインクルードさせて、
プリプロセッサで違いを吸収させることにしました。
Jon the Ripperのコードを見続けた後では全く普通に見えますが、
やりすぎかもしれません。危ない危ない(笑)
なんにせよコードの整理がようやく終わったので、明日こそ
GPU検索を動かせるはずです。楽しみです。
・10桁トリップのCPU検索のマルチスレッド化。
・ファイルの分割等のコードの整理。
■明日の予定
・10桁トリップのGPU検索への対応。
それではまた〜
待て屋じゃ10M/Tすら程遠かったから期待
使ってるグラボがショボイんじゃね？
GPUがRADEONじゃなくてGeForceなんだろ。
SIMDとSIMTでの方向性の違いとかも関係しているのかの。
デフォルト値はCompute Capabilityで変えているつもりじゃったが、上手く動いていないのかや？
それにしてもGTX 580 OCでの速度は予想以上に速いようじゃが、ドライバのバージョンの影響も大きいのかの・・・
わっちは熱中するとBBSでのレスとかそっちのけで、コードを眺めたりのんびり煙管をふかしながら考えをまとめたりになってしまうの w
それは楽しみじゃの。
すぐに見つかるDESベースのcrypt()の実装は初心者向けの解説的なものか、極端に最適化されたもののどちらかという感じじゃったからの。
わっちのほうもビットマップを使った大量検索への対応ももうすぐ完了しそうじゃから、
それが終わればDESベースのcrypt()の勉強も再開しようかの。
正規表現への対応とかはハードルが高い上に、ある程度ならば
外部ツールでターゲットファイルを作るという力技も使えるからの w
>
> SIMDとSIMTでの方向性の違いとかも関係しているのかの。
なるほど〜 Radeonのアーキテクチャのことは何も知らないんですけど、
かなり違うみたいですね φ(..)ﾒﾓﾒﾓ
>
> デフォルト値はCompute Capabilityで変えているつもりじゃったが、上手く動いていないのかや？
> それにしてもGTX 580 OCでの速度は予想以上に速いようじゃが、ドライバのバージョンの影響も大きいのかの・・・
blocks/SMは 8のままでした。また一段落したらソースを追ってみます。
>
> それは楽しみじゃの。
> すぐに見つかるDESベースのcrypt()の実装は初心者向けの解説的なものか、極端に最適化されたもののどちらかという感じじゃったからの。
>
> わっちのほうもビットマップを使った大量検索への対応ももうすぐ完了しそうじゃから、
> それが終わればDESベースのcrypt()の勉強も再開しようかの。
期待してます。またぜひ参考にさせていただきたいです。
mtyは現行ラデにしか対応してませんが？
なるべく応えられるように頑張りますです。
さて、GPU検索への対応ですけど、まだもうちょっと作業が必要なようです。
何も考えずに使う変数を全部シェアードメモリに載せようとしたら
コンパイラに怒られてしまいました。
Bitslice DESで必要な変数はすべてstruct DES_Contextに押し込んでおいたのですが、
なんとサイズが8808バイトになってました。今の実装では1ブロックあたり128個の
スレッドが動いてるのですが、これでは共有メモリのサイズが全然足りません。
共有メモリのサイズはCompute Capabilityが1.xの場合は16K、2.xの場合は48Kと
なっています。スレッドの数をギリギリの32まで減らしてやっても、使える共有メモリの
サイズは1スレッドあたり512バイト、もしくは1536バイトなので、可能な限り
DES_Contextのサイズを減らす必要があります。
>
> mtyは現行ラデにしか対応してませんが？
はCPU版の話なんじゃないでしょうか。
ttp://naniya.sourceforge.jp/ CPU版のソースってGPLで公開されてたんだ…
後で見てみよう。
・中身が毎回同じ配列は、あらかじめ計算しておいてコンスタントメモリに追い出す。
・中身が動的に変化する配列は、ポインタの代わりにunsigned charのインデックスを使う。
・Key Scheduleのインデックスをcrypt (3)実行の前に実際のKeyに展開するのはやめにする。
・unionでstruct DES_Contextのメンバをまとめてやる。
512バイトはなかなか厳しい数字ですが、1536バイトなら十分に達成可能なはずです。
CPU検索のルーチンで動作確認をしつつ、すこしずつ削っていきたいと思います。
> sizeof(DES_Context): 7528
先は長いですが、最初の一歩です。
こまるので一応動作確認だけしてみましたが、ちゃんとトリップの変換はできている
ようです。
ついこの間まで知らなかったんですけど、Compute Capabilityが2.xの場合、CUDAの
コードからprintf()が呼び出せます。デバッグのときに非常に便利です。
0x300 * 4 bytes * 2 = 6144 bytes なのでこれはでかいです。
あとはExpansion Tableのポインタの配列もUINT8のインデックスの配列に変えました。
結果はこんな感じです。
> sizeof(DES_Context): 1088
今日だけで随分はかどったな… 続きはまた明日やることにします。
資料を超適当に集めてきました。
Optimization Techniques for Large Data Structures on CUDA
ttp://www.eecis.udel.edu/~mpellegr/eleg662-09s/li.pdf CUDA Programming Notes
ttp://www.ast.cam.ac.uk/~stg20/cuda/programming/index.html Optimizing CUDA
ttp://mc.stanford.edu/cgi-bin/images/0/0a/M02_4.pdf CUDA Optimization
ttp://www.prace-project.eu/hpc-training/training_pdfs/2653.pdf 本格的に最適化することを考えたらそろそろXPからWindows 7に移行して
Parallel Nsightを導入する必要があるかも… 結構な量の作業に
なるのでとりかかるのは週末になるかも知れません。
・Bitslice DESのGPUでの動作確認。
・Bitslice DESで使われるデータ構造のサイズを1/8に減らす。
■今後の予定
・10桁トリップのGPU検索の試験実装。
・開発環境をWindows 7に移行して、Parallel Nsightを導入。
それではまた〜
あちこちで資料を漁るのもいいけど、マニュアルも読もうぜ。ｗ
printf とかコア数とかVisual Profilerとかの話を見る限り、読んでないだろ。
CUDA C Programming GuideのAppendix F. Compute Capabilitiesとか必読だろ、ｊｋ。
(printfのこともマニュアルを読んで知ったのです)
どうももろにshared memoryのbank conflictがおきてるようなので、
ちょうどAppendix F.を読んでました。
これは確かに知らないと全く性能が出せないですねえ。
BitsliceじゃないほうのDES crypt()での走査をCUDAでやろうと()している者です。
ttp://ruffnex.oc.to/kenji/xrea/crypt.txt のサンプルにある定数（縮約型転置1,2・循環シフト・P/拡大型/初期/最終転置・SBOXの計848バイト)は
__constant__でコンスタントメモリに格納してキャッシュ(8KB)が効いてくれる…はず。
コンスタントメモリ（のキャッシュ）にはSharedMemoryにあるようなバンクコンフリクトの問題は
あるのだろうか。いやないはず。バンクに分かれているという話も聞かないしリードオンリーだし。
余りにも遅かったら調べて報告する予定です。要するにあれからまだほとんど進んでいません。
自分で言うのもアレですが意外すぎる…もっと躓くと思っていたのに。
現状CUDAの中でif文(というかfor文)を使いまくっているので速度が全然出ないというオチを
予想しておりますが。
ここからの課題：
●キー候補としてどの範囲をどのように走査するのか。
→文字コード表 シフトJIS(Shift_JIS)
ttp://charset.7jp.net/sjis.html を参考にしながら設定する予定。
●キー候補の列挙はCUDAでやるかCPUでやるか
→CやPerlで同じようなことをしたときの経験上、トリップ検索のほとんどの
時間はキー→トリップ（要するにcrypt()）で使われているはずなので、とりあえずはCPUにやらせる。
ちなみにこの経験の際、どこかのサンプルのcrypt() by Cを使ったCの検索プログラムよりも
Perlのほうが早かったので心が折れそうになりました。Perlといえどcrypt()はネイティブコードで実装
されているのかcrypt() by Cが教科書的すぎたのかその両方か。
●欲しいトリップの取捨選択をCUDAでやるかCPUでやるか
→前述のcrypt()が所要時間の大半を占める、ということを考えるとこれもCPUでやって
よさそうな気はします。crypt() by CUDAが早すぎてトリップの取捨選択がCPUでは
追いつかない、ということになったらこれもCUDAでやりますかね。
> あれ？キー→トリップの箇所をCUDA化して速度はまだ調べていないけど…正常に結果が出た！？
> 自分で言うのもアレですが意外すぎる…もっと躓くと思っていたのに。
CUDA Cはコードを動かすだけならかなり素直な実装になっているという印象です。
> ちなみにこの経験の際、どこかのサンプルのcrypt() by Cを使ったCの検索プログラムよりも
> Perlのほうが早かったので心が折れそうになりました。Perlといえどcrypt()はネイティブコードで実装
> されているのかcrypt() by Cが教科書的すぎたのかその両方か。
おそらく後者でしょう。Bitsliceでないcrypt (3)のCの実装では、UCB-cryptが性能的に
優秀なようです。
> ●欲しいトリップの取捨選択をCUDAでやるかCPUでやるか
> →前述のcrypt()が所要時間の大半を占める、ということを考えるとこれもCPUでやって
> よさそうな気はします。
取捨選択をすべてCPU側でやると、生成されたトリップをCPU側に渡すために
大量のグローバルメモリへのアクセスが発生して効率がでないんじゃないでしょうか。
Tripperではターゲットの最初の5文字(6x5 = 30 bit)をunsigned intに変換して、
CUDA側で生成されたトリップの最初の5文字と比較することによって
ある程度取捨選択するようになっています。この点についてはHoro氏のやり方は
CUDAのアーキテクチャと非常に親和性の高いものだと考えています。参考までに。
>大量のグローバルメモリへのアクセスが発生して効率がでないんじゃないでしょうか。
マップドメモリ + カーネルの並列実行
これでそこそこマシになった。
ボクの作ってるCUDAトリッパーでは。ｗ
古いゲフォで動かないけど。ｗ
> マップドメモリ + カーネルの並列実行
これはなかなか興味深い話です。
しかしCompute Capabilityが低いと厳しいですよねえ。
10桁トリップの検索ではshared memoryを目一杯使う予定なので、
さすがにCC1.xの縛りではしんどくなってきました。
某所でこんなカキコをした。ｗ
>マップドメモリとカーネル並列実行までやってもCUDA SHA-1 Tripper
>に届かないとかなにそれこわい
悪魔のコードな待て屋と違って、魔改造するのが楽そうだったんだよね。
綺麗でシンプルなCUDA SHA-1 Tripperって。
わっちもRadeonの方はよく知らぬが、GeForceはメモリアクセス等のレイテンシの大きさは
スレッドを切り替えて隠蔽する方針のようじゃから、大量のスレッドが必要になって
かといって闇雲にスレッドを増やせばいいというわけでもないようじゃからの・・・
-xオプションのデフォルト値は1系は2で、2.0が8で、2.1が12じゃから、上手くいっていると思いんす。
とりあえずターゲットIPCとかは無視してコア数だけでの設定じゃがの。
コンスタントメモリへのアクセスはハーフワープ内のスレッドが異なるアドレスにアクセスするときは
逐次実行になって処理が直線的に増えるようじゃから、注意が必要かも知れぬの。
シンプルではあるかも知れぬが、綺麗といえるようなコードかの？ｗ
新しいテンプレートを使ってVisual Studioのソリューションやプロジェクトを作り直したら
ちゃんと2.0向けのCUBINも含んだバイナリを出力するようになってくれて
GTX 460での実行速度が15%程度向上しおった・・・
ビットマップを使った実装も上手くいったみたいで
とりあえず16Mターゲット放り込んでも速度の低下は誤差レベルですんでおるみたいじゃから
あとは最終チェックかの。
レスありがとうございます！
host-device間のメモリアクセスは確かにまずいですね。
unsigned intへのキャストで比較という方法も含めて考えてみます。
マップドメモリというキーワードは昨日初めて知ったというレベルですが
最適化の段階で検討したいと思います。
＞ハーフワープ内のスレッドが異なるアドレスにアクセス
コンスタントメモリ内に区分はなく（キャッシュがありますが）基本的にGPU全体で共有ではないのでしょうか。
異なるスレッドから”同じコンスタントメモリアドレスへの”アクセスは逐次処理になるということでしょうか？
だとすると、今回置くデータは大きくないのでコンスタントメモリ内に複製をいくつか用意して
（キャッシュに収まる範囲で）スレッドによってアクセスする先を分散させるなどで対処可能…
でも、コンスタントメモリ内のどこであろうと異なるスレッドからのアクセスは逐次、ということで
あればこうやって複製を作るのはムダか…
現在はどこまでkernelfunc<<x, y>>のx,yを増やせるのかをテスト中。
NVIDIA_CUDA_C_ProgrammingGuide.pdfの109ページ(p97)に
GTX480＝Multiprocessorは15個、CUDAコアは480個
GTX450＝Multiprocessorは14個、CUDAコアは448個
とある。自分のGTS450はCUDAコア192→Multiprocessorは6個、
つまりkernelfunc<<6, x>>()で呼び出すのがベストかと思いきや、
いくつかテストした中では<<8, x>>がよさそうな感じ。
ちなみにダメなときはモニタが真っ黒になってスリープ→約5秒後に回復。
Windowsからは今回はちゃんと復帰したけど気をつけなさいと怒られる。
正：GTX470＝Multiprocessorは14個、CUDAコアは448個
誤：GTX450＝Multiprocessorは14個、CUDAコアは448個
どんなプログラムになってんのか知らんが、いくらなんでもそんなグリッドサイズじゃ小さすぎるだろ。
綺麗の反対は汚いではない、といいわけをしておいて。ｗ
待て屋を魔改造してて、何回泣きそうになったか。ｗｗｗ
複雑怪奇すぎるよ、あれは。
レスありがとうございます。現状、速度の点でどうかという観点に達していないので、
手直し（特にメモリの使い方）をして速度もわかるようにしてから最適なグリッドサイズに
ついて改めて見直したいと思います。
今のところkernelfunc<<<8,128>>>()のkernelfunc1つあたり32トリップ調べる、
8*128*32=32768が最善なんですよね。フリーズするかしないかという観点では。
32トリップはkernel内でループで回しているだけなのでこれが増えても
メモリ使用量は変わらない（結果も作為的に32ではなく1つしか確保せず)と考えていたの
ですが、これを64に増やすとアウト（5秒間スリープ)です。
仮にkernelにあるループがinline展開のようなことをされているのなら、
ループが長くなると何かの制限を越えてしまうのかもしれません。
それとも実行時エラーなのでスレッドの結果待ちタイムアウトだったりして。
Kernel details: Grid size: [700 1 1], Block size: [1024 1 1]
Register Ratio: 0.875 ( 28672 / 32768 ) [27 registers per thread]
ドライバが腐ってんじゃね？
前のドライバだと、OpenCLでもおかしな値を返してきてたりしてたし。
XP 32bitで280.26って評判よくないみたいだけど、CUDAとOpenCLではサイコー。ｗ
コンスタントメモリに区分は無くGPU全体で共有というのは、あくまでもソフトウェアからみたものであって
ハードウェア的にはSMというかSMの中にあるInstraction Unitによって管理されているように思いんす。
G80やGT200系はよく分からなかったのじゃが、FermiのL1キャッシュはSM内にあって
L2キャッシュは双方向クロスバで全SMからアクセス可能のようじゃが、
キャッシュの一貫性維持の簡略化とかで、やはりSM単位での管理になっておるんじゃないかの。
少なくともハーフワープ内のスレッドはアクセスする先を分散させては逆効果で、
極力同一アドレスにアクセスするようにすべきではないかの。
シンプルイズベスト（キリッ）というか、わっちの場合は複雑にしてしまうと自分でも手に負えなくなるからのｗ
わっちも早く無駄が無く、尚且つメンテしやすい芸術的なコードを書けるようになりたいの・・・
ttp://kie.nu/jG cuda_sha1tripper-0.4.0_win32bin.zip -
ttp://kie.nu/jH ビットマップを利用して大量検索できるようにしてみたのじゃが、
動作環境がGeForce 8シリーズ以降でグラフィックメモリ256MB以上で
推奨環境はGTX 450以上でそれなりの速度のデュアルコア以上という
軽めのゲームなら軽々動きそうなスペックになってしもうたｗ
それからWindows版のバイナリを利用するならGeForceドライバ266.58辺りが必要になるかも知れぬ。
その他にも基本的なスクリプト等が書ける程度の能力、もしくは補助ツールがあるといいかもしれぬのｗ
スクリプトでtarget_huge.txtを生成できるのじゃが、このファイルはダブルクリックしない方がいいの・・・
お疲れさまです〜
ただいま10桁トリップのGPU検索の試験実装と奮闘中なので、
これが終わりしだいダウンロードさせて頂きます。
探っていたんですが、cuda-memcheckを使ってようやく原因がわかりました。
しかしこれ、なんとかなるのかなあ。
----
CUDA_SHA1_Tripper_MERIKEN: CUDA FUNCTION FALL FAILED: unspecified launch failure
(line 774)
========= Invalid __global__ read of size 4
========= at 0x00006fc8 in CUDA_PerformSearching_DES
========= by thread (0,0,0) in block (12,0,0)
========= Address 0x05703011 is misaligned
=========
========= ERROR SUMMARY: 1 error
原因で、その部分を全部書きなおすことで解決しました。
しかし自分の書いたコードじゃないと思わぬところで足をすくわれますね。
Bitslice DESのルーチンがエンバグしてえらい目に遭いましたが、
ようやくちゃんと動くようになりました。
とりあえずローカルメモリだけを使うようにしてシェアードメモリは触っていないので
スピードはまだまだですが、それは今後の最適化次第ということで実に楽しみです。
試しにCompute Visual Profilerを動かしてみました。
(XPでは何故か途中でクラッシュして動きませんでした)
で、気づいたのがOccupancyが最大でも0.167とかなり低いことです。
register per threadが63と高いのが関係してるのかしらん。
ちょっと減らしてみよう。
通読しておきました。やっぱり性能をだそうと思ったら資料を読んで
プロファイラを使わないと無理ですね。PROGRAMMING GUIDEも後で
最初からちゃんと読んでおこう。
"invalid kernel image"というエラーが出てしまいました。
--maxregcountを16と32にしてみたんですが、両方共エラーが出ます。
やはりいろいろとshared memoryに追い出さないと効率は上がらなさそうです。
開発環境の問題なのかなあ。
ttp://forums.nvidia.com/index.php?showtopic=199795 なんということだ orz
Parallel Nsightが使えないとは意味不明ですが、
とりあえずCompute Visual Profilerが動くようになったので
これでしばらく頑張ってみます。
で、レジスタの数を16に減らしたら案の定スピードは落ちてしまいました。
これは相当うまく共有メモリを使ってやらないといけないようです。
途中からいろいろおかしくなるなあ。"unknown error"がCUDAの
関数から帰ってくるなんて初めてだ。実に不思議です。
ドライバの反応が遅すぎたのがいけなかったようです。
Timeout Detection and Recovery of GPUs through WDDM
ttp://msdn.microsoft.com/en-us/windows/hardware/gg487368 ようやく問題なくVisual Profilerが動くようになったので、
心置きなく最適化に集中できます。しかし今回の10桁対応の件では
本当にいろいろあるなあ。とりあえず当面の目標はOccupancyを上げることです。
【GPU】GTX 460
【CPU】i7 920
【OS】Windows XP SP3 32bit
【バージョン】CUDA SHA-1 Tripper 0.4.0
【オプション】-d 0
【Display Driver】280.26
【速度】
1409283 kTrips in 5.110 sec - 275.789 MTrips/sec
1409284 kTrips in 5.046 sec - 279.288 MTrips/sec
1409284 kTrips in 5.063 sec - 278.350 MTrips/sec
【その他】タゲは Nonotan のみ
【GPU】GTX 460
【CPU】i7 920
【OS】Windows XP SP3 32bit
【バージョン】CUDA SHA-1 Tripper 0.4.0
【オプション】-d 0
【Display Driver】280.26
【速度】
1271906 kTrips in 5.407 sec - 235.233 MTrips/sec
1272117 kTrips in 5.297 sec - 240.158 MTrips/sec
1271183 kTrips in 5.250 sec - 242.130 MTrips/sec
【その他】英単語など340249ターゲット
しばらく走らせてみましたが、まったくヒットしません。
Reading target file "target.txt"...
340249 targets found
となってるからちゃんとタゲは読み込んでるみたいですが。
なんだろう？
ああああああ！
私の間違いでした。
ちゃんとヒットしてました。ごめんなさい。
【GPU】GT 430
【CPU】i7 920
【OS】Windows XP SP3 32bit
【バージョン】CUDA SHA-1 Tripper 0.4.0
【オプション】-d 1
【Display Driver】280.26
【速度】
402653 kTrips in 4.891 sec - 82.325 MTrips/sec
402653 kTrips in 4.875 sec - 82.596 MTrips/sec
402652 kTrips in 4.890 sec - 82.342 MTrips/sec
【その他】タゲは Nonotan のみ
> こんな数値でもちゃんと動いてるぜ。てゆか、もう一桁大きくしても大丈夫だし。
> Kernel details: Grid size: [700 1 1], Block size: [1024 1 1]
> Register Ratio: 0.875 ( 28672 / 32768 ) [27 registers per thread]
これ、SHA-1の話ですよね? Bitslice DESだとper threadのレジスタ数が最大の63になって、
なかなかOccupancyが上がらないのです。スレッドの数を増やしたら
性能は2割ほど上がったけどOccupancyが0.10から0.06に下がってしまいました。
ターゲット数を増やした時の速度低下が予想以上に大きいの・・・
ターゲット先頭3文字の文字種が増えるとグローバルメモリへのアクセスが増えるはずじゃが
それが大きく影響しておるのかの。
正規表現のサブセット等への対応も考えたほうがいいのかの・・・
遅くなりましたが、ようやく試すことができました。
に比べてちょっと遅くなってるのはOSを変えてから
OCを切ったままにしてあるからです。
【GPU】GTX 580 (OCなし: 772/1544/2004)
【CPU】Phenom II X6 1100T 3.30GHz
【OS】Windows 7 Ultimate SP1 64bit
【バージョン】CUDA SHA-1 Tripper 0.4.0
【オプション】なし
【Display Driver】270.81
【速度】
2147479 kTrips in 3.354 sec - 640.274 MTrips/sec
2147477 kTrips in 3.370 sec - 637.234 MTrips/sec
2147482 kTrips in 3.354 sec - 640.275 MTrips/sec
2147483 kTrips in 3.369 sec - 637.425 MTrips/sec
【その他】配布パッケージのtrip.txt (5完1タゲ)
Device 0: "GeForce GTX 580"
Compute Capability revision number: 2.0
Total amount of global memory: 1503 Mbytes
Number of multiprocessors: 16
Number of cores: 512
Clock rate: 1.54 GHz
Use device 0, grid is 128 blocks, 8 blocks/SM (default is 8 blocks/SM)
Reading target file "target.txt"...
1 targets found
多ターゲット時の速度低下はある程度は仕方が無いと思います。
英単語のリストだと、付属のtarget_large.txtよりも
target_intの数が増えるのが大きいと思われますです。
【GPU】GTX 580 (OCなし: 772/1544/2004)
【CPU】Phenom II X6 1100T 3.30GHz
【OS】Windows 7 Ultimate SP1 64bit
【バージョン】CUDA SHA-1 Tripper 0.4.0
【オプション】なし
【Display Driver】270.81
【速度】
2044474 kTrips in 3.495 sec - 584.971 MTrips/sec
2044614 kTrips in 3.479 sec - 587.702 MTrips/sec
2044527 kTrips in 3.478 sec - 587.846 MTrips/sec
【その他】英単語のリスト(196962タゲ)
Device 0: "GeForce GTX 580"
Compute Capability revision number: 2.0
Total amount of global memory: 1503 Mbytes
Number of multiprocessors: 16
Number of cores: 512
Clock rate: 1.54 GHz
Use device 0, grid is 128 blocks, 8 blocks/SM (default is 8 blocks/SM)
Reading target file "target.txt"...
196962 targets found
> 正規表現のサブセット等への対応も考えたほうがいいのかの・・・
前方一致だけなら自分の改造版のソースを流用していただければ
すぐにプリプロセッサが出きるはずです。
後方一致や任意の位置での検索をしようとするとプリプロセッサだけでは
きびしくなってきますが…
Visual Profilerで調べた結果、Occupancyが1スレッドあたりのレジスタ数のせいで
低いことがわかったので、CUDA GPU Occupancy Calculatorで調べてみました。
ttp://developer.download.nvidia.com/compute/cuda/CUDA_Occupancy_calculator.xls 結果はこんな感じです。
ttp://www.meriken2ch.com/files/2011-09-05-CUDA-occupancy-current.JPG やはり1スレッドあたりのレジスタ数が邪魔をしてたようで、1SMが同時処理できるブロックの数が4に
なってしまっています。これではOccupancyが上がらないのは当たり前です。
今後の予定としては、共有メモリを1スレッドあたり32 * 4 bytes使って
使用するレジスタの数を半分にすることです。レジスタの数をやみくもに減らしても
スピードが落ちるだけだし、1スレッドに割り当てる共有メモリの量を
増やしても同時処理できるブロックの数が減ってコアが有効利用できないので、
ここらへんがぎりぎりのラインでしょう。下のグラフのようになれば理想的ですが、
はたしてどうなることやら…
ttp://www.meriken2ch.com/files/2011-09-05-CUDA-occupancy-ideal.JPG Threads per Block: 128 → 128
Registers per Thread: 63 → 32
Shared Memory per Block: 0 → 6144
Active Threads per Multiprocessor: 512 → 1024
Active Warps per Multiprocessor: 16 → 32
Occupancy of each Multiprocessor: 33% → 67%
うーん、これは厳しいなあ。できるだけ節約しないと駄目だな、これは。
1スレッドあたりのレジスタ数を20、共有メモリを8 * 4バイトまで削ることができれば
1SMあたり192スレッドまで詰め込んでtheoretical occupancyが100%になるけど、
これは無理そうだしな…
しかし共有メモリが1SMあたり48Kしかないというのはなかなか厳しいです。
もうなるべくローカル変数を減らしてレジスタ数を削るしかないですね。
乙
【GPU】GTX 460
【CPU】i7 860
【OS】Windows 7 SP１ 32bit
【バージョン】CUDA SHA-1 Tripper 0.4.0
【オプション】なし
Device 0: "GeForce GTX 460"
Compute Capability revision number: 2.1
Total amount of global memory: 993 Mbytes
Number of multiprocessors: 7
Number of cores: 336
Clock rate: 1.40 GHz
Use device 0, grid is 84 blocks, 12 blocks/SM (default is 12 blocks/SM)
Reading target file "target.txt"...
1 targets found
1409285 kTrips in 4.929 sec - 285.917 MTrips/sec
1409284 kTrips in 5.055 sec - 278.790 MTrips/sec
1409284 kTrips in 5.023 sec - 280.566 MTrips/sec
速くﾈｴ。
Device 0: "GeForce GTX 460"
Compute Capability revision number: 2.1
Total amount of global memory: 993 Mbytes
Number of multiprocessors: 7
Number of cores: 336
Clock rate: 1.40 GHz
Use device 0, grid is 140 blocks, 20 blocks/SM (default is 12 blocks/SM)
Reading target file "target.txt"...
1 targets found
2348808 kTrips in 8.065 sec - 291.235 MTrips/sec
2348805 kTrips in 8.081 sec - 290.658 MTrips/sec
2348809 kTrips in 8.190 sec - 286.790 MTrips/sec
2348804 kTrips in 8.081 sec - 290.658 MTrips/sec
2348809 kTrips in 8.097 sec - 290.084 MTrips/sec
Reading target file "target.txt"...
1 targets found
4227854 kTrips in 14.368 sec - 294.255 MTrips/sec
4227856 kTrips in 14.383 sec - 293.948 MTrips/sec
4227855 kTrips in 14.430 sec - 292.991 MTrips/sec
4227854 kTrips in 14.352 sec - 294.583 MTrips/sec
目一杯。
この程度で「大きい」という感想になるとは。
一回、億個単位のタゲでも食わせてみますか。ｗ
うにで878264708ターゲットまでは試したことが。ｗｗｗ
ここらへんはCUDAのアーキテクチャの制約の影響をもろに受けてるわけで、
Radeonがどうなっているのか実に気になるところです。
新しい7970のTDPは190WでGTX 580より低いんだよな。ちょっと試してみたいかも…
できればPTXのコードは弄りたくないんですけど、場合によっては
やむを得ないかもしれません。
現在9.02KTrips/sec。ふぅ…
シェアードメモリを全く使っていなかったり
16384Tripsごとに全部CPU-GPU間で全部転送しなおしていたり
ここからどう早くなるのかが楽しみだぜ！
コード公開ありがとうございます！
自分はsha1のほうに取り組む予定は現状ありませんが、
コーディングの参考にしたいと思いダウンロードさせていただきました！
私も随分勉強させて頂きました。
少しずつ速くなってます。Occupancyを33%から少なくとも67%、
できれば100%まであげたいんですけど、なかなか楽はさせてもらえませんね〜
ある模様。やっぱ中間ファイルをちゃんとみないと駄目だな。
この方法でレジスタ数を抑えられるなら万々歳なんだけど…
> PTX is an intermediate language, not the final assembly output.
> Use decuda to verify your assumption.
>
> Consensus here, so far, has been that register reuse is done in
> the final stage of translating the PTX code to native machine
> instructions.
>
> However I have often been able to reduce register usage at
> the PTX level by carefully making selected local variables
> "volatile"- it effects compiler optimization such that
> the compiler puts the value into a register immediately.
> I even do this for constants (e.g. 1.0 or 0.0) that are needed
> more than once. This saves registers because constants usually
> keep getting loaded into registers over and over - even if
> the same constant has been loaded previously. The volatile trick
> is a nice workaround - however I have only tested it with the 1.1
> and 2.0 SDK so far.
ttp://forums.nvidia.com/index.php?showtopic=89573 こりゃ効率悪くなるわけだわ。どうしよっかなあ…
本体側に追い出せないか、現在検討中。
これがなければローカルメモリへのアクセスがかなり減らせる上に、
レジスタ数の削減もできるはず…
やはりタイムアウトが原因でした。
デフォルトだとWindows Vistaや7ではカーネルの活動限界は2秒なんですね…。
↓のページで説明されているようにTdrDelayを設定することで解決（ブラックアウトしない。Windowsからも怒られない）しました。
timeoutリカバリーの有無自体に変更はないならTdrLevelを新規作成する必要はない模様です。
TdrDelayの作成後にOSの再起動は必要でした。
CUDAカーネル実行のタイムアウト - PukiWiki Plus!
ttp://imd.naist.jp/~fujis/cgi-bin/wiki/index.php?CUDA%A5%AB%A1%BC%A5%CD%A5%EB%BC%C2%B9%D4%A4%CE%A5%BF%A5%A4%A5%E0%A5%A2%A5%A6%A5%C8 １．スレッド内のみで使う変数をGlobalからSharedMemoryにした
２．スコープ上流用ができる配列を流用した
などをやっても全然スピードが変わらなく、ブラックアウトも頻発して心が折れかけてました。
が原因がタイムアウトだとわかったのでどんどんぶん回す希望が持てました。
３．GTS450は4-Multiprocessorsであることに気づいた。48*4＝192 CUDA Cores。で書いた
＞GTX480＝Multiprocessorは15個、CUDAコアは480個
＞GTX470＝Multiprocessorは14個、CUDAコアは448個
というのはあくまでGF100（GTX480,470,465）の話で、GF104以降は48CUDAコアで1Multiprocessorに
なる模様。つまりblocks/gridは4がいいのかな。
【レビュー】「GeForce GTX 460」を試す - 新GPUコア"GF104"の基礎性能とオーバークロック性能 (1) 400シリーズに新コア採用の200ドル帯GPU登場 | パソコン | マイコミジャーナル
ttp://journal.mycom.co.jp/articles/2010/07/12/gf104/index.html ＞「GeForce GTX 460」のCUDA Core構成。SM(Streaming Multiprocessor)アレイあたりのCUDA Core数は48基で、
今後の予定：
(i)ブロックあたりのSharedMemoryは16KBまでだよとコンパイラに怒られるけど、
Fermi（GTS450）なら48KBまで使えたはず。コンパイラオプションに目を向けてみる。
(ii)現状Shareする意味のまったくないSharedMemoryの使い方をしているので、
レジスタをうまく使えないかを考えてみる。
今のコードでは1スレッドで必要な一時変数は256Bytes＋768Bytes＋α(カウンタや交換時の変数)。
768Bytes分はShared場合によってはGlobalに置くとしても、256Bytes＋αはレジスタで済ませたい。
1ブロックで使えるレジスタは4Bytes×32768本＝128KBytes。
つまり1スレッド512Bytesなら256スレッドまでまかなえるはずだから共有メモリの上限
のほうが先にくるはず(768*256＝192KBytesは共有メモリに入らない）。
とりあえず9KTrips/secは脱したい…。
でも、鳥屋ならなんとかしそうで怖い。ｗｗｗ
いや、だからマニュアル読もうぜ。ｗ
なんで一次情報元を優先しないんだろう。
あと、「CUDA トレーニング」でググって、Volume 1を読むとか。
> やっぱさ、GTX 580使っても10桁じゃ10Mさえいかないんじゃね？ｗ
> でも、鳥屋ならなんとかしそうで怖い。ｗｗｗ
いや、さすがにうちでは10M TPSは軽く超えてますよｗ
ただ、レジスタ数の問題さえ解決できれば2〜3倍の速度向上ができますけど、
それでも100M TPS出すのはちょっときびしいかもしれませんねえ。
失礼しました、VolumeI_テクニカルトレーニング.pdfに経験則として
ブロックの数＞マルチプロセッサの数
スレッド＝192 or 256が最適
と書かれてますね。アドバイスありがとうございます！
タイムアウトの問題があったのでこれまでは↑のような数で試すと必ず失敗していたので
GTS450だと何かが制限に引っかかっているのか？と考えてしまってました。
1次情報はFermiが出た直後や出る前のものが多くて、Multiprocessorの数なども
製品情報から推定するしかないと。
（と思っていたら動かしていたサンプルにはっきり4 Multiprocessorsと出ていたわけですが）
ようやく環境変数CUDA_PROFILEを1にしました（OSの再起動も必要でした）。
（occupancy=0.083…32スレッドでsharedmemoryがいっぱいいっぱいになるようじゃやむなしか…)
Visual Profilerも使っていきたいと思います。
日本語のWebはとっつきやすくていいんだけど、ベンチマーク主体のサイトより
後藤氏の記事のほうがGPUやCPUのアーキテクチャの話題が主体で役に立つはず。
ttp://pc.watch.impress.co.jp/docs/column/kaigai/index2010.html それからCUDA_C_Programming_Guide.pdfのAppendix Aに
CUDA対応デバイスの一覧があって、Compute CapabilityやSM数、コア数が記載されている。
CC 2.xでは初期設定ではシェアードメモリに48kBでL1キャッシュに16kBの割り当てらしいけど、
コンパイラオプションで、CC 2.x以降限定にしていないとかいう落ちのような。
特にVisual Studioのテンプレートだとデフォルトで「-arch sm_10」と「-arch sm_20」になっているし。
プロジェクトのプロパティ→構成プロパティ→CUDA Build Rule v3.0.14→General
GPU Architecture(1):sm_10 ←sm_20に
GPU Architecture(2):sm_20
GPU Architecture(3):0
【Before】kernelfunc uses too much shared data (0x4050 bytes + 0x10 bytes system, 0x4000 max)
【After】エラー 0！！（BeforeでもVSのコンパイラ的にはエラー0でCUDAのそれだけがエラーメッセージを出していましたが）
…ありがとうございます！
仰るとおりVisualStudio(2008)で作っていてまさにsm_10とsm_20になっていました。
こんなところにオプションがあったのですね、助かりました！
これで経験則的最善といわれる192スレッドはギリギリ(256B*192=48KB)なので届か
ないとはいえそれに近…あれ？192で通りました！RUN…（結果が正しければ）一挙に12KTrips/secに！
3割アップです！（12KT/secとはいえ）3割！ありがとうございます！
アーキテクチャ寄りの話は後藤氏が明るいのですね。
バックナンバーがこうまとめられているとは…ありがとうございます！
アーキテクチャで引っかかったときにまた参照させていただきます。
手元のCUDA_C_Programming_Guide.pdfにはGTX470まで…ですがこれ2010年5月版でした。
CUDA4.0は問題の切り分けがまた増えそうで遠慮していたのですがdocumentだけでも
ダウンロード…したら…書かれてますねちゃんとGTS450も！GTX560Tiまで。
すみません手抜きして新しい情報源をちゃんと見ていなくてお手数をおかけしました。
何から何までアドバイスありがとうございます。
俺の感覚ではGTX460で良くて数十M、100Mいったらすげーな、って感じだたな
>
> 俺の感覚ではGTX460で良くて数十M、100Mいったらすげーな、って感じだたな
GTX 460だと580の半分以下のスピードしか出ないはずなので、
それで100M TPSでたらすごいですよ。でも580なら達成不可能な
数字ではないという印象です。PTXのコードからcubinに変換されるときの
レジスタの割り当ての最適化がかなりいい加減なようなので、
PTXのコードに大幅に手を入れてやればかなりのところまで
いけるはずです。Cのレベルでの最適化が限界まできたら
PTXに手をつける予定です。
同価格帯のラデと比べるとかなり落ちる。（※トリップ検索においては。ｗ）
鳥屋先生の科学力を考慮しなくてもね。ｗｗｗ
100M届くかどうかったら、5770クラスだもんね。
まあとりあえずゲフォで10桁トリップが検索出来るというところに
意味があるんですよｗ これが一段落したら、ラデも是非試して
みたいですね。
160B(Shared)+96B(Shared)の合計256Bにできた…！
これで256B*192スレッド＝ジャスト48KBにぴったり収まる。
ここから圧縮して192Bにできればもうひとつの経験則最善スレッド数である256が実現できるのだけど。
手元のそろばんでは172Bにまでは圧縮できることになっているのでそれを目指します。
圧縮ついでに◆MERIKEN4.kさんがでおっしゃっていた5文字をunsigned intにして
一致判定というのもできるかもしれません。
と書き込もうとしていた数時間後：
圧縮は130B+96B=228Bまでできた。しかしそもそも…
crypt内部変数のunsigned int [64]をSharedMemoryからローカル変数に変えただけで倍速になった！？
occupancyか？→と思ったけれど0.458で変わってないから違う。
ローカル宣言の配列はGlobalに割り当てらるはずだし実際レジスタは30本しか使ってないことに
なっているので、レジスタに行って高速化されたわけでもなさそう。
考えられるとしたら…バンクコンフリクトというのがひどかったということなのかな？
（バンクコンフリクト回避を考慮したコーディングは全くしていないため）
そんなこんなで、SharedMemoryを全てローカル変数に置き換えてthreads/blockを1024にまで上げ、
occupancyも0.66になり、現在のところ170KTrips/secです。
以前Perlで作ったTrip走査が確か80KTrips/sec（旧PCですが）だったので嬉しいです。
これまでアドバイスをくださった◆MERIKEN4.kさん◆wordlist..nnさん◆Horo/.IBXjcgさん464さん
はじめスレのみなさん参考にさせていただいたサイトのみなさんありがとうございました。
もちろんまだまだ終わりではなく、170KT/sは世間一般的には遅すぎですし、
せっかくGPGPUを使うのだから1Mの大台には乗りたいのでさらに修正を続けます。
要因はkey→salt→ある行列E(48Bytes)を計算するところをカーネルの外に出したこと。
salt（つまりkey[1]とkey[2])を固定しても十分すぎるほど走査すべき範囲はあるので
CPU側で計算してカーネル実行の直前にConstantMemoryに入れるようにした。
これに伴って必要な内部変数も48Bytes減った。効果は速度にして約15％の向上。
【1MTrips/sec到達に向けての今後の予定】
(1) ヒットの成否判断をunsigned intで行って高速化を図る。 …＋5％
(2) スレッド毎の使用レジスタは現在28本。occupancy0.66を引き上げる。 …＋10％
(3) 今後一週間以内に突如すばらしい高速化のアイデアがひらめく …＋15％
(4) だが何も思いつかない。現実は非情である。 …−15％
(5) おおっとそこにはGTS450を捨てGTX595を購入するの姿が！？ …＋300％
【雑文】
8バイトを1つのまとまりとして扱いたくてdoubleへのポインタから値戻ししたり
64ビットprojだからと考えポインタを使ってみようとしたけど
「incorrect register class for result 0」や「unaligned memory access not supported」
とCUDAコンパイラに怒られてしまった…。しかもSharedMemory容量越えのときとは違って
VisualStudioにもやーい怒られてやんのーと言われる（「ツールはエラー コードを返しました」）。
単なるコピーならコンパイラがうまくやってくれると信じて素直に代入文を書くことにする。
uint4 なら使ってたなぁ。SHA-1だけど。ｗ
自分の実装でもsaltの処理はCPUでやらせるようにして、若干速度が上がりました。
あと、(1)の処理をCUDA側でやるだけで1M TPSは簡単に超えられるはずですよ。
キャッシュが効かないと、グローバルメモリへのアクセスはものすごく遅くなりますからね。
1タゲなら書き出しの量が1/(64^5)に減るので決定的です。
レスありがとうございます。が、おそらくそのような高度な話ではないです。
単にカーネルに8バイトの情報を引数として与える際に、
(1) GlobalMemoryへのアドレスを渡すか
cudaMalloc(&d_pointer,8);
cudaMemcpy(d_pointer, "abcdefgh", 8, cudaMemcpyHostToDevice);
kernelfunc<<<32,1024>>>(d_pointer);
(2) int32*2つにして値渡しするか
int h_iarray[2];
memcpy(h_iarray,"abcdefgh",8);
kernelfunc<<<32,1024>>>(h_iarray[0], h_iarray[1]);
(3) 64bitprojでビルドしてるからポインタで渡せば引数1つでオーバーヘッドが少なそう？
int *x_pointer;
memcpy(&x_pointer,"abcdefgh",8);
kernelfunc<<<32,1024>>>(x_pointer);
(4) いや(2)の方法でdoubleを使えば1つで8バイトを値渡しできるからオーバーヘッドが少な…
と試した結果、(3)と(4)はコンパイルが通らなかったという話でした。
(3)が不可の理由はカーネル呼び出し時にデバイス側で32ビットアドレスに変換されていたり
するのかなと（レジスタは32bitですし）、cudaMalloc()を通してないアドレスはコンパイル時に
はじかれるのかなと勝手に推測しています。(4)はよくわかりません。
uint2＝16bit、uint4＝32bitのtypedefでしょうか。Vector Typeといわれて
連想するのはSTLのvector→CUDAなら4.0からのthrustくらいしか思い浮かびません。
折角レスをいただいておきながら申し訳ないのですが、↑の件のオーバーヘッドは（仮にあるとしても）
1％にも満たないと思うので深追いすることは今のところ考えていなかったりするのです…。
レスありがとうございます！ところが…
CUDA側での判定自体（ただし文字単位）は12KTripsか遅くとも209KTripsの時点で既に処方済み
だったので、あまり速度UPの余地はないかもしれません…。
【12KTrips〜209KTrips/secの時点】
(1) カーネル内で6bit*10+4bitの情報→先頭5文字のunsigned charへ変換
(2) カーネル内で所望の文字列との比較
【さきほど(依然として209KTrips/sec)】
(1) CPUで所望の文字列→32bit整数に(逆)変換 →ConstantMemoryへ
(2) カーネル内で6bit*10+4bitの情報と32bit整数との比較
以下、さんの書き込みを見る前に書いていた(475に付けると改行オーバーでNGになった)文です。
【現状】
unsigned intで先頭4文字+2bitの判定をするようにした。所望のTrip文字列→bit列をCPU側で
最初に逆算し、カーネル内ではint32同士の判定しかしていないから計算量は確実に減っている
はずだけれど効果は1％くらい(?)。見落としていることがないか確認する。
ないとは思ってたのですが、0になっていることしかなくてひょっとして楽できる…？と思っていたので危なかったです。
ではおはようございます＆おやすみなさいです。 進展があったらまた書き込ませていただきます。
横槍ですけど、Vector TypeのことはProgramming Guideに載ってますよ。
自分はまだ試してないですけど… unsigned intを使うより効率がいいなら
Bitslice DES の実装に直接応用できるのであとで試してみたいと思います。
うーん、それは変ですねえ。とにかく最適化で一番気を使うのは
分岐の処理とグローバルメモリへのアクセスですからねえ。
コードを公開されるのでしたらぜひ見せていただきたいです。
使ってレジスタ数を63から32まで減らすことを目標にしました。
nvccはこれでもかというぐらいレジスタを使っているので、
C言語での書き方を工夫してレジスタの割り当てを減らしたいところです。
個人的には終わりがみえている10桁トリップのツールを作ってどうするの？って思うが
他人の趣味だからどうでもいいか(*‘ω‘*)
純粋な遊びに実用性を求めるのは野暮というものですよｗ
楽しければそれでいいのです。
John the Ripperの実装についてきたS-Boxには幾つか種類があって
選べるようになっているのですが、全部試す時間はないのでレジスタの
使用数が一番小さいものを選ぶことにしました。とりあえず試してみたら、
なにもしていないのに前より少しだけ速くなっています。やはりレジスタの割り当て方の
まずさが相当足を引っ張っていると思われます。
John the Rippperのコメントによればレジスタ数は14〜19個で済むはずですが、
アホの子のnvccは何も考えずに60〜80個レジスタを割り当ててくれています。
やはり相当最適化の余地があるみたいです。
オプションとかifdefでいろいろ試せるようにしておくとと楽しいぞ。ｗ
おれおれCUDAトリッパーはこんな感じにしてる。
#ifdef USE_CONST_MEM
status = cudaMemcpyToSymbol( keyWc, keyW, keyWSize, 0, cudaMemcpyHostToDevice );
CHECKSTATUS( "cudaMemcpyToSymbol( keyW )", status );
tube1Sha1<<<option.gridSize, option.blockSize>>>( hashAd );
status = cudaGetLastError();
CHECKSTATUS( "kernel", status );
#else /* USE_CONST_MEM */
if ( ! option.useMap[device] ) {
status = cudaMemcpy( keyWd, keyW, keyWSize, cudaMemcpyHostToDevice );
CHECKSTATUS( "cudaMemcpy( keyW )", status );
}
tube1Sha1<<<option.gridSize, option.blockSize>>>( keyWd, hashAd );
status = cudaGetLastError();
CHECKSTATUS( "kernel", status );
#endif /* not USE_CONST_MEM */
コンスタントメモリに変数を追い出せるとかなりおいしいですよね。
自分の実装では速度低下はほとんど見られませんでした。
ましたけど、なかなか意味不明です。これ
> x55550000 = a1 & ~a6;
が、これ
> mov.s32 %r21, %r2;
> mov.s32 %r22, %r10;
> not.b32 %r23, %r22;
> and.b32 %r24, %r21, %r23;
> mov.s32 %r25, %r24;
になるのだからよくわかりません。というか、これってCの構文木を
トレースして出力してるだけなんじゃ… これでは全くお話にならないので、
次のドキュメントを読んでインラインアセンブラを使うことにします。
Using_Inline_PTX_Assembly_In_CUDA.pdf
ptx_isa_2.3.pdf
S-Box内で使われている一時変数の数をぎりぎりまで限界まで減らすことにしました。
この手の最適化はどう考えてもコンパイラの仕事ですけど、まあ仕方がありません。
エンバクにだけ気をつけてせっせと削っていきます。
またまた申し訳ないです…programming guideのpdfにもろに載ってますね。
◆wordlist..nnさんも◆MERIKEN4.kさんもどうしてそんなに親切なんですか…ありがとうございます！
昨晩の俺はCUDA vector type uint2でググっただけでしたorz
現在昨日から何も進んではいません。
公開は問題ないです、コメントをいただけるならぜひとも見ていただきたいです。
ただ貧乏性のため古いコードがコメントアウトで残りまくっているので…時間を頂戴したいです。
コメントアウトや#ifdefを削るとカーネル部分だけなら140行(4000Bytes)
削る前は本体2200行（カーネル600行）、ヘッダー300行。
今から…26時間以内にはどこかに載せたいと思います。
ベンダーのサンプルプログラムを読む。
これは基本で必須だと思うんだが、やらないやつのほうが多いのか？
砂上に楼閣を築くのはおすすめできないな。ｗ
あとは先人の知恵をパク、じゃなかったｗ、参考にする、と。
CUDA SHA-1 Tripperは大変いい。SHA-1だけど。
待て屋は参考にはならん。ｗビットスライスだけど。
うとりっぱーはもうダウンロードできないんだっけ？UFC-cryptだけど。
DES自体はググればいろいろ出てくるよな。
Phil Karn先生とかEric Young先生とか定番か。
SASS見てみましたけど、予想通りS-Boxのあたりでレジスタを大量に消費してました。
30以上使ってたので、実際に必要な数よりかなり多いですね。
cubinとPTXのコードが違うというのはもちろん理解してますけど、
実際の挙動はPTXのコードとプロファイリングの結果からある程度予測できるという印象です。
自分の調べた限りでは、現在のBitslice DESの最小ゲート数の実装は、John the Ripperで
使われているRoman Rusakov氏のものでした。のSlashdotの記事で紹介されてますけど、
Kahn氏のオリジナルより17%ゲート数が少ないとのことです。
まあ、そのゲート数減らしたやつが
ttp://yy43.60.kg/test/read.cgi/tripageruo/1236341912/223 だったりする。ｗ
なにも考えずにまんま持ってきた。ｗｗｗ
新待て屋もそれを採用してさらにいろいろと魔術を駆使してる、らしい。ｗ
いつリリースされんのかしらんが。
ttp://www.darkside.com.au/bitslice/ そりゃやっぱりゲート数が少ないほうを使いますよねｗ
正直これだけゲート数が減らせたというのは驚きです。
新待て屋というのはラデ版のことですか? それは実に興味深いですね…
よく分からないけど、変数を宣言したらその分だけしっかりレジスタ使ってくれるとか・・・？
確かゲート毎に新しく変数を用意して代入しているんだよね・・・。
見るにはどこかで登録必須？
でもSSE2とかの命令セットとかってCUDAやATI Streamで使えるの？
> よく分からないけど、変数を宣言したらその分だけしっかりレジスタ使ってくれるとか・・・？
PTXのレベルでは演算子ごとにレジスタを割り当ててます。
一応cubinに変換される段階で最適化されるはずなんですけど、あまり当てにならないみたいです。
> 確かゲート毎に新しく変数を用意して代入しているんだよね・・・。
そうです、そうです。なので、使い回せば結構変数の数は簡単に減らせるんですよね。
今まで多少オーバーラップのあった10桁と12桁のコードを
完全に分けてしまいました。これで思う存分最適化に
集中できます。
しかし10桁GPU検索の最適化は相当な長丁場になりそうなので、
その前にコードを公開するか迷うところです。S-Boxの最適化が
一段落した段階で考えるか…
サッパリ分からないんですけど、MERIKEN4.kさんて何をされてる方なんですか？
あと失礼ですが、お歳はおいくつくらいの方なんでしょうか。
当然、どっちも、だ。(CPU版とGPU版）
ソースコードならちゃんとあるべき場所に置いてあるぞ。
GPL遵守してる俺様カコイイ。ｗｗｗ
ttp://sourceforge.jp/projects/naniya/svn/view/branches/mty-makai/?root=naniya GPU版はここにはないが。
ちょっと Radeon HD 7990 予約してくる。
ここでやってることは本業とは全く関係ない完全な趣味です。
自分のことは自分のウェブサイトに書いておいたので
探してみてくださいな。もともと別の板でつかってたコテハンなので、
内容もそれなりですけど…
(`・ ω・´)な感じの人なんですねｗ
元気なときはそんな感じですねｗ 最近は(≡ω≡)こんな時のほうが多いですけど…
さて、試しに数日ぶりに10桁トリップのCPU検索ルーチンを動かしたら
エンバグしてる模様。GPU検索とコードを一部共通にしていたのが
まずかったみたいです。Bitslice DESがちゃんと動いているのは確認したので、
また明日にでもバグ取りすることにします。
よければお時間のあるときに見ていただけると嬉しいです、よろしくおねがいします。
ttp://ll.la/0wG@ （公開期限2011-09-14(水) 03:02:59）
現在私のGTS450では233KTrips/secとなっております。
からなぜ向上したのかは不明です
（候補：ビット比較がやはり効いていた・速度計算を間違えていた）。
カーネル内の32回ループで複数ヒットした場合（可能性はものすごく小さいですが）、
最後のヒットの情報だけが残ります。
高々グローバルメモリの8Bytes×32768＝256KBが8MBになるだけなので全部保存してもいいかもしれませんが…。
あるいはAtomicAdd()で速度低下がたいしたことなければ、保存場所を管理するのもアリかなと思っています。
が、今はグローバルメモリ節約よりは速度UPを優先して取り組みます。
実行したときによって9秒になったり10秒になったりするのですが、
秒オーダーでしか時刻を取っていないせいでこんなことになってしましました。
cuda_profileでは現在gputime=[ 4385544.000 ]です（2回カーネルを呼んでいるのでこの2倍＋α）。
今後コードの変更が速度に与える影響を計る際はちゃんとprofileのgputimeを見るようにします。
ttp://ll.la/*7RV （公開期限2011-09-15(木) 03:51:58）
心臓に悪いですねえ。でもこれでようやく安心してS-Boxの最適化に入れます。
ありがとうございます！
Bitslice DESの進行を遅らせることは本意ではないので、のS-Boxの最適化など
を優先していただいてこっちは今後気が向いたときで結構です。
走査するkeyの範囲をみて問題発見（自己解決）：
カーネル呼び出しの中では変化しないはずのsalt(unsigned char key[8]ならkey[1]とkey[2])の
うちkey[2]を変化させてしまっている。
一応、ShiftJISの上位8bitの候補はどれも0x7B以上であるため、ここを候補32パターンの
範囲内でどのように変化させてもsaltの計算時には'.'(==0x2E）で計算されるため問題は生じないが…。
今後の拡張時にこの点に気をつけないと誤ったsaltが使われてしまう。検索速度に影響する話ではない。
まあプログラミング自体息抜きなので、のんびりやらせていただきますｗ
S-Boxの最適化の方は、インラインアセンブラの使い方がわかったので
あとはせっせと手作業でゲートを変換してやるだけです。
PTXのマニュアルの予約語の部分を見てみたのじゃが、
CUDAがネイティブに対応している論理演算は標準的なもの以外はどれぐらいあるのかの？
対応していない論理演算を利用したS-boxを下手に使うと、逆にゲート数が増えかねないしの。
sboxes-s.cにあるAltiVecのvselを利用したものかの？
vselやそれに相当する命令がネイティブに実装されていないケースではどうなるのか気になるの。
まあわっちはS-boxの最適化どころか、CUDAでの実装テストもまだで
Kwan氏のサンプルコードの大部分を何とか理解した程度じゃがｗ
S-boxやCUDAに関係の無い部分だけでも、
最適化しようとすると凄まじいことになりそうじゃの・・・
自分が使っているS-Boxの実装はJohn the Ripperのnonstd.cにある
MMX/SSE2/AVX/RISCアーキテクチャ用のもので、ゲートの種類はand、or、xor、not、andnの
5つだけです。John the Ripperにしてはｗ素直な実装です。andnに対応するPTXの命令はないので
and.b32とnot.b32にばらしています。
やっぱりレジスタ数を32まで減らすにはS-Box以外の部分にも手を付けざるをえないでしょうね〜
最適化の前にできる限りシンプルにしておくつもりです。
【以下、現状と今後の予定】
カーネルと同じ動きをするホスト関数を作って実行し、2〜3KTrips/secという結果を得る。
1年前と同じくまたもPerlに対する敗北感を感じる。
不要な計算を削ったりもしてるのに…部分もメモリ消費をケチってbitで格納しているのがまずいのか。
キー64bit→block64bit(実質56bit)→KSbit[24](KS[16][48]を32bit*24で格納したもの)のうち
block→KSbitに法則らしきものをみつけ、（この部分の）計算量が半分くらいになりそうだと
いう希望をもつ。メモリ消費も現在余裕のあるConstantMemoryの増加だけで済みそうだ。
Best Practice Guideの4.0を読み始める。
ようやくのConstantMemoryへのアクセスが逐次実行になる(serialize)という意味を理解する。
それと自動変数のまずさ(ローカルメモリに格納)を理解する。
C Programming Guideの4.0を読み始める。
ビットシフトがaddやlogical operationに比べ3倍かかることに気づく。
ただ現在思い当たる実施可能な修正点は、一致判定をシフトではなくANDのマスクで、くらいしかない。
ようやくCUDA_Occupancy_Calculator.xlsの使い方がなんとなくわかってくる。
そして経験則としてThread/Blocksは192か256が良いという意味も把握する。
192か384にするとoccupancyが0.75になることに気づく。実際0.75になった。
192にして使用レジスタを24にまで軽量化できれば0.88になるらしい。現在26なので不可能ではなさそう。
直前に読んだBest Practice Guideには50％以上からのoccupancyアップは即性能向上を
意味するものではないよとあったはずなのであまり期待しすぎないようにトライしてみる。
occupancyは0.75から0.875へ。gputimeにして3％改善されました(253KTrips/sec)。
速い実装が欲しいならUFC-cryptを勧めます。うちのPhenom II X6ではなにもしないで
1コアで300K crypt/sでてましたよ。素のBitslice DESが500K crypt/sぐらいだったので、
UFC-cryptも十分速いです。
理屈がわかればあとは機械作業なんだけど、これをあと7回繰り返さなきゃならんのか orz
まあ最初の書き換えがすんなり終わっただけでも僥倖なので、さっさと残りも
片付けることにします。今週中に終わればいいけど、どうなるかなあ…
変数名が凄いことになっておるのじゃが、実装自体は素直なのかの？ｗ
あれをandnをandとnotの2つのゲートでの実装に変えると、ゲート数としてはKwan氏の物と比べて5%程度減るのかの？
スレッドあたりのレジスタ数やシェアードメモリの容量はかなり厳しいの・・・
KSは一度に作らずにラウンドごとに作ればメモリ消費量は簡単に抑えられないかの？
計算量を減らすのは展開してハードコードという力技かの。
しかしビットシフトが加減算や論理演算の3倍のコストというのは予想外じゃの・・・
UFC-cryptは280KBのテーブルが必要みたいじゃからCUDAには向かないと思いんす。
単一saltを繰り返し利用した場合に大幅な速度アップということは、キャッシュを利用した高速化かの。
しかし素のBitslice DESの6割程度ということは、やはり非並列計算では圧倒的な速度なのかの。
お疲れ様じゃの。
使用レジスタ数の削減はかなり期待していいのかの？
アドバイスありがとうございます。ラウンドごとに作るというのは
KS[16][48]を（実際は32bit*24で格納）16回のループの中で1つだけ求めるということ
だと思いますが、この16回ループの外にDESの25回ループ(カウンタm)があるため、
mでKS[]は変化しないので計算量が今に比べて25倍になってしまいそうです。
現状KS[]はレジスタを使用しているわけではない（スレッドあたりレジスタ消費MAXが23）のですが、
192スレッド/blockの場合1スレッドに割けるSharedMemoryが36バイトで全然足りないので、
KS[]へのメモリアクセスが足を引っ張っているなら25倍の計算量になっても
毎回計算してSharedMemoryに納めたほうがいいかもしれません、考えて見ます。
計算量を減らす案は展開ではなく、KS[16][48]を24行×(16bit+16bit)と考えた場合に
16bitまたは32bitがキーからのシフト演算の組み合わせで計算できそう、というものです。
アクセスは列方向になるので参照時に不利かもしれませんが。
というか今既にそういう格納をしているのでここが足かせになっているかもしれません…。
それとでダウンロードさせていただいたcuda_sha1tripper-0.4.0.zipについて
よければ教えていただきたいのですが、cuda_sha1tripper.cuの170行で
＞ b64t[threadIdx.x] = b64t_d[threadIdx.x];
とConstantMemoryからSharedMemoryへコピーし、以降はSharedMemoryのb64t[]を参照
しているのは、ConstantMemoryよりSharedMemoryのほうが早いからなのでしょうか。
私の理解では、
１．8KBのキャッシュに収まる限り速度はConstantMemory≒SharedMemory
（長い逐次処理になると＜、バンクコンフリクトがあると＞ などに左右されるものの)
２．b64tの使われ方をみるとバンクコンフリクトを完全回避できるわけではない（aの値によるランダムアクセス）
３．b64tはリードオンリー
であるためConstantMemoryを使いそうになるので、考えが至っていないところをご指摘いただけるとありがたいです。
失礼しました、の
＞計算量を減らす案は展開ではなく、
は間違いでやっぱり展開でした。
LibreOfficeのcalcとにらめっこしたりペタペタコピペして見通しをよくしようとしてたのに、
コーディングに入るために変換表を最初から見直ししてたら…計算規則が一目瞭然の簡単すぎでﾜﾛﾀ…数時間の苦労が…
CUDAによる bit-sliced DESの実装に関する論文があるのに何で読まないん(*‘ω‘ *)？
俺は読んでねーけど、全国大会のA4ピラじゃなくてフルペーパーくさかったぞ(*‘ω‘ *)？
ためになるんじゃねーの(*‘ω‘ *)？
前()にもちょっと書きましたけど、次の論文にはざっと目を通してます。
Efficient Password and Key recovery using Graphic Cards
ttp://www.emsec.rub.de/media/crypto/attachments/files/2011/03/DA_Schober.pdf Record Setting Software Implementation of DES Using CUDA
ttp://home.dei.polimi.it/barenghi/files/ITNG2010.pdf 特にSchoberの学位論文はかなり詳しくbitslice DESのCUDAでの実装を解説しています。
ただ、報告されている速度はトリップ検索に換算するとGTX 260で
13M TPS前後なので、参考になるかといわれるとなかなか微妙なところです。
> 12,9 M PW/s BEST RESULT (ZeroCopy Alternative): 8 char PW characterset
> generated, Build conguration: 121 registers, 4672 bytes lmem,
> 32+16 bytes smem, 304 bytes cmem. Execution conguration: 4096 blocks
> 128 threads
(Schober, 2010, p. 116)
言われてみればcryptの25回のDESループ内ではKSは変化しないのじゃったの。
やはり展開してハードコードが一番の気がするの。
行数が凄まじいことになるがのｗ
コンスタントメモリからシェアードメモリにコピーして、それを使うようにしたのは
>514にもあるように、ハーフワープ内のスレッドがアクセスするコンスタントメモリのアドレスが異なると
逐次実行になるからじゃが、見直してみるとハーフワープ内の全スレッドが同一アドレスにアクセスする部分も結構あるの・・・
酷いバンクコンフリクトを起こしていそうな部分もあるから、書き直さねばならぬの。
JtRの実装が素直なのはS-Boxの中身だけで、あとはかなりすごいことになってますねｗ
UFC-cryptがそれだけメモリを使っているなら、ちょっとCUDAでは厳しいですねえ。
レジスタ数の削減は予定ではうまくいくはずｗですけど、実際にどうなるかは後のお楽しみです。
んなもんホンキでやるやついないだろうし。ｗ
ttp://kie.nu/w9 cuda_sha1tripper-0.4.1_win32bin.zip -
ttp://kie.nu/wa とりあえず問題のテーブルを、コンスタントメモリ上のとシェアードメモリ上のとで
使い分けるようにしてみたのじゃが、速度は誤差程度しか変わっておらぬ。
他の部分の処理やオーバーヘッドの方が圧倒的に大きいからかの。
あのS-boxの変数は自動生成したコードそのままなのかのｗ
DESはそれを基にしたものはあちこちで使われておるから、
研究している所もそれなりにありそうじゃがの。
DESベースのcrypt()の方は流石にもう重要な用途ではほとんど使われておらぬと思うがのｗ
あちこち！？
IPsecぐらいしか浮かばない。ｗ
何年も前に死亡宣告されたDESをCUDAでなんて需要ないっしょ。
SHA-1は（実装が）手軽だからよく使われるよね、総当たりの実験とかに。（ぇ
Ivanタン、ﾊｧﾊｧ
> あのS-boxの変数は自動生成したコードそのままなのかのｗ
変数名とか見る限り、まったくそのままなんでしょうねえｗ
Kwan氏は自分の作ったゲート作成用のプログラムを公開してるみたいですけど、
JtRのほうも気になります。
展開してハードコードすればシェアードメモリの容量の問題は回避できそうじゃが、
やはり6ビットを使ってテーブル参照で4ビットの値を得るというあたりが厄介じゃの。
これから使うことはないかも知れぬが、
昔作成されてDES系で暗号化されているものとかもあるのではないかの。
レス遅くなってすみませんそしてありがとうございます。
Michael GladさんによるUFC-Cryptという高速な実装があるのですね。
cryptをどのように高速化しているのか興味深いのでみつかったら(理解できれば)読んでみたいと思います。
シングルスレッドで300K crypt/sというのはすごいですねそして少しショックです…。
マシン性能差とトリップ判定のことを考えるとPerlのcryptはUFC-cryptで実装されているのかな
…と思いきやCrypt::Passwdというモジュールがあるくらいだからそうではなさそう。
, 527
ご回答ありがとうございます。逐次実行によるロスを嫌ってということですね。
ハーフワープ内が同一アドレスにアクセスすることが保証されている箇所をConstantMemoryにしたと。
そして効果は誤差程度だったと…変なことを言ってお手間を取らせてしまい申し訳ないです。
（）のタイトルで思ったのですが、学会発表などのIntroductionで
工学的・社会的意義を唱えたい場合はPassword and Key recoveryに役立ちます！
って主張するしかないのだろうか…
総当り方式だから暗号の耐久性云々の話とはちょっと違ってくるだろうし。
KS[16][48]（実際には32ビット×24で格納）の計算をシフト演算で置き換えて(, 519)、
gputime計算で260KTrips/secと約3％のスピードアップになった。
しかし使用レジスタ数が23→27、これに伴いoccupancyが0.875→0.750に低下した。
occupancyが下がっているのにもかかわらず速度が改善されているのだから計算量は確実に
減ったといえるのだろうけど、「レジスタ使ったから速くなりました」みたいで悔しい。
演算を分割してレジスタ消費を抑えられないかを調べてみる。
途中、(x<<(-2)) は (x>>(2)) と等価ではないことを知らずにハマりかける。
なぜ等価じゃないんだ…と思ったけど、加減算などと違って左右のシフトでは使っているであろう
ハードウェアロジックが違うからかなあとなんとなく納得する。
ググろうとしても右シフトでMSBに0を埋めるか1を埋めるかの話ばかりがヒットしたので
真相は(自分の中では)闇…WikiPediaにも理由までは載っていなかった。
ビット演算 - Wikipedia
ttp://ja.wikipedia.org/wiki/%E3%83%93%E3%83%83%E3%83%88%E6%BC%94%E7%AE%97#.E3.83.93.E3.83.83.E3.83.88.E3.82.B7.E3.83.95.E3.83.88 ＞一方、C, C++ 等では未定義動作となる。
での使い分けを見て思ったのだけど、
AバイトのConstantMemoryは、A*16バイトのSharedMemoryによって性能低下なしに
置き換え可能（逐次実行になるリスクがゼロになるボーナス付き。アドレス計算のコストは目をつぶるとして）なのだろうか。
ワープとバンクコンフリクトとバンクについての理解が全然足りないのでこれを機に調べて確認してみる。
ふむふむによるとUFC-cryptは280KBのテーブルを使うと…
いやまて約7*10^17バイトのテーブルを使えばO(1)で10桁トリップが計算可能…ｺﾞｸﾘ
今更ながらレジスタ数/スレッドは与えられるものではなく与えるものであることに気づく。
20, 24, 28のうち24が今のところベストで267KTrips/sec。
命令文の書き換えに飽きてきたのでこれからしばらくはSharedMemoryの活用に注力する。
テクニカルトレーニングVol1の「バンクの競合がなければ、共有メモリは最も高速なレジスタ」を信じて。
青山幸也先生のCUDAプログラミング入門(cuda_all_2011-04-01.pdf)を読み進め、
メモリ周りについての知識のなさをカバーしようと試みる。
行列R[64]（実際はL[32]とR[32]の両方）を現在のローカル変数(GlobalMemory)からConstantMemoryに戻す。
192threads/blockなので(32+32)*192=12KBで十分48KBに収まる。
何も考えずにR[i+threadIdx.x*64]的なアクセスをやると見事に速度が1/4に低下した。
バンクコンフリクト回避を考えR[i*threadsPerBlock+threadIdx.x]にすることで
ローカル変数のときに比べて1割速度が改善され、301KTrips/secとなった。
SharedMemoryさんすみません私の使い方が間違っていました…()
＞crypt内部変数のunsigned int [64]をSharedMemoryからローカル変数に変えただけで倍速になった！？
勝手に速度は↓だと思っていたら、
バンクコンフリクトなしSharedMemory＞＞バンクコンフリクトありSharedMemory＞GlobalMemory
実際は↓でした（GlobalMemoryは何も考えていないのでおそらくuncoalesced）。
バンクコンフリクトなしSharedMemory[110km/h]＞GlobalMemory[100km/h]＞＞バンクコンフリクトありSharedMemory[25km/h]
その中で--ptxas-options=-vというオプションを知り早速追加（VSのGUIで項目があった）する。
ConstantMemoryを指すcmem[0]やcmem[2]やcmem[16]の違いについては不明のままだが、
コンパイル時にレジスタ（指定してるから自明だけど)やLocalMemory・ConstantMemoryの消費量が
わかるのは今後役に立つかもしれない。
このまま192threads/blockでいくなら1threadあたりあと192BytesもSharedMemoryが使えるので、
これから他の変数もSharedMemoryへの置き換えを試してみる。
って、こんなの見ても役にはたたんか。ｗ
Cygwin 環境下で nvcc を make で、なんていうヘンタイなボクは
nvcc -h > nvcc.txt したのをたまに見る。ｗｗｗ
アドバイスありがとうございます！
手元にあるのは2010年11月版なのでこれを機にSDK4.0に移行しようかなと思います。
ちょうど4.0のProgramming Guideを読んでcapability1.xと2.xの違いでバンクが16とか32とか
同じ32bitワードならコンフリクトなしとかを整理したくなってきたので。
あとの
＞192threads/blockなので(32+32)*192=12KBで十分48KBに収まる
は間違いでした。12KBの時点で既にoccupancy0.5以下は必至。
SharedMemory/blockは48KBだけど48KB丸ごと使うとMultiprocessorあたり1blockしか入らなくなるんだ。
occupancy0.5に低下したにもかかわらずメモリの配置変更だけで以前より早くなったということは
メモリの遅さがボトルネックになっているということか。
CUDA core数やシェーダクロックを考えるとGTX460はGTS450の4〜5割増かな。
でもメモリバス幅が2倍になるからメモリがネックならそれ以上も期待できるのか。
今ならSLI対応マザー込みでも4万円かからずに組める…ｺﾞｸﾘ…いやまて…Keplerはいつ出る…
4Gamer.net ― 総額4〜5万円の「GeForce GTX 460」SLIテストレポート。GTX 480に代わる選択肢として一考の価値あり（GeForce GTX 400）
ttp://www.4gamer.net/games/099/G009929/20100716100/ Programming Guide ver4.0のp.170を読み、32bitワード単位でインタリーブと
あるから以下のように解釈した。しかしiArray[tid % 128]でアクセスしても
iArray[]をGlobalMemory上に置いたときの半分の速度になってしまった。
__shared__ int iArray[128];
iArray[0]→バンク0
iArray[1]→バンク1
iArray[2]→バンク2
…
iArray[31]→バンク31
iArray[32]→バンク0
iArray[33]→バンク1
…
iArray[127]→バンク31
__shared__ char cArray[128];
cArray[0]、cArray[1]、cArray[2]、cArray[3]→バンク0
cArray[4]、cArray[5]、cArray[6]、cArray[7]→バンク1
cArray[8]、cArray[9]、cArray[10]、cArray[11]→バンク2
…
cArray[124]、cArray[125]、cArray[126]、cArray[127]→バンク31
なぜだ…解釈が間違っているのかと思いきや、occupancyが0.125になっていただけだった。
それもそのはず、192*(64Bytes+4*24Bytes)=30KBのSharedMemoryを使っており
Multiprocessorが1ブロックずつしか処理できなくなっただけ。
KS[]の4*24Bytesは25回ループ(m)の中の16回ループ(i)の中の8回ループ(k)中に6回参照されるので
ぜひともSharedMemoryに入れたいところだったけど…。
＞《F.4.3》 シェアードメモリ (Compute Capability 2.x)
＞シェアードメモリは32個のバンクを持っていて、連続する32bitのワードは連続するバンクに割り当てられます。
＞つまりメモリインタリーブみたいなもんです。
＞
＞それぞれのバンクは1クロックで32bitの帯域を持っています。
＞したがってcapability1.xのときと違い、前半のハーフウォープと後半のハーフウォープ間で
＞バンクコンフリクトを起こすことがありえます。
（これはバンクコンフリクトの対象がハーフウォープからウォープになったのかな？）
＞
＞バンクコンフリクトは、2つ以上のスレッドが「同じバンクに属する異なる32bitワード」に
＞アクセスしたときに生じます。「同じバンクに属する同じ32bitワード」であればいくつ
＞のスレッドが同時にアクセスしてもバンクコンフリクトは起こりません（読み込みなら。書き込みは未定義）。
＞1.xと違って、読み込みのときは複数のワードを1回の転送でbroadcastすることができるのです。
＞
＞つまり、1.xと違って、次のようなchar型配列へのアクセスはバンクコンフリクトを生じません。
＞__shared__ char shared[32];
＞char data = shared[BaseIndex + tid];
＞《F.4.3.1》 32bit Stridedアクセス
＞よくあるのは、各スレッドがスレッドID（tidとします）とあるstride（sとします）を
＞使って、配列中のある32bitワードにアクセスするというやりかたです。
＞__shared__ float shared[32];
＞float data = shared[BaseIndex + s * tid];
＞
＞この場合、スレッド{tid}とスレッド{tid+n}は、次のいずれかであるときに確実に同じバンクにアクセスしてしまいます。
＞１．s*nが32(2.xにおけるバンク数)の倍数であるとき
＞２．32とsの最大公約数をdとすると、nが32/dの倍数であるとき
＞したがって、32/dが32以上のときに限りバンクコンフリクトを回避でき、
＞つまりd==1で、要するにsが奇数のときです。
同時にロードできるブロック数が減るのかや・・・
不足したときにデバイスメモリに退避とかするより効率的なのかもしれぬが、
気をつけねばうっかりはまってしまうの。
しかし1スレッドで使えるレジスタやシェアードメモリの数はかなり厳しそうじゃの・・・
アンコアレスでそこまでグローバルメモリが速いとも思えぬが、キャッシュが効いておるのかの。
ラウンド鍵KS[]はcrypt()でも56ビットの鍵から恒等的な演算で導けるのじゃから、
展開してハードコードしてやれば不要になるの。
今やっているのが一段落着いたら試してみてはどうかの。
LとR、それに56ビットの鍵の120byteはスレッド毎にシェアードメモリで、
saltの影響を受ける拡大転置Eはコンスタントメモリで、
S-boxはコンスタントメモリもしくはグローバルメモリからシェアードメモリにロード、
余裕があればDESの入出力の64byteは余裕があればスレッド毎にシェアードメモリかの。
レスありがとうございます！
以下、あくまで192thread/blockのoccupancy100％を維持する前提ですが、
現時点の自分の理解では以下の※2つの結論となります。
Multiprocessorあたりの最大処理可能スレッドは1536
Multiprocessorあたりの最大処理可能ブロックは8
→つまりthreads/blockが192のときにギリギリ8ブロックに収まる
→192threads/blockのときに1スレッドあたり使えるレジスタは20本 ※
この192thread/block × 8 blocks/Multiprocessorsのときに
(occupancy100％を維持するなら)1ブロックが使えるSharedMemoryは48KB/8＝6144Bytes
つまり1スレッドが使えるSharedMemoryの最大値は6144/192＝32Bytes ※
（occupancy0.875にして7blockにするにしてもレジスタが24本、SharedMemory36Bytesとなるはず。）
32Bytesということは32bitが8本ということですが、どこに割り当てるべきかというと
KS[]は96バイトの情報なので無理なので、
block[](64bit)、L[](32bit)、R[](32bit)、preS[](64bit) の合計24Bytes。おお、収まりますね。★
おっしゃるように56bit(64bit格納)の鍵を加えてジャスト32Bytesです。
SharedMemoryの使える量はもっと速くに気づくべきだったんですが…。
KS[]の算出を展開ですか…。確かに1ビットずつ考えていけば分解というか展開できますね。
ちょっとできるかどうかわかりませんけど選択肢として頭に入れておきます。
できれば「同じKS[]を持つようなキー56bitの集合」を特定してKS[]の計算をカーネル外に
出せたら相当速くなる（計算量が減る上にGlobalMemory→ConstantMemoryの効果）のですが、
そもそも数学的にそれが可能かどうか…。
DESとはいえそのへんはしっかりしてそうに思いますが、一度紙とペンとLibreOfficeを使って考えたいと思います。
原点回帰(?)で今はSharedMemoryを全く使っていないのですが、occupancy100％が効いているのか
357KTrips/secになりました。ちなみにレジスタを24本使ってoccupancy87％のときは356KTrips/secです。
あとはblock, L, R, preSをSharedMemoryにしてどれくらい早くなるかですね。
ちなみに途中で、SharedMemoryに入らないならレジスタを使えばいいじゃないと
KS[]の96バイトの半分をむりやりレジスタに入れて（配列を使えない(?)ので面倒でした）
みましたがそれでも48BytesのSharedMemory＋レジスタ合計42本を使うためoccupancyが上がらず、
性能はイマイチでした（たしか200KTrips/secくらい）。
しかしunsigned int LR[2]をSharedMemoryにすると320KTrips/secに落ちた…
今回はoccupancyも1.0で変わっていないのになぜ…既にLRはレジスタに入っていたのかな。
いやバンクコンフリクト？
LR[i]をLR[i*192+threadIdx.x]に置き換えていて、threadIdx.xは0〜191だからバンクコンフリクトは
起こりようがないはずなんだけど…昨日も言ったとおりSDK4.0の入れ時かなぁ。
2日ほどCUDAマシンに触れない日が続くので続きは来週やります。
＞できれば「同じKS[]を持つようなキー56bitの集合」を特定してKS[]の計算をカーネル外に
入力のキーがが56bit、出力のKS[]が768bitだから異なるキーから同じKS[]が
現われるようにはなっていないでしょうね。それでも入力のビットとKS[]との対応がきれいに
整理できるとすれば部分的に計算とメモリをカーネルの外に出せるのですが。
とりかかったところです。大分慣れてきたので1個あたり2時間弱ぐらいで済みそうな
感じですけど、それでも随分時間がかかりますねえ。
必要もなくなりました。今日中に全部終わらせたいところだけど、ちょっと
厳しいかな〜
レジスタ数の削減は何とかなりそうな感じなんですけどねえ。現在公開してるバージョンが
OSによっては立ち上がらないのが判明したので、早めに新しい版を公開したいところです。
cudaTripper12Wiz7.exe -fastMessage off -yukiNMessage on
みたいな遊び機能はつけないんけ(*‘ω‘ *)？
＝358KTrips/sec
→preS[]をLocalMemoryからSharedMemoryに置き換えた
＝358KTrips/sec(小数点以下の範囲でわずかに改善)
→25回ループの初回(m==0)は初期転置をする必要がない(オールゼロ確定)のでif文で除外した
＝360KTrips/sec
→threads/blockを192から256に変更。というのも同時に走るスレッド数は変わらない(効率は落ちない)ことに気づいたから。
＝362KTrips/sec
→環境を4.0に移行した
（Computing SDKのアンインストール→ToolKitのアンインストール→Developer Driver 4.0のクリーンインストール
→ToolKit4.0のインストール→Computing SDKのインストール→projectのパス再設定）
＝357KTrips/sec
→sm_20からsm_21に変更した
＝382KTrips/sec
力技以外での高速化のネタが尽きた感が…あとは#pragma unrollしまくるとか…
Toolkit4.0に同梱のPTXやThrustのドキュメントを眺め、改めてCUDAは親切だなぁと感じる。
将来DirectComputeやOpenCLの独占状態になる可能性はあるにしても、
ATI StreamがCUDAのシェアを上回ることは考えにくいなあと思う。
sm_20とsm_21の最適化の差が結構あるの。
25回ループの初回に初期転置を行わないだけで差が出るということは、
初期転置や最終転置をハードコードするだけでも結構な効果がありそうじゃの。
展開してハードコードは色々と大変じゃが、
色々な処理が省けるということに気がつくと中々におもしろいと思いんす。
手作業だけでやろうとすると膨大な時間がかかるがのｗ
昨日レスできなくてすみません。
最終転置についてもm==0の初期転置のようなわかりやすいショートカットが
できないかなと思ったんですが、最終転置したものが出力になるので
できま…あれ？…できますね…できます。
あらかじめ所望の32bit値を最終転置の逆変換をかましておけば
64bit値＋マスクの比較にはなりますが、できますね。
ヒントをありがとうございます！早速やってみます！※修正案1
…だがちょっと待ってほしい。m==25-1の最終転置の前には何があるだろうか。
R = L ^ f[P]に相当する部分は逆変換を事前に求めることはできないが、残りの部分はL=Rでまだ遡れる。
つまり出力の64bitのうち32bitは｛m==25-1かつi==16-2｝におけるR = L ^ f[P]の代入が終わった時点で、
確定する。ここで枝刈りを行えば…ｺﾞｸﾘ…※修正案2
修正案2によるコストはスレッドあたりifが25*16==400回増えること（＋64bitマスク判定）。
そのメリットは、早期の判定で32スレッド全会一致で却下されたときに限り、その後の処理を省略できること。
その後の処理は1/400に過ぎない計算量ですが…
所望のトリップ候補が多数だとifコストも増え全会一致で却下の可能性も下がりそうですが…
逆変換前後のbitの位置を調べないとそもそも絵に描いた餅になるかもしれませんが…
とにかくやってみます。
コストの400回ifはカウンタのifだし最後だけの条件変更なので、ループをunrollすれば数回にできるハズ…
修正案1でどのくらい減るか、修正案1＋修正案2でどのくらい減るかor増えるか報告します。
この書き込みは当初「展開やハードコードはやっぱり面倒です」と書くつもりだったのですが
具体的な修正案と結び付けられると確かにおもしろいものだと思えてきそうです。
これまで＝382KTrips/sec
→なぜかConstantMemoryの変数の多くがsigned charだったのをunsigned charに置き換えた
＝389KTrips/sec
→__const__ unsigned char S[8][64] を __const__ unsigned int S[8][64] に置き換えf作成時のビットシフトを不要にした
＝393KTrips/sec
ここまできたら400KTrips/secには届きたい。
できれば500K。500いったらGTX580さんが1Mまで連れて行ってくれる。たぶん。
→の修正案1
＝393KTrips/sec(小数点以下で改善）
→カーネルからCPUへは最終転置をせずに送り返すことにした
＝394KTrips/sec
→カーネルからCPUへの出力である一致成否変数を8バイト(以前はblockを返していたため)→1バイトに
＝395KTrips/sec
→の修正案2（15bit判定のみ）
＝390KTrips/secに低下 ※
→の修正案2（15bit判定を通過後、i==16-1のループ実行→残りの15bit判定）
＝397KTrips/sec
これまでは0〜5ビットはトリップで不使用のため6〜31ビット目の26bit判定だったわけですが、
それに対する最終転置FPの逆変換を考えると、それぞれのビットは均等に0〜63ビット目に
ばら撒かれていました。
つまりm==25-1でi==16-2のループが終わった時点で32ビットの情報は確定していますが、
トリップの先頭5文字×6＝30ビットのうち半分の15bitがその確定した32ビットの中にあります。
これまでの26bit判定(32-6)から15bit判定にしてもごくわずかのヒット率が2048倍になる程度、
とりあえず全列挙しておきそこから1/2048をみつけるのはCPU側でやればいい…
と思っていたら※のように速度が低下しました。
これまでと比べて2048倍グローバルメモリにアクセスする機会が増えたことが
原因かなと推測しています。
if(){ ... ; break; }
else{ break; }
if(){ ... }
break;
return文も使えない（実行時エラー）ことに気づいた。
warp内でreturnするのとしないのが混ざっているとダメだったはずと思いきや、カウンタm,iにのみ依存する
分岐のreturn文でも実行時エラーになった。おとなしくbreak2回で脱出することにした。
ピコーン！でf作成時に32ビットのSを使うなら、P転置を済ませたSを使ってOR結合すればいいじゃないか！
もともとは「m==0のときはL[]（0確定)とのXOR演算も削れるな…でもlogical operationって
ほとんどコストかかってないよね…他に削れるところは…」という流れだったけどこれは400届くかな…？
→のP転置済みのS[]を使ってP転置をカーネル内から除去した（P[]はConstantMemory上から不要に）
＝479KTrips/sec
あれっ…えっ…なんか間違いとか見落としとかありそうで怖いんですけど…でも結果は出てるし…
先日、編集中のソースはどんな計算を表しているのかがすごくわかりにくいので、
元になったkenji aiko 氏のcrypt2.cを見ながらチラシの裏に各変数と転置・変換の関係を整理していた。
その際面倒だったのでベクトル（変数）と行列（変換）のように表記していた。
「転置に相当する計算はベクトルと疎行列（要素は0/1）の積まんまじゃないか」
→「疎行列の計算に置き換えると高速化が期待できる・・？」
→「いや、その疎行列の計算に特化しまくったのが今の姿だろ…俺ｱﾎｽorz」
あとThrustは内部でCUDAを使っているものであり、CUDA内部でThrustを使うものではないと知ったのもほんの数日前。
（何を血迷ったかてっきりカーネル内でSTL的なことができるのかと…）
これまで＝479KTrips/sec
→1〜7文字一致まで対応するためマスクをConstantMemoryに置いた。他マイナーチェンジ（忘却）
＝475KTrips/sec こんなに遅くなるのか…#defineしてリテラルのほうがいいかな？
→初期転置IPと最終転置FPを合成した
＝450KTrips/sec え？計算量は確実に減ってるし使ってる変数の数も増えてないのに…
→初期転置と最終転置を合成すると、それは0-31と32-63を入れ替えているだけだったので代入文にした
＝483KTrips/sec （ヒットがないときのカーネルコールでは487KTrips/secくらい）
結局、
・m==0のときの初期転置は不要
・m==24のときの最終転置は不要（それ以前に判定が済んでいる）
なので、m==x回目ループの最後の最終転置とm==x+1回目ループの頭の初期転置は
合成してループの最後に持っていくことができる。
しかも最終転置FPと初期転置を合成すると、単に0-31ビットと32-63ビットを交換しているだけ。
そんなはずは…と思ったが結果は出ているので正しいと考えるしかない。
つまり合成した転置用行列すら必要なく、代入（交換）でよかった。
しかしわからないのはFP＋IPを合成する前後で速度が落ちていること。
考えられるのはレジスタの割り当てが変わって、GlobalMemoryへのアクセスが増えたくらい？
そろそろ4.0導入時に気になっていたPTXのpdfを開くときが来たか…
charの変数をunsigned charに変えるだけでも速度が上がるのかや。
S-boxをunsigned intに変えてビットシフトを回避というのがよく分からぬ・・・
FPはIPの逆の処理を行うから、合成すると何も処理しないことになるから、それでいいと思いんす。
Wikipediaによると、当時のハードウェアのブロック入出力の仕様が原因らしいの。
16ラウンド目はLとRの入れ替えを行わないことになっておるし、
Kenji氏などの実装では16ラウンド目にも入れ替えを行っておるから
LとRを再び入れ替える必要があるのではないかの。
Kenji氏の実装を基にしておるなら、配列の先頭を指すポインタを使うようにすれば
配列の要素を一つ一つコピーせずに、ポインタを入れ替えるだけで済むの。
SP-boxを使った実装を探してみると、色々と興味深いものが見つかったのじゃが、
結構複雑な上に、わっちはSHA-1の方の修正を行うのが先かの・・・
atomic関数を使ってデータ構造にも手を加える予定で結構時間がかかりそうじゃが、
そっちもかなり気になっておるからの。
＞S-boxをunsigned intに変えてビットシフトを回避というのがよく分からぬ・・
以下、こんな説明でいいかわかりませんが：
もともとS[][]はどんなi,jに対しても
S[i][j]…0〜16(未満)
で各要素は4ビットの情報しか持っていません。
ですがたとえばS[1][j]は必ず4ビット左シフトして一時変数fの第4〜7ビットに代入され、
S[2][j]は必ず8ビット左シフトしてfの第8〜11ビットに代入されます。
そこでSをucharの配列ではなくuintの配列にしてあらかじめ左シフトすると
S[0][j]…0〜2^4
S[1][j]…2^4〜2^8
S[2][j]…2^8〜2^12
S[3][j]…2^12〜2^16
…
となってfへ代入の際のシフト演算が不要になるということです。
【before】f=(S[0][a]<<0) | (S[1][b]<<4) | (S[2][c]<<8) |… | (S[7][h]<<28);
【 after 】f=S[0][a] | S[1][b] | S[2][c] |… | S[7][h];
さらにこのfは行列Pによって転置されたものだけがXOR演算で使われるので、
あらかじめそのP転置をS[][]に対してかけたものを定数配列S[][]としておきます。
すると↑のf作成式を修正することなく、R生成を
R=L^fという32ビットlogical operationで実現できP転置を省略できます。
WikiPediaのDESを見るとExpansionのビット割り当てなど新たな発見がありました。
FPはIPの逆でしたか…おかげさまでスッキリしましたありがとうございました！
上の例でもそうですが、LやRなど0/1しか入らない変数はuchar[]ではなくuintで
ビット格納しているので、LR入れ替えは代入文で済ませています。
現在は転置処理省略の最後の砦(?)、KS[16][48]からpreS[48]作成までを攻略中。
kenji aiko氏によるcrypt2.cでいうところの以下の部分。
for(j=0; j < 48; j++)preS[j] = R[E[j]-1] ^ KS[i][j];
その前哨戦として、KSの格納方法を変更した。
これまではメモリ使用量を切り詰めるため、unsigned int KSa[24]で格納していた。
KS[i][j]に対応するものがKSa[j/2]の第(i+(j%2)*16)ビット目、という表現で。
これでKSが持つ情報量である768ビットを過不足なく収めることができた。
一応uchar KS[16][48]よりは速度も3％ほど改善された（）。
しかしこの方法では次の問題があった。
１．あるステージiのときにKSa[0]〜KSa[23]の全てアクセスする必要がある(の列方向云々)
２．その後のR[E[j]-1]とのXOR演算を32ビット整数で行うことが困難
そこでメモリ使用量は増えるが、unsigned int KSb[32]で格納することにした。
KS[i][j]に対応するものがKSb[i*2+j/24]の第(j%24)ビット目、という表現で。
これならステージiのときにKSb[i*2]とKSb[i*2+1]にアクセスするだけで済む。
（実際はその後の演算のために第( ((j%24)/6)*8+j%6 )ビット目に対応させている）
コンパイル時に教えてくれるspill storeとspill loadは2倍になったが、速度が大幅に改善された。
というかこんなにも足を引っ張っていたのか…
悩みどころは、KSaの方式はアクセス効率こそ悪いものの、C[]、D[]からの
作成速度は俺の考えられる範囲では最善だということ。ここを何とかするアイディアは
ないではないけど、非常に面倒だしやってみないと速くなるか遅くなるかわからないので後回し。
preS導出を32ビットXOR2回で行うようにした＝840KTrips/sec
(速度には関係ないが可読性のためE[]生成にも多少手を加えた)
もう削れる転置が残っていない…たぶん…
→KSの生成を、KS[i][j]はkeyのどのビットからくるかというテーブル(ConstantMemory上)で行った
＝853KTrips/sec
→KSの生成を、keyのnビット目はKSのどの位置(複数ある。12〜15）に影響するかというテーブルで――
＝866KTrips/sec
今後の予定：
KSの生成時間を仮に1/56にできれば1500KTrips/sec程度になる見積もり。あくまで推定。
というのもKS生成コードを1ループしか回さないときの走査がそれくらいだったから。当然正しい結果は出ないけど。
このときKS生成ループの短縮以上の最適化がされてしまっていたらもっと低くなるので、
1500というのはKS生成の高速化で到達できる上限でしかないけれど。
そしてこのKS生成時間は1/50くらいにならできそう。
むしろそのために「keyのnビット目はKSのどの位置に影響するか」のテーブルを作った。
本当に1/50にできるなら、算盤の上では1490くらいだろうか。と自分を追い詰めてみる。
SMあたりのスループットの表を見て、CC1.xとCC2.0とCC2.1では
コアあたりのシフトや乗算のスループットがかなり異なることに今更ながら気がついた・・・
GF100系とGF104系での性能差は、コアあたりのレジスタ数だけの問題でもなさそうじゃの。
もうucharの配列ではなく、uint32にビット格納にしておったのかや。
メモリ消費だけでなく演算量もかなり減って効果も大きそうじゃの。
主様のおかげでSP-boxを利用した実装の理解も少しは楽になりそうな気がしてきたの。
ビット格納の場合はkeyからKSを生成するのに結構な演算量になりそうじゃから
メモリ使用量が増えるのは我慢してKSを保存しておいた方がいいのかの・・・
Compute Capability 2.0以降でSMあたりのコア数やレジスタ数が増えておるが、
同時にロードできるブロック数の最大数はSMあたり8のままで、
上限が上がっておるのはSMあたりのワープ数じゃった。
ブロックあたりのスレッド数を増やすしかなさそうじゃが、難儀しそうじゃの・・・
ttp://kie.nu/Lq cuda_sha1tripper-0.4.2_win32bin.zip -
ttp://kie.nu/Lr とりあえず共有メモリの使用量が多くてFermiより前のGPUで
アクティブになるブロックがSMあたり1つ（となると思われる）バグの修正と多少の改良を行ってみたの。
Fermiシリーズでは特に差は見られないと思いんす。
CUDA Occupancy Calculatorを使ってブロックあたりのスレッド数を真面目に検討しておるのじゃが、
やはりレジスタ数の制限が厄介そうじゃの・・・
スレッドあたりのレジスタ使用量を20にまで減らさねばならぬというのは結構厳しいの。
レジスタ数のオプションを色々と試しておるとP-stateが一番上まで上がらぬようになったのじゃが、
ドライバの省電力機能が誤作動したのかの・・・
表示は止まるけどCPUは走り続けるんですね
これでしばらくしてからPause解除するとmaximamの数値がえらいことになるけど
メール欄
ﾄﾝｸｽ
コード読んでて気がついたんだけど、カーネルの下の方にある
out->trip[いっぱい]=b64t[a〜c];
この11行ってa,b,cだけをホストに返して、変換はCPUでやったほうがいい気がします。
自分のほうはSP-boxが何なのかも存じ上げませんが、結果として何かプラスになっていれば幸いです。
今のところは、KSはmの25回ループの前に生成したものを保持しておく方針です。
ただwarp divergence避けとLocalMemoryへのアクセス回避を両立する方法として、
毎回計算という案も捨ててはいません。
keyからKSの生成の演算量は小さくできたと思いきや大して効果がなかったので(後述)、
これからwarp divergenceを起こさないような生成方法にする予定です。
それとありがとうございます、今回もダウンロードさせていただきました。
交番二進符号（グレイコード）を使ってKS生成の計算量は1/50どころか
1/127くらいにした。したはず…なのに速度がたいして上がらなかった。
前回866KTrips/sec
→1スレッドあたり32パターンではなく128パターンを走査(qループ)することにして877KTrips/sec
→あるループq+1のときのKS生成をqからの差分（ここで交番二進符号)から求めることにして897KTrips/sec
なぜかqを32回ループに戻すと930KTrips/secくらいまで上がるけど走査範囲が面倒になるのでその手は使わない。
【これまで】
高速大容量のメモリ領域がほしくて、ではTextureMemoryでできることについて調べようと思い
青山幸也先生のCUDAプログラミング入門(cuda_all_2011-04-01.pdf)を読み直す。
なぜかwarp divergenceについてのページに目が行き、現在divergent_branch=[ 660 ]であることに気づく。
しかも全てKS生成で発生している模様（KS生成コードを削るとdivergent_branch0になった）。
warp divergenceは、KS生成時の「keyの第nビットが立っていたら―を行う」という部分で発生している(はず)。
0〜255のうち立っているビットの数をwarp内で揃えればdivergeも減ると思い、パスカルの三角形とにらめっこをする。
しかしそう都合よく分配できるわけではなさそう。4bit以上は逆に0のANDマスクという手もあるかもしれない。
warp divergenceについてBest Practice Guide4.0を調べるつもりが、
またもその次々項である「ループカウンタは符号付きで」に目が移りビビる。
＞Medium Priority: Use signed integers rather than unsigned integers as loop counters.
理由は納得できるようなできないような…ということはたぶんできてないが
実践してみると約4KTrips/sec(0.5％）速度が改善された。
あと今更ながら64bit整数の演算が使えることに気づく。なぜのスループット表に載っていないんだ…。
可読性etcを考えるとunsigned long longは捨てがたいが、SharedMemoryに置いたときや
GlobalMemoryに置いたときを想定すると32bit*2のほうが小回りが利くこと、
試しにLRをlong longにすると649KTrips/secにまで落ちたことから、32bit*2での使用を継続する。
【今後の予定】
引き続き、KSの生成方法をどうするかを考えていく。
パスカルの三角形かwarp divergence集中攻撃用の32パターンテーブルで1000KTrips/secに到達…したい。
一応SharedMemoryを使ってthreads間でKS生成を分担するというCUDA的な(?)方法もあるけど…。
原因がよく分からぬが、切り分けのためにも専用マシンが欲しくなるの。
CPUでの処理をなるべく軽くしたかったのじゃが、
ワープ内の他のスレッドを待たせることになるというデメリットもあるの。
そのままreturnして、そのスレッドはそれ以上検索しないのをまずは何とかしようと
データ構造の見直しも考えておったのじゃが、キーの情報は30ビットじゃから
出力全体をuint32の配列にしてCPU側で色々と処理するのもよさそうじゃの。
SP-boxはS-boxにP転置を施したものをそう呼んでいる実装がいくつかあって
発想としては主様と同じかと思いんす。
KSの生成にグレイコードやパスカルの三角形を使う方法もあるのかや。
わっちの頭では思いつきそうにもないの。
ループカウンタの話はBest Practices Guideの6.3かの。
オーバーフローの検出のしやすさでコンパイラでの最適化のしやすさが変わるのかの？
大量のドキュメントを読むのは面倒じゃが、やはり重要じゃの・・・
一般向けのGeForceシリーズでは倍精度の性能に制限がかけられていたり、
モデルによってはそもそも一部のユニットしか倍精度に対応していなかったりするようじゃから
64ビット整数も同様なのではないかの。
やっぱし同じところで躓いてるんだな・・・
命令コードのサイズに縛りさえなければ、KS[16][48]を作らずにK[56]のままやったほうが効率よさそうなんだけどね。
つまりオリジナルのBitsliceのコードみたいに16イテレーションを全てアンロールしてしまう、と。
ところでKnights Cornerはかなり安いらしいんだが物理演算アクセラレータとして
コンシューマ市場に出たりとかしないかねえ？
前回まで＝897KTrips/sec
→グレイコードでwarp内でのループの数を揃えた(2,3,4,4,4,5,6,8)
→そしてpreS[2]を使い回して32bitのpreS[1]にした
＝906KTrips/se
→立たせるビットが5以上のときは、最初は全て1にして4回以下のビット下げにした(2,3,4,4,2+1,3+1,4+1,4+1)
＝918KTrips/sec
→珍しくCUDA的なこと(SharedMemoryをジャスト8KB使ってKSの計算の一部をBlock内で分担)をした
→これに伴ってSharedMemoryに置いていたpreS[1]をLocalMemoryに置いた
＝961KTrips/sec
【の◆Horo/.IBXjcgさんへ】
自分が思いつくようなことは効率のよくないやり方orよくて車輪の再発明だろうとは思っていましたが、
（既存のstudyをちゃんと調べていない時点で当然ですが）PとS-boxの合成もそんな感じですね…。
おそらくpreS[]生成時のE転置とS(P)-boxの転置の2つは最後まで残る（削れない）だろうと考えてます。
あるキーkey1におけるKS1がわかっているときに、key1のうちの1ビットだけを反転させたkey2における
KS2を、少ない計算量（あくまでもKSをゼロから作るときに比べて）で求めるときにグレイコードを使ってます。
ちなみにグレイコードがv^(v)で列挙できるのはWikipediaを見て初めて知りました(テーブル要らんかった…)。
パスカルの三角形はただnCrを求める（0-255のうちビットがいくつ立っているかで分類するため）のに使っただけです。
そうですBest Practice Guide4.0の56ページの6.3です。
TeslaとGeforceでの差別化ということですね。不良コアはまだしも意図的な制限ならちょっと残念です。
「Tesla100台でHPC」はすごいと思いますが、「一般向けのGeforce100台でHPC！」だったらもっと夢があるんだけど。
いやいや、32bit整数演算で夢を追い続ければいいのか。
【次回予告】
あれ？KSの半分はConstantMemoryに入るんじゃ…とにも懲りずに自分を追い込んでみる
まさかとは思うけど、KS生成のたびにキー文字列を律儀にtransposeしてる？
#ABCDEFGH
とする。これを前半のABCDとEFGHにわけよう。
EFGHの部分は128個のキー全く別々の文字列にしてパックする。
ABCDの部分は同じ文字をパックする（転置したビットパターンは00000000かFFFFFFFFで表現できる）
シーケンシャルに変更して最後まで達したらEFGHの部分を再生成する。
あと、transposeは1ビットずつちまちますんなよ。
ttp://www.hackersdelight.org/HDcode/transpose32.c.txt 初歩的なことだけど、CUDAの機械語でサポートしてるビット論理演算って
未だにand, or, xor, notだけなの？
ttp://www.openwall.com/john/ もう4ヶ月前の話ですまんが、なにやらJtRの人がvselを使った最速のS-box作ったらしい。
JtR本体はGPLだけど新しいS-boxは劣化BSDライセンスで使えるから関係各位は
とりあえずマージしとけばいいよｗｗｗ
つーかさ、情報収集能力に長けてる私にそんな情報をいまさら。>最速S-boxww
w
ww
奇怪語とかの低レベルな話はキライだって知ってるだろ？
まあ、s2uwとかつくっちゃったし、もはや説得力ないか。
ra8最高！(和良
2chがDESだのSHA-1だのオワコンの暗号形式にこだわってるのはなぜかって
ぶっちゃけ管理者が馬鹿なだけだからな。
てか、今年11月までのレンタル料しか払ってないからあのサイトどのみち消えるよｗｗｗ
だから再配布する権利をよこせ。ｗいや、くれ。いあ、ください。
てゆか、上の方で言ってるのって、TXのやりかたじゃん。ｗ
どうせ現状でもBrothersoftに無断配布されてるんだし
CPU側であれこれやってみたら遅くなってしもうた。
非同期にしておらぬからCPUでの処理に時間がかかって足を引っ張っておるのかと
プロファイラで確認すると、sha1trip_serach()のGPU Timeも伸びておった・・・
キーの5文字30ビットをuint32にするのは演算量が増えてデメリットが多いの。
トリップのBASE64エンコードだけCPU側での処理というのも試してみたのじゃが、
先頭30ビットがヒットする確率が高くないせいかGPU Timeの差は0.1%以下でしかなかった。
他の部分の改良が済んでCPUでの処理を非同期にした後でまた試してみるかの。
予告どおりKSの半分をConstantMemoryに入れる方向で修正した…がバグがあり正しく動作しない
走査範囲がガラリと変わったこともあり段階的に試していなかったのでどこが間違っているのかさっぱり…
偏った走査になるというデメリットもあるし速度がどうなるかはバグをなくしてからのお楽しみだけど、
これまでLocalMemory(GlobalMemory)に置かざるをえなかったKSへのアクセスの半分が大幅に改善されるはず。
どこだ…どこに間違いがあるんだ…
アドバイスありがとうございます！
キーから1回1回転置するようなことはやってないです。の↓です。
＞あるキーkey1におけるKS1がわかっているときに、key1のうちの1ビットだけを反転させたkey2における
＞KS2を、少ない計算量（あくまでもKSをゼロから作るときに比べて）で求める
またPC1_C・PC1_D・PC1_D・PC2_Dの転置は合成して1つの転置にしています。
転置後のビットパターン順で0からFFFFF...まで走査するというやりかた（？）は
１．KS(i==0)は0〜FFFF..に並ぶが、KS(i==1〜15)は結局転置が必要
２．トリップとして有効な値域(文字コード)かの判定が厄介
だと思うのでやってないです。
ちゃんと考えるのはバグ取りが終わった後にさせてもらいますが、
これって32x32の2値行列の数学的な転置(aij==bji)ではないですよね？
DESでやっているシャッフル的な転置も可能なのでしょうか。
→KS[]の半分をConstantMemoryに入れた。＝947KTrips/sec（ガーン…）
これに伴ってSharedMemoryの使用量もMAXの半分である4096Bytesにはできるはず。
2日間ほど正しい結果が出ずに辛かったが今は正しく動いている（と思う）。
しかしなぜか速度は落ちた。てんこ盛りになっていたデバッグコードは
除去したはずなので、この方法の効果が薄かったということだろうか。
いやそんなことはない（と思う）！
今後はいくつか気づいた自明な演算の除去などの調整をして再チャレンジ！
デバッグの日々で思ったのは、CUDAコンパイラの最適化は相当手ごわそうだということ。
「結果は正しくないけれど本番と同等と思える（思えた）」コードでは1000KTrips/sec越えがよく出る。
の1490とかいう妄言とは違って、ループの回数を削る・処理を丸ごと削るなどはしていないのに。
何らかの間違いのある処理から不要な部分を見つけ出してショートカットしているのだろうか。
正しい処理は、効率の差はあれど情報処理的に冗長ではないってことかな。
妄言といえば、KS生成速度がの1/50だとかの1/127とかも間違いでした。
初期の方法と比較しても最大で1/56、グレイコード使用による効果は
最大で1/7（使用グレイコードのビット数7)しか得られないはず。
速度は変化なし。
m==15、i==14の時点の一致判定をS[0][]〜S[3][]の部分の枝刈りを前倒しして高速化できればと
考えたが、効果はなかった。
おそらく(5文字一致の場合）前倒しされるのは実質5ビット分の判定でしかないため。
CPUでの条件判定と違って1warp中に1つでも枝刈りできないものがあれば効果がないのが厄介。
blockIdx依存のKS生成を高速化できると思ったが、既にblock内で分担しているから
ほとんど変わらないだろうし、そもそもここは処理時間全体の1％もかかっていないはず。
いいかげんそろそろ、「コード修正→profileのgputimeの変化を見る」というどんぶり勘定をやめ、
gputimeを数箇所でみてどこに時間がかかっているのかをちゃんと調べよう。
枝刈りの関係上、5文字判定ではなく6文字やそれ以上にするほど走査は高速になることに気づいた。
瞬間風速では7文字で1MTrips/secに達してるからこれを以って高速化…ｹﾞﾌﾝｹﾞﾌﾝ…
おかげさまでやっと意味が（なんとなく）わかってきました。
32x32の縦横を入れ替えて、ビット演算を32並列化された0代入や-1代入などに
置き換えられるというのがbitsliceの考え方だったんですね。
（他に【※1】、【※2】を参考にさせていただきました）
ご紹介いただいたtranspose32a()は縦横転置をする関数で、
mが0x0000FFFF→0x00FF00FF→…→0x55555555と変化していき、
5*16*(シフト2回、論理6回、32ビットload/storeが5回)
くらいの演算量で行うものであると。
そしてシャッフル的転置も代入(交換)で32回分同時に行えると。
おもしろいですね、アドバイスありがとうございました。
自分のコードで残っているE転置を32並列化する場合、シャッフル的転置のコストの変化は
現在 →{シフト2回、論理2回、非2べきmodと除算2回、加算1回、32ビットload/store72回(48?)}×32
32並列→{32ビットload/store72回}×1＋{シフト2回、論理6回、32ビットload/store5回}×5*16×2
（おおよそ）となるはずで、処理量もメモリアクセスも大幅に改善されそうですね。
1スレッドで行う場合の記憶領域(一時変数32倍)をやりくりできればどえらいことに…
道理でbitslice DESにボロ負けするわけだ。
とはいえ、「DESの旧来の実装方法では」「GTX 260で75Mkey/sec程度」【※3】とあるので
1MTrips/secにも達していないことの言い訳にはできないんですけど…。
【※1】DSAS開発者の部屋:bitsliceによる超高速ビット演算
ttp://dsas.blog.klab.org/archives/51389536.html 【※2】だんごやさんの覚書き - Bitslice DES
ttp://dango.chu.jp/hiki/?Bitslice+DES 【※3】お馬鹿な猫の備忘録 DESやcryptのCUDAでの実装の論文
ttp://nahgo.blog100.fc2.com/blog-entry-23.html 依頼の9完出したらツールの良い検証＆宣伝？になると思うよ
-----
希望の9文字ﾄﾘｯﾌﾟはここだよな(12桁もOK) Part 0x0A
ttp://toki.2ch.net/test/read.cgi/qa/1299965026/732
【ターゲットのまとめ】
【wiz7用(cudaTripper12Wiz7用)】
^Tanamin.. () (コメントに#とかはいらなかったりする)
^IVIG1YNTZ # ()
+GARNET/NA #
+GARNET.NA
^xSx...xSx #
^MINERAL. # ^MINERAL[./][./]用。
^MINERAL/
^Judgment # ^Judgment[./]用 ()
^JUDGMENT
^MIDNIGHT # ^MIDNIGHT[./]用
^EasEasEas #
^WaffenSS. #
^WaffenSS/
^KOUGAKUBU # ()
+coodellar #
+YUZ/24.7/ #
＞道理でbitslice DESにボロ負けするわけだ。
誤解を与えるとまずいのでの発言に補足させていただきますと、
bitsliceを使えば楽に高速化できるとは思っていません。
推測ですが、大きな一時記憶領域が必要だったり地道な展開が待っていたりと
CUDA化する際の課題は色々あるはずで、にもかかわらずそれを実現した
◆MERIKEN4.kさんには恐れ入るばかりです。
→KSの残り半分をGlobalMemoryからLocalMemoryへ
＝968KTrips/sec
→blockIdx依存のKS生成を、「特定warpが6ループして1回同期」から、
「特定warp2つが並列で3ループして、2回同期」にした
＝971KTrips/sec
→E転置で使用する配列を、E[出力位置]==入力位置というuchar配列から、
E[入力位置]==出力位置に1が入ったuint32というuint32配列にした
＝1124KTrips/sec
おかげさまで念願の1MTrips/secに到達することができました。
これまでアドバイスをくださった◆MERIKEN4.kさん◆wordlist..nnさん
◆Horo/.IBXjcgさんさん,, ・´ ∀ ｀・ ,,）っ-○○○さんはじめ
スレのみなさんありがとうございました。
今朝まではだましだましで1000に触れるくらいしかないと思っていましたが、
1割オーバーできて正直ビックリです。
E転置の方式変更も、後述の__ffs()のために作った配列を使ってみただけだったのですが。
ちゃんと走査できているかのチェックはごく簡単にしかしておりませんが、
勝手ながら、ひとまず自分はこれで一区切りしたいと思います（9月中のように
まとまった時間を取ってコーディングすることはしないと思います）。
それにしてもよかった、これでGTX580を買わずに済んだ…。
KSの半分をGlobalMemoryからLocalMemoryにおいてわずかに速度が改善されたが、
その理由は深く考えなかった。しかし別件の検索中に次のような記述を見つける。
GPGPU 勉強会 - CUDA Mistakes
ttp://epa.scitec.kobe-u.ac.jp/~gpgpu/hiki/hiki.cgi?CUDA+Mistakes ＞local領域はデバイスメモリにあるのだが、local領域はつねにスレッドと
＞同じ数だけあるので、自動的にコアレスされるらしい。
なるほど。GlobalMemoryに置いたときもcoalescedになるように気を付けたはず
だったけど、元々ホストからも他のスレッドからも参照される必要のない変数なので、
LocalMemoryに入れてコンパイラに任せたほうがよかったのかもしれない。
時間計測はCUDA専用の関数があったと思いきやそれはカーネルの外での
話（cudaEventCreateなど）で、カーネル内ではclock()でよかったのだと知る。
早めに使っておけばよかった。ここで使うclock()もCUDA専用ではあるけど。
時間計測の結果からE転置が最大のネックであろうと判断する。
時間計測と前後してProgramming Guide4.0の C.2 Intrinsic Function中のInteger Functions(p.141)で
__ffs(int x)という関数（xの最も下位のONビットの番号＋1を返す。オールゼロならゼロを返す）を知る。
これを使えばE転置を次のように高速化できると考えた。しかし結果は960→735と悲惨なことに。
・temp[j]=R[E[j]]（に相当するORビット演算）を
Before：48回
After ：R[32]中にある1の数（のwarp内の最大値）回
仮にwarp内に0xFFFF0000と0x0000FFFFというRを持つスレッドが混在していても、
通常なら32回ループのところを__ffs()を使えばwarp divergenceを起こすことなく
16回のループで終えられると思ったのに。
遅くなった原因として考えられるのは次の2つくらいだろうか。
１．__ffs()が単純に遅い （Intrinsic Functionなのに？）
２．ループ判定中の__ffs()が、コンパイラor実行ユニットの最適化を妨げた
さて__ffs()を使わず E[入力位置]==出力位置に1が入ったuint32 にしたことで
1割以上高速化されたのはなぜか。それはおそらくStoreの回数だと考えられる。
これまでのE転置だと1回ずつ1をセットすることになっていた。
新しいEの中身を見てみると（saltによって変化するが）内訳は、
オールゼロ：28個、ONビットが1つ：24個、ONビットが2つ：12個
となっており、Storeの回数のうち12/48を省略できたことが速度を改善したのではと。
ちなみに__ffs()を使ってE転置を行う場合、「出力位置を与えれば入力位置が得られる」
というこれまでの配列Eは使えなかったので↑のような配列を作ることになりそれを流用した。
他のは倍出ているような気がするのですが・・・・ドライバは最新のにしました。
Windows Vista Ult 64bitです
Q6600＠3.2GHzです。
> 他のは倍出ているような
他のとは何のことでしょうか(*‘ω‘ *)？
> おかげさまで念願の1MTrips/secに到達することができました。
よくわからんなぁ(*‘ω‘ *)
GTX480で１MTrips/sってこと？
Bitsliced-DES使わないで、wiz7はGTX460で1.5MTrips/s 出てたけど。
とあるボトルネックを解消できたら、その数倍は出そうな感じだったな(*‘ω‘ *)
なので、俺の感覚は
SHA-3がもうじき決まるし次のトリップ仕様でも検討しようずｗｗ
> SHA-3がもうじき決まるし次のトリップ仕様でも検討しようずｗｗ
ドラフトなり、叩き台なりつくってみれ(*‘ω‘ *)
1MTrips/sはGTS450 GDDR5-1GBでです。は全てこの環境です。
GTX4xx系や5xxにするとどのくらいになるかはわかりません。
occupancyが下がっても速度が変わらないのでメモリバウンドだとは思うんですが。
それと「GTX580を買わずに済んだ」とは書きましたが仮に俺が買うとしたら
cc2.1対応のGTX560tiですね。FermiシュリンクじゃないほうのKeplerまで待ちますけど。
【余談】
DirectXの10や11の序盤のチュートリアルでシェーダ言語が出てくることに驚く。
しかしCUDAのおかげで自分が理解できそうなこと・できなさそうなことの判別はできる程度に。
1ヶ月前なら*.fx/*.hlslファイルを見てもちんぷんかんぷんだったはず。
DirectX9でDrawPrimitive()していた頃とは隔世の感があるけど、
確かに行列積の計算をGPGPUで…じゃなくてGPUの本来の仕事として行えば
速度を落とさずに色々できそうだなぁと夢がひろがりんぐ。
ttp://kie.nu/14K cuda_sha1tripper-0.5.0_win32bin.zip -
ttp://kie.nu/14M 色々と見直して大量検索時の速度低下を抑えるようにしてみたのじゃが、
恩恵を受けるのは巨大なワードリストを読み込ませているようなケースぐらいかの。
それにキャッシュを当てにしておるから、Fermi以降で無いと厳しいかも知れぬ。
ソフトの方のバージョンも書いておいた方がいいと思いんす。
とりあえずGPU-Zや類似ソフトでクロックや負荷を確認かの。
AMDは次世代GPUを年内に投入という話が出ているみたいじゃが、
Keplerも近いうちに無事登場してくれるのか気になるの。
ttp://kie.nu/17s cuda_sha1tripper-0.5.1_win32bin.zip -
ttp://kie.nu/17t 変更は優先度を設定するのをやめたのと、コメント部分のミス修正ぐらいかの。
ローテートが無くてシフトが重いというのは厄介じゃの。
PTXにはbfiとかがあるようじゃが、それらを使うと多少はましになるのかの・・・
ちなみに64bitビルド。
ちゃんと工夫すれば800Mぐらいいくかな？
よくわかっていない者がダウンロード・実行して文句を言っても困るからの。
じゃがあのアップローダは一覧表示も無いようじゃから、その心配もあまりないかの。
Quadroとはまた凄いものを使っておるの。
SMが14基でクロックが1150MHzのようじゃからそれぐらいではないかの。
検索速度（MTrips/sec） / (SM数 * シェーダクロック（GHz）)
の値はCC 2.1では28〜30、CC 2.0では26程度になるのかの。
SMあたりのコア数が増えて加算や論理演算のスループットが上がったようじゃが
スレッド数も増やせておらぬし、あまり恩恵を受けられておらぬの・・・
そのパスワードってどこかに書いてあるの？
それとも身内用？
↑ ｺｺﾀﾞｲｼﾞ
その辺は既に試してみたんですが駄目でした。
が、今日もう1度見てみたところCookie要求されていたのに気付き・・・。
どもでした。
GTX260、280.26、toolkit4.0.17
完全一致で検索お願いします
ここに晒してください
このままではスリープしか出来ない。
【GPU】GTX 580 (950/2052/1900)
【CPU】Phenom II X6 1100T 3.30GHz
【OS】Windows 7 Ultimate SP1 64bit
【バージョン】CUDA SHA-1 Tripper MERIKEN's Branch 0.03 Beta 1
【オプション】-x 16 -c -g
【Display Driver】285.62
【速度】
846.75M tripcodes/s (average)
【その他】正規表現の英単語のリスト(前方一致2タゲ)
On average, it takes 14.6 years to find one match at this speed.
orz....
【GPU】GTS 450 GDDR5 1024MB@128bit(core810/shader1620/mem3608)
【CPU】Athlon II X4 640 3GHz
【OS】Windows 7 Professional SP1 64bit
【バージョン】CUDA SHA-1 Tripper 0.5.1（をx64＆sm_21でビルド。regは無指定の45(0.417%)）
【オプション】なし（デフォルトの 8blocks/SM。16にすると172MT/Sに)
【速度】 173.801 MTrips/sec
【その他】ターゲットは6文字のもの1つのみ
Device 0: "GeForce GTS 450"
Compute Capability revision number:2.1
Total amount of global memory: 993 Mbytes
Number of multiprocessors: 4
Number of cores: 192
Clock rate:1.62 GHz
バージョンが違いますがさんのGTX460と比較すると
173.8*(1.4/1.62)*(7/4)=262となって大体スペック通りでしょうか。
実は◆Horo/.IBXjcgさんのcuda_sha1tripperは
ソースを拝見させていただいていたものの、12桁トリを使うことが
なかったためビルド・実行は一度もしたことがありませんでした。
今日12桁トリを作りたくなったので使わせていただきました。
6文字トリが20分足らずで…改めてありがとうございます！
同じエラーが出て実行出来ない。
Quadro FX3800, WinXP 64bit
CUDA SHA-1 Tripper MERIKEN's Branch の
> On average, it takes 14.6 years to find one match at this speed.
ここいらの計算、9完以上だと間違ってるような気がする(*‘ω‘ *)
忙しそうだねメリケンさん
ﾁﾗｯと見た感じ足りないのは権限ぽいね。
Administratorとかで起動すれば動くかな？
検証も何もしてないのでこのカキコをあまり信じないように。ｗ
一応アドミン権限付きのアカウントで実行した。
別のＷin7マシンでは普通に動くんだけどなぁ。
書き忘れたけど、win7の64bit
XPってことだから権限関係かなと思った。
エラーコードを表示させるようになってないから、原因コードがわかんないんだよね。
あとは、.NET のなんとかがいるとか、ランタイムとかそんな話かな。
MSDNライブラリとかDependency Walkerとかで確認すればわかるかもしれないけど、今日はもう寝る。ｗ
↓開発者向け情報ｗ
ttp://support.microsoft.com/kb/238187/en-us プログラミングに全く時間がさけませんでした。
いろいろ報告していただいたのに返事が出来ず
申し訳ありませんでした。
さんに報告していただいたバグの件ですが、
お察しの通りCrypt APIの使い方を間違えたために発生したもので、
手元の開発版では既に修正済みです。クリスマス休みあたりに
まとまった時間が取れそうなので、近いうちに修正したバージョンを
うｐします。
気長に待ってます
CPU検索機能付きバージョンまだー(*‘ω‘*)？
ttps://github.com/chapuni/llvm-project を fork してみてくれー アーキテクチャについて早く知りたいですね。
Tesla→Fermiのときのようにレジスタが増えるとかシェアードメモリが増えるとか
夢だけは果てしなく広がるんですけどね。
完全に私事ですがDirectX/DirectComputeの勉強は全然進んでませんｗ
GTX 680が欲しくなって来ました。一時期7970を買おうかとも
考えてたんですけど、迷うところです。
900WのUPSを新調してひっそりとTripperの開発を再開したのですが、
無茶をさせすぎたせいかうちの580ちゃんは入院してしまいました。
正規表現の検索に結構大きなバグがあるみたいなので、
カードが戻ってくるまでソースを眺めることにします。
生きていたんですね・・乙！
どもども。本業で時間を取られすぎていただけなんですけど、もうちょっと時間をうまく
つかえるようになりたいですね。
さて、580ちゃんは帰って来ましたが、こんどはマザボがおかしくなってしまいました。
580の電圧を1100mVまで盛って930MHzまでOCしつつTripperを走らせてたら、
ブルースクリーンが出てWindows 7が立ち上がらなくなってしまいました。
インストール用のDVDすら動かないのでどうしようか悩んだのですが、
さいわいXPはまだ立ち上がるので、開発はXPで続けることにします。
皆さんもOCするときには気をつけて下さい。
GTX580を走らせているPCは娯楽用なので当分このままにしておいて、
夏になって時間ができたらマザボをGigabyteの3-way SLI対応のものに新調して
Windows 7をインストールし直す予定です。それまでにはもうちょっと開発が
進んでるといいなあ。
そしてついに発売されましたねKepler。
このスレとの関連度が高そうな順に以下GTX680の記事です。
【後藤弘茂のWeekly海外ニュース】 NVIDIAが次世代GPUアーキテクチャ「Kepler」のベールを剥いだ
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20120322_520640.html 西川善司の3Dゲームファンのための「NVIDIA Kepler」講座 - GAME Watch
ttp://game.watch.impress.co.jp/docs/series/3dcg/20120322_520598.html 4Gamer.net ― NVIDIA，「Kepler」ことGeForce 600ファミリーを発表。アーキテクチャの要点をまとめてチェック
ttp://www.4gamer.net/games/120/G012093/20120321043/ 4Gamer.net ― 「GeForce GTX 680」レビュー（前編）。低消費電力で「扱いやすい史上最速GPU」に
ttp://www.4gamer.net/games/120/G012093/20120320002/ 正直なところですが、思ったことを数点＋α。
(1)CUDA Coreあたりの性能は多少落ちるものの、より多くのCUDA Coreを
積めるようになった感じでしょうか。
だとすると、Tripperの性能追求という意味では歓迎すべき変化だと思います。
(2)後藤さんの記事にあるレジスタ数2倍というのが気になります。
＞また、Kepler SMXでは、レジスタ数は2倍に、インフライトで
＞制御できるWARP数は64WARPへと増やされている。
何あたりのレジスタ数を指しているのか次第ですが（SM→SMXで構造が変わってるので）、
文字通りの意味で2倍なら労せずして高速化が図れそうです。
（同時に今までのレジスタ消費のやりくりがさらっと水に流れそうですが）
(3)スケジューリングをGPU側（ハードウェア）からCPU側（ドライバ）で行うように
なったことについては、どの程度の性能のCPUならボトルネックにならずに済むかが
気になります。Athlon II 640で十分クリアできるといいのですが。
(4)個人的な話になりますが、買うとしたらGK106になりそうです。
SDKが出るまでは買ってもおもしろくないでしょうし、せっかく買うなら
GF104/GF106のようにcompute capabilityが一番先行してるのが欲しいのです。
(5)GTX680とは全く関係ないのですが、先日CUDA SDKを4.0から4.1に
クリーンインストールして、のをビルドしたら約800KTrips/secに落ちました…。
ビルドオプションなどをチェックしたものの現在に至るまで原因は不明。
の時点でバグがありそうな気もしています。
【occupancy100％を維持しつつ1スレッドが使えるレジスタ数】
GF1x0系の場合 32（ ＝32768/(32*32) ）
GF1x4やGF1x6の場合は20（ ≒32768/(48*32) ）
GK104の場合は10（ ≒65536/(192*32) ）
仮に1スレッドで20本のレジスタを使いたければ、occupancyが50％以下になると。
Whitepaper NVIDIA GeForce GTX 680 v1.0
ttp://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf GPGPUだとかなり微妙ですねえ。これは次の780を待ったほうがいいんでしょうねえ。
とりあえず580から搾り取れるだけ絞りとって、夏休みにはRadeon HD 7970を買って
Direct Computeに手を出してみようかしらん。
GPGPU目的の人はとりあえずKepler2待ちということで。
ttp://insidehpc.com/2012/03/22/nvidia-shows-off-first-kepler-gpus-pcs-first-server-gpu-coprocessors-in-q3/ Radeonは全くわかりませんが、HD7xxx(GCN)はGPGPU寄りになったらしい話は聞きますね。
コプロセッサ的位置付け(?)になって値段が跳ね上がるようなことが
ないことを祈ります。
SDKを4.1にした後でのを走らせると1割ほど遅くなってました。
何か共通してオプション(ビルドorCUDA環境)が変わってるのかもしれません。
【GPU】GTS 450 GDDR5 1024MB@128bit(core810/shader1620/mem3608)
【CPU】Athlon II X4 640 3GHz
【OS】Windows 7 Professional SP1 64bit
【バージョン】CUDA SHA-1 Tripper 0.5.1（をx64＆sm_21でビルド。regは45(41.7%)）
【オプション】なし（デフォルトの 8blocks/SM)
【速度】 155.031 MTrips/sec
【その他】ターゲットは6文字のもの1つのみ
Device 0: "GeForce GTS 450"
Compute Capability revision number:2.1
Total amount of global memory: 1024 Mbytes
Number of multiprocessors: 4
Number of cores: 192
Clock rate:1.62 GHz
あとcudaDeviceProp::totalGlobalMemの見え方も変わってます(993→1024MB)。
11月から変わったことといえばUSB3.0のカードを挿してることくらいか。
ちなみにregは無指定にすると51(33.3％)に。このとき150.0 MTrips/sec。
reg＝43(41.7％)を指定すると154.318 MTrips/sec。
個人的には1万2万で買えるビデオカードにも「ムダに」GPGPUの機能が盛り込まれている、
という状況が続いてくれるとありがたいんですけどね。
Kepler2はTesla用のようですね。さすがにTeslaには手が出せないなあ。
> To keep things straight between the PCs and the servers, El Reg had Gupta
> dub the one used in GeForce PC GPUs “Kepler1″ because it will have a different
> design from the one used in Telsa server coprocessors at the heart of
> a number of very large and powerful supercomputers later this year. We’ll call
> that one “Kepler2″, which will have a heavy dose of double-precision floating
> point processing as well as more memory, ECC scrubbing on the memory,
> different packaging aimed at servers, and a higher price tag.
向いていないのは明らかですね。論理演算が24/17クロックというのは厳しすぎる…
GTX680のグラフィック・GPGPU性能を調べる
ttp://dokumaru.wordpress.com/2012/03/27/gtx680-spec/ 最近はTesla2070cがヤフオクで10万以下で出てたりします。
もはやTeslaは世界中のGPGPUのデファクトスタンダードなので、
安くなるのも早いと思いますよ。
浮動小数点演算を使ってない限り、GK104はグラフィック寄りと言うより
GPGPUを捨てたと言いたくなりそうな変化ですね。
CUDA Coreあたりの性能が落ちるとは聞いていましたが、
まさか単純な部類（？）だと思っていた整数演算・ビット演算が削られるとは。
一番時間がかかっている転置処理でシフトを多用してるのに所要サイクル8倍とか…。
ただ商品としてはおそらくこっちの方向のほうが正しいんでしょうね。
ゲームはもちろんのこと、GPGPUという枠の中でもエンコードなどfloat演算が多くを
占める（？）処理では、coreが増える分パフォーマンスが上がると思いますし。
SLIしながらトリップ解析なんかしたら、画面重すぎてまともにPCいじれないからね〜
続けてれば今頃終わったかもしれないのに＞＜
Revision number: 1.0
Total amount of global memory: 320 Mbytes
Number of multiprocessors: 12
Number of cores: 96
Clock rate: 1.30 GHz
Device 1: "Quadro FX 4600"
Revision number: 1.0
Total amount of global memory: 768 Mbytes
Number of multiprocessors: 12
Number of cores: 96
Clock rate: 1.20 GHz
Use device 0, grid is 24 blocks
402651 kTrips in 4.781 sec - 84.219 MTrips/sec
これってシングルGPUしか使わないのかね？
古いバージョンは持ってるんだが、新しいのを試してみたい…
と素人考えの俺
Shaderを汎用的に使ってるのがCUDAだ
やったー！
ttp://kie.nu/iWq [SHA-1] ライセンス的に問題があれば削除します
ありがとうございます！
助かりました
ｲ｀ﾍ
/: :| ヽ
/ : :/ ヽ ＿＿＿ _,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡 /
( : : : : : : : : : : : : : : ｀ゝ /
マ r::/: /: : | : : : : : : : : ::＼ /
//: /: : : |: : | |: : |: _: : : :ヽ
ジ {/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
〉 ,‐-‐､｀|7 || |_::|,_|: : :|:::|: |
で ／ r:oヽ` /.:oヽヽ: :|: | :|
{ {o:::::::} {:::::0 }/: :|N
っ | ヾ:::ソ ヾ:::ｿ /|: : |
！？ ヽ::::ー-.. ／ヽ ..ー-::: ヽ::| r--ッ
-tヽ／´|｀::::::::::;／ `､ ::::::::::: /: i } ＞
::∧: : :|: |J ＼ ／ ／::i: | /＿ゝ
. ＼ヾ: |::|｀ - ,, ___｀-´_ ,, - ´|: : :|:::|
ヽ: |::|＼ ￣/ /| |: : :|: |
使用バージョンはCUDA_SHA1_Tripper_MERIKEN0.02
デフォ設定の7完で探すと平均約280MT/sで、GTX675Mの273MT/sとあんま変わらないなって印象
…と思いきや、ブロック数を設定できる中で最高の16に上げたら約290MTrip/sになった
やっぱりKeplerはクロックを落として数を増やして性能向上してるからなんだろうか
俺はただ使わせてもらってるだけのド素人だから、何か書き方がまずかったりしたらすまん
協力できることあったら、言ってもらえれば引き受けます
正しくないコードを後から同じように書くのは難しい。
もしくは同じコードを覚えていられる程度のコード量しかかけない著しくコードの生産性の低い人か。
そういうのに限ってサンデープログラマですら無かったりするんだし
忙しさにかまけて返事を怠ってしまい申し訳ありませんでした。
お詫びと言ってはなんですが、1年ぶりにCUDA SHA-1 Tripper MERIKEN's
Branchを更新しました。
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch 新しいバージョンは0.04 Alpha 1で、主な変更点はOSによっては起動
しなかったバグの修正と、10桁検索への暫定的対応です。最適化は全く
進んでいないので速度は期待しないでください。さんに報告して
いただいたバグはこれで潰されているはずです。
ようやく実習が終わって多少時間が取れるようになったので、
当分の間は10桁検索の最適化と、正規表現と検索時間予測の不具合の
修正に費やすつもりです。
Keplerでの報告は貴重なので助かります。ありがとうございました。
正直なところKeplerにしては意外に速度が出ているという感想です。
新しい開発版ではブロック数をもっと大きく設定できるので是非試して
みてください。
いずれKepler向けのコードも埋め込む予定で、そうすればもっと速度がでる
はずです。ただ、CUDA Toolkit 4.1と4.2を試してみたのですが、マクロを
乱用していた箇所でコンパイラが落ちてしまい、ビルドができませんでしたorz
うまく行ったらまたここでお知らせします。
移行したのでこちらの方の最適化も進めたいと思っています。
特にSLIへの対応は効果が大きいと思われます。
1.6T tripcodes/sぐらい出るんじゃないかと期待しているんですが…
CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Alpha 1
[compiled at 21:20:50 on Sep 1 2012 (PST)]
Copyright (C) 2009 ◆Horo/.IBXjcg
Copyright (C) 2011-12 ◆MERIKEN4.k
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
Using a GPU as a search device.
CUDA DEVICE
===========
Number of Available CUDA Devices: 1
Device: 0 ("GeForce GTX 460") with 7 multiprocessors at 1.400GHz
Compute Capability: 2.1
Number of Blocks: 56
Number of Threads: 128
TARGETS
=======
0: "TEST/"
TRIPCODES
=========
◆TEST/nmmV1F/ #紺TC6l9Q08ﾝﾃ (8d ae 54 43 36 6c 39 51 30 38 dd c3)
◆TEST/1bldoyp #｡ﾄﾀｨｳYﾊFuz0ｮ (a1 c4 c0 a8 b3 59
STATUS
Searching for 1 pattern (1 chunk) with 5 characters.
0.020T tripcodes were generated in 0d 0h 1m 36s at:
266.80M tripcodes/s (current)
206.64M tripcodes/s (average)
On average, it takes 3.6 seconds to find one match at this speed.
22 matches found at 817.93 matches/h and 0.91G tripcodes/match.
The actual matching probability is 18% higher than expected.
0% of matching tripcodes were invalid.
CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Alpha 1
CUDA DEVICE
Number of Available CUDA Devices: 1
Device: 0 ("GeForce GTX 460") with 7 multiprocessors at 1.400GHz
Compute Capability: 2.1
Number of Blocks: 56
Number of Threads: 128
CPU
Number of Processors: 8
Number of Search Threads: 7
TARGETS
=======
0: "TEST/"
TRIPCODES
=========
◆TEST/SGBBUqO #ﾁ2P甘ｻD6留｣q (c1 32 50 8a c3 bb 44 36 97 af a3 71)
◆TEST/BcBsMcw #踈sYn嬌ネ弑E (e6 f1 73 59 6e 9b 67 83 6c 9c 55 45)
◆TEST/LF4Jzpn #楾bﾝﾃｴｾ7．9o (9e b7 62 dd c3 b4 be 37 81 44 39 6f)
◆TEST/ptBTxW7 #ｻﾁｭ霈Qｲｷ釟QE (bb c1 ad e8 bc 51 b2 b7 e7 da 51 45)
◆TEST/mLcBOcY #Q閥ﾀDﾐｬｹｳQк (51 94 b4 c0 44 d0 ac b9 b3 51 84 7b)
◆TEST/OfJZabg #ﾑｵ浦NﾎﾀlN･ﾙﾞ (d1 b5 89 59 4e ce c0 6c 4e a5 d9 de)
Searching for 1 pattern (1 chunk) with 5 characters.
0.006T tripcodes were generated in 0d 0h 0m 25s at:
267.70M tripcodes/s (current)
GPU: 265.11M tripcodes/s
CPU: 2.59M tripcodes/s
236.92M tripcodes/s (average)
On average, it takes 3.1 seconds to find one match at this speed.
6 matches found at 859.98 matches/h and 0.99G tripcodes/match.
The actual matching probability is 8% higher than expected.
0% of matching tripcodes were invalid.
本当にお久しぶりです! 早速試していただいてありがとうございます。
妙にCPU検索が遅いなと思ったら、最適化するのを忘れていたみたいです…
今はなんとかToolkit 4.2でコンパイルできるようにコードをいじっているところです。
GTX 680 手元にあるからいろいろ試してみるか。
ぜひよろしくお願いします。
結局色々試したけどToolkit 4.2ではコンパイルできなかったので、
stackoverflowで質問してきました。
CUDA Toolkit 4.1/4.2: nvcc Crashes with an Access Violation
ttp://stackoverflow.com/questions/12239849 こんなエラーが出てたので、コンパイラのバグかコードが長すぎるかの
どちらかだと思うのですが…
1> Stack dump:
1> 0. Running pass 'Promote Constant Global' on module 'moduleOutput'.
1>CUDACOMPILE : nvcc error : 'cicc' died with status 0xC0000005 (ACCESS_VIOLATION)
コードが複雑すぎてどうやってもコンパイラのバグを回避するのは
難しいようです。あきらめてToolkit 5.0 RCをインストールする
ことにしました。
ttp://developer.nvidia.com/cuda/cuda-pre-production これでうまくいく事を願うのみです。
GTX 580で試してみたら20%ほど速度低下してしまいましたorz
仕方がないので当面の開発はToolkit 4.0で続けて、
Toolkit 5.0を使った6xxシリーズ向けのビルドは、
おまけとして配布パッケージに添付することにします。
あ、ありがとうございます。やっぱりそれぐらいですね。
GTX 580でもまだ20M TPSぐらいです。PTXでコードをごりごり
書きなおしてレジスタ数を減らして最適化する予定ですけど、
どうなるかちょっとわかりませんねえ。
カードなので、それまでは580ちゃんに頑張ってもらおうつもりです。
NVIDIA's Monster GPU for Tesla K20, 2013 GeForce and Quadro Cards
ttp://vr-zone.com/articles/nvidia-s-monster-gpu-for-tesla-k20-2013-geforce-and-quadro-cards/15884.html# 他ツールのCPU検索より高速になることを期待しております
といっても私は12桁が本命ですので現状で満足とかなんとか
mty_win_x64_20071012を試してみたら、
4.6GHzにOCしたCore i7-3770Kで20.2M TPSでした。
GTX 580とどっこいどっこいといったところです。
570でも同じぐらい速度が出せるようになるといいんですけどねえ。
もしかして10桁はSHA-1と違って低速なのでしょうか
CUDA化したら高速になるものだと思ってました
10桁検索は思った以上に遅いですね。またCUDA自体があまりDESの計算に
向いていないというのもあります。関連論文を漁ってみましたけど、
そこまで速度は出ていません。(に論文の引用があります。)
まあでも今回のはとりあえずBitslice DESをCUDAで動かしてみただけなので
速度は今後の最適化次第でしょう。
やはりそうですか。
しかしCPU+GPUで検索すれば良い速度になりそう。
MERIKEN's BranchのCPU検索はほとんどおまけですけど、
10桁ならmtyと組み合わせるなら多少は助けになるかも知れませんね。
なんにせよもうちょっと頑張りますです。
いえいえ、少しでも速くしたいのでCPU検索には助けて貰ってますよ。
機能も速度も十分なのですが、欲を言うと正規表現が惜しいというか。
12桁検索で後方一致にすると560M→100M未満になります。
CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Alpha 1
[compiled at 21:20:50 on Sep 1 2012 (PST)]
Copyright (C) 2009 ◆Horo/.IBXjcg
Copyright (C) 2011-12 ◆MERIKEN4.k
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
Using a GPU as a search device.
CUDA DEVICE
===========
Number of Available CUDA Devices: 1
Device: 0 ("GeForce GT 640") with 2 multiprocessors at 0.901GHz
Compute Capability: 3.0
Number of Blocks: 16
Number of Threads: 128
TARGETS
=======
0: "TEST/"
（途中省略）
STATUS
======
Searching for 1 pattern (1 chunk) with 5 characters.
0.029T tripcodes were generated in 0d 0h 5m 00s at:
98.15M tripcodes/s (current)
98.28M tripcodes/s (average)
On average, it takes 7.5 seconds to find one match at this speed.
33 matches found at 395.94 matches/h and 0.89G tripcodes/match.
The actual matching probability is 27% higher than expected.
6% of matching tripcodes were invalid.
あと -l 10 の10桁検索は2.8Mくらいでした
後方一致でも前方一致と同じ速度を出すことはもちろん可能なんですけど、
これ以上複雑にしたくなかったし需要もないだろうと思ったので
放っておいたんですよね。どれぐらいの手間で改善できるのかちょっと
調べてみます。
いえ、動作報告はいつでも参考になるので助かります。
640もKeplerコアですけど性能はGTX580の1/3弱なので、
Keplerコアだと同等のFermiコアに比べて検索速度は半分強といったところでしょうか。
レスありがとうございます。
優先事項というほどではないと思いますので、記憶の片隅にでも置いて頂ければ。
気づきましたｗ 使ったことなかったのですっかり忘れてた…
580 SLIの性能を試してみようと2個起動してみたのですが、全く問題なく
動いています。普段使っている正規表現のパターンで1.21G tripcodes/s出ているので、
OCしてパターンが一つだけなら1.6G TPSは固いでしょう。
2枚のグラボを隙間なしで設置しているせいか、下のカードは73℃なのに上のカードは
87℃まで温度が上がっています。OCしてないからこの間みたいに突然ヒートシンクが
膨張して物理的に壊れることはないだろうけど、ちょっと心配です。
その内に手を付けることになるとおもいます。できたらまたここ報告します。
どうもです。動作報告くらいしかできませんが、お待ちしております。
【GPU】NVIDIA GeForce GTX 580 2-Way SLI (OC: 960/1920/2104MHz)
【CPU】Intel Core i7-3770K (OC: 4.6GHz)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Alpha 2
【オプション】-x 48 -c -g; -x 48 -g -d 1
【Display Driver】305.60
【速度】 1659.26M tripcodes/s (GPU0+CPU: 863.75M; GPU1: 795.51M)
【その他】7完1タゲ。CPUの速度は約33.5M TPS。
さすがにこれだけ無茶するとシステムがかなり不安定になります。
ケースの電源をUPSにつないでようやく落ちないようになりました。
消費電力はシステム全体で730Wほどです。
省エネですね。
【GPU】グラボの買い時！ GTX 660Tiが2万5000円台に GTX 580より高性能で省電力
ttp://hayabusa3.2ch.net/test/read.cgi/news/1346739794/
電気代はアパートの管理会社が払ってるので問題ないんですけど、
自腹だとちょっと迷いますね。
ぜひ買ってTripperを試してみて下さいｗ
GUIは次のバージョンあたりで考えてます。
とりあえず今のバージョンを最適化して安定させるのが最優先です。
例: ◆TEST/zXiSQ #ﾊ楳彦ｨg銃F (ca 94 80 95 46 a8 67 8f 65 46)
したらばでは使えたので、2chとしたらばのトリップの仕様の違いを
調べればすぐにこのバグは潰せるとは思うが、しかしこんなのが
残ってるとはなあ…
自分で調べ上げたい、というのでなければここに書いてあったり。
ttp://sourceforge.jp/projects/naniya/wiki/2chtrip まあ、ここの情報もすでに古くなってるんだが。
いろいろ変わったしな。
あ、ありがとうございます! そういえばこんな話もありましたね〜
早速手直ししてテストしてるところです。
どうせseedあたりだろうとぼんやり見当はつけてたのですが、
詳しいことはすっかり忘れていました。
Bitslice DESの最適化に取り掛かりました。
S-Boxをレジスタの使用を最適化しながらPTXの命令で書き直しています。
一年ぶり()の作業ですけど相変わらずめんどくさいです。
2時間かけて5番目のS-Boxの最適化を完了して、テストも問題なく終了。
あと3つ残ってるので約6時間か〜
PTXアセンブリへの変換は使用するレジスタ数を減らすために
やっているんですが、手作業によるレジスタ割り付けの最適化の副作用で
検索速度もびみょ〜にはやくなっています。
やはりCUDAのコンパイラは相当最適化をサボっている模様。
これ、Bitslice DESのゲートの情報から直接PTXのコードを
機械的に生成してやったら相当速くなるんでしょうねえ。
Win8 64bit評価版でも0.04 Alpha 1動きましたので報告しておきます
＃環境書き忘れてましたが688はWin7 SP1 64bitでドライバ306.02βでの結果です
Win8ではGT640もOS標準ドライバで認識されてWin8標準ドライバは302.86相当のようですが
Win8標準ドライバではGPU検索できませんでした
で306.02βはWin8にも対応してるのでそのまま使ったところ688とほぼ同じ結果になりました
（デフォルト設定で12桁GPU検索：約98M・10桁GPU検索：約2.8M）
他の3DベンチとかでもWin7 SP1 64bit + 306.02βとWin8 64bit評価版 + 306.02βで
ほとんど同じ結果になりましたので
Win7 SP1 64bitとWin8 64bitは（同じドライバが使えれば）特に性能差はない感じです
あと -x 32 にすると12桁GPU検索が約107Mくらいまで上がりました
それ以上にしてもGT640ではほとんど変化ないみたいです
CUDA/OpenGL/OpenCLとかMSが関与してない部分はアウトなはず
ありがとうございます。ドライバの件は盲点でした。README.txtに追加しておきます。
-xは自動的に最適な値を設定するようにしたいんですけどね〜 今後の課題です。
さっきようやく7番目のS-Boxの最適化が終わりました。
ようやくあと1個です。はたしてどうなることやら…
それとは別に普段のトリップ検索を裏で続けることができるので
すごく便利です。安いのでいいからはやく2枚目をかっておけばよかった…
Max Register Countを32に設定すると、相変わらず著しい速度低下が
見られましたorz
仕方がないのでMax Register Countを0にしてプロファイラで調べてみたら、
registers per threadは37でした。手作業での最適化の前はレジスタ数は63で
lmemへのregister-spillingは4 bytesだったので、最適化は相当な効果が
あったようですが、あと一歩足りなかったようです。レジスタ数を32まで下げられれば
Occupancyは上がるはずですが、カーネルの構造を見なおさなければいけないので
悩ましいところです。
元祖CUDA SHA-1 Tripperは使えるんですが、MERIKEN`s BRANCH版が使えません。
スペックが足りないからでしょうか。
Intel CORE i7
nVIDIA GEFORCE 540M
ドライバは対応バージョンになってる？
あとVC++2010ランタイムが入ってないとか？
入ってなければ↓からvcredist_x86.exeをダウンロードしてインストール
ttp://www.microsoft.com/ja-jp/download/details.aspx?id=26999 VC++2010ランタイムかもしれませんね。
Win32アプリケーションだから大丈夫だと思ったんだけどなあ。
OSはなんですか? あと起動した時に出るメッセージも教えて
もらえると助かります。コマンドプロンプトから起動すれば
もうちょっと詳しいことがわかるかもしれません。
あ、書き忘れてたけどスペックは全く問題ないはずです。
もうちょっと手元のテストする環境を増やしたほうがいいのかな…
すっかり忘れていました。1ブロックあたりのスレッドの数が128なので、
1スレッドあたり6144/128=48 bytes使えることになります。
単純に計算すればレジスタに割り当てられているローカル変数を12個
共有メモリに押し出せるはずですが…
全く速度が上がらないのにMemory Clockを挙げたら検索が早くなることが判明。
12桁検索と全く違うパターンなので非常に興味深いです。
やっぱメモリの使い方も見なおさないと駄目か…
480 bytes使っているのが速度があまり出ない原因になっているみたいです。
ここは1年前にかなり頑張って削った部分で、Bitslice DESの特性上これ以上
減らすのは難しいようです。やはりレジスタの数を減らしてoccupancyを
上げるしかないですねえ。
Theoretical Occupancyを0.67まで上げたのですが、
スピードは前のままでした。
やっぱりローカルメモリへのランダムアクセスが足をひっぱっているのかなあ。
> Occupancy Analysis for kernel CUDA_PerformSearching_DES on device GeForce GTX 580
>
> Kernel details: Grid size: [128 1 1], Block size: [128 1 1]
> Register Ratio: 1 ( 32768 / 32768 ) [31 registers per thread]
> Shared Memory Ratio: 1 ( 49152 / 49152 ) [6144 bytes per Block]
> Active Blocks per SM: 8 (Maximum Active Blocks per SM: 8)
> Active threads per SM: 1024 (Maximum Active threads per SM: 1536)
> Potential Occupancy: 0.666667 ( 32 / 48 )
> Occupancy limiting factor: Registers , Shared-memory
Blitslice DESで使っている変数を全部共有メモリに押し込むのも
ありなのかも… ちょっと試してみよう。
う〜ん、完全に煮詰まったので10桁検索の最適化はしばらく置いておこう。
1つのプロセスで複数のGPUをつかって検索できるようになりました。
GPUのルーチンを書いてた頃は複数GPUへの対応は考えていなかったので
thread-safeにするのにちょっと手間取りましたが、CPU検索に対応したときに
マルチスレッド化していたおかげでかなり楽ができました。
奮い立ってますか！
あ、どもども。ありがたくいただきます。まあ予想してたとはいえ1G TPSを普通に
出せるようになるとテンション上がりますよねｗ
【GPU】NVIDIA GeForce GTX 580 2-Way SLI (OC: 940/1880/2104MHz 1100mv)
【CPU】Intel Core i7-3770K (OC: 4.6GHz 1420mv)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Alpha 2
【オプション】-x 48 -c -g
【Display Driver】305.60
【速度】 1689.88M tripcodes/s (sustained average speed for 10 minutes)
【その他】7完1タゲ。CPUの速度は約32M TPS。
検索スレッドの割り当ての方法を調整したのでより多少速度が上がっています。
ただ、効率が良くなったせいかOC耐性はかえって低くなってしまいました。
幾つグラボがあっても対応できるようにしておいたので、グラボを積めば積むほど
速くなります。後もう1枚580を追加するか580を1枚590と入れ替えれば
2G TPSも問題なく出せるはずです。
は(*‘ω‘ *)？
お、お久しぶりです。
無茶させすぎると検索に引っかからなくなります。
まあ200万パターンなんて普通の使い方ではありえないんだろうけど
いまいちすっきりしません。
確か前に試したときは大丈夫だったんだけどなあ。
こりゃ当分の間は正規表現検索のバグ取りと最適化ですね。
全数検索できなかったバグは修正できました。
10桁検索に対応した時に紛れ込んでいたみたいです。
結果はこんなかんじです。
> TARGETS
> =======
> 0: "[:digit:][:digit:][:digit:][:digit:][:digit:][:digit:][:digit:][:digit:][:
digit:][:digit:][:digit:][:digit:]" (regex)
>
> TRIPCODES
> =========
> ◆753780980947 #Lb豹ｵｨ5mﾉ5Sﾌ (4c 62 95 5e b5 a8 35 6d c9 35 53 cc)
> ◆390605178955 #輩｣ﾙ俐ﾈ7zV壷 (94 79 a3 d9 98 dc c8 37 7a 56 92 d9)
> ◆689789333040 #tjﾄx檪迎踞濮 (74 6a c4 78 9f 4b 8c 7d e6 f5 e0 60)
> ◆583596611640 #ﾊﾍざx/駝ﾁｵп (ca cd 82 b4 78 2f e9 6b c1 b5 84 81)
> ◆485900195723 #祢5ｧ餓f7祟驗 (94 49 35 a7 89 ec 66 37 e2 4d e9 84)
>
> STATUS
> ======
> Searching for 100000 patterns (100000 chunks) with 12 characters.
> 0.023T tripcodes were generated in 0d 0h 0m 40s at:
> 556.41M tripcodes/s (current)
> 562.35M tripcodes/s (average)
> On average, it takes 5.3 seconds to find one match at this speed.
>
> 5 matches found at 448.97 matches/h and 4.51G tripcodes/match.
> The actual matching probability is 5% higher than expected.
> 0% of matching tripcodes were invalid.
近いうちに修正したバージョンをあげるので是非試してみて下さい。
問題の再現はできませんでした。やっぱりで指摘されたように
発見確率の計算をどこかで間違っているのかしらん。
8完以下も9完以上も同じように計算してるのでちょっと考えにくいんだけど。
・後方一致検索の高速化。
・検索アルゴリズムとブロック数の動的設定。
とりあえず前者をやることにします。
8完以下は調べてないからわからない(*‘ω‘ *)
なので、より正確に言うなら「ここいらの計算、”少なくとも”9完以上だと間違ってるような気がする(*‘ω‘ *)」かな
真面目にやろうとすると検索ルーチンの最深部まで手を入れなきゃいけないので
結構緊張します。とりあえず12桁のCPU検索とGPU検索の作業は終わりました。
思ったより順調だけど、残りはどうなることやら。
なるほど、そうですか。後で確率計算の部分を見なおしてみます。
ターゲットが短い場合はちゃんと合っているのでなかなか難しいところですが…
TRIPCODES
=========
CUDA_SHA-1_Tripper_MERIKENs_Branch: CUDA FUNCTION FALL FAILED: the launch timed
out and was terminated (line 637)
STATUS
======
Searching for 7 patterns (7 chunks) with 7 to 8 characters.
0.571T tripcodes were generated in 0d 0h 39m 14s at:
3.17M tripcodes/s (current)
GPU: 0.00M tripcodes/s
CPU: 3.17M tripcodes/s
242.31M tripcodes/s (average)
On average, it takes 1.1 hours to find one match at this speed.
No matches were found yet.
一応トリップ総合ページだと思ってたんだが。
OS替えました? ひょっとしたらこれかもしれません。
CUDAカーネル実行のタイムアウト
ttp://imd.naist.jp/~fujis/cgi-bin/wiki/index.php?CUDA%A5%AB%A1%BC%A5%CD%A5%EB%BC%C2%B9%D4%A4%CE%A5%BF%A5%A4%A5%E0%A5%A2%A5%A6%A5%C8 このサイトならちゃんと見れますよ。
ttp://trip2ch.net/
今10桁CPU検索のテストをしているところです。
しかしCPU検索の遅いことといったらないです。
全然最適化していないとはいえ、速度がmtyの8分の1というのは酷すぎる。
OpenCLへの移植を考えているので出来ればあまり手を付けたくないんですけど、
気が向いたらamd64への最適化をするかもしれません。
mtyのGPU版の10桁検索の速度は今考えると異常ですね。
でもあれはCALで書かれていてOpenGLではなかったはずです。
で、CALはサポートされなくなったのでmtyはHD 7xxxシリーズでは動かないと
聞きました。12桁検索は公開されているプログラムがないのでなんとも
いえませんねえ。
なるほど
とりあえず年末と言われてるGTX7XXの巻き返しに期待かな
NVIDIA以外のデバイスを使おうと思ったらOpenCLで書くしかないですからね。
780はほんとうに楽しみです。思い切って790を買うかもしれません。
12桁検索は確実に速くなるでしょうね。10桁はメモリ周りが見直されないと
厳しいかなｗ
もうちょっと手を入れれば前方一致検索と同じ速度を出せますけど、
とりあえずここらへんまでにしておきます。
後方一致検索が行われているときには
"Performing a backward-matching search"と表示されます。
ターゲットはすべて$で終わっている必要があるので注意して下さい。
今日か明日に新しい開発版をうｐします。
> TARGET(S)
> =========
> 0: "//TEST$" (regex)
>
> TRIPCODES
> =========
> ◆bBFuMr//TEST #瞥ﾕM珱ﾎR齎嵩 (95 cb d5 4d e0 fc ce 52 e6 d8 90 93)
>
> STATUS
> ======
> Performing a backward-matching search for 1 pattern (1 chunk).
> 0.082T tripcodes were generated in 0d 0h 1m 00s at:
> 1360.77M tripcodes/s (current)
> GPU: 1328.75M tripcodes/s
> CPU: 32.02M tripcodes/s
> 1354.37M tripcodes/s (average)
> On average, it takes 34.7 seconds to find one match at this speed.
>
> 1 match found at 59.54 matches/h and 81.89G tripcodes/match.
> The actual matching probability is 16% lower than expected.
> 0% of matching tripcodes were invalid.
ttp://ra8.s31.xrea.com/ut.html ーc−ｇで死亡
ーｇならおｋ
STATUS
======
Searching for 7 patterns (7 chunks) with 7 to 8 characters.
4.285T tripcodes were generated in 0d 4h 30m 14s at:
263.82M tripcodes/s (current)
264.26M tripcodes/s (average)
On average, it takes 1.1 hours to find one match at this speed.
2 matches found at 0.44 matches/h and 2142.46G tripcodes/match.
The actual matching probability is 48% higher than expected.
33% of matching tripcodes were invalid.
結構いろんな人が検索プログラムを作ってますよね。libdesは確か
Bitslice DESじゃなかったのでスピードはあまり出なかった記憶があります。
-gだけで大丈夫なら電源関係かもしれません。システム全体に負荷をかけると
結構電圧が不安定になったりします。
CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Alpha 2
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch 今回の変更点は以下になります。
・10桁トリップ検索の不具合を修正。
・正規表現検索の不具合を修正。
・後方一致検索を高速化。
・複数のGPUへの対応。
あとおまけでGT/GTX 6xxシリーズ用にCUDA Toolkit 5.0でビルドしたものも
付けておきました。うまく動くかどうかわかりませんが、是非試してみて
下さい。
後方一致の迅速なご対応ありがとうございます。
通常の前方一致検索とほぼ同等の速度が出ました。
otu
それはなによりです。ターゲットの数が多ければ多いほど効果は大きいでしょうね。
いままでいかにさぼってたか分かってしまいますがｗ
最適化の処理をGPU検索スレッドに丸投げすることにしました。
最初は親スレッドでまとめてやろうかと思っていたのですが、
収拾がつかなくなりそうだったので止めました。
方針は決まったので後はガリガリコードを書くだけです。
まずブロック数の自動設定から片付けることにしよう。
いつもお世話になっています。
CUDA5の6xx版はまだまだパフォーマンスを引き出せない感じですね。
設定を詰めても平均260MT/sあたりしか出ません。
そして従来向けの非6ｘｘバージョンだと、ブロック数を192(KeplerのSMXあたりのCUDAコア数)にしたら
GPU単体平均で300MT/s超え、瞬間で320MT/s以上は出てました。
ここらへんの結果は後ほどコピペします。
ちなみにこの時表示は"1344blocks per SM"(GTX680Mは7SMXなので掛け算されてる？)になっています。
"***blocks per SM"の値を192に近づけるために
指定27ブロック、189blocks per SM表示でも試してみたのですが
指定192ブロック、1344blocks per SM表示の状態の方が明らかに速かったので
この表示はSMX単体に対してではなくGPUコア全体に対するブロック数のようですがどうなのでしょうか。
私の認識が間違っていたらすみません。
うーん、やぱりToolkit 5.0でビルドすると性能が出ないですね。
今はいいけど780あたりが出るまでには治っているといてほしいものです。
たしかにKeplerはコア数が多いので-xの値を大きくしたほうがいいですね。
もうちょっと大きくしてみてもいいかもしれません。
> この表示はSMX単体に対してではなくGPUコア全体に対するブロック数の
> ようですがどうなのでしょうか。
これはうっかり表示を間違えていました。申し訳ない… 早速直しておきました。
いずれにせよこれはかなり興味深い報告です。有難うございました。
早速の対応ありがとうございます。
今色々なブロック数を試行している最中ですので結果はもうしばらくお待ちください。
あとCPUとGPUの並列で動作させていて気になったことを一つ。
ご存知かもしれませんが、KeplerからはGPUへの命令の一部をCPUが演算するように制御が変更されています。
(参考：
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20120322_520640.html そしてこれはGPUが強力になればなるほどCPUの負担も増えるはずです。
(私のような素人の考えですので間違っているかもしれませんがｗ)
ちなみにGTX680M単体検索時のCPU負荷は12%＠2スレッド使用となっていましたので、
これに加えてCPUでも検索をかけるとどこかに無理は来ているはずです。
ですので、現状ではCPU+GPU検索時には論理CPU数-1スレッドで検索していますが、
もしかしたらCore i系CPU+KeplerGPUのシステムでは、2スレッドくらい空けた方が
それほど速度低下もなく全体として安定動作するかもしれないんじゃないかとも思いました。
CPUが検索に使うスレッド数を指定するオプションがあればそこら辺も実験できるのですが、追加は無理でしょうか？
新参のくせにいろいろ要求してしまってすみません。
sage保存のためにカキコしときます、すみません。
わかりました。じゃあそのオプションも追加しておきます。
＞GTX680M単体検索時のCPU負荷は12%＠2スレッド使用となっていました
トリッパーへのCPUスレッド割り当てを1スレッドに変更して見てみると、
トリッパーが1スレッド100%使用して100/8≒12%となっていました。
この数字がトリッパー単体がリソース消費しているのか
GPU制御まで含めての数字なのかは自分の勉強不足でわかりません。
ありがとうございます。
こちらも一番いい設定を見つけ出してみます。
-x 8 659.83M TPS
-x 16 676.21M TPS
-x 24 679.08M TPS
-x 32 680.79M TPS
-x 48 683.01M TPS
-x 64 683.46M TPS
-x 96 685.81M TPS
-x 128 686.29M TPS
-x 192 686.90M TPS
-x 256 684.66M TPS
基本的に◆Horo/.IBXjcg氏のの方針の延長で-xを扱ってきたので、
この結果はかなり意外です。もうちょっと色々試して見ればよかったな。
自動設定はこのリストの値を順番に試していって最速のものを
選ばせるようにしよう。
CUDA DEVICE
===========
Number of Available CUDA Devices: 1
Device: 0 ("GeForce GTX 460") with 7 multiprocessors at 1.400GHz
Compute Capability: 2.1
Number of Blocks per SM: 56
Number of Threads per Block: 128
CPU
===
Number of Processors: 8
Number of Search Threads: 7
TARGET(S)
=========
0: "Trip.."
TRIPCODES
=========
STATUS
======
Performing a forward-matching search for 1 pattern (1 chunk).
0.006T tripcodes were generated in 0d 0h 0m 19s at:
291.60M tripcodes/s (current)
GPU: 270.13M tripcodes/s
CPU: 21.47M tripcodes/s
291.60M tripcodes/s (average)
On average, it takes 2.7 minutes to find one match at this speed.
No matches were found yet.
ちゃんと動いているみたいですね。よかったよかった。
電源については、このプログラムがPCにかなり無茶させているような気もしますけど…
普段運用するときにCPU検索を切っておけば大丈夫だと思います。
さっきのはCPUとかドライババージョン書いてなかったですけど
CPUはCore i7 3820QM(Ivy、2.7-3.7GHｚ、4C8T)
GPUドライバは306.02β、CUDAドライバは5.0.1を使ってました。
まぁそれだと日頃やってるゲームで不具合出ちゃうんで
CUDA5.0はまだまだ未熟なようだし302.71、CUDA4.2.1に戻しました。
ベンチはとりあえず後者で統一してみます。
しかしこのPC買って間もないんですが最近のノートって速くなりましたねぇ。
CUDA 5.0はRCだから性能は当分このまんまでしょうねえ。
実は10桁検索は15%ほど速くなるんですけど、12桁が遅くなりすぎです。
これ、趣味じゃなくて本職の人達は相当困ると思うんですけど…
680Mは結構速いですよね。自分も本業ではほとんどノートしか使いません。
いけなくなったので、10桁検索の処理のループの回数を大分減らして軽くしました。
目立った速度低下は見られないのでこれでよしとします。
なんか本当にvoodooの様相を呈してきたけどいいのかしらん。
今後が楽しみですが、Keplerはなかなか厳しいですねえ・・・
Kepler2とも呼ばれているらしいGK110の内部がどうなるのか気になりますね。
GTX780は値段が凄いことになりそうですけど・・・
メモリアクセスがネックになるというのは消費電力の面でも避けられると良いですが、やはり難しいのでしょうかね？
Keplerちゃんはわりと頑張っているという印象です。680Mで300M TPS出るんなら
680なら450M TPSぐらいいくんじゃないでしょうか。の記事を見たときには
＼(^o^)／ｵﾜﾀと思ったものですが…
今まで出てきた情報を見る限りではGK100を使えば検索速度が速くなることは
間違い無いでしょう。値段がどうであれ私は必ず買います!
10桁検索はBitslice DESを使っている限りメモリアクセスで足を引っ張られる
でしょうねえ。変数を全部レジスタと共有メモリに全部押し込められるような
やり方が見つかればいいんですけど…
うーん、無理やりできなくも無いですけど、今の10桁検索の速度で
需要はあるんでしょうか…
うーん、このツールの12桁検索と他のツールの10桁検索を併用する方がいいかもしれません。
失礼しましたm(_ _)m
いや、GTX680だと多分めちゃくちゃ伸びると思います。
GTX680Mって実質GTX670のダウンクロック版ですしね
GTX680はGTX680Mに比べて
CUDAコア：7SMX=1344→8SMX=1536 1.14倍
最大コアクロック：720→1058 1.47倍
最大メモリ帯域幅：115.2→192.2 1.67倍
ちょっとうちの680MをOCして試しに回してみますわｗ
0.04 Alpha 2を同じ環境（Win7 SP1 x64 + 306.02β）で試してみましたが
通常版の方は0.04 Alpha 1とほとんど同じでオプションを何も付けないデフォルトで12桁GPU検索約98M、
GT640では -x に大きい数値を入れてもあまり変化ないですが試しに -x 192 にしてみると約105Mでした
CUDA Toolkit 5.0版の方はデフォルトで約90M、-x 192 で約95Mでした
10桁GPU検索はたしかにCUDA Toolkit 5.0版の方が速くて（といってもGT640では元の数値がしょぼいですが）
通常版で約2.8MのところがCUDA Toolkit 5.0版だと約3.3Mくらいになりました
GTX680M
コア720→835MHｚ (AfterBurnerの限界)
まだ設定が見えてこないので-x 192のままで検索
GPU単体で5分検索してみた結果
Max：352.3GT/s
Ave：350.5GT/s
この結果からもクロック1.16倍に対し平均速度は1.17倍と順当に上がってるので
の結果をもとにざっくり試算すると495GT/sあたり行くんじゃないかと。
まぁ単純に倍にはできないかもしれないですが、それでも400台後半は出ると思います。
しかもこれまだ設定詰め切れてない状態なんでもうちょい伸びるかも？
うちしょぼい環境（取り付けてるPCがG41なのでPCIEも1.1動作）と比べるのはアレかも知れませんが
GT640（2SMX=384・コア900M）で -x 192 で12桁GPU検索平均約105Mだったので
1344/384 * 720/900 = 2.8
平均約300M / 平均約105M = 2.857
と考えれば
12桁GPU検索だとメモリ帯域（GT640はDDR3なのでたった28.8GB/s）はあんまり関係なくて
GTX680だと約500M近い数値出そうですね
なるほど
確かにそれから見ると単純にコア数とクロックに対してリニアに伸びていきそうですね。
OCしたときの伸び方は分かってもSMX数がどこまで効くのかはわかってませんでした。
しかしKeplerでのオプションは順当にコア数通りの192が最適な気がしなくもない…。
確かに256とかにすると最大瞬間風速は出るけど速度のブレが激しいというか。
つーか忍法帖不具合でリセットかよ
無能運営とプログラマめ…
680Mが300M TPSだとする680は
300 * (8/7) * (1058/720) ≒ 503.8M TPS
ぐらいになる計算ですね。この場合メモリは全く関係ないはずです。
-x 192で1タゲだと定格の580では680M TPS出るので26%の速度低下ですけど、
ビット演算やシフト演算が致命的に遅いのにこれぐらいで済んでいるのは
やっぱりCUDA coreの数が多いからなんでしょうね。
一晩置いた結果に疑問点があって今まで観察していたのですが
ちょっと発見したことがあります。
-xでの指定ブロック数＞“Number of Threads per Block”(=128) の時
→スコアが20秒ごとに上下する、差が大きいほどそのバラつきは大きい
例：-x 256の場合、最大306GT/s、最低281GT/s、-x 192の場合最大300GT/s、最低286GT/s
バラつきがある分、一発の速度は出ても長く動かすと平均は下がり約294GT/sに収束する
“Number of Threads per Block”(=128)≧-xでの指定ブロック数 の時
→スコアの上下は小さい。安定してスコアが出るが最大も低いので平均は293GT/s
というように、現状ではブロック数を上げても長い目で見ると速度向上にはつながっていません。
(今までの報告は、ちょこっと動かしただけだったので見逃したようです、すみません)
自分は直感でしか言えないんですが、Keplerの膨大な数のコアを活かすためには
“Number of Threads per Block”を変更したほうが良いのかなと。
ただ、過去ログを読んだ限りではなかなか厳しそうですね…。
スレッドの数を増やすのは-xの値を増やすのと効果はほとんど変わらない
はずです。-xの値を増やすと速度の測定値が上下するのは、1回のCUDA関数の
呼び出しで処理されるトリップの量が増えるので、その分だけ測定値が
不正確になるからです。
またスレッドの数には大きな制約があって、CUDAのアーキテクチャの都合で
スレッドの数は32の倍数にするのが一番効率がいいことになっています。
興味が有るのならこちらを是非どうぞ。
NVIDIA GPU の構造と CUDA スレッディングモデル
ttp://www.softek.co.jp/SPG/Pgi/TIPS/public/accel/gpu-accel2.html なるほど、currentの数値に関してはそこまで気にしなくてもいいということですね。
あと資料ありがとうございました。
Warpの概念というのも知りませんでしたし、ここまで踏み込んだもの
(と言ってもプログラミングをされる方なら基本のレベルなのかもしれませんが)は
今まで見たことが無かったので、読み進めるだけでも頭がパンクしそうでしたが
CUDAコアはCPUよりもずっと並列動作向けに作られているんだなぁということはわかりました。
本当に抽象的にしか頭に入ってませんが…ｗ
今ちょうど休暇中なのでゆっくり勉強していきます。
資料を読んだりしながら動かしたので本来より多少数値は下がってるかもしれません。
CUDA DEVICE
===========
Number of Available CUDA Devices: 1
Device: 0 ("GeForce GTX 680M") with 7 multiprocessors at 0.719GHz
Compute Capability: 3.0
Number of Blocks per SM: 1568
Number of Threads per Block: 128
TARGET(S)
=========
0: "GTX680M"
STATUS
======
Performing a forward-matching search for 1 pattern (1 chunk).
0.504T tripcodes were generated in 0d 0h 28m 27s at:
308.05M tripcodes/s (current)
295.41M tripcodes/s (average)
On average, it takes 2.8 hours to find one match at this speed.
No matches were found yet.
CUDA DEVICE
===========
Number of Available CUDA Devices: 2
Device: 0 ("GeForce GTX 680") with 8 multiprocessors at 0.705GHz
Compute Capability: 3.0
Number of Blocks: 512
Number of Threads: 128
TARGETS
=======
0: "TEST/"
TRIPCODES
=========
STATUS
======
Searching for 1 pattern (1 chunk) with 5 characters.
0.046T tripcodes were generated in 0d 0h 1m 30s at:
509.21M tripcodes/s (current)
507.76M tripcodes/s (average)
On average, it takes 1.5 seconds to find one match at this speed.
36 matches found at 1437.80 matches/h and 1.27G tripcodes/match.
The actual matching probability is 11% lower than expected.
5% of matching tripcodes were invalid.
あ、あのリンクはもし興味があれば、というつもりで貼ったので…
グラボのプログラミングはかなり特殊なのです。
224が最適だとすると、ブロック数の自動設定はもうちょっと
細かくしたほうがいいかもしれませんね…
とうとう680での報告ですね。ありがとうございます。
CUDAデバイスの数が2となっていますけど、これはSLIですか?
それともPhysX用にもう一枚別のカードが入っているんでしょうか。
なんにせよ、大体予想した速度と同じぐらいで安心しました。
やはりハイエンドのカードではそれに見合う数字が出て欲しいですからね。
もう1枚は画面表示用のQuadro 2000で、680をGPGPU専用にしています。
自分の680Mではブロック数を上げ過ぎると30分平均で見ても少し速度は落ちてました。
といっても2〜3MT/sくらいの差ですけどね。
動く上限自体は320くらいで、そこから32ブロックごとに減らして様子を見てみてました。
そしてその224ってのがKeplerのどれでも最適かというと疑問なんですよね。
1SMX=192コアなのはどれも同じだけど、GPUクロックとかSMX数によっても頭打ちが変わってきたりしないのかなと。
あ、なるほど。本職の方でしたか。それならばその構成も納得ですね。
もしよろければQuadroでも試してみて下さいｗ
詳しく調べて頂いてありがとうございました。
カードによる差は、実行時に速度を測定しつつ自動的にブロック数を調整させることで
対応していく予定です。
今日突然、
|
＼ __ ／
＿ （ｍ） ＿ﾋﾟｺｰﾝ
|ミ|
／ ｀´ ＼
('A`)
ノヽノヽ
くく
と上手い考えが閃いて、大きな進展がありました。
そのままなんですが、次の点を変更してやりました。
(1) 1回のBitslice DESの処理に8個のスレッドを割り当てて、
8つあるS-Boxを同時に処理させる。
(2) 共有メモリのバンクコンフリクトを避けるために、
ダミーの変数ｗを構造体に追加する。
(1)は並列性を高めるといういかにもGPGPU的なやり方なんですが、
(2)は行き当たりばったりもいいところでvoodoo(黒魔術)の感さえありますｗ
> STATUS
> ======
> Performing a forward-matching search for 1 pattern (1 chunk).
> 0.004T tripcodes were generated in 0d 0h 0m 50s at:
> 84.50M tripcodes/s (current)
> 85.74M tripcodes/s (average)
> On average, it takes 8.7 seconds to find one match at this speed.
>
> 2 matches found at 143.33 matches/h and 2.15G tripcodes/match.
> The actual matching probability is 50% lower than expected.
> 0% of matching tripcodes were invalid.
580 SLIをOCしてこれなのでRadeon用のmtyと比べると相当しょぼいのですが、
それでもなどと言われてた頃に比べると相当の進歩ですｗ
早速ノート用のOCメモリ(DDR3-1866 CL=10 1.5V)注文しちゃいました。
まぁ大きく上がるとは思えないけど最後の手段で…。
ないかと思われますｗ まだプロファイラにはかけてないので、
今後はプロファイリングの結果を見ながら、共有メモリのバンクコンフリクトを
減らしたり、Occupancyを増やしたり、レジスタの割付を変えてみたりして
最適化を進めたいと思います。最初の目標だった580単体での100M TPSは
難しいだろうけど、それに近い数字が出るといいなあ。
うーん、どうでしょうねえ。CPU検索は確実に早くなると思いますけど…
しかし私が言うのも何ですけど、なかなかはまってますね。
気づいたらグラボ満載のPCを組み立てているかもしれませんねｗ
人のことは全く言えないんですけどね… 780/790まで我慢我慢…
昔は自作PC組んでて8800GTX→HD5870+QX9650とか使ってたんですが
今はもう省電力でいいやーって感じでノートにしました。
あとこのノートPC、実は既にグラボを載せ替えてるんですよ。
元々GTX675M積んでたけど680Mのベンチ見て
ebayでカナダから680MのMXMボードを取り寄せました。
多分今のところ日本でGTX680M積んでる15インチノート持ってるのは俺しかいないｗ
最近のノートはそんなことができるんですか。驚きました。
どうりで性能が高いわけです。
非常にいい感じでAchieved Occupancy (0.48)が
Theoretical Occupancy(0.50)に近づいています。
----
Limiting Factor
Achieved Instruction Per Byte Ratio: 79719.32 ( Balanced Instruction Per Byte Ratio: 4.95 )
Achieved Occupancy: 0.48 ( Theoretical Occupancy: 0.50 )
IPC: 1.04 ( Maximum IPC: 2 )
Achieved global memory throughput: 0.01 ( Peak global memory throughput(GB/s): 192.38 )
Occupancy Analysis for kernel CUDA_PerformSearching_DES on device GeForce GTX 580
Kernel details: Grid size: [256 1 1], Block size: [32 8 1]
Register Ratio: 0.84375 ( 27648 / 32768 ) [35 registers per thread]
Shared Memory Ratio: 0.945312 ( 46464 / 49152 ) [15488 bytes per Block]
Active Blocks per SM: 3 (Maximum Active Blocks per SM: 8)
Active threads per SM: 768 (Maximum Active threads per SM: 1536)
Potential Occupancy: 0.5 ( 24 / 48 )
Occupancy limiting factor: Registers , Shared-memory
マウスとかエイリアンとかにあるよなぁ、と一瞬思ったけど 15 インチか。ｗ
廃熱大丈夫なのか？それ。
しかもGTX675M比で3D性能は1.5倍だけど温度はかなり下がりましたしね。
定格でトリッパーを連続で回してもジャスト60度ってとこです。ゲーム時はもうちょい上がりますが。
全体の消費電力だってディスプレイ込みで150Wくらい。
それでいて上の構成の当時最高スペックの元自作機より絶対的な性能も高いし
すごい時代になったもんだなと。
自分のはClevoのP150EMなんですけど海外じゃ680M搭載機は売られてるんですよ。
日本でも兄貴分の17インチには680Mの設定があるけど
15インチのやつで設定してるところはない。
冷却システムは17インチも15インチも全く同じなんですけどね。
つーか冷却の面だと標準の675Mの方がよっぽど厳しかったですわｗ
某MMOやってるとGPU90度超えとかいう恐ろしいことになってましたから。
今は10度以上下がって70度台、ノートとしては十分合格点です。
そりゃすごい。うちのでおもいっきり動かすと2枚のグラボが
それぞれ70度と80度いきますからね。なんせ580は一枚244Wですからねえ。
ワッパが全然違います。
お、お久しぶりです!
よほど興奮してたんだなｗ
それはさておき、10桁検索の最適なスレッド数を見つけるためにいろいろ
実験してみました。
CUDA_SHA-1_Tripper_MERIKENs_Branch.exe (-l 10 -x 128 -d 0)
スレッド数 速度(M TPS)
32 6.14
64 13.45
128 22.85
256 35.66
---(以下compute_10,sm_10でコンパイルできず)--
288 18.05
384 24.37
512 38.07
576 (動作せず)
640 (動作せず)
共有メモリの使用量の関係でスレッドの数が多くなると
Compute Capabilityが2.0未満だとコンパイルできなくなります。
10桁検索はCC2.0以上必須にしようかな。
576と640が動かなかったのは謎です。ちょっと調べてみよう。
むしろCL=9から10になったので微妙なところで遅くなってるような気が…
でも同時にLiquidUltraを注文して塗ってみたらすごい効果でした。
室温27度で比較してみると…
塗る前の最大負荷時の温度
CPU：90度
GPU：80度
↓
塗った後の最大負荷時の温度
CPU：75度
GPU：65度
LiquidProは怖くて手が出なかったけど十分すぎる。
これで安心してCPUとGPU同時でブン回せますｗ
32Kがshared memoryに割り当てられていて、
残りがL1 cacheとして使われているから無理やり共有メモリを32K以上
使おうとすると挙動がとたんにおかしくなる、ということらしいです。
L1キャッシュを無効にするためにオプションで
-Xptxas -dlcm-cg
と指定してみたけど 上手くいってない模様。どうしたものか。
全然違いますねえ。自分も580で試してみたいけど、さすがにEVGAの
無期限保証を手放す訳にはいかないか…
> The same on-chip memory is used for both L1 and shared memory, and
> how much of it is dedicated to L1 versus shared memory is
> configurable for each kernel call (Section F.4.1);
> Global memory caching in L1 can be disabled at compile time
> (Section F.4.2);
> Local memory caching in L1 cannot be disabled (Section 5.3.2.2),
> but programmers can control local memory usage by limiting the
> amount of variables that the compiler is likely to place in local
> memory (Section 5.3.2.2) and by controlling register spilling
> via the __launch_bounds()__ attribute (Section B.17) or the
> -maxrregcount compiler option.
ttp://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/Fermi_Tuning_Guide.pdf そこが難しいところですね。
自分はもう改造しまくって保障なんかｼﾗﾈな世界なんでどうでもいいけどｗ
Fermiはすさまじく爆熱だから効果もかなりあるとは思うんですが…。
模様。Fermiはピーキーすぎる…
1> ptxas info : Compiling entry function '_Z25CUDA_PerformSearching_DESP10CUDAOutputPhPjji' for 'sm_20'
1> ptxas info : Function properties for _Z25CUDA_PerformSearching_DESP10CUDAOutputPhPjji
1> 24 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1> ptxas info : Used 63 registers, 4+0 bytes lmem, 38720+0 bytes smem, 52 bytes cmem[0], 2540 bytes cmem[2], 8 bytes cmem[14], 72 bytes cmem[16]
実はちょっとまえに580を思いっきりOCしてトリップ検索してたら
バキバキとすごい音がしてヒートシンクが膨張してカードが壊れちゃった
ことがあったんです。保証ですぐ交換してもらえたので助かりました。
うへ、ヒートシンクが膨張って何度まで上がってたんだろう…
そういうのがあるとやっぱり保証は欲しいですね。
自分も同じマシンでGTX675MとGTX680M比べてるわけですけど、
あの熱は本当に怖かった。
まぁCUDAの事を考えると、下手にリキプロとかぶち込むよりも
GeForce700系待ちの方がいいかもしれませんね。
水冷も試してみようかなと思ったんですけど、
保証とメンテのこと考えるとね…
当分の間は580 SLIの掃除機のような轟音とストーブの
ような爆熱に付き合うことになりそうです。
勘違いかしら。でもそれだと32KB移譲共有メモリが使えないことの
説明がつかない… 実に謎です。
> The same on-chip memory is used for both L1 and shared memory:
> It can be configured as 48 KB of shared memory and 16 KB of L1
> cache or as 16 KB of shared memory and 48 KB of L1 cache . . .
ttp://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/CUDA_C_Programming_Guide.pdf Fermiちゃん、ツンデレすぎるだろう…
CUDA: Is It Possible to Use All of 48KB of On-Die Memory As Shared Memory?
ttp://stackoverflow.com/questions/12402191 共有メモリ云々は私の勘違いで、原因はレジスタの数が足りなかった
だけでした。原因がわかってすっきりしたけど、10桁検索のこれ以上の
性能向上は難しいかもしれないなあ。
580 SLI OCで100M TPS出ました。もう何でもありですね…
これを見る限りスレッド数は768で決定ですね。
これでにさらに6M TPS以上盛ることができたわけだ。
CUDA_SHA-1_Tripper_MERIKENs_Branch.exe -l 10 -x 128 -d 0
(580単体 1タゲ 3分間の平均速度)
スレッド数 速度(M TPS)
32 6.14
64 13.45
128 22.85
256 35.66
---(以下compute_10,sm_10でコンパイル不可)--
288 18.05
384 24.37
512 38.07
---(以下レジスタ数の調整の必要あり)--
640 31.74
768 42.06
---(以下共有メモリ不足でコンパイル不可)--
896
ほぼ同じ速度が出るようになりました。結局レジスタの数が
多すぎてSMが同時に1つのブロックしか処理できていなかった
ということみたいです。なんにせよこれで古いカードを切り捨てる
必要はなくなりました。
ほとんど誤差みたいなものですが、一応10に設定しておきます。
ループ回数 速度(M TPS)
4 41.30
8 41.71
10 41.81
12 41.76
14 41.75
16 41.73
あるとないのとでは全然違うけど、偶数にしなければ効果はほぼ同じなので
無難に1に設定しておきます。しかしバンクコンフリクトの影響は露骨ですね。
ダミー変数の数 速度(M TPS)
0 19.98
1 41.81
2 38.89
3 41.81
4 31.43
7 41.79
【GPU】NVIDIA GeForce GTX 580 2-Way SLI (OC: 950/2004MHz 1100mv)
【CPU】Intel Core i7-3770K (OC: 4.4GHz 1300mv)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Alpha 3
【10桁・12桁】10桁
【オプション】-l 10 -x 128
【Display Driver】305.60
【10分間の平均速度】 102.59M tripcodes/s
【その他】5完1タゲ
またいい考えが閃かない限り、10桁検索の最適化は一段落です。
Occupancyはまだ0.5のはずなので、理屈で言えばレジスタの数と
共有メモリの量が倍あれば速度はさらにあがるんでしょうけど、
CUDAの制約上仕方ないですね。いずれはRadeonとOpenCLの組み合わせも
ためしてみたいなあ。
気になる記事があったのでどうぞ
ttp://dualsocketworld.blog134.fc2.com/blog-entry-328.html xeon phiは速いのかな？
GTX680Mで使える初めてのWHQL統一ドライバだ…
リンク先はIntelが裏で動いてNVIDIAとAMDの足を引っ張っているという陰謀論ですけど、
元の記事を見ると話は随分違います。
> ではそもそもなぜPCI-SIGは300Wを超える仕様を拒否したか、であるがNeshati氏に
> よれば「300Wを超えるようなカードは、シャーシのメカニカル的な強度に無理が
> 生じてくる。あるいはこうしたハイパワーのカードの場合、リテンションの強度や
> カードそのものの重量、排熱がシステムに与えるストレスなどを考慮しなければ
> ならない。冷却やエアフローが、システム内部への排熱がシステムボードのほかの
> コンポーネントに影響を与えない様にする必要がある。例えばCPUとかなら、Intelに
> してもAMDにしても内部にThermal Sensorを搭載し、温度が上がったら発熱を
> 下げるような工夫がされている。ところがGPUカードはこうした具合になっていない。
> これはシステム全体のパフォーマンスをむしろ下げる方向に作用する。これは
> ユーザーにとって良いことではない。GPUベンダーは、もう少しThermal Budgetや
> Cooling Budgetを考えるべきだろう。勿論NVIDIAの様なGPUベンダーの視点から
> すれば、こうした問題は解決可能なのだろう。しかしPCI-SIGの視点からすると、
> メンバー企業がスペックを超えた仕様を独自の努力で可能にするのは自由だが、
> それを仕様化するのは好ましいとは言えない」という返事であった。
IDF 2011 - 大原雄介のIDFレポート - PCIe Gen3はどうなる? PCI-SIGインタビュー
ttp://news.mynavi.jp/articles/2011/09/20/idf01/index.html しばらく580 SLIを使っている身としては、Neshati氏の言っていることは
至極もっともに思えるのですが…
ためしてみたい気もするけど、今の305.60がちゃんと動いているので
悩むところです。昔と違ってドライバも随分安定しましたからね〜
Xeon Phiはx86系のコアを50個以上搭載してるそうですよ。
また新たな変態アーキテクチャが誕生するわけですね。実に楽しみですw
OpenCLにも対応するそうです。思い切ってTripperをOpenCLに移植しようかな。
自分も入れてみた結果302.71に戻そうかなと思ってます。
そこまで良いドライバではないような気がしますし。
確かに3DMark11のベンチスコアは微増するんだけど、
302.71より後のドライバはDX9世代のゲームとの相性が悪いので。
たかだか2〜3%伸びる程度なら安定性を取る。
あと仕事行ってる間にCPU+GPUで放置してみたんで結果報告です。
7完+8完の検索、オプションは-x 224でで合計平均が約321MT/s
見た感じそれぞれの平均はCPUが約26MT/s、GPUが約295MT/sってところでした。
最高温度はCPU80度、GPU63度＠室温30度、GPUは余裕でOC常用行けそうかも。
今ですら2スロット占有は当然、3スロット占有も珍しくないですし、冷却の問題は大きいですね。
Fermiのシュリンク版・・・欲しかったですｗ
それなら多分常用でも大丈夫でしょうけど、くれぐれも気をつけてくださいね〜
それにしてもCPU検索も馬鹿にできないですね。
頑張ってアセンブラで書き直してやれば12桁のCPU検索の速度は倍ぐらいに
なるはずなので、気が向いたらやるかもしれません。
Fermiちゃん、いろんな意味で熱すぎですw
まぁ大丈夫です。
やる時には温度監視しながらやりますし
+135MHz以上は確実に回りそうなのにAfterBurnerの制限で回せませんから。
温度とか見ててもKeplerってかなりマージン取って作ってあるなーと思いますよ。
あと今になって気づいたけどの周波数は間違いでした。
限界835MHzじゃなくてベース+135MHｚの854.5MHzでした。すみません。
検索アルゴリズムのほうはかなり手間取りそうな感じです。
10桁・12桁
前方一致・後方一致・位置指定なし
線形探索・二分探索
ビットマップの使用・不使用
と、思いついただけでも2x3x2x2=24個のカーネルを用意しないといけません。
マクロを多用してかなり手間を省いてはいるんですが、数が多すぎです。
まあでも性能や将来の拡張性のことを考えるとここで妥協するわけにはいきません。
まああれだけゲームに必要ない機能を削ったらかなり余裕があるでしょうねえ。
設計の割り切り具合が凄いです。
了解しました。Tripperが早速役に立っているようでなによりですｗ
これからもよろしくお願いします。
Horo氏のコードはシングルスレッド・CPU検索なし・複数GPU対応なしだったので、
その時の名残りでグルーバル変数が多用されていたのですが、
自動設定の準備としてブロック数の決定などの処理をメインのスレッドから
検索スレッドに移しました。1年前の多スレッド化はかなりの突貫工事だったのですが、
これで安心して自動設定の実装に取り掛かれます。
速度が激減するという謎の現象が発生。どういうこっちゃ…
あと葉挿し的なブロック数を設定してやるだけです。
MERIKENさんの英語力をお借りしたくて質問させて下さい。
Press power button override 4 seconds, and then re-plugin AC adaptor.
これ、電源ボタンを4秒押し続けた後にACアダプタをつなげ、ってことでいいんでしょうか？
BIOSアップデートかけたら成功表示出たのに起動できなくなった…orz
それで合ってますよ。しかし災難ですね。うまく直るといいんですが…
ありがとうございます。
このご時世にブータブルUSB作ってDOSで更新しろとか正直言って難易度高いですわ
680Mへの対応が不十分でその更新とかって話だったのに
USBからDOSを起動なんて話、初めて聞きました。
DOS使ってたのなんて中学生の頃じゃなかったかしらん。
何もかもが懐かしい…
ブロック数をだんだん増やしてやって、速度の増加が頭打ちになったら
そこで測定を終了するというごく簡単な仕組みですが、それなりに
動作しているようです。あまりブロック数を増やしすぎても
タイムアウトが発生しやすくなるだけなので、伸びが鈍化したら
適当なところで切り上げています。
12桁のをコピペして1発で完動でした。
あとはキービットマップと線形探索・二分探索か…
24個用意してそれぞれをテストするだけです。幾つかはこれまで使ってきたものを
流用できるし、マクロを多用しているのでそれほど手間にはならないはずですが、
どうなることやら…
衝撃の事実が発覚しました。結局のところ、少なくとも580では
(1) パターンが5個以上の時は二分探索のほうが線形探索よりも速い。
(2) パターンが4個以上の時はビットマップを使用したほうが速い。
ということで、ほとんどの場合二分検索とビットマップの組み合わせのほうが
速いということが判明し、以前適当に決めてたしきい値はかなりずれていた
ことがわかりました。というわけで検索アルゴリズムの自動設定は
ほとんど効果が期待できないということになってしまいましたorz
まあアルゴリズムの動的な最適化のおかげで検索ルーチンがしゃれにならない
ぐらい複雑になってたので、かえって良かったのかもしれません。
この際なので思い切って要らない部分を削ってしまうことにします。
どもども、頑張りますです。
ソースの可視性も良くなって、結果的には非常によかったと思います。
問題なのは関数がマクロ化されていない10桁検索のほうなんですが、
仕方ないのでせっせと作業を続けます。
ご心配をおかけしました。
BIOSをアップデートしたらオーバークロックメモリと相性が出ちゃってました。
PC3-1866から1600＠CL=9に戻したらすんなり起動…。
俺の週末を返せｗ
ってことで検索協力復活できる模様です。
それはなによりです。突然立ち上がらなくなるとびっくりしますよね。
そろそろ新しい開発版をうｐする予定なので、またテストをしていただけると
有難いです。
10桁と12桁の両方とも多ターゲットの検索の効率が大幅に向上しました。
特に10桁トリップ検索はFermiだとようやく使えないこともない速度を出せるよう
になりました。ただ、10桁検索ではKeplerの非常に苦手な論理演算()を
これでもかというぐらい使っているので、6xxシリーズではほとんど速度を
期待できません。残念ですが、こればっかりはどうにもなりませんね〜
CC2.0未満のカードでどれぐらい性能が出るのかも気になるところです。
テスト用にGTX 260とGT 640を買っちゃおうかな…
事が判明。したらばでは普通に通るので、症状も全く同じ。やれやれ。
◆8/TS2/yk5Q #ﾕﾔﾎIｼ朽ﾕﾟp (d5 d4 ce 49 bc 8b 80 d5 df 70)
前回のはこれ。
◆TEST/zXiSQ #ﾊ楳彦ｨg銃F (ca 94 80 95 46 a8 67 8f 65 46)
共通点はShift-JISの第二バイトに0x80があることぐらいしか
見当たりません。
> 共通点はShift-JISの第二バイトに0x80があることぐらいしか
> 見当たりません。
それが問題でしょ(*‘ω‘ *)
したらばのトリップ生成について
ttp://chimaera.org/shitarabatrip.html やっぱこれなんですかね〜
とりあえず第二バイトに0x80がこないようにしておこうっと。
✕ ◆/602/yVjaQ #l｣B朽くｭ綏 (6c a3 42 8b 80 82 ad ad e3 56)
✕ ◆zV/801/VZo #l｣B劇憾ｸｬ｡ (6c a3 42 8c 80 8a b6 b8 ac a1)
✕ ◆/900/RTINI #l｣B操左ﾁxe (6c a3 42 91 80 8d b6 c1 78 65)
✕ ◆8/TS2/yk5Q #ﾕﾔﾎIｼ朽ﾕﾟp (d5 d4 ce 49 bc 8b 80 d5 df 70)
✕ ◆TEST/zXiSQ #ﾊ楳彦ｨg銃F (ca 94 80 95 46 a8 67 8f 65 46)
○ ◆M/DL/300/k #ﾄ戛0ｴｾﾛ閠ﾑ (c4 9c fc 30 b4 be db e8 80 d1)
○ ◆/544/t63mY #ﾙｽｩs牾ﾟｬ麾 (d9 bd a9 73 e0 b1 df ac 9f 80)
やっぱりキーのShift-JIS文字の第二バイトに0x80がくるとまずいみたいです。
最後の2つが大丈夫なのは、キーの最後の2バイトは10桁トリップ生成に
関係ないからでしょう。これでようやくすっきりしました。
どうものページで解説されている以外にもしたらばと2chの
トリップ生成の方法に違いがあるみたいです。
とりあえず一休みしてから、今日か明日中に0.04 Beta 1をうｐします。
あーなるほど、これですか。見落としてました。とんでもない糞仕様ですねえ。
っていうか知ってるんなら教えて下さいよw
> bbs.cgi 稼働サーバOS(FreeBSD)のCRYPT(3)には、他OSと互換性がなく対策も
> 困難である仕様が存在します。FreeBSDではキーバイト列に 0x80 が含まれて
> いる場合にそれをキー文字列の終端(0x00)と見なし、以降のバイト列は
> 0x00 であるかのごとく処理してしまいます。一部のShift_JIS全角文字が
> この仕様に抵触します。
ttp://sourceforge.jp/projects/naniya/wiki/2chtrip CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Beta 1
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch 今回の変更点は以下の通りです。
・ブロック数の自動設定。
・10桁トリップ検索の高速化。
・多ターゲットの検索の高速化。
・2ちゃんねるで使用できないトリップが生成されるバグの修正。
特に問題がなければこれを安定版にする予定です。テストしていただける
方にはブロック数の自動設定がちゃんと動いているか確認していただけると
非常にありがたいです。
CUDA SHA-1 Tripper MERIKEN's Branch 0.04 Beta 1
CUDA DEVICE
===========
CUDA Device Count: 1
Device No.: 0
Device Name: GeForce GTX 460
Multiprocessor Count: 7
Clock Rate: 1400MHz
Compute Capability: 2.1
CPU
Number of Processors: 8
Number of Search Threads: 7
TARGET(S)
0: "TEST/"
TRIPCODES
◆TEST/8VsqeHK #ﾟ遥N､ﾆｲ位Rﾝﾄ (df 97 79 4e a4 c6 b2 88 ca 52 dd c4)
◆TEST/eiqEcis #ｿdﾝｨ撚ｬnﾏﾍJ･ (bf 64 dd a8 94 51 ac 6e cf cd 4a a5)
◆TEST/96wx5kE #怜l･Y凧顳eﾃc (97 e5 6c a5 59 91 fa e9 42 65 c3 63)
Performing a forward-matching search for 1 pattern (1 chunk)
with 5 characters on CPU and GPU(s):
CUDA0: [optimizing...] 265.4M TPS, 8 blocks/SM
0.003T tripcodes were generated in 0d 0h 0m 10s at:
281.83M tripcodes/s (current)
GPU: 260.91M tripcodes/s
CPU: 20.91M tripcodes/s
281.83M tripcodes/s (average)
On average, it takes 2.6 seconds to find one match at this speed.
6 matches found at 2156.76 matches/h and 0.47G tripcodes/match.
The actual matching probability is 128% higher than expected.
0% of matching tripcodes were invalid.
あ、早速有り難うございます! 自動設定は動いてますか?
"STATUS"の4行下の"[optimizing...]"が消えれば設定は終了なんですけど、
そのときのブロック数("blocks/SM"の左の数字)はどうなってますか?
STATUS
======
Performing a forward-matching search for 64001 patterns (4001 chunks)
with 6 to 12 characters on CPU and GPU(s):
CUDA0: [optimizing...] 257.0M TPS, 8 blocks/SM
0.003T tripcodes were generated in 0d 0h 0m 10s at:
271.66M tripcodes/s (current)
GPU: 252.21M tripcodes/s
CPU: 19.45M tripcodes/s
271.66M tripcodes/s (average)
On average, it takes 2.9 minutes to find one match at this speed.
No matches were found yet.
そうそう、それなんですけど、しばらく(10分ぐらい)放っておくと、これ
> CUDA0: [optimizing...] 257.0M TPS, 8 blocks/SM
の"8 blocks/SM"の数字が段々増えていって、最終的には
"[optimizing...]"が消えるんです。
STATUS
======
Performing a forward-matching search for 64001 patterns (4001 chunks)
with 6 to 12 characters on GPU(s):
CUDA0: 272.8M TPS, 160 blocks/SM
そうそうそれです。ありがとうございます。しかし160とはかなり高い数字が
出ていますね。自動設定はかなり保守的にしたつもりだったんですが…
Compute Capabilityが2.1だと2.0だとまたちょっと違うのかしらん。
今後の予定について考えてみました。とりあえず今思いつくのは
これぐらいです。
・GUIの実装。
・CPU検索の高速化。
・OpenGLへの移植とRadeonへの対応。
どれもかなりの作業量なのでどこから手を付けていいか
迷うところです。
SSE用の超高速なDESとSHA-1の実装がネットに転がっているので、
それをひっつけてやるだけでかなり改善されるはずです。
問題なのはこれらの実装がほとんどGNU as用だということですが、
mingwを使えばなんとかなるんじゃないかと考えています。
やっぱりGUIですかね〜 WindowsのGUIプログラミングは
Visual Basic 1.0（ｗ 以来なんですけど、C#の入門本も
買ってきたしなんとかなるでしょう!
どんな機能があるといいか教えていただけると助かります。
作業量がかなり多くなりそうなので最後までとっておくことにします。
特にアーキテクチャの違いで10桁検索がどれぐらい速くなるか
非常に気になるところです。
というわけで、次のバージョンでシンプルなGUIの実装を目指しつつ、
他の作業も少しづつ進めていくことにします。
そうですよ。
あ、もちろんCUDAの実装はそのままです。
GPU検索の高速化もっとやったら(*‘ω‘ *)？
あと、後方一致検索の高速化の反映忘れてね(*‘ω‘ *)？
もしくは、GUIとCLI別にして、フロントエンドみたいなの作るとか。
GPU検索の最適化の作業は、何かまた思いついたら再開しますけど、
それまではお休みです。今まで考えてたことはもうだいたいやってしまったもので…
あと後方一致検索は高速化されているはずですが…
具体的にBeta 1よりAlpha 2のほうが速い後方一致のパターン/ターゲットはありますか?
やっぱり検索ルーチンの奥に手を入れると色々思いつかない
不具合が出てきますね。
あ、書き忘れてたけどGUIはもともとフロントエンドとして作るつもりです。
やっぱりCUI版の需要もありますし、なによりも作るのが楽ですｗ
見つかって良かったです。
あとバクを修正したバージョンで簡単なテストをしてみたところこんな感じに
なりました。
"^/[:digit:][:digit:]/[:digit:][:digit:]/" -> 656M TPS
"/[:digit:][:digit:]/[:digit:][:digit:]/$" -> 653M TPS
これを見る限りでは後方一致検索は前方一致検索と同じぐらいの速度が出ている
ように見えるのですが…
検索ルーチンをいじるたびにバグが紛れ込むんじゃないかとひやひやします。
バグがあるみたいです。もうちょっと原因を探ってみます。
低速になってしまうのがやや不便ですね
紛れ込んだみたいです。二日前のコードにロールバックしたら
消えました。ブロック数の自動設定はうまく動いているみたいですが、
コードの整理はやり直しかorz
すべてのターゲットで"^"か"$"のいずれかが使われているケースなら
最適化できないことも無いですが、コードがさらに複雑になってしまうので
バランスを取るのが難しいところです。バグ取りが終わったらちょっと
考えてみます。
集中しているのでこのバージョンには間に合いませんが、次のバージョンで
そのアイディアを取り入れさせて頂きます。
それはそうと、ヒット率が落ちるバグはどうやら検索ルーチン以外のところに
紛れ込んでいたらしく、どうやら検索ルーチンの整理のやり直しは避けられそうです。
よかったよかった。
Beta 1は大丈夫みたいです。あ〜、びっくりした。でもいい機会だからテストの
やり方をもうちょっと考えよっと。
胸熱な展開だな。ｗ
いえ、WindowsのExplorerでコピペですｗ ソースコードの管理ももうちょっと
しっかりしなきゃなあ。
バージョン0.04の安定版を公開することにします。
あとバージョン0.05でGUIに対応するために、Visual Studioのプロジェクトを
新しく作り直しました。SHA-1ベースの12桁トリップだけでなくDES cryptベースの
10桁トリップにも一応対応したし、CUDAだけでなくOpenGLへの移植も考えている
ので、新スレへの移行の段階でプログラムの名前を新しいものに変える予定です。
ありがとうございます。
試してみます。（今更）
個人的にはGUIは必要を感じないけど、どんなGUIになるかは楽しみ(*‘ω‘ *)
"git bisect -h"
え、そんなうｐするまでもない低レベルなことしかしてないよ。
------------------------------------------------
CUDA_SHA-1_Tripper_MERIKENs_Branch.exe -x 224
------------------------------------------------
たとえばこんな風にテキストファイル保存して
拡張子をbatに書き換えてこいつを同じフォルダに入れて起動するだけ。
試したい設定の数だけ作って保存しとけばいいし楽。
うちのQuadro FX 3800でもBeta1は無事動作しました。最適数検索は1分位で終了し、-x 16でした。速度は・・・それなりですが。
今後の希望として、計算途中結果の保存機能を実装して頂けると助かります。
どうしてもPCをシャットダウンする必要が有り、その度に再実行だとなかなかトリップが見つかりません。
0.04 Beta 1をWin7 SP1 x64 + 306.23でデフォルトターゲット（"TEST/"）で試してみたところ
12桁GPU検索（オプションなし）と10桁GPU検索（オプション -l 10）で
それぞれ10分間動かして以下のような結果になりました
12桁GPU検索
======
CUDA0: 106.1M TPS, 160 blocks/SM
0.063T tripcodes were generated in 0d 0h 10m 00s at:
109.05M tripcodes/s (current)
104.50M tripcodes/s (average)
On average, it takes 7.1 seconds to find one match at this speed.
10桁GPU検索
======
CUDA0: 7.4M TPS, 96 blocks/SM
0.004T tripcodes were generated in 0d 0h 10m 00s at:
7.47M tripcodes/s (current)
7.30M tripcodes/s (average)
On average, it takes 1.7 minutes to find one match at this speed.
12桁GPU検索は0.04 Alphaと同じくらいの速度ですが
10桁GPU検索は0.04 Alphaでは約2.8Mでしたので（数値自体は相変わらずしょぼいですが）かなり高速化してます
なお12桁GPU検索の方は約8分後・10桁GPU検索の方は約6分後に[optimizing...]が消えました
あとGT640は12桁GPU検索でブロック数が32〜64くらいまでは常時約105Mあたり安定してますが
それ以上では約110Mと約100Mが10秒毎に交互に切り替わって平均約105M、みたいな挙動になってるみたいです
とりあえずGUI化してまっさきに付けたい機能は検索の一時停止です。
ちょっと作業する度に検索を停止するのはめんどくさいので…
報告ありがとうございます。検索速度も教えていただけると非常に助かります。
トリップ検索は数分の一秒ごとに乱数で計算を全てやり直しているので、
再実行しても効率は全く変わりません。ひたすら待ちましょう。
詳しく報告していただいて大変参考になりました。
自動設定はちゃんと動いているみたいですね。
10桁検索は…まあ頑張っているほうでしょうｗ
ttp://www.meriken2ch.com/files/2012-09-18-MTF-mockup.jpg VSでGUIを作るのは初めてなんですが、割と簡単でした。
まあ問題はこれからなんですが…
名前はMERIKEN Tripperでもいいんじゃないですか(適当)
いやー、Visual Studioは便利ですねえ。「検索設定」のタブのデザインは
出来上がったので、あとは「検索スレッド」のタブを仕上げたら
本格的にC#のプログラミングを始めます。
"tripper"という単語は英語の意味がちょっとあれなのでやめておきました。
トリッパーでおｋ。ｗｗｗ
それはおかしいですね。OSのバージョンは何ですか?
cuda_sha1tripperは各ver動いたんだけどなぁ
ちょっとテストバージョンを用意するので待って下さい。
cuda_sha1tripperと違ってMERIKEN's BranchではWindowsのAPIを
使って乱数を取り出しているんです。
これをパッケージの実行ファイルと差し替えて試してみて下さい。
ttp://www.meriken2ch.com/files/CUDA_SHA-1_Tripper_MERIKENs_Branch_2012-09-18.zip 今度こそMSDNのサンプル通りのはずです。
awesome! thank *you* for the bug report!
標準出力のリダイレクトとシグナルを使ってやればGUI化は
わりと簡単にできそうな感じです。案ずるより産むが易しというやつですね。
乱数でしたか。Orz
10分間の検索速度は以下の通りです。
QuadroFX3800
Xeon X5680@3.33GHz
WinXP64SP2
0.04β1
12桁
-c -g -x 16
305.93
238.23M tc/s
"/TEST"
238.91M tc/s (current)
GPU:171.13M tc/s
CPU: 67.78M tc/s
ありがとうございます。CPUが凄いことになっていますね。
6コア12スレッドのようですが、素晴らしい数字です。
C#簡単すぎﾜﾛﾀｗ とりあえず検索パターンの一覧を一時ファイルに書きだして
CUI版に渡すようにします。あとはオプションの設定かな。
いや、本業で薬中・アル中の患者さんを診ることが多いので洒落にならないんですよ…
せっかく考えていただいた名前ですけど、もう決めてしまったもので…
あと自分にとってプログラミングは息抜きなので、なるべく本業のことは思い出したく
ないんです。
検索プロセスにターゲットを渡すことに成功しました。
しかしC#はめちゃくちゃ楽ですね。昔Cでせっせとウィンドウイベントの処理してた
ころが嘘のようです。あと残っている作業は、
・検索プロセスのオプションの指定
・CPUとGPUの情報の取得
・検索結果のリダイレクト
・検索プロセスのシグナルの処理
ぐらいかな。難しいことはなにもないので次スレを立てる前までに形にしておきたい
ところですが、どうなるかな…
GTX480で520M tc/s〜出てるけど発熱酷過ぎﾜﾛｽ
これは冬になったら暖房がてら稼働するか
opが沢山できますように。
とりっぷキーが
カタカナ
ひらがな
漢字
数字
記号
英大文字
英小文字
顔文字
絵文字
ナドナドお願いします。
こんどこそ直っているはずです。これで安心して0.05の作業を続けられます。
CUDA SHA-1 Tripper MERIKEN's Branch 0.04
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch 結構出てますね〜 580が2枚だと排熱で死にそうです…
いつもありがとうございます。キーの種類はある程度選べるといいですね。
ただあまり細かくするとトリップが見つからなくなってしまうので
バランスが必要ですが…
GUIから正規表現を含むパターンの設定をしたり、オプションを指定したり
出来るようになりました。あとは肝心のプロセス間通信の実装か…
CUI版を最初に1回走らせて、CUDAデバイスの一覧を標準出力に出させてから、
C#のほうでそれを処理しています。これでGUI版からもGPUが選べるようになりました。
これでリダイレクトのやり方も分かったからあともうちょっとです。
お疲れ様。
===========
CUDA Device Count: 1
Device No.: 0
Device Name: GeForce GTX 4
Multiprocessor Count: 7
Clock Rate: 1400MHz
Compute Capability: 2.1
CPU
===
Number of Processors: 8
Number of Search Threads: 7
STATUS
======
Performing a forward-matching search for 32
with 10 characters on CPU and GPU(s):
CUDA0: 273.0M TPS, 192 blocks/SM
0.164T tripcodes were generated in 0d 0h 9m
300.55M tripcodes/s (current)
GPU: 280.79M tripcodes/s
CPU: 19.76M tripcodes/s
287.79M tripcodes/s (average)
と同じ環境で0.04を10分間動かしてみた結果です
12桁GPU検索
======
CUDA0: 106.2M TPS, 192 blocks/SM
0.063T tripcodes were generated in 0d 0h 10m 00s at:
110.73M tripcodes/s (current)
104.17M tripcodes/s (average)
On average, it takes 7.1 seconds to find one match at this speed.
10桁GPU検索
======
CUDA0: 7.5M TPS, 128 blocks/SM
0.004T tripcodes were generated in 0d 0h 10m 00s at:
7.34M tripcodes/s (current)
7.32M tripcodes/s (average)
On average, it takes 1.7 minutes to find one match at this speed.
最適化の結果が変わってますが
0.04 Beta 1でも動かす毎に12桁は160〜192、10桁は96〜128あたりで変わってましたので
挙動や速度に特に変化はない模様です
動作も安定してます
ちなみにこのPCのCPUはC2D E7400ですのでこちらもあまり戦力にならず
12桁検索で約9.6M、10桁検索に至っては約0.66Mと誤差の範囲？です
心の中での応援としょぼい環境での人柱くらいしかできなくてすみませんが
新バージョンの開発もがんばってください
ありがとうございます。励みになります。きちんと動いているようで
なによりです。なんせ長い間ほったらかしだったので、ようやく形になって
ホッとしました。GUI版の作業は着々と進んでいます。もうしばらく
お待ちください。
ttp://www.meriken2ch.com/files/2012-09-21-MTF-Screenshot-1.jpg 
ttp://www.meriken2ch.com/files/2012-09-21-MTF-Screenshot-2.jpg 
ttp://www.meriken2ch.com/files/2012-09-21-MTF-Screenshot-3.jpg 明日までに終わらせたいけどどうかなあ
・ファイルからの読み込みとファイルへの保存。
・エラー処理。
・一時停止の処理。
あ、そうそう、OpenGLへの移植の準備をしようと思って以前組み立てたPCに
以前買ったHD 5770を入れてAMDのSDKをインストールしようとしたんですけど、
肝心のSDKがXPに対応してませんでした。結局Windows 7をもう一つ買うことに
なってしまいました。とほほほほ…
実際のところどうなんでしょう…
Technetの方が安くすんだりしないですか？
上のHD5770とかはハードウェアでの対応は単精度のみだったりする
Technetもちょっと魅力的だけど、さすがにもう当分新しいPCを組むつもりはないので
今回は見送りました。
これですね。
Previous ATI Stream SDK v1.x-beta Release Packages
ttp://developer.amd.com/Resources/archive/ArchivedTools/gpu/ATIStreamSDKv1.4Beta/pages/PreviousATIStreamSDKReleasePackages.aspx XP対応なのは有難いけど、なるべくSDKは最新のものを使いたいので
Windows 7で開発環境を整えることにします。あ、あとトリップ検索では
浮動小数点演算は一切使っていないので大丈夫です。
SIGCONTに相当する命令がないことが判明し、実装がとんでもなく面倒になりそう
だったので、今回は見送ることにしました。まあGUI化によって検索の実行と再開が
かなりお手軽に出来るようになったので、一時停止の機能自体それほど必要なくなった、
というのもあります。
というわけで残りの作業はファイルの入出力とエラー処理の実装だけです。
他にも実装したい機能は色々あるのですが、とりあえず次スレまでに次の開発版を
間に合わせることを最優先することにします。
> 実装がとんでもなく面倒になりそう
(*‘ω‘ *)？
あ、これはCUI版に新しくWin32のメッセージ処理のルーチンを追加したくなかった
だけです。シグナルが使えればかなりお手軽にできたんですけどね〜
つ「SuspendThread」
待て屋リミッターはこれとかを使って実現してる。ｗ
ttp://www.nurs.or.jp/~sug/soft/super/signal.htm 検索スレッドで時間の経過を測定してるので、有無をいわさずスレッドを止めると
支障が出てしまうのです…
WindowsではPOSIXシグナルの一部は使えないんですよ。
ttp://www.ops.dti.ne.jp/~allergy/thread/thread.html#event ありがとうございます。一時停止の機能を実装するときに参考にさせていただきます。
なりました。検索プロセスの側でstderrにエラーコードと詳細情報を
流させるようにして、それをリダイレクトしてGUI側で拾うようにしています。
さすがにエラー処理をしている部分にいちいちエラーコードを追加する
作業にはうんざりさせられましたが、一番面倒くさそうなところだったので、
終わって一安心といったところです。あとはGUI内部のエラー処理と
ファイルの入出力ですが、これらは割と単純なのでなんとかなるでしょう。
入力の段階で弾くようにしました。やることはわかってるのでひたすらコードを
書いていくだけなんですけど、C#は初めてなので思ったより時間がかかりました。
まあでもあともうちょっとです。なんとか次スレまでには間に合うかな。
人柱仕様になっているので注意して下さい。
MERIKEN's Tripcode Finder 0.05 Alpha 1
ttp://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch 今回の変更点はGUIの追加です。今まで通りのコマンドライン版も利用できます。
デフォルトのファイル名が変更されたり、正規表現の指定の方法が変更されて
いたりするので注意して下さい。なお、GUIの利用には「Microsoft .NET
Framework 4 Client Profile」が必要になります。次の場所からダウンロード
して下さい。
ttp://www.microsoft.com/ja-jp/download/details.aspx?id=24872 ググったらこれ64bitOSでもx86の方を入れないと解決しないんだな。ややこしい
Microsoft Visual C++ 2010 再頒布可能パッケージ (x86)
ttp://www.microsoft.com/ja-jp/download/details.aspx?id=5555 ^\.*ABC\.*$
^ABC\.\.
このような組み合わせを記述した場合、後者が一切ヒットしなくなります。
動作報告ありがとうございます。
VCの再頒布可能パッケージの話は以前にも出てましたね。説明を追加して
おきます。の不具合はこちらでは再現できませんでした。
GUI版とCUI版、どちらをお使いですか? CUI版ではpatterns.txtの
最後の行にパターンを記述することはできないので注意して下さい。
要望があります。
ものすごいスピードで検索してなおかつGUIもつけてくれて
すごいと思います。
GPUを利用している性質上、検索中はCPUはアイドルでも
マウスがカクカクになるほどGPUを使っているようです。
トリップ検索の優先度の設定とかできないでしょうか？
タスクマネージャでプロセスの優先度を下げてもあまり変化は
ないようです。
GUI版とCUI版、両方で動作確認しております。
ターゲットが少ない場合にはヒットしていますが、合計500行ほど記述している場合にヒットしない現象が発生しています。
-x 8で、普段は動かしてます。
README読んだ?
すみません、そのオプション知らなかったです。
確認してみます。
GUI版なら「詳細設定 -> 1SMあたりのブロック数」でも設定できますよ。
グラボを2枚差して一枚を画面表示に、もう一枚をトリップ検索に使うという
手もあります。
了解しました。お手数ですが、問題の発生するpatterns.txtを
こちらにメールで送っていただくことはできますか?
meriken2ch@gmail.com
ぜひ直したいので、よろしくお願いします。
ありがとうございます。
用事のため明日になりますが、必ずメールします。
【トリップ検索】MERIKEN's Tripcode Finder
ttp://anago.2ch.net/test/read.cgi/software/1348565078/
このスレはなかなか思い出深いスレでした。
次スレでもよろしくお願いします。
こちらではちゃんと出ているみたいですけど…
ttp://ikura.2ch.net/test/read.cgi/qa/1348046271/167n
ﾃﾞｹﾀ
^ABC\.\.
下しか出ませんけど。
あるいみれあですか？
◆ABC..K.KEk #4ｴy資Dﾗ/犖 (34 B4 79 8E 91 44 D7 2F E0 B6)
(.)(.)(.)(.)、速度表示がすごく落ちますね
それはなにより。キーのあとに半角スペースが紛れ込んでいたみたいです。
ttp://ikura.2ch.net/test/read.cgi/qa/1348046271/169n
> (.)(.)(.)(.)
このパターンはやば過ぎですｗ
そんな感じでした。 半角なんてｷﾗｲﾀﾞ
？もつかえたらなって・・
"?"って「前の文字が1文字あるかないか」でしたっけ? あとで入れておきます。
ありがとうございます。ぜひGUI版の感想を聞かせてください。
おねがいします。
使ってみたい
?*
?+
??
10桁CPU検索の最適化と高速化に期待
MERIKENsTripcodeFinder_0.05_Alpha_1のMERIKENsTripcodeFinder.exeだと
単体では8800GTX、GT520共にに動くのですが
使用するGPU：をすべて使用にしてしまうと落ちてしまうのです
やはりCompute Capabilityのサポートに違いがあるGPUの
同時使用はマズイという事なんでしょうかね
Compute Capabilityが違うこと自体は問題ないはずです。
エラーメッセージが出ているなら、その内容と(もしあれば)エラーコードを
お願いします。あと、「詳細設定 -> 1SM当たりのブロック数」を1にして
エラーが起きるかどうか試してみて下さい。
それはよかった。頑張った甲斐がありましたｗ
10桁検索はかなり頑張って高速化したのでこれ以上伸びるかどうかは
微妙なところですね〜
ブロック数は指定しても状況は変わらないみたいです
あとCUI版はデフォルトだと落ちずにデバイスが二つ
認識されている状況でもGT520の片方のみ動いてしまい
直接[-d 0]で8800GTXを指定しない限りは動かないようです
10桁の計算は8800GTXの場合は0.00M tripcodes/sと
そもそも動いてない模様です
それはかなり謎な挙動ですね。8800GTXのCCが1.0、GT520が2.1ですか…
CCが違うカードが混在した環境でテストしたことがないので
ちょっとよくわかりませんが、おそらくCCの違いが影響しているんでしょうねえ。
とりあえず注意書きを追加して、いずれテスト用に別のカードを買って
試してみたいと思います。貴重な報告、ありがとうございました。
よく考えてみたらどこかでエラー処理をしそこなっているような挙動ですねえ…
ちょっと調べてみます。
エラーチェックに漏れがないか調べてみましたけど、
それらしい場所はありませんでした。やっぱりテスト用にもうちょっと
色々なカードを揃えたほうがいいのかな…
メール受け取りました。早速調べてみます。
楽しみ
12桁の目標は倍、10桁は10倍が今のところの目標です。
CPU検索だけでも使い物になるプログラムにしたいですねえ。
あれは単純に64bitでビルドするだけじゃなくて64bit最適化みたいなこともしないと駄目なのかな
あとmty_calのGPU検索部分は32bit版と64bit版でほとんど同レベルだったから
GPU検索が64bit版で高速化しないようなら64bit版を作る意味もあまりないかもしれないけど
もし64bit版が簡単に作れて速度も上がりそうなら64bit版も希望
今自分が使っている環境が64bitなのでいずれ64bit版もぜひ作ってみたいですね。
SSEだけでなくAVXも是非試してみたいです。
ttp://anago.2ch.net/test/read.cgi/software/1348565078/
もう書けないので、新しいスレッドを立ててくださいです。。。
