【トリップ検索】CUDA SHA-1 Tripper【GeForce】
1 :
名無しさん@お腹いっぱい。 :
2011/07/23(土) 22:33:58.01 ID:ymCTk7/G0
2 :
1 :2011/07/23(土) 22:41:17.24 ID:ymCTk7/G0
CUDA Toolkit 4.0でリビルドしたらリファのGTX 580で640MTrips/s出たので 記念にスレを立てました。これから少しずつ改造していく予定です。
3 :
1 :2011/07/23(土) 23:05:19.72 ID:ymCTk7/G0
5 :
1 :2011/07/24(日) 09:23:32.57 ID:CCuEpXVd0
>>4 使ってるグラボの種類が違ってて(Radeon とNVIDIA)、
ユーザー層が被らないので別スレでお願いします。
>>2 cudaTripper10Wiz7 は、CUDA Toolkit 4.0でビルドしたら、逆に遅くなったなぁ(*‘ω‘ *)
環境の違いかな
>>1 さんは、Windows7 64bitだったりします?
あと、4.0 でビルドしたやつは、実行時に表示される "Revision number" はいくつになるんでしょう?
元々ついてるexeと比べればいいの? CUDA4.0 64bitでコンパイルすると16.0%↑ compute_20,sm_21 に変更すると18.1%↑
>>7 ふむぅ
3.2だと64bitでも差は出なかった気がするけど、4.0だと出るのにゃ(´・ω・`)
9 :
1 :2011/07/25(月) 08:16:17.58 ID:3K/guMaX0
うちのはXP 32bitですよ。オリジナルは490MTrips/sぐらいだったので、 30%速くなってますね。"Revision number"はあとで確かめてみます。
>>6 表示されるRevision numberはCompute Capabilityでハードウェア依存だと思います。
>>9 使っているドライバのバージョンはいくつのものでしょうか?
270以降のものはXPでは結構トラブル報告があるみたいで悩みます。
11 :
1 :2011/07/26(火) 05:17:52.92 ID:JBHRB9Wu0
>>6 パラメータはこんな感じです。
> 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
12 :
1 :2011/07/26(火) 05:22:11.43 ID:JBHRB9Wu0
>>12 どうも。
やはり環境によるのでしょうかね。
覚悟を決めて270系を試そうか悩みます。
14 :
1 :2011/07/29(金) 12:59:42.42 ID:ET2Wz95M0
15 :
1 :2011/07/31(日) 12:27:42.44 ID:dKqT71TM0
ちょこっとソースに手を入れて画面出力をcudaTripper12Wiz7風にしました。 こんな感じで途中経過がスクロールせずに表示されます。 > 654.4MTrips/s [Total: 0.193TTrips, 0.084hours, Tripcodes: 0] 全然大したことはないのですが結構使い勝手が違います。 次は半角カタカナを含むキーを探索できるようにする予定。
16 :
1 :2011/08/01(月) 01:38:03.10 ID:QqRMCqFa0
GTX 580を951/1902/2203にオーバークロックして808.54M tripcodes/sが 出ました。 もともと772/1544/2004だったのでかなり無理をしています。 ファンは85%でこれ以上はMSI Afterburnerでは上げられないようです。 GPUの温度は68℃なので問題ないはずですが、ファンが掃除機のようです…
>>15 NT系でスクロールせずに表示というのは結構面倒ですよね?
どうやっているのか少し気になります。
>>16 1チップで800MTrips/sec超えですか・・・
GPUメモリ負荷が低いので、どうもFermi系では意外と消費電力少ないみたいです。
18 :
1 :2011/08/01(月) 03:04:47.52 ID:QqRMCqFa0
このあと電圧を1.150V、クロックを959/1918/2103まで上げて 810.83M tripcodes/sが出ましたが、どうやらここらへんが 限界のようです。GPUの温度も80度を超えたし… これ以上はファンを変えるか水冷化しないと無理ですね。
19 :
1 :2011/08/01(月) 03:14:04.19 ID:QqRMCqFa0
>>17 下の関数を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);
}
21 :
1 :2011/08/02(火) 06:00:10.23 ID:eiQbj9dZ0
>>20 ありがとうございます! 後で落として試してみます。
GTX 580では-Xオプションは16が最適でした。
22 :
1 :2011/08/02(火) 06:20:24.28 ID:eiQbj9dZ0
23 :
1 :2011/08/02(火) 10:13:56.99 ID:eiQbj9dZ0
ちょこっといじってkey[6]までは半角カナも探索するようにしました。 b64t[]に半角カナを足して大きさを128まで増やして、 無効な文字コードは飛ばすようにしただけです。後は残りをどうするかな…
24 :
1 :2011/08/02(火) 19:14:05.66 ID:eiQbj9dZ0
結局こんな感じでお茶を濁して12桁まで半角カナに対応。 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
26 :
1 :2011/08/02(火) 19:36:38.46 ID:eiQbj9dZ0
sha1trip_search()ですけど、これだけだと動きません。 ソースを配布したいのはやまやまなんですけど、どうしよう…
>>26 この後に入れそうになった
out->trip[11] = b64t_d[(c >> 24) & 63];
28 :
1 :2011/08/02(火) 19:46:51.64 ID:eiQbj9dZ0
それは危ないw ソースは近いうちにうpするのでちょっと待ってくださいな。
30 :
1 :2011/08/02(火) 19:49:55.99 ID:eiQbj9dZ0
半角カナに対応させる前に
HyperTransportをOCしてもう一回最高速に挑戦してみました。
ほかの条件は
>>18 と同じです。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
ちょっと上がって結構嬉しいかも…
32 :
1 :2011/08/02(火) 20:00:51.82 ID:eiQbj9dZ0
CUDAのためだけに組んだ、一点豪華主義の自作PCです。 ほかの部品を全部足してもGTX 580よりずっと安いですw 頑張ってくれてます。 念のために数時間走らせてヒット率が落ちてないのを確認してから Shift-JISへの対応に入る予定です。半角カナのときみたいに 変換テーブルが使えないので思案のしどころです。
>>32 580が、何ヶ月持ちますか? いまだ460ですです。
GPUが72度って普通ですよね。
34 :
1 :2011/08/03(水) 02:28:51.18 ID:aRUlnL6P0
72度なら余裕でしょう。 うちのは85度で回し続けてるのでちょっと心配です。 買ったばかりなので今のところ大丈夫ですけど、 このペースで動かし続けたらわかりませんねえ。
35 :
1 :2011/08/03(水) 06:10:56.73 ID:aRUlnL6P0
36 :
1 :2011/08/03(水) 07:27:06.76 ID:aRUlnL6P0
超適当にkey[11]までShift-JISに対応させたら できたトリップの85%がゴミという素敵な結果にorz 一応できたトリップは有効なようなので、あとは以下にスピードを殺さずに 効率を上げるかなんですが、かなり大変そう…
>できたトリップの85%がゴミ 気になるうな。 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
38 :
1 :2011/08/03(水) 10:14:32.43 ID:aRUlnL6P0
キーの値の設定を範囲を考えずにやってただけなので大丈夫です。 現在鋭意修正中。最終的にはゴミはほとんどでなくなる予定です。 やっぱりGTX 460は色々違ってるみたいですね。 出来上がったらテストしていただけると有難いです。
39 :
1 :2011/08/03(水) 11:12:54.40 ID:I7Q8j7GI0
大きなテーブルを使ってインデックスからキーの値を引くようにしたら、 ゴミは20%ぐらいまで減りました。ほんとは0%になるはずだったんだけど謎だ… まだ見落としてる所があるのかしらん。あと副作用でちょっと早くなったみたいです。
40 :
1 :2011/08/03(水) 11:45:18.96 ID:I7Q8j7GI0
ごみは1%以下になりました。あとはUnicodeに変換できない 2バイト文字を取り除くようにしたらShift-JIS対応は終了です。
∧∧∩ ( ゚∀゚ )/ ハ_ハ ⊂ ノ ハ_ハ ('(゚∀゚ ∩ (つ ノ ∩゚∀゚)') ハ_ハ ヽ 〈 (ノ 〉 / ハ_ハ ('(゚∀゚∩ ヽヽ_) (_ノ ノ ∩゚∀゚)') O,_ 〈 〉 _,O `ヽ_) (_/ ´ ハ_ハ ⊂(。A。⊂_、⊃ で き る よ !! ⊂´⌒⊃゚∀゚)⊃ V^V _ _ _ ,ハ ( ヽ,_ O´ 〈 _ _ 〉 `O (.(。A。∪ ノ ハ ( ヽヽ ∪。A。).) V^V / 〈 /ヽ 〉 ヽ V^V (.(。A。∪ ノ ⊂) ∪。A。).) V^V ( ⊃ V^V /( 。A。) ∪V^V
MappedMemory使ったほうが速度速くならないかな。 あと、CPU使うところでOpenMPとかSSEと思ったけど、 元のソース眺める限り、使えそうにないですね
43 :
1 :2011/08/04(木) 02:28:06.59 ID:t9BmwxU70
>>42 > MappedMemory使ったほうが速度速くならないかな。
ありがとうございます! ちょっと調べてみます。
44 :
1 :2011/08/04(木) 02:41:10.23 ID:t9BmwxU70
Shift-JIS対応のものを7完3タゲでしばらく動かした結果がこちら。 いろいろバックグラウンドで動かしてたので速度は問題ないのですが、 ヒット率がかなり落ちてるのが気になります。 > 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に対応しただけで効率が悪くなるなんてあるんだろうか… ちょっと調べてみよう。
45 :
1 :2011/08/04(木) 03:56:16.87 ID:t9BmwxU70
効率が悪くなってるのは検索してるときにキーが重複してるからなんだろうけど、 かなり真面目に計算しないといけないな、こりゃ。
46 :
1 :2011/08/04(木) 08:24:36.64 ID:t9BmwxU70
最適化のためにループの外に出しておいた処理を ループの中に戻したらヒット率がもとに戻りました。 理由は全く謎です。もとに戻すと多少速度は落ちるのですが、仕方がありません。 なんにせよShift-JIS化そのものに問題はなくてほっとしました。
そろそろですか・・・
48 :
1 :2011/08/05(金) 00:05:17.70 ID:dSgyh/OI0
どうやら
>>44 で話したヒット率の低下は偶然だったようで、
時間をかければ理論値に収束することがわかりました。
7完だと収束に時間がかかるだけだったようです。
おかげで最適化も進んで、速度もちょこっと上がりました。
あとは無効なShift-JISの文字を取り除くようにして、
ちゃんと2chで使えるトリップだけを表示するようにしました。
49 :
1 :2011/08/05(金) 00:05:49.04 ID:dSgyh/OI0
今のところこんな感じです。 > ◆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.
50 :
1 :2011/08/05(金) 00:11:01.34 ID:dSgyh/OI0
あとはコードを見直して綺麗にしてテストしてから公開する予定です。 数日かかるかもしれませんが、しばしお待ちを。
51 :
1 :2011/08/05(金) 16:02:36.86 ID:qhRY/zrt0
突貫工事で何とか配布パッケージができました。これからうpします。
52 :
1 = ◆MERIKEN4.k :2011/08/05(金) 16:22:05.28 ID:qhRY/zrt0
53 :
◆MERIKEN4.k :2011/08/05(金) 16:27:07.50 ID:qhRY/zrt0
オリジナルからの改善点は、 ・30%ほど速度が向上。 ・Shift-JISに対応。 ・画面表示の改善。 の3点です。
>52 乙 さっそく 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.
まじないがないソースコードは・・(黒一色なんて・・ ありがとう
56 :
◆MERIKEN4.k :2011/08/05(金) 16:48:41.60 ID:qhRY/zrt0
>>54 早速ありがとうございます。
>>37 と比べると結構速度が上がってますねえ。
よかったよかった。
ソースは確かに色ついてないですねえ。これどうすればいいんでしょう。
実は開発に使ったVisual Studioは全く詳しくないのです…
>>56 わたしは、何もわかりませんので。
黒でもいいですよ。 ひらがなとか漢字なんか使うと色が変わったり・・
速いよホント
58 :
◆MERIKEN4.k :2011/08/05(金) 17:06:28.79 ID:qhRY/zrt0
GTX 480のほうが改善率がいいみたいですねえ。どうしてだろう… 速度改善ですが、まだ試してみたい方法が残ってるので もうちょっと速くなるかもしれません。
59 :
◆MERIKEN4.k :2011/08/05(金) 17:20:56.54 ID:qhRY/zrt0
いつもの7完3タゲで思いっきりOCして822.33M tripcodes/sがでました。 ---- 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.
乙と言いたいとこだが、オリジナルのライセンスが不明なのに勝手にGPL3を宣言しちゃって大丈夫なのか?
お金=速さ ですね・・
62 :
◆MERIKEN4.k :2011/08/05(金) 17:27:38.89 ID:qhRY/zrt0
同じ条件で7完1タゲにしたら、836.84M tripcodes/sでした。 これが今のところ最高ですね。やっぱ次はヒット判定を改善しようっと。 ---- 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.
3タゲで 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)
64 :
◆MERIKEN4.k :2011/08/05(金) 17:36:11.88 ID:qhRY/zrt0
>>60 そこはやっぱちょっと問題ですよねえ。
でも配布する以上自分が書いた分のコードのライセンスを
指定しないわけにはいかなかったので…
もし原作者さんからクレームがきたらすぐに引っ込めます。
65 :
◆MERIKEN4.k :2011/08/05(金) 17:38:12.51 ID:qhRY/zrt0
>>63 かなり違いますねえ。やっぱりタゲの数でぜんぜん違うんだな。
66 :
◆MERIKEN4.k :2011/08/05(金) 17:41:52.91 ID:qhRY/zrt0
>>61 > お金=速さ ですね・・
でも持ってるものを最大限活用することはできます!
自分もせっかく買ったこのカードを骨までしゃぶりつくすつもりです。
ほんと、暖かいねGPUって。 冬ならいいのにな。
俺の決めたライセンスが気に入らなきゃオリ作者は連絡寄越せってんじゃなくて、
そっちから連絡取って伺い立てんのが筋じゃねえの?
nvCUDA_sha1からコア部分のマクロとかを拝借したつってるから他のライセンスが絡んでる可能性もあるし。
http://yakin.38-ch.net/trip/
>>68 nvCUDA_sha1はクラックツールだからもともと法的には真っ黒ですけどね。
この件は原作者様にこのスレにお越しいただいて解決することにします。
なんつーかひでえな
>>67 冬なら暖房いらないですね、これw 最近買ったんですけど、
こんなに熱くてうるさいもんだとは思いませんでした。
GPUの拘束時間が長い?分重いですがすごい速くなってますね。 280M→440MTrip/s @GTX470
>>73 > GPUの拘束時間が長い?分重いですがすごい速くなってますね。
> 280M→440MTrip/s @GTX470
報告ありがとうございます。やはりカードによってかなり上昇率にばらつきがあるようですね。
できれば画面のパラメータ等を貼っていただけると有難いのですが…
一応PAUSEキーで一時停止できるようになっていますが、使用中はかなり重くなりますね。
うっかり
>>75 で◆Horo/.IBXjcg氏を呼び捨てにしてるしorz
返す返すも申し訳ありませんでした。
オリジナルのコードに対するpatchとしてならば、公開しても問題ない…と思う
やっぱり慌ててるとろくな事がないですね… 今後の方針としては (1) ◆Horo/.IBXjcg氏にGPLでの配布の許可をもらえるまで待つ。 (2) なるべくコードの書き換えを進めて、自分のコードにしてしまう。 の二本立てでいきたいと思います。どのみちターゲットを正規表現に対応させるために 大幅に書き換える予定だったので、かえって良かったのかもしれません。 最終目的は10桁のトリップに対応させることだけど、先は長い…
>>77 > オリジナルのコードに対するpatchとしてならば、公開しても問題ない…と思う
たしかにその手もありますね。ただ、自分のわかりやすいように変数名を
ほとんど変えてしまったのでいまのままだとパッチがまるごとソースコードに
なりかねませんorz
というわけでコードをせっせと書き換え中。まあなんとかなるでしょう。
と思ったけどやっぱこれ書き換えただけじゃどうにもならないよなw まあいいや。もうだいたいやり方は分かったから自分で1から書きなおそう。 CUDA用の10桁トリップ検索プログラムも作りたいし。 10桁のが完成するまでに◆Horo/.IBXjcg氏がここに来てくれるといいなあ。
>>82 ん? 別に自分で1から書き直す分には問題ないでしょう。
それともバイナリの配布が気に入らないのかしらん。
というわけなのでnvCUDA_sha1由来の部分だけ書き換えてから もう一回GPLv3でソースを含めて配布することにします。
話がループに入ったな。w からんできてる名無しが問題にしてるのは再配布してることじゃなくて、 ライセンスを勝手に設定してることなんじゃないのか。 原作者はいじろうが再配布しようが気にしそうにはないけど。 つーか、パクったことを隠してバイナリだけを配布してる訳じゃないし。 ついでに俺様らしい意地悪なことも書いておこう。www 許可を求めたのは俺様で、「構わぬ」という返事は俺様宛であって見ている人全員じゃないだろ。(和良
特にGPLで配布することに問題は感じませんけどね。自分がGPLで 配布しても、元のコードの著作権は氏が保有してるわけですから 氏の権利が制限されることはありません。 > 「構わぬ」という返事は俺様宛であって あの書き方を見る限り誰が再配布しても構わないようでしたけど。
もちろん勝手に商用ライセンスを設定したりするのはまずいですけど、 GPLは改変したソースコードの公開を強制するライセンスですから ライセンスなしやBSDで配布するより安全でしょう。
「元のソースのライセンスが不明確(「見せる」のが目的で「弄る」ことを禁止されている可能性がある)なのに勝手にソース弄って公開したら駄目だ」とか 「元のライセンスがGPLと互換性がないのにGPLにしたら駄目だ」とかならまだ分かるけど 「元の作者が派生物にGPLをライセンスすることを意図していないかもしれないのに勝手にGPLにしたら駄目だ」なら理解できない ライセンスの決定権は派生物作者にあるんだから、文句があるなら自分でプログラム書けという話。 ま、GPLは名無しが勝手に色々弄る場所に向いたライセンスとはあまり言えないと思うがね。ある意味非常に厳しいライセンスだし。 しかもバイナリ配布時にソースを添付しないといけない訳でも、ネット上でのソース公開を強制するものでも、バイナリ無償配布を強制するものでもない。 > 見ている人全員じゃない 2人がプライベートで話したのではなく、BBS上で公に書いた以上、それは解釈に無理があるだろう。
>>88 ん?GPLのプログラムを売ってはいけない決まりはないぞ。販売もフリーのライセンスだから。
>>90 もちろんそれは理解してますけど、GPLは商用ライセンスじゃないでしょう。
>>87 やっぱり理解してないな…
何でしばしばGPLと互換性があるライセンスなのかどうかが問題になるのか考えてみよう
>>93 GPLがviralだということは十分承知してますよ。だからこそGPLを選んだんですけど…
もちろん私がGPLv3で改変物を配布しても、◆Horo/.IBXjcg氏は自分のコードは好きに
できるので、別のライセンスを選んで配布することは自由です。
例えば私が変更を加えたTripperをGPLv3で配布しても、オリジナルはHoro/.IBXjcg氏の 著作物なので氏がBSDライセンスやX11で配布することが出来ます。私がGPLを使うことに 反対されてる方々はここらへんを理解してないのでしょう。
>>93 の話は著作権者以外の人間がライセンスの異なるソフトウェアをマージする
ときに発生する問題であって、Tripperの著作権者である◆Horo/.IBXjcg氏には
あてはまりません。
というわけで自分は
>>85 の方針で全く問題ないと考えるので、
今後この話は◆Horo/.IBXjcg氏との間だけでさせて頂きます。悪しからず。
聞いたのが 2010/10/24 で返事が 2011/06/20 。 さて次の降臨はいつだ。w なんというかさすがソフトウェア板。 ライセンスがどうのに厳しいな。 待て屋スレその他でもいろいろいじめられたし。 結局GPLと言いながら要件を満たさないまま放置してる俺様カコイイ!
>>95 >>82 にもあるが、やっぱりベクトルは違うが理解してない度は同レベルだな
グレーのままで置いておけばいいものを…
>>98 > 聞いたのが 2010/10/24 で返事が 2011/06/20 。
> さて次の降臨はいつだ。w
今年はもう現れてくれないんじゃないですかw
もちろん来てくれることに越したことはないですけど…
> 結局GPLと言いながら要件を満たさないまま放置してる俺様カコイイ!
こりゃいかんがな (´・ω・`)
まあそのうち最適化が十分進んで 知らない間に元のコードがなくなるぐらいになりますよw 次に考えてるのはCUDA内のヒット判定の最適化です。 trip[0]からtrip[4]までの6bits * 5 = 30bitsと 大きさが2^30bits = 128MBの巨大なビットマップを使って、 トリップがパターンにマッチするかどうかをほぼO(1)で 判定できるようにする予定です。 これで検索するターゲットの増加による速度低下はほぼ0になるはずですけど、 うまくいくかしらん。
試しに何も変更しないで5000個のターゲットを試してみたら、 いつまでたっても最初のサイクルが終わりませんでしたw 6完500タゲでも112M tripcodes/sという微妙すぎる結果に。 6完1タゲが788M tripcodes/sなのでえらい速度低下です。 これはなんとかしないと…
これ、ループの最深部でのヒット判定がO(N)なのが問題なんだよな。 こりゃ遅くなるわけです。
>>99 「人と人とは理解し合えない」って偉い人が言ってたよ。
『事実』と『妄想』はきっちりわけて、
『妄想』はなるべく垂れ流さないようにしてる俺様だが、
あえて言おう。カs・・・・・おっと違う。w
原作者はどうしようと文句言う気なんかないんじゃね?(妄想
つか、妄想で物言うヤツ大杉。
そこで、なんとか粒子の登場ですね。
「僕が一番CUDAをうまく使えるんだ」ってなもんですかw さっさと書き換えてソースを公開したいけど、用事ができてしまい時間がなかなかとれません。 その間にアイディアは溜まっていく一方で、ちょっともどかしいです。
まさにチラシの裏にでも書いてろ。
>>97 のコードをコンパイルしてみました。
あっさり通ったので、とりあえず生成したトリップを元に
新しいコードの検証をしてみたいと思います。
余計な部分を取り除いてから、CUDA Cに移植する予定。
>>109 そのソースをコンパイルしたバイナリをCUDA C(ry
新しいコードはあっさりと動作確認できました。
用意された関数を呼び出したんですが、
Tripperと
>>97 のコードで同じ結果が出ています。
> 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のマクロがよくわからんと書いてましたけど、 私もさっぱりわかりませんw まあ動いてるからいいや。 食事食べてからCUDA Cに移植しよっと。
よく考えたらこの関数ってCPUでトリップコードの検索をさせるのにも 使えるんだよな。
よっしゃ、一発で動いた! しかも元のコードより速くなっててテラワロスw
んなつまんない物作んないでzipとかrarの暗証解読作れや
と思ったら勘違いだった orz 5パーセント近く遅くなってるな… まあでも一発で動いただけでもよしとしなきゃな。 これから最適化するか…
>>115 あ、これは完全に遊びなので、そういう人に迷惑がかかることは
やらないのです。
ちょこちょこといじったら元のコードよりも速くなりました。 ループの外に処理を追い出したり、配列の代わりに定数をつかうように したりしただけですが… コンパイラの最適化が甘いらしく、ちょっとしたことですぐに速度が 変わってきます。 なんにせよコードもすっきりしたし、言うことなしです。 ちょっと心配だったけどほっとしました。 最終確認をしてからソースを含めてうpすることにします。
というわけで新しいバージョンです。ソースも同梱されています。
CUDA SHA-1 Tripper 0.2.1 MERIKEN's branch 0.01 alpha 5
http://bitly.com/r0jVWJ 出所不明のコードをGPLv2でライセンスされたもので置き換えてあります。
また、前のバージョンに比べて多少速度が上がって表示画面が見やすく
なっています。
止まったがな・・ 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.
122 :
名無しさん@お腹いっぱい。 :2011/08/10(水) 23:06:13.69 ID:l0RyWmohO
基本的な質問ですいません。。 トリップがあるのですが、そのキーを忘れた場合はどのようにどうしたら良いのでしょうか?
>>122 専ブラの履歴もしくは、その専ブラのフォルダ内のいづれかのファイル内に残ってないの?
で、どうするかだけど、そのトリップは本当に貴方が使っていたものかどうか?というのが
分からないと、他人になり済まそうとしている可能性もあるわけで。
その辺、証明できるものはある?
wiz7 の前方一致・後方一致・位置指定なし、それぞれ65536タゲまで指定できるバージョンを作りました。 Ver 0.01 RC011 と使い分けたら良いかもしれません。 【cudaTripper12Wiz7 - CUDA版12桁トリップ検索ツール】 アップデートしました(cudaTripper12Wiz7 Ver 0.01 RC012 by iincho)。 今回の変更は以下の1のようです。 なお、このバージョンを "current stable version candidate 2" とします。 1.前方一致・後方一致・位置指定なしで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タゲ(前方一致)
激しく誤爆(*‘ω‘ *)www
126 :
名無しさん@お腹いっぱい。 :2011/08/11(木) 00:17:57.64 ID:Qvv5g6fwO
スレッドに張り付けてあるんでそのスレは、気付いてお気に入り登録したので判ります! 証明出来るもの自体がわからないんです。。
>>121 > 止まったがな・・
報告ありがとうございます。本当に助かります。どうもNumber of Blocksが
少ないと落ちてしまうみたいですね… ちょっと調べてみます。
オプションで"-x 1"を指定したら100%おちました/(^o^)\
>>124 あ、どうも〜 これだけタゲが増えても速度が落ちないのは凄いですねえ。
新しいコードが原因かと思ったけど、コメントアウトしても まだ発生します。とりあえず一安心ですが何が原因なんだろ。 CUDAのコードじゃないのかな…
やれやれ、やっとバグが取れたわい。 コードを書き直す過程で混入していたみたいです。
>>128 のアイディアを試してみたけど、
速度低下が激しく使い物になりませんでしたorz
やはり256個のスレッドが128MBのメモリにランダムアクセスするという
のは無理があったみたいです。もうちょっとテーブルを小さくすれば
使い物になるかな。
テーブルの作成をしている傍らで気になっていた不具合をいろいろ
潰しました。
特に問題だったのが、
>>103-104 で報告したターゲットの増加に伴う
速度低下の不具合でしたが、マッチ判定の部分をいじったらかなり
改善されました。
6完500タゲ 112M → 555M
6完5000タゲ 測定不能 → 162M
だいぶましになったけど、
>>124 の数字と比べるとやっぱり
見劣りするなあ… どうしたものか。
テストン =========== 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.
>>135 > 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使えば追えるだろ
うちのPC、XPでParallel Nsight使えないんですよ… どうやら落ちてるのは本体側のコードらしいので、 休憩してから追ってみます。
141 :
名無しさん@お腹いっぱい。 :2011/08/11(木) 19:32:16.76 ID:Qvv5g6fwO
トリップキーを忘れてしまいました。 検索出来る方、方法があれば教えてもらえませんか? もし教えてもらえたらサブアドレス貼りますのでよかったら教えて下さいm(__)m
逆引きナンテ技で・・・・>140
>>141 このスレまでこれたのなら、自力で何とか出来ないかお前。
>>140 逆引き? なんでしょうそれは…
>>141 似てるのならいくらでも作れるけど、完全一致となると無理ですねえ。
GPUが85度の状態で24時間動かし続けてたらpower throttlingが頻繁に起こるように なってしまいました。ファンの回転数を調整して70度にしたら安定してきました。 うるさいですけど、やっぱりあまり無茶はできませんね。
どうやら新しく書いたCUDA用のヒット判定のコードがエンバグしてる模様。なぜだ…
ようやくバグが潰せたみたいです。コードがすっきりした分速度も上がりました。 6完500タゲ 112M → 555M → 721M → 727M 6完5000タゲ 測定不能 → 162M → 720M → 725M あと、N=1の特殊なケースの際も性能が数%向上しています。 ただターゲットの数が多いケースではビットマップの効果が大きいのですが、 ターゲットが数が数個の場合はグラボのメモリに対する大量のランダムアクセスのおかげで かえって性能が落ちるようです。できればランタイムで最適な方法をえらべるようにしたいところ ですが…
…まだたまにCUDA側のコードの出力が化けるなあ。 まあいいや、無効な出力は処理しないで飛ばしてしまおう。
元のコードでなんでわざわざ出力用の配列をループの最後で0にクリアしてるのか 不明だったけど、こういうことだったんだな。
試しに英単語のリストを使ってターゲットを65536個にしたら、677M tripcodes/sがでました。 ほとんど速度が落ちてないですね。素晴らしい。
192K個のターゲット(8〜12完)で651M tripcodes/sが出たのでかなりいい感じです。 ちなみに256Kではプログラムが落ちてしまいましたw さすがに無茶ですね。
おかしな出力を調べるために色々仕掛けをして、しばらく動かしたまま放置しておくことに。 うーん、どうなるか楽しみだ…
化けた出力はかなり不思議なことになっていました。 てっきりメモリがどかっと書き換えられているのかと思ったら、 そうではなくて特定の数バイトだけがおかしくなっています。 ひょっとしたらこれ、グラボをオーバークロックしたからかもしれんな。 もとに戻して試してみよう。
やはりOCが原因だったようで、元に戻したらエラーは出なくなりました。 メモリを頻繁にアクセスするようになったからこんなふうになったんだな。やれやれ。
154 :
名無しさん@お腹いっぱい。 :2011/08/12(金) 16:46:16.80 ID:LH7k2nKmO
>>143 12ケタなんですが…
2ちゃんねるの高校野球版でベスト8ん当てるスレがあるんですが…今まで生き残ってはいるもののトリップを忘れてしまい、証明が出来なくて。
泣けてきそうです(*_*)
155 :
名無しさん@お腹いっぱい。 :2011/08/12(金) 16:56:18.39 ID:LH7k2nKmO
文字と数字を組み合わせたキーなんですが… ある程度のパターンは覚えてるんですけど、それを試す場所と時間がなくて。携帯からなんで。 トリップテスト版や本文に何も入れなくて試したんですが(80回)ほど時間がかかり過ぎて! 助けてもらえないでしょうか(>_<)
>>154-155 助けてあげたいのはやまやまですけど、どこにも残っていないなら復元は無理です。
そのためのトリップなんですから。スレ違いなのでもう返事はしないので、悪しからず。
157 :
名無しさん@お腹いっぱい。 :2011/08/12(金) 18:16:58.07 ID:LH7k2nKmO
すいません。お邪魔しました
独り言形式だと敵を作ると思うので、報告形式にした方がいいかと… 応援してます、頑張ってください。
あ、これ考えるのの手助けに書いてるようなものなので… とりあえずこのまま続けて、問題が出てきたら変えるようにします。
なんにせよ応援ありがとうございます。 色々付け足したい機能があるので当分の間はせっせと取り組むつもりです。
これまでCUDAのコードのループの最深部で、どの探索方法を使うかについて 分岐させてたのですが、1つの分岐のコストがしゃれにならないので、 マクロを多用してケースごとに関数を作ることにしました。 可読性? なにそれおいしいの? という感じですが、 その結果ターゲットの数が少ない場合の速度がかなり改善されました。 こんどこそ最初のバージョン(0.01a1)より速くなってるはずです。
ほぼ満足行く最適化が出来たので、細かい部分の修正に入りました。 幾つかオプションを追加しました。 -b: ヒットしたらビープを鳴らす。 -i: 無効なキー(Unicode非対応)のトリップコードも出力する。 後やりたいのはターゲットの数の上限を取り払うことです。 ここまでできたら次のバージョンを"0.01 beta 1"として公開したいと思います。
上限を取っ払うついでに色々コードを書き換えたらまた不安定に… 後もうちょっとなんだけどなあ。
…どうもまたOCがらみのようです。紛らわしいから開発の最中は切っておくことにしよう。
OCを切ったら気持よく動いてくれています。よかったよかった。
19万タゲで試してみましたが、速度低下も1タゲと比較して14%程度に抑えられています。
5日前のこと(
>>103-104 )を考えると夢のようですw
この拡張は正規表現への対応の下準備なので、これぐらい性能に余裕があると安心です。
というわけで>18、
>>30 と
>>62 に続けて最高速の測定をしてみました。
> 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.
最高速がやたらと大きいのは測定の間隔を短くしたためですが、
平均を
>>62 と比べても微妙に速くなっています。
やはり1タゲだとかなり無茶ができます。
明日配布パッケージをまとめて、うpしよっと。
書き忘れてた。今回の変更点は以下になります。 ・ターゲット数の制限の撤廃。多ターゲット時の大幅な速度の向上。 ターゲット数が少ない場合の速度もちょっとだけ上がっています。
今後の予定として今考えている追加機能は、これぐらいです。 ・正規表現による検索 ・10桁トリップの検索 ・CPU検索 ・速度測定による動的な探索アルゴリズムの選択 (線形・2分探索、キービットマップの使用・不使用) ・GUIの実装 ・元のコードの書き換え 正規表現への対応が、内部のデータ構造に与える影響が一番大きくて 頭をつかうので、これから手をつけようかな。9月からまた忙しくなるから 時間のあるうちに片付けておこう。これについてはずっと考えていて、 もう頭の中でアルゴリズムは出来上がってるので、後はせっせと コーディングをするだけです。
ダウンロードしてくれてる人はいるみたいだけど、ちゃんと動いてるのかな〜 うちでは絶好調で動いてますけど、環境が変わると違うから、ちと不安です。 さて、今日は正規表現への対応の下準備をしていました。 オリジナルのTripperでは、CUDAのコードではトリップの最初の5文字を 使って一致しているかどうか判定していて、残りはCPUが調べています。 いまやっているのは、この「最初の5文字」という制限を取り払って、 CUDAのコードで任意の位置の5文字を比較できるようにする、ということです。 そのために色々内部構造を拡張しているのですが、CPUとGPUの アドレス空間の違いを常に意識しなければいけないのでかなりめんどくさいです。
配列のサイズを決めうちにすればこんなに悩まなくて済むんですけど、 このプログラムには余計な制限は一切付けない方針です。 あ、あともう一つ新しいオプションを付けました。 -w: 速度が急に低下したら警告する。 グラボをOCしてるときにひんぱんにpower throttlingがかかって 速度が低下したので、念のためこのオプションを追加しました。
まあ普通に考えたら何万も何十万もターゲットを設定するわけないんだから、 反応が薄くても仕方ないよなw やっぱ本命はあくまで正規表現と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これぐらいがふつうですよね・・
やかん板に降臨。 と思ったら、ここにはまだか………。
自慢屋さん乙↑
>>9 CUDA 4.0でFermiに最適化したコードを吐かせると30%も速くなるのかや。
>>42 Mapped Memoryは面倒そうじゃが、上手くいったときのメリットも大きそうじゃな。
>>69 ただのパスワードクラッカーの作成や利用そのものが法に触れるような国はどこかの?
仮に法に触れるとすれば、それはそれでそんなものを参考にしてツールを作るのは倫理的にどうなんだという話になりかねんしの・・・
>>103-104 ヒット判定自体が重いことに加えて、ワープ・ダイバージェンスの問題も起きていそうじゃな・・・
>>112 理解できなんだのは別の部分なのじゃが、まああのマクロも1から書けと言われると厳しいの。
>>146 グローバルメモリへのアクセスは色々と面倒じゃから、ビットマップを使うという発想はなかったの。
>>167 早速見せてもらっているのじゃが、こういうマクロの使い方もあったとはの w
>>169 正規表現や10桁トリップへの対応は相当な作業量にならないかの。
>>170 分岐が多発する状況はかなり気を使う必要があって面倒じゃな。
>>171 GTX 580のOCは消費電力も凄そうじゃの・・・
>>173-175 いつもありがとうございます。そちらで無事に動いているのが
確認できてほっとしました。でも19万ターゲットは普通じゃないですw
複雑な正規表現が展開された時のことを見越して性能を上げておいたのです。
>>178 わざわざお越しいただいてありがとうございます。
公開してくださったコードのおかげで楽しく遊ばせていただいてますw
改変したものは、問題がないと判断してGPLv3で公開しましたが、
もし問題がありましたら、一言いただければ直ぐに対処させて頂きます。
>>179 > 早速見せてもらっているのじゃが、こういうマクロの使い方もあったとはの w
あれはCのプリプロセッサが貧弱なので見た目がひどい事になってるだけですw
> 正規表現や10桁トリップへの対応は相当な作業量にならないかの。
正規表現対応のCUDA側の準備は終わったのでなんとか頑張ります。
10桁トリップももうコードがあるのでなんとかなるでしょう。
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/des.c > GTX 580のOCは消費電力も凄そうじゃの・・・
Tripperをはしらせるだけで200W近く跳ね上がります。部屋が暑いです…
----
てっきり当分来られないものだと思い込んでいたのでびっくりしましたw
わざわざコードまで読んでいただいて光栄です。
1年後とおっしゃらず、またぜひお越しください。お待ちしております。
| \ __ / _ (m) _ピコーン |ミ| / `´ \ ('A`) ノヽノヽ くく さっきこんな感じでひらめいて、最小限の手間で 前方一致だけでなく任意の位置の文字列を探索する機能が実装できました。 後は本体側で正規表現を展開する処理を実装すればいいだけです。
…「いいだけ」ってかいたけど結構な作業量ですよね、これ。 まあ技術的に一番難しい部分は解決したわけだからいいか。
とりあえず"target_regex.txt"にターゲットを書き込むと 任意の位置で検索できるようにしました。速度は20%以上 落ちますがまあこれは仕方がない。あとは今後の最適化次第です。
>>181 楽しんでもらえて嬉しいでありんす。
わっちが書いた部分は構わぬというか、改造版を見て楽しんだりとかを考えるとライセンスの衝突が無ければその方が良さそうじゃの。
>>182 演算量に対してホスト・デバイス間のデータ転送量が十分に少ないから差が出にくいのかの。
DMCAは範囲が限定されておるが、それでもかなり議論になっておるの。
EUの方ではクラッキングツールの違法化を唱えておる者もおるみたいじゃが、愚かなことにならなければいいがの・・・
>>182 メモリ使用量的には富豪的とは思わぬが、グローバルメモリへのアクセス、それもランダムなのが気になるのじゃが
アクセスにかかる時間は大量のスレッドで隠蔽できておるということかの。
>>183 あの巨大なマクロは一部が異なる関数を多数作るのに利用しておるのかや?
DESベースのcryptをCUDAで実装するのは色々と苦労しそうじゃが、
主様はわっちよりかなり頭が良さそうじゃから期待していいのかの? w
消費電力が増加分だけで200Wとはハイエンドのグラボとは怖ろしいものじゃの・・・
>>184 >>186 どうやっておるのか気になるの。
その方法を考えながら待つというのもまた楽しいがの w
>>187 > 楽しんでもらえて嬉しいでありんす。
> わっちが書いた部分は構わぬというか、改造版を見て楽しんだりとかを考えると
> ライセンスの衝突が無ければその方が良さそうじゃの。
そう言っていただけるとほんとうに有難いです。
> 演算量に対してホスト・デバイス間のデータ転送量が十分に少ないから差が出にくいのかの。
いったん準備が整ったらCPU側ではCUDAのメモリはいじらないですからね。
> DMCAは範囲が限定されておるが、それでもかなり議論になっておるの。
> EUの方ではクラッキングツールの違法化を唱えておる者もおるみたいじゃが、
> 愚かなことにならなければいいがの・・・
経済活動のために自由を制限しようという動きは活発ですからね。心配です。
>>188 > メモリ使用量的には富豪的とは思わぬが、グローバルメモリへのアクセス、
> それもランダムなのが気になるのじゃが
> アクセスにかかる時間は大量のスレッドで隠蔽できておるということかの。
これはアクセスするメモリの量によってだいぶ変わってきます。
最初は30bitのtarget_dwに直接対応する2^30=1GBのキー・ビットマップを試してみた
ですが、かえって遅くなったのでサイズを2^24=16MBに減らしました。
ビットマップのサイズは可変に出来るので、いずれは動的に最適化する予定です。
ビット単位で変えて速度を測定するのもいいかもしれません。
> あの巨大なマクロは一部が異なる関数を多数作るのに利用しておるのかや?
そうです。CUDAのコードのループの中に条件文を書きたくなかったのでああなりました。
あまりの大きさに、書いてて自分でも笑っちゃいましたけどw
> DESベースのcryptをCUDAで実装するのは色々と苦労しそうじゃが、
> 主様はわっちよりかなり頭が良さそうじゃから期待していいのかの? w
この論文によればGT200シリーズで75.2Mkey/sがでたとあるので、
何とかできると思います。(5ページ目には実装の詳細があります)
Record Setting Software Implementation of DES Using CUDA
http://home.dei.polimi.it/barenghi/files/ITNG2010.pdf 10桁トリップの検索はどうしても欲しい機能なので、頑張りますです。
> どうやっておるのか気になるの。
> その方法を考えながら待つというのもまた楽しいがの w
数日中にα版を公開する予定なのでご期待くださいw
というわけで早速正規表現展開用のスタックを実装して、 正規表現の"^"と"$"が使えるようになりました。 処理の枠組みはできたので、あとはごりごりとパーサの 残りを実装するだけです。
もちろんあまり複雑にはできないので、適当なサブセットで 落とし所を見つけるつもりです。今のところ考えているのは "."と"[]"と"[^]"と"*"と"+"と"()"と"|"ぐらいです。 このパーサの目的は、「可能な組み合わせをすべて出力する」ことなので、 「特定の文字列が街しているか調べる」普通のパーサとは ちょっと趣が異なっています。
とりあえず"[:digit:]"はできました。 こんな感じでパターンがかけます。 > ^[: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億パターンに挑戦してみましたが、 さすがにメモリ不足で怒られましたw でもこれ、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.
と、ここまで書いて気づいたんだけど、別に6文字目以降は 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:]*$ # 数字のみ
いかんいかん、間違えてるぞ。"^.*$"は12連じゃないや。 '.'を展開してから伸ばすんじゃなくって、'.'を伸ばしてから 展開するんだった。意外に難しいな…
そうか、最初にちゃんとトークンを切り出してやらないと駄目なんだな… φ(..)メモメモ
せっせと正規表現のパーサを実装中。こんどこそ’.'と'*'への対応が終わりました。
演算子の優先順位を間違えてエライ目に遭いましたが、なんとか直せました。
あとはカッコと'|'と"[]"への対応が済めば、パーサは完成。色々試してみたいので楽しみです。
これさえ終われば、パターンの比較用に特殊文字を実装して最適化したら、
正規表現への対応は完了です。うまくやれば、
>>197 みたいなケースでも
正規表現を展開せずに済むようになるはずです。今日はもう時間がないから
明日にしようっと。
(⌒,,⌒)〜っ (⌒,_, ,⌒て ,,_,) ! ノ U。`yヘ_,、_ノ ! し|~〜〜 。 ヘ⌒iヽフ |! ゚o 。.゚(・ω|・ ) おつかれ |! 。o゚ ⊂ ゚ とノ |i 。゚ ゚ o .゚|.。|. | |i、..゜。。゚ ゚し|'J . |,,._二二二_,! 。゚o
後方一致とcpu検索が欲しいです…
>>190 UINT8で2^24個というのはそういうことだったのかや w
巨大なビットマップで1byteに1bitは富豪的すぎるかも知れぬの。
しかしビットマップでヒットした場合に別の方法で改めて検索するというのはなかなか面白いの。
BitSlice DESをCUDAで実装すればGTX 260で373Mkey/sかや・・・
crypt()に応用したときにどのくらい速度が出るかも含めて気になるの。
>>202 あ、どうもw 美味しくいただきますです。
>>203 後方一致は正規表現の一部としてもうつけちゃったので、次に公開する版で
使えるようになります。最適化してないので前方一致ほどは速くないですけど…
CPU検索はWin32のスレッドの使い方さえわかればすぐに実装できるはずなので、
10桁への対応が終わったら取り掛かります。
>>204 あ、みえてたんですね。こんばんわ〜
>
>>190 > UINT8で2^24個というのはそういうことだったのかや w
> 巨大なビットマップで1byteに1bitは富豪的すぎるかも知れぬの。
>
> しかしビットマップでヒットした場合に別の方法で改めて検索するというのはなかなか面白いの。
最初は真面目に8bit全部使ってたんですけど、それだと速度的においしくないのでやめましたw
2段構えになっちゃったのは偶然ですけど、ほとんどのケースでO(1)でヒット判定ができるので
結構うまく動いてると思います。
> BitSlice DESをCUDAで実装すればGTX 260で373Mkey/sかや・・・
> crypt()に応用したときにどのくらい速度が出るかも含めて気になるの。
これはほんとうに楽しみです。正規表現を速く終わらせてこっちに取り掛からねば…
打倒mty!
さっき思いついて、N=1のケースでループ内のグローバルメモリへのアクセスを1つへらしたら それだけで3M tripcodes/s以上速度が上がりました。やはりグローバルメモリへのアクセスは なるべく避けたほうがいいみたいですね。 まだ最適化の余地があったのには驚きましが、ターゲットの数が少ない場合はスレッドの ローカルメモリ(8K)かマルチプロセッサ内の共有メモリ(48K)をつかえば更に高速にできるかもしれません。
>>207 > 打倒mty!
10桁でGPU版待て屋を超えるのが目標ですけど、はたしてどうなるんでしょうねw
ゲフォ対ラデだと圧倒的に不利だろ。w 同じハードウェアならともかく。
そこを工夫するのが面白いんじゃないですか。 CUDAにも大分慣れてきたし、わかりませんぞw
>>206 8bit全部使うと速度的にというのがよく分からんのじゃが、ビットのテストのコストが意外と大きいということかの?
バイナリサーチやリニアサーチを行う確率が1/(2^24)になるのは結構おいしそうじゃの。
>>208 グローバルメモリはアクセスに数百サイクルかかるのじゃったかの・・・
ローカルメモリ(8KB)はコンスタントメモリの間違いかの?
シェアードメモリはFermiでは48KBみたいじゃが、それ以前のものは16KBみたいじゃから
環境依存を減らすならそのあたりも気をつけたほうがいいかも知れぬの。
2^16分のビットマップを8KiBにしてシェアードメモリに乗せてみるのも面白いかも知れぬの。
OpenCL で作ったトリッパーをゲフォとラデで走らせてみたが、 その差は歴然だった。(同一バイナリでw) まあ、AMD が OpenCL に力入れてるってのもあるかもしれんが。 あと某外人がやってるのを観察してるんだが、こんな感じだな。 GeForce GTX580 670M Radeon HD 5770 680M 580でも5770に勝てないレベル
>>212 >
>>206 > 8bit全部使うと速度的にというのがよく分からんのじゃが、ビットのテストのコストが意外と大きいということかの?
何日か前に試してみたときにはそうでした。勘違いかもしれないので、ビットマップの最適化を
するときにもう一度調べてみます。
>
>>208 > グローバルメモリはアクセスに数百サイクルかかるのじゃったかの・・・
>
> ローカルメモリ(8KB)はコンスタントメモリの間違いかの?
per-threadのメモリのことだったんですけどサイズは16〜512Kの間違いでした。
> シェアードメモリはFermiでは48KBみたいじゃが、それ以前のものは16KBみたいじゃから
> 環境依存を減らすならそのあたりも気をつけたほうがいいかも知れぬの。
これは知りませんでした。危ない危ない…
> 2^16分のビットマップを8KiBにしてシェアードメモリに乗せてみるのも面白いかも知れぬの。
これは実に興味深いです。後で試してみます。
しかしアーキテクチャのことを知ってるのと知らないのでは大違いですねえ。 GPGPUはかなり奥が深いですね。
>>213 OpenCLは極限まで性能を引き出そうとすれば、アーキテクチャ毎にコードを書かなければならないとかいう噂もあるからの・・・
演算性能の理論値的にはRadeonの方が上みたいじゃが、良くも悪くもAMDは理想が高くて
Radeonのアーキテクチャもまた変更になるという話もあるからの。
ハッカーレベルの者やチャレンジャー以外は、CPUとGPUの開発環境レベルでの統合が落ち着くまで様子見というのも少なくないかも知れぬ。
>>214 per-threadというとローカルメモリじゃと思うが、ハードウェア的にはグローバルメモリと同じで
オフチップでグローバルメモリと変わらない、というか全スレッドで共有できない分
1スレッドが使えるメモリが減ってデメリットばかりの気もするの。
>>216 10桁版ならcrypt()じゃから100M出れば十分というか、それでも凄いと思いんす。
>>217 > per-threadというとローカルメモリじゃと思うが、ハードウェア的にはグローバルメモリと同じで
> オフチップでグローバルメモリと変わらない、というか全スレッドで共有できない分
> 1スレッドが使えるメモリが減ってデメリットばかりの気もするの。
なるほど… さっきN=1のケースで速くなったのは、配列へのアクセスが無くなった
せいかもしれません。もうちょっと調べてみます。
先ほど"[]"の実装がようやく終わりました。 例えば"[Nn][Uu][Ll][Pp][Oo]"と指定すると、"nullpo"や"NULLPO"や"NuLuPo"や"nullPO"に マッチします。ちゃんと'-'や'^'での文字範囲の指定もできます。 ようやくこれで'*'や'+'の使いやすくなりました。
>>220 >
>>213 は SHA-1 での値。
ですよね〜 それにしても5770の数値が高すぎるような気がしますけど…
> 鳥屋先生の皮算用wでは、SHA-1 なら DES の 5 倍は速度が出る、らしい。w
ほんとかなあw ますます580でDESの速度を試してみたくなりました。
> まあそのスレ見てんなら知ってるだろうけど、
>
ttp://yy43.60.kg/test/read.cgi/tripageruo/1274911652/305 > って状態だが。
このレスは読んでませんでした。なかなか面白い数値が出てますね。
やっぱデュアルコアの6990にシングルコアの580で対抗するためには
SLIにするしかないのかなあ。マザボと電源を変えなきゃいけないから
当分の間は無理ですけど…
> OpenCL で作ったヤツは、同一バイナリで CPU でも動くんだがこれがやたらと速い。
> たぶん、俺がなんかミスってるというオチの悪寒がするが。w
ヒット率を理論値と較べてみると捗りますよ。
このプロジェクトが一段落したらほかのGPGPUの環境もしらべてみよう。
単一のバイナリでどの環境でも動けば最高だけど、実際どうなんだろう…
頑張って'|'演算子を実装。あとは括弧の処理を書き終わればパーサは完了です。 なんかここ最近で一番頭を使った気がするw
デキタ━━━━(゚∀゚)━━━━ッ!! ようやく正規表現のパーサが出来ました。色々試してみたけど、かなり強力です。 例えば、 ^([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 . . ."以下に平均時間が表示されます。
>>223 の例では4年になるのでまず無理ですねw
さて、後は最適化を残すのみです。
正規表現の展開によるパターン数の指数関数的増加(
>>194 、
>>197 )を
抑えるために、内部用の特殊文字を導入したいのですが、
この変更ではかなりプログラムの内部構造に手を入れることになるので
ちと心配です。まあでもいまさらだからいいかw
とりあえず数字の分だけ終了。"^[:digit:]*$"と指定すると、 数字だけのトリップがわさわさ採れます。 だいぶ気をつけてコーディングしたかいがあって、効果は抜群です。 今日はこれぐらいにして続きは明日やろう。 首尾よくいけば明日には正規表現対応のバージョン0.02b1を うpできるはずです。 ---- 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
と_)_) 旦
>>226
>>227 |ヘ⌒ヽフズズー
| ・ω・)
|つC□)
ありがとうございます。ほかの特殊文字も追加したら
大絶賛エンバク中ですw 今日中に治るといいなあ。
でもこれ、ヒット率を理論値と較べる機能がついてなかったら 完全にバクを見逃してたよな。つけといてよかった。 理論値はかなり真面目に計算してるので、またぜひコードを みてやってください。
特殊文字を比較してるルーチンでとんでもない打ち間違いを発見。 こりゃヒット率が落ちるわけだ。 で、バクをひとつ直したと思ったら今度は謎のスピード低下。 すんなり行くかと思ったけど、やはり一筋縄ではいかないですね。
スピード低下は勘違いでしたw いろいろ実験してる時にGPUに 無茶させすぎてるせいかpower throttlingがかかりまくりです。 GPU-Zの特殊オプションでいちいち解除してるんですけど メンドクサイので、GUIをつけるときには解除する機能を つけたいです。
GUIアプリならPCを使ってない時だけフルスピードで走らせるとか、 色々アイディアはあるんですけど… とりあえず必要な機能を 揃えてからですね。
今日は仕上げとして展開されたパターンのコリジョンを処理するコードを書きました。 特殊文字を使うと効率はよくなるのですが、次のような正規表現の場合に困った事になります。 NUL.PO NULLPA この場合どちらが先になるかわからないので、ヒット判定の時のCPU側のbinary searchの ルーチンが正しく動作しません。これは正規表現に対応していないオリジナルにはなかった 問題ですが、'.'を展開するルーチンを組み込んで解決しました。思わないところで問題が でてくるものですが、うまくいったと思います。
というわけで、正規表現の対応はこれで完了しました。 前方一致でない検索で極端に遅くなるケースが確認されましたが、 この問題への対処はランタイムでの最適化に対応するまで後回しにする予定です。 これから新しいバージョンのパッケージを用意するのでちょっと待っていて下さい。
( ゚д゚ ) ガタッ .r ヾ __|_| / ̄ ̄ ̄/_ \/ /
236 :
◆MERIKEN4.k :2011/08/19(金) 14:24:37.03 ID:WHpJPhX30
ども〜 CUDA_SHA1_Tripper_MERIKEN: ERROR: There is an invalid character in a target pattern. ・・・・
238 :
◆MERIKEN4.k :2011/08/19(金) 14:41:49.07 ID:WHpJPhX30
>>237 > ども〜
>
> 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.
240 :
◆MERIKEN4.k :2011/08/19(金) 14:59:13.81 ID:WHpJPhX30
そっちはちゃんと動いてますね。 正規表現もぜひぜひw試してみてください。 こんどからサンプルには面白そうな正規表現を入れておこう。 さて、ひと段楽したけど、これからどうしようかな… もう一回スピードテストしてみようかな。
241 :
◆MERIKEN4.k :2011/08/19(金) 15:57:17.76 ID:WHpJPhX30
というわけで最高速の測定です。
> 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
(過去の記録:
>>18 >>30 >>62 >>166 )
速度測定の間隔を再調整したため今回は最高速はそれほどあがってませんが、
平均が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.
243 :
◆MERIKEN4.k :2011/08/19(金) 16:17:00.44 ID:WHpJPhX30
>>242 > 小一時間ほどマワシテミタ
あ、いい感じですねえ。
> 3% higher
これが0%、
> 9% of matching tripcodes were invalid.
これが7%に近ければ近いほどよいということになってるので、
なかなかよい具合に収束しています。今回はプログラムの内部に
めちゃくちゃに手を加えたのでちと心配だったので、安心しました。
244 :
◆MERIKEN4.k :2011/08/19(金) 16:26:27.64 ID:WHpJPhX30
さっきループの中を調べてみたんですが、 インデックスからShift-JISコードへの変換テーブルが無駄に大きい ことが判明。気前よくグローバルメモリに65536バイトの配列を 3つ用意してたんですが、最初の400バイトちょっとしかアクセスして ませんでしたw 余裕を持ってサイズを設定しても2Kすらいかないので、 こいつをシェアードメモリに移してやれば高速化できるかもしれません。 もうこのプログラムのことは手に取るようにわかるようになったので、 もう一回見直してみたらかなり無駄が省ける気がします。楽しみだ…
targetはどれぐらいいけますかね?
246 :
◆MERIKEN4.k :2011/08/19(金) 16:36:18.22 ID:WHpJPhX30
メモリが許す限りいけるはずです。 前方一致で正規表現を使わないなら数百万でも大丈夫じゃ ないでしょうか。
247 :
◆MERIKEN4.k :2011/08/19(金) 17:05:49.75 ID:WHpJPhX30
今ソースを見てて気づいたんですが、なぜか全位置検索でキービットマップを 使わない設定になっていました。おかしいと思ったんだよな… 明日不具合を修正したBeta 2をうpします。
248 :
◆MERIKEN4.k :2011/08/19(金) 17:29:36.75 ID:WHpJPhX30
最高速測定の話の続きですが、ループ内のグローバルメモリへの アクセスをもう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)、非常においしい結果に。 まだまだいけそうです。
249 :
◆MERIKEN4.k :2011/08/19(金) 18:13:33.52 ID:WHpJPhX30
CUDA側のコードのループの回数を倍にして、もう一回だけ試してみました。 > 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以上伸びたので 上出来でしょう。
250 :
◆GikoNekobg :2011/08/19(金) 19:10:56.33 ID:3wVJoHeW0
お疲れ様。
251 :
(の◇の) ◆wordlist..nn :2011/08/19(金) 21:42:18.93 ID:r12D2b3I0 BE:474063146-DIA(289888)
【GPU】GTX 460 【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 のみ
252 :
(の◇の) ◆wordlist..nn :2011/08/19(金) 21:44:40.60 ID:r12D2b3I0 BE:711093694-DIA(289888)
>>251 同じマシン同じ条件で 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
253 :
(の◇の) ◆wordlist..nn :2011/08/19(金) 21:51:11.74 ID:r12D2b3I0 BE:948125568-DIA(289888)
>>251 同じまs(r
俺様作の OpenCL トリッパーだとこんなもん。w
112.728010Mtps
254 :
◆MERIKEN4.k :2011/08/20(土) 07:45:21.62 ID:yyJEk2z60
>>251-252 あ、どうもわざわざ助かります。1タゲだと意外にオリジナルと差が出ないですね。
最適化が進んだ次のバージョンだと違うのかなあ。”-arch=sm_21"が
効いているのかもしれません。あとで調べてみます。
あと、やっぱりOpenCLの共通のコードだと厳しいみたいですね。
コードを書くときはアーキテクチャにべったりですからねえ。
255 :
◆MERIKEN4.k :2011/08/20(土) 11:34:47.91 ID:yyJEk2z60
8400GS "TEST/"のみ 7.7MTrips/sec 動いた><
あ、言い忘れ おつですおつです><
258 :
◆MERIKEN4.k :2011/08/20(土) 16:15:44.37 ID:yyJEk2z60
>>256 動作報告、ありがとうございます。
オプションで"-x 2"とか"-x 4"とか指定するともうちょっと速くなる
かもしれません。ここらへんの設定は自動でできるようにする予定です。
259 :
◆MERIKEN4.k :2011/08/20(土) 16:19:24.23 ID:yyJEk2z60
ちょっと予定を変えて、現在CPU検索に対応するための 作業をしています。必要なコードはほとんどすべて揃ってるので、 あとはメインループを書くだけなんですが、どうなるかしらん。
260 :
◆MERIKEN4.k :2011/08/20(土) 18:27:42.01 ID:yyJEk2z60
とりあえずやっつけでCPUだけでも動くバージョンができました。 > 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でした。
261 :
◆GikoNekobg :2011/08/20(土) 18:48:25.62 ID:bXewp3Y30
>>255 乙
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.
262 :
◆MERIKEN4.k :2011/08/20(土) 19:03:07.41 ID:yyJEk2z60
>>261 あ、どうも〜 いつも有難うございます。
ちょっぴり速くなってるみたいですね。よかったよかった。
263 :
◆MERIKEN4.k :2011/08/20(土) 19:06:23.71 ID:yyJEk2z60
264 :
◆MERIKEN4.k :2011/08/20(土) 19:11:58.45 ID:yyJEk2z60
というわけでcudaTripper12Wiz7を動かして調べてみたら、 うちのPhenomではCPU検索は1タゲ前方一致で11.2M TPSぐらいでした。 ちょっと安心したけど、それでもえらい差だよな… やっぱCDUAのコードを使いまわすだけじゃスピードでないよなあ。 うーん、これからどうしよう…
265 :
◆GikoNekobg :2011/08/20(土) 19:22:16.29 ID:bXewp3Y30
【GPU】GTX 460 【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]
266 :
◆MERIKEN4.k :2011/08/20(土) 19:42:24.05 ID:yyJEk2z60
>>265 お、こっちのほうがだいぶ速いですね。CPU検索分の11M TPSを差し引いても
ここまで差は出ないはずですが、ブロック数の設定のせいかなあ。
オプションで"-x 4"を指定してやるといいかもしれません。
しかしこうなるとやっぱりランタイムの設定が必要ですねえ。
267 :
◆MERIKEN4.k :2011/08/20(土) 20:00:46.62 ID:yyJEk2z60
手元のcudaTripper12Wiz7 version 0.01 RC004と比較してみましたが、 やはり改変したCUDA SHA-1 TripperのほうがCPU検索を含めても 速度が出ていました。しかしこんなことなら最新版をダウンロードして おくんだったなあ。
268 :
◆MERIKEN4.k :2011/08/20(土) 21:16:55.45 ID:yyJEk2z60
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のならきっとあるはず。
269 :
◆MERIKEN4.k :2011/08/20(土) 21:23:50.08 ID:yyJEk2z60
270 :
◆MERIKEN4.k :2011/08/20(土) 21:43:30.67 ID:yyJEk2z60
271 :
◆MERIKEN4.k :2011/08/21(日) 08:25:49.77 ID:0aXAtS7W0
272 :
◆MERIKEN4.k :2011/08/21(日) 09:33:05.09 ID:0aXAtS7W0
>>269 のリンク先を読み始めたけど、ずいぶん大事なことが書いてありました。
SHA-1のハッシュ値を計算するのに、仕様とかを見るとW[]のサイズが80に
なってるのに、オリジナルのTripperではW[]のサイズがたしか16だったので
不思議だったのですが、ようやくなぞが解けそうです。
273 :
◆MERIKEN4.k :2011/08/21(日) 10:12:04.29 ID:0aXAtS7W0
要するに、これ > 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 なるということらしいんだけど…
274 :
◆MERIKEN4.k :2011/08/21(日) 10:37:02.37 ID:0aXAtS7W0
煮詰まったのでいろいろぐぐってたら、
SSE2 IntrinsicsによるSHA-1の実装を見つけました。
http://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.
275 :
◆GikoNekobg :2011/08/21(日) 17:29:05.96 ID:RsDQXnVM0
>オプションで"-x 4"を指定してやるといいかもしれません。 遅くなった? 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.
276 :
◆MERIKEN4.k :2011/08/21(日) 17:39:47.86 ID:0aXAtS7W0
ありゃりゃ、こちらの勘違いだったようです。わざわざすいません… うーん、そうするとcudaTripperの新しいバージョンが だいぶ速くなってたってことなのかなあ。それともGTX 460に あわせて作ってあるってことなのかしらん。
277 :
◆MERIKEN4.k :2011/08/21(日) 17:43:34.72 ID:0aXAtS7W0
>>275 とりあえず"sm_21"をつけてコンパイルしてみるので、
また次のバージョンでお願いします。たぶん速くなるはずです。
278 :
◆MERIKEN4.k :2011/08/21(日) 17:44:44.58 ID:0aXAtS7W0
しかしこうして違う環境でテストしていただけると本当に助かります。 ありがたやありがたや…
279 :
◆MERIKEN4.k :2011/08/21(日) 17:45:34.07 ID:0aXAtS7W0
先ほどからSSE Initrinsicsと奮闘中ですがどうしても "_mm_store_si128"でCPU保護例外が出てしまいます。 どうしてなんだろう… "_mm_storeu_si128"でもだめだったから アラインメントの問題じゃないだろうし…
280 :
(の◇の) ◆wordlist..nn :2011/08/21(日) 18:16:25.07 ID:DGWxIzoa0 BE:790104858-DIA(289888)
横から口出ししていいもんかどうかと思いつつ。 -x 4 とか減らしてどうする。 増やそうぜ。w つか、今見たら16までにしてるけど、明らかに小さすぎるな。
281 :
(の◇の) ◆wordlist..nn :2011/08/21(日) 18:27:29.42 ID:DGWxIzoa0 BE:355547063-DIA(289888)
口出ししちゃったしもうついでだ。w アナライザで見ると、こんな感じだからまだまだ伸びしろはあるんじゃないかな。w 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
282 :
◆MERIKEN4.k :2011/08/21(日) 19:39:45.16 ID:0aXAtS7W0
あ、有難うございますw -xの上限ってオリジナルは8だったのを 増やしたんですよ。460だと16以上でもいいのかな。もうちょっと増やしときます。
283 :
◆MERIKEN4.k :2011/08/21(日) 19:41:40.38 ID:0aXAtS7W0
いまCPU用のSHA-1のルーチンをいじってますけど、 これまだ大分最適化の余地がありますね。 さっさとWindows 7に移行して、Parallel Nsightで真面目に解析してみようかなあ。
284 :
◆MERIKEN4.k :2011/08/21(日) 20:48:51.08 ID:0aXAtS7W0
SSEのほうはようやく使い方が少しずつわかってきて、高速化の目処が立ちました。 しかしこれ、物凄いくせがありますね。Intrinsicsをつかってるから 余計そう見えるのかもしれないけど…
285 :
◆MERIKEN4.k :2011/08/22(月) 04:43:20.87 ID:q3tPjXJ80
あれから自分でコードを書いたり、新しいコードを試してみたりしたんですが、 SSE2の使用による速度の増加は3割ぐらいのようで思ったほど伸びてくれません。 謎の速度低下があったりして、とんとんといったところです。たぶんこれ、 全部アセンブラで書かないと速度がでないんだろうけど、ちと荷が重いので CPU検索の最適化は後回しにして先に進むことにします。
286 :
◆MERIKEN4.k :2011/08/22(月) 05:09:42.69 ID:q3tPjXJ80
謎の速度低下の原因がわかったって、だいぶ数値が改善されました。 > 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使えば?
288 :
◆MERIKEN4.k :2011/08/22(月) 12:19:20.74 ID:kSccGppM0
>>287 > SSE2なんて化石は投げ捨ててAVX使えば?
どんな環境でもお手軽に使えるプログラムを目指してるので、
とりあえずSSE2で高速化してみます。余裕ができたらぜひAVXも
挑戦してみたいですね。
289 :
◆MERIKEN4.k :2011/08/22(月) 12:33:33.13 ID:kSccGppM0
マルチスレッド化したとたんに性能が出なくなって頭を抱えていたのですが、 ネットで拾ってきた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.
290 :
◆MERIKEN4.k :2011/08/22(月) 13:04:54.62 ID:kSccGppM0
>>289 の問題はグローバルメモリの変数を関数内に移す事で解決しました。
マルチスレッドかすると思わぬところで問題が出てきますねえ。
ともあれ、ようやくそれなりの数字が出てきたのでほっとしました。
あとはこれを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.
291 :
◆MERIKEN4.k :2011/08/22(月) 16:00:43.94 ID:kSccGppM0
CPU検索への対応が完了したので、また最高速に挑戦してみました。 【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の大台に乗せたいところです。
292 :
◆MERIKEN4.k :2011/08/22(月) 16:05:55.14 ID:kSccGppM0
というわけで、特に問題がなければ明日CPU検索に対応した バージョン0.03 Beta 1をうpします。CPUだけでもちゃんと 検索できます。
293 :
◆MERIKEN4.k :2011/08/23(火) 01:50:13.50 ID:8b4qHmgQ0
さっき気づいたんですけど、書き込むときにage続けてましたね。 失礼しました。
さて、下ごしらえは全部済んだので、いよいよこれから10桁トリップへの 対応の作業に入ります。楽しみすぐる… ここまで来るのに結構かかりましたが、CPU対応を先に済ませたのは、 これを先に終わらせておけば10桁用のコードを先にCPUで試せるからです。 10桁トリップを生成するコードさえ書いてしまえばすぐに検索できるはず ですが、果たしてどうなることやら…
296 :
◆GikoNekobg :2011/08/23(火) 06:09:05.81 ID:b0KGeLrN0
>293 乙 -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タシjby (b5 94 a6 43 4f 42 c0 bc 6a 62 82 99) ◆TEST/nVAvFAi #7幽ソ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.
>>296 朝早くから有難うございます。意外にGPUのほうは伸びないですねえ。
"-x 16"とかそれ以上にするといいかもしれません。
さっきからCUDA検索用にもうひとつCPUスレッドを追加したのですが、 思わぬところで時間を取られてえらい目にあいました。ともあれ、 これのおかげでプログラムの構造が大分すっきりしました。 メインのスレッドは他のスレッドがせっせと働いてるのを のんびりと待って、たまに結果を表示するだけです。 副作用として、将来的に複数のグラボに対応するのも容易になりました。 予算ができたらぜひもう1枚グラボを追加したいところです。 マザボと電源も交換になるのでえらい出費ですが…
>>298 正規検索もいいけど、
>>124 を参考にGPU検索は cudaTripper12Wiz7 より20%以上高速化。できれば倍ほど高速化。
CPU検索は、少なくとも cudaTripper12Wiz7 よりは高速化。
を、めざしてみてょ(*‘ω‘ *)
楽しみにしています
>>299 うはw これはハードルが高いwww
cudaTripper12Wiz7は良い目標になっているので本当にありがたいです。
10桁トリップ対応の後は、ランタイムでの診断を含めた全体的な最適化に
取り組む予定なので、何とか超えられるように頑張ります。
素のcryptを使って試しに実装してみたら、CPU 1スレッドで300K tripcodes/sしかでませんでしたw こりゃ先が長いわ…
>>302 bit-sliced DESを使わなきゃ速度でんよ(*‘ω‘ *)
『CUDAによるbit-slicedDESの実装』みたいな論文があるから読んでみれ(*‘ω‘ *)
305 :
◆GikoNekobg :2011/08/23(火) 15:59:44.04 ID:b0KGeLrN0
【GPU】GTX 460 【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)
readme読んだだけではオプション指定の方法が分りませんorz 教えてエロイ人
>>305 わざわざ試していただいて助かります。やっぱり速くなってますねえ。
これを見てからまさかと思って自分のPCで試してみたら、"-x 16"よりも
"-x 20"のほうが明らかに速いことが判明。前試してみて"-x 16"が
一番速かった(
>>26 )はずなんですけど、何が起こったのやらorz
というわけで"-x"オプションの上限を可能なかぎり上げて色々試してみたところ、
GTX 580では"-x 48"が一番速いことがわかりました。間違いかと思ったけど
ヒット率もちゃんと安定してるし、問題はないようです。
>>281 のお告げが無かったら
勘違いしたままでした。ありがたや、ありがたや。
>>306 > readme読んだだけではオプション指定の方法が分りませんorz
>
> 教えてエロイ人
普通に使う分に必要なのは"-x"だけです。"-x 16"とか”-x 32"というふうに、
マルチプロセッサあたりのブロック数を指定します。数字を変えて試してみると
よいようです。
後いろいろ付け足したのですが、まだ暫定的なものなので、次のバージョンをうpするときに
まとめます。しばしおまちを。
さっきちょこっと最高速の測定をしてみたらとんでもない数字が出てるぞ。 用事があるので、あとで試してみよう。実に楽しみだ…
OCしながら最高速の測定は時間がかかるので、後の楽しみにとっておきます。 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; } }
これ、saltの値がいたるところで使われていますねえ。 bitslice DESがcryptの実装に使えるのはわかってるんですけど、相当手ごわそうです。 他の実装を探してみたんですけど、見つかったのは"John the Ripper"だけで、これが かなり複雑で容易に理解できそうにありません。ま、他の部分の最適化を進めながら のんびりやるしかないか…
> bitslice DESの概要はわかったのですが わかってない気がする(*‘ω‘ *)…
いや、ほんとうにわかりましたからw FIPSの仕様書(
>>313 )と
Bitslice DESのソース(
>>304 )が一対一で対応しているのはわかったので、
以外に早く謎が解けるかもしれません。要はunsigned longのビット長の
数のケースを同時に処理してやることで効率を稼いでるだけで、
やってることは同じですからね。
Ln = Rn-1
Rn = Ln-1 ^ f(Rn-1,Kn)
上の演算が行われた直後にsaltに基づく値と排他的論理和をとればいいはずです。
上の処理は、25回行われるDESのイテレーション1回につき16回繰り返されるので
結構な回数ですが、コスト的にはそれほどでもないでしょう。
とりあえずUFC-cryptのsaltの処理を無効にして、Bitslice DESと同じ結果が出るかどうか ためしてみることにします。これがうまくいけば、あとはBitslice DESにsaltの処理を 加えるだけです。salt用のテーブルはUFC-cryptのものを流用すればいいはずですが、 はたしてどうなることやら…
>>316 (*‘ω‘ *)単芝はやめとこうよ・・・
あ、この単芝は普段から使いまくってるだけで他意は全く無いです。 お気になされるのでしたらこのスレでは使うのはやめておきます。
>>319 (*‘ω‘ *)やめといたほうがいいと思うね
いまだに(藁 とか書く人みたいに感じる
(*‘ω‘ *)好きで使うならもちろん勝手だけど
そうですねえ… 単芝は昔から使ってたし、ただ単に好きなだけなんですよ。 昔草の根BBSとかで「(笑)」とか打ってたのの代わりです。 あんまり気にしないでくださいな。 さて、Bitslice DESを試そうと思ったのですが、なかなか思うように動いてくれません。 unsigned long k[56]の最初のビットに56bitのキーをアンロールして p[]とc[]はゼロクリアしdeseval()を呼び出してやれば良いと思ったんだけど、ちがうのかな…
しかしこの作業、思った以上の手間になりそうだな。 SHA-1とは比較にならない難敵ですね。 面白そうだったからほとんど何も考えずに始めたけど、無知とは恐ろしいw 今後の予定としては、Bitslice DESに取り組みつつ、既存のルーチンで10桁トリップへの 対応を進めながら同時に最適化もする、ということにしたいと思います。そろそろ 本業が忙しくなってくるけど、このプロジェクトは実に楽しいのでぜひ長く続けたいですね。
…なんか盛大な勘違いしていたけど、Bitslice DESのdesevalってあらかじめ 設定されたp[], k[], c[]の組み合わせが正しい場合にnon-zeroを返す 関数だったんですね。「なんでc[]に結果が入らねーんだ!」って ブチギレてたけど、main.cを見てようやく間違いに気づきましたw resultに代入されてる値を見たときに気づくべきだった… これを実際にDESで暗号化する関数にかえるためには resultをいじってる部分をパーミュテーションに変えれば いいんだな。よし、希望の光が見えてきたぞ。
単芝って何の事かと思ったら文末のwの事か 嘲笑的な語句は専ブラ設定でレス消去対象にしてるので、作者のレスの1/3位が消えてるわ
>>326 うーん、単芝なんてしょっちゅう見かけるので特に気にせずに使ってましたけど…
この板は真面目な方が多いんでしょうねえ。やっぱりこのスレで使うのはやめておこう。
まあ、それを指摘したレスもAAと消去対象レスへのレスで引っ掛かって消去されてるんだけどね 乱暴な語句や煽り・荒らしに使われる可能性のあるAAは大体消去対象なので、 このスレだと4割以上のレスが消えてる
>>329 > まあ、それを指摘したレスもAAと消去対象レスへのレスで引っ掛かって消去されてるんだけどね
> 乱暴な語句や煽り・荒らしに使われる可能性のあるAAは大体消去対象なので、
> このスレだと4割以上のレスが消えてる
なるほどなるほど。今後は気をつけます。
ああ、俺も単芝って何かと思ってたわ^^
Bitslice DESのソースを整形したら、FIPSの仕様書(p. 13)のE BIT-SELECTION TABLEに きれいに対応していました。同じページにある"Figure 2. Calculation of f(R, K)"の 左上にあるまるで囲まれた"E"が"E Box"のようです。これであとはごりごりと コードを書くだけのはず…
Bitslice DESを改造したものとUCB-cryptの結果を比べてるのですが、 どうも思ったように一致してくれません。LとRの値がいっしょになってくれないと いけないんだけど、おかしいなあ。テストデータではsaltを".."に設定してあるから 挙動はおなじになるはずなんだけど…
しかしsaltのエンコーディングがBase64でないのには驚きました。 最初は"AA"に設定してたのですが、saltbitsが0x000にならなかったので ようやく気づいたわけですが…
libdesのcrypt()の速度を測ってみたけど、じゃっかん UCF-cryptのほうが速いという結果に。 …やっぱりこりゃなんとしてもBitslice DESをつかってcrypt()を 実装するしかないですね。
しかしlibdesのソースも随分わかりにくいな〜 スピードのためだから仕方が無いとは言え、これではアルゴリズムがわかりにくすぎる。 いっそのことcrytographyの教科書を一冊買おうかしらん。
とりあえず上の論文で紹介されてた教科書のKindle版をぽちりました。
Bruce Schneier. Applied Cryptography - Protocols, Algorithms, and Source
Code in C (2nd Ed.). Wiley, 1996.
http://www.amazon.com/dp/B000SEHPK6/ しかし便利な世の中になったもんですね。お昼を食べたら早速読んでみよう。
>>343 の教科書には
>>342 より詳しい記述はありませんでしたorz
まあこの本は手元においておいてもいいから無駄にはなりませんけど、
それにしても弱ったな… 自分はDESがどのようにcrypt (3)で使われてるか
知りたいだけなのに。ひょっとしたらkeyのエンコーディングを間違えてるのかな。
ちょっと調べてみよう。
この本にcryptDESの詳細が載ってるらしいんだけど、すぐ手に入らないし
高いからまようなあ。これは最後の手段としてとっておこう。
A. Menezes, P. van Oorschot, and S. Vanstone. Handbook of Applied Cryp-
tography. CRC Press, 1996.
http://www.amazon.com/dp/0849385237
うーん、そのままコンパイルしただけじゃ動かないな、これ。 やっぱさすがに古すぎたか… コードは一番すっきりしてるだけに残念。 しかしこれからどうしようかな。
完全に煮詰まったので、放ったらかしにしてた"John the Ripper"のBitslice DESのコードを もう一回引っ張り出していじってたら、今度はなんとちゃんと動いているみたいです。 DES_BS_cmp_all()とDES_BS_cmp_one()に正しい変換結果を渡してやると ちゃんとTRUEが返ってきます。これはひょっとしたらひょっとするかもしれんぞ…
DES_bs_all.B[]に変換結果が入ってるのは分かるんだけど、 DES_BS_cmp_all()とDES_BS_cmp_one()で何をやってるのかさっぱりわかりません。 コードも#ifdefの嵐だし、よくこんなのメンテナンスできるよな…
色々たどってみたら、DES_bs_all.B[]の中身は予想以上に最適化されて複雑なもの だということが判明。DESの最後のパーミュテーション(inverse initial permutation)を 行わずに、検索するciphertextにinitial permutationをかけて比較してたのには驚きました。 コメントを見ても「変数が全てキャッシュに乗るように 1つの構造体に全部まとめておいたから勝手にばらすんじゃねーぞ」とか、 「最適化されたコードに支障が出るから、構造体のメンバーの順番は入れ替えないように」 とか恐ろしげなことが平気で書かれています。 とにかくJohn the RipperのBitslice DESのコードが自機で確実に動いているという 証拠はつかんだので、続きはあしたやろうっと。一応速度だけ計測してみたら、 UCB-cryptの3倍ぐらい出たのでかなり楽しみです。
■今日のまとめ(2011年8月26日) ・オリジナルのBitslice DESのコードをcrypt (3)に対応させる作業は難航。 ・その代わり、John the RipperのBitslice DESのコードを自機で動かすことに成功。 ■明日の予定・目標 ・John the Ripperの内部データを実際のトリップに変換する。 それではまた。
cuda_sha1tripper-0.3.0.zip -
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もドライバもバージョンが古いからの・・・
次はビットマップを使った大量検索も試してみようかの。
354 :
(の◇の) ◆wordlist..nn :2011/08/27(土) 21:05:34.04 ID:kfiScS6u0 BE:355547063-DIA(289888)
>>251 【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間違ってたことに今頃気づいた。www
355 :
(の◇の) ◆wordlist..nn :2011/08/27(土) 21:24:23.76 ID:kfiScS6u0 BE:1422187889-DIA(289888)
>>354 ソースはあとのお楽しみでまだ見てませんが、コア数が!
やっぱこうしますよね〜。
プロファイラで見ると
Active Blocks per SM: 8 (Maximum Active Blocks per SM: 8)
Active threads per SM: 1024 (Maximum Active threads per SM: 1536)
てな感じですね。というか、ゲフォはレジスタが厳しい!
>>353 お疲れさまです〜 こちらでも動作確認しました。ソースを見ましたけど、
SHA-1の部分を差し替えられたんですね。詳しい報告はまた後でさせて頂きます。
>>355 ラデのレジスタの数はブロック単位でとんでもないことになってるみたいですね。
実際1スレッドあたりどれぐらい使えるのか、非常に興味があります。
Bitslice DESの移植するときにはCUDAだとShared Memoryをつかわないと
かなり厳しいことになりそうなので…
それはそうと、さっき初めてComputer Visual Profilerの存在に気づいて
いま動かしてるんですけど、これって物凄い重いですね。結果が実にたのしみです。
test
トリップテストを誤爆してしまった…
でもとにかくJohn the RipperのBitslice DESのコードで
10桁トリップを生成することに成功しました!
∩( ・ω・)∩ばんじゃーい
素のCでかかれてることもあって速度はCPU1スレッドで550K TPSと
まだまだですが、UCB-cryptが330K TPSだったのと比べると差は
歴然としています。Bitslice DESのことを教えていただいて
本当にありがとうございました >
>>303 さて、これからJohn the Ripperのコードの余分な部分を削りまくって
綺麗なvanilla Cの実装にしてからCUDA Cに移植することにします。
途中でCPU検索に対応させるのがさきですけど…
【GPU】GTX 460 【CPU】i7 860 【OS】Windows 7 SP1 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
>>353 私も試してみました。調べてみたら、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
Bitslice DESまでの道はまだまだ先だけど、まずCでcryptの動きを理解しようと思い
http://ruffnex.oc.to/kenji/xrea/crypt.txt のサンプルを触っていたらPerlのcrypt()と結果が違うことがあって躓いていた。
両者の違いは、saltの2文字に0x21〜0x2Dまでの値(!から-まで)が含まれていた場合に、
サンプルのmain()→saltはそのまま
Perlのcrypt()→saltの該当文字を0x2E(.)に置き換える
ということだった。あーすっきりした。
俺が知っているCで書かれたcrypt()のサンプルはこれだけなので感謝してます。
しかも解説付きですからね。
現状Bitslice DESはまだまだまだ自分の手には負えなさそうなのでまずは
CUDAの勉強も兼ねてこっちの並列化を試みる。
>>362 > DESアルゴリズムでは64ビットの鍵をそのまま縮約型転置PC1にいれてましたが
> (結果DESでは8の倍数ビット目が削除されていた)crypt()では1,9,17...ビット目が
> 削除されることになっています。
道理でBitslice DESがそのままでは動かなかったわけだ…
この資料は本当に助かります。正直John the Ripperのコードは余計なものが
つきすぎてるので、できればオリジナルのBitslice DESを使いたいのです。
> Perlのcrypt()→saltの該当文字を0x2E(.)に置き換える
2chのサーバーではsaltの挙動は更に異なっているようです。
こちらの資料が参考になりました。
http://raccy.xrea.jp/ruby/trip.html
しかし同じような事をしている人がいるというのは心強いです。 一緒に頑張りましょう!
オリジナルのBitslice DESのコードをいじってみたけど、
やっぱりうごきませんねえ…
>>362 のコードとじっくり取り組めば
謎は解けるんでしょうけど、今回は動いているJohn the Ripperの
コードで先に進むことにします。
しかしこのコード、今まで見た中で一番汚いんじゃないかというぐらいの
カオスっぷりです。いろんなプラットフォームに対応しつつスピードを
極限まで追求するとこんな感じなんでしょうか。
ようやく10桁トリップのCPU検索ルーチンが完成して、 今動かし始めたところです。510K TPSぐらいしか出てないので テストするにも時間がかかりますが、まあ仕方が無いです。 さて、どうなるかな…
367 :
362 :2011/08/29(月) 11:59:15.00 ID:xoK0EyFD0
>>363 ありがとうございます!リンク先の表で自分の理解でよかったのだと確信できました。
◆MERIKEN4.kさんはリアルタイムで過程を書き込んでくださるのですごく勉強になります。
一方俺はCUDA学習目的が5割、10桁トリップ走査目的が5割でやっており、
トリップ走査の高速化には全く貢献しえないので申し訳ないですが、進展があれば報告していきたいと思います。
そういっていただけるとありがたいです。 いろいろ特殊な事が多いので、やはりノウハウの共有って大事ですよね。 またぜひいろいろ聞かせてください。
キタ━━━━━━(゚∀゚)━━━━━━ !!!!!
記念すべき10桁トリップ第一号です。
http://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.
Tripperの改造を始めたときから10桁対応を意識しながらコーディング
してたんですが、実際にちゃんと動いているのを見ると感無量です。
しかし
>>295 で実際に作業を開始してから4日でようやくCPU検索が
動き始めたわけですから、想像以上の難物です。
最初は「ネットで適当なコードを拾ってくれば1日でGPU検索までできるだろう」
なんて思ってたので見通しが甘すぎですけど…
さて、今日はもうこれぐらいにして続きは明日にしよう。
■今日のまとめ(2011年8月28日)
・10桁トリップのCPU検索がようやく動く。
■明日の予定
・CPUで全位置検索ができるようにする。
・John the Ripper由来のコードのクリーンアップ。
それではまた〜
今朝は10桁対応の続きでした。 本格的にコードを綺麗にする前に、万一のことを考えて トリップの出現確率を計算しているルーチンの修正を行いました。 10桁トリップの最後は情報量が4bitしかないため、次の16文字しか 出現しません。 .26AEIMQUYcgkosw これに応じて出現確率の計算を修正し、出る可能性のないパターンを 削除するようにしました。これで正確な確率が出るようになったので、 テストをしながら思う存分コードを削れます。
あと、12桁用のルーチンではキー空間を網羅的に探索するように していたのですが、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)
というわけで、せっせとJohn the Ripperのコードを綺麗にしているわけですが、 気分は「汚物は消毒だ〜っ!!(AA略」という感じです。#ifdefにまみれた 4000行あるnonstd.cにはまだ手をつけていませんが、避けては通れません。とほほ…
非常に恐ろしく見えたnonstd.cでしたが、#ifdefをある程度取り除いて みたら、単にアーキテクチャ毎にに最適化されたDESのS-Boxがずらずらと 並んでただけでした。使用するレジスタの数や特定のオペランドの 実行回数に応じて非常に細かく場合わけされています。 ここらへんのJohn the Ripperの性能へのこだわりには本当に 関心させられます。絶対にメンテしたくないコードですけど… 今はとりあえず適当なS-Boxの組み合わせを選んでおいて、 あとで手作業で実行時間を測定して、CPUとGPUに最適な組み合わせを それぞれ調べることにします。
さて、汚物の消毒(笑)は完了して、4000行あったnonstd.cは150行になりました。 素のCの実装と関係ない部分を削除して、8つあるS-Boxを8つのインクルードファイルに 追い出したのですが、随分とすっきりとしました。あとは残りの部分をきれいにして、 thread-safeにしてしまったら、GPUのルーチンの実装に取り掛かれます。 もうS-Boxのソースは当分見たくないです(笑)
みんなどのツール使ってトリップ検索してるの?
>>378 > みんなどのツール使ってトリップ検索してるの?
VecTripper → Radeon版待て屋。 → CUDA SHA-1 Tripper
という流れでした。いま作っているTripperの改造板は、これらのツールの
良いところをすべて取り込む予定です。VecTripperはMac用なので
使っている人は少ないと思いますけど、機能的にもUIの面でも非常に
洗練されているのでぜひ見習いたいですね。
コードのクリーンアップがようやく終わりました。 あれだけごちゃごちゃしてたJohn the RipperのBitslice DESのコードが、 500行ほどの1つにすっきり収まり結構感動しました(笑) もちろん機種判別用の#ifdefは全て削除しました。 このルーチンはどのCコンパイラでも通るはずなので、 Tripperとは別の形でいずれ単独で公開したいと思います。
Johnのコードには相当難儀させらましたけど、実際には オリジナルよりもはるかに効率のよいS-Boxの実装を 手に入れることができたのでかえって良かったのかも知れません。 あとはこれがCUDA Cで動いてくれればいいんだけど…
マルチスレッドへの対応は全く問題なく終わりました。 Phenom II X6で2.71M TPSと笑っちゃうような数字ですが、John the Ripperは もともとSSE2/AVX Intrinsicsに対応していたので、コードの最適化は比較的容易なはずです。 もともとCPU対応はおまけみたいな扱いなので、最適化は後の楽しみにとっておいて、 いよいよ本命のGPUによる10桁トリップ検索への対応の作業を始めることにします。 どれぐらいスピードが出るか、実に楽しみです。
おっと、コードをCUDA Cに移植する前に、大量にあるgotoを削除しとかないとな… John the Ripperのコードは本当に効率重視というかんじですけど、 この分岐の嵐ではCUDAでは性能がでないでしょう。
全部マクロですまそうとしたらコンパイラが落ちました(笑) 8 S-Boxes * 16 rounds * 25 iterationsだから当然か… まあ分岐といってもwarp divergenceが発生するわけではないようなので、 とりあえずこのままにしておきます。
なるべくGPU検索とCPU検索でコードを共有化したいんだけど、 これ、GPU検索の前にコードの整理をしないと駄目だな。
なんとかCPUとGPUでDESのルーチンを共有するために、 共通のルーチンをインクルードファイルに押し込めて、 2つのファイルでインクルードさせて、 プリプロセッサで違いを吸収させることにしました。 Jon the Ripperのコードを見続けた後では全く普通に見えますが、 やりすぎかもしれません。危ない危ない(笑) なんにせよコードの整理がようやく終わったので、明日こそ GPU検索を動かせるはずです。楽しみです。
■今日のまとめ (2011年8月30日) ・10桁トリップのCPU検索のマルチスレッド化。 ・ファイルの分割等のコードの整理。 ■明日の予定 ・10桁トリップのGPU検索への対応。 それではまた〜
とうとうゲフォで10桁検索が… 待て屋じゃ10M/Tすら程遠かったから期待
>>389 GPUがRADEONじゃなくてGeForceなんだろ。
>>355 >>357 SIMDとSIMTでの方向性の違いとかも関係しているのかの。
>>361 デフォルト値はCompute Capabilityで変えているつもりじゃったが、上手く動いていないのかや?
それにしてもGTX 580 OCでの速度は予想以上に速いようじゃが、ドライバのバージョンの影響も大きいのかの・・・
>>367 わっちは熱中するとBBSでのレスとかそっちのけで、コードを眺めたりのんびり煙管をふかしながら考えをまとめたりになってしまうの w
>>380 それは楽しみじゃの。
すぐに見つかるDESベースのcrypt()の実装は初心者向けの解説的なものか、極端に最適化されたもののどちらかという感じじゃったからの。
わっちのほうもビットマップを使った大量検索への対応ももうすぐ完了しそうじゃから、
それが終わればDESベースのcrypt()の勉強も再開しようかの。
正規表現への対応とかはハードルが高い上に、ある程度ならば
外部ツールでターゲットファイルを作るという力技も使えるからの w
>>391 >
>>355 >>357 > SIMDとSIMTでの方向性の違いとかも関係しているのかの。
なるほど〜 Radeonのアーキテクチャのことは何も知らないんですけど、
かなり違うみたいですね φ(..)メモメモ
>
>>361 > デフォルト値はCompute Capabilityで変えているつもりじゃったが、上手く動いていないのかや?
> それにしてもGTX 580 OCでの速度は予想以上に速いようじゃが、ドライバのバージョンの影響も大きいのかの・・・
blocks/SMは 8のままでした。また一段落したらソースを追ってみます。
>
>>380 > それは楽しみじゃの。
> すぐに見つかるDESベースのcrypt()の実装は初心者向けの解説的なものか、極端に最適化されたもののどちらかという感じじゃったからの。
>
> わっちのほうもビットマップを使った大量検索への対応ももうすぐ完了しそうじゃから、
> それが終わればDESベースのcrypt()の勉強も再開しようかの。
期待してます。またぜひ参考にさせていただきたいです。
>>390 mtyは現行ラデにしか対応してませんが?
>>388 なるべく応えられるように頑張りますです。
さて、GPU検索への対応ですけど、まだもうちょっと作業が必要なようです。
何も考えずに使う変数を全部シェアードメモリに載せようとしたら
コンパイラに怒られてしまいました。
Bitslice DESで必要な変数はすべてstruct DES_Contextに押し込んでおいたのですが、
なんとサイズが8808バイトになってました。今の実装では1ブロックあたり128個の
スレッドが動いてるのですが、これでは共有メモリのサイズが全然足りません。
共有メモリのサイズはCompute Capabilityが1.xの場合は16K、2.xの場合は48Kと
なっています。スレッドの数をギリギリの32まで減らしてやっても、使える共有メモリの
サイズは1スレッドあたり512バイト、もしくは1536バイトなので、可能な限り
DES_Contextのサイズを減らす必要があります。
>>394 の続きですけど、今後の方針はこんな感じです。
・中身が毎回同じ配列は、あらかじめ計算しておいてコンスタントメモリに追い出す。
・中身が動的に変化する配列は、ポインタの代わりにunsigned charのインデックスを使う。
・Key Scheduleのインデックスをcrypt (3)実行の前に実際のKeyに展開するのはやめにする。
・unionでstruct DES_Contextのメンバをまとめてやる。
512バイトはなかなか厳しい数字ですが、1536バイトなら十分に達成可能なはずです。
CPU検索のルーチンで動作確認をしつつ、すこしずつ削っていきたいと思います。
とりあえず毎回同じ配列を外に出してみました。 > sizeof(DES_Context): 7528 先は長いですが、最初の一歩です。
行き過ぎた最適化でCUDAでBitslice DESのコードが動かなくなっても こまるので一応動作確認だけしてみましたが、ちゃんとトリップの変換はできている ようです。 ついこの間まで知らなかったんですけど、Compute Capabilityが2.xの場合、CUDAの コードからprintf()が呼び出せます。デバッグのときに非常に便利です。
一番大きかったKey Schedule関係の配列をなんとか外に追い出すことに成功しました。 0x300 * 4 bytes * 2 = 6144 bytes なのでこれはでかいです。 あとはExpansion Tableのポインタの配列もUINT8のインデックスの配列に変えました。 結果はこんな感じです。 > sizeof(DES_Context): 1088 今日だけで随分はかどったな… 続きはまた明日やることにします。
■今日のまとめ (2011年8月31日) ・Bitslice DESのGPUでの動作確認。 ・Bitslice DESで使われるデータ構造のサイズを1/8に減らす。 ■今後の予定 ・10桁トリップのGPU検索の試験実装。 ・開発環境をWindows 7に移行して、Parallel Nsightを導入。 それではまた〜
乙鰈〜
403 :
(の◇の) ◆wordlist..nn :2011/09/01(木) 20:13:28.25 ID:66KZFuYJ0 BE:197526252-DIA(289888)
>>400 あちこちで資料を漁るのもいいけど、マニュアルも読もうぜ。w
printf とかコア数とかVisual Profilerとかの話を見る限り、読んでないだろ。
CUDA C Programming GuideのAppendix F. Compute Capabilitiesとか必読だろ、jk。
あ、どもども。Programming Guideは適時拾い読みをしてます。 (printfのこともマニュアルを読んで知ったのです) どうももろにshared memoryのbank conflictがおきてるようなので、 ちょうどAppendix F.を読んでました。 これは確かに知らないと全く性能が出せないですねえ。
405 :
362 :2011/09/02(金) 01:09:48.92 ID:GfmKCDSR0
◆MERIKEN4.kさんはじめみなさんおつかれさまです。
BitsliceじゃないほうのDES crypt()での走査をCUDAでやろうと(
>>362 )している者です。
http://ruffnex.oc.to/kenji/xrea/crypt.txt のサンプルにある定数(縮約型転置1,2・循環シフト・P/拡大型/初期/最終転置・SBOXの計848バイト)は
__constant__でコンスタントメモリに格納してキャッシュ(8KB)が効いてくれる…はず。
コンスタントメモリ(のキャッシュ)にはSharedMemoryにあるようなバンクコンフリクトの問題は
あるのだろうか。いやないはず。バンクに分かれているという話も聞かないしリードオンリーだし。
余りにも遅かったら調べて報告する予定です。要するにあれからまだほとんど進んでいません。
406 :
362 :2011/09/02(金) 03:28:28.34 ID:GfmKCDSR0
あれ?キー→トリップの箇所をCUDA化して速度はまだ調べていないけど…正常に結果が出た!?
自分で言うのもアレですが意外すぎる…もっと躓くと思っていたのに。
現状CUDAの中でif文(というかfor文)を使いまくっているので速度が全然出ないというオチを
予想しておりますが。
ここからの課題:
●キー候補としてどの範囲をどのように走査するのか。
→文字コード表 シフトJIS(Shift_JIS)
http://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でやりますかね。
>>406 > あれ?キー→トリップの箇所を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のアーキテクチャと非常に親和性の高いものだと考えています。参考までに。
408 :
(の◇の) ◆wordlist..nn :2011/09/02(金) 17:29:35.00 ID:jbgkgFqx0 BE:355548029-DIA(289888)
>>407 >大量のグローバルメモリへのアクセスが発生して効率がでないんじゃないでしょうか。
マップドメモリ + カーネルの並列実行
これでそこそこマシになった。
ボクの作ってるCUDAトリッパーでは。w
古いゲフォで動かないけど。w
あれ、CUDAトリッパー作られていたんですか? > マップドメモリ + カーネルの並列実行 これはなかなか興味深い話です。 しかしCompute Capabilityが低いと厳しいですよねえ。 10桁トリップの検索ではshared memoryを目一杯使う予定なので、 さすがにCC1.xの縛りではしんどくなってきました。
410 :
(の◇の) ◆wordlist..nn :2011/09/02(金) 20:48:40.95 ID:jbgkgFqx0 BE:948125186-DIA(289888)
CUDA SHA-1 Tripperの魔改造をあきらめて、完全自作に走ったわけで。 某所でこんなカキコをした。w >マップドメモリとカーネル並列実行までやってもCUDA SHA-1 Tripper >に届かないとかなにそれこわい 悪魔のコードな待て屋と違って、魔改造するのが楽そうだったんだよね。 綺麗でシンプルなCUDA SHA-1 Tripperって。
>>392 わっちもRadeonの方はよく知らぬが、GeForceはメモリアクセス等のレイテンシの大きさは
スレッドを切り替えて隠蔽する方針のようじゃから、大量のスレッドが必要になって
かといって闇雲にスレッドを増やせばいいというわけでもないようじゃからの・・・
-xオプションのデフォルト値は1系は2で、2.0が8で、2.1が12じゃから、上手くいっていると思いんす。
とりあえずターゲットIPCとかは無視してコア数だけでの設定じゃがの。
>>405 コンスタントメモリへのアクセスはハーフワープ内のスレッドが異なるアドレスにアクセスするときは
逐次実行になって処理が直線的に増えるようじゃから、注意が必要かも知れぬの。
>>410 シンプルではあるかも知れぬが、綺麗といえるようなコードかの?w
CUDA 3.2でもCompute Capability 2系向けのコードを生成できるようじゃから 新しいテンプレートを使ってVisual Studioのソリューションやプロジェクトを作り直したら ちゃんと2.0向けのCUBINも含んだバイナリを出力するようになってくれて GTX 460での実行速度が15%程度向上しおった・・・ ビットマップを使った実装も上手くいったみたいで とりあえず16Mターゲット放り込んでも速度の低下は誤差レベルですんでおるみたいじゃから あとは最終チェックかの。
413 :
362 :2011/09/02(金) 22:38:16.21 ID:GfmKCDSR0
>◆MERIKEN4.kさん◆wordlist..nnさん◆Horo/.IBXjcg
レスありがとうございます!
>>407 host-device間のメモリアクセスは確かにまずいですね。
unsigned intへのキャストで比較という方法も含めて考えてみます。
>>408 マップドメモリというキーワードは昨日初めて知ったというレベルですが
最適化の段階で検討したいと思います。
>>411 >ハーフワープ内のスレッドが異なるアドレスにアクセス
コンスタントメモリ内に区分はなく(キャッシュがありますが)基本的にGPU全体で共有ではないのでしょうか。
異なるスレッドから”同じコンスタントメモリアドレスへの”アクセスは逐次処理になるということでしょうか?
だとすると、今回置くデータは大きくないのでコンスタントメモリ内に複製をいくつか用意して
(キャッシュに収まる範囲で)スレッドによってアクセスする先を分散させるなどで対処可能…
でも、コンスタントメモリ内のどこであろうと異なるスレッドからのアクセスは逐次、ということで
あればこうやって複製を作るのはムダか…
414 :
362 :2011/09/02(金) 22:44:16.39 ID:GfmKCDSR0
失礼しました、敬称がついておりませんでした>◆Horo/.IBXjcgさん 現在はどこまで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からは今回はちゃんと復帰したけど気をつけなさいと怒られる。
415 :
414 :2011/09/02(金) 22:45:41.62 ID:GfmKCDSR0
>>414 の訂正
正:GTX470=Multiprocessorは14個、CUDAコアは448個
誤:GTX450=Multiprocessorは14個、CUDAコアは448個
416 :
(の◇の) ◆wordlist..nn :2011/09/02(金) 23:06:45.75 ID:jbgkgFqx0 BE:553073074-DIA(289888)
>>414 どんなプログラムになってんのか知らんが、いくらなんでもそんなグリッドサイズじゃ小さすぎるだろ。
417 :
(の◇の) ◆wordlist..nn :2011/09/02(金) 23:10:36.75 ID:jbgkgFqx0 BE:395052454-DIA(289888)
>>411 綺麗の反対は汚いではない、といいわけをしておいて。w
待て屋を魔改造してて、何回泣きそうになったか。www
複雑怪奇すぎるよ、あれは。
418 :
362 :2011/09/03(土) 00:33:03.60 ID:qflCs/PV0
>>416 レスありがとうございます。現状、速度の点でどうかという観点に達していないので、
手直し(特にメモリの使い方)をして速度もわかるようにしてから最適なグリッドサイズに
ついて改めて見直したいと思います。
今のところkernelfunc<<<8,128>>>()のkernelfunc1つあたり32トリップ調べる、
8*128*32=32768が最善なんですよね。フリーズするかしないかという観点では。
32トリップはkernel内でループで回しているだけなのでこれが増えても
メモリ使用量は変わらない(結果も作為的に32ではなく1つしか確保せず)と考えていたの
ですが、これを64に増やすとアウト(5秒間スリープ)です。
仮にkernelにあるループがinline展開のようなことをされているのなら、
ループが長くなると何かの制限を越えてしまうのかもしれません。
それとも実行時エラーなのでスレッドの結果待ちタイムアウトだったりして。
419 :
(の◇の) ◆wordlist..nn :2011/09/03(土) 01:03:57.62 ID:myUo6N/c0 BE:1422187698-DIA(289888)
こんな数値でもちゃんと動いてるぜ。てゆか、もう一桁大きくしても大丈夫だし。 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ではサイコー。w
>>413 コンスタントメモリに区分は無くGPU全体で共有というのは、あくまでもソフトウェアからみたものであって
ハードウェア的にはSMというかSMの中にあるInstraction Unitによって管理されているように思いんす。
G80やGT200系はよく分からなかったのじゃが、FermiのL1キャッシュはSM内にあって
L2キャッシュは双方向クロスバで全SMからアクセス可能のようじゃが、
キャッシュの一貫性維持の簡略化とかで、やはりSM単位での管理になっておるんじゃないかの。
少なくともハーフワープ内のスレッドはアクセスする先を分散させては逆効果で、
極力同一アドレスにアクセスするようにすべきではないかの。
>>417 シンプルイズベスト(キリッ)というか、わっちの場合は複雑にしてしまうと自分でも手に負えなくなるからのw
わっちも早く無駄が無く、尚且つメンテしやすい芸術的なコードを書けるようになりたいの・・・
cuda_sha1tripper-0.4.0.zip -
ttp://kie.nu/jG cuda_sha1tripper-0.4.0_win32bin.zip -
ttp://kie.nu/jH ビットマップを利用して大量検索できるようにしてみたのじゃが、
動作環境がGeForce 8シリーズ以降でグラフィックメモリ256MB以上で
推奨環境はGTX 450以上でそれなりの速度のデュアルコア以上という
軽めのゲームなら軽々動きそうなスペックになってしもうたw
それからWindows版のバイナリを利用するならGeForceドライバ266.58辺りが必要になるかも知れぬ。
その他にも基本的なスクリプト等が書ける程度の能力、もしくは補助ツールがあるといいかもしれぬのw
スクリプトでtarget_huge.txtを生成できるのじゃが、このファイルはダブルクリックしない方がいいの・・・
>>421 お疲れさまです〜
ただいま10桁トリップのGPU検索の試験実装と奮闘中なので、
これが終わりしだいダウンロードさせて頂きます。
原因不明の"unspecified launch failure"がでるので原因を 探っていたんですが、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
結局John the Ripperのコードがワードの配列をバイト単位でアクセスしてたのが 原因で、その部分を全部書きなおすことで解決しました。 しかし自分の書いたコードじゃないと思わぬところで足をすくわれますね。
10桁トリップのGPU検索の試験実装ができました。 Bitslice DESのルーチンがエンバグしてえらい目に遭いましたが、 ようやくちゃんと動くようになりました。 とりあえずローカルメモリだけを使うようにしてシェアードメモリは触っていないので スピードはまだまだですが、それは今後の最適化次第ということで実に楽しみです。
さっきようやく開発環境をWindows 7に移行して 試しにCompute Visual Profilerを動かしてみました。 (XPでは何故か途中でクラッシュして動きませんでした) で、気づいたのがOccupancyが最大でも0.167とかなり低いことです。 register per threadが63と高いのが関係してるのかしらん。 ちょっと減らしてみよう。
そうそう、開発環境を移行している間にCUDA C BEST PRACTICES GUIDEを 通読しておきました。やっぱり性能をだそうと思ったら資料を読んで プロファイラを使わないと無理ですね。PROGRAMMING GUIDEも後で 最初からちゃんと読んでおこう。
per threadあたりのレジスタ数を減らそうとしたら "invalid kernel image"というエラーが出てしまいました。 --maxregcountを16と32にしてみたんですが、両方共エラーが出ます。 やはりいろいろとshared memoryに追い出さないと効率は上がらなさそうです。
--maxregcountを元に戻しても治らないぞ orz 開発環境の問題なのかなあ。
Parallel Nsightを使うためにWindows 7に移行したのに Parallel Nsightが使えないとは意味不明ですが、 とりあえずCompute Visual Profilerが動くようになったので これでしばらく頑張ってみます。 で、レジスタの数を16に減らしたら案の定スピードは落ちてしまいました。 これは相当うまく共有メモリを使ってやらないといけないようです。
レジスタの数を減らしたのにOccupancy Rateはそのままでした。(・3・)アルエー?
うーん、どうもCompute Visual Profilerを動かしても、 途中からいろいろおかしくなるなあ。"unknown error"がCUDAの 関数から帰ってくるなんて初めてだ。実に不思議です。
435 :
(の◇の) ◆wordlist..nn :2011/09/05(月) 22:32:09.82 ID:TBBskvOe0
>>421 >>354 【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 のみ
436 :
(の◇の) ◆wordlist..nn :2011/09/05(月) 22:40:57.71 ID:TBBskvOe0
>>435 【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ターゲット
437 :
(の◇の) ◆wordlist..nn :2011/09/05(月) 22:49:29.28 ID:TBBskvOe0
>>436 しばらく走らせてみましたが、まったくヒットしません。
Reading target file "target.txt"...
340249 targets found
となってるからちゃんとタゲは読み込んでるみたいですが。
なんだろう?
438 :
(の◇の) ◆wordlist..nn :2011/09/05(月) 22:55:27.78 ID:TBBskvOe0
>>437 ああああああ!
私の間違いでした。
ちゃんとヒットしてました。ごめんなさい。
439 :
(の◇の) ◆wordlist..nn :2011/09/05(月) 22:58:32.79 ID:TBBskvOe0
>>435 【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 のみ
>>419 > こんな数値でもちゃんと動いてるぜ。てゆか、もう一桁大きくしても大丈夫だし。
> 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に下がってしまいました。
>>435-436 ターゲット数を増やした時の速度低下が予想以上に大きいの・・・
ターゲット先頭3文字の文字種が増えるとグローバルメモリへのアクセスが増えるはずじゃが
それが大きく影響しておるのかの。
正規表現のサブセット等への対応も考えたほうがいいのかの・・・
>>421 遅くなりましたが、ようやく試すことができました。
>>361 に比べてちょっと遅くなってるのは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
>>421 >>441 多ターゲット時の速度低下はある程度は仕方が無いと思います。
英単語のリストだと、付属の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
>>441 > 正規表現のサブセット等への対応も考えたほうがいいのかの・・・
前方一致だけなら自分の改造版のソースを流用していただければ
すぐにプリプロセッサが出きるはずです。
後方一致や任意の位置での検索をしようとするとプリプロセッサだけでは
きびしくなってきますが…
あれ、計算間違えてるぞ。共有メモリは1スレッドあたり6144 / 128 = 12 * 4バイトか。 うーん、これは厳しいなあ。できるだけ節約しないと駄目だな、これは。 1スレッドあたりのレジスタ数を20、共有メモリを8 * 4バイトまで削ることができれば 1SMあたり192スレッドまで詰め込んでtheoretical occupancyが100%になるけど、 これは無理そうだしな… しかし共有メモリが1SMあたり48Kしかないというのはなかなか厳しいです。 もうなるべくローカル変数を減らしてレジスタ数を削るしかないですね。
>>421 乙
【GPU】GTX 460
【CPU】i7 860
【OS】Windows 7 SP1 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
速くネエ。
【オプション】 -d 0 -x 20 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
Use device 0, grid is 252 blocks, 36 blocks/SM (default is 12 blocks/SM) 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 目一杯。
450 :
(の◇の) ◆wordlist..nn :2011/09/06(火) 20:09:06.78 ID:eJ9eESIC0 BE:790104285-DIA(289888)
>>441 この程度で「大きい」という感想になるとは。
一回、億個単位のタゲでも食わせてみますか。w
うにで878264708ターゲットまでは試したことが。www
今朝はガリガリとローカル変数の数を削るという実に地味な作業をしていました。 ここらへんはCUDAのアーキテクチャの制約の影響をもろに受けてるわけで、 Radeonがどうなっているのか実に気になるところです。 新しい7970のTDPは190WでGTX 580より低いんだよな。ちょっと試してみたいかも…
まあでもとりあえずはCUDAの性能の限界まで頑張ってみないと… できればPTXのコードは弄りたくないんですけど、場合によっては やむを得ないかもしれません。
453 :
362 :2011/09/07(水) 04:52:59.46 ID:KSbhzaG50
BitsliceじゃないほうのDES crypt(10桁トリップ)を対象にしている者です。
現在9.02KTrips/sec。ふぅ…
シェアードメモリを全く使っていなかったり
16384Tripsごとに全部CPU-GPU間で全部転送しなおしていたり
ここからどう早くなるのかが楽しみだぜ!
>>421 コード公開ありがとうございます!
自分はsha1のほうに取り組む予定は現状ありませんが、
コーディングの参考にしたいと思いダウンロードさせていただきました!
Horo氏のコードはほんとうに参考になるのでぜひ一読を薦めますです。 私も随分勉強させて頂きました。
私の10桁トリップの検索のコードは最適化とエンバクを繰り返しながら 少しずつ速くなってます。Occupancyを33%から少なくとも67%、 できれば100%まであげたいんですけど、なかなか楽はさせてもらえませんね〜
どうやらvolatileキーワードを使ってレジスタ数を減らす方法が
ある模様。やっぱ中間ファイルをちゃんとみないと駄目だな。
この方法でレジスタ数を抑えられるなら万々歳なんだけど…
> 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.
http://forums.nvidia.com/index.php?showtopic=89573
初めてptxファイル見たけど、レジスタ割り当てまくっててワロタw こりゃ効率悪くなるわけだわ。どうしよっかなあ…
CUDA側でしていたsaltとexpansion functionの処理を 本体側に追い出せないか、現在検討中。 これがなければローカルメモリへのアクセスがかなり減らせる上に、 レジスタ数の削減もできるはず…
459 :
362 :2011/09/08(木) 21:19:03.65 ID:Is6P+pLc0
460 :
362 :2011/09/08(木) 21:28:12.42 ID:Is6P+pLc0
現状:
1.スレッド内のみで使う変数をGlobalからSharedMemoryにした
2.スコープ上流用ができる配列を流用した
などをやっても全然スピードが変わらなく、ブラックアウトも頻発して心が折れかけてました。
が原因がタイムアウトだとわかったのでどんどんぶん回す希望が持てました。
3.GTS450は4-Multiprocessorsであることに気づいた。48*4=192 CUDA Cores。
>>414-415 で書いた
>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登場 | パソコン | マイコミジャーナル
http://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は脱したい…。
461 :
(の◇の) ◆wordlist..nn :2011/09/08(木) 23:42:41.10 ID:XJyqqMKA0 BE:967877977-DIA(289888)
やっぱさ、GTX 580使っても10桁じゃ10Mさえいかないんじゃね?w
でも、鳥屋ならなんとかしそうで怖い。www
>>460 いや、だからマニュアル読もうぜ。w
なんで一次情報元を優先しないんだろう。
あと、「CUDA トレーニング」でググって、Volume 1を読むとか。
>>461 > やっぱさ、GTX 580使っても10桁じゃ10Mさえいかないんじゃね?w
> でも、鳥屋ならなんとかしそうで怖い。www
いや、さすがにうちでは10M TPSは軽く超えてますよw
ただ、レジスタ数の問題さえ解決できれば2〜3倍の速度向上ができますけど、
それでも100M TPS出すのはちょっときびしいかもしれませんねえ。
463 :
362 :2011/09/09(金) 00:52:17.14 ID:umRhT1Lx0
>>461 失礼しました、VolumeI_テクニカルトレーニング.pdfに経験則として
ブロックの数>マルチプロセッサの数
スレッド=192 or 256が最適
と書かれてますね。アドバイスありがとうございます!
タイムアウトの問題があったのでこれまでは↑のような数で試すと必ず失敗していたので
GTS450だと何かが制限に引っかかっているのか?と考えてしまってました。
1次情報はFermiが出た直後や出る前のものが多くて、Multiprocessorの数なども
製品情報から推定するしかないと。
(と思っていたら動かしていたサンプルにはっきり4 Multiprocessorsと出ていたわけですが)
ようやく環境変数CUDA_PROFILEを1にしました(OSの再起動も必要でした)。
(occupancy=0.083…32スレッドでsharedmemoryがいっぱいいっぱいになるようじゃやむなしか…)
Visual Profilerも使っていきたいと思います。
>>460 日本語のWebはとっつきやすくていいんだけど、ベンチマーク主体のサイトより
後藤氏の記事のほうがGPUやCPUのアーキテクチャの話題が主体で役に立つはず。
http://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」になっているし。
465 :
362 :2011/09/09(金) 02:03:08.40 ID:umRhT1Lx0
>>464 プロジェクトのプロパティ→構成プロパティ→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まで。
すみません手抜きして新しい情報源をちゃんと見ていなくてお手数をおかけしました。
何から何までアドバイスありがとうございます。
>>462 俺の感覚ではGTX460で良くて数十M、100Mいったらすげーな、って感じだたな
>>466 >
>>462 > 俺の感覚ではGTX460で良くて数十M、100Mいったらすげーな、って感じだたな
GTX 460だと580の半分以下のスピードしか出ないはずなので、
それで100M TPSでたらすごいですよ。でも580なら達成不可能な
数字ではないという印象です。PTXのコードからcubinに変換されるときの
レジスタの割り当ての最適化がかなりいい加減なようなので、
PTXのコードに大幅に手を入れてやればかなりのところまで
いけるはずです。Cのレベルでの最適化が限界まできたら
PTXに手をつける予定です。
468 :
(の◇の) ◆wordlist..nn :2011/09/09(金) 12:54:21.75 ID:VplkvUb+0 BE:829609676-DIA(289888)
まあゲフォだとそうだよな。 同価格帯のラデと比べるとかなり落ちる。(※トリップ検索においては。w) 鳥屋先生の科学力を考慮しなくてもね。www 100M届くかどうかったら、5770クラスだもんね。
CUDAをこういう用途に使う人もいるのか
>>468 まあとりあえずゲフォで10桁トリップが検索出来るというところに
意味があるんですよw これが一段落したら、ラデも是非試して
みたいですね。
471 :
362 :2011/09/09(金) 16:27:19.02 ID:umRhT1Lx0
これまで256B(Shared)+768B(Global)だったところを、変数を圧縮して
160B(Shared)+96B(Shared)の合計256Bにできた…!
これで256B*192スレッド=ジャスト48KBにぴったり収まる。
ここから圧縮して192Bにできればもうひとつの経験則最善スレッド数である256が実現できるのだけど。
手元のそろばんでは172Bにまでは圧縮できることになっているのでそれを目指します。
圧縮ついでに◆MERIKEN4.kさんが
>>407 でおっしゃっていた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の大台には乗りたいのでさらに修正を続けます。
472 :
362 :2011/09/10(土) 02:28:39.47 ID:cPH0Nr9t0
209KTrips/secになりました!
要因は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を購入する
>>362 の姿が!? …+300%
【雑文】
8バイトを1つのまとまりとして扱いたくてdoubleへのポインタから値戻ししたり
64ビットprojだからと考えポインタを使ってみようとしたけど
「incorrect register class for result 0」や「unaligned memory access not supported」
とCUDAコンパイラに怒られてしまった…。しかもSharedMemory容量越えのときとは違って
VisualStudioにもやーい怒られてやんのーと言われる(「ツールはエラー コードを返しました」)。
単なるコピーならコンパイラがうまくやってくれると信じて素直に代入文を書くことにする。
Vector Type の uint2 とかそんな話? uint4 なら使ってたなぁ。SHA-1だけど。w
>>472 自分の実装でもsaltの処理はCPUでやらせるようにして、若干速度が上がりました。
あと、(1)の処理をCUDA側でやるだけで1M TPSは簡単に超えられるはずですよ。
キャッシュが効かないと、グローバルメモリへのアクセスはものすごく遅くなりますからね。
1タゲなら書き出しの量が1/(64^5)に減るので決定的です。
475 :
362 :2011/09/10(土) 04:57:33.75 ID:cPH0Nr9t0
>>473 レスありがとうございます。が、おそらくそのような高度な話ではないです。
単にカーネルに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%にも満たないと思うので深追いすることは今のところ考えていなかったりするのです…。
476 :
362 :2011/09/10(土) 05:14:21.26 ID:cPH0Nr9t0
>>474 レスありがとうございます!ところが…
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整数との比較
以下、
>>474 さんの書き込みを見る前に書いていた(475に付けると改行オーバーでNGになった)文です。
【現状】
unsigned intで先頭4文字+2bitの判定をするようにした。所望のTrip文字列→bit列をCPU側で
最初に逆算し、カーネル内ではint32同士の判定しかしていないから計算量は確実に減っている
はずだけれど効果は1%くらい(?)。見落としていることがないか確認する。
477 :
362 :2011/09/10(土) 05:22:13.79 ID:cPH0Nr9t0
そういえば全然関係ない話ですがprogramming guideを見返してcudaMalloc()にゼロクリア機能はないのだと認識しました。 ないとは思ってたのですが、0になっていることしかなくてひょっとして楽できる…?と思っていたので危なかったです。 ではおはようございます&おやすみなさいです。 進展があったらまた書き込ませていただきます。
>>475 横槍ですけど、Vector TypeのことはProgramming Guideに載ってますよ。
自分はまだ試してないですけど… unsigned intを使うより効率がいいなら
Bitslice DES の実装に直接応用できるのであとで試してみたいと思います。
>>476 うーん、それは変ですねえ。とにかく最適化で一番気を使うのは
分岐の処理とグローバルメモリへのアクセスですからねえ。
コードを公開されるのでしたらぜひ見せていただきたいです。
とりあえず共有メモリには手を付けないで、
>>456 の方法でvolatileキーワードを
使ってレジスタ数を63から32まで減らすことを目標にしました。
nvccはこれでもかというぐらいレジスタを使っているので、
C言語での書き方を工夫してレジスタの割り当てを減らしたいところです。
>>470 個人的には終わりがみえている10桁トリップのツールを作ってどうするの?って思うが
他人の趣味だからどうでもいいか(*‘ω‘*)
>>481 純粋な遊びに実用性を求めるのは野暮というものですよw
楽しければそれでいいのです。
とりあえずS-Boxが手頃なサイズなので、これの最適化から始めることにしました。 John the Ripperの実装についてきたS-Boxには幾つか種類があって 選べるようになっているのですが、全部試す時間はないのでレジスタの 使用数が一番小さいものを選ぶことにしました。とりあえず試してみたら、 なにもしていないのに前より少しだけ速くなっています。やはりレジスタの割り当て方の まずさが相当足を引っ張っていると思われます。 John the Rippperのコメントによればレジスタ数は14〜19個で済むはずですが、 アホの子のnvccは何も考えずに60〜80個レジスタを割り当ててくれています。 やはり相当最適化の余地があるみたいです。
つか、デバイス側は読み込みだけなら、コンスタントメモリに転送した方がいいような? オプションとかifdefでいろいろ試せるようにしておくとと楽しいぞ。w おれおれ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 */
>>484 コンスタントメモリに変数を追い出せるとかなりおいしいですよね。
自分の実装では速度低下はほとんど見られませんでした。
いろいろCのコードをいじってどのようにPTXに変換されるのか試してみ ましたけど、なかなか意味不明です。これ > 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内で使われている一時変数の数をぎりぎりまで限界まで減らすことにしました。 この手の最適化はどう考えてもコンパイラの仕事ですけど、まあ仕方がありません。 エンバクにだけ気をつけてせっせと削っていきます。
488 :
362 :2011/09/10(土) 23:41:13.07 ID:cPH0Nr9t0
>>478 またまた申し訳ないです…programming guideのpdfにもろに載ってますね。
◆wordlist..nnさんも◆MERIKEN4.kさんもどうしてそんなに親切なんですか…ありがとうございます!
昨晩の俺はCUDA vector type uint2でググっただけでしたorz
現在昨日から何も進んではいません。
公開は問題ないです、コメントをいただけるならぜひとも見ていただきたいです。
ただ貧乏性のため古いコードがコメントアウトで残りまくっているので…時間を頂戴したいです。
コメントアウトや#ifdefを削るとカーネル部分だけなら140行(4000Bytes)
削る前は本体2200行(カーネル600行)、ヘッダー300行。
今から…26時間以内にはどこかに載せたいと思います。
PTX見ても意味がない
SASS見なさい
ベンダーのマニュアルを読んでちゃんと理解する。 ベンダーのサンプルプログラムを読む。 これは基本で必須だと思うんだが、やらないやつのほうが多いのか? 砂上に楼閣を築くのはおすすめできないな。w あとは先人の知恵をパク、じゃなかったw、参考にする、と。 CUDA SHA-1 Tripperは大変いい。SHA-1だけど。 待て屋は参考にはならん。wビットスライスだけど。 うとりっぱーはもうダウンロードできないんだっけ?UFC-cryptだけど。 DES自体はググればいろいろ出てくるよな。 Phil Karn先生とかEric Young先生とか定番か。
>>490 SASS見てみましたけど、予想通りS-Boxのあたりでレジスタを大量に消費してました。
30以上使ってたので、実際に必要な数よりかなり多いですね。
cubinとPTXのコードが違うというのはもちろん理解してますけど、
実際の挙動はPTXのコードとプロファイリングの結果からある程度予測できるという印象です。
>>491 自分の調べた限りでは、現在のBitslice DESの最小ゲート数の実装は、John the Ripperで
使われているRoman Rusakov氏のものでした。
>>323 のSlashdotの記事で紹介されてますけど、
Kahn氏のオリジナルより17%ゲート数が少ないとのことです。
>>493 そりゃやっぱりゲート数が少ないほうを使いますよねw
正直これだけゲート数が減らせたというのは驚きです。
新待て屋というのはラデ版のことですか? それは実に興味深いですね…
>>486 よく分からないけど、変数を宣言したらその分だけしっかりレジスタ使ってくれるとか・・・?
>>487 確かゲート毎に新しく変数を用意して代入しているんだよね・・・。
>>493 見るにはどこかで登録必須?
でもSSE2とかの命令セットとかってCUDAやATI Streamで使えるの?
>>496 > よく分からないけど、変数を宣言したらその分だけしっかりレジスタ使ってくれるとか・・・?
PTXのレベルでは演算子ごとにレジスタを割り当ててます。
一応cubinに変換される段階で最適化されるはずなんですけど、あまり当てにならないみたいです。
> 確かゲート毎に新しく変数を用意して代入しているんだよね・・・。
そうです、そうです。なので、使い回せば結構変数の数は簡単に減らせるんですよね。
とりあえず10桁GPU検索のコードをPTXで書き直す前に、 今まで多少オーバーラップのあった10桁と12桁のコードを 完全に分けてしまいました。これで思う存分最適化に 集中できます。 しかし10桁GPU検索の最適化は相当な長丁場になりそうなので、 その前にコードを公開するか迷うところです。S-Boxの最適化が 一段落した段階で考えるか…
自分にはレス内容を見ても何が書いてあるのか サッパリ分からないんですけど、MERIKEN4.kさんて何をされてる方なんですか? あと失礼ですが、お歳はおいくつくらいの方なんでしょうか。
>>499 ここでやってることは本業とは全く関係ない完全な趣味です。
自分のことは自分のウェブサイトに書いておいたので
探してみてくださいな。もともと別の板でつかってたコテハンなので、
内容もそれなりですけど…
なるほど。 (`・ ω・´)な感じの人なんですねw
>>502 元気なときはそんな感じですねw 最近は(≡ω≡)こんな時のほうが多いですけど…
さて、試しに数日ぶりに10桁トリップのCPU検索ルーチンを動かしたら
エンバグしてる模様。GPU検索とコードを一部共通にしていたのが
まずかったみたいです。Bitslice DESがちゃんと動いているのは確認したので、
また明日にでもバグ取りすることにします。
504 :
362 :2011/09/12(月) 02:09:43.00 ID:m8UM7BLm0
すみません、
>>488 で26時間以内とか言っておきながら…明日の朝までには載せます。
505 :
362 :2011/09/12(月) 03:21:22.35 ID:m8UM7BLm0
26時間を過ぎて申し訳ませんが拙コードを載せました。
よければお時間のあるときに見ていただけると嬉しいです、よろしくおねがいします。
http://ll.la/0wG@ (公開期限2011-09-14(水) 03:02:59)
現在私のGTS450では233KTrips/secとなっております。
>>476 からなぜ向上したのかは不明です
(候補:ビット比較がやはり効いていた・速度計算を間違えていた)。
カーネル内の32回ループで複数ヒットした場合(可能性はものすごく小さいですが)、
最後のヒットの情報だけが残ります。
高々グローバルメモリの8Bytes×32768=256KBが8MBになるだけなので全部保存してもいいかもしれませんが…。
あるいはAtomicAdd()で速度低下がたいしたことなければ、保存場所を管理するのもアリかなと思っています。
が、今はグローバルメモリ節約よりは速度UPを優先して取り組みます。
506 :
362 :2011/09/12(月) 03:30:37.16 ID:m8UM7BLm0
すみません、
>>505 の209KTrips/sec→233KTrips/secは実行時間10秒か9秒かの違いだけでした。
実行したときによって9秒になったり10秒になったりするのですが、
秒オーダーでしか時刻を取っていないせいでこんなことになってしましました。
cuda_profileでは現在gputime=[ 4385544.000 ]です(2回カーネルを呼んでいるのでこの2倍+α)。
今後コードの変更が速度に与える影響を計る際はちゃんとprofileのgputimeを見るようにします。
507 :
362 :2011/09/12(月) 03:53:56.99 ID:m8UM7BLm0
さっき落として中身を確認しました。あとでゆっくり読ませていただきます。
>>503 のバグは無事潰せました。しかし久し振りに動かしたコードが動作しないと
心臓に悪いですねえ。でもこれでようやく安心してS-Boxの最適化に入れます。
510 :
362 :2011/09/12(月) 06:08:28.52 ID:m8UM7BLm0
>>508 ありがとうございます!
Bitslice DESの進行を遅らせることは本意ではないので、
>>509 のS-Boxの最適化など
を優先していただいてこっちは今後気が向いたときで結構です。
走査するkeyの範囲をみて問題発見(自己解決):
カーネル呼び出しの中では変化しないはずのsalt(unsigned char key[8]ならkey[1]とkey[2])の
うちkey[2]を変化させてしまっている。
一応、ShiftJISの上位8bitの候補はどれも0x7B以上であるため、ここを候補32パターンの
範囲内でどのように変化させてもsaltの計算時には'.'(==0x2E)で計算されるため問題は生じないが…。
今後の拡張時にこの点に気をつけないと誤ったsaltが使われてしまう。検索速度に影響する話ではない。
>>510 まあプログラミング自体息抜きなので、のんびりやらせていただきますw
S-Boxの最適化の方は、インラインアセンブラの使い方がわかったので
あとはせっせと手作業でゲートを変換してやるだけです。
>>486 PTXのマニュアルの予約語の部分を見てみたのじゃが、
CUDAがネイティブに対応している論理演算は標準的なもの以外はどれぐらいあるのかの?
対応していない論理演算を利用したS-boxを下手に使うと、逆にゲート数が増えかねないしの。
>>492 sboxes-s.cにあるAltiVecのvselを利用したものかの?
vselやそれに相当する命令がネイティブに実装されていないケースではどうなるのか気になるの。
まあわっちはS-boxの最適化どころか、CUDAでの実装テストもまだで
Kwan氏のサンプルコードの大部分を何とか理解した程度じゃがw
S-boxやCUDAに関係の無い部分だけでも、
最適化しようとすると凄まじいことになりそうじゃの・・・
>>512 自分が使っているS-Boxの実装はJohn the Ripperのnonstd.cにある
MMX/SSE2/AVX/RISCアーキテクチャ用のもので、ゲートの種類はand、or、xor、not、andnの
5つだけです。John the Ripperにしてはw素直な実装です。andnに対応するPTXの命令はないので
and.b32とnot.b32にばらしています。
やっぱりレジスタ数を32まで減らすにはS-Box以外の部分にも手を付けざるをえないでしょうね〜
最適化の前にできる限りシンプルにしておくつもりです。
514 :
362 :2011/09/13(火) 05:32:37.46 ID:E16g4WMF0
現在カーネルのgputimeだけで計算した検索速度の最高は現在246KTrips/secでした(<<<48,384>>>のとき)。
【以下、現状と今後の予定】
カーネルと同じ動きをするホスト関数を作って実行し、2〜3KTrips/secという結果を得る。
1年前と同じくまたもPerlに対する敗北感を感じる。
不要な計算を削ったりもしてるのに…部分もメモリ消費をケチってbitで格納しているのがまずいのか。
キー64bit→block64bit(実質56bit)→KSbit[24](KS[16][48]を32bit*24で格納したもの)のうち
block→KSbitに法則らしきものをみつけ、(この部分の)計算量が半分くらいになりそうだと
いう希望をもつ。メモリ消費も現在余裕のあるConstantMemoryの増加だけで済みそうだ。
Best Practice Guideの4.0を読み始める。
ようやく
>>411 の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アップは即性能向上を
意味するものではないよとあったはずなのであまり期待しすぎないようにトライしてみる。
515 :
362 :2011/09/13(火) 06:55:23.31 ID:E16g4WMF0
うわ…カウンタ変数i,jとmをunsigned intからunsigned charにするだけでレジスタが2本減るとは…。 occupancyは0.75から0.875へ。gputimeにして3%改善されました(253KTrips/sec)。
>>514 速い実装が欲しいならUFC-cryptを勧めます。うちのPhenom II X6ではなにもしないで
1コアで300K crypt/sでてましたよ。素のBitslice DESが500K crypt/sぐらいだったので、
UFC-cryptも十分速いです。
ようやく最初のS-Boxのインラインアセンブラでの書き換えが終了しました。 理屈がわかればあとは機械作業なんだけど、これをあと7回繰り返さなきゃならんのか orz まあ最初の書き換えがすんなり終わっただけでも僥倖なので、さっさと残りも 片付けることにします。今週中に終わればいいけど、どうなるかなあ…
>>513 変数名が凄いことになっておるのじゃが、実装自体は素直なのかの?w
あれをandnをandとnotの2つのゲートでの実装に変えると、ゲート数としてはKwan氏の物と比べて5%程度減るのかの?
スレッドあたりのレジスタ数やシェアードメモリの容量はかなり厳しいの・・・
>>514 KSは一度に作らずにラウンドごとに作ればメモリ消費量は簡単に抑えられないかの?
計算量を減らすのは展開してハードコードという力技かの。
しかしビットシフトが加減算や論理演算の3倍のコストというのは予想外じゃの・・・
>>516 UFC-cryptは280KBのテーブルが必要みたいじゃからCUDAには向かないと思いんす。
単一saltを繰り返し利用した場合に大幅な速度アップということは、キャッシュを利用した高速化かの。
しかし素のBitslice DESの6割程度ということは、やはり非並列計算では圧倒的な速度なのかの。
>>517 お疲れ様じゃの。
使用レジスタ数の削減はかなり期待していいのかの?
519 :
326 :2011/09/14(水) 04:08:34.45 ID:aT+OMMBh0
>>518 アドバイスありがとうございます。ラウンドごとに作るというのは
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がキーからのシフト演算の組み合わせで計算できそう、というものです。
アクセスは列方向になるので参照時に不利かもしれませんが。
というか今既にそういう格納をしているのでここが足かせになっているかもしれません…。
それと
>>421 でダウンロードさせていただいたcuda_sha1tripper-0.4.0.zipについて
よければ教えていただきたいのですが、cuda_sha1tripper.cuの170行で
> b64t[threadIdx.x] = b64t_d[threadIdx.x];
とConstantMemoryからSharedMemoryへコピーし、以降はSharedMemoryのb64t[]を参照
しているのは、ConstantMemoryよりSharedMemoryのほうが早いからなのでしょうか。
私の理解では、
1.8KBのキャッシュに収まる限り速度はConstantMemory≒SharedMemory
(長い逐次処理になると<、バンクコンフリクトがあると> などに左右されるものの)
2.b64tの使われ方をみるとバンクコンフリクトを完全回避できるわけではない(aの値によるランダムアクセス)
3.b64tはリードオンリー
であるためConstantMemoryを使いそうになるので、考えが至っていないところをご指摘いただけるとありがたいです。
520 :
326 :2011/09/14(水) 06:20:52.70 ID:aT+OMMBh0
>>518 失礼しました、
>>519 の
>計算量を減らす案は展開ではなく、
は間違いでやっぱり展開でした。
LibreOfficeのcalcとにらめっこしたりペタペタコピペして見通しをよくしようとしてたのに、
コーディングに入るために変換表を最初から見直ししてたら…計算規則が一目瞭然の簡単すぎでワロタ…数時間の苦労が…
>>517 CUDAによる bit-sliced DESの実装に関する論文があるのに何で読まないん(*‘ω‘ *)?
俺は読んでねーけど、全国大会のA4ピラじゃなくてフルペーパーくさかったぞ(*‘ω‘ *)?
ためになるんじゃねーの(*‘ω‘ *)?
>>519-520 言われてみればcryptの25回のDESループ内ではKSは変化しないのじゃったの。
やはり展開してハードコードが一番の気がするの。
行数が凄まじいことになるがのw
コンスタントメモリからシェアードメモリにコピーして、それを使うようにしたのは
>514にもあるように、ハーフワープ内のスレッドがアクセスするコンスタントメモリのアドレスが異なると
逐次実行になるからじゃが、見直してみるとハーフワープ内の全スレッドが同一アドレスにアクセスする部分も結構あるの・・・
酷いバンクコンフリクトを起こしていそうな部分もあるから、書き直さねばならぬの。
>>518 JtRの実装が素直なのはS-Boxの中身だけで、あとはかなりすごいことになってますねw
UFC-cryptがそれだけメモリを使っているなら、ちょっとCUDAでは厳しいですねえ。
レジスタ数の削減は予定ではうまくいくはずwですけど、実際にどうなるかは後のお楽しみです。
今ならCUDAでのDES実装の世界最先端を行くことも可能じゃね? んなもんホンキでやるやついないだろうし。w
cuda_sha1tripper-0.4.1.zip -
ttp://kie.nu/w9 cuda_sha1tripper-0.4.1_win32bin.zip -
ttp://kie.nu/wa とりあえず問題のテーブルを、コンスタントメモリ上のとシェアードメモリ上のとで
使い分けるようにしてみたのじゃが、速度は誤差程度しか変わっておらぬ。
他の部分の処理やオーバーヘッドの方が圧倒的に大きいからかの。
>>525 あのS-boxの変数は自動生成したコードそのままなのかのw
>>526 DESはそれを基にしたものはあちこちで使われておるから、
研究している所もそれなりにありそうじゃがの。
DESベースのcrypt()の方は流石にもう重要な用途ではほとんど使われておらぬと思うがのw
>>527 あちこち!?
IPsecぐらいしか浮かばない。w
何年も前に死亡宣告されたDESをCUDAでなんて需要ないっしょ。
SHA-1は(実装が)手軽だからよく使われるよね、総当たりの実験とかに。(ぇ
Ivanタン、ハァハァ
>>527 > あのS-boxの変数は自動生成したコードそのままなのかのw
変数名とか見る限り、まったくそのままなんでしょうねえw
Kwan氏は自分の作ったゲート作成用のプログラムを公開してるみたいですけど、
JtRのほうも気になります。
素のcryptを展開して、Bitslice DESを使ったものと見比べておるのじゃが、結構演算量が多いの。
展開してハードコードすればシェアードメモリの容量の問題は回避できそうじゃが、
やはり6ビットを使ってテーブル参照で4ビットの値を得るというあたりが厄介じゃの。
>>528 これから使うことはないかも知れぬが、
昔作成されてDES系で暗号化されているものとかもあるのではないかの。
531 :
326 :2011/09/15(木) 16:23:02.25 ID:PTtOmdZq0
>>516 レス遅くなってすみませんそしてありがとうございます。
Michael GladさんによるUFC-Cryptという高速な実装があるのですね。
cryptをどのように高速化しているのか興味深いのでみつかったら(理解できれば)読んでみたいと思います。
シングルスレッドで300K crypt/sというのはすごいですねそして少しショックです…。
マシン性能差とトリップ判定のことを考えるとPerlのcryptはUFC-cryptで実装されているのかな
…と思いきやCrypt::Passwdというモジュールがあるくらいだからそうではなさそう。
>>524 , 527
ご回答ありがとうございます。逐次実行によるロスを嫌ってということですね。
ハーフワープ内が同一アドレスにアクセスすることが保証されている箇所をConstantMemoryにしたと。
そして効果は誤差程度だったと…変なことを言ってお手間を取らせてしまい申し訳ないです。
>>522 (
>>342 )のタイトルで思ったのですが、学会発表などのIntroductionで
工学的・社会的意義を唱えたい場合はPassword and Key recoveryに役立ちます!
って主張するしかないのだろうか…
総当り方式だから暗号の耐久性云々の話とはちょっと違ってくるだろうし。
532 :
362 :2011/09/15(木) 16:27:18.79 ID:PTtOmdZq0
【現状+今後の予定】
KS[16][48](実際には32ビット×24で格納)の計算をシフト演算で置き換えて(
>>514 , 519)、
gputime計算で260KTrips/secと約3%のスピードアップになった。
しかし使用レジスタ数が23→27、これに伴いoccupancyが0.875→0.750に低下した。
occupancyが下がっているのにもかかわらず速度が改善されているのだから計算量は確実に
減ったといえるのだろうけど、「レジスタ使ったから速くなりました」みたいで悔しい。
演算を分割してレジスタ消費を抑えられないかを調べてみる。
途中、(x<<(-2)) は (x>>(2)) と等価ではないことを知らずにハマりかける。
なぜ等価じゃないんだ…と思ったけど、加減算などと違って左右のシフトでは使っているであろう
ハードウェアロジックが違うからかなあとなんとなく納得する。
ググろうとしても右シフトでMSBに0を埋めるか1を埋めるかの話ばかりがヒットしたので
真相は(自分の中では)闇…WikiPediaにも理由までは載っていなかった。
ビット演算 - Wikipedia
http://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++ 等では未定義動作となる。
>>527 での使い分けを見て思ったのだけど、
AバイトのConstantMemoryは、A*16バイトのSharedMemoryによって性能低下なしに
置き換え可能(逐次実行になるリスクがゼロになるボーナス付き。アドレス計算のコストは目をつぶるとして)なのだろうか。
ワープとバンクコンフリクトとバンクについての理解が全然足りないのでこれを機に調べて確認してみる。
ふむふむ
>>518 によるとUFC-cryptは280KBのテーブルを使うと…
いやまて約7*10^17バイトのテーブルを使えばO(1)で10桁トリップが計算可能…ゴクリ
533 :
362 :2011/09/15(木) 18:39:12.35 ID:PTtOmdZq0
ふとビルド時のメッセージを眺めていて-maxrregcount=32をみつけ、 今更ながらレジスタ数/スレッドは与えられるものではなく与えるものであることに気づく。 20, 24, 28のうち24が今のところベストで267KTrips/sec。 命令文の書き換えに飽きてきたのでこれからしばらくはSharedMemoryの活用に注力する。 テクニカルトレーニングVol1の「バンクの競合がなければ、共有メモリは最も高速なレジスタ」を信じて。
534 :
362 :2011/09/16(金) 04:54:05.61 ID:RqlX1DLV0
現在301KTrips/secになりました。
青山幸也先生の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さんすみません私の使い方が間違っていました…(
>>471 )
>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への置き換えを試してみる。
つ「nvcc.pdf v4.0 January 2011」 って、こんなの見ても役にはたたんか。w Cygwin 環境下で nvcc を make で、なんていうヘンタイなボクは nvcc -h > nvcc.txt したのをたまに見る。www
536 :
362 :2011/09/16(金) 14:56:59.29 ID:RqlX1DLV0
>>535 アドバイスありがとうございます!
手元にあるのは2010年11月版なのでこれを機にSDK4.0に移行しようかなと思います。
ちょうど4.0のProgramming Guideを読んでcapability1.xと2.xの違いでバンクが16とか32とか
同じ32bitワードならコンフリクトなしとかを整理したくなってきたので。
あと
>>534 の
>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)
http://www.4gamer.net/games/099/G009929/20100716100/
537 :
362 :2011/09/16(金) 15:29:23.46 ID:RqlX1DLV0
【問題点とその解決】 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に入れたいところだったけど…。
538 :
362 :2011/09/16(金) 15:31:37.57 ID:RqlX1DLV0
【本文p.170の拙訳】Programming Guide ver4.0 (2011/5/6) >《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}は、次のいずれかであるときに確実に同じバンクにアクセスしてしまいます。 >1.s*nが32(2.xにおけるバンク数)の倍数であるとき >2.32とsの最大公約数をdとすると、nが32/dの倍数であるとき >したがって、32/dが32以上のときに限りバンクコンフリクトを回避でき、 >つまりd==1で、要するにsが奇数のときです。
1ブロックで使用するシェアードメモリの容量を増やせば、
同時にロードできるブロック数が減るのかや・・・
不足したときにデバイスメモリに退避とかするより効率的なのかもしれぬが、
気をつけねばうっかりはまってしまうの。
しかし1スレッドで使えるレジスタやシェアードメモリの数はかなり厳しそうじゃの・・・
>>534 アンコアレスでそこまでグローバルメモリが速いとも思えぬが、キャッシュが効いておるのかの。
>>537 ラウンド鍵KS[]はcrypt()でも56ビットの鍵から恒等的な演算で導けるのじゃから、
展開してハードコードしてやれば不要になるの。
今やっているのが一段落着いたら試してみてはどうかの。
LとR、それに56ビットの鍵の120byteはスレッド毎にシェアードメモリで、
saltの影響を受ける拡大転置Eはコンスタントメモリで、
S-boxはコンスタントメモリもしくはグローバルメモリからシェアードメモリにロード、
余裕があればDESの入出力の64byteは余裕があればスレッド毎にシェアードメモリかの。
540 :
362 :2011/09/17(土) 02:28:54.79 ID:aNpcTVqX0
>>539 レスありがとうございます!
以下、あくまで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を使って考えたいと思います。
541 :
362 :2011/09/17(土) 02:33:50.36 ID:aNpcTVqX0
現在
>>540 ★の実現に向けてL[]とR[]をバイト格納からビット格納への書き換えが終わったところです。
原点回帰(?)で今はSharedMemoryを全く使っていないのですが、occupancy100%が効いているのか
357KTrips/secになりました。ちなみにレジスタを24本使ってoccupancy87%のときは356KTrips/secです。
あとはblock, L, R, preSをSharedMemoryにしてどれくらい早くなるかですね。
ちなみに途中で、SharedMemoryに入らないならレジスタを使えばいいじゃないと
KS[]の96バイトの半分をむりやりレジスタに入れて(配列を使えない(?)ので面倒でした)
みましたがそれでも48BytesのSharedMemory+レジスタ合計42本を使うためoccupancyが上がらず、
性能はイマイチでした(たしか200KTrips/secくらい)。
542 :
362 :2011/09/17(土) 03:07:10.03 ID:aNpcTVqX0
unsigned int block[2]をSharedMemoryに入れることで358KTrips/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マシンに触れない日が続くので続きは来週やります。
543 :
362 :2011/09/17(土) 08:40:15.40 ID:77cHGm/E0
>>540 の訂正です。
>できれば「同じKS[]を持つようなキー56bitの集合」を特定してKS[]の計算をカーネル外に
入力のキーがが56bit、出力のKS[]が768bitだから異なるキーから同じKS[]が
現われるようにはなっていないでしょうね。それでも入力のビットとKS[]との対応がきれいに
整理できるとすれば部分的に計算とメモリをカーネルの外に出せるのですが。
結局今週はあんまり時間が取れなくて、現在ようやく3番目のS-Boxの最適化に とりかかったところです。大分慣れてきたので1個あたり2時間弱ぐらいで済みそうな 感じですけど、それでも随分時間がかかりますねえ。
3番目のS-Boxの変換が終了。コツがわかってきたのでそれほど神経をすり減らす 必要もなくなりました。今日中に全部終わらせたいところだけど、ちょっと 厳しいかな〜
レジスタ数は63個でめいっぱいですけど、幸いlmemへのregister spillingは4 bytesだけなので、 レジスタ数の削減は何とかなりそうな感じなんですけどねえ。現在公開してるバージョンが OSによっては立ち上がらないのが判明したので、早めに新しい版を公開したいところです。
>>546 cudaTripper12Wiz7.exe -fastMessage off -yukiNMessage on
みたいな遊び機能はつけないんけ(*‘ω‘ *)?
548 :
362 :2011/09/20(火) 06:00:31.97 ID:IhAMgBKh0
これまで =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のシェアを上回ることは考えにくいなあと思う。
>>548 sm_20とsm_21の最適化の差が結構あるの。
25回ループの初回に初期転置を行わないだけで差が出るということは、
初期転置や最終転置をハードコードするだけでも結構な効果がありそうじゃの。
展開してハードコードは色々と大変じゃが、
色々な処理が省けるということに気がつくと中々におもしろいと思いんす。
手作業だけでやろうとすると膨大な時間がかかるがのw
550 :
362 :2011/09/22(木) 02:17:15.94 ID:Pad5dxAp0
>>549 昨日レスできなくてすみません。
最終転置についても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増えるか報告します。
この書き込みは当初「展開やハードコードはやっぱり面倒です」と書くつもりだったのですが
具体的な修正案と結び付けられると確かにおもしろいものだと思えてきそうです。
551 :
362 :2011/09/22(木) 02:28:14.88 ID:Pad5dxAp0
ちなみに
>>550 の修正はまだやってませんが、
これまで=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まで連れて行ってくれる。たぶん。
552 :
362 :2011/09/22(木) 15:13:00.82 ID:Pad5dxAp0
これまで=393KTrips/sec
→
>>550 の修正案1
=393KTrips/sec(小数点以下で改善)
→カーネルからCPUへは最終転置をせずに送り返すことにした
=394KTrips/sec
→カーネルからCPUへの出力である一致成否変数を8バイト(以前はblockを返していたため)→1バイトに
=395KTrips/sec
→
>>550 の修正案2(15bit判定のみ)
=390KTrips/secに低下 ※
→
>>550 の修正案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倍グローバルメモリにアクセスする機会が増えたことが
原因かなと推測しています。
553 :
362 :2011/09/22(木) 15:31:33.60 ID:Pad5dxAp0
途中、↓の後者よりも前者のほうが定常的に速いのがよくわからなかった。
if(){ ... ; break; }
else{ break; }
if(){ ... }
break;
return文も使えない(実行時エラー)ことに気づいた。
warp内でreturnするのとしないのが混ざっているとダメだったはずと思いきや、カウンタm,iにのみ依存する
分岐のreturn文でも実行時エラーになった。おとなしくbreak2回で脱出することにした。
ピコーン!
>>551 でf作成時に32ビットのSを使うなら、P転置を済ませたSを使ってOR結合すればいいじゃないか!
もともとは「m==0のときはL[](0確定)とのXOR演算も削れるな…でもlogical operationって
ほとんどコストかかってないよね…他に削れるところは…」という流れだったけどこれは400届くかな…?
554 :
362 :2011/09/22(木) 16:05:36.92 ID:Pad5dxAp0
これまで=397KTrips/sec
→
>>553 のP転置済みのS[]を使ってP転置をカーネル内から除去した(P[]はConstantMemory上から不要に)
=479KTrips/sec
あれっ…えっ…なんか間違いとか見落としとかありそうで怖いんですけど…でも結果は出てるし…
先日、編集中のソースはどんな計算を表しているのかがすごくわかりにくいので、
元になったkenji aiko 氏のcrypt2.cを見ながらチラシの裏に各変数と転置・変換の関係を整理していた。
その際面倒だったのでベクトル(変数)と行列(変換)のように表記していた。
「転置に相当する計算はベクトルと疎行列(要素は0/1)の積まんまじゃないか」
→「疎行列の計算に置き換えると高速化が期待できる・・?」
→「いや、その疎行列の計算に特化しまくったのが今の姿だろ…俺アホスorz」
あとThrustは内部でCUDAを使っているものであり、CUDA内部でThrustを使うものではないと知ったのもほんの数日前。
(何を血迷ったかてっきりカーネル内でSTL的なことができるのかと…)
555 :
362 :2011/09/22(木) 22:30:21.96 ID:Pad5dxAp0
解せぬ… これまで=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を開くときが来たか…
>>551 charの変数をunsigned charに変えるだけでも速度が上がるのかや。
S-boxをunsigned intに変えてビットシフトを回避というのがよく分からぬ・・・
>>555 FPはIPの逆の処理を行うから、合成すると何も処理しないことになるから、それでいいと思いんす。
Wikipediaによると、当時のハードウェアのブロック入出力の仕様が原因らしいの。
16ラウンド目はLとRの入れ替えを行わないことになっておるし、
Kenji氏などの実装では16ラウンド目にも入れ替えを行っておるから
LとRを再び入れ替える必要があるのではないかの。
Kenji氏の実装を基にしておるなら、配列の先頭を指すポインタを使うようにすれば
配列の要素を一つ一つコピーせずに、ポインタを入れ替えるだけで済むの。
SP-boxを使った実装を探してみると、色々と興味深いものが見つかったのじゃが、
結構複雑な上に、わっちはSHA-1の方の修正を行うのが先かの・・・
atomic関数を使ってデータ構造にも手を加える予定で結構時間がかかりそうじゃが、
そっちもかなり気になっておるからの。
557 :
362 :2011/09/23(金) 03:46:16.22 ID:f+10o26U0
>>556 >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入れ替えは代入文で済ませています。
558 :
362 :2011/09/23(金) 20:50:17.40 ID:f+10o26U0
これまで=487KTrips/sec、KSの格納方法変更後=605KTrips/sec
現在は転置処理省略の最後の砦(?)、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%ほど改善された(
>>532 )。
しかしこの方法では次の問題があった。
1.あるステージiのときにKSa[0]〜KSa[23]の全てアクセスする必要がある(
>>519 の列方向云々)
2.その後の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[]からの
作成速度は俺の考えられる範囲では最善だということ。ここを何とかするアイディアは
ないではないけど、非常に面倒だしやってみないと速くなるか遅くなるかわからないので後回し。
559 :
362 :2011/09/23(金) 22:10:08.75 ID:f+10o26U0
これまで=605KTrips/sec preS導出を32ビットXOR2回で行うようにした=840KTrips/sec (速度には関係ないが可読性のためE[]生成にも多少手を加えた) もう削れる転置が残っていない…たぶん…
560 :
362 :2011/09/24(土) 00:52:52.22 ID:hDAGRmKB0
これまで=840KTrips/sec →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くらいだろうか。と自分を追い詰めてみる。
atomic関数等を調べようと、プログラミングガイドを見ておったのじゃが
SMあたりのスループットの表を見て、CC1.xとCC2.0とCC2.1では
コアあたりのシフトや乗算のスループットがかなり異なることに今更ながら気がついた・・・
GF100系とGF104系での性能差は、コアあたりのレジスタ数だけの問題でもなさそうじゃの。
>>557 もうucharの配列ではなく、uint32にビット格納にしておったのかや。
メモリ消費だけでなく演算量もかなり減って効果も大きそうじゃの。
主様のおかげでSP-boxを利用した実装の理解も少しは楽になりそうな気がしてきたの。
ビット格納の場合はkeyからKSを生成するのに結構な演算量になりそうじゃから
メモリ使用量が増えるのは我慢してKSを保存しておいた方がいいのかの・・・
ドキュメントを読み返していて重要なことに今更ながら気がついた。 Compute Capability 2.0以降でSMあたりのコア数やレジスタ数が増えておるが、 同時にロードできるブロック数の最大数はSMあたり8のままで、 上限が上がっておるのはSMあたりのワープ数じゃった。 ブロックあたりのスレッド数を増やすしかなさそうじゃが、難儀しそうじゃの・・・
cuda_sha1tripper-0.4.2.zip -
ttp://kie.nu/Lq cuda_sha1tripper-0.4.2_win32bin.zip -
ttp://kie.nu/Lr とりあえず共有メモリの使用量が多くてFermiより前のGPUで
アクティブになるブロックがSMあたり1つ(となると思われる)バグの修正と多少の改良を行ってみたの。
Fermiシリーズでは特に差は見られないと思いんす。
CUDA Occupancy Calculatorを使ってブロックあたりのスレッド数を真面目に検討しておるのじゃが、
やはりレジスタ数の制限が厄介そうじゃの・・・
ブロックあたり192スレッドで、SMあたり8ブロック走らせるには スレッドあたりのレジスタ使用量を20にまで減らさねばならぬというのは結構厳しいの。 レジスタ数のオプションを色々と試しておるとP-stateが一番上まで上がらぬようになったのじゃが、 ドライバの省電力機能が誤作動したのかの・・・
パスがわからない・・・orz
MERIKEN氏のを使い始めたんだけど、CPUGPU両方使用中にPauseキーで止めると
表示は止まるけどCPUは走り続けるんですね
これでしばらくしてからPause解除するとmaximamの数値がえらいことになるけど
>>565 メール欄
>>566 トンクス
コード読んでて気がついたんだけど、カーネルの下の方にある
out->trip[いっぱい]=b64t[a〜c];
この11行ってa,b,cだけをホストに返して、変換はCPUでやったほうがいい気がします。
568 :
362 :2011/09/25(日) 21:40:22.22 ID:iu5ihCXs0
>>561 自分のほうはSP-boxが何なのかも存じ上げませんが、結果として何かプラスになっていれば幸いです。
今のところは、KSはmの25回ループの前に生成したものを保持しておく方針です。
ただwarp divergence避けとLocalMemoryへのアクセス回避を両立する方法として、
毎回計算という案も捨ててはいません。
keyからKSの生成の演算量は小さくできたと思いきや大して効果がなかったので(後述)、
これからwarp divergenceを起こさないような生成方法にする予定です。
それと
>>563 ありがとうございます、今回もダウンロードさせていただきました。
569 :
362 :2011/09/25(日) 21:53:24.75 ID:iu5ihCXs0
>>560 で言った1490は幻でした。
交番二進符号(グレイコード)を使って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%)速度が改善された。
570 :
362 :2011/09/25(日) 21:56:37.67 ID:iu5ihCXs0
【これまでその2】
あと今更ながら64bit整数の演算が使えることに気づく。なぜ
>>561 のスループット表に載っていないんだ…。
可読性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的な(?)方法もあるけど…。
P-stateが上がらない症状は再起動して直ったと思ったら、また発症しおった・・・
原因がよく分からぬが、切り分けのためにも専用マシンが欲しくなるの。
>>567 CPUでの処理をなるべく軽くしたかったのじゃが、
ワープ内の他のスレッドを待たせることになるというデメリットもあるの。
そのままreturnして、そのスレッドはそれ以上検索しないのをまずは何とかしようと
データ構造の見直しも考えておったのじゃが、キーの情報は30ビットじゃから
出力全体をuint32の配列にしてCPU側で色々と処理するのもよさそうじゃの。
>>568 SP-boxはS-boxにP転置を施したものをそう呼んでいる実装がいくつかあって
発想としては主様と同じかと思いんす。
>>569-570 KSの生成にグレイコードやパスカルの三角形を使う方法もあるのかや。
わっちの頭では思いつきそうにもないの。
ループカウンタの話はBest Practices Guideの6.3かの。
オーバーフローの検出のしやすさでコンパイラでの最適化のしやすさが変わるのかの?
大量のドキュメントを読むのは面倒じゃが、やはり重要じゃの・・・
一般向けのGeForceシリーズでは倍精度の性能に制限がかけられていたり、
モデルによってはそもそも一部のユニットしか倍精度に対応していなかったりするようじゃから
64ビット整数も同様なのではないかの。
やあ。 やっぱし同じところで躓いてるんだな・・・ 命令コードのサイズに縛りさえなければ、KS[16][48]を作らずにK[56]のままやったほうが効率よさそうなんだけどね。 つまりオリジナルのBitsliceのコードみたいに16イテレーションを全てアンロールしてしまう、と。 ところでKnights Cornerはかなり安いらしいんだが物理演算アクセラレータとして コンシューマ市場に出たりとかしないかねえ?
573 :
362 :2011/09/27(火) 21:44:02.93 ID:uTyvzxn30
【現状】
前回まで=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
【
>>571 の◆Horo/.IBXjcgさんへ】
自分が思いつくようなことは効率のよくないやり方orよくて車輪の再発明だろうとは思っていましたが、
(既存のstudyをちゃんと調べていない時点で当然ですが)PとS-boxの合成もそんな感じですね…。
おそらくpreS[]生成時のE転置とS(P)-boxの転置の2つは最後まで残る(削れない)だろうと考えてます。
あるキーkey1におけるKS1がわかっているときに、key1のうちの1ビットだけを反転させたkey2における
KS2を、少ない計算量(あくまでもKSをゼロから作るときに比べて)で求めるときにグレイコードを使ってます。
ちなみにグレイコードがv^(v
>>1 )で列挙できるのはWikipediaを見て初めて知りました(テーブル要らんかった…)。
パスカルの三角形はただnCrを求める(0-255のうちビットがいくつ立っているかで分類するため)のに使っただけです。
そうですBest Practice Guide4.0の56ページの6.3です。
TeslaとGeforceでの差別化ということですね。不良コアはまだしも意図的な制限ならちょっと残念です。
「Tesla100台でHPC」はすごいと思いますが、「一般向けのGeforce100台でHPC!」だったらもっと夢があるんだけど。
いやいや、32bit整数演算で夢を追い続ければいいのか。
【次回予告】
あれ?KSの半分はConstantMemoryに入るんじゃ…と
>>560 にも懲りずに自分を追い込んでみる
てかKSの生成自体はってそんなに時間食わなかったと思うんだけど。
まさかとは思うけど、KS生成のたびにキー文字列を律儀にtransposeしてる?
#ABCDEFGH
とする。これを前半のABCDとEFGHにわけよう。
EFGHの部分は128個のキー全く別々の文字列にしてパックする。
ABCDの部分は同じ文字をパックする(転置したビットパターンは00000000かFFFFFFFFで表現できる)
シーケンシャルに変更して最後まで達したらEFGHの部分を再生成する。
あと、transposeは1ビットずつちまちますんなよ。
http://www.hackersdelight.org/HDcode/transpose32.c.txt
> ののたんぺ
初歩的なことだけど、CUDAの機械語でサポートしてるビット論理演算って
未だにand, or, xor, notだけなの?
http://www.openwall.com/john/ もう4ヶ月前の話ですまんが、なにやらJtRの人がvselを使った最速のS-box作ったらしい。
JtR本体はGPLだけど新しいS-boxは劣化BSDライセンスで使えるから関係各位は
とりあえずマージしとけばいいよwww
ダニーはもうトリップなんてものにまったく興味なくしたのかと思ってたら。w つーかさ、情報収集能力に長けてる私にそんな情報をいまさら。>最速S-boxww w ww 奇怪語とかの低レベルな話はキライだって知ってるだろ? まあ、s2uwとかつくっちゃったし、もはや説得力ないか。 ra8最高!(和良
まあ正直、新たに何か作る気は無い。 2chがDESだのSHA-1だのオワコンの暗号形式にこだわってるのはなぜかって ぶっちゃけ管理者が馬鹿なだけだからな。 てか、今年11月までのレンタル料しか払ってないからあのサイトどのみち消えるよwww
>>577 だから再配布する権利をよこせ。wいや、くれ。いあ、ください。
てゆか、上の方で言ってるのって、TXのやりかたじゃん。w
勝手にやってくれ
そしてまた見た人全員に許可が出たものと解釈される。www
その辺含めて勝手にしてくれ どうせ現状でもBrothersoftに無断配布されてるんだし
グローバルメモリの配列をuint32にするために、とりあえず構造体をuint32のものにして CPU側であれこれやってみたら遅くなってしもうた。 非同期にしておらぬからCPUでの処理に時間がかかって足を引っ張っておるのかと プロファイラで確認すると、sha1trip_serach()のGPU Timeも伸びておった・・・ キーの5文字30ビットをuint32にするのは演算量が増えてデメリットが多いの。 トリップのBASE64エンコードだけCPU側での処理というのも試してみたのじゃが、 先頭30ビットがヒットする確率が高くないせいかGPU Timeの差は0.1%以下でしかなかった。 他の部分の改良が済んでCPUでの処理を非同期にした後でまた試してみるかの。
583 :
362 :2011/09/28(水) 23:34:20.01 ID:V2vI8QA30
【現状】
予告どおりKSの半分をConstantMemoryに入れる方向で修正した…がバグがあり正しく動作しない
走査範囲がガラリと変わったこともあり段階的に試していなかったのでどこが間違っているのかさっぱり…
偏った走査になるというデメリットもあるし速度がどうなるかはバグをなくしてからのお楽しみだけど、
これまでLocalMemory(GlobalMemory)に置かざるをえなかったKSへのアクセスの半分が大幅に改善されるはず。
どこだ…どこに間違いがあるんだ…
>>574 アドバイスありがとうございます!
キーから1回1回転置するようなことはやってないです。
>>573 の↓です。
>あるキーkey1におけるKS1がわかっているときに、key1のうちの1ビットだけを反転させたkey2における
>KS2を、少ない計算量(あくまでもKSをゼロから作るときに比べて)で求める
またPC1_C・PC1_D・PC1_D・PC2_Dの転置は合成して1つの転置にしています。
転置後のビットパターン順で0からFFFFF...まで走査するというやりかた(?)は
1.KS(i==0)は0〜FFFF..に並ぶが、KS(i==1〜15)は結局転置が必要
2.トリップとして有効な値域(文字コード)かの判定が厄介
だと思うのでやってないです。
ちゃんと考えるのはバグ取りが終わった後にさせてもらいますが、
これって32x32の2値行列の数学的な転置(aij==bji)ではないですよね?
DESでやっているシャッフル的な転置も可能なのでしょうか。
なんか沸いてきた(*‘ω‘ *)…
わーい
ちんでみたらいかがでしょうか(*‘ω‘ *)?
587 :
362 :2011/10/01(土) 00:32:49.73 ID:C6U3mSQQ0
これまで=961KTrips/sec
→KS[]の半分をConstantMemoryに入れた。=947KTrips/sec(ガーン…)
これに伴ってSharedMemoryの使用量もMAXの半分である4096Bytesにはできるはず。
2日間ほど正しい結果が出ずに辛かったが今は正しく動いている(と思う)。
しかしなぜか速度は落ちた。てんこ盛りになっていたデバッグコードは
除去したはずなので、この方法の効果が薄かったということだろうか。
いやそんなことはない(と思う)!
今後はいくつか気づいた自明な演算の除去などの調整をして再チャレンジ!
デバッグの日々で思ったのは、CUDAコンパイラの最適化は相当手ごわそうだということ。
「結果は正しくないけれど本番と同等と思える(思えた)」コードでは1000KTrips/sec越えがよく出る。
>>560 の1490とかいう妄言とは違って、ループの回数を削る・処理を丸ごと削るなどはしていないのに。
何らかの間違いのある処理から不要な部分を見つけ出してショートカットしているのだろうか。
正しい処理は、効率の差はあれど情報処理的に冗長ではないってことかな。
妄言といえば、KS生成速度が
>>560 の1/50だとか
>>590 の1/127とかも間違いでした。
初期の方法と比較しても最大で1/56、グレイコード使用による効果は
最大で1/7(使用グレイコードのビット数7)しか得られないはず。
588 :
362 :2011/10/01(土) 21:22:29.38 ID:C6U3mSQQ0
【現状と今後】 速度は変化なし。 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に達してるからこれを以って高速化…ゲフンゲフン…
589 :
362 :2011/10/01(土) 21:24:02.84 ID:C6U3mSQQ0
>>574 おかげさまでやっと意味が(なんとなく)わかってきました。
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による超高速ビット演算
http://dsas.blog.klab.org/archives/51389536.html 【※2】だんごやさんの覚書き - Bitslice DES
http://dango.chu.jp/hiki/?Bitslice+DES 【※3】お馬鹿な猫の備忘録 DESやcryptのCUDAでの実装の論文
http://nahgo.blog100.fc2.com/blog-entry-23.html
590 :
名無しさん@お腹いっぱい。 :2011/10/02(日) 13:08:07.43 ID:AgCWtxgU0
591 :
362 :2011/10/02(日) 13:13:29.92 ID:fRC3IjyG0
>>589 >道理でbitslice DESにボロ負けするわけだ。
誤解を与えるとまずいので
>>589 の発言に補足させていただきますと、
bitsliceを使えば楽に高速化できるとは思っていません。
推測ですが、大きな一時記憶領域が必要だったり地道な展開が待っていたりと
CUDA化する際の課題は色々あるはずで、にもかかわらずそれを実現した
◆MERIKEN4.kさんには恐れ入るばかりです。
592 :
362 :2011/10/02(日) 13:23:47.51 ID:fRC3IjyG0
これまで=947KTrips/sec(方式変更でダウン(
>>587 ))
→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さん
>>464 さん,, ・´ ∀ `・ ,,)っ-○○○さんはじめ
スレのみなさんありがとうございました。
今朝まではだましだましで1000に触れるくらいしかないと思っていましたが、
1割オーバーできて正直ビックリです。
E転置の方式変更も、後述の__ffs()のために作った配列を使ってみただけだったのですが。
ちゃんと走査できているかのチェックはごく簡単にしかしておりませんが、
勝手ながら、ひとまず自分はこれで一区切りしたいと思います(9月中のように
まとまった時間を取ってコーディングすることはしないと思います)。
それにしてもよかった、これでGTX580を買わずに済んだ…。
593 :
362 :2011/10/02(日) 13:48:03.64 ID:fRC3IjyG0
【経緯その1/2】
KSの半分をGlobalMemoryからLocalMemoryにおいてわずかに速度が改善されたが、
その理由は深く考えなかった。しかし別件の検索中に次のような記述を見つける。
GPGPU 勉強会 - CUDA Mistakes
http://epa.scitec.kobe-u.ac.jp/~gpgpu/hiki/hiki.cgi?CUDA+Mistakes >local領域はデバイスメモリにあるのだが、local領域はつねにスレッドと
>同じ数だけあるので、自動的にコアレスされるらしい。
なるほど。GlobalMemoryに置いたときもcoalescedになるように気を付けたはず
だったけど、元々ホストからも他のスレッドからも参照される必要のない変数なので、
LocalMemoryに入れてコンパイラに任せたほうがよかったのかもしれない。
時間計測はCUDA専用の関数があったと思いきやそれはカーネルの外での
話(cudaEventCreateなど)で、カーネル内ではclock()でよかったのだと知る。
早めに使っておけばよかった。ここで使うclock()もCUDA専用ではあるけど。
時間計測の結果からE転置が最大のネックであろうと判断する。
594 :
362 :2011/10/02(日) 13:52:45.86 ID:fRC3IjyG0
【経緯その2/2】 時間計測と前後して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つくらいだろうか。 1.__ffs()が単純に遅い (Intrinsic Functionなのに?) 2.ループ判定中の__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は使えなかったので↑のような配列を作ることになりそれを流用した。
それよりだんごやさんの家の移転先どこがいいかの?
596 :
名無しさん@お腹いっぱい。 :2011/10/02(日) 16:45:15.84 ID:I+BxO05p0
GTX480で280M程度しかでないのですがこんなもんですか? 他のは倍出ているような気がするのですが・・・・ドライバは最新のにしました。 Windows Vista Ult 64bitです Q6600@3.2GHzです。
>>596 > 他のは倍出ているような
他のとは何のことでしょうか(*‘ω‘ *)?
>>592 > おかげさまで念願の1MTrips/secに到達することができました。
よくわからんなぁ(*‘ω‘ *)
GTX480で1MTrips/sってこと?
Bitsliced-DES使わないで、wiz7はGTX460で1.5MTrips/s 出てたけど。
とあるボトルネックを解消できたら、その数倍は出そうな感じだったな(*‘ω‘ *)
なので、俺の感覚は
>>466
VSELとか3入力のXORとかあれば高速化できるのにな。 SHA-3がもうじき決まるし次のトリップ仕様でも検討しようずww
>>599 > SHA-3がもうじき決まるし次のトリップ仕様でも検討しようずww
ドラフトなり、叩き台なりつくってみれ(*‘ω‘ *)
601 :
362 :2011/10/07(金) 07:22:53.75 ID:vuF0uemW0
>>598 1MTrips/sはGTS450 GDDR5-1GBでです。
>>362 は全てこの環境です。
GTX4xx系や5xxにするとどのくらいになるかはわかりません。
occupancyが下がっても速度が変わらないのでメモリバウンドだとは思うんですが。
それと「GTX580を買わずに済んだ」とは書きましたが仮に俺が買うとしたら
cc2.1対応のGTX560tiですね。FermiシュリンクじゃないほうのKeplerまで待ちますけど。
【余談】
DirectXの10や11の序盤のチュートリアルでシェーダ言語が出てくることに驚く。
しかしCUDAのおかげで自分が理解できそうなこと・できなさそうなことの判別はできる程度に。
1ヶ月前なら*.fx/*.hlslファイルを見てもちんぷんかんぷんだったはず。
DirectX9でDrawPrimitive()していた頃とは隔世の感があるけど、
確かに行列積の計算をGPGPUで…じゃなくてGPUの本来の仕事として行えば
速度を落とさずに色々できそうだなぁと夢がひろがりんぐ。
cuda_sha1tripper-0.5.0.zip -
ttp://kie.nu/14K cuda_sha1tripper-0.5.0_win32bin.zip -
ttp://kie.nu/14M 色々と見直して大量検索時の速度低下を抑えるようにしてみたのじゃが、
恩恵を受けるのは巨大なワードリストを読み込ませているようなケースぐらいかの。
それにキャッシュを当てにしておるから、Fermi以降で無いと厳しいかも知れぬ。
>>596 ソフトの方のバージョンも書いておいた方がいいと思いんす。
とりあえずGPU-Zや類似ソフトでクロックや負荷を確認かの。
>>601 AMDは次世代GPUを年内に投入という話が出ているみたいじゃが、
Keplerも近いうちに無事登場してくれるのか気になるの。
cuda_sha1tripper-0.5.1.zip -
ttp://kie.nu/17s cuda_sha1tripper-0.5.1_win32bin.zip -
ttp://kie.nu/17t 変更は優先度を設定するのをやめたのと、コメント部分のミス修正ぐらいかの。
ローテートが無くてシフトが重いというのは厄介じゃの。
PTXにはbfiとかがあるようじゃが、それらを使うと多少はましになるのかの・・・
なんでDLパスワードがかかってるの?
Quadro6000で何も工夫せずにやって430MTrips/sぐらい。 ちなみに64bitビルド。 ちゃんと工夫すれば800Mぐらいいくかな?
>>604 よくわかっていない者がダウンロード・実行して文句を言っても困るからの。
じゃがあのアップローダは一覧表示も無いようじゃから、その心配もあまりないかの。
>>605 Quadroとはまた凄いものを使っておるの。
SMが14基でクロックが1150MHzのようじゃからそれぐらいではないかの。
検索速度(MTrips/sec) / (SM数 * シェーダクロック(GHz))
の値はCC 2.1では28〜30、CC 2.0では26程度になるのかの。
SMあたりのコア数が増えて加算や論理演算のスループットが上がったようじゃが
スレッド数も増やせておらぬし、あまり恩恵を受けられておらぬの・・・
初期化をGetTickCountでやってるみたいだけど、それだと高々20bit程度しか乱雑性が確保できないから、事実上作れないトリップがかなり発生してるとおもう。
>>606 そのパスワードってどこかに書いてあるの?
それとも身内用?
[sage SHA-1] ↑ ココダイジ
>>609-610 その辺は既に試してみたんですが駄目でした。
が、今日もう1度見てみたところCookie要求されていたのに気付き・・・。
どもでした。
Could not create a new key container と出て起動できんのだけど、何か足りない? GTX260、280.26、toolkit4.0.17
613 :
名無しさん@お腹いっぱい。 :2011/11/06(日) 10:57:49.43 ID:eJUK4Flk0
pOcac3dkOs 完全一致で検索お願いします ここに晒してください
CUDA SHA-1 TripperはPauseキーでCUDAだけ一時停止出来るようですが、途中経過をファイルに吐いて完全に停止する方法は無いのでしょうか? このままではスリープしか出来ない。 【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....
615 :
362 :2011/11/19(土) 19:59:41.47 ID:rn2ArDyd0
>>603 【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
バージョンが違いますが
>>447 さんのGTX460と比較すると
173.8*(1.4/1.62)*(7/4)=262となって大体スペック通りでしょうか。
実は◆Horo/.IBXjcgさんのcuda_sha1tripperは
ソースを拝見させていただいていたものの、12桁トリを使うことが
なかったためビルド・実行は一度もしたことがありませんでした。
今日12桁トリを作りたくなったので使わせていただきました。
6文字トリが20分足らずで…改めてありがとうございます!
>>612 同じエラーが出て実行出来ない。
Quadro FX3800, WinXP 64bit
>>614 CUDA SHA-1 Tripper MERIKEN's Branch の
> On average, it takes 14.6 years to find one match at this speed.
ここいらの計算、9完以上だと間違ってるような気がする(*‘ω‘ *)
ホシュ 忙しそうだねメリケンさん
>>612 >>616 チラッと見た感じ足りないのは権限ぽいね。
Administratorとかで起動すれば動くかな?
検証も何もしてないのでこのカキコをあまり信じないように。w
620 :
616 :2011/12/07(水) 19:36:39.72 ID:6ZlDEwX30
>>619 一応アドミン権限付きのアカウントで実行した。
別のWin7マシンでは普通に動くんだけどなぁ。
621 :
612 :2011/12/07(水) 23:05:54.92 ID:Egafq4Au0
自分もadminで起動してる 書き忘れたけど、win7の64bit
ソースのエラー表示してるとこチラッと見たら、暗号化関連のライブラリ関数呼んでたし、 XPってことだから権限関係かなと思った。 エラーコードを表示させるようになってないから、原因コードがわかんないんだよね。 あとは、.NET のなんとかがいるとか、ランタイムとかそんな話かな。 MSDNライブラリとかDependency Walkerとかで確認すればわかるかもしれないけど、今日はもう寝る。w
624 :
◆MERIKEN4.k :2011/12/09(金) 16:01:29.11 ID:8NFpDmYO0 BE:997515735-2BP(12)
皆様大変ご無沙汰しています。ここ数ヶ月本業が忙しくて
プログラミングに全く時間がさけませんでした。
いろいろ報告していただいたのに返事が出来ず
申し訳ありませんでした。
>>612 さんに報告していただいたバグの件ですが、
お察しの通りCrypt APIの使い方を間違えたために発生したもので、
手元の開発版では既に修正済みです。クリスマス休みあたりに
まとまった時間が取れそうなので、近いうちに修正したバージョンを
うpします。
625 :
612 :2011/12/09(金) 21:19:51.55 ID:HTK8s1jz0
ありがとうございます 気長に待ってます
>>624 CPU検索機能付きバージョンまだー(*‘ω‘*)?
なんたる誤爆
629 :
362 :2012/01/23(月) 23:20:45.33 ID:EBH+ywV40
Keplerを楽しみにしてるんですが、いつ発売するしないの情報はともかく アーキテクチャについて早く知りたいですね。 Tesla→Fermiのときのようにレジスタが増えるとかシェアードメモリが増えるとか 夢だけは果てしなく広がるんですけどね。 完全に私事ですがDirectX/DirectComputeの勉強は全然進んでませんw
Keplerはかなり性能がいいみたいですねえ。 GTX 680が欲しくなって来ました。一時期7970を買おうかとも 考えてたんですけど、迷うところです。 900WのUPSを新調してひっそりとTripperの開発を再開したのですが、 無茶をさせすぎたせいかうちの580ちゃんは入院してしまいました。 正規表現の検索に結構大きなバグがあるみたいなので、 カードが戻ってくるまでソースを眺めることにします。
632 :
◆MERIKEN4.k :2012/03/19(月) 06:54:44.63 ID:EcG6ZFcb0 BE:1995030465-2BP(12)
>>631 どもども。本業で時間を取られすぎていただけなんですけど、もうちょっと時間をうまく
つかえるようになりたいですね。
さて、580ちゃんは帰って来ましたが、こんどはマザボがおかしくなってしまいました。
580の電圧を1100mVまで盛って930MHzまでOCしつつTripperを走らせてたら、
ブルースクリーンが出てWindows 7が立ち上がらなくなってしまいました。
インストール用のDVDすら動かないのでどうしようか悩んだのですが、
さいわいXPはまだ立ち上がるので、開発はXPで続けることにします。
皆さんもOCするときには気をつけて下さい。
GTX580を走らせているPCは娯楽用なので当分このままにしておいて、
夏になって時間ができたらマザボをGigabyteの3-way SLI対応のものに新調して
Windows 7をインストールし直す予定です。それまでにはもうちょっと開発が
進んでるといいなあ。
633 :
362 :2012/03/22(木) 23:44:54.17 ID:Zce3WSx+0
634 :
362 :2012/03/22(木) 23:48:39.54 ID:Zce3WSx+0
日本語の記事4つを読んだものの俺レベルではよくわからないというのが
正直なところですが、思ったことを数点+α。
(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に
クリーンインストールして、
>>592 のをビルドしたら約800KTrips/secに落ちました…。
ビルドオプションなどをチェックしたものの現在に至るまで原因は不明。
>>592 の時点でバグがありそうな気もしています。
635 :
名無しさん@お腹いっぱい。 :2012/03/25(日) 23:03:28.71 ID:O+ccD8vw0
636 :
◆MERIKEN4.k :2012/03/26(月) 06:21:27.19 ID:lAcflTK50 BE:3192048768-2BP(12)
ゲームをやってる分には680で大分性能が向上するんでしょうけど、 GPGPUだとかなり微妙ですねえ。これは次の780を待ったほうがいいんでしょうねえ。 とりあえず580から搾り取れるだけ絞りとって、夏休みにはRadeon HD 7970を買って Direct Computeに手を出してみようかしらん。
638 :
362 :2012/03/27(火) 00:50:53.76 ID:lv5DG0t20
>>636 Radeonは全くわかりませんが、HD7xxx(GCN)はGPGPU寄りになったらしい話は聞きますね。
>>637 コプロセッサ的位置付け(?)になって値段が跳ね上がるようなことが
ないことを祈ります。
SDKを4.1にした後で
>>615 のを走らせると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。
639 :
362 :2012/03/27(火) 01:02:17.67 ID:lv5DG0t20
失礼しました、Kepler2はTeslaシリーズに相当するものが出るということですね。 個人的には1万2万で買えるビデオカードにも「ムダに」GPGPUの機能が盛り込まれている、 という状況が続いてくれるとありがたいんですけどね。
640 :
◆MERIKEN4.k :2012/03/28(水) 12:50:30.75 ID:xNtu6SZY0 BE:1795526993-2BP(12)
>>637 >>639 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.
641 :
◆MERIKEN4.k :2012/03/28(水) 12:51:12.77 ID:xNtu6SZY0 BE:4788072498-2BP(12)
>>640 最近はTesla2070cがヤフオクで10万以下で出てたりします。
もはやTeslaは世界中のGPGPUのデファクトスタンダードなので、
安くなるのも早いと思いますよ。
643 :
362 :2012/03/29(木) 00:46:50.95 ID:dOoqFXZM0
>>641 浮動小数点演算を使ってない限り、GK104はグラフィック寄りと言うより
GPGPUを捨てたと言いたくなりそうな変化ですね。
CUDA Coreあたりの性能が落ちるとは聞いていましたが、
まさか単純な部類(?)だと思っていた整数演算・ビット演算が削られるとは。
一番時間がかかっている転置処理でシフトを多用してるのに所要サイクル8倍とか…。
ただ商品としてはおそらくこっちの方向のほうが正しいんでしょうね。
ゲームはもちろんのこと、GPGPUという枠の中でもエンコードなどfloat演算が多くを
占める(?)処理では、coreが増える分パフォーマンスが上がると思いますし。
GTX680をメインに使って、GTX580はPhysXSLI&解析用に使えばいいんじゃない? SLIしながらトリップ解析なんかしたら、画面重すぎてまともにPCいじれないからね〜
やけに時間かかるなぁと思ってよく見たら数世紀かかるらしいのでやめた
GTX680とか670での報告求む
>>645 続けてれば今頃終わったかもしれないのに><
お金持ちキタル
Device 0: "GeForce 8800 GTS" 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しか使わないのかね?
スマソ[-d device]オプションで複数起動できた
10桁どうなってるの今?
超久々にトリップ検索について調べてたけどcuda_sha1tripper-0.5.1ってもうダウンロードできないんかな? 古いバージョンは持ってるんだが、新しいのを試してみたい…
開発終了?
KEPLER-2待ちでは?
シェーダーのパフォーマンスは上がってるんだからCUDAじゃなくてシェーダーで計算すれば今のkeplerでも速くなるんじゃないの? と素人考えの俺
ナイスボケ Shaderを汎用的に使ってるのがCUDAだ
ということはkeplerに合ったプログラムを書けば速いんですね! やったー!
誰かsha1tripperの最新版くだしゃい…
>>652 からずっと待ってたんです…
>>656 イ`ヘ
/: :| ヽ
/ : :/ ヽ ___ _,,,:. .-: :´彡フ
_ノ\_∠: : : : : : : : :`: :-: :,:_:/彡 /
( : : : : : : : : : : : : : : `ゝ /
マ r::/: /: : | : : : : : : : : ::\ /
//: /: : : |: : | |: : |: _: : : :ヽ
ジ {/ 7|`\/i: /|:|/|´: : : : :|ヽ
〉 ,‐-‐、`|7 || |_::|,_|: : :|:::|: |
で / r:oヽ` /.:oヽヽ: :|: | :|
{ {o:::::::} {:::::0 }/: :|N
っ | ヾ:::ソ ヾ:::ソ /|: : |
!? ヽ::::ー-.. /ヽ ..ー-::: ヽ::| r--ッ
-tヽ/´|`::::::::::;/ `、 ::::::::::: /: i } >
::∧: : :|: |J \ / /::i: | /_ゝ
. \ヾ: |::|` - ,, ___`-´_ ,, - ´|: : :|:::|
ヽ: |::|\  ̄/ /| |: : :|: |
ノートだけどGTX680MでKeplerなんで報告。 使用バージョンはCUDA_SHA1_Tripper_MERIKEN0.02 デフォ設定の7完で探すと平均約280MT/sで、GTX675Mの273MT/sとあんま変わらないなって印象 …と思いきや、ブロック数を設定できる中で最高の16に上げたら約290MTrip/sになった やっぱりKeplerはクロックを落として数を増やして性能向上してるからなんだろうか 俺はただ使わせてもらってるだけのド素人だから、何か書き方がまずかったりしたらすまん 協力できることあったら、言ってもらえれば引き受けます
663 :
名無しさん@お腹いっぱい。 :2012/08/11(土) 14:57:40.96 ID:fZAKPWcy0
GUIマダァ-? (・∀・ )っ/凵⌒☆チンチン
俺すらソースコード紛失して同じもの作るの二度と不可能だけどな
日本語を正しく書けない奴が正しいコードを書くことは稀だからな。 正しくないコードを後から同じように書くのは難しい。
>>665 は何も見ず10年前と全く同じ文章書ける人なんだな
もしくは同じコードを覚えていられる程度のコード量しかかけない著しくコードの生産性の低い人か。
2chでtypoを盾にポジショントークするアホなんざ放っておけよ そういうのに限ってサンデープログラマですら無かったりするんだし
皆様大変ご無沙汰しています。いろいろ報告していただいたのに
忙しさにかまけて返事を怠ってしまい申し訳ありませんでした。
お詫びと言ってはなんですが、1年ぶりにCUDA SHA-1 Tripper MERIKEN's
Branchを更新しました。
http://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch 新しいバージョンは0.04 Alpha 1で、主な変更点はOSによっては起動
しなかったバグの修正と、10桁検索への暫定的対応です。最適化は全く
進んでいないので速度は期待しないでください。
>>612 さんに報告して
いただいたバグはこれで潰されているはずです。
ようやく実習が終わって多少時間が取れるようになったので、
当分の間は10桁検索の最適化と、正規表現と検索時間予測の不具合の
修正に費やすつもりです。
>>662 Keplerでの報告は貴重なので助かります。ありがとうございました。
正直なところKeplerにしては意外に速度が出ているという感想です。
新しい開発版ではブロック数をもっと大きく設定できるので是非試して
みてください。
いずれKepler向けのコードも埋め込む予定で、そうすればもっと速度がでる
はずです。ただ、CUDA Toolkit 4.1と4.2を試してみたのですが、マクロを
乱用していた箇所でコンパイラが落ちてしまい、ビルドができませんでしたorz
うまく行ったらまたここでお知らせします。
最近新しいPCを組んでCore i7-3770Kと580 SLIの組み合わせに 移行したのでこちらの方の最適化も進めたいと思っています。 特にSLIへの対応は効果が大きいと思われます。 1.6T tripcodes/sぐらい出るんじゃないかと期待しているんですが…
SHA-1_Tripper_MERIKENs_Branch.exe 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.
SHA-1_Tripper_MERIKENs_Branch.exe -c -g 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.
>>671-672 本当にお久しぶりです! 早速試していただいてありがとうございます。
妙にCPU検索が遅いなと思ったら、最適化するのを忘れていたみたいです…
今はなんとかToolkit 4.2でコンパイルできるようにコードをいじっているところです。
なんかキテター GTX 680 手元にあるからいろいろ試してみるか。
>>674 ぜひよろしくお願いします。
結局色々試したけどToolkit 4.2ではコンパイルできなかったので、
stackoverflowで質問してきました。
CUDA Toolkit 4.1/4.2: nvcc Crashes with an Access Violation
http://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でのビルドはできたのですが、 GTX 580で試してみたら20%ほど速度低下してしまいましたorz 仕方がないので当面の開発はToolkit 4.0で続けて、 Toolkit 5.0を使った6xxシリーズ向けのビルドは、 おまけとして配布パッケージに添付することにします。
GTX570で10桁検索したら12Mtripcodes/s程度でした
>>678 あ、ありがとうございます。やっぱりそれぐらいですね。
GTX 580でもまだ20M TPSぐらいです。PTXでコードをごりごり
書きなおしてレジスタ数を減らして最適化する予定ですけど、
どうなるかちょっとわかりませんねえ。
>>679 他ツールのCPU検索より高速になることを期待しております
といっても私は12桁が本命ですので現状で満足とかなんとか
>>681 mty_win_x64_20071012を試してみたら、
4.6GHzにOCしたCore i7-3770Kで20.2M TPSでした。
GTX 580とどっこいどっこいといったところです。
570でも同じぐらい速度が出せるようになるといいんですけどねえ。
>>682 もしかして10桁はSHA-1と違って低速なのでしょうか
CUDA化したら高速になるものだと思ってました
>>683 10桁検索は思った以上に遅いですね。またCUDA自体があまりDESの計算に
向いていないというのもあります。関連論文を漁ってみましたけど、
そこまで速度は出ていません。(
>>522 に論文の引用があります。)
まあでも今回のはとりあえずBitslice DESをCUDAで動かしてみただけなので
速度は今後の最適化次第でしょう。
>>684 やはりそうですか。
しかしCPU+GPUで検索すれば良い速度になりそう。
>>685 MERIKEN's BranchのCPU検索はほとんどおまけですけど、
10桁ならmtyと組み合わせるなら多少は助けになるかも知れませんね。
なんにせよもうちょっと頑張りますです。
>>686 いえいえ、少しでも速くしたいのでCPU検索には助けて貰ってますよ。
機能も速度も十分なのですが、欲を言うと正規表現が惜しいというか。
12桁検索で後方一致にすると560M→100M未満になります。
しょぼいので参考にならないかも知れませんがGT640(WinFast WFGT640-1GD3LP)で0.04 Alpha 1をデフォルトのまま5分ほど動かしてみました 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.
なお -x 16 にすると102M〜103Mくらいになりました あと -l 10 の10桁検索は2.8Mくらいでした
>>687 後方一致でも前方一致と同じ速度を出すことはもちろん可能なんですけど、
これ以上複雑にしたくなかったし需要もないだろうと思ったので
放っておいたんですよね。どれぐらいの手間で改善できるのかちょっと
調べてみます。
>>688 いえ、動作報告はいつでも参考になるので助かります。
640もKeplerコアですけど性能はGTX580の1/3弱なので、
Keplerコアだと同等のFermiコアに比べて検索速度は半分強といったところでしょうか。
>>690 レスありがとうございます。
優先事項というほどではないと思いますので、記憶の片隅にでも置いて頂ければ。
ソースを眺めてたらいまさら-dオプションでCUDAデバイスを指定できることに 気づきましたw 使ったことなかったのですっかり忘れてた… 580 SLIの性能を試してみようと2個起動してみたのですが、全く問題なく 動いています。普段使っている正規表現のパターンで1.21G tripcodes/s出ているので、 OCしてパターンが一つだけなら1.6G TPSは固いでしょう。 2枚のグラボを隙間なしで設置しているせいか、下のカードは73℃なのに上のカードは 87℃まで温度が上がっています。OCしてないからこの間みたいに突然ヒートシンクが 膨張して物理的に壊れることはないだろうけど、ちょっと心配です。
>>692 その内に手を付けることになるとおもいます。できたらまたここ報告します。
695 :
名無しさん@お腹いっぱい。 :2012/09/04(火) 06:38:16.88 ID:YD/MKKNo0 BE:510057623-PLT(30002)
>>694 どうもです。動作報告くらいしかできませんが、お待ちしております。
SLIで動くことがわかったので、久しぶりに最高速の記録を出してみました。 【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ほどです。
699 :
名無しさん@お腹いっぱい。 :2012/09/04(火) 22:54:28.33 ID:U9CsveFA0
GUIの実装よろしく
>>697 電気代はアパートの管理会社が払ってるので問題ないんですけど、
自腹だとちょっと迷いますね。
>>698 ぜひ買ってTripperを試してみて下さいw
>>699 GUIは次のバージョンあたりで考えてます。
とりあえず今のバージョンを最適化して安定させるのが最優先です。
10桁のGPU検索でたまに2chで使えないトリップを生成することが判明。 例: ◆TEST/zXiSQ #ハ楳彦ィg銃F (ca 94 80 95 46 a8 67 8f 65 46) したらばでは使えたので、2chとしたらばのトリップの仕様の違いを 調べればすぐにこのバグは潰せるとは思うが、しかしこんなのが 残ってるとはなあ…
>>702 あ、ありがとうございます! そういえばこんな話もありましたね〜
早速手直ししてテストしてるところです。
どうせseedあたりだろうとぼんやり見当はつけてたのですが、
詳しいことはすっかり忘れていました。
どうやら
>>701 のバグは治ったみたいなので
Bitslice DESの最適化に取り掛かりました。
S-Boxをレジスタの使用を最適化しながらPTXの命令で書き直しています。
一年ぶり(
>>545 )の作業ですけど相変わらずめんどくさいです。
2時間かけて5番目のS-Boxの最適化を完了して、テストも問題なく終了。
あと3つ残ってるので約6時間か〜
6番目のS-Boxの変換も終了。 PTXアセンブリへの変換は使用するレジスタ数を減らすために やっているんですが、手作業によるレジスタ割り付けの最適化の副作用で 検索速度もびみょ〜にはやくなっています。 やはりCUDAのコンパイラは相当最適化をサボっている模様。 これ、Bitslice DESのゲートの情報から直接PTXのコードを 機械的に生成してやったら相当速くなるんでしょうねえ。
688でGT640の報告をした者ですが 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ではほとんど変化ないみたいです
OS標準のインボックスドライバだとDirectX関連の機能しか入ってないよ CUDA/OpenGL/OpenCLとかMSが関与してない部分はアウトなはず
>>706-707 ありがとうございます。ドライバの件は盲点でした。README.txtに追加しておきます。
-xは自動的に最適な値を設定するようにしたいんですけどね〜 今後の課題です。
あれ、トリップが出てないや。
>>708 は私です。
さっきようやく7番目のS-Boxの最適化が終わりました。
ようやくあと1個です。はたしてどうなることやら…
しかしグラボを2枚刺しにしておくと、開発しながら それとは別に普段のトリップ検索を裏で続けることができるので すごく便利です。安いのでいいからはやく2枚目をかっておけばよかった…
S-Boxの最適化がようやく終了したのはよかったのですが、 Max Register Countを32に設定すると、相変わらず著しい速度低下が 見られましたorz 仕方がないのでMax Register Countを0にしてプロファイラで調べてみたら、 registers per threadは37でした。手作業での最適化の前はレジスタ数は63で lmemへのregister-spillingは4 bytesだったので、最適化は相当な効果が あったようですが、あと一歩足りなかったようです。レジスタ数を32まで下げられれば Occupancyは上がるはずですが、カーネルの構造を見なおさなければいけないので 悩ましいところです。
712 :
きら ◆Kira.u9zNc :2012/09/08(土) 00:06:52.89 ID:bcVaIwDEP
>>705 元祖CUDA SHA-1 Tripperは使えるんですが、MERIKEN`s BRANCH版が使えません。
スペックが足りないからでしょうか。
Intel CORE i7
nVIDIA GEFORCE 540M
>>712-713 VC++2010ランタイムかもしれませんね。
Win32アプリケーションだから大丈夫だと思ったんだけどなあ。
OSはなんですか? あと起動した時に出るメッセージも教えて
もらえると助かります。コマンドプロンプトから起動すれば
もうちょっと詳しいことがわかるかもしれません。
>>712 あ、書き忘れてたけどスペックは全く問題ないはずです。
もうちょっと手元のテストする環境を増やしたほうがいいのかな…
>>711 の続きですけど、共有メモリがper blockで6144 bytes使えることを
すっかり忘れていました。1ブロックあたりのスレッドの数が128なので、
1スレッドあたり6144/128=48 bytes使えることになります。
単純に計算すればレジスタに割り当てられているローカル変数を12個
共有メモリに押し出せるはずですが…
ちょっと10桁検索で色々試してみたら、GPUのCore Clockを上げても 全く速度が上がらないのにMemory Clockを挙げたら検索が早くなることが判明。 12桁検索と全く違うパターンなので非常に興味深いです。 やっぱメモリの使い方も見なおさないと駄目か…
ソースを見なおしてみたけど、やっぱりローカルメモリを1スレッドあたり 480 bytes使っているのが速度があまり出ない原因になっているみたいです。 ここは1年前にかなり頑張って削った部分で、Bitslice DESの特性上これ以上 減らすのは難しいようです。やはりレジスタの数を減らしてoccupancyを 上げるしかないですねえ。
共有メモリを目一杯使ってレジスタ数を31まで下げて 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
いっそのことblocks per SMとthreads per blockを犠牲にして Blitslice DESで使っている変数を全部共有メモリに押し込むのも ありなのかも… ちょっと試してみよう。
>>720 の方法を試してみたけどやっぱり速度が出ないです。
う〜ん、完全に煮詰まったので10桁検索の最適化はしばらく置いておこう。
気を取り直して複数のGPUへの対応作業を済ませました。 1つのプロセスで複数のGPUをつかって検索できるようになりました。 GPUのルーチンを書いてた頃は複数GPUへの対応は考えていなかったので thread-safeにするのにちょっと手間取りましたが、CPU検索に対応したときに マルチスレッド化していたおかげでかなり楽ができました。
つ茶〜 >722 奮い立ってますか!
>>723 あ、どもども。ありがたくいただきます。まあ予想してたとはいえ1G TPSを普通に
出せるようになるとテンション上がりますよねw
というわけでもう一回最高速の記録を出してみました。
【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。
検索スレッドの割り当ての方法を調整したので
>>696 より多少速度が上がっています。
ただ、効率が良くなったせいかOC耐性はかえって低くなってしまいました。
まあこれで最速のトリップ検索プログラムと呼んでも差し支えないでしょうw 幾つグラボがあっても対応できるようにしておいたので、グラボを積めば積むほど 速くなります。後もう1枚580を追加するか580を1枚590と入れ替えれば 2G TPSも問題なく出せるはずです。
いいんちょ降臨なう
なんかやっぱりまだ正規表現の検索が安定しないな〜 無茶させすぎると検索に引っかからなくなります。 まあ200万パターンなんて普通の使い方ではありえないんだろうけど いまいちすっきりしません。
10桁全数erなんですが12桁全数だとどんな感じですか?
732 :
名無しさん@お腹いっぱい。 :2012/09/09(日) 02:29:40.32 ID:tFESEFpF0 BE:2040228364-PLT(30002)
全数字検索すると半分くらいに速度落ちてた気がする
うーん、全数検索できないですねえ。 確か前に試したときは大丈夫だったんだけどなあ。 こりゃ当分の間は正規表現検索のバグ取りと最適化ですね。
>>731 全数検索できなかったバグは修正できました。
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.
全数検索の速度低下はだいたい30%ぐらいですね。 近いうちに修正したバージョンをあげるので是非試してみて下さい。
正規表現の数が多くなりすぎるとヒットしづらくなるような気がして調べてみたけど
問題の再現はできませんでした。やっぱり
>>617 で指摘されたように
発見確率の計算をどこかで間違っているのかしらん。
8完以下も9完以上も同じように計算してるのでちょっと考えにくいんだけど。
後とりあえず残っている課題は次の通り。 ・後方一致検索の高速化。 ・検索アルゴリズムとブロック数の動的設定。 とりあえず前者をやることにします。
>>736 8完以下は調べてないからわからない(*‘ω‘ *)
なので、より正確に言うなら「ここいらの計算、”少なくとも”9完以上だと間違ってるような気がする(*‘ω‘ *)」かな
いままで後方一致検索は手抜きもいいところだったんだけど、 真面目にやろうとすると検索ルーチンの最深部まで手を入れなきゃいけないので 結構緊張します。とりあえず12桁のCPU検索とGPU検索の作業は終わりました。 思ったより順調だけど、残りはどうなることやら。
>>738 なるほど、そうですか。後で確率計算の部分を見なおしてみます。
ターゲットが短い場合はちゃんと合っているのでなかなか難しいところですが…
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.
のたサイト最近繋がらないけどどっかに移転したの? 一応トリップ総合ページだと思ってたんだが。
後方一致検索の最適化は10桁GPU検索の分まで終了。 今10桁CPU検索のテストをしているところです。 しかしCPU検索の遅いことといったらないです。 全然最適化していないとはいえ、速度がmtyの8分の1というのは酷すぎる。 OpenCLへの移植を考えているので出来ればあまり手を付けたくないんですけど、 気が向いたらamd64への最適化をするかもしれません。
openCLのradeonの方が速いんだっけ?
>>746 mtyのGPU版の10桁検索の速度は今考えると異常ですね。
でもあれはCALで書かれていてOpenGLではなかったはずです。
で、CALはサポートされなくなったのでmtyはHD 7xxxシリーズでは動かないと
聞きました。12桁検索は公開されているプログラムがないのでなんとも
いえませんねえ。
>>747 なるほど
とりあえず年末と言われてるGTX7XXの巻き返しに期待かな
GPGPUの分野ではCUDAがデファクトスタンダードになりつつあるみたいですけど、 NVIDIA以外のデバイスを使おうと思ったらOpenCLで書くしかないですからね。
>>748 780はほんとうに楽しみです。思い切って790を買うかもしれません。
12桁検索は確実に速くなるでしょうね。10桁はメモリ周りが見直されないと
厳しいかなw
ようやく後方一致検索の高速化が終わりました。 もうちょっと手を入れれば前方一致検索と同じ速度を出せますけど、 とりあえずここらへんまでにしておきます。 後方一致検索が行われているときには "Performing a backward-matching search"と表示されます。 ターゲットはすべて$で終わっている必要があるので注意して下さい。 今日か明日に新しい開発版をうpします。 > 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 >>743 ーc−gで死亡
ーgならおk
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.
>>752 結構いろんな人が検索プログラムを作ってますよね。libdesは確か
Bitslice DESじゃなかったのでスピードはあまり出なかった記憶があります。
-gだけで大丈夫なら電源関係かもしれません。システム全体に負荷をかけると
結構電圧が不安定になったりします。
>>754 後方一致の迅速なご対応ありがとうございます。
通常の前方一致検索とほぼ同等の速度が出ました。
>>755 それはなによりです。ターゲットの数が多ければ多いほど効果は大きいでしょうね。
いままでいかにさぼってたか分かってしまいますがw
さて、検索アルゴリズムの動的最適化をどうやるかぼんやり考えていたのですが、 最適化の処理をGPU検索スレッドに丸投げすることにしました。 最初は親スレッドでまとめてやろうかと思っていたのですが、 収拾がつかなくなりそうだったので止めました。 方針は決まったので後はガリガリコードを書くだけです。 まずブロック数の自動設定から片付けることにしよう。
759 :
662 :2012/09/10(月) 14:28:26.73 ID:g7lnNtCs0
>>754 いつもお世話になっています。
CUDA5の6xx版はまだまだパフォーマンスを引き出せない感じですね。
設定を詰めても平均260MT/sあたりしか出ません。
そして従来向けの非6xxバージョンだと、ブロック数を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コア全体に対するブロック数のようですがどうなのでしょうか。
私の認識が間違っていたらすみません。
>>759 うーん、やぱりToolkit 5.0でビルドすると性能が出ないですね。
今はいいけど780あたりが出るまでには治っているといてほしいものです。
たしかにKeplerはコア数が多いので-xの値を大きくしたほうがいいですね。
もうちょっと大きくしてみてもいいかもしれません。
> この表示はSMX単体に対してではなくGPUコア全体に対するブロック数の
> ようですがどうなのでしょうか。
これはうっかり表示を間違えていました。申し訳ない… 早速直しておきました。
いずれにせよこれはかなり興味深い報告です。有難うございました。
761 :
名無しさん@お腹いっぱい。 :2012/09/10(月) 18:00:09.23 ID:g7lnNtCs0
>>760 早速の対応ありがとうございます。
今色々なブロック数を試行している最中ですので結果はもうしばらくお待ちください。
あとCPUとGPUの並列で動作させていて気になったことを一つ。
ご存知かもしれませんが、KeplerからはGPUへの命令の一部をCPUが演算するように制御が変更されています。
(参考:
http://pc.watch.impress.co.jp/docs/column/kaigai/20120322_520640.html そしてこれはGPUが強力になればなるほどCPUの負担も増えるはずです。
(私のような素人の考えですので間違っているかもしれませんがw)
ちなみにGTX680M単体検索時のCPU負荷は12%@2スレッド使用となっていましたので、
これに加えてCPUでも検索をかけるとどこかに無理は来ているはずです。
ですので、現状ではCPU+GPU検索時には論理CPU数-1スレッドで検索していますが、
もしかしたらCore i系CPU+KeplerGPUのシステムでは、2スレッドくらい空けた方が
それほど速度低下もなく全体として安定動作するかもしれないんじゃないかとも思いました。
CPUが検索に使うスレッド数を指定するオプションがあればそこら辺も実験できるのですが、追加は無理でしょうか?
新参のくせにいろいろ要求してしまってすみません。
あ…またageちゃったorz sage保存のためにカキコしときます、すみません。
>>761 わかりました。じゃあそのオプションも追加しておきます。
>>761 補足
>GTX680M単体検索時のCPU負荷は12%@2スレッド使用となっていました
トリッパーへのCPUスレッド割り当てを1スレッドに変更して見てみると、
トリッパーが1スレッド100%使用して100/8≒12%となっていました。
この数字がトリッパー単体がリソース消費しているのか
GPU制御まで含めての数字なのかは自分の勉強不足でわかりません。
>>763 ありがとうございます。
こちらも一番いい設定を見つけ出してみます。
580で7完1タゲで5分間の平均時速を測ったらこんな結果に。
-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氏の
>>411 の方針の延長で-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.
>>767 ちゃんと動いているみたいですね。よかったよかった。
電源については、このプログラムがPCにかなり無茶させているような気もしますけど…
普段運用するときにCPU検索を切っておけば大丈夫だと思います。
眺めてばっかりなのも退屈だから仮のトリップつけつつ休憩。 さっきのはCPUとかドライババージョン書いてなかったですけど CPUはCore i7 3820QM(Ivy、2.7-3.7GHz、4C8T) GPUドライバは306.02β、CUDAドライバは5.0.1を使ってました。 まぁそれだと日頃やってるゲームで不具合出ちゃうんで CUDA5.0はまだまだ未熟なようだし302.71、CUDA4.2.1に戻しました。 ベンチはとりあえず後者で統一してみます。 しかしこのPC買って間もないんですが最近のノートって速くなりましたねぇ。
>>769 CUDA 5.0はRCだから性能は当分このまんまでしょうねえ。
実は10桁検索は15%ほど速くなるんですけど、12桁が遅くなりすぎです。
これ、趣味じゃなくて本職の人達は相当困ると思うんですけど…
680Mは結構速いですよね。自分も本業ではほとんどノートしか使いません。
10桁検索のテストをしてたら何回かグラボが不安定になってリスタートしなければ いけなくなったので、10桁検索の処理のループの回数を大分減らして軽くしました。 目立った速度低下は見られないのでこれでよしとします。 なんか本当にvoodooの様相を呈してきたけどいいのかしらん。
開発再開で10桁にも対応し始めたのですか。 今後が楽しみですが、Keplerはなかなか厳しいですねえ・・・ Kepler2とも呼ばれているらしいGK110の内部がどうなるのか気になりますね。 GTX780は値段が凄いことになりそうですけど・・・ メモリアクセスがネックになるというのは消費電力の面でも避けられると良いですが、やはり難しいのでしょうかね?
これ、10桁と12桁の同時検索はできないのでしょうか。
>>772 Keplerちゃんはわりと頑張っているという印象です。680Mで300M TPS出るんなら
680なら450M TPSぐらいいくんじゃないでしょうか。
>>641 の記事を見たときには
\(^o^)/オワタと思ったものですが…
今まで出てきた情報を見る限りではGK100を使えば検索速度が速くなることは
間違い無いでしょう。値段がどうであれ私は必ず買います!
10桁検索はBitslice DESを使っている限りメモリアクセスで足を引っ張られる
でしょうねえ。変数を全部レジスタと共有メモリに全部押し込められるような
やり方が見つかればいいんですけど…
>>773 うーん、無理やりできなくも無いですけど、今の10桁検索の速度で
需要はあるんでしょうか…
>>775 うーん、このツールの12桁検索と他のツールの10桁検索を併用する方がいいかもしれません。
失礼しましたm(_ _)m
>>774 いや、GTX680だと多分めちゃくちゃ伸びると思います。
GTX680Mって実質GTX670のダウンクロック版ですしね
GTX680はGTX680Mに比べて
CUDAコア:7SMX=1344→8SMX=1536 1.14倍
最大コアクロック:720→1058 1.47倍
最大メモリ帯域幅:115.2→192.2 1.67倍
ちょっとうちの680MをOCして試しに回してみますわw
GT640ユーザーですが開発お疲れ様です 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くらいになりました
OCしてみました。
GTX680M
コア720→835MHz (AfterBurnerの限界)
まだ設定が見えてこないので-x 192のままで検索
GPU単体で5分検索してみた結果
Max:352.3GT/s
Ave:350.5GT/s
この結果からもクロック1.16倍に対し平均速度は1.17倍と順当に上がってるので
>>777 の結果をもとにざっくり試算すると495GT/sあたり行くんじゃないかと。
まぁ単純に倍にはできないかもしれないですが、それでも400台後半は出ると思います。
しかもこれまだ設定詰め切れてない状態なんでもうちょい伸びるかも?
>>779 うちしょぼい環境(取り付けてる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近い数値出そうですね
>>780 なるほど
確かにそれから見ると単純にコア数とクロックに対してリニアに伸びていきそうですね。
OCしたときの伸び方は分かってもSMX数がどこまで効くのかはわかってませんでした。
しかしKeplerでのオプションは順当にコア数通りの192が最適な気がしなくもない…。
確かに256とかにすると最大瞬間風速は出るけど速度のブレが激しいというか。
つーか忍法帖不具合でリセットかよ
無能運営とプログラマめ…
12桁検索の速度はコアクロックとSM(X)の数に正比例するはずなので、 680Mが300M TPSだとする680は 300 * (8/7) * (1058/720) ≒ 503.8M TPS ぐらいになる計算ですね。この場合メモリは全く関係ないはずです。 -x 192で1タゲだと定格の580では680M TPS出るので26%の速度低下ですけど、 ビット演算やシフト演算が致命的に遅いのにこれぐらいで済んでいるのは やっぱりCUDA coreの数が多いからなんでしょうね。
>>782 一晩置いた結果に疑問点があって今まで観察していたのですが
ちょっと発見したことがあります。
-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”を変更したほうが良いのかなと。
ただ、過去ログを読んだ限りではなかなか厳しそうですね…。
>>784 なるほど、currentの数値に関してはそこまで気にしなくてもいいということですね。
あと資料ありがとうございました。
Warpの概念というのも知りませんでしたし、ここまで踏み込んだもの
(と言ってもプログラミングをされる方なら基本のレベルなのかもしれませんが)は
今まで見たことが無かったので、読み進めるだけでも頭がパンクしそうでしたが
CUDAコアはCPUよりもずっと並列動作向けに作られているんだなぁということはわかりました。
本当に抽象的にしか頭に入ってませんが…w
今ちょうど休暇中なのでゆっくり勉強していきます。
そして報告です。今のところこの-x 224が一番いい感じです。 資料を読んだりしながら動かしたので本来より多少数値は下がってるかもしれません。 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.
787 :
674 :2012/09/11(火) 15:36:16.19 ID:bDZse3Pb0
CUDA_SHA-1_Tripper_MERIKENs_Branch_0.04_Alpha_1.exe -x 64 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.
>>785-786 あ、あのリンクはもし興味があれば、というつもりで貼ったので…
グラボのプログラミングはかなり特殊なのです。
224が最適だとすると、ブロック数の自動設定はもうちょっと
細かくしたほうがいいかもしれませんね…
>>787 とうとう680での報告ですね。ありがとうございます。
CUDAデバイスの数が2となっていますけど、これはSLIですか?
それともPhysX用にもう一枚別のカードが入っているんでしょうか。
なんにせよ、大体予想した速度と同じぐらいで安心しました。
やはりハイエンドのカードではそれに見合う数字が出て欲しいですからね。
790 :
674 :2012/09/12(水) 11:06:52.31 ID:UFrBQI8+0
>>789 もう1枚は画面表示用のQuadro 2000で、680をGPGPU専用にしています。
>>788 自分の680Mではブロック数を上げ過ぎると30分平均で見ても少し速度は落ちてました。
といっても2〜3MT/sくらいの差ですけどね。
動く上限自体は320くらいで、そこから32ブロックごとに減らして様子を見てみてました。
そしてその224ってのがKeplerのどれでも最適かというと疑問なんですよね。
1SMX=192コアなのはどれも同じだけど、GPUクロックとかSMX数によっても頭打ちが変わってきたりしないのかなと。
>>790 あ、なるほど。本職の方でしたか。それならばその構成も納得ですね。
もしよろければQuadroでも試してみて下さいw
>>791 詳しく調べて頂いてありがとうございました。
カードによる差は、実行時に速度を測定しつつ自動的にブロック数を調整させることで
対応していく予定です。
さて、
>>720-721 あたりで完全に行き詰っていた10進検索の最適化ですが、
今日突然、
|
\ __ /
_ (m) _ピコーン
|ミ|
/ `´ \
('A`)
ノヽノヽ
くく
と上手い考えが閃いて、大きな進展がありました。
共有メモリに一時変数を全部押し込めるというアイディアは そのままなんですが、次の点を変更してやりました。 (1) 1回のBitslice DESの処理に8個のスレッドを割り当てて、 8つあるS-Boxを同時に処理させる。 (2) 共有メモリのバンクコンフリクトを避けるために、 ダミーの変数wを構造体に追加する。 (1)は並列性を高めるといういかにもGPGPU的なやり方なんですが、 (2)は行き当たりばったりもいいところでvoodoo(黒魔術)の感さえありますw
で、結果的には10進検索を2倍以上高速化させることができました。
> 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と比べると相当しょぼいのですが、
それでも
>>461 などと言われてた頃に比べると相当の進歩ですw
昨日の資料見てるとメインメモリ速度も効くような気がしたので 早速ノート用のOCメモリ(DDR3-1866 CL=10 1.5V)注文しちゃいました。 まぁ大きく上がるとは思えないけど最後の手段で…。
実際他の論文を読む限りこれは「CUDAでのDES実装の世界最先端」(
>>461 )では
ないかと思われますw まだプロファイラにはかけてないので、
今後はプロファイリングの結果を見ながら、共有メモリのバンクコンフリクトを
減らしたり、Occupancyを増やしたり、レジスタの割付を変えてみたりして
最適化を進めたいと思います。最初の目標だった580単体での100M TPSは
難しいだろうけど、それに近い数字が出るといいなあ。
>>796 うーん、どうでしょうねえ。CPU検索は確実に早くなると思いますけど…
しかし私が言うのも何ですけど、なかなかはまってますね。
気づいたらグラボ満載のPCを組み立てているかもしれませんねw
まあ私もAmazonで590の中古の値段をチェックしてたりするので 人のことは全く言えないんですけどね… 780/790まで我慢我慢…
>>798 昔は自作PC組んでて8800GTX→HD5870+QX9650とか使ってたんですが
今はもう省電力でいいやーって感じでノートにしました。
あとこのノートPC、実は既にグラボを載せ替えてるんですよ。
元々GTX675M積んでたけど680Mのベンチ見て
ebayでカナダから680MのMXMボードを取り寄せました。
多分今のところ日本でGTX680M積んでる15インチノート持ってるのは俺しかいないw
>>800 最近のノートはそんなことができるんですか。驚きました。
どうりで性能が高いわけです。
プロファイリングの結果はこんなかんじです。 非常にいい感じで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
ブロック数の話は
>>463 のあたりでも出てるよね。
マウスとかエイリアンとかにあるよなぁ、と一瞬思ったけど 15 インチか。w
廃熱大丈夫なのか?それ。
>>801 しかもGTX675M比で3D性能は1.5倍だけど温度はかなり下がりましたしね。
定格でトリッパーを連続で回してもジャスト60度ってとこです。ゲーム時はもうちょい上がりますが。
全体の消費電力だってディスプレイ込みで150Wくらい。
それでいて上の構成の当時最高スペックの元自作機より絶対的な性能も高いし
すごい時代になったもんだなと。
>>803 自分のはClevoのP150EMなんですけど海外じゃ680M搭載機は売られてるんですよ。
日本でも兄貴分の17インチには680Mの設定があるけど
15インチのやつで設定してるところはない。
冷却システムは17インチも15インチも全く同じなんですけどね。
つーか冷却の面だと標準の675Mの方がよっぽど厳しかったですわw
某MMOやってるとGPU90度超えとかいう恐ろしいことになってましたから。
今は10度以上下がって70度台、ノートとしては十分合格点です。
>>804 そりゃすごい。うちのでおもいっきり動かすと2枚のグラボが
それぞれ70度と80度いきますからね。なんせ580は一枚244Wですからねえ。
ワッパが全然違います。
>>803 お、お久しぶりです!
よく見たら昨日の書き込み、「10桁検索」が全部「10進検索」になってるよ… よほど興奮してたんだなw それはさておき、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同時でブン回せますw
うーん、もっと調べてみたらどうやらオンダイの48Kのメモリのうち、 32Kがshared memoryに割り当てられていて、 残りがL1 cacheとして使われているから無理やり共有メモリを32K以上 使おうとすると挙動がとたんにおかしくなる、ということらしいです。 L1キャッシュを無効にするためにオプションで -Xptxas -dlcm-cg と指定してみたけど 上手くいってない模様。どうしたものか。
>>809 全然違いますねえ。自分も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.
http://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/Fermi_Tuning_Guide.pdf
>>811 そこが難しいところですね。
自分はもう改造しまくって保障なんかシラネな世界なんでどうでもいいけどw
Fermiはすさまじく爆熱だから効果もかなりあるとは思うんですが…。
どうやらregister spillingが発生して、その結果L1キャッシュを無効にできない 模様。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]
>>813 実はちょっとまえに580を思いっきりOCしてトリップ検索してたら
バキバキとすごい音がしてヒートシンクが膨張してカードが壊れちゃった
ことがあったんです。保証ですぐ交換してもらえたので助かりました。
>>815 うへ、ヒートシンクが膨張って何度まで上がってたんだろう…
そういうのがあるとやっぱり保証は欲しいですね。
自分も同じマシンでGTX675MとGTX680M比べてるわけですけど、
あの熱は本当に怖かった。
まぁCUDAの事を考えると、下手にリキプロとかぶち込むよりも
GeForce700系待ちの方がいいかもしれませんね。
>>816 水冷も試してみようかなと思ったんですけど、
保証とメンテのこと考えるとね…
当分の間は580 SLIの掃除機のような轟音とストーブの
ような爆熱に付き合うことになりそうです。
register spillingはなくしたのに未だにちゃんと動いてくれません。 Fermiちゃん、ツンデレすぎるだろう…
結局わからなかったのでまたstack overflowに行って質問してきました。
CUDA: Is It Possible to Use All of 48KB of On-Die Memory As Shared Memory?
http://stackoverflow.com/questions/12402191 共有メモリ云々は私の勘違いで、原因はレジスタの数が足りなかった
だけでした。原因がわかってすっきりしたけど、10桁検索のこれ以上の
性能向上は難しいかもしれないなあ。
全然期待してなかったけど、レジスタの数を絞ってスレッドを768個にしたら、 580 SLI OCで100M TPS出ました。もう何でもありですね…
というわけでもうちょっとスレッド数をいじって速度を調べてみました。
これを見る限りスレッド数は768で決定ですね。
これで
>>793-796 にさらに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
更にもうちょっといじってみたところ、スレッド数を256にしても ほぼ同じ速度が出るようになりました。結局レジスタの数が 多すぎて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の組み合わせも ためしてみたいなあ。
GeForceの306.23ドライバきてた GTX680Mで使える初めてのWHQL統一ドライバだ…
>>827 リンク先はIntelが裏で動いてNVIDIAとAMDの足を引っ張っているという陰謀論ですけど、
元の記事を見ると話は随分違います。
> ではそもそもなぜPCI-SIGは300Wを超える仕様を拒否したか、であるがNeshati氏に
> よれば「300Wを超えるようなカードは、シャーシのメカニカル的な強度に無理が
> 生じてくる。あるいはこうしたハイパワーのカードの場合、リテンションの強度や
> カードそのものの重量、排熱がシステムに与えるストレスなどを考慮しなければ
> ならない。冷却やエアフローが、システム内部への排熱がシステムボードのほかの
> コンポーネントに影響を与えない様にする必要がある。例えばCPUとかなら、Intelに
> してもAMDにしても内部にThermal Sensorを搭載し、温度が上がったら発熱を
> 下げるような工夫がされている。ところがGPUカードはこうした具合になっていない。
> これはシステム全体のパフォーマンスをむしろ下げる方向に作用する。これは
> ユーザーにとって良いことではない。GPUベンダーは、もう少しThermal Budgetや
> Cooling Budgetを考えるべきだろう。勿論NVIDIAの様なGPUベンダーの視点から
> すれば、こうした問題は解決可能なのだろう。しかしPCI-SIGの視点からすると、
> メンバー企業がスペックを超えた仕様を独自の努力で可能にするのは自由だが、
> それを仕様化するのは好ましいとは言えない」という返事であった。
>>828 ためしてみたい気もするけど、今の305.60がちゃんと動いているので
悩むところです。昔と違ってドライバも随分安定しましたからね〜
>>827 Xeon Phiはx86系のコアを50個以上搭載してるそうですよ。
また新たな変態アーキテクチャが誕生するわけですね。実に楽しみですw
OpenCLにも対応するそうです。思い切ってTripperをOpenCLに移植しようかな。
>>831 自分も入れてみた結果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常用行けそうかも。
>>830 今ですら2スロット占有は当然、3スロット占有も珍しくないですし、冷却の問題は大きいですね。
Fermiのシュリンク版・・・欲しかったですw
>>833 それなら多分常用でも大丈夫でしょうけど、くれぐれも気をつけてくださいね〜
それにしてもCPU検索も馬鹿にできないですね。
頑張ってアセンブラで書き直してやれば12桁のCPU検索の速度は倍ぐらいに
なるはずなので、気が向いたらやるかもしれません。
>>834 Fermiちゃん、いろんな意味で熱すぎですw
>>835 まぁ大丈夫です。
やる時には温度監視しながらやりますし
+135MHz以上は確実に回りそうなのにAfterBurnerの制限で回せませんから。
温度とか見ててもKeplerってかなりマージン取って作ってあるなーと思いますよ。
あと今になって気づいたけど
>>779 の周波数は間違いでした。
限界835MHzじゃなくてベース+135MHzの854.5MHzでした。すみません。
ブロック数と検索アルゴリズムの自動設定をどうやるか色々考えてたんですが、 検索アルゴリズムのほうはかなり手間取りそうな感じです。 10桁・12桁 前方一致・後方一致・位置指定なし 線形探索・二分探索 ビットマップの使用・不使用 と、思いついただけでも2x3x2x2=24個のカーネルを用意しないといけません。 マクロを多用してかなり手間を省いてはいるんですが、数が多すぎです。 まあでも性能や将来の拡張性のことを考えるとここで妥協するわけにはいきません。
>>837 まああれだけゲームに必要ない機能を削ったらかなり余裕があるでしょうねえ。
設計の割り切り具合が凄いです。
トリップ、ひとまずこれに固定しときます
>>840 了解しました。Tripperが早速役に立っているようでなによりですw
これからもよろしくお願いします。
今日は数時間かけてコードを整理しました。 Horo氏のコードはシングルスレッド・CPU検索なし・複数GPU対応なしだったので、 その時の名残りでグルーバル変数が多用されていたのですが、 自動設定の準備としてブロック数の決定などの処理をメインのスレッドから 検索スレッドに移しました。1年前の多スレッド化はかなりの突貫工事だったのですが、 これで安心して自動設定の実装に取り掛かれます。
ブロック数の自動設定の実装の途中ですが、ブロック数を動的に増やしてやると 速度が激減するという謎の現象が発生。どういうこっちゃ…
あ、出力用の配列のサイズも一緒に変えなきゃ駄目なのか。な〜んだ。
しかし予想以上のめんどくささです。ようやく各フェーズの平均速度が出たので あと葉挿し的なブロック数を設定してやるだけです。
スレとは全く関係ないことで申し訳ないんですが MERIKENさんの英語力をお借りしたくて質問させて下さい。 Press power button override 4 seconds, and then re-plugin AC adaptor. これ、電源ボタンを4秒押し続けた後にACアダプタをつなげ、ってことでいいんでしょうか? BIOSアップデートかけたら成功表示出たのに起動できなくなった…orz
>>846 それで合ってますよ。しかし災難ですね。うまく直るといいんですが…
>>847 ありがとうございます。
このご時世にブータブルUSB作ってDOSで更新しろとか正直言って難易度高いですわ
680Mへの対応が不十分でその更新とかって話だったのに
>>848 USBからDOSを起動なんて話、初めて聞きました。
DOS使ってたのなんて中学生の頃じゃなかったかしらん。
何もかもが懐かしい…
一応12桁検索のブロック数の自動設定の実装は終わりました。 ブロック数をだんだん増やしてやって、速度の増加が頭打ちになったら そこで測定を終了するというごく簡単な仕組みですが、それなりに 動作しているようです。あまりブロック数を増やしすぎても タイムアウトが発生しやすくなるだけなので、伸びが鈍化したら 適当なところで切り上げています。
10桁検索のブロック数の自動設定の実装も終了。 12桁のをコピペして1発で完動でした。 あとはキービットマップと線形探索・二分探索か…
アルゴリズムの最適化の状態遷移の部分だけ書き終えました。後はCUDAカーネルを 24個用意してそれぞれをテストするだけです。幾つかはこれまで使ってきたものを 流用できるし、マクロを多用しているのでそれほど手間にはならないはずですが、 どうなることやら…
とりあえず12桁前方一致検索の分だけ全部作っていろいろと調べてみたところ、 衝撃の事実が発覚しました。結局のところ、少なくとも580では (1) パターンが5個以上の時は二分探索のほうが線形探索よりも速い。 (2) パターンが4個以上の時はビットマップを使用したほうが速い。 ということで、ほとんどの場合二分検索とビットマップの組み合わせのほうが 速いということが判明し、以前適当に決めてたしきい値はかなりずれていた ことがわかりました。というわけで検索アルゴリズムの自動設定は ほとんど効果が期待できないということになってしまいましたorz まあアルゴリズムの動的な最適化のおかげで検索ルーチンがしゃれにならない ぐらい複雑になってたので、かえって良かったのかもしれません。 この際なので思い切って要らない部分を削ってしまうことにします。
超期待してます。
とりあえず
>>853 の結果を踏まえて12桁検索のルーチンをかなり整理しました。
ソースの可視性も良くなって、結果的には非常によかったと思います。
問題なのは関数がマクロ化されていない10桁検索のほうなんですが、
仕方ないのでせっせと作業を続けます。
>>847 ご心配をおかけしました。
BIOSをアップデートしたらオーバークロックメモリと相性が出ちゃってました。
PC3-1866から1600@CL=9に戻したらすんなり起動…。
俺の週末を返せw
ってことで検索協力復活できる模様です。
>>857 それはなによりです。突然立ち上がらなくなるとびっくりしますよね。
そろそろ新しい開発版をうpする予定なので、またテストをしていただけると
有難いです。
CUDAカーネルの整理はほぼ終わりました。探索アルゴリズムの見直しの結果、
10桁と12桁の両方とも多ターゲットの検索の効率が大幅に向上しました。
特に10桁トリップ検索はFermiだとようやく使えないこともない速度を出せるよう
になりました。ただ、10桁検索ではKeplerの非常に苦手な論理演算(
>>641 )を
これでもかというぐらい使っているので、6xxシリーズではほとんど速度を
期待できません。残念ですが、こればっかりはどうにもなりませんね〜
CC2.0未満のカードでどれぐらい性能が出るのかも気になるところです。
テスト用にGTX 260とGT 640を買っちゃおうかな…
ようやくテストも完了だと思ってたら、
>>701 のバグが治っていない
事が判明。したらばでは普通に通るので、症状も全く同じ。やれやれ。
ちなみに問題のトリップはこれ。 ◆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があることぐらいしか 見当たりません。
>>861 > 共通点はShift-JISの第二バイトに0x80があることぐらいしか
> 見当たりません。
それが問題でしょ(*‘ω‘ *)
>>862 やっぱこれなんですかね〜
とりあえず第二バイトに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桁トリップ生成に 関係ないからでしょう。これでようやくすっきりしました。
ちなみに上のトリップはすべてしたらばで使えました。
どうも
>>863 のページで解説されている以外にもしたらばと2chの
トリップ生成の方法に違いがあるみたいです。
今度こそ
>>701 のバグも直ったはずです。あー疲れた。
とりあえず一休みしてから、今日か明日中に0.04 Beta 1をうpします。
>>702 で貼っといたのに全然読んでなくてワロタ。w
>>868 あーなるほど、これですか。見落としてました。とんでもない糞仕様ですねえ。
っていうか知ってるんなら教えて下さいよw
> bbs.cgi 稼働サーバOS(FreeBSD)のCRYPT(3)には、他OSと互換性がなく対策も
> 困難である仕様が存在します。FreeBSDではキーバイト列に 0x80 が含まれて
> いる場合にそれをキー文字列の終端(0x00)と見なし、以降のバイト列は
> 0x00 であるかのごとく処理してしまいます。一部のShift_JIS全角文字が
> この仕様に抵触します。
http://sourceforge.jp/projects/naniya/wiki/2chtrip
HA-1_Tripper_MERIKENs_Branch.exe -c -g 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.
>>871 あ、早速有り難うございます! 自動設定は動いてますか?
"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.
>>873 そうそう、それなんですけど、しばらく(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
>>876 そうそうそれです。ありがとうございます。しかし160とはかなり高い数字が
出ていますね。自動設定はかなり保守的にしたつもりだったんですが…
Compute Capabilityが2.1だと2.0だとまたちょっと違うのかしらん。
というわけで10桁トリップ検索への対応の作業も一段落したので、 今後の予定について考えてみました。とりあえず今思いつくのは これぐらいです。 ・GUIの実装。 ・CPU検索の高速化。 ・OpenGLへの移植とRadeonへの対応。 どれもかなりの作業量なのでどこから手を付けていいか 迷うところです。
GUIに期待
このなかで一番楽そうなのはCPU検索の高速化です。 SSE用の超高速なDESとSHA-1の実装がネットに転がっているので、 それをひっつけてやるだけでかなり改善されるはずです。 問題なのはこれらの実装がほとんどGNU as用だということですが、 mingwを使えばなんとかなるんじゃないかと考えています。
>>879 やっぱりGUIですかね〜 WindowsのGUIプログラミングは
Visual Basic 1.0(w 以来なんですけど、C#の入門本も
買ってきたしなんとかなるでしょう!
どんな機能があるといいか教えていただけると助かります。
Radeonへの対応は実は一番楽しみなんですが、 作業量がかなり多くなりそうなので最後までとっておくことにします。 特にアーキテクチャの違いで10桁検索がどれぐらい速くなるか 非常に気になるところです。 というわけで、次のバージョンでシンプルなGUIの実装を目指しつつ、 他の作業も少しづつ進めていくことにします。
Radeonへの対応ってのはOpenCL使うということ?
>>883 あ、もちろんCUDAの実装はそのままです。
>>878 GPU検索の高速化もっとやったら(*‘ω‘ *)?
あと、後方一致検索の高速化の反映忘れてね(*‘ω‘ *)?
ユーザが色々設定いじったりするのが増えない限りGUIじゃなくてもいいんじゃね もしくは、GUIとCLI別にして、フロントエンドみたいなの作るとか。
>>886 GPU検索の最適化の作業は、何かまた思いついたら再開しますけど、
それまではお休みです。今まで考えてたことはもうだいたいやってしまったもので…
あと後方一致検索は高速化されているはずですが…
具体的にBeta 1よりAlpha 2のほうが速い後方一致のパターン/ターゲットはありますか?
後方一致検索のテストをしていたらバグを見つけてしまったorz やっぱり検索ルーチンの奥に手を入れると色々思いつかない 不具合が出てきますね。
>>887 あ、書き忘れてたけどGUIはもともとフロントエンドとして作るつもりです。
やっぱりCUI版の需要もありますし、なによりも作るのが楽ですw
一応バグは直りました。普通の使い方ではでないはずですけど、何にせよ
見つかって良かったです。
>>886 あとバクを修正したバージョンで簡単なテストをしてみたところこんな感じに
なりました。
"^/[:digit:][:digit:]/[:digit:][:digit:]/" -> 656M TPS
"/[:digit:][:digit:]/[:digit:][:digit:]/$" -> 653M TPS
これを見る限りでは後方一致検索は前方一致検索と同じぐらいの速度が出ている
ように見えるのですが…
しかし、もうそろそろテストも自動化したほうがいいのかもしれないなあ。 検索ルーチンをいじるたびにバグが紛れ込むんじゃないかとひやひやします。
あれから色々調べてみたんですが、どうもBeta 1にはヒット率が低くなる バグがあるみたいです。もうちょっと原因を探ってみます。
前方一致のターゲットと後方一致のターゲットを同時に検索すると 低速になってしまうのがやや不便ですね
どうやらヒット率が落ちるバグはCUDAカーネルを書き換えた時に 紛れ込んだみたいです。二日前のコードにロールバックしたら 消えました。ブロック数の自動設定はうまく動いているみたいですが、 コードの整理はやり直しかorz
>>894 すべてのターゲットで"^"か"$"のいずれかが使われているケースなら
最適化できないことも無いですが、コードがさらに複雑になってしまうので
バランスを取るのが難しいところです。バグ取りが終わったらちょっと
考えてみます。
でもそういうケースは実際のところ結構有りそうですね。現在はバグ取りに 集中しているのでこのバージョンには間に合いませんが、次のバージョンで そのアイディアを取り入れさせて頂きます。 それはそうと、ヒット率が落ちるバグはどうやら検索ルーチン以外のところに 紛れ込んでいたらしく、どうやら検索ルーチンの整理のやり直しは避けられそうです。 よかったよかった。
もっとよく調べたら、ヒット率が落ちるバグはついさっき紛れ込んだもので、 Beta 1は大丈夫みたいです。あ〜、びっくりした。でもいい機会だからテストの やり方をもうちょっと考えよっと。
git で bisect か。 胸熱な展開だな。w
>>899 いえ、WindowsのExplorerでコピペですw ソースコードの管理ももうちょっと
しっかりしなきゃなあ。
というわけで後1週間ぐらい様子を見て、特に大きな問題がなければ バージョン0.04の安定版を公開することにします。 あとバージョン0.05でGUIに対応するために、Visual Studioのプロジェクトを 新しく作り直しました。SHA-1ベースの12桁トリップだけでなくDES cryptベースの 10桁トリップにも一応対応したし、CUDAだけでなくOpenGLへの移植も考えている ので、新スレへの移行の段階でプログラムの名前を新しいものに変える予定です。
902 :
きら ◆Kira.u9zNc :2012/09/18(火) 16:56:58.52 ID:g5RalNWRP
>>712 です
ありがとうございます。
試してみます。(今更)
>>901 個人的にはGUIは必要を感じないけど、どんなGUIになるかは楽しみ(*‘ω‘ *)
自分はbatファイル作ってやってるなぁ
batファイルうp "git bisect -h"
>>905 え、そんなうpするまでもない低レベルなことしかしてないよ。
------------------------------------------------
CUDA_SHA-1_Tripper_MERIKENs_Branch.exe -x 224
------------------------------------------------
たとえばこんな風にテキストファイル保存して
拡張子をbatに書き換えてこいつを同じフォルダに入れて起動するだけ。
試したい設定の数だけ作って保存しとけばいいし楽。
907 :
616 :2012/09/18(火) 20:46:39.19 ID:aj94xEuT0
開発お疲れ様です。 うちのQuadro FX 3800でもBeta1は無事動作しました。最適数検索は1分位で終了し、-x 16でした。速度は・・・それなりですが。 今後の希望として、計算途中結果の保存機能を実装して頂けると助かります。 どうしてもPCをシャットダウンする必要が有り、その度に再実行だとなかなかトリップが見つかりません。
GT640ユーザーですが新バージョンどうもです 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、みたいな挙動になってるみたいです
>>903 とりあえずGUI化してまっさきに付けたい機能は検索の一時停止です。
ちょっと作業する度に検索を停止するのはめんどくさいので…
>>907 報告ありがとうございます。検索速度も教えていただけると非常に助かります。
トリップ検索は数分の一秒ごとに乱数で計算を全てやり直しているので、
再実行しても効率は全く変わりません。ひたすら待ちましょう。
>>908 詳しく報告していただいて大変参考になりました。
自動設定はちゃんと動いているみたいですね。
10桁検索は…まあ頑張っているほうでしょうw
>>910 名前はMERIKEN Tripperでもいいんじゃないですか(適当)
メリーケーンon my mind♪
メリーケーン♪
あれから色々いじってウィンドウのサイズが可変になりました。
いやー、Visual Studioは便利ですねえ。「検索設定」のタブのデザインは
出来上がったので、あとは「検索スレッド」のタブを仕上げたら
本格的にC#のプログラミングを始めます。
>>911 "tripper"という単語は英語の意味がちょっとあれなのでやめておきました。
検索する→高速なのでいいのががんがんヒットする→のうじるだだもれ トリッパーでおk。www
torippa-!
917 :
名無しさん@お腹いっぱい。 :2012/09/19(水) 12:17:54.24 ID:YxVeUwKT0
頭にス付けるといいと思う
ストリッパー!
919 :
名無しさん@お腹いっぱい。 :2012/09/19(水) 14:12:25.19 ID:KaiQthBt0
うーむどのverでもCould not create a new key containerが出るんだが何なんだろう・・・
>>919 それはおかしいですね。OSのバージョンは何ですか?
Win7x64でGTX480 cuda_sha1tripperは各ver動いたんだけどなぁ
>>921 ちょっとテストバージョンを用意するので待って下さい。
thx, it works now :)
>>924 awesome! thank *you* for the bug report!
プロセス間通信についてちょっと調べたんですけど、 標準出力のリダイレクトとシグナルを使ってやればGUI化は わりと簡単にできそうな感じです。案ずるより産むが易しというやつですね。
927 :
616 :2012/09/19(水) 22:17:40.60 ID:HKqLB+Uf0
>>909 乱数でしたか。Orz
10分間の検索速度は以下の通りです。
QuadroFX3800
Xeon
[email protected] 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
>>927 ありがとうございます。CPUが凄いことになっていますね。
6コア12スレッドのようですが、素晴らしい数字です。
GUIのほうですが、6行コードを書いたらCUI版の呼び出しに成功しました。 C#簡単すぎワロタw とりあえず検索パターンの一覧を一時ファイルに書きだして CUI版に渡すようにします。あとはオプションの設定かな。
>>915 いや、本業で薬中・アル中の患者さんを診ることが多いので洒落にならないんですよ…
じゃあ新しい名前はTrip Doctorで決まりですね
>>931 せっかく考えていただいた名前ですけど、もう決めてしまったもので…
あと自分にとってプログラミングは息抜きなので、なるべく本業のことは思い出したく
ないんです。
さて、一応GUIフロントエンドからテンポラリファイルを使って 検索プロセスにターゲットを渡すことに成功しました。 しかしC#はめちゃくちゃ楽ですね。昔Cでせっせとウィンドウイベントの処理してた ころが嘘のようです。あと残っている作業は、 ・検索プロセスのオプションの指定 ・CPUとGPUの情報の取得 ・検索結果のリダイレクト ・検索プロセスのシグナルの処理 ぐらいかな。難しいことはなにもないので次スレを立てる前までに形にしておきたい ところですが、どうなるかな…
C#簡単だよね GTX480で520M tc/s〜出てるけど発熱酷過ぎワロス これは冬になったら暖房がてら稼働するか
550M tc/s〜 だった大して変わらんか
期待してます。 MERIKEN's Tripcode Finder 0,05 opが沢山できますように。 とりっぷキーが カタカナ ひらがな 漢字 数字 記号 英大文字 英小文字 顔文字 絵文字 ナドナドお願いします。
おつかれさまー
>>934-935 結構出てますね〜 580が2枚だと排熱で死にそうです…
>>936 いつもありがとうございます。キーの種類はある程度選べるといいですね。
ただあまり細かくするとトリップが見つからなくなってしまうので
バランスが必要ですが…
「検索設定」タブと「詳細設定」タブの処理の実装はほぼ完了しました。 GUIから正規表現を含むパターンの設定をしたり、オプションを指定したり 出来るようになりました。あとは肝心のプロセス間通信の実装か…
CPUとGPUの情報の取得も出来るようになりました。 CUI版を最初に1回走らせて、CUDAデバイスの一覧を標準出力に出させてから、 C#のほうでそれを処理しています。これでGUI版からもGPUが選べるようになりました。 これでリダイレクトのやり方も分かったからあともうちょっとです。
>>937 お疲れ様。
===========
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)
安定版完成おめでとうございます
>>908 と同じ環境で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と誤差の範囲?です
心の中での応援としょぼい環境での人柱くらいしかできなくてすみませんが
新バージョンの開発もがんばってください
通常のプロセス間通信の実装はほぼ終わりました。残っているのはこれぐらいです。 明日までに終わらせたいけどどうかなあ ・ファイルからの読み込みとファイルへの保存。 ・エラー処理。 ・一時停止の処理。 あ、そうそう、OpenGLへの移植の準備をしようと思って以前組み立てたPCに 以前買ったHD 5770を入れてAMDのSDKをインストールしようとしたんですけど、 肝心のSDKがXPに対応してませんでした。結局Windows 7をもう一つ買うことに なってしまいました。とほほほほ…
OpenGLじゃなくてOpenCLでした。中途半端だの何だの言われてる規格みたいですけど、 実際のところどうなんでしょう…
複数PCにWindowsのライセンス用意するんだったら、場合によっては Technetの方が安くすんだりしないですか?
ATI Stream(Brook+)ならXPでもGPGPUがいけるしHD2000以降でも動いたような(HD3800以降でないと倍精度非対応だけど)
つかRADEONは最上位じゃないとネイティブで倍精度に対応してなかったりするから注意ね 上のHD5770とかはハードウェアでの対応は単精度のみだったりする
前から欲しかった検索の一時停止の機能ですけど、Windows自体にSIGSTOPと SIGCONTに相当する命令がないことが判明し、実装がとんでもなく面倒になりそう だったので、今回は見送ることにしました。まあGUI化によって検索の実行と再開が かなりお手軽に出来るようになったので、一時停止の機能自体それほど必要なくなった、 というのもあります。 というわけで残りの作業はファイルの入出力とエラー処理の実装だけです。 他にも実装したい機能は色々あるのですが、とりあえず次スレまでに次の開発版を 間に合わせることを最優先することにします。
>>951 > 実装がとんでもなく面倒になりそう
(*‘ω‘ *)?
>>952 あ、これはCUI版に新しくWin32のメッセージ処理のルーチンを追加したくなかった
だけです。シグナルが使えればかなりお手軽にできたんですけどね〜
>>951 つ「SuspendThread」
待て屋リミッターはこれとかを使って実現してる。w
>>954 検索スレッドで時間の経過を測定してるので、有無をいわさずスレッドを止めると
支障が出てしまうのです…
>>955 WindowsではPOSIXシグナルの一部は使えないんですよ。
>>957 ありがとうございます。一時停止の機能を実装するときに参考にさせていただきます。
さて、検索プロセスのエラーをようやくGUIのほうで処理できるように なりました。検索プロセスの側でstderrにエラーコードと詳細情報を 流させるようにして、それをリダイレクトしてGUI側で拾うようにしています。 さすがにエラー処理をしている部分にいちいちエラーコードを追加する 作業にはうんざりさせられましたが、一番面倒くさそうなところだったので、 終わって一安心といったところです。あとはGUI内部のエラー処理と ファイルの入出力ですが、これらは割と単純なのでなんとかなるでしょう。
パターンの読み込みの処理の実装を完了。ついでにパターンに使えない文字を 入力の段階で弾くようにしました。やることはわかってるのでひたすらコードを 書いていくだけなんですけど、C#は初めてなので思ったより時間がかかりました。 まあでもあともうちょっとです。なんとか次スレまでには間に合うかな。
不具合報告です。 ^\.*ABC\.*$ ^ABC\.\. このような組み合わせを記述した場合、後者が一切ヒットしなくなります。
>>962-963 動作報告ありがとうございます。
VCの再頒布可能パッケージの話は以前にも出てましたね。説明を追加して
おきます。
>>963 の不具合はこちらでは再現できませんでした。
GUI版とCUI版、どちらをお使いですか? CUI版ではpatterns.txtの
最後の行にパターンを記述することはできないので注意して下さい。
作者様 要望があります。 ものすごいスピードで検索してなおかつGUIもつけてくれて すごいと思います。 GPUを利用している性質上、検索中はCPUはアイドルでも マウスがカクカクになるほどGPUを使っているようです。 トリップ検索の優先度の設定とかできないでしょうか? タスクマネージャでプロセスの優先度を下げてもあまり変化は ないようです。
>>964 GUI版とCUI版、両方で動作確認しております。
ターゲットが少ない場合にはヒットしていますが、合計500行ほど記述している場合にヒットしない現象が発生しています。
>>965 -x 8で、普段は動かしてます。
README読んだ?
>>967 すみません、そのオプション知らなかったです。
確認してみます。
>>965 >>968 GUI版なら「詳細設定 -> 1SMあたりのブロック数」でも設定できますよ。
グラボを2枚差して一枚を画面表示に、もう一枚をトリップ検索に使うという
手もあります。
>>966 了解しました。お手数ですが、問題の発生するpatterns.txtを
こちらにメールで送っていただくことはできますか?
[email protected] ぜひ直したいので、よろしくお願いします。
>>969 ありがとうございます。
用事のため明日になりますが、必ずメールします。
DLさせて頂きました。ありがとうございます&お疲れ様です。
化けるのかな?
◆ABC../Sp93vy #cBsョソVBKr汢ォ (63 42 73 AE BF 56 42 4B 72 9F 89 AB)
ikuraは、おkでanagoがだめなだけ?
それは不思議ですね…
ぉおおおおおおおおオオオオオオオオオオオオオオオオ デケタ
^\.*ABC\.*$ ^ABC\.\. 下しか出ませんけど。 あるいみれあですか? ◆ABC..K.KEk #4エy資Dラ/犖 (34 B4 79 8E 91 44 D7 2F E0 B6) (.)(.)(.)(.)、速度表示がすごく落ちますね
>>980 そんな感じでした。 半角なんてキライダ
?もつかえたらなって・・
>>981 "?"って「前の文字が1文字あるかないか」でしたっけ? あとで入れておきます。
>>972 ありがとうございます。ぜひGUI版の感想を聞かせてください。
2chの使われないメール欄ってなんのためにあるんだろうか
>>982 おねがいします。
使ってみたい
?*
?+
??
GUIいい感じですね 10桁CPU検索の最適化と高速化に期待
Win7x64 295.73で8800GTX+GT520のDual環境ですが MERIKENsTripcodeFinder_0.05_Alpha_1のMERIKENsTripcodeFinder.exeだと 単体では8800GTX、GT520共にに動くのですが 使用するGPU:をすべて使用にしてしまうと落ちてしまうのです やはりCompute Capabilityのサポートに違いがあるGPUの 同時使用はマズイという事なんでしょうかね
あと10桁検索だと8800GTXはエラーで落ちてしまうみたいです
>>987-988 Compute Capabilityが違うこと自体は問題ないはずです。
エラーメッセージが出ているなら、その内容と(もしあれば)エラーコードを
お願いします。あと、「詳細設定 -> 1SM当たりのブロック数」を1にして
エラーが起きるかどうか試してみて下さい。
>>986 それはよかった。頑張った甲斐がありましたw
10桁検索はかなり頑張って高速化したのでこれ以上伸びるかどうかは
微妙なところですね〜
エラーコードは出ずに落ちるので分かりませんでした ブロック数は指定しても状況は変わらないみたいです あとCUI版はデフォルトだと落ちずにデバイスが二つ 認識されている状況でもGT520の片方のみ動いてしまい 直接[-d 0]で8800GTXを指定しない限りは動かないようです 10桁の計算は8800GTXの場合は0.00M tripcodes/sと そもそも動いてない模様です
>>991 それはかなり謎な挙動ですね。8800GTXのCCが1.0、GT520が2.1ですか…
CCが違うカードが混在した環境でテストしたことがないので
ちょっとよくわかりませんが、おそらくCCの違いが影響しているんでしょうねえ。
とりあえず注意書きを追加して、いずれテスト用に別のカードを買って
試してみたいと思います。貴重な報告、ありがとうございました。
>>991 よく考えてみたらどこかでエラー処理をしそこなっているような挙動ですねえ…
ちょっと調べてみます。
>>991 エラーチェックに漏れがないか調べてみましたけど、
それらしい場所はありませんでした。やっぱりテスト用にもうちょっと
色々なカードを揃えたほうがいいのかな…
>>970 メール受け取りました。早速調べてみます。
>>880 のCPU検索の高速化はどれぐらい速くなるのかな?
楽しみ
>>996 12桁の目標は倍、10桁は10倍が今のところの目標です。
CPU検索だけでも使い物になるプログラムにしたいですねえ。
mtyだとCPU検索は64bitWinで64bit版を動かすと32bit版に比べて2割くらい高速だったけど あれは単純に64bitでビルドするだけじゃなくて64bit最適化みたいなこともしないと駄目なのかな あとmty_calのGPU検索部分は32bit版と64bit版でほとんど同レベルだったから GPU検索が64bit版で高速化しないようなら64bit版を作る意味もあまりないかもしれないけど もし64bit版が簡単に作れて速度も上がりそうなら64bit版も希望
>>998 今自分が使っている環境が64bitなのでいずれ64bit版もぜひ作ってみたいですね。
SSEだけでなくAVXも是非試してみたいです。
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。