5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【トリップ検索】CUDA SHA-1 Tripper【GeForce】

1 :名無しさん@お腹いっぱい。:2011/07/23(土) 22:33:58.01 ID:ymCTk7/G0
CUDA SHA-1 Tripperは12桁トリップ専用のトリップ検索プログラムです。
2009年8月に◆Horo/.IBXjcg氏によって公開されました。

CUDAを使用しているので、GeForceシリーズのビデオカードと
181.20以降のドライバが必要です。
カードによっては600MTrips/sを超える速度を出すことも可能です。
ただ、GPUに高負荷がかかりシステムが不安定になる可能性があるので
使用の際には十分に注意して下さい。

なお、ソースコードは配布パッケージに同梱されています。

■入手先
https://skydrive.live.com/?cid=20e0a840474e1862&sc=documents&id=20E0A840474E1862%21420

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
これは関連スレになるのかな。

【GPGPU】くだすれCUDAスレ pert4【NVIDIA】
http://hibari.2ch.net/test/read.cgi/tech/1291467433/

4 :名無しさん@お腹いっぱい。:2011/07/24(日) 02:45:14.64 ID:hpQtuqnN0
トリップ検索アプリでスレまとめれば?

【mty】トリップ検索「まあ、待て屋。」 Part.1
http://hibari.2ch.net/test/read.cgi/software/1205766220/

5 :1:2011/07/24(日) 09:23:32.57 ID:CCuEpXVd0
>>4
使ってるグラボの種類が違ってて(Radeon とNVIDIA)、
ユーザー層が被らないので別スレでお願いします。

6 :名無しさん@お腹いっぱい。:2011/07/24(日) 14:19:00.68 ID:ua+CIPGNP
>>2
cudaTripper10Wiz7 は、CUDA Toolkit 4.0でビルドしたら、逆に遅くなったなぁ(*‘ω‘ *)

環境の違いかな
>>1 さんは、Windows7 64bitだったりします?

あと、4.0 でビルドしたやつは、実行時に表示される "Revision number" はいくつになるんでしょう?

7 :名無しさん@お腹いっぱい。:2011/07/24(日) 18:10:46.21 ID:hpQtuqnN0
元々ついてるexeと比べればいいの?
CUDA4.0 64bitでコンパイルすると16.0%↑
compute_20,sm_21 に変更すると18.1%↑


8 :名無しさん@お腹いっぱい。:2011/07/24(日) 18:12:22.43 ID:pl0Lw/IJP
>>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"はあとで確かめてみます。

10 :名無しさん@お腹いっぱい。:2011/07/25(月) 20:27:45.24 ID:r1e87oe40
>>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
ドライバはCUDAのサイトでダウンロードしたものを使っています。
http://developer.nvidia.com/cuda-toolkit-40

> devdriver_4.0_winxp_32_270.81_general.exe

うちでは特に不具合は出てませんが…

13 :名無しさん@お腹いっぱい。:2011/07/26(火) 21:13:19.54 ID:oUQaYQf10
>>12
どうも。
やはり環境によるのでしょうかね。
覚悟を決めて270系を試そうか悩みます。

14 :1:2011/07/29(金) 12:59:42.42 ID:ET2Wz95M0
このスレざっと見てみましたけど結構危ない感じですねえ。
うちでは未だになんの不都合もなく動いてます。
何も考えなかったのがかえって幸いしたみたいです…

XP専用 GeForce Driver Part62
http://hibari.2ch.net/test/read.cgi/jisaku/1310557070/

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℃なので問題ないはずですが、ファンが掃除機のようです…

17 :名無しさん@お腹いっぱい。:2011/08/01(月) 02:50:47.38 ID:i5/aokT00
>>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);
}

20 :名無しさん@お腹いっぱい。:2011/08/02(火) 00:34:32.59 ID:yDVCjG6k0
こんばんは。私
http://yakin.38-ch.net/test/read.cgi/trip/1269695900
>>3ですが、いつの間にかアップローダーが消えていたんですね。
とりあえずVS2010 SP1 + CUDA4.0でコンパイルした物を置いておきます。
ttp://loda.jp/uploader777/?id=2180.zip
-xオプションの上限は36まで可能にしてあります。

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
ソースをつらつらと眺めてどうしたら半角カナを含むキーを探索できるようにするか思案中。
http://pastebin.com/bmhRc2t8

key[0]からkey[6]まではsha1trip_search()の外で決め打ちされてるので問題なし。
あとはkey[7]からkey[11]までだけど… いずれShift-JISにも対応させたいので結構悩むなあ
http://charset.7jp.net/sjis.html

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


25 :名無しさん@お腹いっぱい。:2011/08/02(火) 19:26:43.21 ID:tYuMdyPg0
>>24
それをどこにほりこめばいいのですか?

26 :1:2011/08/02(火) 19:36:38.46 ID:eiQbj9dZ0
sha1trip_search()ですけど、これだけだと動きません。
ソースを配布したいのはやまやまなんですけど、どうしよう…

27 :名無しさん@お腹いっぱい。:2011/08/02(火) 19:39:32.69 ID:tYuMdyPg0
>>26
この後に入れそうになった   
out->trip[11] = b64t_d[(c >> 24) & 63];

28 :1:2011/08/02(火) 19:46:51.64 ID:eiQbj9dZ0
それは危ないw ソースは近いうちにうpするのでちょっと待ってくださいな。

29 :名無しさん@お腹いっぱい。:2011/08/02(火) 19:48:18.95 ID:tYuMdyPg0
>>28
わかりました。

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

ちょっと上がって結構嬉しいかも…

31 :名無しさん@お腹いっぱい。:2011/08/02(火) 19:51:54.36 ID:tYuMdyPg0
>>30
驚異的なスピードですです。

32 :1:2011/08/02(火) 20:00:51.82 ID:eiQbj9dZ0
CUDAのためだけに組んだ、一点豪華主義の自作PCです。
ほかの部品を全部足してもGTX 580よりずっと安いですw
頑張ってくれてます。

念のために数時間走らせてヒット率が落ちてないのを確認してから
Shift-JISへの対応に入る予定です。半角カナのときみたいに
変換テーブルが使えないので思案のしどころです。

33 :名無しさん@お腹いっぱい。:2011/08/02(火) 20:04:07.27 ID:tYuMdyPg0
>>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
key[6]までをShift-JISに対応させました。
なぜか乱数発生用に使われていたxor128()がうまくうごかなくなったので
CryptAPIを使うように変更。
http://msdn.microsoft.com/en-us/library/aa382375(v=vs.85).aspx
一応測ってみたけどスピードは落ちてないようです。

問題なのはここからで、実際にGPU内でSHA-1ハッシュを計算するときに
いかにに無効なキーを効率よく排除していくかが鍵になります。

36 :1:2011/08/03(水) 07:27:06.76 ID:aRUlnL6P0
超適当にkey[11]までShift-JISに対応させたら
できたトリップの85%がゴミという素敵な結果にorz
一応できたトリップは有効なようなので、あとは以下にスピードを殺さずに
効率を上げるかなんですが、かなり大変そう…

37 : ◆loooool3HEXd :2011/08/03(水) 09:16:31.63 ID:ff+mBy3Y0
>できたトリップの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対応は終了です。

41 : ◆loooool3HEXd :2011/08/03(水) 13:35:11.39 ID:ff+mBy3Y0
                  ∧∧∩
                 ( ゚∀゚ )/
            ハ_ハ   ⊂   ノ    ハ_ハ
          ('(゚∀゚ ∩  (つ ノ    ∩゚∀゚)')
       ハ_ハ  ヽ  〈   (ノ     〉  /   ハ_ハ
     ('(゚∀゚∩  ヽヽ_)         (_ノ ノ  ∩゚∀゚)')
     O,_  〈                    〉  _,O
       `ヽ_)                   (_/ ´
                                ハ_ハ
 ⊂(。A。⊂_、⊃   で き る よ !!  ⊂´⌒⊃゚∀゚)⊃
   V^V    _                      _
       _ ,ハ                  ( ヽ,_
     O´  〈    _         _     〉  `O
     (.(。A。∪  ノ ハ        ( ヽヽ   ∪。A。).)
       V^V  /  〈    /ヽ   〉  ヽ   V^V
          (.(。A。∪   ノ ⊂)  ∪。A。).)
            V^V    (  ⊃   V^V
                 /( 。A。)
                 ∪V^V

42 :名無しさん@お腹いっぱい。:2011/08/03(水) 18:44:05.25 ID:kks1cpDh0
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化そのものに問題はなくてほっとしました。

47 : ◆loooool3HEXd :2011/08/04(木) 09:15:13.98 ID:tOKBn4oJ0
そろそろですか・・・

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
というわけでこちらがソースコードを含む配布パッケージになります。

CUDA SHA-1 Tripper 0.2.1 MERIKEN's branch 0.01 alpha 1
http://www.meriken2ch.com/files/CUDA_SHA-1_Tripper_MERIKEN0.01a1.zip

自画自賛wですが我ながら良く出来てると思うので使ってやって下さい。
動作報告をしていただけると大変嬉しいです。

53 : ◆MERIKEN4.k :2011/08/05(金) 16:27:07.50 ID:qhRY/zrt0
オリジナルからの改善点は、

・30%ほど速度が向上。
・Shift-JISに対応。
・画面表示の改善。

の3点です。

54 : ◆loooool3HEXd :2011/08/05(金) 16:33:19.94 ID:MMDugCUk0
>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.

55 : ◆loooool3HEXd :2011/08/05(金) 16:41:53.30 ID:MMDugCUk0
まじないがないソースコードは・・(黒一色なんて・・


ありがとう

56 : ◆MERIKEN4.k :2011/08/05(金) 16:48:41.60 ID:qhRY/zrt0
>>54
早速ありがとうございます。>>37と比べると結構速度が上がってますねえ。
よかったよかった。

ソースは確かに色ついてないですねえ。これどうすればいいんでしょう。
実は開発に使ったVisual Studioは全く詳しくないのです…

57 : ◆loooool3HEXd :2011/08/05(金) 16:53:55.72 ID:MMDugCUk0
>>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.

60 :名無しさん@お腹いっぱい。:2011/08/05(金) 17:24:39.88 ID:hdUpxfxK0
乙と言いたいとこだが、オリジナルのライセンスが不明なのに勝手にGPL3を宣言しちゃって大丈夫なのか?

61 : ◆loooool3HEXd :2011/08/05(金) 17:24:51.90 ID:MMDugCUk0
お金=速さ  ですね・・

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.

63 : ◆loooool3HEXd :2011/08/05(金) 17:33:16.33 ID:MMDugCUk0
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
> お金=速さ  ですね・・

でも持ってるものを最大限活用することはできます!
自分もせっかく買ったこのカードを骨までしゃぶりつくすつもりです。

67 : ◆GikoNekobg :2011/08/05(金) 17:45:24.34 ID:MMDugCUk0
ほんと、暖かいねGPUって。
冬ならいいのにな。

68 :名無しさん@お腹いっぱい。:2011/08/05(金) 17:51:12.26 ID:hdUpxfxK0
俺の決めたライセンスが気に入らなきゃオリ作者は連絡寄越せってんじゃなくて、
そっちから連絡取って伺い立てんのが筋じゃねえの?
nvCUDA_sha1からコア部分のマクロとかを拝借したつってるから他のライセンスが絡んでる可能性もあるし。
http://yakin.38-ch.net/trip/

69 : ◆MERIKEN4.k :2011/08/05(金) 18:02:28.95 ID:qhRY/zrt0
>>68
nvCUDA_sha1はクラックツールだからもともと法的には真っ黒ですけどね。
この件は原作者様にこのスレにお越しいただいて解決することにします。

70 : ◆MERIKEN4.k :2011/08/05(金) 18:03:41.82 ID:qhRY/zrt0
というわけで向こうのスレに書きこんできました。
http://yakin.38-ch.net/test/read.cgi/trip/1269695900/20

71 :名無しさん@お腹いっぱい。:2011/08/05(金) 18:04:05.61 ID:hdUpxfxK0
なんつーかひでえな

72 : ◆MERIKEN4.k :2011/08/05(金) 18:14:46.38 ID:qhRY/zrt0
>>67
冬なら暖房いらないですね、これw 最近買ったんですけど、
こんなに熱くてうるさいもんだとは思いませんでした。

73 :名無しさん@お腹いっぱい。:2011/08/05(金) 23:09:50.57 ID:d5H67KpH0
GPUの拘束時間が長い?分重いですがすごい速くなってますね。
280M→440MTrip/s @GTX470

74 : ◆MERIKEN4.k :2011/08/06(土) 02:27:53.77 ID:cg9YSGf00
>>73
> GPUの拘束時間が長い?分重いですがすごい速くなってますね。
> 280M→440MTrip/s @GTX470

報告ありがとうございます。やはりカードによってかなり上昇率にばらつきがあるようですね。
できれば画面のパラメータ等を貼っていただけると有難いのですが…

一応PAUSEキーで一時停止できるようになっていますが、使用中はかなり重くなりますね。

75 : ◆MERIKEN4.k :2011/08/06(土) 02:37:55.61 ID:cg9YSGf00
配布条件については完全に私の勇み足だったので一旦ソースコードの配布は中止させて
いただきます。◆Horo/.IBXjcgには大変申し訳ないことをしました。謝罪させて頂きます。

ソースコードなし、再配布禁止の新しいバージョンを用意したので、今後ダウンロードされる
かたはこちらをご利用下さい。配布条件の違い以外は前のバージョンと同じです。
http://www.meriken2ch.com/files/CUDA_SHA-1_Tripper_MERIKEN0.01a2.zip
なお、最初のバージョンは再配布しないでくださるようお願いします。

76 : ◆MERIKEN4.k :2011/08/06(土) 02:53:25.04 ID:cg9YSGf00
うっかり>>75で◆Horo/.IBXjcg氏を呼び捨てにしてるしorz
返す返すも申し訳ありませんでした。

77 :名無しさん@お腹いっぱい。:2011/08/06(土) 04:03:34.62 ID:45Bn8myw0
オリジナルのコードに対するpatchとしてならば、公開しても問題ない…と思う

78 : ◆MERIKEN4.k :2011/08/06(土) 04:19:36.80 ID:cg9YSGf00
やっぱり慌ててるとろくな事がないですね…
今後の方針としては

(1) ◆Horo/.IBXjcg氏にGPLでの配布の許可をもらえるまで待つ。
(2) なるべくコードの書き換えを進めて、自分のコードにしてしまう。

の二本立てでいきたいと思います。どのみちターゲットを正規表現に対応させるために
大幅に書き換える予定だったので、かえって良かったのかもしれません。
最終目的は10桁のトリップに対応させることだけど、先は長い…

79 : ◆MERIKEN4.k :2011/08/06(土) 04:26:05.91 ID:cg9YSGf00
>>77
> オリジナルのコードに対するpatchとしてならば、公開しても問題ない…と思う

たしかにその手もありますね。ただ、自分のわかりやすいように変数名を
ほとんど変えてしまったのでいまのままだとパッチがまるごとソースコードに
なりかねませんorz

80 : ◆MERIKEN4.k :2011/08/06(土) 14:05:45.16 ID:cg9YSGf00
というわけでコードをせっせと書き換え中。まあなんとかなるでしょう。

81 : ◆MERIKEN4.k :2011/08/06(土) 17:27:57.46 ID:cg9YSGf00
と思ったけどやっぱこれ書き換えただけじゃどうにもならないよなw
まあいいや。もうだいたいやり方は分かったから自分で1から書きなおそう。
CUDA用の10桁トリップ検索プログラムも作りたいし。
10桁のが完成するまでに◆Horo/.IBXjcg氏がここに来てくれるといいなあ。

82 :名無しさん@お腹いっぱい。:2011/08/06(土) 18:09:19.81 ID:eDINnrW+0
http://slashdot.jp/it/comments.pl?sid=540425&cid=1996605
方向性は違うがこれと同レベルで痛いな。

83 : ◆MERIKEN4.k :2011/08/06(土) 21:45:02.24 ID:cg9YSGf00
>>82
ん? 別に自分で1から書き直す分には問題ないでしょう。
それともバイナリの配布が気に入らないのかしらん。

84 : ◆MERIKEN4.k :2011/08/06(土) 21:46:37.73 ID:cg9YSGf00
氏の元の発言を読みかえしたら、nvCUDA_sha1の部分に問題があるだけで
氏の書いたコードの再配布自体は構わないと仰られてますね。

> 7 :ののたん ◆KiwamonoL. :2010/10/24(日) 00:05:13.67 ID:oeeN+FrM0
> >>6
> ソースをいじくりまわしたものを再配布してもいいのでしょうか?
http://yakin.38-ch.net/test/read.cgi/trip/1269695900/7

> 15 : ◆Horo/.IBXjcg :sage :2011/06/20(月) 00:57:29.38 (p)ID:UnljLL3w0(3)
> >>7
> わっちは構わぬのじゃが、他から拝借した部分があるからややこしいかもしれぬの。
>
> 確かnvCUDA_sha1とかいうのを改造しようとして、完全にはよう理解せなんだから
> コア部分のマクロとかを拝借した記憶があるの。
http://yakin.38-ch.net/test/read.cgi/trip/1269695900/15

85 : ◆MERIKEN4.k :2011/08/06(土) 21:49:32.26 ID:cg9YSGf00
というわけなのでnvCUDA_sha1由来の部分だけ書き換えてから
もう一回GPLv3でソースを含めて配布することにします。

86 :ののたん ◆KiwamonoL. :2011/08/07(日) 01:50:34.36 ID:CoKtIaaQ0 ?DIA(289888)
話がループに入ったな。w
からんできてる名無しが問題にしてるのは再配布してることじゃなくて、
ライセンスを勝手に設定してることなんじゃないのか。

原作者はいじろうが再配布しようが気にしそうにはないけど。
つーか、パクったことを隠してバイナリだけを配布してる訳じゃないし。


ついでに俺様らしい意地悪なことも書いておこう。www
許可を求めたのは俺様で、「構わぬ」という返事は俺様宛であって見ている人全員じゃないだろ。(和良

87 : ◆MERIKEN4.k :2011/08/07(日) 03:25:56.90 ID:tpe7fUST0
特にGPLで配布することに問題は感じませんけどね。自分がGPLで
配布しても、元のコードの著作権は氏が保有してるわけですから
氏の権利が制限されることはありません。

> 「構わぬ」という返事は俺様宛であって

あの書き方を見る限り誰が再配布しても構わないようでしたけど。

88 : ◆MERIKEN4.k :2011/08/07(日) 03:59:16.63 ID:tpe7fUST0
もちろん勝手に商用ライセンスを設定したりするのはまずいですけど、
GPLは改変したソースコードの公開を強制するライセンスですから
ライセンスなしやBSDで配布するより安全でしょう。

89 :名無しさん@お腹いっぱい。:2011/08/07(日) 04:05:09.97 ID:p3nC4NxP0
「元のソースのライセンスが不明確(「見せる」のが目的で「弄る」ことを禁止されている可能性がある)なのに勝手にソース弄って公開したら駄目だ」とか
「元のライセンスがGPLと互換性がないのにGPLにしたら駄目だ」とかならまだ分かるけど
「元の作者が派生物にGPLをライセンスすることを意図していないかもしれないのに勝手にGPLにしたら駄目だ」なら理解できない
ライセンスの決定権は派生物作者にあるんだから、文句があるなら自分でプログラム書けという話。
ま、GPLは名無しが勝手に色々弄る場所に向いたライセンスとはあまり言えないと思うがね。ある意味非常に厳しいライセンスだし。
しかもバイナリ配布時にソースを添付しないといけない訳でも、ネット上でのソース公開を強制するものでも、バイナリ無償配布を強制するものでもない。
> 見ている人全員じゃない
2人がプライベートで話したのではなく、BBS上で公に書いた以上、それは解釈に無理があるだろう。

90 :名無しさん@お腹いっぱい。:2011/08/07(日) 04:10:32.11 ID:p3nC4NxP0
>>88
ん?GPLのプログラムを売ってはいけない決まりはないぞ。販売もフリーのライセンスだから。

91 : ◆MERIKEN4.k :2011/08/07(日) 04:12:56.17 ID:tpe7fUST0
>>90
もちろんそれは理解してますけど、GPLは商用ライセンスじゃないでしょう。

92 :名無しさん@お腹いっぱい。:2011/08/07(日) 08:11:30.86 ID:4o98MY9B0
>>87
やっぱり理解してないな…
何でしばしばGPLと互換性があるライセンスなのかどうかが問題になるのか考えてみよう

93 :名無しさん@お腹いっぱい。:2011/08/07(日) 08:12:22.05 ID:4o98MY9B0
>>91
ググれよ
http://ja.wikipedia.org/wiki/%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%81%AE%E4%BA%92%E6%8F%9B%E6%80%A7

94 : ◆MERIKEN4.k :2011/08/07(日) 08:57:03.28 ID:tpe7fUST0
>>93
GPLがviralだということは十分承知してますよ。だからこそGPLを選んだんですけど…

もちろん私がGPLv3で改変物を配布しても、◆Horo/.IBXjcg氏は自分のコードは好きに
できるので、別のライセンスを選んで配布することは自由です。

95 : ◆MERIKEN4.k :2011/08/07(日) 10:02:08.76 ID:tpe7fUST0
例えば私が変更を加えたTripperをGPLv3で配布しても、オリジナルはHoro/.IBXjcg氏の
著作物なので氏がBSDライセンスやX11で配布することが出来ます。私がGPLを使うことに
反対されてる方々はここらへんを理解してないのでしょう。

96 : ◆MERIKEN4.k :2011/08/07(日) 10:13:03.41 ID:tpe7fUST0
>>93の話は著作権者以外の人間がライセンスの異なるソフトウェアをマージする
ときに発生する問題であって、Tripperの著作権者である◆Horo/.IBXjcg氏には
あてはまりません。

というわけで自分は>>85の方針で全く問題ないと考えるので、
今後この話は◆Horo/.IBXjcg氏との間だけでさせて頂きます。悪しからず。

97 : ◆MERIKEN4.k :2011/08/07(日) 11:04:22.28 ID:tpe7fUST0
というわけでググったらこんなのが見つかりました。

sha_digest 2.2
http://users.physik.fu-berlin.de/~jtt/sha_digest.html

GPLv2のSHA-1の実装です。これをCUDAに移植して最適化して
元のコードとまぜまぜすれば問題は解決するわけだ。

98 :ののたん ◆KiwamonoL. :2011/08/07(日) 11:46:39.51 ID:CoKtIaaQ0 ?DIA(289888)
聞いたのが 2010/10/24 で返事が 2011/06/20 。
さて次の降臨はいつだ。w

なんというかさすがソフトウェア板。
ライセンスがどうのに厳しいな。
待て屋スレその他でもいろいろいじめられたし。
結局GPLと言いながら要件を満たさないまま放置してる俺様カコイイ!

99 :名無しさん@お腹いっぱい。:2011/08/07(日) 15:20:28.66 ID:4o98MY9B0
>>95
>>82にもあるが、やっぱりベクトルは違うが理解してない度は同レベルだな

100 :名無しさん@お腹いっぱい。:2011/08/07(日) 15:23:59.75 ID:C+2UJfcg0
グレーのままで置いておけばいいものを…

101 : ◆MERIKEN4.k :2011/08/07(日) 15:35:57.58 ID:tpe7fUST0
>>98
> 聞いたのが 2010/10/24 で返事が 2011/06/20 。
> さて次の降臨はいつだ。w

今年はもう現れてくれないんじゃないですかw
もちろん来てくれることに越したことはないですけど…

> 結局GPLと言いながら要件を満たさないまま放置してる俺様カコイイ!

こりゃいかんがな (´・ω・`)

102 : ◆MERIKEN4.k :2011/08/07(日) 16:12:52.97 ID:tpe7fUST0
まあそのうち最適化が十分進んで
知らない間に元のコードがなくなるぐらいになりますよw

次に考えてるのはCUDA内のヒット判定の最適化です。
trip[0]からtrip[4]までの6bits * 5 = 30bitsと
大きさが2^30bits = 128MBの巨大なビットマップを使って、
トリップがパターンにマッチするかどうかをほぼO(1)で
判定できるようにする予定です。
これで検索するターゲットの増加による速度低下はほぼ0になるはずですけど、
うまくいくかしらん。

103 : ◆MERIKEN4.k :2011/08/07(日) 18:01:41.30 ID:tpe7fUST0
試しに何も変更しないで5000個のターゲットを試してみたら、
いつまでたっても最初のサイクルが終わりませんでしたw

6完500タゲでも112M tripcodes/sという微妙すぎる結果に。
6完1タゲが788M tripcodes/sなのでえらい速度低下です。
これはなんとかしないと…

104 : ◆MERIKEN4.k :2011/08/07(日) 18:04:28.25 ID:tpe7fUST0
これ、ループの最深部でのヒット判定がO(N)なのが問題なんだよな。
こりゃ遅くなるわけです。

105 :ののたん ◆KiwamonoL. :2011/08/07(日) 23:44:07.27 ID:CoKtIaaQ0 ?DIA(289888)
>>99
「人と人とは理解し合えない」って偉い人が言ってたよ。

『事実』と『妄想』はきっちりわけて、
『妄想』はなるべく垂れ流さないようにしてる俺様だが、
あえて言おう。カs・・・・・おっと違う。w
原作者はどうしようと文句言う気なんかないんじゃね?(妄想

つか、妄想で物言うヤツ大杉。

106 :名無しさん@お腹いっぱい。:2011/08/07(日) 23:55:50.46 ID:LxMCVz7M0
そこで、なんとか粒子の登場ですね。

107 : ◆MERIKEN4.k :2011/08/09(火) 07:51:06.98 ID:vLxOj7590
「僕が一番CUDAをうまく使えるんだ」ってなもんですかw

さっさと書き換えてソースを公開したいけど、用事ができてしまい時間がなかなかとれません。
その間にアイディアは溜まっていく一方で、ちょっともどかしいです。

108 :名無しさん@お腹いっぱい。:2011/08/09(火) 09:53:34.75 ID:UqIW6c680
まさにチラシの裏にでも書いてろ。

109 : ◆MERIKEN4.k :2011/08/10(水) 09:02:25.47 ID:omyMOCso0
>>97のコードをコンパイルしてみました。
あっさり通ったので、とりあえず生成したトリップを元に
新しいコードの検証をしてみたいと思います。
余計な部分を取り除いてから、CUDA Cに移植する予定。

110 :名無しさん@お腹いっぱい。:2011/08/10(水) 09:11:42.75 ID:Kw7pHqZv0
>>109
そのソースをコンパイルしたバイナリをCUDA C(ry

111 : ◆MERIKEN4.k :2011/08/10(水) 09:59:54.43 ID:omyMOCso0
新しいコードはあっさりと動作確認できました。
用意された関数を呼び出したんですが、
Tripperと>>97のコードで同じ結果が出ています。

> SHA1_Context context;
> BYTE digest[SHA1_HASH_SIZE];
> sha1_initialize(&context);
> sha1_add_bytes(&context, key, 12);
> sha1_calculate(&context, digest);

問題はこれからなんだけど…

112 : ◆MERIKEN4.k :2011/08/10(水) 12:08:59.14 ID:omyMOCso0
無事にトリップ生成関数の作成に終了。

> void sha1_generate_tripcode(UINT8 *key, UINT8 *digest)

Horo氏はSHA-1のマクロがよくわからんと書いてましたけど、
私もさっぱりわかりませんw まあ動いてるからいいや。
食事食べてからCUDA Cに移植しよっと。

113 : ◆MERIKEN4.k :2011/08/10(水) 12:09:58.85 ID:omyMOCso0
よく考えたらこの関数ってCPUでトリップコードの検索をさせるのにも
使えるんだよな。

114 : ◆MERIKEN4.k :2011/08/10(水) 13:03:50.29 ID:omyMOCso0
よっしゃ、一発で動いた!
しかも元のコードより速くなっててテラワロスw

115 :名無しさん@お腹いっぱい。:2011/08/10(水) 13:25:40.66 ID:OCw6f7BO0
んなつまんない物作んないでzipとかrarの暗証解読作れや

116 : ◆MERIKEN4.k :2011/08/10(水) 13:43:44.91 ID:omyMOCso0
と思ったら勘違いだった orz
5パーセント近く遅くなってるな…
まあでも一発で動いただけでもよしとしなきゃな。
これから最適化するか…

117 : ◆MERIKEN4.k :2011/08/10(水) 14:16:27.97 ID:omyMOCso0
>>115
あ、これは完全に遊びなので、そういう人に迷惑がかかることは
やらないのです。

118 : ◆MERIKEN4.k :2011/08/10(水) 16:01:00.76 ID:omyMOCso0
ちょこちょこといじったら元のコードよりも速くなりました。
ループの外に処理を追い出したり、配列の代わりに定数をつかうように
したりしただけですが…
コンパイラの最適化が甘いらしく、ちょっとしたことですぐに速度が
変わってきます。


なんにせよコードもすっきりしたし、言うことなしです。
ちょっと心配だったけどほっとしました。
最終確認をしてからソースを含めてうpすることにします。

119 : ◆MERIKEN4.k :2011/08/10(水) 17:08:25.79 ID:omyMOCso0
というわけで新しいバージョンです。ソースも同梱されています。

CUDA SHA-1 Tripper 0.2.1 MERIKEN's branch 0.01 alpha 5
http://bitly.com/r0jVWJ

出所不明のコードをGPLv2でライセンスされたもので置き換えてあります。
また、前のバージョンに比べて多少速度が上がって表示画面が見やすく
なっています。

120 :名無しさん@お腹いっぱい。:2011/08/10(水) 17:39:49.55 ID:pqCyKwOh0
何故にわざわざ短縮URL…
https://sites.google.com/site/meriken2ch/files

121 : ◆GikoNekobg :2011/08/10(水) 19:16:02.34 ID:GFyY0yvi0
止まったがな・・

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
基本的な質問ですいません。。

トリップがあるのですが、そのキーを忘れた場合はどのようにどうしたら良いのでしょうか?

123 :名無しさん@お腹いっぱい。:2011/08/10(水) 23:36:12.67 ID:Kw7pHqZv0
>>122
専ブラの履歴もしくは、その専ブラのフォルダ内のいづれかのファイル内に残ってないの?

で、どうするかだけど、そのトリップは本当に貴方が使っていたものかどうか?というのが
分からないと、他人になり済まそうとしている可能性もあるわけで。

その辺、証明できるものはある?

124 :いいんちょ ◆GPPPPPPPPU :2011/08/10(水) 23:44:54.73 ID:oHSC6TRFP
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タゲ(前方一致)

125 :いいんちょ ◆GPPPPPPPPU :2011/08/10(水) 23:45:37.59 ID:oHSC6TRFP
激しく誤爆(*‘ω‘ *)www

126 :名無しさん@お腹いっぱい。:2011/08/11(木) 00:17:57.64 ID:Qvv5g6fwO
スレッドに張り付けてあるんでそのスレは、気付いてお気に入り登録したので判ります!

証明出来るもの自体がわからないんです。。

127 : ◆MERIKEN4.k :2011/08/11(木) 02:47:16.47 ID:ufqwc1xP0
>>121
> 止まったがな・・

報告ありがとうございます。本当に助かります。どうもNumber of Blocksが
少ないと落ちてしまうみたいですね… ちょっと調べてみます。

128 : ◆MERIKEN4.k :2011/08/11(木) 02:51:35.92 ID:ufqwc1xP0
オプションで"-x 1"を指定したら100%おちました/(^o^)\

129 : ◆MERIKEN4.k :2011/08/11(木) 03:03:57.34 ID:ufqwc1xP0
>>124
あ、どうも〜 これだけタゲが増えても速度が落ちないのは凄いですねえ。

130 : ◆MERIKEN4.k :2011/08/11(木) 03:05:37.42 ID:ufqwc1xP0
新しいコードが原因かと思ったけど、コメントアウトしても
まだ発生します。とりあえず一安心ですが何が原因なんだろ。
CUDAのコードじゃないのかな…

131 : ◆MERIKEN4.k :2011/08/11(木) 03:54:12.71 ID:ufqwc1xP0
やれやれ、やっとバグが取れたわい。
コードを書き直す過程で混入していたみたいです。

132 : ◆MERIKEN4.k :2011/08/11(木) 04:11:37.22 ID:ufqwc1xP0
というわけでバグを修正したものをうpしました。
◆GikoNekobgさん、ありがとうございました。

http://www.meriken2ch.com/files/CUDA_SHA-1_Tripper_MERIKEN0.01a6.zip

133 : ◆MERIKEN4.k :2011/08/11(木) 05:17:12.74 ID:ufqwc1xP0
>>128のアイディアを試してみたけど、
速度低下が激しく使い物になりませんでしたorz
やはり256個のスレッドが128MBのメモリにランダムアクセスするという
のは無理があったみたいです。もうちょっとテーブルを小さくすれば
使い物になるかな。

134 : ◆MERIKEN4.k :2011/08/11(木) 09:23:56.13 ID:ufqwc1xP0
テーブルの作成をしている傍らで気になっていた不具合をいろいろ
潰しました。

特に問題だったのが、>>103-104で報告したターゲットの増加に伴う
速度低下の不具合でしたが、マッチ判定の部分をいじったらかなり
改善されました。

6完500タゲ 112M → 555M
6完5000タゲ 測定不能 → 162M

だいぶましになったけど、>>124の数字と比べるとやっぱり
見劣りするなあ… どうしたものか。

135 : ◆GikoNekobg :2011/08/11(木) 12:38:44.93 ID:5Qs7LbSJ0
テストン
===========
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.

136 : ◆MERIKEN4.k :2011/08/11(木) 12:48:02.44 ID:ufqwc1xP0
>>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)

早速助かります。ちょっと数字が落ちてるのが気になりますね。もうちょっと調べてみます。

137 : ◆MERIKEN4.k :2011/08/11(木) 13:17:39.28 ID:ufqwc1xP0
テーブルを使ってかなり早くなったのですが、ときどき原因不明のエラーで
落ちるようになってしまいました。テーブルを大きくすると落ちるので、
メモリ周りが原因なのかしらん。

138 : ◆MERIKEN4.k :2011/08/11(木) 15:27:10.37 ID:ufqwc1xP0
速度はこんな感じで相当上がってきたんですが、まだ時々例外が出てプロセスが終了します。
どうしてなんだろ…

6完500タゲ 112M  → 555M → 721M
6完5000タゲ 測定不能 → 162M → 720M

139 :名無しさん@お腹いっぱい。:2011/08/11(木) 15:46:42.93 ID:5C+iaRgc0
デバッグしろよデバッグ
Parallel Nsight使えば追えるだろ

140 : ◆MERIKEN4.k :2011/08/11(木) 15:59:50.31 ID:ufqwc1xP0
うちのPC、XPでParallel Nsight使えないんですよ…
どうやら落ちてるのは本体側のコードらしいので、
休憩してから追ってみます。

141 :名無しさん@お腹いっぱい。:2011/08/11(木) 19:32:16.76 ID:Qvv5g6fwO
トリップキーを忘れてしまいました。 検索出来る方、方法があれば教えてもらえませんか?

もし教えてもらえたらサブアドレス貼りますのでよかったら教えて下さいm(__)m

142 : ◆GikoNekobg :2011/08/11(木) 20:08:56.10 ID:5Qs7LbSJ0
逆引きナンテ技で・・・・>140

>>141
このスレまでこれたのなら、自力で何とか出来ないかお前。

143 : ◆MERIKEN4.k :2011/08/12(金) 03:12:59.93 ID:EYJ1odVH0
>>140
逆引き? なんでしょうそれは…

>>141
似てるのならいくらでも作れるけど、完全一致となると無理ですねえ。

144 : ◆MERIKEN4.k :2011/08/12(金) 04:47:06.33 ID:EYJ1odVH0
GPUが85度の状態で24時間動かし続けてたらpower throttlingが頻繁に起こるように
なってしまいました。ファンの回転数を調整して70度にしたら安定してきました。
うるさいですけど、やっぱりあまり無茶はできませんね。

145 : ◆MERIKEN4.k :2011/08/12(金) 08:29:43.39 ID:EYJ1odVH0
どうやら新しく書いたCUDA用のヒット判定のコードがエンバグしてる模様。なぜだ…

146 : ◆MERIKEN4.k :2011/08/12(金) 11:24:26.97 ID:EYJ1odVH0
ようやくバグが潰せたみたいです。コードがすっきりした分速度も上がりました。

6完500タゲ 112M  → 555M → 721M → 727M
6完5000タゲ 測定不能 → 162M → 720M → 725M

あと、N=1の特殊なケースの際も性能が数%向上しています。

ただターゲットの数が多いケースではビットマップの効果が大きいのですが、
ターゲットが数が数個の場合はグラボのメモリに対する大量のランダムアクセスのおかげで
かえって性能が落ちるようです。できればランタイムで最適な方法をえらべるようにしたいところ
ですが…

147 : ◆MERIKEN4.k :2011/08/12(金) 12:10:39.34 ID:EYJ1odVH0
…まだたまにCUDA側のコードの出力が化けるなあ。
まあいいや、無効な出力は処理しないで飛ばしてしまおう。

148 : ◆MERIKEN4.k :2011/08/12(金) 12:31:18.77 ID:EYJ1odVH0
元のコードでなんでわざわざ出力用の配列をループの最後で0にクリアしてるのか
不明だったけど、こういうことだったんだな。

149 : ◆MERIKEN4.k :2011/08/12(金) 13:23:45.13 ID:EYJ1odVH0
試しに英単語のリストを使ってターゲットを65536個にしたら、677M tripcodes/sがでました。
ほとんど速度が落ちてないですね。素晴らしい。

150 : ◆MERIKEN4.k :2011/08/12(金) 13:33:57.10 ID:EYJ1odVH0
192K個のターゲット(8〜12完)で651M tripcodes/sが出たのでかなりいい感じです。
ちなみに256Kではプログラムが落ちてしまいましたw さすがに無茶ですね。

151 : ◆MERIKEN4.k :2011/08/12(金) 14:39:06.63 ID:EYJ1odVH0
おかしな出力を調べるために色々仕掛けをして、しばらく動かしたまま放置しておくことに。
うーん、どうなるか楽しみだ…

152 : ◆MERIKEN4.k :2011/08/12(金) 14:59:46.34 ID:EYJ1odVH0
化けた出力はかなり不思議なことになっていました。
てっきりメモリがどかっと書き換えられているのかと思ったら、
そうではなくて特定の数バイトだけがおかしくなっています。
ひょっとしたらこれ、グラボをオーバークロックしたからかもしれんな。
もとに戻して試してみよう。

153 : ◆MERIKEN4.k :2011/08/12(金) 15:27:03.94 ID:EYJ1odVH0
やはり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回)ほど時間がかかり過ぎて!

助けてもらえないでしょうか(>_<)

156 : ◆MERIKEN4.k :2011/08/12(金) 17:29:10.26 ID:EYJ1odVH0
>>154-155
助けてあげたいのはやまやまですけど、どこにも残っていないなら復元は無理です。
そのためのトリップなんですから。スレ違いなのでもう返事はしないので、悪しからず。

157 :名無しさん@お腹いっぱい。:2011/08/12(金) 18:16:58.07 ID:LH7k2nKmO
すいません。お邪魔しました

158 :名無しさん@お腹いっぱい。:2011/08/12(金) 18:54:15.39 ID:4huWp6Db0
独り言形式だと敵を作ると思うので、報告形式にした方がいいかと…

応援してます、頑張ってください。

159 : ◆MERIKEN4.k :2011/08/13(土) 00:06:13.89 ID:qrBcmYtV0
あ、これ考えるのの手助けに書いてるようなものなので…
とりあえずこのまま続けて、問題が出てきたら変えるようにします。

160 : ◆MERIKEN4.k :2011/08/13(土) 00:09:20.62 ID:qrBcmYtV0
なんにせよ応援ありがとうございます。
色々付け足したい機能があるので当分の間はせっせと取り組むつもりです。

161 : ◆MERIKEN4.k :2011/08/13(土) 00:26:36.99 ID:qrBcmYtV0
これまでCUDAのコードのループの最深部で、どの探索方法を使うかについて
分岐させてたのですが、1つの分岐のコストがしゃれにならないので、
マクロを多用してケースごとに関数を作ることにしました。

可読性? なにそれおいしいの? という感じですが、
その結果ターゲットの数が少ない場合の速度がかなり改善されました。
こんどこそ最初のバージョン(0.01a1)より速くなってるはずです。

162 : ◆MERIKEN4.k :2011/08/13(土) 06:10:08.69 ID:qrBcmYtV0
ほぼ満足行く最適化が出来たので、細かい部分の修正に入りました。
幾つかオプションを追加しました。

-b: ヒットしたらビープを鳴らす。
-i: 無効なキー(Unicode非対応)のトリップコードも出力する。

後やりたいのはターゲットの数の上限を取り払うことです。
ここまでできたら次のバージョンを"0.01 beta 1"として公開したいと思います。

163 : ◆MERIKEN4.k :2011/08/13(土) 14:20:10.47 ID:qrBcmYtV0
上限を取っ払うついでに色々コードを書き換えたらまた不安定に…
後もうちょっとなんだけどなあ。

164 : ◆MERIKEN4.k :2011/08/13(土) 14:56:23.35 ID:qrBcmYtV0
…どうもまたOCがらみのようです。紛らわしいから開発の最中は切っておくことにしよう。

165 : ◆MERIKEN4.k :2011/08/13(土) 15:30:21.01 ID:qrBcmYtV0
OCを切ったら気持よく動いてくれています。よかったよかった。
19万タゲで試してみましたが、速度低下も1タゲと比較して14%程度に抑えられています。
5日前のこと( >>103-104 )を考えると夢のようですw
この拡張は正規表現への対応の下準備なので、これぐらい性能に余裕があると安心です。

166 : ◆MERIKEN4.k :2011/08/13(土) 16:16:02.74 ID:qrBcmYtV0
というわけで>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しよっと。

167 : ◆MERIKEN4.k :2011/08/13(土) 23:54:25.87 ID:qrBcmYtV0
新しいバージョンです。これで問題がなければこのバージョンを
0.01の正式版にすることにします。

CUDA SHA-1 Tripper MERIKEN's Branch 0.01 beta 1
http://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch

168 : ◆MERIKEN4.k :2011/08/13(土) 23:58:45.71 ID:qrBcmYtV0
書き忘れてた。今回の変更点は以下になります。

・ターゲット数の制限の撤廃。多ターゲット時の大幅な速度の向上。

ターゲット数が少ない場合の速度もちょっとだけ上がっています。

169 : ◆MERIKEN4.k :2011/08/14(日) 07:28:46.80 ID:9YUjltRZ0
今後の予定として今考えている追加機能は、これぐらいです。

・正規表現による検索
・10桁トリップの検索
・CPU検索
・速度測定による動的な探索アルゴリズムの選択
  (線形・2分探索、キービットマップの使用・不使用)
・GUIの実装
・元のコードの書き換え

正規表現への対応が、内部のデータ構造に与える影響が一番大きくて
頭をつかうので、これから手をつけようかな。9月からまた忙しくなるから
時間のあるうちに片付けておこう。これについてはずっと考えていて、
もう頭の中でアルゴリズムは出来上がってるので、後はせっせと
コーディングをするだけです。

170 : ◆MERIKEN4.k :2011/08/14(日) 15:34:46.14 ID:9YUjltRZ0
ダウンロードしてくれてる人はいるみたいだけど、ちゃんと動いてるのかな〜
うちでは絶好調で動いてますけど、環境が変わると違うから、ちと不安です。

さて、今日は正規表現への対応の下準備をしていました。
オリジナルのTripperでは、CUDAのコードではトリップの最初の5文字を
使って一致しているかどうか判定していて、残りはCPUが調べています。

いまやっているのは、この「最初の5文字」という制限を取り払って、
CUDAのコードで任意の位置の5文字を比較できるようにする、ということです。
そのために色々内部構造を拡張しているのですが、CPUとGPUの
アドレス空間の違いを常に意識しなければいけないのでかなりめんどくさいです。

171 : ◆MERIKEN4.k :2011/08/14(日) 15:54:38.62 ID:9YUjltRZ0
配列のサイズを決めうちにすればこんなに悩まなくて済むんですけど、
このプログラムには余計な制限は一切付けない方針です。


あ、あともう一つ新しいオプションを付けました。

-w: 速度が急に低下したら警告する。

グラボをOCしてるときにひんぱんにpower throttlingがかかって
速度が低下したので、念のためこのオプションを追加しました。

172 : ◆MERIKEN4.k :2011/08/14(日) 16:00:53.01 ID:9YUjltRZ0
まあ普通に考えたら何万も何十万もターゲットを設定するわけないんだから、
反応が薄くても仕方ないよなw
やっぱ本命はあくまで正規表現と10桁対応だよな。この2つは今月中にぜひ
やり遂げたい。

173 : ◆GikoNekobg :2011/08/14(日) 17:26:01.14 ID:AOqK5npp0
速くなったね。。

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.

174 : ◆GikoNekobg :2011/08/14(日) 17:40:59.26 ID:AOqK5npp0
落ちないね。。ご苦労様です

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.

175 : ◆GikoNekobg :2011/08/14(日) 17:43:02.61 ID:AOqK5npp0
>まあ普通に考えたら何万も何十万もターゲットを設定するわけないんだから、

Searching for 198173これぐらいがふつうですよね・・

176 :ののたん ◆KiwamonoL. :2011/08/14(日) 19:47:25.24 ID:n+td4OoF0 ?DIA(289888)
やかん板に降臨。
と思ったら、ここにはまだか………。

177 :名無しさん@お腹いっぱい。:2011/08/14(日) 21:00:10.27 ID:Az5gvvmS0
自慢屋さん乙↑

178 : ◆Horo/.IBXjcg :2011/08/14(日) 21:23:37.52 ID:1W3huLTr0
>>9
CUDA 4.0でFermiに最適化したコードを吐かせると30%も速くなるのかや。

>>42
Mapped Memoryは面倒そうじゃが、上手くいったときのメリットも大きそうじゃな。

>>69
ただのパスワードクラッカーの作成や利用そのものが法に触れるような国はどこかの?
仮に法に触れるとすれば、それはそれでそんなものを参考にしてツールを作るのは倫理的にどうなんだという話になりかねんしの・・・

>>103-104
ヒット判定自体が重いことに加えて、ワープ・ダイバージェンスの問題も起きていそうじゃな・・・

>>112
理解できなんだのは別の部分なのじゃが、まああのマクロも1から書けと言われると厳しいの。

>>146
グローバルメモリへのアクセスは色々と面倒じゃから、ビットマップを使うという発想はなかったの。

179 : ◆Horo/.IBXjcg :2011/08/14(日) 21:37:02.29 ID:1W3huLTr0
>>167
早速見せてもらっているのじゃが、こういうマクロの使い方もあったとはの w

>>169
正規表現や10桁トリップへの対応は相当な作業量にならないかの。

>>170
分岐が多発する状況はかなり気を使う必要があって面倒じゃな。

>>171
GTX 580のOCは消費電力も凄そうじゃの・・・

180 : ◆MERIKEN4.k :2011/08/15(月) 10:05:12.36 ID:MyZmNGi40
>>173-175
いつもありがとうございます。そちらで無事に動いているのが
確認できてほっとしました。でも19万ターゲットは普通じゃないですw
複雑な正規表現が展開された時のことを見越して性能を上げておいたのです。

181 : ◆MERIKEN4.k :2011/08/15(月) 10:13:00.26 ID:MyZmNGi40
>>178
わざわざお越しいただいてありがとうございます。
公開してくださったコードのおかげで楽しく遊ばせていただいてますw
改変したものは、問題がないと判断してGPLv3で公開しましたが、
もし問題がありましたら、一言いただければ直ぐに対処させて頂きます。

182 : ◆MERIKEN4.k :2011/08/15(月) 10:29:51.32 ID:MyZmNGi40
>>178
> Mapped Memoryは面倒そうじゃが、上手くいったときのメリットも大きそうじゃな。

以前試したときには思ったほど効果は上がりませんでした。
ランダムアクセスが大量に発生するからかも知れません。

> >>69
> ただのパスワードクラッカーの作成や利用そのものが法に触れるような国はどこかの?
> 仮に法に触れるとすれば、それはそれでそんなものを参考にしてツールを作るのは倫理的にどうなんだという話になりかねんしの・・・

アメリカではこんな話もあります。
http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%9F%E3%83%AC%E3%83%8B%E3%82%A2%E3%83%A0%E8%91%97%E4%BD%9C%E6%A8%A9%E6%B3%95

> >>103-104
> ヒット判定自体が重いことに加えて、ワープ・ダイバージェンスの問題も起きていそうじゃな・・・

なるほど、道理で… 条件文が入るとやたらと遅くなる理由がわかりました。

> グローバルメモリへのアクセスは色々と面倒じゃから、ビットマップを使うという発想はなかったの。


1バイトを1ビットとして扱う富豪的プログラミングですw

183 : ◆MERIKEN4.k :2011/08/15(月) 10:45:39.26 ID:MyZmNGi40
>>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年後とおっしゃらず、またぜひお越しください。お待ちしております。

184 : ◆MERIKEN4.k :2011/08/15(月) 11:29:55.70 ID:MyZmNGi40
       |
   \  __  /
   _ (m) _ピコーン
      |ミ|
    /  `´  \
     ('A`)
     ノヽノヽ
       くく

さっきこんな感じでひらめいて、最小限の手間で
前方一致だけでなく任意の位置の文字列を探索する機能が実装できました。
後は本体側で正規表現を展開する処理を実装すればいいだけです。

185 : ◆MERIKEN4.k :2011/08/15(月) 11:33:55.13 ID:MyZmNGi40
…「いいだけ」ってかいたけど結構な作業量ですよね、これ。
まあ技術的に一番難しい部分は解決したわけだからいいか。

186 : ◆MERIKEN4.k :2011/08/15(月) 14:02:25.60 ID:MyZmNGi40
とりあえず"target_regex.txt"にターゲットを書き込むと
任意の位置で検索できるようにしました。速度は20%以上
落ちますがまあこれは仕方がない。あとは今後の最適化次第です。

187 : ◆Horo/.IBXjcg :2011/08/15(月) 17:57:39.65 ID:XwIjWBID0
>>181
楽しんでもらえて嬉しいでありんす。
わっちが書いた部分は構わぬというか、改造版を見て楽しんだりとかを考えるとライセンスの衝突が無ければその方が良さそうじゃの。

>>182
演算量に対してホスト・デバイス間のデータ転送量が十分に少ないから差が出にくいのかの。

DMCAは範囲が限定されておるが、それでもかなり議論になっておるの。
EUの方ではクラッキングツールの違法化を唱えておる者もおるみたいじゃが、愚かなことにならなければいいがの・・・


188 : ◆Horo/.IBXjcg :2011/08/15(月) 18:19:50.78 ID:XwIjWBID0
>>182
メモリ使用量的には富豪的とは思わぬが、グローバルメモリへのアクセス、それもランダムなのが気になるのじゃが
アクセスにかかる時間は大量のスレッドで隠蔽できておるということかの。

>>183
あの巨大なマクロは一部が異なる関数を多数作るのに利用しておるのかや?

DESベースのcryptをCUDAで実装するのは色々と苦労しそうじゃが、
主様はわっちよりかなり頭が良さそうじゃから期待していいのかの? w

消費電力が増加分だけで200Wとはハイエンドのグラボとは怖ろしいものじゃの・・・

>>184 >>186
どうやっておるのか気になるの。
その方法を考えながら待つというのもまた楽しいがの w

189 : ◆MERIKEN4.k :2011/08/16(火) 04:34:48.94 ID:rCBU7iUe0
>>187
> 楽しんでもらえて嬉しいでありんす。
> わっちが書いた部分は構わぬというか、改造版を見て楽しんだりとかを考えると
> ライセンスの衝突が無ければその方が良さそうじゃの。

そう言っていただけるとほんとうに有難いです。

> 演算量に対してホスト・デバイス間のデータ転送量が十分に少ないから差が出にくいのかの。

いったん準備が整ったらCPU側ではCUDAのメモリはいじらないですからね。

> DMCAは範囲が限定されておるが、それでもかなり議論になっておるの。
> EUの方ではクラッキングツールの違法化を唱えておる者もおるみたいじゃが、
> 愚かなことにならなければいいがの・・・

経済活動のために自由を制限しようという動きは活発ですからね。心配です。

190 : ◆MERIKEN4.k :2011/08/16(火) 04:55:07.30 ID:rCBU7iUe0
>>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

191 : ◆MERIKEN4.k :2011/08/16(火) 08:11:17.75 ID:rCBU7iUe0
というわけで早速正規表現展開用のスタックを実装して、
正規表現の"^"と"$"が使えるようになりました。

処理の枠組みはできたので、あとはごりごりとパーサの
残りを実装するだけです。

192 : ◆MERIKEN4.k :2011/08/16(火) 09:54:19.77 ID:rCBU7iUe0
もちろんあまり複雑にはできないので、適当なサブセットで
落とし所を見つけるつもりです。今のところ考えているのは
"."と"[]"と"[^]"と"*"と"+"と"()"と"|"ぐらいです。

このパーサの目的は、「可能な組み合わせをすべて出力する」ことなので、
「特定の文字列が街しているか調べる」普通のパーサとは
ちょっと趣が異なっています。

193 : ◆MERIKEN4.k :2011/08/16(火) 10:18:54.47 ID:rCBU7iUe0
「街」ってなんだよ。「マッチ」だよorz

とりあえずあると便利そうなものから実装中。
"[:digit:]"と"[:alpha:]"と"[:alnum:]"と"[:punct:]"を扱えるようにしよう。
http://php-regex.blogspot.com/

194 : ◆MERIKEN4.k :2011/08/16(火) 11:17:19.30 ID:rCBU7iUe0
とりあえず"[: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でコンパイルして本体のメモリを
追加したらもっといけるんだろうな。わくわく…

195 : ◆MERIKEN4.k :2011/08/16(火) 12:02:44.27 ID:rCBU7iUe0
とりあえずこれだけ実装しました。
コードをコピペしてちょちょっと変えただけですけが…

[: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.

196 : ◆MERIKEN4.k :2011/08/16(火) 12:10:07.89 ID:rCBU7iUe0
と、ここまで書いて気づいたんだけど、別に6文字目以降は
CUDAのコードとは関係ないんだから最初にまじめに展開する必要がないような…
そのまま正規表現を残してもいいし、特殊な内部コードを使っても
いいんだよな。まあいいや、これはほかのを実装してから後で考えよっと。

197 : ◆MERIKEN4.k :2011/08/16(火) 13:03:45.85 ID:rCBU7iUe0
'.'とエスケープシーケンス('\\')も終了。

> ^...\.\.\.\.\.\.

これをパターンとして設定すると、こんな具合になります。
このような比較的単純なパターンでも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.

198 : ◆MERIKEN4.k :2011/08/16(火) 14:30:14.56 ID:rCBU7iUe0
エスケープシーケンスじゃなくてエスケープだった… やれやれ。

さて、'*'と'+'の実装も終わりました。ただ、このままだと
展開されるパターンの数が多すぎてまったくおいしくないことが判明。
今のところは次のようなパターンで12連のトリップを指定することぐらいしか
使い道がありません。

^.*$ # 12連


あんまりきれいな実装ではないですが、パターン用の特殊文字を
使うしかないようです。もしこれが実現すれば、次のようなパターンでも
きちんと検索できるはずです。

^[:digit:]*$ # 数字のみ

199 : ◆MERIKEN4.k :2011/08/16(火) 17:21:28.98 ID:rCBU7iUe0
いかんいかん、間違えてるぞ。"^.*$"は12連じゃないや。
'.'を展開してから伸ばすんじゃなくって、'.'を伸ばしてから
展開するんだった。意外に難しいな…

200 : ◆MERIKEN4.k :2011/08/17(水) 01:36:58.38 ID:bPz1YhZq0
そうか、最初にちゃんとトークンを切り出してやらないと駄目なんだな… φ(..)メモメモ

201 : ◆MERIKEN4.k :2011/08/17(水) 13:31:24.34 ID:bPz1YhZq0
せっせと正規表現のパーサを実装中。こんどこそ’.'と'*'への対応が終わりました。
演算子の優先順位を間違えてエライ目に遭いましたが、なんとか直せました。
あとはカッコと'|'と"[]"への対応が済めば、パーサは完成。色々試してみたいので楽しみです。

これさえ終われば、パターンの比較用に特殊文字を実装して最適化したら、
正規表現への対応は完了です。うまくやれば、>>197みたいなケースでも
正規表現を展開せずに済むようになるはずです。今日はもう時間がないから
明日にしようっと。

202 : ◆GikoNekobg :2011/08/17(水) 14:09:06.57 ID:UqJCvdvK0
         (⌒,,⌒)〜っ
        (⌒,_, ,⌒て ,,_,)
         ! ノ U。`yヘ_,、_ノ !
        し|~〜〜 。 ヘ⌒iヽフ
            |! ゚o 。.゚(・ω|・ ) おつかれ
           |! 。o゚ ⊂ ゚ とノ
          |i 。゚ ゚ o .゚|.。|. |
         |i、..゜。。゚ ゚し|'J
.           |,,._二二二_,!
       。゚o

203 :名無しさん@お腹いっぱい。:2011/08/17(水) 22:56:53.96 ID:fNJGb1NY0
後方一致とcpu検索が欲しいです…


204 : ◆Horo/.IBXjcg :2011/08/17(水) 23:04:30.98 ID:YFILQBj70
>>190
UINT8で2^24個というのはそういうことだったのかや w
巨大なビットマップで1byteに1bitは富豪的すぎるかも知れぬの。

しかしビットマップでヒットした場合に別の方法で改めて検索するというのはなかなか面白いの。

BitSlice DESをCUDAで実装すればGTX 260で373Mkey/sかや・・・
crypt()に応用したときにどのくらい速度が出るかも含めて気になるの。

205 : ◆MERIKEN4.k :2011/08/17(水) 23:09:44.60 ID:bPz1YhZq0
>>202
あ、どうもw 美味しくいただきますです。

>>203
後方一致は正規表現の一部としてもうつけちゃったので、次に公開する版で
使えるようになります。最適化してないので前方一致ほどは速くないですけど…
CPU検索はWin32のスレッドの使い方さえわかればすぐに実装できるはずなので、
10桁への対応が終わったら取り掛かります。

206 : ◆MERIKEN4.k :2011/08/17(水) 23:22:46.38 ID:bPz1YhZq0
>>204
あ、みえてたんですね。こんばんわ〜

> >>190
> UINT8で2^24個というのはそういうことだったのかや w
> 巨大なビットマップで1byteに1bitは富豪的すぎるかも知れぬの。
>
> しかしビットマップでヒットした場合に別の方法で改めて検索するというのはなかなか面白いの。

最初は真面目に8bit全部使ってたんですけど、それだと速度的においしくないのでやめましたw
2段構えになっちゃったのは偶然ですけど、ほとんどのケースでO(1)でヒット判定ができるので
結構うまく動いてると思います。

> BitSlice DESをCUDAで実装すればGTX 260で373Mkey/sかや・・・
> crypt()に応用したときにどのくらい速度が出るかも含めて気になるの。

これはほんとうに楽しみです。正規表現を速く終わらせてこっちに取り掛からねば…

207 :名無しさん@お腹いっぱい。:2011/08/17(水) 23:23:19.56 ID:fNJGb1NY0
打倒mty!

208 : ◆MERIKEN4.k :2011/08/17(水) 23:42:17.71 ID:bPz1YhZq0
さっき思いついて、N=1のケースでループ内のグローバルメモリへのアクセスを1つへらしたら
それだけで3M tripcodes/s以上速度が上がりました。やはりグローバルメモリへのアクセスは
なるべく避けたほうがいいみたいですね。

まだ最適化の余地があったのには驚きましが、ターゲットの数が少ない場合はスレッドの
ローカルメモリ(8K)かマルチプロセッサ内の共有メモリ(48K)をつかえば更に高速にできるかもしれません。

209 : ◆MERIKEN4.k :2011/08/17(水) 23:53:09.63 ID:bPz1YhZq0
>>207
> 打倒mty!

10桁でGPU版待て屋を超えるのが目標ですけど、はたしてどうなるんでしょうねw

210 :(の◇の) ◆wordlist..nn :2011/08/18(木) 00:10:41.77 ID:HHH28J5z0 ?DIA(289888)
ゲフォ対ラデだと圧倒的に不利だろ。w
同じハードウェアならともかく。

211 : ◆MERIKEN4.k :2011/08/18(木) 00:15:29.75 ID:U5ajSK5C0
そこを工夫するのが面白いんじゃないですか。
CUDAにも大分慣れてきたし、わかりませんぞw

212 : ◆Horo/.IBXjcg :2011/08/18(木) 00:39:36.35 ID:fntHp7ed0
>>206
8bit全部使うと速度的にというのがよく分からんのじゃが、ビットのテストのコストが意外と大きいということかの?
バイナリサーチやリニアサーチを行う確率が1/(2^24)になるのは結構おいしそうじゃの。

>>208
グローバルメモリはアクセスに数百サイクルかかるのじゃったかの・・・

ローカルメモリ(8KB)はコンスタントメモリの間違いかの?
シェアードメモリはFermiでは48KBみたいじゃが、それ以前のものは16KBみたいじゃから
環境依存を減らすならそのあたりも気をつけたほうがいいかも知れぬの。

2^16分のビットマップを8KiBにしてシェアードメモリに乗せてみるのも面白いかも知れぬの。


213 :(の◇の) ◆wordlist..nn :2011/08/18(木) 00:40:13.86 ID:HHH28J5z0 ?DIA(289888)
OpenCL で作ったトリッパーをゲフォとラデで走らせてみたが、
その差は歴然だった。(同一バイナリでw)
まあ、AMD が OpenCL に力入れてるってのもあるかもしれんが。

あと某外人がやってるのを観察してるんだが、こんな感じだな。
GeForce GTX580 670M
Radeon HD 5770 680M

580でも5770に勝てないレベル

214 : ◆MERIKEN4.k :2011/08/18(木) 01:04:53.61 ID:U5ajSK5C0
>>212
> >>206
> 8bit全部使うと速度的にというのがよく分からんのじゃが、ビットのテストのコストが意外と大きいということかの?

何日か前に試してみたときにはそうでした。勘違いかもしれないので、ビットマップの最適化を
するときにもう一度調べてみます。

> >>208
> グローバルメモリはアクセスに数百サイクルかかるのじゃったかの・・・
>
> ローカルメモリ(8KB)はコンスタントメモリの間違いかの?

per-threadのメモリのことだったんですけどサイズは16〜512Kの間違いでした。

> シェアードメモリはFermiでは48KBみたいじゃが、それ以前のものは16KBみたいじゃから
> 環境依存を減らすならそのあたりも気をつけたほうがいいかも知れぬの。

これは知りませんでした。危ない危ない…

> 2^16分のビットマップを8KiBにしてシェアードメモリに乗せてみるのも面白いかも知れぬの。

これは実に興味深いです。後で試してみます。

215 : ◆MERIKEN4.k :2011/08/18(木) 01:15:08.05 ID:U5ajSK5C0
しかしアーキテクチャのことを知ってるのと知らないのでは大違いですねえ。
GPGPUはかなり奥が深いですね。

216 : ◆MERIKEN4.k :2011/08/18(木) 01:16:05.80 ID:U5ajSK5C0
>>213
> OpenCL で作ったトリッパーをゲフォとラデで走らせてみたが、
> その差は歴然だった。(同一バイナリでw)
> まあ、AMD が OpenCL に力入れてるってのもあるかもしれんが。

うーん、OpenCLのことは何も知らないのでそこらへんはなんとも…

> GeForce GTX580 670M

これだけでたら大喜びですよw

> Radeon HD 5770 680M

これ、実際のところどうなんでしょ? 5770と待て屋の組み合わせだと100Mでてないですけど…
http://yy43.60.kg/test/read.cgi/tripageruo/1178031498/900n
http://yy43.60.kg/test/read.cgi/tripageruo/1178031498/955n

217 : ◆Horo/.IBXjcg :2011/08/18(木) 01:58:02.96 ID:fntHp7ed0
>>213
OpenCLは極限まで性能を引き出そうとすれば、アーキテクチャ毎にコードを書かなければならないとかいう噂もあるからの・・・

演算性能の理論値的にはRadeonの方が上みたいじゃが、良くも悪くもAMDは理想が高くて
Radeonのアーキテクチャもまた変更になるという話もあるからの。
ハッカーレベルの者やチャレンジャー以外は、CPUとGPUの開発環境レベルでの統合が落ち着くまで様子見というのも少なくないかも知れぬ。

>>214
per-threadというとローカルメモリじゃと思うが、ハードウェア的にはグローバルメモリと同じで
オフチップでグローバルメモリと変わらない、というか全スレッドで共有できない分
1スレッドが使えるメモリが減ってデメリットばかりの気もするの。

>>216
10桁版ならcrypt()じゃから100M出れば十分というか、それでも凄いと思いんす。

218 : ◆MERIKEN4.k :2011/08/18(木) 02:25:48.72 ID:U5ajSK5C0
>>217
> per-threadというとローカルメモリじゃと思うが、ハードウェア的にはグローバルメモリと同じで
> オフチップでグローバルメモリと変わらない、というか全スレッドで共有できない分
> 1スレッドが使えるメモリが減ってデメリットばかりの気もするの。

なるほど… さっきN=1のケースで速くなったのは、配列へのアクセスが無くなった
せいかもしれません。もうちょっと調べてみます。

219 : ◆MERIKEN4.k :2011/08/18(木) 03:07:35.54 ID:U5ajSK5C0
先ほど"[]"の実装がようやく終わりました。
例えば"[Nn][Uu][Ll][Pp][Oo]"と指定すると、"nullpo"や"NULLPO"や"NuLuPo"や"nullPO"に
マッチします。ちゃんと'-'や'^'での文字範囲の指定もできます。
ようやくこれで'*'や'+'の使いやすくなりました。

220 :(の◇の) ◆wordlist..nn :2011/08/18(木) 07:51:17.93 ID:HHH28J5z0 ?DIA(289888)
>>213 は SHA-1 での値。

鳥屋先生の皮算用wでは、SHA-1 なら DES の 5 倍は速度が出る、らしい。w
まあそのスレ見てんなら知ってるだろうけど、
ttp://yy43.60.kg/test/read.cgi/tripageruo/1274911652/305
って状態だが。


OpenCL で作ったヤツは、同一バイナリで CPU でも動くんだがこれがやたらと速い。
たぶん、俺がなんかミスってるというオチの悪寒がするが。w

221 : ◆MERIKEN4.k :2011/08/18(木) 08:33:28.32 ID:U5ajSK5C0
>>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の環境もしらべてみよう。
単一のバイナリでどの環境でも動けば最高だけど、実際どうなんだろう…

222 : ◆MERIKEN4.k :2011/08/18(木) 09:43:30.28 ID:U5ajSK5C0
頑張って'|'演算子を実装。あとは括弧の処理を書き終わればパーサは完了です。
なんかここ最近で一番頭を使った気がするw

223 : ◆MERIKEN4.k :2011/08/18(木) 10:49:09.09 ID:U5ajSK5C0
デキタ━━━━(゚∀゚)━━━━ッ!!

ようやく正規表現のパーサが出来ました。色々試してみたけど、かなり強力です。
例えば、

^([Hh]oge[Mm]oge|HOGEMOGE)[:digit:]*$

と指定してやると、”◆hogemoge1418"や"◆HOGEMOGE3241"や"◆HogeMoge9658"などに
ヒットします。かなり使いでがありそう…

224 : ◆MERIKEN4.k :2011/08/18(木) 11:01:52.49 ID:U5ajSK5C0
あと、便利な機能としてヒットするまでの平均時間を表示するように
しました。

> 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

225 : ◆MERIKEN4.k :2011/08/18(木) 11:29:03.32 ID:U5ajSK5C0
さて、後は最適化を残すのみです。
正規表現の展開によるパターン数の指数関数的増加(>>194>>197)を
抑えるために、内部用の特殊文字を導入したいのですが、
この変更ではかなりプログラムの内部構造に手を入れることになるので
ちと心配です。まあでもいまさらだからいいかw

226 : ◆MERIKEN4.k :2011/08/18(木) 15:13:19.78 ID:U5ajSK5C0
とりあえず数字の分だけ終了。"^[: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.

227 : ◆GikoNekobg :2011/08/18(木) 19:26:27.94 ID:R3Vgwkmh0
∧_∧
( ´・ω・)
( つ  O
と_)_) 旦>>226

228 : ◆MERIKEN4.k :2011/08/19(金) 04:45:58.58 ID:WHpJPhX30
>>227
|ヘ⌒ヽフズズー
| ・ω・)
|つC□)

ありがとうございます。ほかの特殊文字も追加したら
大絶賛エンバク中ですw 今日中に治るといいなあ。

229 : ◆MERIKEN4.k :2011/08/19(金) 04:48:12.74 ID:WHpJPhX30
でもこれ、ヒット率を理論値と較べる機能がついてなかったら
完全にバクを見逃してたよな。つけといてよかった。
理論値はかなり真面目に計算してるので、またぜひコードを
みてやってください。

230 : ◆MERIKEN4.k :2011/08/19(金) 05:01:53.28 ID:WHpJPhX30
特殊文字を比較してるルーチンでとんでもない打ち間違いを発見。
こりゃヒット率が落ちるわけだ。

で、バクをひとつ直したと思ったら今度は謎のスピード低下。
すんなり行くかと思ったけど、やはり一筋縄ではいかないですね。

231 : ◆MERIKEN4.k :2011/08/19(金) 05:10:03.61 ID:WHpJPhX30
スピード低下は勘違いでしたw いろいろ実験してる時にGPUに
無茶させすぎてるせいかpower throttlingがかかりまくりです。
GPU-Zの特殊オプションでいちいち解除してるんですけど
メンドクサイので、GUIをつけるときには解除する機能を
つけたいです。

232 : ◆MERIKEN4.k :2011/08/19(金) 05:40:35.71 ID:WHpJPhX30
GUIアプリならPCを使ってない時だけフルスピードで走らせるとか、
色々アイディアはあるんですけど… とりあえず必要な機能を
揃えてからですね。

233 : ◆MERIKEN4.k :2011/08/19(金) 12:16:14.90 ID:WHpJPhX30
今日は仕上げとして展開されたパターンのコリジョンを処理するコードを書きました。
特殊文字を使うと効率はよくなるのですが、次のような正規表現の場合に困った事になります。

NUL.PO
NULLPA

この場合どちらが先になるかわからないので、ヒット判定の時のCPU側のbinary searchの
ルーチンが正しく動作しません。これは正規表現に対応していないオリジナルにはなかった
問題ですが、'.'を展開するルーチンを組み込んで解決しました。思わないところで問題が
でてくるものですが、うまくいったと思います。

234 : ◆MERIKEN4.k :2011/08/19(金) 12:25:57.34 ID:WHpJPhX30
というわけで、正規表現の対応はこれで完了しました。
前方一致でない検索で極端に遅くなるケースが確認されましたが、
この問題への対処はランタイムでの最適化に対応するまで後回しにする予定です。
これから新しいバージョンのパッケージを用意するのでちょっと待っていて下さい。

235 : ◆GikoNekobg :2011/08/19(金) 13:09:50.76 ID:3wVJoHeW0
  ( ゚д゚ ) ガタッ
  .r   ヾ
__|_| / ̄ ̄ ̄/_
  \/    /

236 : ◆MERIKEN4.k :2011/08/19(金) 14:24:37.03 ID:WHpJPhX30
というわけで新しいバージョンをうpしました。開発版のバージョン0.02bが
それにあたります。(安定版の0.01は0.01bとまったく同じです)
これまで書いた通り、正規表現への対応等、かなり使い勝手が
よくなっています。使っていただけたら動作報告をしていただけると
非常に嬉しいです。

http://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch

>>235
お待たせしましたw ぜひ楽しんでくださいな。

237 : ◆GikoNekobg :2011/08/19(金) 14:38:21.39 ID:3wVJoHeW0
ども〜

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"にお願いします。

239 : ◆GikoNekobg :2011/08/19(金) 14:46:35.93 ID:3wVJoHeW0


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氏がおっしゃられたように条件文とグローバルメモリへの
アクセスは相当なペナルティになるようです。ループ内でグローバル
メモリにアクセスしている場所は数箇所あるので、シェアードメモリを
うまく使ってやればまだまだ最適化の余地はありそうです。

242 : ◆GikoNekobg :2011/08/19(金) 16:07:17.38 ID:3wVJoHeW0
小一時間ほどマワシテミタ

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すらいかないので、
こいつをシェアードメモリに移してやれば高速化できるかもしれません。

もうこのプログラムのことは手に取るようにわかるようになったので、
もう一回見直してみたらかなり無駄が省ける気がします。楽しみだ…

245 : ◆GikoNekobg :2011/08/19(金) 16:32:52.36 ID:3wVJoHeW0
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 ?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 ?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 ?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
新しいバージョンをうpしました。

CUDA SHA-1 Tripper MERIKEN's Branch 0.02 Beta 2
http://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch

0.02 Beta 1にあったかなり大きなバグをいくつか修正したので、
Beta 1をダウンロードされた方もぜひこちらを再度ダウンロード
してください。このバージョンに特に問題がなければ、これを
正式版にする予定です。

256 :名無しさん@お腹いっぱい。:2011/08/20(土) 12:18:03.11 ID:SJuWkq6G0
8400GS
"TEST/"のみ
7.7MTrips/sec

動いた><

257 :名無しさん@お腹いっぱい。:2011/08/20(土) 12:19:02.65 ID:SJuWkq6G0
あ、言い忘れ
おつですおつです><

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
お、あったあった。

> CPU検索ルーチンを実装。Core i7 2600K で1コアあたり
> 16MTrips/sくらいの検索速度(2タゲの場合)。
http://toki.2ch.net/test/read.cgi/qa/1299965026/168

ちょっとこれ、うちのと違いすぎる…
どういうこっちゃ。もうちょっと調べてみよう。

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
64bit版のはすぐに見つかりました。
http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1/

とりあえずこれはとっておいて、32bit版のを探そう。

270 : ◆MERIKEN4.k :2011/08/20(土) 21:43:30.67 ID:yyJEk2z60
SHA-1のSSE2による実装は首尾よく見つかりました。
http://trac.aircrack-ng.org/svn/trunk/src/sha1-sse2.S
ライセンスもPublic Domainだしちょうどいいや。
しかし、これをVisual C++のコードに組み込むのは
一手間かかりそうだな…

271 : ◆MERIKEN4.k :2011/08/21(日) 08:25:49.77 ID:0aXAtS7W0
>>269-270のコードをそのまま使うのは敷居が高いので、
Cのコンパイラから直接SSE2の命令を使うことを検討中。

MMX, SSE, and SSE2 Intrinsics
http://msdn.microsoft.com/en-us/library/y0dh78ez(v=VS.90).aspx

この機能を使って何とかアセンブラを使わずに高速化できないかなあ。

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 ?DIA(289888)
横から口出ししていいもんかどうかと思いつつ。

-x 4 とか減らしてどうする。
増やそうぜ。w
つか、今見たら16までにしてるけど、明らかに小さすぎるな。

281 :(の◇の) ◆wordlist..nn :2011/08/21(日) 18:27:29.42 ID:DGWxIzoa0 ?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に比べると
まだまだですね。

287 :名無しさん@お腹いっぱい。:2011/08/22(月) 07:00:02.24 ID:X9ASZ06K0
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
というわけで新しいバージョンです。

CUDA SHA-1 Tripper MERIKEN's Branch 0.03 Beta 1
http://www.meriken2ch.com/programming/cuda-sha-1-tripper-merikens-branch

変更点は以下の通りです。

・CPU検索に対応。対応するGPUがなくても動作します。GPUとCPUを両方使いたい
 場合はオプションで"-c -g"と指定してください。
・"sm_21"をつけてコンパイルしたので、GTX 460では速くなっているはずです。
・"-x"オプションの上限を32まで増やしました。

ぜひお試しください。

294 : ◆MERIKEN4.k :2011/08/23(火) 01:51:01.25 ID:8b4qHmgQ0
さっき気づいたんですけど、書き込むときにage続けてましたね。
失礼しました。

295 : ◆MERIKEN4.k :2011/08/23(火) 02:31:18.99 ID:8b4qHmgQ0
さて、下ごしらえは全部済んだので、いよいよこれから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.

297 : ◆MERIKEN4.k :2011/08/23(火) 08:03:34.11 ID:8b4qHmgQ0
>>296
朝早くから有難うございます。意外にGPUのほうは伸びないですねえ。
"-x 16"とかそれ以上にするといいかもしれません。

298 : ◆MERIKEN4.k :2011/08/23(火) 08:23:34.00 ID:8b4qHmgQ0
さっきからCUDA検索用にもうひとつCPUスレッドを追加したのですが、
思わぬところで時間を取られてえらい目にあいました。ともあれ、
これのおかげでプログラムの構造が大分すっきりしました。
メインのスレッドは他のスレッドがせっせと働いてるのを
のんびりと待って、たまに結果を表示するだけです。

副作用として、将来的に複数のグラボに対応するのも容易になりました。
予算ができたらぜひもう1枚グラボを追加したいところです。
マザボと電源も交換になるのでえらい出費ですが…

299 :名無しさん@お腹いっぱい。:2011/08/23(火) 12:50:14.74 ID:/UGB9NTfP
>>298
正規検索もいいけど、

>>124を参考にGPU検索は cudaTripper12Wiz7 より20%以上高速化。できれば倍ほど高速化。
CPU検索は、少なくとも cudaTripper12Wiz7 よりは高速化。

を、めざしてみてょ(*‘ω‘ *)
楽しみにしています

300 : ◆MERIKEN4.k :2011/08/23(火) 12:54:55.76 ID:8b4qHmgQ0
例のごとくGPLのコードを拾ってきてコンパイルしたら
トリップコードへの変換はうまくいきました。
https://aff4.googlecode.com/hg/libreplace/crypt.c

問題はこれからだけど、やっぱりSHA-1よりずいぶん計算量が多そうです。
まあなんとかなるかな…

301 : ◆MERIKEN4.k :2011/08/23(火) 13:06:49.88 ID:8b4qHmgQ0
>>299
うはw これはハードルが高いwww
cudaTripper12Wiz7は良い目標になっているので本当にありがたいです。
10桁トリップ対応の後は、ランタイムでの診断を含めた全体的な最適化に
取り組む予定なので、何とか超えられるように頑張ります。

302 : ◆MERIKEN4.k :2011/08/23(火) 13:30:23.61 ID:8b4qHmgQ0
素のcryptを使って試しに実装してみたら、CPU 1スレッドで300K tripcodes/sしかでませんでしたw
こりゃ先が長いわ…

303 :名無しさん@お腹いっぱい。:2011/08/23(火) 14:55:45.64 ID:/UGB9NTfP
>>302
bit-sliced DESを使わなきゃ速度でんよ(*‘ω‘ *)

『CUDAによるbit-slicedDESの実装』みたいな論文があるから読んでみれ(*‘ω‘ *)

304 : ◆MERIKEN4.k :2011/08/23(火) 15:30:25.07 ID:8b4qHmgQ0
ははあ、なるほどなるほど。
http://www.darkside.com.au/bitslice/
これなら何とかなりそうな感じですね。
この大量にある変数を、なんとかレジスタとシェアードメモリに
押し込めればいいわけだ。光明が見えてきました。ありがとうございます!

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)

306 :名無しさん@お腹いっぱい。:2011/08/23(火) 19:22:33.89 ID:wST+kV3E0
readme読んだだけではオプション指定の方法が分りませんorz

教えてエロイ人

307 : ◆MERIKEN4.k :2011/08/24(水) 06:00:22.99 ID:Fcgoq/qj0
>>305
わざわざ試していただいて助かります。やっぱり速くなってますねえ。
これを見てからまさかと思って自分のPCで試してみたら、"-x 16"よりも
"-x 20"のほうが明らかに速いことが判明。前試してみて"-x 16"が
一番速かった( >>26 )はずなんですけど、何が起こったのやらorz

というわけで"-x"オプションの上限を可能なかぎり上げて色々試してみたところ、
GTX 580では"-x 48"が一番速いことがわかりました。間違いかと思ったけど
ヒット率もちゃんと安定してるし、問題はないようです。>>281のお告げが無かったら
勘違いしたままでした。ありがたや、ありがたや。

308 : ◆MERIKEN4.k :2011/08/24(水) 06:04:23.35 ID:Fcgoq/qj0
>>306
> readme読んだだけではオプション指定の方法が分りませんorz
>
> 教えてエロイ人

普通に使う分に必要なのは"-x"だけです。"-x 16"とか”-x 32"というふうに、
マルチプロセッサあたりのブロック数を指定します。数字を変えて試してみると
よいようです。

後いろいろ付け足したのですが、まだ暫定的なものなので、次のバージョンをうpするときに
まとめます。しばしおまちを。

309 : ◆MERIKEN4.k :2011/08/24(水) 06:11:38.05 ID:Fcgoq/qj0
さっきちょこっと最高速の測定をしてみたらとんでもない数字が出てるぞ。
用事があるので、あとで試してみよう。実に楽しみだ…

310 : ◆MERIKEN4.k :2011/08/24(水) 10:08:08.64 ID:3qnslGw/0
OCしながら最高速の測定は時間がかかるので、後の楽しみにとっておきます。

bitslice DESの概要はわかったのですが、saltの部分だけがどうしてもわからない…
現在UFC-cryptのソースを見ながら思案中です。

311 : ◆MERIKEN4.k :2011/08/24(水) 10:24:17.54 ID:3qnslGw/0
ここがキモらしいということはわかりました。


----

/*
* 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);

312 : ◆MERIKEN4.k :2011/08/24(水) 10:25:32.59 ID:3qnslGw/0
あとこれも。

----

----

/*
* 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;
}
}

313 : ◆MERIKEN4.k :2011/08/24(水) 10:34:33.51 ID:3qnslGw/0
これも一応張っておこう。

FIPS PUB 46-3, DATA ENCRYPTION STANDARD (DES)
http://www.ii.uib.no/~osvik/des/fips46-3.pdf

これがうまくいって、変数を全部レジスタとシェアードメモリに
押し込めることができたらかなりスピードでそうだよな…
ちょっと疲れたのでいったん休憩します。

314 : ◆MERIKEN4.k :2011/08/24(水) 14:33:55.85 ID:3qnslGw/0
これ、saltの値がいたるところで使われていますねえ。
bitslice DESがcryptの実装に使えるのはわかってるんですけど、相当手ごわそうです。
他の実装を探してみたんですけど、見つかったのは"John the Ripper"だけで、これが
かなり複雑で容易に理解できそうにありません。ま、他の部分の最適化を進めながら
のんびりやるしかないか…

315 :名無しさん@お腹いっぱい。:2011/08/24(水) 15:34:20.50 ID:h65DTT91P
> bitslice DESの概要はわかったのですが

わかってない気がする(*‘ω‘ *)…

316 : ◆MERIKEN4.k :2011/08/24(水) 16:17:15.34 ID:3qnslGw/0
いや、ほんとうにわかりましたからw FIPSの仕様書( >>313 )と
Bitslice DESのソース( >>304 )が一対一で対応しているのはわかったので、
以外に早く謎が解けるかもしれません。要はunsigned longのビット長の
数のケースを同時に処理してやることで効率を稼いでるだけで、
やってることは同じですからね。 

Ln = Rn-1
Rn = Ln-1 ^ f(Rn-1,Kn)

上の演算が行われた直後にsaltに基づく値と排他的論理和をとればいいはずです。
上の処理は、25回行われるDESのイテレーション1回につき16回繰り返されるので
結構な回数ですが、コスト的にはそれほどでもないでしょう。

317 : ◆MERIKEN4.k :2011/08/24(水) 16:35:20.12 ID:3qnslGw/0
とりあえずUFC-cryptのsaltの処理を無効にして、Bitslice DESと同じ結果が出るかどうか
ためしてみることにします。これがうまくいけば、あとはBitslice DESにsaltの処理を
加えるだけです。salt用のテーブルはUFC-cryptのものを流用すればいいはずですが、
はたしてどうなることやら…

318 :名無しさん@お腹いっぱい。:2011/08/24(水) 17:48:09.06 ID:h65DTT91P
>>316
(*‘ω‘ *)単芝はやめとこうよ・・・

319 : ◆MERIKEN4.k :2011/08/24(水) 17:54:38.48 ID:3qnslGw/0
あ、この単芝は普段から使いまくってるだけで他意は全く無いです。
お気になされるのでしたらこのスレでは使うのはやめておきます。

320 :名無しさん@お腹いっぱい。:2011/08/24(水) 20:02:12.00 ID:h65DTT91P
>>319
(*‘ω‘ *)やめといたほうがいいと思うね
いまだに(藁 とか書く人みたいに感じる

(*‘ω‘ *)好きで使うならもちろん勝手だけど

321 : ◆MERIKEN4.k :2011/08/25(木) 03:45:11.28 ID:0UN03WJb0
そうですねえ… 単芝は昔から使ってたし、ただ単に好きなだけなんですよ。
昔草の根BBSとかで「(笑)」とか打ってたのの代わりです。
あんまり気にしないでくださいな。

さて、Bitslice DESを試そうと思ったのですが、なかなか思うように動いてくれません。
unsigned long k[56]の最初のビットに56bitのキーをアンロールして
p[]とc[]はゼロクリアしdeseval()を呼び出してやれば良いと思ったんだけど、ちがうのかな…

322 : ◆MERIKEN4.k :2011/08/25(木) 04:00:14.50 ID:0UN03WJb0
しかしこの作業、思った以上の手間になりそうだな。
SHA-1とは比較にならない難敵ですね。
面白そうだったからほとんど何も考えずに始めたけど、無知とは恐ろしいw

今後の予定としては、Bitslice DESに取り組みつつ、既存のルーチンで10桁トリップへの
対応を進めながら同時に最適化もする、ということにしたいと思います。そろそろ
本業が忙しくなってくるけど、このプロジェクトは実に楽しいのでぜひ長く続けたいですね。

323 : ◆MERIKEN4.k :2011/08/25(木) 05:18:11.37 ID:0UN03WJb0
ははあ、どうやらc[]に特定の値を代入しとかないと、このs-box circutsは動かないんだな。
自動的に生成されてるから、かなり徹底して最適化がされてますね。
PS3用のcryptのコードもざっと見てみましたけど、s-box circuitsはPerlで
自動生成されています。

Breaking UNIX crypt() on the PlayStation 3
http://www.zorinaq.com/talks/breaking-unix-crypt.pdf
http://www.zorinaq.com/cell-bf/

あと、これまではKwan氏のゲート回路( >>304 )が最速とされてたみたいですけど、
ごく最近になって記録が塗り替えられたようです。

17% Smaller DES S-box Circuits Found
http://it.slashdot.org/story/11/07/01/1734213/17-Smaller-DES-S-box-Circuits-Found

こっちもあとで調べてみよう。

324 : ◆MERIKEN4.k :2011/08/25(木) 09:28:12.61 ID:0UN03WJb0
…なんか盛大な勘違いしていたけど、Bitslice DESのdesevalってあらかじめ
設定されたp[], k[], c[]の組み合わせが正しい場合にnon-zeroを返す
関数だったんですね。「なんでc[]に結果が入らねーんだ!」って
ブチギレてたけど、main.cを見てようやく間違いに気づきましたw
resultに代入されてる値を見たときに気づくべきだった…

これを実際にDESで暗号化する関数にかえるためには
resultをいじってる部分をパーミュテーションに変えれば
いいんだな。よし、希望の光が見えてきたぞ。

325 : ◆MERIKEN4.k :2011/08/25(木) 10:28:15.98 ID:0UN03WJb0
ちょっと思いついて"salt DES 挙動"でググったら、次の記述を発見。

> salt は DES アルゴリズムに対し、16777216 通りまたは 4096 通り (つまり、24
> ビットまたは 12 ビット) 中の 1 通りという不規則性を導入します (salt の
> ビット i が設定されている場合、DES E-Box 出力中のビット i とビット i+24
> とが交換されます)。
http://www.jp.freebsd.org/cgi/mroff.cgi?sect=3&subdir=man&lc=1&cmd=&dir=jpman-7.2.2/man&man=crypt

これでようやく最後の謎が解決しました。これならばdeseval()に組み込むのも
容易でしょう。

326 :名無しさん@お腹いっぱい。:2011/08/25(木) 14:42:18.89 ID:G2rvt1ph0
単芝って何の事かと思ったら文末のwの事か
嘲笑的な語句は専ブラ設定でレス消去対象にしてるので、作者のレスの1/3位が消えてるわ

327 : ◆MERIKEN4.k :2011/08/25(木) 14:51:43.78 ID:0UN03WJb0
ようやく>>304のBitslice DESのコードの動作確認ができました。
次のリンク先のDESのtextをビットにばらして引数として渡してやると、
ちゃんとciphertextが得られます。

http://www.rsa.com/rsalabs/node.asp?id=2105

後はsaltの処理を加えてこれを25回イテレートしてやればcryptと同等になるはずです。
ここまでまる二日かかりましたが、あともう少しでめどが立ちます。
残りはまた明日やろう。

328 : ◆MERIKEN4.k :2011/08/25(木) 14:54:00.82 ID:0UN03WJb0
>>326
うーん、単芝なんてしょっちゅう見かけるので特に気にせずに使ってましたけど…
この板は真面目な方が多いんでしょうねえ。やっぱりこのスレで使うのはやめておこう。

329 :名無しさん@お腹いっぱい。:2011/08/25(木) 15:12:32.93 ID:G2rvt1ph0
まあ、それを指摘したレスもAAと消去対象レスへのレスで引っ掛かって消去されてるんだけどね
乱暴な語句や煽り・荒らしに使われる可能性のあるAAは大体消去対象なので、
このスレだと4割以上のレスが消えてる

330 : ◆GikoNekobg :2011/08/25(木) 17:43:21.41 ID:sB9H2U6s0
凄すぎ。


http://www.asus.co.jp/Graphics_Cards/NVIDIA_Series/ENGTX580_DCII2DIS1536MD5/

331 : ◆GikoNekobg :2011/08/25(木) 17:49:30.55 ID:sB9H2U6s0
こっちだ・・すごい値段。

http://pc.nikkeibp.co.jp/article/news/20110813/1034862/

332 : ◆MERIKEN4.k :2011/08/25(木) 21:19:37.64 ID:0UN03WJb0
>>329
> まあ、それを指摘したレスもAAと消去対象レスへのレスで引っ掛かって消去されてるんだけどね
> 乱暴な語句や煽り・荒らしに使われる可能性のあるAAは大体消去対象なので、
> このスレだと4割以上のレスが消えてる

なるほどなるほど。今後は気をつけます。

333 :名無しさん@お腹いっぱい。:2011/08/25(木) 21:23:09.90 ID:0zjo4pG70
ああ、俺も単芝って何かと思ってたわ^^

334 : ◆MERIKEN4.k :2011/08/25(木) 21:25:01.42 ID:0UN03WJb0
>>331
> こっちだ・・すごい値段。
>
> http://pc.nikkeibp.co.jp/article/news/20110813/1034862/

それ、興味があって調べてたんですけど、さすがにその値段では手が
でないですねえ。性能的にはOCした2-way SLIの580と変わらないから、
5万以上割高ですからね。

335 : ◆MERIKEN4.k :2011/08/25(木) 21:30:31.36 ID:0UN03WJb0
これはJavaによるcryptの実装ですけど、
こちらのほうがもっとわかりやすいですね。
http://www.dynamic.net.au/christos/crypt/Password.txt

336 : ◆MERIKEN4.k :2011/08/25(木) 22:12:40.71 ID:0UN03WJb0
Bitslice DESのソースを整形したら、FIPSの仕様書(p. 13)のE BIT-SELECTION TABLEに
きれいに対応していました。同じページにある"Figure 2. Calculation of f(R, K)"の
左上にあるまるで囲まれた"E"が"E Box"のようです。これであとはごりごりと
コードを書くだけのはず…

337 : ◆MERIKEN4.k :2011/08/26(金) 15:37:25.29 ID:Rc4PKbfx0
Bitslice DESを改造したものとUCB-cryptの結果を比べてるのですが、
どうも思ったように一致してくれません。LとRの値がいっしょになってくれないと
いけないんだけど、おかしいなあ。テストデータではsaltを".."に設定してあるから
挙動はおなじになるはずなんだけど…

338 : ◆MERIKEN4.k :2011/08/27(土) 05:51:33.04 ID:0IxzL9Yn0
 UCB-cryptのソースがどうにもわかりにくかったので、
libdesのcrypt()もコンパイルしてみました。

http://ftp.vim.org/security/coast/libs/libdes/

関数定義が古いK&Rのスタイルだったので修正が必要でしたが、
大した手間もなくちゃんと動きました。John the Ripperのも
これぐらい簡単に動いてくれればよかったんですけど、
まあ文句を言っても始まりません。早速動作を検証してみよう。

339 : ◆MERIKEN4.k :2011/08/27(土) 05:57:04.79 ID:0IxzL9Yn0
しかしsaltのエンコーディングがBase64でないのには驚きました。
最初は"AA"に設定してたのですが、saltbitsが0x000にならなかったので
ようやく気づいたわけですが…

340 : ◆MERIKEN4.k :2011/08/27(土) 06:06:56.79 ID:0IxzL9Yn0
libdesのcrypt()の速度を測ってみたけど、じゃっかん
UCF-cryptのほうが速いという結果に。
…やっぱりこりゃなんとしてもBitslice DESをつかってcrypt()を
実装するしかないですね。

341 : ◆MERIKEN4.k :2011/08/27(土) 06:56:32.10 ID:0IxzL9Yn0
しかしlibdesのソースも随分わかりにくいな〜
スピードのためだから仕方が無いとは言え、これではアルゴリズムがわかりにくすぎる。
いっそのことcrytographyの教科書を一冊買おうかしらん。

342 : ◆MERIKEN4.k :2011/08/27(土) 07:14:38.27 ID:0IxzL9Yn0
文献をあさってたら、crypt()の実装の詳細を扱ってる論文を見つけました。

Efficient Password and Key recovery using Graphic Cards
http://www.emsec.rub.de/media/crypto/attachments/files/2011/03/DA_Schober.pdf

p. 18から始まる"4.1.2. The UNIX crypt Algorithm"に詳しいことが載っています。
こりゃ実装に入る前にもうちょっと色々調べたほうがいいかもしれません。
というか、この人すでにCUDAでBitslice DESの実装をしたみたいなんだけど、
ソースは手に入らないのかな…

343 : ◆MERIKEN4.k :2011/08/27(土) 07:20:33.48 ID:0IxzL9Yn0
とりあえず上の論文で紹介されてた教科書のKindle版をぽちりました。

Bruce Schneier. Applied Cryptography - Protocols, Algorithms, and Source
Code in C (2nd Ed.). Wiley, 1996.
http://www.amazon.com/dp/B000SEHPK6/

しかし便利な世の中になったもんですね。お昼を食べたら早速読んでみよう。

344 : ◆MERIKEN4.k :2011/08/27(土) 08:27:49.95 ID:0IxzL9Yn0
>>343の教科書には>>342より詳しい記述はありませんでしたorz
まあこの本は手元においておいてもいいから無駄にはなりませんけど、
それにしても弱ったな… 自分はDESがどのようにcrypt (3)で使われてるか
知りたいだけなのに。ひょっとしたらkeyのエンコーディングを間違えてるのかな。
ちょっと調べてみよう。

345 : ◆MERIKEN4.k :2011/08/27(土) 08:39:39.24 ID:0IxzL9Yn0
この本にcryptDESの詳細が載ってるらしいんだけど、すぐ手に入らないし
高いからまようなあ。これは最後の手段としてとっておこう。

A. Menezes, P. van Oorschot, and S. Vanstone. Handbook of Applied Cryp-
tography. CRC Press, 1996.
http://www.amazon.com/dp/0849385237

346 : ◆MERIKEN4.k :2011/08/27(土) 08:48:45.75 ID:0IxzL9Yn0
あと>>342の論文では次の文献がリファレンスとして挙げらてました。
とりあえずUNIXのオリジナルのソースを見てみよう。

[Cryp] cryptDES C souce from 7th Edition Unix, provided by Henry Spencer http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7, found via http://google.com/codesearch/p#118goTAkg2o/usr/src/libc/gen/crypt.c

[CryM] Linux Programmer’s Manual, CRYPT(3) man-page http://www.kernel.org/doc/man-pages/online/pages/man3/crypt.3.html

[MT79] R. Morris and K. Thompson. Password Security: A Case History. Bell Laboratories, 1979.

347 : ◆MERIKEN4.k :2011/08/27(土) 08:52:55.95 ID:0IxzL9Yn0
よしやった! このコードはものすごい綺麗です。さすがにオリジナルなだけはある。
これなら大丈夫でしょう。

http://google.com/codesearch/p#ZWtxA-fyzBo/UnixArchive/PDP-11/Distributions/research/Henry_Spencer_v7/v7.tar.gz%7C118goTAkg2o/usr/src/libc/gen/crypt.c

348 : ◆MERIKEN4.k :2011/08/27(土) 10:14:01.87 ID:0IxzL9Yn0
うーん、そのままコンパイルしただけじゃ動かないな、これ。
やっぱさすがに古すぎたか… コードは一番すっきりしてるだけに残念。
しかしこれからどうしようかな。

349 : ◆MERIKEN4.k :2011/08/27(土) 11:44:07.16 ID:0IxzL9Yn0
完全に煮詰まったので、放ったらかしにしてた"John the Ripper"のBitslice DESのコードを
もう一回引っ張り出していじってたら、今度はなんとちゃんと動いているみたいです。
DES_BS_cmp_all()とDES_BS_cmp_one()に正しい変換結果を渡してやると
ちゃんとTRUEが返ってきます。これはひょっとしたらひょっとするかもしれんぞ…

350 : ◆MERIKEN4.k :2011/08/27(土) 12:28:29.96 ID:0IxzL9Yn0
DES_bs_all.B[]に変換結果が入ってるのは分かるんだけど、
DES_BS_cmp_all()とDES_BS_cmp_one()で何をやってるのかさっぱりわかりません。
コードも#ifdefの嵐だし、よくこんなのメンテナンスできるよな…

351 : ◆MERIKEN4.k :2011/08/27(土) 14:25:49.96 ID:0IxzL9Yn0
色々たどってみたら、DES_bs_all.B[]の中身は予想以上に最適化されて複雑なもの
だということが判明。DESの最後のパーミュテーション(inverse initial permutation)を
行わずに、検索するciphertextにinitial permutationをかけて比較してたのには驚きました。

コメントを見ても「変数が全てキャッシュに乗るように
1つの構造体に全部まとめておいたから勝手にばらすんじゃねーぞ」とか、
「最適化されたコードに支障が出るから、構造体のメンバーの順番は入れ替えないように」
とか恐ろしげなことが平気で書かれています。

とにかくJohn the RipperのBitslice DESのコードが自機で確実に動いているという
証拠はつかんだので、続きはあしたやろうっと。一応速度だけ計測してみたら、
UCB-cryptの3倍ぐらい出たのでかなり楽しみです。

352 : ◆MERIKEN4.k :2011/08/27(土) 14:47:51.97 ID:0IxzL9Yn0
■今日のまとめ(2011年8月26日)
・オリジナルのBitslice DESのコードをcrypt (3)に対応させる作業は難航。
・その代わり、John the RipperのBitslice DESのコードを自機で動かすことに成功。

■明日の予定・目標
・John the Ripperの内部データを実際のトリップに変換する。

それではまた。

353 : ◆Horo/.IBXjcg :2011/08/27(土) 20:25:48.80 ID:2gJ7DKwQ0
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 ?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 ?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)
てな感じですね。というか、ゲフォはレジスタが厳しい!

356 : ◆MERIKEN4.k :2011/08/28(日) 00:52:35.63 ID:9nceMSa20
>>353
お疲れさまです〜 こちらでも動作確認しました。ソースを見ましたけど、
SHA-1の部分を差し替えられたんですね。詳しい報告はまた後でさせて頂きます。

357 : ◆MERIKEN4.k :2011/08/28(日) 00:57:48.07 ID:9nceMSa20
>>355
ラデのレジスタの数はブロック単位でとんでもないことになってるみたいですね。
実際1スレッドあたりどれぐらい使えるのか、非常に興味があります。
Bitslice DESの移植するときにはCUDAだとShared Memoryをつかわないと
かなり厳しいことになりそうなので…

それはそうと、さっき初めてComputer Visual Profilerの存在に気づいて
いま動かしてるんですけど、これって物凄い重いですね。結果が実にたのしみです。

358 : ◆QwF3QYjuZk :2011/08/28(日) 03:04:19.82 ID:9nceMSa20
test

359 : ◆MERIKEN4.k :2011/08/28(日) 03:59:02.70 ID:9nceMSa20
トリップテストを誤爆してしまった…
でもとにかく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検索に対応させるのがさきですけど…

360 : ◆GikoNekobg :2011/08/28(日) 06:15:52.70 ID:K8vphbg60
【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

361 : ◆MERIKEN4.k :2011/08/28(日) 14:29:19.22 ID:9nceMSa20
>>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

362 :名無しさん@お腹いっぱい。:2011/08/29(月) 02:19:28.34 ID:xoK0EyFD0
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の勉強も兼ねてこっちの並列化を試みる。

363 : ◆MERIKEN4.k :2011/08/29(月) 02:51:25.30 ID:G09yQQGf0
>>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

364 : ◆MERIKEN4.k :2011/08/29(月) 03:03:29.61 ID:G09yQQGf0
しかし同じような事をしている人がいるというのは心強いです。
一緒に頑張りましょう!

365 : ◆MERIKEN4.k :2011/08/29(月) 03:45:14.99 ID:G09yQQGf0
オリジナルのBitslice DESのコードをいじってみたけど、
やっぱりうごきませんねえ… >>362のコードとじっくり取り組めば
謎は解けるんでしょうけど、今回は動いているJohn the Ripperの
コードで先に進むことにします。

しかしこのコード、今まで見た中で一番汚いんじゃないかというぐらいの
カオスっぷりです。いろんなプラットフォームに対応しつつスピードを
極限まで追求するとこんな感じなんでしょうか。

366 : ◆MERIKEN4.k :2011/08/29(月) 11:47:31.56 ID:G09yQQGf0
ようやく10桁トリップのCPU検索ルーチンが完成して、
今動かし始めたところです。510K TPSぐらいしか出てないので
テストするにも時間がかかりますが、まあ仕方が無いです。
さて、どうなるかな…

367 :362:2011/08/29(月) 11:59:15.00 ID:xoK0EyFD0
>>363
ありがとうございます!リンク先の表で自分の理解でよかったのだと確信できました。
◆MERIKEN4.kさんはリアルタイムで過程を書き込んでくださるのですごく勉強になります。
一方俺はCUDA学習目的が5割、10桁トリップ走査目的が5割でやっており、
トリップ走査の高速化には全く貢献しえないので申し訳ないですが、進展があれば報告していきたいと思います。


368 : ◆MERIKEN4.k :2011/08/29(月) 12:05:32.08 ID:G09yQQGf0
そういっていただけるとありがたいです。
いろいろ特殊な事が多いので、やはりノウハウの共有って大事ですよね。
またぜひいろいろ聞かせてください。

369 : ◆MERIKEN4.k :2011/08/29(月) 12:14:16.42 ID:G09yQQGf0
キタ━━━━━━(゚∀゚)━━━━━━ !!!!!

記念すべき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.

370 : ◆MERIKEN4.k :2011/08/29(月) 12:38:22.20 ID:G09yQQGf0
Tripperの改造を始めたときから10桁対応を意識しながらコーディング
してたんですが、実際にちゃんと動いているのを見ると感無量です。

しかし>>295で実際に作業を開始してから4日でようやくCPU検索が
動き始めたわけですから、想像以上の難物です。
最初は「ネットで適当なコードを拾ってくれば1日でGPU検索までできるだろう」
なんて思ってたので見通しが甘すぎですけど…

さて、今日はもうこれぐらいにして続きは明日にしよう。

■今日のまとめ(2011年8月28日)
・10桁トリップのCPU検索がようやく動く。

■明日の予定
・CPUで全位置検索ができるようにする。
・John the Ripper由来のコードのクリーンアップ。

それではまた〜

371 : ◆MERIKEN4.k :2011/08/30(火) 03:32:37.58 ID:0vxsMNNo0
今朝は10桁対応の続きでした。
本格的にコードを綺麗にする前に、万一のことを考えて
トリップの出現確率を計算しているルーチンの修正を行いました。
10桁トリップの最後は情報量が4bitしかないため、次の16文字しか
出現しません。

  .26AEIMQUYcgkosw

これに応じて出現確率の計算を修正し、出る可能性のないパターンを
削除するようにしました。これで正確な確率が出るようになったので、
テストをしながら思う存分コードを削れます。

372 : ◆MERIKEN4.k :2011/08/30(火) 03:59:49.16 ID:0vxsMNNo0
あと、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)

373 : ◆MERIKEN4.k :2011/08/30(火) 05:03:28.80 ID:0vxsMNNo0
というわけで、せっせとJohn the Ripperのコードを綺麗にしているわけですが、
気分は「汚物は消毒だ〜っ!!(AA略」という感じです。#ifdefにまみれた
4000行あるnonstd.cにはまだ手をつけていませんが、避けては通れません。とほほ…

374 : ◆MERIKEN4.k :2011/08/30(火) 11:25:25.83 ID:0vxsMNNo0
非常に恐ろしく見えたnonstd.cでしたが、#ifdefをある程度取り除いて
みたら、単にアーキテクチャ毎にに最適化されたDESのS-Boxがずらずらと
並んでただけでした。使用するレジスタの数や特定のオペランドの
実行回数に応じて非常に細かく場合わけされています。
ここらへんのJohn the Ripperの性能へのこだわりには本当に
関心させられます。絶対にメンテしたくないコードですけど…

今はとりあえず適当なS-Boxの組み合わせを選んでおいて、
あとで手作業で実行時間を測定して、CPUとGPUに最適な組み合わせを
それぞれ調べることにします。

375 :名無しさん@お腹いっぱい。:2011/08/30(火) 12:42:48.02 ID:0c8znTyHP
>>372
(*‘ω‘ *)つ http://toki.2ch.net/test/read.cgi/qa/1299965026/306

376 : ◆MERIKEN4.k :2011/08/30(火) 13:12:49.24 ID:0vxsMNNo0
>>375
> >>372
> (*‘ω‘ *)つ http://toki.2ch.net/test/read.cgi/qa/1299965026/306

衝突はほんとにすぐ起きますよね。

> キーはソルト分の2bitは固定

このへんはいまいちわかりませんでしたが…

377 : ◆MERIKEN4.k :2011/08/30(火) 14:09:12.18 ID:0vxsMNNo0
さて、汚物の消毒(笑)は完了して、4000行あったnonstd.cは150行になりました。
素のCの実装と関係ない部分を削除して、8つあるS-Boxを8つのインクルードファイルに
追い出したのですが、随分とすっきりとしました。あとは残りの部分をきれいにして、
thread-safeにしてしまったら、GPUのルーチンの実装に取り掛かれます。
もうS-Boxのソースは当分見たくないです(笑)

378 : ◆kneefQkyys :2011/08/30(火) 16:38:21.18 ID:ALklDUOi0
みんなどのツール使ってトリップ検索してるの?

379 : ◆MERIKEN4.k :2011/08/30(火) 21:53:36.76 ID:0vxsMNNo0
>>378
> みんなどのツール使ってトリップ検索してるの?

VecTripper → Radeon版待て屋。 → CUDA SHA-1 Tripper

という流れでした。いま作っているTripperの改造板は、これらのツールの
良いところをすべて取り込む予定です。VecTripperはMac用なので
使っている人は少ないと思いますけど、機能的にもUIの面でも非常に
洗練されているのでぜひ見習いたいですね。

380 : ◆MERIKEN4.k :2011/08/30(火) 22:10:09.76 ID:0vxsMNNo0
コードのクリーンアップがようやく終わりました。
あれだけごちゃごちゃしてたJohn the RipperのBitslice DESのコードが、
500行ほどの1つにすっきり収まり結構感動しました(笑)
もちろん機種判別用の#ifdefは全て削除しました。
このルーチンはどのCコンパイラでも通るはずなので、
Tripperとは別の形でいずれ単独で公開したいと思います。

381 : ◆MERIKEN4.k :2011/08/30(火) 22:42:56.74 ID:0vxsMNNo0
Johnのコードには相当難儀させらましたけど、実際には
オリジナルよりもはるかに効率のよいS-Boxの実装を
手に入れることができたのでかえって良かったのかも知れません。
あとはこれがCUDA Cで動いてくれればいいんだけど…

382 : ◆MERIKEN4.k :2011/08/31(水) 08:37:29.32 ID:UPr3S6rv0
マルチスレッドへの対応は全く問題なく終わりました。
Phenom II X6で2.71M TPSと笑っちゃうような数字ですが、John the Ripperは
もともとSSE2/AVX Intrinsicsに対応していたので、コードの最適化は比較的容易なはずです。

もともとCPU対応はおまけみたいな扱いなので、最適化は後の楽しみにとっておいて、
いよいよ本命のGPUによる10桁トリップ検索への対応の作業を始めることにします。
どれぐらいスピードが出るか、実に楽しみです。

383 : ◆MERIKEN4.k :2011/08/31(水) 08:57:17.80 ID:UPr3S6rv0
おっと、コードをCUDA Cに移植する前に、大量にあるgotoを削除しとかないとな…
John the Ripperのコードは本当に効率重視というかんじですけど、
この分岐の嵐ではCUDAでは性能がでないでしょう。

384 : ◆MERIKEN4.k :2011/08/31(水) 09:26:57.82 ID:UPr3S6rv0
全部マクロですまそうとしたらコンパイラが落ちました(笑)
8 S-Boxes * 16 rounds * 25 iterationsだから当然か…
まあ分岐といってもwarp divergenceが発生するわけではないようなので、
とりあえずこのままにしておきます。

385 : ◆MERIKEN4.k :2011/08/31(水) 10:38:16.65 ID:UPr3S6rv0
なるべくGPU検索とCPU検索でコードを共有化したいんだけど、
これ、GPU検索の前にコードの整理をしないと駄目だな。


386 : ◆MERIKEN4.k :2011/08/31(水) 13:30:00.73 ID:UPr3S6rv0
なんとかCPUとGPUでDESのルーチンを共有するために、
共通のルーチンをインクルードファイルに押し込めて、
2つのファイルでインクルードさせて、
プリプロセッサで違いを吸収させることにしました。
Jon the Ripperのコードを見続けた後では全く普通に見えますが、
やりすぎかもしれません。危ない危ない(笑)

なんにせよコードの整理がようやく終わったので、明日こそ
GPU検索を動かせるはずです。楽しみです。

387 : ◆MERIKEN4.k :2011/08/31(水) 13:34:16.76 ID:UPr3S6rv0
■今日のまとめ (2011年8月30日)
・10桁トリップのCPU検索のマルチスレッド化。
・ファイルの分割等のコードの整理。

■明日の予定
・10桁トリップのGPU検索への対応。

それではまた〜

388 :ヌクモリティ ◆vipper.ogg :2011/08/31(水) 13:53:05.20 ID:35i/quR30
とうとうゲフォで10桁検索が…
待て屋じゃ10M/Tすら程遠かったから期待

389 :名無しさん@お腹いっぱい。:2011/08/31(水) 19:46:29.77 ID:bsGjRpPq0
http://hibari.2ch.net/test/read.cgi/software/1205766220/571

使ってるグラボがショボイんじゃね?

390 :名無しさん@お腹いっぱい。:2011/08/31(水) 20:05:01.97 ID:FbZF3cWJ0
>>389
GPUがRADEONじゃなくてGeForceなんだろ。

391 : ◆Horo/.IBXjcg :2011/09/01(木) 01:39:44.83 ID:yaFN8Ufp0
>>355 >>357
SIMDとSIMTでの方向性の違いとかも関係しているのかの。

>>361
デフォルト値はCompute Capabilityで変えているつもりじゃったが、上手く動いていないのかや?
それにしてもGTX 580 OCでの速度は予想以上に速いようじゃが、ドライバのバージョンの影響も大きいのかの・・・

>>367
わっちは熱中するとBBSでのレスとかそっちのけで、コードを眺めたりのんびり煙管をふかしながら考えをまとめたりになってしまうの w

>>380
それは楽しみじゃの。
すぐに見つかるDESベースのcrypt()の実装は初心者向けの解説的なものか、極端に最適化されたもののどちらかという感じじゃったからの。

わっちのほうもビットマップを使った大量検索への対応ももうすぐ完了しそうじゃから、
それが終わればDESベースのcrypt()の勉強も再開しようかの。

正規表現への対応とかはハードルが高い上に、ある程度ならば
外部ツールでターゲットファイルを作るという力技も使えるからの w


392 : ◆MERIKEN4.k :2011/09/01(木) 06:40:03.24 ID:rNww9Rtc0
>>391
> >>355 >>357
> SIMDとSIMTでの方向性の違いとかも関係しているのかの。

なるほど〜 Radeonのアーキテクチャのことは何も知らないんですけど、
かなり違うみたいですね φ(..)メモメモ

> >>361
> デフォルト値はCompute Capabilityで変えているつもりじゃったが、上手く動いていないのかや?
> それにしてもGTX 580 OCでの速度は予想以上に速いようじゃが、ドライバのバージョンの影響も大きいのかの・・・

blocks/SMは 8のままでした。また一段落したらソースを追ってみます。

> >>380
> それは楽しみじゃの。
> すぐに見つかるDESベースのcrypt()の実装は初心者向けの解説的なものか、極端に最適化されたもののどちらかという感じじゃったからの。
>
> わっちのほうもビットマップを使った大量検索への対応ももうすぐ完了しそうじゃから、
> それが終わればDESベースのcrypt()の勉強も再開しようかの。

期待してます。またぜひ参考にさせていただきたいです。

393 :名無しさん@お腹いっぱい。:2011/09/01(木) 06:54:45.82 ID:4EJRSGLT0
>>390
mtyは現行ラデにしか対応してませんが?


394 : ◆MERIKEN4.k :2011/09/01(木) 06:55:15.94 ID:rNww9Rtc0
>>388
なるべく応えられるように頑張りますです。

さて、GPU検索への対応ですけど、まだもうちょっと作業が必要なようです。
何も考えずに使う変数を全部シェアードメモリに載せようとしたら
コンパイラに怒られてしまいました。

Bitslice DESで必要な変数はすべてstruct DES_Contextに押し込んでおいたのですが、
なんとサイズが8808バイトになってました。今の実装では1ブロックあたり128個の
スレッドが動いてるのですが、これでは共有メモリのサイズが全然足りません。

共有メモリのサイズはCompute Capabilityが1.xの場合は16K、2.xの場合は48Kと
なっています。スレッドの数をギリギリの32まで減らしてやっても、使える共有メモリの
サイズは1スレッドあたり512バイト、もしくは1536バイトなので、可能な限り
DES_Contextのサイズを減らす必要があります。

395 : ◆MERIKEN4.k :2011/09/01(木) 06:58:35.98 ID:rNww9Rtc0
>>393
> >>390
> mtyは現行ラデにしか対応してませんが?

>>388はCPU版の話なんじゃないでしょうか。
http://naniya.sourceforge.jp/
CPU版のソースってGPLで公開されてたんだ…
後で見てみよう。

396 : ◆MERIKEN4.k :2011/09/01(木) 07:07:53.13 ID:rNww9Rtc0
>>394の続きですけど、今後の方針はこんな感じです。

・中身が毎回同じ配列は、あらかじめ計算しておいてコンスタントメモリに追い出す。
・中身が動的に変化する配列は、ポインタの代わりにunsigned charのインデックスを使う。
・Key Scheduleのインデックスをcrypt (3)実行の前に実際のKeyに展開するのはやめにする。
・unionでstruct DES_Contextのメンバをまとめてやる。

512バイトはなかなか厳しい数字ですが、1536バイトなら十分に達成可能なはずです。
CPU検索のルーチンで動作確認をしつつ、すこしずつ削っていきたいと思います。

397 : ◆MERIKEN4.k :2011/09/01(木) 08:12:20.19 ID:rNww9Rtc0
とりあえず毎回同じ配列を外に出してみました。

> sizeof(DES_Context): 7528

先は長いですが、最初の一歩です。

398 : ◆MERIKEN4.k :2011/09/01(木) 08:47:25.56 ID:rNww9Rtc0
行き過ぎた最適化でCUDAでBitslice DESのコードが動かなくなっても
こまるので一応動作確認だけしてみましたが、ちゃんとトリップの変換はできている
ようです。

ついこの間まで知らなかったんですけど、Compute Capabilityが2.xの場合、CUDAの
コードからprintf()が呼び出せます。デバッグのときに非常に便利です。

399 : ◆MERIKEN4.k :2011/09/01(木) 15:34:53.26 ID:rNww9Rtc0
一番大きかったKey Schedule関係の配列をなんとか外に追い出すことに成功しました。
0x300 * 4 bytes * 2 = 6144 bytes なのでこれはでかいです。
あとはExpansion Tableのポインタの配列もUINT8のインデックスの配列に変えました。
結果はこんな感じです。

> sizeof(DES_Context): 1088

今日だけで随分はかどったな… 続きはまた明日やることにします。

400 : ◆MERIKEN4.k :2011/09/01(木) 15:52:48.08 ID:rNww9Rtc0
そろそろデータのメモリ配置の問題も考えなければいけないので、
資料を超適当に集めてきました。

Optimization Techniques for Large Data Structures on CUDA
http://www.eecis.udel.edu/~mpellegr/eleg662-09s/li.pdf

CUDA Programming Notes
http://www.ast.cam.ac.uk/~stg20/cuda/programming/index.html

Optimizing CUDA
http://mc.stanford.edu/cgi-bin/images/0/0a/M02_4.pdf

CUDA Optimization
http://www.prace-project.eu/hpc-training/training_pdfs/2653.pdf

本格的に最適化することを考えたらそろそろXPからWindows 7に移行して
Parallel Nsightを導入する必要があるかも… 結構な量の作業に
なるのでとりかかるのは週末になるかも知れません。

401 : ◆MERIKEN4.k :2011/09/01(木) 16:01:34.91 ID:rNww9Rtc0
■今日のまとめ (2011年8月31日)
・Bitslice DESのGPUでの動作確認。
・Bitslice DESで使われるデータ構造のサイズを1/8に減らす。

■今後の予定
・10桁トリップのGPU検索の試験実装。
・開発環境をWindows 7に移行して、Parallel Nsightを導入。

それではまた〜

402 : ◆GikoNekobg :2011/09/01(木) 19:01:27.80 ID:w0wlW58l0
乙鰈〜

403 :(の◇の) ◆wordlist..nn :2011/09/01(木) 20:13:28.25 ID:66KZFuYJ0 ?DIA(289888)
>>400
あちこちで資料を漁るのもいいけど、マニュアルも読もうぜ。w
printf とかコア数とかVisual Profilerとかの話を見る限り、読んでないだろ。

CUDA C Programming GuideのAppendix F. Compute Capabilitiesとか必読だろ、jk。

404 : ◆MERIKEN4.k :2011/09/01(木) 20:39:01.35 ID:rNww9Rtc0
あ、どもども。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でやりますかね。

407 : ◆MERIKEN4.k :2011/09/02(金) 17:04:58.76 ID:NsT4cfu10
>>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 ?DIA(289888)
>>407
>大量のグローバルメモリへのアクセスが発生して効率がでないんじゃないでしょうか。

マップドメモリ + カーネルの並列実行

これでそこそこマシになった。
ボクの作ってるCUDAトリッパーでは。w
古いゲフォで動かないけど。w

409 : ◆MERIKEN4.k :2011/09/02(金) 20:14:10.04 ID:NsT4cfu10
あれ、CUDAトリッパー作られていたんですか?

> マップドメモリ + カーネルの並列実行

これはなかなか興味深い話です。
しかしCompute Capabilityが低いと厳しいですよねえ。
10桁トリップの検索ではshared memoryを目一杯使う予定なので、
さすがにCC1.xの縛りではしんどくなってきました。

410 :(の◇の) ◆wordlist..nn :2011/09/02(金) 20:48:40.95 ID:jbgkgFqx0 ?DIA(289888)
CUDA SHA-1 Tripperの魔改造をあきらめて、完全自作に走ったわけで。
某所でこんなカキコをした。w

>マップドメモリとカーネル並列実行までやってもCUDA SHA-1 Tripper
>に届かないとかなにそれこわい


悪魔のコードな待て屋と違って、魔改造するのが楽そうだったんだよね。
綺麗でシンプルなCUDA SHA-1 Tripperって。

411 : ◆Horo/.IBXjcg :2011/09/02(金) 21:55:12.22 ID:XeY8WC+S0
>>392
わっちもRadeonの方はよく知らぬが、GeForceはメモリアクセス等のレイテンシの大きさは
スレッドを切り替えて隠蔽する方針のようじゃから、大量のスレッドが必要になって
かといって闇雲にスレッドを増やせばいいというわけでもないようじゃからの・・・

-xオプションのデフォルト値は1系は2で、2.0が8で、2.1が12じゃから、上手くいっていると思いんす。
とりあえずターゲットIPCとかは無視してコア数だけでの設定じゃがの。

>>405
コンスタントメモリへのアクセスはハーフワープ内のスレッドが異なるアドレスにアクセスするときは
逐次実行になって処理が直線的に増えるようじゃから、注意が必要かも知れぬの。

>>410
シンプルではあるかも知れぬが、綺麗といえるようなコードかの?w


412 : ◆Horo/.IBXjcg :2011/09/02(金) 22:10:15.73 ID:XeY8WC+S0
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 ?DIA(289888)
>>414
どんなプログラムになってんのか知らんが、いくらなんでもそんなグリッドサイズじゃ小さすぎるだろ。

417 :(の◇の) ◆wordlist..nn :2011/09/02(金) 23:10:36.75 ID:jbgkgFqx0 ?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 ?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

420 : ◆Horo/.IBXjcg :2011/09/03(土) 01:57:35.22 ID:U2zMQsc40
>>413
コンスタントメモリに区分は無くGPU全体で共有というのは、あくまでもソフトウェアからみたものであって
ハードウェア的にはSMというかSMの中にあるInstraction Unitによって管理されているように思いんす。

G80やGT200系はよく分からなかったのじゃが、FermiのL1キャッシュはSM内にあって
L2キャッシュは双方向クロスバで全SMからアクセス可能のようじゃが、
キャッシュの一貫性維持の簡略化とかで、やはりSM単位での管理になっておるんじゃないかの。

少なくともハーフワープ内のスレッドはアクセスする先を分散させては逆効果で、
極力同一アドレスにアクセスするようにすべきではないかの。

>>417
シンプルイズベスト(キリッ)というか、わっちの場合は複雑にしてしまうと自分でも手に負えなくなるからのw
わっちも早く無駄が無く、尚且つメンテしやすい芸術的なコードを書けるようになりたいの・・・

421 : ◆Horo/.IBXjcg :2011/09/03(土) 03:18:39.06 ID:U2zMQsc40
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を生成できるのじゃが、このファイルはダブルクリックしない方がいいの・・・

422 : ◆MERIKEN4.k :2011/09/03(土) 10:28:51.78 ID:i626T/dU0
>>421
お疲れさまです〜
ただいま10桁トリップのGPU検索の試験実装と奮闘中なので、
これが終わりしだいダウンロードさせて頂きます。

423 : ◆MERIKEN4.k :2011/09/03(土) 11:40:04.75 ID:i626T/dU0
原因不明の"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

424 : ◆MERIKEN4.k :2011/09/03(土) 12:28:11.54 ID:i626T/dU0
結局John the Ripperのコードがワードの配列をバイト単位でアクセスしてたのが
原因で、その部分を全部書きなおすことで解決しました。
しかし自分の書いたコードじゃないと思わぬところで足をすくわれますね。

425 : ◆MERIKEN4.k :2011/09/03(土) 16:43:15.27 ID:i626T/dU0
10桁トリップのGPU検索の試験実装ができました。
Bitslice DESのルーチンがエンバグしてえらい目に遭いましたが、
ようやくちゃんと動くようになりました。
とりあえずローカルメモリだけを使うようにしてシェアードメモリは触っていないので
スピードはまだまだですが、それは今後の最適化次第ということで実に楽しみです。

426 : ◆MERIKEN4.k :2011/09/05(月) 05:33:58.83 ID:a8Kci59n0
さっきようやく開発環境をWindows 7に移行して
試しにCompute Visual Profilerを動かしてみました。
(XPでは何故か途中でクラッシュして動きませんでした)

で、気づいたのがOccupancyが最大でも0.167とかなり低いことです。
register per threadが63と高いのが関係してるのかしらん。
ちょっと減らしてみよう。

427 : ◆MERIKEN4.k :2011/09/05(月) 05:39:21.90 ID:a8Kci59n0
そうそう、開発環境を移行している間にCUDA C BEST PRACTICES GUIDEを
通読しておきました。やっぱり性能をだそうと思ったら資料を読んで
プロファイラを使わないと無理ですね。PROGRAMMING GUIDEも後で
最初からちゃんと読んでおこう。

428 : ◆MERIKEN4.k :2011/09/05(月) 05:55:43.34 ID:a8Kci59n0
per threadあたりのレジスタ数を減らそうとしたら
"invalid kernel image"というエラーが出てしまいました。
--maxregcountを16と32にしてみたんですが、両方共エラーが出ます。
やはりいろいろとshared memoryに追い出さないと効率は上がらなさそうです。

429 : ◆MERIKEN4.k :2011/09/05(月) 07:24:36.54 ID:a8Kci59n0
--maxregcountを元に戻しても治らないぞ orz
開発環境の問題なのかなあ。

430 : ◆MERIKEN4.k :2011/09/05(月) 08:11:27.76 ID:a8Kci59n0
どうやらさっきインストールしたParallel Nsightが原因みたいです。
http://forums.nvidia.com/index.php?showtopic=199795
なんということだ orz

431 : ◆MERIKEN4.k :2011/09/05(月) 09:41:03.14 ID:a8Kci59n0
Parallel Nsightを使うためにWindows 7に移行したのに
Parallel Nsightが使えないとは意味不明ですが、
とりあえずCompute Visual Profilerが動くようになったので
これでしばらく頑張ってみます。

で、レジスタの数を16に減らしたら案の定スピードは落ちてしまいました。
これは相当うまく共有メモリを使ってやらないといけないようです。

432 : ◆MERIKEN4.k :2011/09/05(月) 09:47:21.39 ID:a8Kci59n0
レジスタの数を減らしたのにOccupancy Rateはそのままでした。(・3・)アルエー?

433 : ◆MERIKEN4.k :2011/09/05(月) 11:12:54.40 ID:a8Kci59n0
うーん、どうもCompute Visual Profilerを動かしても、
途中からいろいろおかしくなるなあ。"unknown error"がCUDAの
関数から帰ってくるなんて初めてだ。実に不思議です。

434 : ◆MERIKEN4.k :2011/09/05(月) 13:39:36.14 ID:a8Kci59n0
Visual Profilerが不安定だった原因が分かりました。
ドライバの反応が遅すぎたのがいけなかったようです。

Timeout Detection and Recovery of GPUs through WDDM
http://msdn.microsoft.com/en-us/windows/hardware/gg487368

ようやく問題なくVisual Profilerが動くようになったので、
心置きなく最適化に集中できます。しかし今回の10桁対応の件では
本当にいろいろあるなあ。とりあえず当面の目標はOccupancyを上げることです。

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 のみ

440 : ◆MERIKEN4.k :2011/09/06(火) 01:21:28.01 ID:v0jogezS0
>>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に下がってしまいました。

441 : ◆Horo/.IBXjcg :2011/09/06(火) 01:46:03.04 ID:aiXVgolG0
>>435-436
ターゲット数を増やした時の速度低下が予想以上に大きいの・・・

ターゲット先頭3文字の文字種が増えるとグローバルメモリへのアクセスが増えるはずじゃが
それが大きく影響しておるのかの。

正規表現のサブセット等への対応も考えたほうがいいのかの・・・

442 : ◆MERIKEN4.k :2011/09/06(火) 09:30:50.33 ID:v0jogezS0
>>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

443 : ◆MERIKEN4.k :2011/09/06(火) 09:47:58.92 ID:v0jogezS0
>>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


444 : ◆MERIKEN4.k :2011/09/06(火) 09:54:08.33 ID:v0jogezS0
>>441
> 正規表現のサブセット等への対応も考えたほうがいいのかの・・・

前方一致だけなら自分の改造版のソースを流用していただければ
すぐにプリプロセッサが出きるはずです。
後方一致や任意の位置での検索をしようとするとプリプロセッサだけでは
きびしくなってきますが…

445 : ◆MERIKEN4.k :2011/09/06(火) 10:30:57.45 ID:v0jogezS0
10桁トリップのGPU検索の話の続きです。
Visual Profilerで調べた結果、Occupancyが1スレッドあたりのレジスタ数のせいで
低いことがわかったので、CUDA GPU Occupancy Calculatorで調べてみました。

http://developer.download.nvidia.com/compute/cuda/CUDA_Occupancy_calculator.xls

結果はこんな感じです。

http://www.meriken2ch.com/files/2011-09-05-CUDA-occupancy-current.JPG

やはり1スレッドあたりのレジスタ数が邪魔をしてたようで、1SMが同時処理できるブロックの数が4に
なってしまっています。これではOccupancyが上がらないのは当たり前です。

今後の予定としては、共有メモリを1スレッドあたり32 * 4 bytes使って
使用するレジスタの数を半分にすることです。レジスタの数をやみくもに減らしても
スピードが落ちるだけだし、1スレッドに割り当てる共有メモリの量を
増やしても同時処理できるブロックの数が減ってコアが有効利用できないので、
ここらへんがぎりぎりのラインでしょう。下のグラフのようになれば理想的ですが、
はたしてどうなることやら…

http://www.meriken2ch.com/files/2011-09-05-CUDA-occupancy-ideal.JPG

Threads per Block: 128 → 128
Registers per Thread: 63 → 32
Shared Memory per Block: 0 → 6144
Active Threads per Multiprocessor: 512 → 1024
Active Warps per Multiprocessor: 16 → 32
Occupancy of each Multiprocessor: 33% → 67%

446 : ◆MERIKEN4.k :2011/09/06(火) 12:00:20.08 ID:v0jogezS0
あれ、計算間違えてるぞ。共有メモリは1スレッドあたり6144 / 128 = 12 * 4バイトか。
うーん、これは厳しいなあ。できるだけ節約しないと駄目だな、これは。

1スレッドあたりのレジスタ数を20、共有メモリを8 * 4バイトまで削ることができれば
1SMあたり192スレッドまで詰め込んでtheoretical occupancyが100%になるけど、
これは無理そうだしな…

しかし共有メモリが1SMあたり48Kしかないというのはなかなか厳しいです。
もうなるべくローカル変数を減らしてレジスタ数を削るしかないですね。


447 : ◆GikoNekobg :2011/09/06(火) 14:25:50.23 ID:VuCRpuSI0
>>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

速くネエ。

448 : ◆GikoNekobg :2011/09/06(火) 14:31:27.56 ID:VuCRpuSI0
【オプション】 -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

449 : ◆GikoNekobg :2011/09/06(火) 14:39:56.02 ID:VuCRpuSI0
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 ?DIA(289888)
>>441
この程度で「大きい」という感想になるとは。

一回、億個単位のタゲでも食わせてみますか。w
うにで878264708ターゲットまでは試したことが。www

451 : ◆MERIKEN4.k :2011/09/07(水) 02:00:24.86 ID:fACAUDND0
今朝はガリガリとローカル変数の数を削るという実に地味な作業をしていました。
ここらへんはCUDAのアーキテクチャの制約の影響をもろに受けてるわけで、
Radeonがどうなっているのか実に気になるところです。
新しい7970のTDPは190WでGTX 580より低いんだよな。ちょっと試してみたいかも…

452 : ◆MERIKEN4.k :2011/09/07(水) 02:19:21.38 ID:fACAUDND0
まあでもとりあえずは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のほうに取り組む予定は現状ありませんが、
コーディングの参考にしたいと思いダウンロードさせていただきました!


454 : ◆MERIKEN4.k :2011/09/07(水) 06:51:18.13 ID:fACAUDND0
Horo氏のコードはほんとうに参考になるのでぜひ一読を薦めますです。
私も随分勉強させて頂きました。

455 : ◆MERIKEN4.k :2011/09/07(水) 08:15:08.63 ID:fACAUDND0
私の10桁トリップの検索のコードは最適化とエンバクを繰り返しながら
少しずつ速くなってます。Occupancyを33%から少なくとも67%、
できれば100%まであげたいんですけど、なかなか楽はさせてもらえませんね〜

456 : ◆MERIKEN4.k :2011/09/07(水) 10:04:00.36 ID:fACAUDND0
どうやら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

457 : ◆MERIKEN4.k :2011/09/07(水) 10:43:08.68 ID:fACAUDND0
初めてptxファイル見たけど、レジスタ割り当てまくっててワロタw
こりゃ効率悪くなるわけだわ。どうしよっかなあ…

458 : ◆MERIKEN4.k :2011/09/07(水) 17:19:00.90 ID:fACAUDND0
CUDA側でしていたsaltとexpansion functionの処理を
本体側に追い出せないか、現在検討中。
これがなければローカルメモリへのアクセスがかなり減らせる上に、
レジスタ数の削減もできるはず…

459 :362:2011/09/08(木) 21:19:03.65 ID:Is6P+pLc0
blocksPerGrid,threadsPerBlockの値を大きくすると実行が途中で止まってしまう問題(>>414,>>418)は
やはりタイムアウトが原因でした。
デフォルトだとWindows Vistaや7ではカーネルの活動限界は2秒なんですね…。
↓のページで説明されているようにTdrDelayを設定することで解決(ブラックアウトしない。Windowsからも怒られない)しました。
timeoutリカバリーの有無自体に変更はないならTdrLevelを新規作成する必要はない模様です。
TdrDelayの作成後にOSの再起動は必要でした。

CUDAカーネル実行のタイムアウト - PukiWiki Plus!
http://imd.naist.jp/~fujis/cgi-bin/wiki/index.php?CUDA%A5%AB%A1%BC%A5%CD%A5%EB%BC%C2%B9%D4%A4%CE%A5%BF%A5%A4%A5%E0%A5%A2%A5%A6%A5%C8


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 ?DIA(289888)
やっぱさ、GTX 580使っても10桁じゃ10Mさえいかないんじゃね?w
でも、鳥屋ならなんとかしそうで怖い。www

>>460
いや、だからマニュアル読もうぜ。w
なんで一次情報元を優先しないんだろう。

あと、「CUDA トレーニング」でググって、Volume 1を読むとか。

462 : ◆MERIKEN4.k :2011/09/09(金) 00:05:12.10 ID:BFSCFgFA0
>>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も使っていきたいと思います。

464 :名無しさん@お腹いっぱい。:2011/09/09(金) 01:11:39.88 ID:ejTeJbsE0
>>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まで。
すみません手抜きして新しい情報源をちゃんと見ていなくてお手数をおかけしました。
何から何までアドバイスありがとうございます。

466 :名無しさん@お腹いっぱい。:2011/09/09(金) 04:15:56.12 ID:vjilqvGsP
>>462
俺の感覚ではGTX460で良くて数十M、100Mいったらすげーな、って感じだたな

467 : ◆MERIKEN4.k :2011/09/09(金) 09:29:46.46 ID:BFSCFgFA0
>>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 ?DIA(289888)
まあゲフォだとそうだよな。
同価格帯のラデと比べるとかなり落ちる。(※トリップ検索においては。w)
鳥屋先生の科学力を考慮しなくてもね。www

100M届くかどうかったら、5770クラスだもんね。

469 :名無しさん@お腹いっぱい。:2011/09/09(金) 12:58:15.53 ID:J63fgovy0
CUDAをこういう用途に使う人もいるのか

470 : ◆MERIKEN4.k :2011/09/09(金) 14:41:55.80 ID:BFSCFgFA0
>>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にもやーい怒られてやんのーと言われる(「ツールはエラー コードを返しました」)。
単なるコピーならコンパイラがうまくやってくれると信じて素直に代入文を書くことにする。


473 :(の◇の) ◆wordlist..nn :2011/09/10(土) 02:50:09.09 ID:YGsdmyaH0 ?DIA(289888)
Vector Type の uint2 とかそんな話?

uint4 なら使ってたなぁ。SHA-1だけど。w

474 : ◆MERIKEN4.k :2011/09/10(土) 04:31:20.88 ID:8OysNyqc0
>>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になっていることしかなくてひょっとして楽できる…?と思っていたので危なかったです。
ではおはようございます&おやすみなさいです。 進展があったらまた書き込ませていただきます。

478 : ◆MERIKEN4.k :2011/09/10(土) 08:36:08.47 ID:8OysNyqc0
>>475
横槍ですけど、Vector TypeのことはProgramming Guideに載ってますよ。
自分はまだ試してないですけど… unsigned intを使うより効率がいいなら
Bitslice DES の実装に直接応用できるのであとで試してみたいと思います。

479 : ◆MERIKEN4.k :2011/09/10(土) 08:43:09.50 ID:8OysNyqc0
>>476
うーん、それは変ですねえ。とにかく最適化で一番気を使うのは
分岐の処理とグローバルメモリへのアクセスですからねえ。
コードを公開されるのでしたらぜひ見せていただきたいです。

480 : ◆MERIKEN4.k :2011/09/10(土) 08:48:57.00 ID:8OysNyqc0
とりあえず共有メモリには手を付けないで、>>456の方法でvolatileキーワードを
使ってレジスタ数を63から32まで減らすことを目標にしました。
nvccはこれでもかというぐらいレジスタを使っているので、
C言語での書き方を工夫してレジスタの割り当てを減らしたいところです。

481 :名無しさん@お腹いっぱい。:2011/09/10(土) 08:57:11.59 ID:OsiZwdQ6P
>>470
個人的には終わりがみえている10桁トリップのツールを作ってどうするの?って思うが
他人の趣味だからどうでもいいか(*‘ω‘*)

482 : ◆MERIKEN4.k :2011/09/10(土) 09:18:18.10 ID:8OysNyqc0
>>481
純粋な遊びに実用性を求めるのは野暮というものですよw
楽しければそれでいいのです。

483 : ◆MERIKEN4.k :2011/09/10(土) 09:49:24.64 ID:8OysNyqc0
とりあえずS-Boxが手頃なサイズなので、これの最適化から始めることにしました。
John the Ripperの実装についてきたS-Boxには幾つか種類があって
選べるようになっているのですが、全部試す時間はないのでレジスタの
使用数が一番小さいものを選ぶことにしました。とりあえず試してみたら、
なにもしていないのに前より少しだけ速くなっています。やはりレジスタの割り当て方の
まずさが相当足を引っ張っていると思われます。

John the Rippperのコメントによればレジスタ数は14〜19個で済むはずですが、
アホの子のnvccは何も考えずに60〜80個レジスタを割り当ててくれています。
やはり相当最適化の余地があるみたいです。

484 :(の◇の) ◆wordlist..nn :2011/09/10(土) 12:39:58.99 ID:YGsdmyaH0 ?DIA(289888)
つか、デバイス側は読み込みだけなら、コンスタントメモリに転送した方がいいような?
オプションとか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 */

485 : ◆MERIKEN4.k :2011/09/10(土) 13:03:10.22 ID:8OysNyqc0
>>484
コンスタントメモリに変数を追い出せるとかなりおいしいですよね。
自分の実装では速度低下はほとんど見られませんでした。

486 : ◆MERIKEN4.k :2011/09/10(土) 13:32:11.04 ID:8OysNyqc0
いろいろ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

487 : ◆MERIKEN4.k :2011/09/10(土) 23:36:55.43 ID:8OysNyqc0
とりあえずインラインアセンブラを使う前に、
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時間以内にはどこかに載せたいと思います。

489 :名無しさん@お腹いっぱい。:2011/09/11(日) 00:03:19.62 ID:zC3dy5ip0
PTX見ても意味がない

490 :名無しさん@お腹いっぱい。:2011/09/11(日) 00:04:18.85 ID:zC3dy5ip0
SASS見なさい

491 :(の◇の) ◆wordlist..nn :2011/09/11(日) 00:32:19.16 ID:mxOBEKbN0 ?DIA(289888)
ベンダーのマニュアルを読んでちゃんと理解する。
ベンダーのサンプルプログラムを読む。
これは基本で必須だと思うんだが、やらないやつのほうが多いのか?
砂上に楼閣を築くのはおすすめできないな。w

あとは先人の知恵をパク、じゃなかったw、参考にする、と。
CUDA SHA-1 Tripperは大変いい。SHA-1だけど。
待て屋は参考にはならん。wビットスライスだけど。
うとりっぱーはもうダウンロードできないんだっけ?UFC-cryptだけど。

DES自体はググればいろいろ出てくるよな。
Phil Karn先生とかEric Young先生とか定番か。

492 : ◆MERIKEN4.k :2011/09/11(日) 01:06:24.80 ID:tGzUJSSY0
>>490
SASS見てみましたけど、予想通りS-Boxのあたりでレジスタを大量に消費してました。
30以上使ってたので、実際に必要な数よりかなり多いですね。
cubinとPTXのコードが違うというのはもちろん理解してますけど、
実際の挙動はPTXのコードとプロファイリングの結果からある程度予測できるという印象です。

>>491
自分の調べた限りでは、現在のBitslice DESの最小ゲート数の実装は、John the Ripperで
使われているRoman Rusakov氏のものでした。>>323のSlashdotの記事で紹介されてますけど、
Kahn氏のオリジナルより17%ゲート数が少ないとのことです。

493 :(の◇の) ◆wordlist..nn :2011/09/11(日) 01:18:41.96 ID:mxOBEKbN0 ?DIA(289888)
>>492
まあ、そのゲート数減らしたやつが
http://yy43.60.kg/test/read.cgi/tripageruo/1236341912/223
だったりする。w
なにも考えずにまんま持ってきた。www

新待て屋もそれを採用してさらにいろいろと魔術を駆使してる、らしい。w
いつリリースされんのかしらんが。

494 : ◆MERIKEN4.k :2011/09/11(日) 01:20:33.47 ID:tGzUJSSY0
おっと間違えた。Bitsliceの実装の話はKahn氏じゃなくてKwan氏だった。
http://www.darkside.com.au/bitslice/

495 : ◆MERIKEN4.k :2011/09/11(日) 01:35:19.28 ID:tGzUJSSY0
>>493
そりゃやっぱりゲート数が少ないほうを使いますよねw
正直これだけゲート数が減らせたというのは驚きです。
新待て屋というのはラデ版のことですか? それは実に興味深いですね…

496 :名無しさん@お腹いっぱい。:2011/09/11(日) 02:45:12.43 ID:Pz7FgOoN0
>>486
よく分からないけど、変数を宣言したらその分だけしっかりレジスタ使ってくれるとか・・・?

>>487
確かゲート毎に新しく変数を用意して代入しているんだよね・・・。

>>493
見るにはどこかで登録必須?
でもSSE2とかの命令セットとかってCUDAやATI Streamで使えるの?


497 : ◆MERIKEN4.k :2011/09/11(日) 05:41:15.24 ID:tGzUJSSY0
>>496
> よく分からないけど、変数を宣言したらその分だけしっかりレジスタ使ってくれるとか・・・?

PTXのレベルでは演算子ごとにレジスタを割り当ててます。
一応cubinに変換される段階で最適化されるはずなんですけど、あまり当てにならないみたいです。

> 確かゲート毎に新しく変数を用意して代入しているんだよね・・・。

そうです、そうです。なので、使い回せば結構変数の数は簡単に減らせるんですよね。

498 : ◆MERIKEN4.k :2011/09/11(日) 10:52:03.46 ID:tGzUJSSY0
とりあえず10桁GPU検索のコードをPTXで書き直す前に、
今まで多少オーバーラップのあった10桁と12桁のコードを
完全に分けてしまいました。これで思う存分最適化に
集中できます。

しかし10桁GPU検索の最適化は相当な長丁場になりそうなので、
その前にコードを公開するか迷うところです。S-Boxの最適化が
一段落した段階で考えるか…

499 :名無しさん@お腹いっぱい。:2011/09/11(日) 10:54:25.79 ID:bQaNMrVi0
自分にはレス内容を見ても何が書いてあるのか
サッパリ分からないんですけど、MERIKEN4.kさんて何をされてる方なんですか?
あと失礼ですが、お歳はおいくつくらいの方なんでしょうか。

500 :(の◇の) ◆wordlist..nn :2011/09/11(日) 10:58:17.51 ID:mxOBEKbN0 ?DIA(289888)
>>495
当然、どっちも、だ。(CPU版とGPU版)

>>496
ソースコードならちゃんとあるべき場所に置いてあるぞ。
GPL遵守してる俺様カコイイ。www
http://sourceforge.jp/projects/naniya/svn/view/branches/mty-makai/?root=naniya
GPU版はここにはないが。


ちょっと Radeon HD 7990 予約してくる。

501 : ◆MERIKEN4.k :2011/09/11(日) 11:38:26.90 ID:tGzUJSSY0
>>499
ここでやってることは本業とは全く関係ない完全な趣味です。
自分のことは自分のウェブサイトに書いておいたので
探してみてくださいな。もともと別の板でつかってたコテハンなので、
内容もそれなりですけど…

502 :名無しさん@お腹いっぱい。:2011/09/11(日) 13:38:21.57 ID:bQaNMrVi0
なるほど。
(`・ ω・´)な感じの人なんですねw

503 : ◆MERIKEN4.k :2011/09/11(日) 14:25:37.46 ID:tGzUJSSY0
>>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
またまたすみません、>>505のURL訂正です。ヘッダー中の不要な箇所を削りました。
http://ll.la/*7RV
(公開期限2011-09-15(木) 03:51:58)

508 : ◆MERIKEN4.k :2011/09/12(月) 04:51:50.20 ID:4BVuiG8a0
さっき落として中身を確認しました。あとでゆっくり読ませていただきます。

509 : ◆MERIKEN4.k :2011/09/12(月) 05:31:35.77 ID:4BVuiG8a0
>>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が使われてしまう。検索速度に影響する話ではない。


511 : ◆MERIKEN4.k :2011/09/12(月) 09:02:50.41 ID:4BVuiG8a0
>>510
まあプログラミング自体息抜きなので、のんびりやらせていただきますw
S-Boxの最適化の方は、インラインアセンブラの使い方がわかったので
あとはせっせと手作業でゲートを変換してやるだけです。

512 : ◆Horo/.IBXjcg :2011/09/13(火) 00:29:20.43 ID:ReECkmWX0
>>486
PTXのマニュアルの予約語の部分を見てみたのじゃが、
CUDAがネイティブに対応している論理演算は標準的なもの以外はどれぐらいあるのかの?

対応していない論理演算を利用したS-boxを下手に使うと、逆にゲート数が増えかねないしの。

>>492
sboxes-s.cにあるAltiVecのvselを利用したものかの?
vselやそれに相当する命令がネイティブに実装されていないケースではどうなるのか気になるの。

まあわっちはS-boxの最適化どころか、CUDAでの実装テストもまだで
Kwan氏のサンプルコードの大部分を何とか理解した程度じゃがw

S-boxやCUDAに関係の無い部分だけでも、
最適化しようとすると凄まじいことになりそうじゃの・・・

513 : ◆MERIKEN4.k :2011/09/13(火) 03:57:15.54 ID:NEjEEXPT0
>>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)。

516 : ◆MERIKEN4.k :2011/09/13(火) 13:54:44.25 ID:NEjEEXPT0
>>514
速い実装が欲しいならUFC-cryptを勧めます。うちのPhenom II X6ではなにもしないで
1コアで300K crypt/sでてましたよ。素のBitslice DESが500K crypt/sぐらいだったので、
UFC-cryptも十分速いです。

517 : ◆MERIKEN4.k :2011/09/13(火) 14:04:43.75 ID:NEjEEXPT0
ようやく最初のS-Boxのインラインアセンブラでの書き換えが終了しました。
理屈がわかればあとは機械作業なんだけど、これをあと7回繰り返さなきゃならんのか orz
まあ最初の書き換えがすんなり終わっただけでも僥倖なので、さっさと残りも
片付けることにします。今週中に終わればいいけど、どうなるかなあ…

518 : ◆Horo/.IBXjcg :2011/09/14(水) 00:07:32.42 ID:/srmheiE0
>>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とにらめっこしたりペタペタコピペして見通しをよくしようとしてたのに、
コーディングに入るために変換表を最初から見直ししてたら…計算規則が一目瞭然の簡単すぎでワロタ…数時間の苦労が…

521 :名無しさん@お腹いっぱい。:2011/09/14(水) 06:28:11.82 ID:q4c9yOMlP
>>517
CUDAによる bit-sliced DESの実装に関する論文があるのに何で読まないん(*‘ω‘ *)?
俺は読んでねーけど、全国大会のA4ピラじゃなくてフルペーパーくさかったぞ(*‘ω‘ *)?
ためになるんじゃねーの(*‘ω‘ *)?

522 : ◆MERIKEN4.k :2011/09/14(水) 17:40:58.69 ID:Kbj0xRio0
>>521
前(>>290)にもちょっと書きましたけど、次の論文にはざっと目を通してます。

Efficient Password and Key recovery using Graphic Cards
http://www.emsec.rub.de/media/crypto/attachments/files/2011/03/DA_Schober.pdf

Record Setting Software Implementation of DES Using CUDA
http://home.dei.polimi.it/barenghi/files/ITNG2010.pdf

特にSchoberの学位論文はかなり詳しくbitslice DESのCUDAでの実装を解説しています。
ただ、報告されている速度はトリップ検索に換算するとGTX 260で
13M TPS前後なので、参考になるかといわれるとなかなか微妙なところです。

> 12,9 M PW/s BEST RESULT (ZeroCopy Alternative): 8 char PW characterset
> generated, Build conguration: 121 registers, 4672 bytes lmem,
> 32+16 bytes smem, 304 bytes cmem. Execution conguration: 4096 blocks
> 128 threads
(Schober, 2010, p. 116)

523 : ◆MERIKEN4.k :2011/09/14(水) 17:49:19.78 ID:Kbj0xRio0
おっと、上のレスのアンカーは>>190でした。

524 : ◆Horo/.IBXjcg :2011/09/14(水) 17:55:59.83 ID:/srmheiE0
>>519-520
言われてみればcryptの25回のDESループ内ではKSは変化しないのじゃったの。
やはり展開してハードコードが一番の気がするの。
行数が凄まじいことになるがのw

コンスタントメモリからシェアードメモリにコピーして、それを使うようにしたのは
>514にもあるように、ハーフワープ内のスレッドがアクセスするコンスタントメモリのアドレスが異なると
逐次実行になるからじゃが、見直してみるとハーフワープ内の全スレッドが同一アドレスにアクセスする部分も結構あるの・・・

酷いバンクコンフリクトを起こしていそうな部分もあるから、書き直さねばならぬの。

525 : ◆MERIKEN4.k :2011/09/14(水) 17:57:45.61 ID:Kbj0xRio0
>>518
JtRの実装が素直なのはS-Boxの中身だけで、あとはかなりすごいことになってますねw
UFC-cryptがそれだけメモリを使っているなら、ちょっとCUDAでは厳しいですねえ。
レジスタ数の削減は予定ではうまくいくはずwですけど、実際にどうなるかは後のお楽しみです。

526 :(の◇の) ◆wordlist..nn :2011/09/14(水) 18:08:44.40 ID:oqFech/v0 ?DIA(289888)
今ならCUDAでのDES実装の世界最先端を行くことも可能じゃね?



んなもんホンキでやるやついないだろうし。w

527 : ◆Horo/.IBXjcg :2011/09/14(水) 21:14:37.45 ID:/srmheiE0
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

528 :(の◇の) ◆wordlist..nn :2011/09/14(水) 22:35:50.11 ID:oqFech/v0 ?DIA(289888)
>>527
あちこち!?
IPsecぐらいしか浮かばない。w
何年も前に死亡宣告されたDESをCUDAでなんて需要ないっしょ。

SHA-1は(実装が)手軽だからよく使われるよね、総当たりの実験とかに。(ぇ
Ivanタン、ハァハァ

529 : ◆MERIKEN4.k :2011/09/14(水) 22:48:40.09 ID:Kbj0xRio0
>>527
> あのS-boxの変数は自動生成したコードそのままなのかのw

変数名とか見る限り、まったくそのままなんでしょうねえw
Kwan氏は自分の作ったゲート作成用のプログラムを公開してるみたいですけど、
JtRのほうも気になります。

530 : ◆Horo/.IBXjcg :2011/09/15(木) 15:03:32.93 ID:8cv5WDNq0
素の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への置き換えを試してみる。

535 :(の◇の) ◆wordlist..nn :2011/09/16(金) 07:59:24.02 ID:NTBRsBDA0 ?DIA(289888)
つ「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が奇数のときです。


539 : ◆Horo/.IBXjcg :2011/09/17(土) 01:47:19.16 ID:0V4VCY2j0
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[]との対応がきれいに
整理できるとすれば部分的に計算とメモリをカーネルの外に出せるのですが。

544 : ◆MERIKEN4.k :2011/09/18(日) 11:25:57.14 ID:nG1l8U4N0
結局今週はあんまり時間が取れなくて、現在ようやく3番目のS-Boxの最適化に
とりかかったところです。大分慣れてきたので1個あたり2時間弱ぐらいで済みそうな
感じですけど、それでも随分時間がかかりますねえ。

545 : ◆MERIKEN4.k :2011/09/18(日) 20:03:20.90 ID:nG1l8U4N0
3番目のS-Boxの変換が終了。コツがわかってきたのでそれほど神経をすり減らす
必要もなくなりました。今日中に全部終わらせたいところだけど、ちょっと
厳しいかな〜

546 : ◆MERIKEN4.k :2011/09/18(日) 20:07:54.60 ID:nG1l8U4N0
レジスタ数は63個でめいっぱいですけど、幸いlmemへのregister spillingは4 bytesだけなので、
レジスタ数の削減は何とかなりそうな感じなんですけどねえ。現在公開してるバージョンが
OSによっては立ち上がらないのが判明したので、早めに新しい版を公開したいところです。

547 :名無しさん@お腹いっぱい。:2011/09/19(月) 16:35:07.26 ID:oD7N7tvQP
>>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のシェアを上回ることは考えにくいなあと思う。

549 : ◆Horo/.IBXjcg :2011/09/20(火) 17:29:23.33 ID:GthWW+Xn0
>>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を開くときが来たか…

556 : ◆Horo/.IBXjcg :2011/09/23(金) 01:43:56.85 ID:pegw3jLY0
>>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くらいだろうか。と自分を追い詰めてみる。

561 : ◆Horo/.IBXjcg :2011/09/24(土) 03:01:29.29 ID:5RwBiNXW0
atomic関数等を調べようと、プログラミングガイドを見ておったのじゃが
SMあたりのスループットの表を見て、CC1.xとCC2.0とCC2.1では
コアあたりのシフトや乗算のスループットがかなり異なることに今更ながら気がついた・・・
GF100系とGF104系での性能差は、コアあたりのレジスタ数だけの問題でもなさそうじゃの。

>>557
もうucharの配列ではなく、uint32にビット格納にしておったのかや。
メモリ消費だけでなく演算量もかなり減って効果も大きそうじゃの。
主様のおかげでSP-boxを利用した実装の理解も少しは楽になりそうな気がしてきたの。

ビット格納の場合はkeyからKSを生成するのに結構な演算量になりそうじゃから
メモリ使用量が増えるのは我慢してKSを保存しておいた方がいいのかの・・・

562 : ◆Horo/.IBXjcg :2011/09/24(土) 21:10:11.69 ID:5RwBiNXW0
ドキュメントを読み返していて重要なことに今更ながら気がついた。

Compute Capability 2.0以降でSMあたりのコア数やレジスタ数が増えておるが、
同時にロードできるブロック数の最大数はSMあたり8のままで、
上限が上がっておるのはSMあたりのワープ数じゃった。

ブロックあたりのスレッド数を増やすしかなさそうじゃが、難儀しそうじゃの・・・

563 : ◆Horo/.IBXjcg :2011/09/25(日) 00:47:21.12 ID:P6svpS9W0
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を使ってブロックあたりのスレッド数を真面目に検討しておるのじゃが、
やはりレジスタ数の制限が厄介そうじゃの・・・

564 : ◆Horo/.IBXjcg :2011/09/25(日) 19:28:37.30 ID:P6svpS9W0
ブロックあたり192スレッドで、SMあたり8ブロック走らせるには
スレッドあたりのレジスタ使用量を20にまで減らさねばならぬというのは結構厳しいの。

レジスタ数のオプションを色々と試しておるとP-stateが一番上まで上がらぬようになったのじゃが、
ドライバの省電力機能が誤作動したのかの・・・

565 :名無しさん@お腹いっぱい。:2011/09/25(日) 21:04:04.86 ID:rSLyvbfX0
パスがわからない・・・orz


566 :名無しさん@お腹いっぱい。:2011/09/25(日) 21:16:36.12 ID:+52s0QJm0
MERIKEN氏のを使い始めたんだけど、CPUGPU両方使用中にPauseキーで止めると
表示は止まるけどCPUは走り続けるんですね
これでしばらくしてからPause解除するとmaximamの数値がえらいことになるけど

>>565
メール欄

567 :名無しさん@お腹いっぱい。:2011/09/25(日) 21:28:18.68 ID:rSLyvbfX0
>>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的な(?)方法もあるけど…。


571 : ◆Horo/.IBXjcg :2011/09/27(火) 00:06:15.26 ID:XtPYArkP0
P-stateが上がらない症状は再起動して直ったと思ったら、また発症しおった・・・
原因がよく分からぬが、切り分けのためにも専用マシンが欲しくなるの。

>>567
CPUでの処理をなるべく軽くしたかったのじゃが、
ワープ内の他のスレッドを待たせることになるというデメリットもあるの。

そのままreturnして、そのスレッドはそれ以上検索しないのをまずは何とかしようと
データ構造の見直しも考えておったのじゃが、キーの情報は30ビットじゃから
出力全体をuint32の配列にしてCPU側で色々と処理するのもよさそうじゃの。

>>568
SP-boxはS-boxにP転置を施したものをそう呼んでいる実装がいくつかあって
発想としては主様と同じかと思いんす。

>>569-570
KSの生成にグレイコードやパスカルの三角形を使う方法もあるのかや。
わっちの頭では思いつきそうにもないの。

ループカウンタの話はBest Practices Guideの6.3かの。
オーバーフローの検出のしやすさでコンパイラでの最適化のしやすさが変わるのかの?
大量のドキュメントを読むのは面倒じゃが、やはり重要じゃの・・・

一般向けのGeForceシリーズでは倍精度の性能に制限がかけられていたり、
モデルによってはそもそも一部のユニットしか倍精度に対応していなかったりするようじゃから
64ビット整数も同様なのではないかの。

572 :,, ・´ ∀ `・ ,,)っ-○○○:2011/09/27(火) 21:30:02.90 ID:Ff64VZNS0
やあ。
やっぱし同じところで躓いてるんだな・・・

命令コードのサイズに縛りさえなければ、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にも懲りずに自分を追い込んでみる

574 :,, ・´ ∀ `・ ,,)っ-○○○:2011/09/27(火) 21:50:29.32 ID:Ff64VZNS0
てかKSの生成自体はってそんなに時間食わなかったと思うんだけど。
まさかとは思うけど、KS生成のたびにキー文字列を律儀にtransposeしてる?


#ABCDEFGH
とする。これを前半のABCDとEFGHにわけよう。
EFGHの部分は128個のキー全く別々の文字列にしてパックする。
ABCDの部分は同じ文字をパックする(転置したビットパターンは00000000かFFFFFFFFで表現できる)
シーケンシャルに変更して最後まで達したらEFGHの部分を再生成する。

あと、transposeは1ビットずつちまちますんなよ。
http://www.hackersdelight.org/HDcode/transpose32.c.txt


575 :,, ・´ ∀ `・ ,,)っ-○○○:2011/09/27(火) 22:06:22.17 ID:Ff64VZNS0
> ののたんぺ
初歩的なことだけど、CUDAの機械語でサポートしてるビット論理演算って
未だにand, or, xor, notだけなの?

http://www.openwall.com/john/
もう4ヶ月前の話ですまんが、なにやらJtRの人がvselを使った最速のS-box作ったらしい。
JtR本体はGPLだけど新しいS-boxは劣化BSDライセンスで使えるから関係各位は
とりあえずマージしとけばいいよwww

576 :(の◇の) ◆wordlist..nn :2011/09/27(火) 23:38:49.17 ID:HJ0c15LV0 ?DIA(289888)
ダニーはもうトリップなんてものにまったく興味なくしたのかと思ってたら。w
つーかさ、情報収集能力に長けてる私にそんな情報をいまさら。>最速S-boxww
w
ww

奇怪語とかの低レベルな話はキライだって知ってるだろ?
まあ、s2uwとかつくっちゃったし、もはや説得力ないか。
ra8最高!(和良

577 :,, ・´ ∀ `・ ,,)っ-○○○:2011/09/28(水) 01:07:43.18 ID:HmbVXb9V0
まあ正直、新たに何か作る気は無い。
2chがDESだのSHA-1だのオワコンの暗号形式にこだわってるのはなぜかって
ぶっちゃけ管理者が馬鹿なだけだからな。

てか、今年11月までのレンタル料しか払ってないからあのサイトどのみち消えるよwww

578 :(の◇の) ◆wordlist..nn :2011/09/28(水) 02:01:07.65 ID:CqD8KZJs0 ?DIA(289888)
>>577
だから再配布する権利をよこせ。wいや、くれ。いあ、ください。
てゆか、上の方で言ってるのって、TXのやりかたじゃん。w

579 :,, ・´ ∀ `・ ,,)っ-○○○:2011/09/28(水) 02:02:18.81 ID:HmbVXb9V0
勝手にやってくれ

580 :(の◇の) ◆Merrypace/Ki :2011/09/28(水) 17:20:37.67 ID:CqD8KZJs0 ?DIA(289888)
そしてまた見た人全員に許可が出たものと解釈される。www

581 :,, ・´ ∀ `・ ,,)っ-○○○:2011/09/28(水) 20:03:32.46 ID:zr2WgOxu0
その辺含めて勝手にしてくれ
どうせ現状でもBrothersoftに無断配布されてるんだし


582 : ◆Horo/.IBXjcg :2011/09/28(水) 22:25:40.56 ID:GJ4vp0f00
グローバルメモリの配列を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でやっているシャッフル的な転置も可能なのでしょうか。

584 :名無しさん@お腹いっぱい。:2011/09/29(木) 08:57:25.98 ID:G7zHSudJP
なんか沸いてきた(*‘ω‘ *)…

585 :,, ・´ ∀ `・ ,,)っ-○○○:2011/09/29(木) 22:33:20.51 ID:lxDiiQb30
わーい

586 :名無しさん@お腹いっぱい。:2011/09/30(金) 07:47:22.72 ID:Gn1+CgoLP
ちんでみたらいかがでしょうか(*‘ω‘ *)?

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
◆MERIKEN4.k、生きてたらツールの検証がてら以下の依頼まわしてみてょ(*‘ω‘ *)
依頼の9完出したらツールの良い検証&宣伝?になると思うよ

-----

希望の9文字トリップはここだよな(12桁もOK) Part 0x0A
http://toki.2ch.net/test/read.cgi/qa/1299965026/732

【ターゲットのまとめ】
【wiz7用(cudaTripper12Wiz7用)】
^Tanamin.. >>116 (>>447) (コメントに#とかはいらなかったりする)
^IVIG1YNTZ # >>490 (>>442)
+GARNET/NA # >>460
+GARNET.NA
^xSx...xSx # >>495
^MINERAL. # ^MINERAL[./][./]用。 >>530
^MINERAL/
^Judgment # ^Judgment[./]用 >>539 (>>727)
^JUDGMENT
^MIDNIGHT # ^MIDNIGHT[./]用 >>571
^EasEasEas # >>663
^WaffenSS. # >>670
^WaffenSS/
^KOUGAKUBU # >>675 (>>729)
+coodellar # >>688
+YUZ/24.7/ # >>708

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は使えなかったので↑のような配列を作ることになりそれを流用した。

595 :,, ・´ ∀ `・ ,,)っ-○○○:2011/10/02(日) 14:31:47.36 ID:WkqT8ylq0
それよりだんごやさんの家の移転先どこがいいかの?

596 :名無しさん@お腹いっぱい。:2011/10/02(日) 16:45:15.84 ID:I+BxO05p0
GTX480で280M程度しかでないのですがこんなもんですか?
他のは倍出ているような気がするのですが・・・・ドライバは最新のにしました。
Windows Vista Ult 64bitです
Q6600@3.2GHzです。

597 :名無しさん@お腹いっぱい。:2011/10/06(木) 05:47:22.25 ID:V88fwpLMP
>>596
> 他のは倍出ているような
他のとは何のことでしょうか(*‘ω‘ *)?

598 :名無しさん@お腹いっぱい。:2011/10/06(木) 05:55:38.32 ID:V88fwpLMP
>>592
> おかげさまで念願の1MTrips/secに到達することができました。
よくわからんなぁ(*‘ω‘ *)
GTX480で1MTrips/sってこと?

Bitsliced-DES使わないで、wiz7はGTX460で1.5MTrips/s 出てたけど。
とあるボトルネックを解消できたら、その数倍は出そうな感じだったな(*‘ω‘ *)

なので、俺の感覚は >>466

599 :,, ・´ ∀ `・ ,,)っ-○○○:2011/10/06(木) 20:27:36.50 ID:VPnIDN5j0
VSELとか3入力のXORとかあれば高速化できるのにな。
SHA-3がもうじき決まるし次のトリップ仕様でも検討しようずww

600 :名無しさん@お腹いっぱい。:2011/10/07(金) 06:02:31.34 ID:jBgSdZ9wP
>>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の本来の仕事として行えば
速度を落とさずに色々できそうだなぁと夢がひろがりんぐ。

602 : ◆Horo/.IBXjcg :2011/10/09(日) 20:31:46.42 ID:F2WInEUp0
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も近いうちに無事登場してくれるのか気になるの。


603 : ◆Horo/.IBXjcg :2011/10/11(火) 20:38:53.91 ID:Z3/Igumv0
cuda_sha1tripper-0.5.1.zip - ttp://kie.nu/17s
cuda_sha1tripper-0.5.1_win32bin.zip - ttp://kie.nu/17t

変更は優先度を設定するのをやめたのと、コメント部分のミス修正ぐらいかの。

ローテートが無くてシフトが重いというのは厄介じゃの。
PTXにはbfiとかがあるようじゃが、それらを使うと多少はましになるのかの・・・

604 :名無しさん@お腹いっぱい。:2011/10/12(水) 10:35:30.82 ID:aOJdNQ0m0
なんでDLパスワードがかかってるの?

605 :やんやん ◆yanyan72E. :2011/10/12(水) 11:36:25.24 ID:YlMOW/Ye0
Quadro6000で何も工夫せずにやって430MTrips/sぐらい。
ちなみに64bitビルド。
ちゃんと工夫すれば800Mぐらいいくかな?

606 : ◆Horo/.IBXjcg :2011/10/12(水) 23:33:20.48 ID:qSduXUFH0
>>604
よくわかっていない者がダウンロード・実行して文句を言っても困るからの。
じゃがあのアップローダは一覧表示も無いようじゃから、その心配もあまりないかの。

>>605
Quadroとはまた凄いものを使っておるの。
SMが14基でクロックが1150MHzのようじゃからそれぐらいではないかの。

検索速度(MTrips/sec) / (SM数 * シェーダクロック(GHz))
の値はCC 2.1では28〜30、CC 2.0では26程度になるのかの。

SMあたりのコア数が増えて加算や論理演算のスループットが上がったようじゃが
スレッド数も増やせておらぬし、あまり恩恵を受けられておらぬの・・・

607 :名無しさん@お腹いっぱい。:2011/10/13(木) 01:49:43.19 ID:S7dCweos0
初期化をGetTickCountでやってるみたいだけど、それだと高々20bit程度しか乱雑性が確保できないから、事実上作れないトリップがかなり発生してるとおもう。

608 :名無しさん@お腹いっぱい。:2011/10/15(土) 11:15:27.67 ID:gtfjhqnB0
>>606
そのパスワードってどこかに書いてあるの?
それとも身内用?

609 : ◆GikoNekobg :2011/10/15(土) 14:42:38.88 ID:Tu1nrZuK0
[sage SHA-1]
    ↑ ココダイジ

610 :名無しさん@お腹いっぱい。:2011/10/15(土) 14:47:25.76 ID:ykrtu9lE0
てか>>603をちゃんと見ようぜ

611 :名無しさん@お腹いっぱい。:2011/10/15(土) 15:19:38.99 ID:gtfjhqnB0
>>609-610
その辺は既に試してみたんですが駄目でした。
が、今日もう1度見てみたところCookie要求されていたのに気付き・・・。
どもでした。

612 :名無しさん@お腹いっぱい。:2011/10/23(日) 16:50:57.54 ID:+1Fq5/Hy0
Could not create a new key container と出て起動できんのだけど、何か足りない?
GTX260、280.26、toolkit4.0.17

613 :名無しさん@お腹いっぱい。:2011/11/06(日) 10:57:49.43 ID:eJUK4Flk0
pOcac3dkOs
完全一致で検索お願いします
ここに晒してください

614 :名無しさん@お腹いっぱい。:2011/11/14(月) 07:33:06.21 ID:ycdr389Z0
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分足らずで…改めてありがとうございます!


616 :名無しさん@お腹いっぱい。:2011/12/02(金) 11:24:00.81 ID:P6+3vdJX0
>>612
同じエラーが出て実行出来ない。

Quadro FX3800, WinXP 64bit


617 :名無しさん@お腹いっぱい。:2011/12/03(土) 03:20:14.73 ID:XHicGJHcP
>>614
CUDA SHA-1 Tripper MERIKEN's Branch の

> On average, it takes 14.6 years to find one match at this speed.

ここいらの計算、9完以上だと間違ってるような気がする(*‘ω‘ *)

618 : ◆GikoNekobg :2011/12/05(月) 17:36:36.11 ID:hRwQe3tB0
ホシュ

忙しそうだねメリケンさん

619 :(の◇の) ◆Merrypace/Ki :2011/12/07(水) 10:48:47.99 ID:CQu7P/360 ?DIA(289888)
>>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

622 :(の◇の) ◆Merrypace/Ki :2011/12/08(木) 01:22:30.06 ID:R6hnS4wY0 ?DIA(289888)
ソースのエラー表示してるとこチラッと見たら、暗号化関連のライブラリ関数呼んでたし、
XPってことだから権限関係かなと思った。
エラーコードを表示させるようになってないから、原因コードがわかんないんだよね。

あとは、.NET のなんとかがいるとか、ランタイムとかそんな話かな。
MSDNライブラリとかDependency Walkerとかで確認すればわかるかもしれないけど、今日はもう寝る。w

623 :(の◇の) ◆Merrypace/Ki :2011/12/08(木) 12:25:03.91 ID:R6hnS4wY0 ?DIA(289888)
これはソースコードを変更したほうがよさそうだね。

↓開発者向け情報w
ttp://support.microsoft.com/kb/238187/en-us

624 : ◆MERIKEN4.k :2011/12/09(金) 16:01:29.11 ID:8NFpDmYO0 ?2BP(12)
皆様大変ご無沙汰しています。ここ数ヶ月本業が忙しくて
プログラミングに全く時間がさけませんでした。
いろいろ報告していただいたのに返事が出来ず
申し訳ありませんでした。

>>612さんに報告していただいたバグの件ですが、
お察しの通りCrypt APIの使い方を間違えたために発生したもので、
手元の開発版では既に修正済みです。クリスマス休みあたりに
まとまった時間が取れそうなので、近いうちに修正したバージョンを
うpします。

625 :612:2011/12/09(金) 21:19:51.55 ID:HTK8s1jz0
ありがとうございます
気長に待ってます

626 :名無しさん@お腹いっぱい。:2011/12/11(日) 12:49:39.25 ID:VjTkuKf+P
>>624
CPU検索機能付きバージョンまだー(*‘ω‘*)?

627 :名無しさん@お腹いっぱい。:2011/12/11(日) 13:11:12.01 ID:1VVjf5R40
#LLVM だれか https://github.com/chapuni/llvm-project を fork してみてくれー

628 :名無しさん@お腹いっぱい。:2011/12/11(日) 13:12:20.34 ID:1VVjf5R40
なんたる誤爆

313 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)