【トリップ検索】MERIKEN's Tripcode Finder

1 ：2012/09/25 〜 最終レス ：2012/11/02

こちらはMERIKEN's Tripcode Finderの本スレです。動作報告・質問・要望等は
こちらでどうぞ。
MERIKEN's Tripcode Finder(旧CUDA SHA-1 Tripper MERIKEN's Branch)は
2012年9月現在で最速の12桁トリップ検索プログラムです(最高速の記録は
1689.88M tripcodes/s)。CPUのみでも検索できますが、NVIDIA GeForce
シリーズのビデオカードを使用すれば非常に高速に検索を行うことが
できます。特徴は以下の通りです。
・ビデオカードのGPUによる高速検索(CPU検索にも対応)。
・GUIによる簡単な操作(コマンドラインからの使用も可能)。
・正規表現によるターゲットの指定。
・漢字等のShift-JIS文字を含むキーの探索。
・ヒット率、ヒットまでの平均時間等のさまざまな情報の表示。
・ターゲットの数の制限の撤廃。
・10桁トリップ検索への暫定的対応。
・検索速度の実行時の最適化。
・GPLv3で公開されたソースコード。
■入手先
http://www.meriken2ch.com/programming/merikens-tripcode-finder
■前スレ
http://anago.2ch.net/test/read.cgi/software/1311428038/

2 ：

■動作環境
【OS】Windows XP/Vista/7/8
【ビデオカード】NVIDIA GeForceシリーズ (ビデオカードがなくてもCPU検索は可能)
【その他】使用するためには次のソフトウェアが必要です。
Microsoft Visual C++ 2010 再頒布可能パッケージ(x86)
http://www.microsoft.com/ja-jp/download/details.aspx?id=5555
Microsoft .NET Framework 4
http://www.microsoft.com/ja-jp/download/details.aspx?id=24872
NVIDIA Display Driver Version 270.81以降 (ビデオカードを使用する場合)
http://www.nvidia.co.jp/Download/index.aspx?lang=jp

3 ：

テンプレは以上です。

4 ：

なるほどね

5 ：

>>1
乙です。

6 ：

>>5
どもども。このスレでもよろしくお願いします。

7 ：

トリップ検索ソフトとか懐かしいなー
昔Athlonだったのでmtyとか使ってた
当時10Mtrips/sで神だったのが1500Mとかどうなってるんだよｗ
トリップ12桁になったから単語の自由度も増えてそれでも探し飽きることはなさそうだけど

8 ：

>>7
次の目標は2G超えですｗ トリップ探しは結構面白いですよね。正規表現が
使えるようになったのでかなり自由に探せるようになりました。

9 ：

しばらくGUI版ばっかりつかってますけど、やっぱり細かいところがいろいろ
気になって来ました。やっぱ一時停止の機能は必要ですね、これ。
Win32のメッセージ通信を使うしかないのか…

10 ：

前スレで報告していただいた正規表現のバクですけど、こちらでも再現できました。
以前からどうも怪しいと思っていたので、具体的な例が見つかって大変助かりました。
問題はこれからどうするかということなんですけれども…

11 ：

で、問題の組み合わせはこれです。すぐにヒットするはずの"^AAA\.\."が
ヒットしないのです。
#regex
^[Aa]+$
^\.+$
^\.*AAA\.*$
^AAA\.\.
正規表現のパターンは内部である程度展開されているんですけど、
問題があるとしたら、(1)展開の仕方か、(2)検索時の見逃しか
どちらかのはずです。

12 ：

内部変数をダンプしたらあっさり原因がわかりました。
> expandedPatternArray[ 10] = {`AAA..', 0}
> expandedPatternArray[ 11] = {`AAA.........', 0}
この部分でexpandedPatternArray[11]の条件が
expandedPatternArray[10]の条件と重なっているのが問題だとおもわれます。
expandedPatternArray[11]を取り除くようなルーチンを書いてやれば
解決するはずです。今あまり時間がないので今晩やろっと。

13 ：

AMDがなんかツール出したみたいだな
http://developer.amd.com/tools/hc/CodeXL/pages/default.aspx

14 ：

>>13
今去年組み立てたPCにWindows 7をインストールしているところです。
Radeon HDとOpenCLの組み合わせが楽しみです。

15 ：

前スレで報告していただいた正規表現のバク(>>10-11)はあっさり直りました。
たま〜に引っかかるはずのパターンがなかなか引っかからなくて気にはなっていたのですが、
これで本当にすっきりしました。報告していただいてありがとうございました。

16 ：

バグ報告した者です。迅速なご対応に感謝致します。
最強のツールにまた一歩近付きましたね。

17 ：

>>16
どもども。これで野望にまた一歩近づきましたｗ

18 ：

AMD APP SDKをインストールしてみましたけど、
サンプルの一部が最新のSDKに対応していなかったりと
投げやり感が半端ではありません。「資料がない」という話は
よく目にしたけど、こういうところもCUDAのほうに開発者が
流れる原因になっているんでしょうねえ。
出来ればひとつのバイナリでNVIDIAとATI/AMDの両方のグラボに
対応させたいので、OpenGLについてはのんびり調べてみたいと思います。

19 ：

GLじゃなくてCL
つかCLはバイナリ互換でなくてソース互換だったような…

20 ：

>>19
またやらかしてしまった… 「一つのバイナリで」と書いたのは
一つの実行ファイルでCUDAとOpenGLの両方に対応する、という意味です。

21 ：

また「OpenGL」って書いてしまった。もう癖になってるんだろうな…
サンプルを見てたら、とりあえずOpenCL.libをリンクして
CL/cl.hppをインクルードしてやればOpenCLのAPIは呼び出せるらしいことが
わかりました。なんとか楽をして既存のプロジェクトからAPIを
呼び出せるようにしたいところです。

22 ：

サンプルを参考にして自分で新規のプロジェクトを作成して
OpenCLのカーネルを呼び出すことに成功しました。これで
環境は整ったので後はひたすらOpenCLのコードを書くだけです。
しかしこれ、アプリケーションを実行するたびにカーネルをコンパイル
するようになっているんですね。デバッグとか超めんどくさいことに
なりそうな予感…

23 ：

>>22
コンパイル済みのバイナリを与えること(オフラインコンパイル)も可能だけど、
いろんなデバイスで使われる場合は実行時のコンパイル(オンラインコンパイル)でないとつらいのかな

24 ：

>>23
やっぱりそういう機能もあるんですね。CUDAだとコンパイル時にComputing Capabilityを
幾つか指定できるようになってますけど、AMD APP SDKの場合はどうなんだろう…

25 ：

まあでも本格的にOpenCLに取り組む前に今のバージョンの安定版を出すほうが先です。
とりあえず一時停止の機能を何とかしないと…

26 ：

どうやって一時停止の機能をなるべく楽をしながら組み込むか考えていたのですが、
とりあえずMutexを試してみることにしました。計算資源をMutexで管理すると
考えるわけです。

27 ：

Mutexを使った実験は無事成功して、検索プロセスから一時停止の状態を
検知することができました。これであとは検索プロセス側の処理を
実装するだけです。

28 ：

検索の一時停止の機能の実装は無事に終わりました。
Mutexが使えるのがわかってからはかなり楽でした。
Mutexを一時停止状態を表すフラグとして使っているので
本来の使用法とはだいぶ違うのですが、うまく動いているので
問題ないでしょう。GUIをあとちょこっと直してから
明日辺りにBeta版をうpする予定です。

29 ：

さっきまたちょっといじって「上へ」ボタンと「下へ」ボタンを追加して、
検索パターン一覧内でパターンの位置を移動できるようにしました。
ちょっとした変更ですけどかなり使い勝手が違ってきます。
Visual C#はVB並のお手軽さでロジックをそのままの形で記述できるのが
実にいいです。あとはエラーチェックの気になっている部分を直したら
Beta版の完成です。

30 ：

開発お疲れ様です。
ちょっとリアルが忙しかったんでGUI版テストしてませんでした。
せっかくCPUスレッド数の指定とかも盛り込んでもらったのにすみません。
今から回してみます。

31 ：

>>30
GUI版ぜひ使ってみて下さい。1週間でC#を勉強しながら
作った割にはいい出来ですｗ

32 ：

>>31
すごく使いやすいですよ。
それとブロック/スレッド各オート時で
自分で設定詰めたものとあまり遜色ないくらい速度出てます。
安定して速度が出始めるまでには5分から10分はかかっていますが
細かく設定詰めなくてもここまで出るのはユーザ側にとってはかなりありがたいかと。

33 ：

>>32
「お手軽に最高の性能を出す」のが目標なのでそう言っていただけると
嬉しいです。性能改善という点ではCUDAではほぼやれることはやり尽くしてしまった
感があるので、やっぱり残りはCPU検索とRadeonへの対応ですね。

34 ：

>>33
そのコンセプトからするといい方向かと。
DOS窓でコマンド打ってまでやろうと思わない人のほうが多いでしょうしｗ
ただ、CPUのオートについてはまだ改良の余地があるかもしれません。
オートより6スレッドの方が自分の3820QMじゃ安定して速度出てました。
オートだと100%使い切っちゃってましたし。GPUドライバ周りのCPU負荷が高そう。
自分の使った感想だと6スレッド≧7スレッド＞8スレッドでした。トータル速度的にも。
トリッパー回しながらPCを使うという場面を想定してもオートだときつかったです。
いちおCPUは非力じゃないはずなのにオートだとまともに文字打てなくなりましたから。
ただ、CPU単体検索という面に於いても従来のソフトの2倍近く速度は出てるんじゃないですかね。

35 ：

手持ちのDualCPUのXeon 5080(NetBursｔ)と8800GTXの組み合わせだと12桁で
自動だと 132.72M
8スレッド 131.05M
7スレッド 132.40M
6スレッド 131.47M
みたいな結果となりますのでCPUの種類によっては自動が最適なんてこともあるみたいですよ
CPU検索のみを実行しますと
オート設定だと12.49M
8スレッドだと12.41M
7スレッドだと11.18M
6スレッドだと10.32M
5スレッドだと9.28M
4スレッドだと8.19M
3スレッドだと6.23M
2スレッドだと4.25M
1スレッドだと2.11M
という結果で同時期のハイエンドGPUの8800GTXは
GPU単体だと121.35Mなので10倍近く高速と言う結果となります
あと負荷掛け続けるとCPUが過熱し過ぎたのか警笛が鳴って焦ったｗ
やはりGPGPUはエアフローに気を付けないとCPUも熱くしてしまうので要注意ですね

36 ：

>>34
CPU検索の自動設定は、何も考えずにCPU検索スレッドの数を
「(論理スレッドの数) - (GPUの数)」に設定しているだけなので、
これも変える必要がありますね。たぶんIntelの石ではhyper-threadingの
おかげでスレッド数を下手に増やすと遅くなる場合もあるのでしょう。
ここらへんはもうちょっと調べる必要があります。
現在の実装だととにかく速度を出すために目一杯計算資源を使っているので、
利便性の点からはかなり改善の余地があるでしょうねえ。検索スレッドの
優先度を低く設定してやるのも手かもしれません。今考えているのは検索の設定で
速度を「速い」とか「最大」とか「ゆっくり」とかから選べられるようにすること
です。GUIの実装が一段落したらぜひ取り組みたいですね。

37 ：

>>35
詳しい報告、ありがとうございました。スレッド数を増やしてもペナルティに
ならないのはやはりXeonだからなんでしょうかね。非常に興味深いところです。
8800GTXも結構速度が出てますね。テスト用に一個欲しいところです。
このプログラムはシステム全体にとんでもない負荷をかけるのでかなり注意する
必要がありますね。私のメインのデスクトップPCはケースの蓋が開けっ放しです。
次からははじめからこんなの
http://www.dangerden.com/store/popup_image.php?id=428
か、こんなの
http://www.dangerden.com/store/popup_image.php?id=250
にしておきます…

38 ：

あれ、写真が出てこないや。元のリンクはこっちです。
http://www.dangerden.com/store/dd-torture-rack.html
http://www.dangerden.com/store/dd-extended-air-box-eatx.html

39 ：

それはそうと、ウィンドウの状態の保存の処理をすっかり忘れてたので
現在実装しているところです。とりあえずここのコードを使わせてもらって
ウィンドウの位置は保存されるようになりました。
http://stackoverflow.com/questions/105932
あとは各タブの状態を保存してやるようにすればGUIの実装は一段落ということに
なります。

40 ：

>>35
そこはどうなんでしょね。
Keplerは従来よりもCPU負荷がきついですから
Fermiまでとは違うという事も考えられます。
いずれにせよ色々なプラットフォームで自動で最高の結果を出そうとすると
相当にデータ集めが必要なんだと思いますよ。単純に。
ホントにプログラミングとかかじったこともないド素人の意見ですけども。

41 ：

つーかごめんなさい個人的なことをいうと
俺のノートはパワーもないしOCの幅もないけど、開発に携われるだけでうれしいです。
新バージョンにクレジットしてくださっただけでも本当にうれしかったです。
できることはできる範囲で全力でやります。

42 ：

>>40
> Keplerは従来よりもCPU負荷がきついですから
こういう要素もあるんでしょうねえ。最適化の作業を進めていると
各Compute Capability毎に1枚テスト用のカードが欲しくなりますけど
流石にそんなわけにもいかないですからねえ。こうやって色々報告していただけると
助かります。

43 ：

あとテスト報告ですけども
3820QM+GTX680Mの最新版でのベストスコアは
GPU(224Bl/SMX)：294+CPU(6T)：26の320MT/sでした。
これは瞬間値じゃなくて長時間平均をとりました。
CPU、GPUそれぞれの単体でも従来よりずっと速いです。

44 ：

>>41
私としてはこのプログラムができるだけいろんなグラボで動くようになればいいと
考えているので、グラボの性能自体はそれほど気にしていないのです。実際のところ
ちゃんと動いているのが確認できて安心しましたｗ

45 ：

>>43
Keplerちゃんもなかなか頑張ってますね。CCが3.0の場合はCPU検索スレッドの数を
1つ減らしてやるぐらいがちょうどいいのかな。あとで修正しておきます。

46 ：

>>45
今までのことを考えるととんでもないスピードだと思いますよコレ
確かにFermiの方がCUDAは速いけどもKeplerでも十分に速いと思います
というか構造上KeplerにCUDAのスピード求めるのも酷ですしね
あとノートは数日前にGTX6xxMXが発表されてKepler化がどんどん進むと思われます
こんだけ省電力で3D性能(に限って言えば)上昇してればKeplerシフトは進むわなぁ

47 ：

同じG80コアであるGeForce8800GTXとQuadroFX4600の同時使用は可能みたいですので
やはり動かす時は同じComputing Capability同士のGPUを使用した方が良さそうです
ついでに12桁での速度は
FX4600単体で80.25M
GPUx2で202.17M
CPUGPU込みで210.00M
消費電力は最大664Wとかなりの電気食いです

48 ：

というかNetburstベースのXeonの効率の悪さに驚愕ですね
548Wも食って12M位しか出ないCPU
552Wとチョイ上回る程度で202MもでるGPU…

49 ：

>>46
ま〜ノートにFermiとか想像できないですからねえ。7xxシリーズでも
一部はKeplerのままかもしれません。

50 ：

>>47-48
Compute Capabilityが違うカードのために幾つかcubinを用意してるんですけど、
これらのバイナリを同時に使うことは出来ないということなんでしょうね。
さっきソースでエラーチェックを怠っていた場所を特定したので、
新しいバージョンではちゃんとエラーが出るはずです。
Netburstはもう仕方がないですね。自分の使ってたPentium 4もとんでもない
爆熱仕様でした…

51 ：

バージョン0.05のBeta版が出来ました。
MERIKEN's Tripcode Finder 0.05 Beta 1
http://www.meriken2ch.com/programming/merikens-tripcode-finder
今回の変更点は以下になります。
・ウィンドウの設定の保存。
・GUIの改善。
・正規表現のバグの修正。
・エラーチェックの改善。
このバージョンに問題がなければ、これをこのまま安定版にする予定です。

52 ：

さっきうｐしたばかりのBeta版ですが、うっかりエラー処理の不具合を
見逃していました。すいません… 修正したバージョンに差し替えておいたので
ダウンロードされた方はお手数ですがもう1回お願いします。
MERIKEN's Tripcode Finder 0.05 Beta 2
http://www.meriken2ch.com/programming/merikens-tripcode-finder

53 ：

>>49
いやーそれがノートの6xxシリーズでも675Mとか670MなんかはFermiなんですよ。
そして当然ながら、全く同じ環境でも680M比で675Mは温度が10度以上高い。
真夏とはいえ、ゲームやるとGPUが90度オーバーとかいうトチ狂った温度になってましたから。
しかし675Mは580Mのリネームな上に
今度は(多分)Keplerの675MXを出すとかなんで分かりづらすぎです。

54 ：

今、ベータ版廻させて貰ってまけどT9600 2CHで、５時間目で2.8Mt/sってところですね
思ったような酉が出てきてないのでもう少し廻しますが、WCG構造解析しながらでこれは結構出てると思います
便利なツールをありがとうです

55 ：

>>53
90度で常用だとかなり不安ですねえ。一応設計上は97℃まで大丈夫なはずですけど…
>>54
どもども。CPU検索はもうちょっと速くしたいですね。

56 ：

AMDのグラボについて調べてたんですけど、7xxxシリーズから大幅に
アーキテクチャが変わっているそうで… 今持ってるのは去年試しに買った
5770だけなので、とりあえずコードをOpenGLで動くようにしてから、
最適化をおアーキテクチャ毎に行うことになりそうです。
まあなんにせよOpenGLへの移植はかなりの長丁場になりそうなので、
CPU検索の性能向上と並行して行うことになるでしょう。

57 ：

tesla K20が出るとさらに凄いことになりそう

58 ：

さて、バージョン0.06の目標はCPU検索の速度向上なんですけど、
とりあえず簡単そうな12桁検索のほうから手を付けたいとおもいます。
次のコードが良さ気なんですけど、まずアセンブルできる環境を
整えないといけないですね…
次のはIntelの開発者が作った64bit版のルーチンで、
Improving the Performance of the Secure Hash Algorithm (SHA-1)
http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1?page=1
こっちが32bit版らしいです。
http://cvs.openssl.org/fileview?f=openssl-addons/intel-accel/sha1-586.pl&v=1.1

59 ：

>>57
Tesla K20も試してみたいけどさすがにお値段が…
K10も$3200ぐらいですからね。

60 ：

CPU検索の速度向上は期待大です
GPUと並行できるのってかなり強みだと思います

61 ：

今のCPU検索の実装は10桁検索の実装の副産物なので、
性能的にはそれほど最適化されてないのです。
どうやらSSE3をつかえばかなり高速化出来るらしいということまでは
わかったのですが…

62 ：

そういえば10桁検索ツールのほとんどがSSE2止まりでしたね
開発進行中なのはMERIKENさんのだけじゃないでしょうか

63 ：

OpenSSLのperlのコードからなんとかGNU asのコードを取り出したいところです。
…などと書いてたんですけど、Macで次のコマンドを実行したらNASM用のコードが
出てきました。
perl sha1-586.pl win32n
出力もそれっぽいし、面倒くさいこと無しにこのまま使えるかも…
> %ifidn __OUTPUT_FORMAT__,obj
> section code use32 class=code align=64
> %elifidn __OUTPUT_FORMAT__,win32
> $@feat.00 equ 1
> section .text code align=64
> %else
> section .text code
> %endif
> ;extern _OPENSSL_ia32cap_P
> global _sha1_block_data_order

64 ：

>>62
一応今の開発環境だとAVXまで対応できるんですけどねｗ
色々面白いことが出来るんじゃないかという気はしますけど、
x86系のアセンブラをいじるのはそれこそ10年ぶりぐらいなので、
今後の進展は神のみぞ知るといったところです。

65 ：

SSE3以降は各社の足並みが揃うのがかなり遅かったですし
無理に最新の拡張命令に対応する必要もないと思いますけどね

66 ：

色々ググってたら面白いことが分かりました。
このSSE3用の_sha1_block_data_orderというルーチンは、
どうやら次のEric Young氏によるSHA-1の実装と組み合わせて使うらしいです。
> # define HASH_BLOCK_DATA_ORDER sha_block_data_order
　　　　:
> __private_extern__ void HASH_BLOCK_HOST_ORDER (SHA_CTX *c, const void *d, int num)
http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-7/Source/sha_locl.h
これはかなり楽して速度を上げられそうな予感…

67 ：

>>65
SHA-1ではAVXは使いませんけど、実はAVXによるBitslice DESの実装にはかなり
興味があるのです。なんせレジスタ長が128bitから256bitになっていますからね。
Bitslice DESの特性を考えれば、AVXによる恩恵を直接受けられるのではないかと
思われます。その前に10桁検索をSSE2に対応させるのが先なんですが…

68 ：

興味をお持ちの分野から着手なさるのがいいかと。
それが有限の時間の中で一番効率がいいと思います。
我々下々にくだるご光栄のおこぼれも増えると思われます。
must to do 事項はなかなかしんどいですから。
ああ私は他力本願‥‥‥

69 ：

エラーログに12完トリップキーを記録させて搾取するのがいいと思います(適当)

70 ：

>>67
うちのIvyちゃんにできることがあれば…
ワッパは少なくともこのスレじゃ最強なはずだし気楽に回せますよ。
全開でもCPUは45Wとかですから。

71 ：

>>58
intelのなら特許からんでくるかもね(*‘ω‘*)

72 ：

>>71
Intelの中の人のコードは利用は自由だと書いてあるので問題ないでしょう。
> It is provided 'as is' and free for either commercial or non-commercial use.
http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1?page=1

73 ：

32bit版のSHA-1のコードはOpenSSLとCRYPTOGRAMSのデュアルライセンスで、
GRYTOGRAMSはGPLと互換性があるので、こちらのコードも
MERIKEN's Tripcode Finderで使用するするのに問題はないでしょう。
> ALTERNATIVELY, provided that this notice is retained in full, this
> product may be distributed under the terms of the GNU General Public
> License (GPL), in which case the provisions of the GPL apply INSTEAD OF
> those given above.
http://www.openssl.org/~appro/cryptogams/

74 ：

>>68
とりあえず今はSSE3を使ったSHA-1のコードを動かすことが最優先です。
>>69
12完とか数世紀単位ですよw
>>70
新しいバージョンのテストをぜひよろしくお願いしますです。

75 ：

ちょこちょこといじっていたら、ちゃんとsha1-586.asmを
アセンブルして実行ファイルにリンクできました。
ここまでは簡単すぎて拍子抜けするぐらいです。
問題はこのルーチンを実際にどうやって使うかなんですけれども…

76 ：

Eric Young氏のコードを参考にしてアセンブラのルーチンを呼ぶ出すコードを
書いたら、信じられないことに1発で動きました! でもperlのスクリプトで
何もオプションを指定しなかったせいか速度はそこそこです。SSE3を使うコードを
生成させるオプションがあるはずなんだけどなあ…

77 ：

SSE3じゃなくてSSSE3でした。紛らわしすぎだろう…
何やら内部で外部変数を参照してCPUの種類の判別をしているみたいなんですが、
何をやっているのかさっぱりわかりません。"_OPENSSL_ia32cap_P"って
なんなんだろう…

78 ：

とりあえずで書いたコードが思い通りに動くと発狂したくなるぐらい嬉しいよな

79 ：

>>77
こいつですね
http://www.openssl.org/docs/crypto/OPENSSL_ia32cap.html
CPUIDを読みだしてプロセッサを判別する…ってことか

80 ：

>>72
ちゃんと特許検索してみ(*‘ω‘*)

81 ：

>>78
ここまですんなりいくとは思いませんでしたｗ
何事もためしてみるもんですね〜
>>79
間違い無くそれですね。とりあえずその変数をチェックしている部分は
全部削除してしまうことにします。

82 ：

CPU判定をしている部分を全部削除したらとりあえずSSSE3のコードは動きました。
…が、スピード自体はかなり微妙です。確かに今までのコードよりちょこっと速く
なってることはなってるんだけど、思ったほどではないです。これはもともと使っていた
SSE2 Intrinsicsで書かれたルーチンがかなり速かったということなのかなあ。

83 ：

う〜ん、しかしこうなるとオリジナルの64bit版のSHA-1のルーチンも試してみたく
なるな… 64bit対応はもうちょっとあとにする予定だったけど、せっかくCPU検索の
速度向上に取り組んでるんだから前倒しにするのもいいかもしれないですね。

84 ：

32bit版と64bit版はGUIのほうで選ぶようにすれば楽に実装できるはずです。
あ、あとアプリケーションを終了させたときに.NETの例外が稀に発生するバグを
見つけました。バージョン0.05の安定版では直しておきます。

85 ：

さっきまたバグを見つけました。一時停止てからすぐに再開すると、ごくまれに
経過時間が1ヶ月分増えてしまうのですが、これも直しておきました。
結構色々でてくるもんですねえ。

86 ：

64bit版を試しに作って動かしてみたのですが、なんとなにもしないのに
12桁検索が32bit版よりも5M TPSほどはやくなっていました。13%ほどの
速度向上になります。やっぱりx64のほうが効率がいいって本当だったんですね…

87 ：

で、SSSE3を利用した64bit版のSHA-1のルーチンを動かしてみたんですが、
これも一発できちんと動いたものの速度の向上はわずかでした＼(^o^)／
今まで使っていたSSE2 Intrinsicsで書かれたルーチンが予想外に効率が良かった
というわけです。まあ64bit版と定格のCore i7-3770K単体の組み合わせで
40M TPSを超えてるんで結構な速度なんですけど、なんとも微妙な結果です。

88 ：

う〜ん、しかしこうなるとできることは限られてくるなあ。
とりあえず64bit版が大分速くなるということはわかったので、
これはバージョン0.06で使えるようにしておきます。
とりあえず12桁の方はこれ以上何も思いつかないので、今度は10桁トリップの
CPU検索のほうを速くしようかな。こっちは最適化の努力を全くしてなくて
SSE等のSIMD命令を一切使っていないので、速くなることは受け合いですｗ
まあ今の実装が遅すぎるだけなんですけれども…
CUDAのときのようにガリガリに最適化されたJohn the Ripperの実装を
持ってきてもいいし、自分でIntrinsicsを使ってちまちま最適化してもいいし、
色々手はあります。

89 ：

10桁CPU検索はmtyの64bit版が最速かな？
超えられるようにがんばって！

90 ：

>>89
AVX無しでmtyを超えられたら言うことないですねｗ
色々やりたいこともあるので当分の間楽しめそうです。
なんだかオラ、ワクワクしてきたぞ!

91 ：

>>90
AVXってちゃんとした整数演算を256bitでできるんけ(*‘ω‘ *)？

92 ：

さて、10桁トリップのCPU検索の高速化のために、テスト用のコードを切り出しました。
これで遠慮無くIntrinsicsを使ってコードを書き直せます。
まず最初にCで書かれたBitslice DESのルーチンをSSE2で書きなおして、
それからさらにAVXを使って書きなおしてやる予定です。AVXはレジスタ長が
倍になっただけのはずなので問題ないでしょう。

93 ：

あと、OpenCLへの移植のために、去年組んだPCを切り替え機を
使ってメインのモニタと入力装置につなげてやりました。これで気軽に
移植の作業ができます。1年ぶりぐらいにPC周りを大掃除したんですけど、
やっぱ整理整頓って重要ですね…

94 ：

ニヨニヨうぉっち用トリップその1(*‘ω‘ *)

95 ：

ニヨニヨうぉっち用トリップその2(*‘ω‘ *)

96 ：

バージョン0.05の安定版をうｐしました。
MERIKEN's Tripcode Finder 0.05
http://www.meriken2ch.com/programming/merikens-tripcode-finder
>>84-85のバグを修正した以外は、Beta 2と同じです。

97 ：

MERIKEN's Tripcode Finder 0.05
CUDA DEVICE
CUDA Device Count: 1
Device No.: 0
Device Name: GeForce GTX 460
Multiprocessor Count: 7
Clock Rate: 1400MHz
Compute Capability: 2.1
CPU
===
Number of Processors: 8
Number of Search Threads: 7
TARGET(S)
=========
0: "TEST//"
TRIPCODES
=========
◆TEST//xz05/X #BｱXｸC｡Vﾗ∀Zｵ (42 B1 58 B8 43 A1 56 D7 81 CD 5A B5)
STATUS
======
Performing a forward-matching search for 1 pattern (1 chunk)
with 6 characters on CPU and GPU(s):
CUDA0: 271.5M TPS, 48 blocks/SM
0.105T tripcodes were generated in 0d 0h 5m 58s at:
302.28M tripcodes/s (current)
GPU: 280.99M tripcodes/s
CPU: 21.29M tripcodes/s
291.47M tripcodes/s (average)
On average, it takes 2.7 minutes to find one match at this speed.
1 match found at 10.04 matches/h and 104.53G tripcodes/match.
The actual matching probability is 34% lower than expected.
0% of matching tripcodes were invalid.

98 ：

>>97
あ、早速有り難うございます。CUI版もちゃんと動いていますね。
GUI版の作成にあたってCUI版にもある程度手を入れざるを得なかったので、
ちゃんと動作するかどうか不安だったんですよね〜

99 ：

今朝は10桁トリップのCPU検索の作業をしていたのですが、
Bitslice DESのルーチンをまとめてえいやっとSSE Intrinsicsで書きなおしたら
案の定動きませんでしたorz おとなしく動作確認をしながら少しづつ
書き直すことにします…

100 ：

>>98
うちはGUI版で動かしてますが問題なしですよ
ばっちり動いてます

101 ：

8800GTX+FX4600の組み合わせですが今までどおり問題ないですよ
0.05 Beta 2からの修正だと思いますが
CC1.0のGPUでは現状対応していないと思われる10桁検索は
GUIの方はちゃんとダイアログが出てエラーで止まるようになってますし
CUIの方も[-l 10]で警告が表示されるようになってます。
MERIKENsTripcodeFinderCUI: CUDA FUNCTION FALL FAILED: too many resources request
ed for launch (file 'C:/Users/Nullpo/Documents/Visual Studio 2010/Projects/MERIK
ENsTripcodeFinderCUI/Source Files/MTF_CUI_CUDA_DES.cu', line 832)
MERIKENsTripcodeFinderCUI: CUDA FUNCTION FALL FAILED: too many resources request
ed for launch (file 'C:/Users/Nullpo/Documents/Visual Studio 2010/Projects/MERIK
ENsTripcodeFinderCUI/Source Files/MTF_CUI_CUDA_DES.cu', line 832)

102 ：

>>100
それはなによりです。自分もGUI版をしばらく使ってますけど、
色々気になるところを直してようやく馴染んできた感があります。
>>101
そうですそうです、エラー処理のいい加減だったところがちゃんと直っているようで
良かったです。しかし10桁検索のルーチンはCC1.0でも動くように書いといた
はずなんですけど、共有メモリかレジスタ数の関係で動かないみたいですね。
注意書きに追加しておきます。

103 ：

>>99の続きです。SSEで書きなおしたルーチンはようやく動くようになりました。
128個のキーを同時に処理できるのはちょっと感動します。
Intrinsicsの使い方を間違えて大いにはまりましたが、あとはBitslice DESの
ルーチンを実際の検索ルーチンに組み込むだけです。

104 ：

組み込みは無事終了しました。バージョン0.05の10桁CPU検索の速度は
2.77M TPS（ｗ だったのですが、SSEで書きなおしたら9.22M TPS出ました。
332%(!)の速度向上ということになります。さすがに4倍というわけには
いきませんでしたが、それでもかなり綺麗にスケールしています。
これは32bit版での数字なので、SSEのレジスタ数が倍になる
64bit版での速度が楽しみです。

105 ：

私も楽しみです^q^

106 ：

64bit版もすんなり動きました。12.21M TPS出ているのでこれまでのバージョンと
比べるとかなり速くなりました。まあでも同じCPUでmtyでは25.06M TPS出ているので
性能的にはまだまだこれからといったところです。
とりあえずはCUDAのときと同じようにS-Box内の一時変数の割り当てを手作業で
最適化することになりそうですが、アセンブラを使わずにSSE Intrinsicsのみで
どこまで最適化出来るかは未知数です。John the Ripperのアセンブラで書かれた
Bitslice DESのルーチンを使用することも考えたのですが、ABIの違いも考慮しなければ
いけないのが悩ましいところです。

107 ：

ためしにS-Boxを書き換えてみたんですが、速度は全く変わりませんでした。
あとついさっき気づいたのですが、64bit版ではGPU検索が正常に作動しないようです。
このままではまずいので、とりあえず今のバージョンを修正して、GUIで32bit版と
64bit版を切り替えられるようにしてから次の開発版として公開する予定です。

108 ：

今後の方針を考えてたんですけど、やっぱりJohn the Ripperのアセンブラで書かれた
Bitslice DESの実装を使ったほうが手間がかからないだろうという結論に達しました。
もう既にギリギリまで最適化された実装があるのに自分で同じ事をやるのも
二度手間ですよね…
問題なのはJohn the RipperがGCCとGNU asを前提としていることですが、
MinGWを使えばVC++から呼び出せるライブラリを作成できそうです。
Using libs/dlls compiled in Linux/MinGW in Visual Studio
http://stackoverflow.com/questions/1291594
MSVC and MinGW DLLs
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
まず>>107の作業を終わらせて、それからMinGWをインストールして
John the Ripperの実装を試して見ることにします。

109 ：

>>107の不具合の原因が分かりました。複数のグラボを使用して検索するときに、
複数のGPU検索スレッドから同一のデバイスポインタを参照していたのが原因なようです。
結局いままで32bit版と580 SLIでちゃんと動いていたのは運が良かったから、というのが
真相のみたいです。これで前スレで報告されていたバグも説明がつきます。
> 987 ：名無しさん＠お腹いっぱい。 ：sage ：2012/09/26(水) 05:20:29.44 (p)ID:39pEz/Td0(3)
> Win7x64 295.73で8800GTX+GT520のDual環境ですが
> MERIKENsTripcodeFinder_0.05_Alpha_1のMERIKENsTripcodeFinder.exeだと
> 単体では8800GTX、GT520共にに動くのですが
> 使用するGPU：をすべて使用にしてしまうと落ちてしまうのです
> やはりCompute Capabilityのサポートに違いがあるGPUの
> 同時使用はマズイという事なんでしょうかね
http://anago.2ch.net/test/read.cgi/software/1311428038/987n
いや〜、未だにこんな大きなバグが残っているとは思いませんでした。
前スレの987さん、ありがとうございました。

110 ：

それはそうと、最近こんな話を見つけました。
http://www.obr-hardware.com/2012/09/exclusive-some-geforce-gtx-780-details.html
どうやらGTX 780はGK110ベースにはならないそうで…
今のうちにお安く590買っておいたほうがいいのかしらん。

111 ：

遠くから期待してます

112 ：

>>111
野望はRadeonにも対応して12桁と10桁の両方で最速のトリップ検索プログラムを
作ることですが、はたしてどうなるんでしょうねえ。

113 ：

>>109
お役に立てて光栄です
今度の修正がきたら8800GTX+GT520の
組み合わせで再度試させてもらいます
それとGT520やCPUで10桁検索を行った場合に出る
○.○世紀という表記は何かのギャグかと思いましたよ

114 ：

>>113
ぜひよろしくお願いします。
「世紀」の表示はプログラムを書いているときは大真面目だったんですけど、
実際に見るとかなりシュールですよねｗ

115 ：

とりあえず64bit対応版は出来ました。「詳細設定」からCPUの
命令セットを切り替えられるようになりました。
やってることはCUI版のx86のビルドとx64のビルドを切り替えてるだけなんですが…
で、OCしてどれぐらいスピードが出るか試してみたんですが、
前スレの12桁検索の最高速の記録にきれいに6M TPSほど上乗せできてます。
10桁のほうも113M TPSほど出るようになりました。
楽して速度向上、おいしいです（＾q＾）
もうちょっと色々テストしてから日曜の夜までには新しい開発版をうｐする予定です。

116 ：

29万パターンを10桁GPU検索させたらグラボが停止しました
12桁の方は正常動作します

117 ：

>>116
グラボは何を使っていますか? ある程度早いグラボならブロック数を減らして
レジストリをいじれば動かせるかもしれません。詳しくはREADME.txtを
参照して下さい。

118 ：

10桁CPU検索のルーチンを修正してたら突然スピードがどんどん遅くなるという
不思議な現象が出ました。色々いじっても直らなかったので頭を抱えていたのですが、
なんとOCしていたIvy Bridgeが熱でスロットルダウンしていただけでした。
OCCTはちゃんと通ったのに… やはりCPU検索だけでもかなりシステムに
負荷がかかってるみたいです。

119 ：

>>117
アドバイスありがとうございます、GPUはGTX570です
READMEの情報を参考にしてみましたが
GPGPUをプライマリに設定しているせいか改善されませんでした
引き続き12桁の方で頑張ります

120 ：

>>118
ちゃんとしたCPUクーラーを乗せたらどうですかね？
Scythe製の3000円ぐらいの製品でも段違いかと思いますが

121 ：

>>119
うーん、それならばパターンの数が多過ぎて捌ききれていないということなんでしょうねえ。
もうちょっとループの回数を減らしたほうがいいのかな…
>>120
CPUクーラーはNoctuaのNH-D14です。でかいです。4.6GHzでの運用を試してみてたんですけど、
システムにかなり無茶させてるのでちょっと無理だったみたいです。これ以上は殻割りか水冷にでも
しないといけないんでしょうけど、ちょっと踏ん切りがつきません…

122 ：

１）ＣＵＩで、作動するときに#regexのtargetを全部書き出さないほうがいいのでは。
２）ＧＵＩの、検索パターンに大量コピペできませんか？
応援してます

123 ：

>>121
ありゃりゃOCしての話ですか･･・
ハイエンドクーラーを持ってるのなら無理せずに
コアが冷える2600k辺りを中古手に入れた方が良いかもですね

124 ：

>>123
Ivy Bridgeがこんなにクセのあるコアだとは思いませんでした。
まあ自分の用途だとCPUよりグラボにつぎ込むことになりそうですけどね〜

125 ：

CPU検索が64bit化によって速くなったので、最高速の測定をしなおしてみました。
【GPU】NVIDIA GeForce GTX 580 2-Way SLI (OC: 940/2004MHz)
【CPU】Intel Core i7-3770K (OC: 4.5GHz 1320mV)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.06 Alpha 1
【オプション】-x 192 -c -g
【Display Driver】306.23
【10分間の平均速度】 1694.86M tripcodes/s
【その他】7完1タゲ。CPUの速度は約37M TPS。

126 ：

安価に最大45GHzの高速CPUを並列処理させてスパコン並みの環境を自宅でも可能にするオープンソースプロジェクト「Parallella」とは？
http://gigazine.net/news/20121007-supercomputer-parallella/
鳥検索が捗るな

127 ：

それってOpteron 6286SE 2.8GHz×16コアを
44.8GHzと言ってるようなものでは･･･

128 ：

原文では45GHzで90GFLOPSのCPU相当と言っているように見える。
5W以下らしいからワットパフォーマンスは悪くなさそうだし
10基とか20基積んでイーサネットとか付いた箱が安く出てくると面白そうだけど。

129 ：

新しい開発版です。
MERIKEN's Tripcode Finder 0.06 Alpha 1
http://www.meriken2ch.com/programming/merikens-tripcode-finder
今回の変更点は以下の通りです。
・64bit版の追加による高速化。
・10桁検索の高速化。
・複数のビデオカードが使用できないバグの修正。

130 ：

おつ

131 ：

8800GTX+GT520(Win7x64 295.73)の組み合わせで
32Bit版は動く事を確認しましたが
64Bit版はcudart64_40_17.dllが無いと蹴られましたよ

132 ：

>>126-128
これ見る限りではデュアルコアのARMと16コアもしくは64コアの
Epiphanyというアクセラレータの組み合わせのようですね。
Epiphanyの各コアは800MHzもしくは1GHzで駆動するようです。
安くて速い並列コンピューター、おいしいです（＾q＾）
http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone
http://www.adapteva.com/products/silicon-devices/

133 ：

>>131
ありゃりゃ… うちの環境だともうCUDA Toolkitがインストールされてるから
気づきませんでした。すみません、今すぐ新しいパッケージを用意します。

134 ：

>>131
パッケージを新しいものと差し替えておきました。これで64bit版もちゃんと
動くはずです。

135 ：

>>122
(1)は正規表現の展開の処理が止まることがあるのでたぶん今のまま
にしておくことになると思いますけど、(2)については検討させて頂きます。
GUIにも気になるところがいろいろ出てきたので、いずれまとめて
改良する予定です。

136 ：

>>132
DARPAのエクサスケールスパコン計画を目指している？
Epiphanyのチップ自体は最大消費電力が2ワットで、1ボードに64チップまで載せられるとかいうのも気になる。

137 ：

創・価
死・ね　
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね

138 ：

10桁CPU検索の改良をを続けるべくJohn the Ripperをダウンロードして
とりあえずMinGWでビルドしてみました。ZlibとOpenSSLをインストールしてから
リンカのオプションに"-ws2_32 -lgdi32"を追加したらビルドに成功。適当な
/etc/passwdを拾ってきて走らせてみたら、CPU使用率が12%の状態で5236K c/s
出てました。1コアあたり1スレッドだけで、なぜかCPU使用率がかなり低いのですが、
もし本当にこれだけの速度が出ているならJohn the RipperのBitslice DESの
ルーチンは相当速いことになります。なかなか面白いことになって来ました。

139 ：

x86-sse.Sだけ抜き出してアセンブルしたらあっさり通っちゃったけど、
これ、どうやって使うんだろう…

140 ：

つらつらとJohn the Ripperのコードを読んでいたらだんだんと思い出してきました。
キーと一時変数と変換結果はまとめてDES_bs_allという構造体に
格納されていて、次の順番で関数を呼び出せば一回の変換が
行われるはずです。
DES_bs_init()
DES_bs_set_key()
DES_bs_set_salt()
DES_bs_crypt_25()
一応必要な関数は全てビルドできたので、あとはテスト用のコードを書いてやれば
いいだけなんですけど、なにせブラックボックスを相手にしているので
結構緊張します。ちょっと休んでから取り掛かることにしようっと。

141 ：

0.06α1で試してみました。システム構成は以前と一緒です。
1時間半の検索速度は以下の通りです。
0.06α1 CUI64bit
12桁
-c -g -x 16
240.76M tc/s
"/TEST"
243.23M tc/s (current)
GPU:171.13M tc/s
CPU: 72.11M tc/s
CPUで70M超えました。6%程速度アップですね。
100M超えに期待しています。がんばって下さい。

142 ：

>>141
報告ありがとうございます。コア数が増えるに従って速度が綺麗にスケールするのは
当然なんですが、それにしてもCPUだけで70M TPSは凄いですね。
100M超えは…どうでしょうｗ

143 ：

大変な勘違いをしていたことが判明しました。
Xeon X5680@3.33GHz, 1CPU, 6コア, HT有効, 12スレッド
と、思い込んでいたのですが、中身を確認したら全然違いました。
Xeon X5680@3.33GHz, 2CPU, 12コア, HT無効, 12スレッド
通りでCPUが早い訳だ。orz
ウソ報告でごめんなさい。HT有効にして再計測してみますが、少し走らせた感じでは余り変わらないみたいです。

144 ：

そんな速いCPU使わねーよｗ
…と思いつつ酉検索においてはやっぱり欲しい

145 ：

自分で使ってる2CPUマシンを1CPUマシンと思い込んでるってどんだけー！
全て業者任せの富豪かよw

146 ：

>>143
それでようやくすっきりしました。「Xeonはやっぱり速いな〜」などと
何も考えずに思っていたんですけど、2年前のモデルで1CPUでその速度は
やっぱり速すぎですよねｗ hyper-threading有りでの報告もぜひお願いします。
うちのi7-3770Kでは4スレッドから8スレッドに増やすと27%ほど
速度が上がったので、hyper-threadingはある程度効果があるみたいですが…

147 ：

>>140の続きです。とりあえずテスト用のルーチンをでっち上げて
x86-sse.Sを試してみましたが、予想通り動きませんでした＼(^o^)／
やはり自分で作成したBitsliceのルーチンを地味にIntrinsicsかインラインアセンブラで
書きなおすしかないようです。幸いなことにSSE2でのS-Boxの実装はx86-sse.Sの
中にあるので、これをうまくつかってやればループの最深部の書き換えは
可能でしょう。しかしこれは想像以上に手強いですねえ。

148 ：

ちょっと調べたらなんとVisual C++のインラインアセンブラはx64を
サポートしていないことが明らかになりましたorz 自分でアセンブラの
ルーチンを書くしかないのかしらん。

149 ：

x64 Intrinsicsで頑張るしか

150 ：

targetはこれなんですけどね？^MERIKEN.s
◆MERIKENXsUyM #ﾇ鋒ﾑﾅ徳6ｶﾙ3o (C7 96 4E D1 C5 93 BF 36 B6 D9 33 6F)
これがあれですかね？”."

151 ：

>>149
IntrinsicsだとどうもSSEのレジスタの割り付けがうまくいってないみたいなんですよね〜
>>150
正規表現だと"."はすべての文字にマッチするのでそれはあってます。
正規表現で"."を指定したいときには"\."と書いて下さい。

152 ：

これでしたか。　　
# ^ $ () | [] [^] . + * \
#
# '.'は全文字にマッチするので、'.'そのものを指定したい場合は
# "\."と記入してください。なお、"[]"内では'\'を使う必要はありません。
癖がついてて、”.”使うんですね。

153 ：

>>152
そういうことです。

154 ：

なんとかならないものかとx86-sse.Sをもうちょっといじってみましたけど、
やはりちゃんと動いてません。また、さきほどからVC++が出力したアセンブラの
ファイルを眺めていたのですが、正直これじゃあスピードでないよね、といった
感じです。やはり残念ながらBitslice DESのルーチンを自分でアセンブラで書くしか
手はないようです。

155 ：

さすがに全部書きなおすのはしんどいのでS-Boxの部分だけでも、と考えて
別の関数に切り出してやったら、それだけで1.6M TPS速くなりました。
コンパイラの最適化サボりすぎだろう…

156 ：

>>145
全て業者任せの富豪から最近譲り受けたんだよ。
「とにかく解析が速いやつ」って注文したらしく、ハードのスペックが分かる資料が全然残ってねぇ。ヽ(´Д｀；)ノ
数値がおかしいんで蓋開けてみたらCPUが二個付いてた・・・

157 ：

CPU-Zぐらい使えよ

158 ：

>>156
> 数値がおかしいんで蓋開けてみたらCPUが二個付いてた・・・
これはなかなかシュールな絵ですねｗ GPU-Zもお勧めです。

159 ：

これがはいじそといわれる類の存在なんだね

160 ：

コンパイラの出力したx64のasmファイルを編集すれば楽かと思って
中間ファイルをMASMにかけてみたんですけど、すんなりアセンブルできません。
セグメントの指定で色々文句を言われたので直してみたんですが、
今度はアセンブルできたもののプログラムが落ちるようになってしまいました。
こりゃ相当な手間がかかりそうです。

161 ：

正直John the RipperのBitslice DESの実装を使えるようにするのも、
Bitslice DESのルーチンを1からアセンブラで書くのも時間がかかりすぎなので、
あともう一つだけアイディアを試してみて、それでうまくいかなかったら
CPU検索の最適化はとりあえず一旦お休みにします。
で、最後のアイディアというのは、Bitslice DESの最深部だけ別のコンパイラで
コンパイルしてやるということです。どうも調べてみるとVC++のSSE Intrinsicsの
最適化はGCCやICCに比べるといまいちなようなので、ある程度の効果は
期待できるでしょう。あとは32bit版だけインラインアセンブラを使って
最適化するという手もあるんですけど、それは後回しにします。

162 ：

で、Intel C++ Studio XE for Windowsの試用版でS-Boxをコンパイル
してみましたが、結果は速度が0.7M TPSほど上がっただけでした。
いや〜、まいったまいった。

163 ：

しかしこれからどうしようかな。
x86のほうはインラインアセンブラも使えるしS-Boxもasmファイルに変換
できたので、とりあえずこちらの最適化を頑張るという手もあるんだよな…

164 ：

う〜ん、どうやらGTX 780はGTX 680の改良版になりそうな模様…
What is going on with Nvidia’s GK114? Like AMD, the answer is not much
http://semiaccurate.com/2012/10/12/what-is-going-on-with-nvidias-gk114/
こりゃ来年のも見送りだな。今のうちにGTX 590を確保しておこうっと。

165 ：

梅田の祖父でGTX590中古があったけど確か34k円位だっけか
まあ発熱には注意だな

166 ：

tesla待とうよ！

167 ：

>>165
確かに熱は大変なことになりそうですねえ。
580 SLIも大概でしたけど、590 + 580とか、システムが持つのかしらん。
電源にはかなり余裕があるんですけど、ちょっと心配です。

168 ：

>>166
Tesla K20、欲しいですw
K10がだいたい$3300ぐらいですけど、K20はいくらぐらいになるんでしょうか…

169 ：

正直なところどうしようか困っていた10桁CPU検索ですが、
ちょっと思いついてregister演算子をSSE Intrinsicsで使ってみたところ、
大した手間もかからずに20%ほど高速化出来ましたｗ
やはりVC++はSSE Intrinsicsの最適化を相当サボっている模様。
John the Ripperの実装を参考にしながらレジスタ割り付けを
工夫することでかなり高速できそうです。これでようやく光が見えてきました。

170 ：

GTX590確保しました! ('◇')ゞ
CPU: PhenomeII X6 1100T@3.3GHz
GPU: GV-N580SO-15I, ENGTX590
OS: Win7 64bit
Prg: 0.06a1
桁: 12
Targ: "TEST/"
Opt: -c -g -x 128
Drv: 306.97
1hrAv: 1830.05MTPS
その他:
CUDA0: 746.1M TPS (580)
CUDA1: 532.6M TPS (590)
CUDA2: 532.7M TPS (590)
1872.38M tripcodes/s (current)
GPU: 1853.10M tripcodes/s
CPU: 19.28M tripcodes/s
580一枚の時にはCPUはフルロードで20M超えていましたが、590を追加するとロードが50%〜100%に激しく変動して、CPUを使い切れてないようでした。
消費電力は怖くて計ってませんw

171 ：

速ぇー

172 ：

速すぎﾜﾛﾀ

173 ：

>>170
こ、これはｗ OCしたら簡単に2G TPSを超えそうですねえ。
Phenom II X6 1100Tは6スレッドでは40M TPSぐらいです。
GPUが3個ならCPU検索スレッドも3つなので、まあ順当なところでしょう。
消費電力もそうですが、温度のほうも気になります。
うちの580 SLIは80℃超がふつうなので…590はもうオークションで
落としたんですけど、ちゃんと運用できるかどうか心配です。

174 ：

>>170 >>173
590確保乙
そのうちトリプルGTX590とか強者が出そうだ…

175 ：

検索停止ボタン押した途端にフリーズした・・・

176 ：

>>175
システム全体がフリーズしたなら、多分ハードウェアの問題でしょうねえ。
電力使用量が急激に変化するととにかく不安定になりがちです。

177 ：

>>174
365W * 3 = 1095Wですか… 電源が２つ入りますね、こりゃ。
まあGPUはあればあるほど速くなる仕様なので、理屈では
ラックマウントサーバーにTeslaを積めるだけ積んで
動かすことも可能なはずですけど…

178 ：

| 冫､)ｼﾞｰ

179 ：

linux版の登場が待たれるな

180 ：

>>176
あ、レスサンキュです、マウスポインタも動かい状態でした。
なかなか安定した環境の構築は難しいです・・・

181 ：

CUDA5来ましたね
http://developer.nvidia.com/cuda/cuda-downloads
NVIDIA，「CUDA 5」を正式発表。第2世代Kepler「GK110」に向けた準備が整う
http://www.4gamer.net/games/076/G007660/20121016013/

182 ：

>>173
夜中に部屋の窓を全開にして両方とも80℃ちょい。窓を閉めると90℃超えます。
今の季節だと、クーラー無しに昼間に常用するのは難しいと思います。
580SLIに590を付け足すなら、エアフローに気をつけて下さい。
最初、エアフローが悪くて580の温度が90℃を軽く超えていって怖い思いをしました。
消費電力は、計算時に+690Wでした。
前日書き忘れたのですが、ブロック数の自動設定機能が安定しませんでした。
走らせるたびに96?〜168?の間をふらつきます。590の二つのGPUでも異なるブロック数になることもありました。
590は早々にXeonマシンに引っ越すつもりなのですが、まだ電源スペックが分からねぇヽ(´Д｀；)ノ

183 ：

最新のドライバーに更新したら動きました！(前動かなかったのに・・・)
前スレではありがとうございました！
(富士通の京にトリップ検索させたらどうなるんだろう・・・)

184 ：

あと現バージョンのCUIで検索すると10桁になるか12桁になるかと
どうすればCUIで10桁を検索するか12桁を検索するか指定できる方法を教えてください

185 ：

>>181
CUDA5は実際のところどうなんでしょうね〜
RC版でビルドしたら12桁GPU検索がかなり遅くなったんですけど、
Production Releaseでは直ってるんでしょうか。あとで試してみます。

186 ：

>>182
非常に参考になりますです。今ある580 SLIを580+590にする予定なんですけど、
2枚のグラボの間に隙間がないので、590は下側につけておいたほうが
よさそうですねえ。ケースにはまるといいんですけど…
ブロック数の設定の違いはいい解決方法が思いつかないです。まあ128以上
だったらほとんど誤差程度の違いしか出ないので大丈夫でしょう。

187 ：

>>184
それは良かった。CUI版はデフォルトでは12桁検索になります。
オプションについてはREADME.txtを参照してください。

188 ：

慣れてないならコマンドラインから直接打ち込むのではなく
ショートカット作って指定したほうが良いかと

189 ：

GTX 590が届いたんですけど、熱すぎて今使っているケースでは580と
一緒に使えないことが判明。どう頑張っても上のカードの温度がかるく90℃を
超えてしまいます。せっかく頑張ってケースに押し込むことができたのにorz
しょうがないので580+590はサブのデスクトップに引越しさせて、
こっちをトリップ検索専用PCとして使うことにします。

190 ：

>>178
Radeonには次のバーションで対応する予定です。
>>179
Linuxにはここ10年ほど触っていないので対応の予定はありません。
CUI版の移植なら難しくないはずなので、いかがですかｗ

191 ：

Radeon版ってOpenCLなんでしょうかね？
それだとintel HD Graphics 4000でも動かせそうな気が

192 ：

最近BOINCに精を出してるのでアプデ来てもどっちを回すか迷うな……

193 ：

仮にintel HD Graphicsでトリッパー動かせるとしたらどれぐらいの速度が出んのかな？

194 ：

>>192
BOINCと同時に廻すと他のアプリケーションが非常に重くなって悲惨なことに…
実際にやって後悔したから
同時に廻すならアプリケーションを使わない時の方がいいと思われ

195 ：

580+590をサブのテストベンチで使うことにしたので、
HD 5770ともう一枚の580をメインのデスクトップに移しました。
とりあえず5770を画面表示用にして、580はGPGPU専用にしてあります。
この組み合わせでちゃんと動くか心配だったのですが、
今のところ問題はありません。Tripcode Finderもちゃんと動いています。
これで理屈ではRadeonとGeForceで同時にトリップ検索を行うなんてことも
できるはずですが、果たしてどうなるんでしょうか。

196 ：

NVとAMDのOpenCL関連のライブラリが競合とかしないのだろうか

197 ：

>>191
OpenCLです。ただ、OpenCLはソース互換なので、Intelので
そのまま動くというわけじゃないですけどね。

198 ：

>>196
NVIDIAのOpenCLのライブラリを結合しなければいいだけなので、
多分大丈夫でしょう(楽観)

199 ：

最近よくかたまるな・・
ヒットしたトリップを、tripcodesに保存前にフリーズ・・・orz
吐き出したトリップを、tripcodesに強制保存できませんか？
ひよわなPCで、ｽﾏｿ。

200 ：

>>197
そのまま動くぞ。
カーネル部分はソースのままで同梱すればいいしな。
俺は一個のバイナリでラデ、ゲフォ、インテルで動かしてたぞ。

201 ：

Intelで動く…だと…？

202 ：

それでもしCPU検索よりも早かったらワロス

203 ：

そんなまさか

204 ：

openCLはgpuでもcpuでも計算出来たような

205 ：

Ivy買ったら内蔵GPUでも動かしてみようと思ってたんだが、買う気が出ない。ｗ

206 ：

>>199
あ〜びっくりした。自分が書いたのかと思ったｗ
強制保存するオプションはあとで付けておきます。

207 ：

>>200
あれ、そうなんですか? どうやってやるのかもうちょっと調べねば…

208 ：

MERIKENsTripcodeFinderCUIなんですが、コマンドラインからの起動がうまくいかないです。

209 ：

>>208
どのようにうまくいかないのかｋｗｓｋ

210 ：

指定がおかしいだけだと思うのですが
C:\MERIKENsTripcodeFinder_0.05\MERIKENsTripcodeFinderCUI.exe -f patterns.txt -g -c -x 16 -t 10で
色々表示された後に
MERIKENsTripcodeFinderCUI: Error: The pattern file could not be opened.と表示されてしまいます。

211 ：

>>210
> 色々表示された後に
ここのところをもうちょっとｋｗｓｋ
あとpatterns.txtはどこにありますか?

212 ：

2レスに分割します。
C:\>C:\MERIKENsTripcodeFinder_0.05\MERIKENsTripcodeFinderCUI.exe -f patterns.txt
-g -c -x 16 -t 10
MERIKEN's Tripcode Finder 0.05
[compiled at 19:37:41 on Oct 3 2012 (PST)]
Copyright (C) 2011-12 ◆MERIKEN4.k
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
Using both GPU(s) and CPU as search devices.

213 ：

CUDA DEVICE
===========
CUDA Device Count: 3
Device No.: 0
Device Name: GeForce GTX 580
Multiprocessor Count: 16
Clock Rate: 1714MHz
Compute Capability: 2.0
Device No.: 1
Device Name: GeForce GTX 580
Multiprocessor Count: 16
Clock Rate: 1912MHz
Compute Capability: 2.0
Device No.: 2
Device Name: GeForce GTX 580
Multiprocessor Count: 16
Clock Rate: 1912MHz
Compute Capability: 2.0
CPU
===
Number of Processors: 12
Number of Search Threads: 10
TARGET(S)
=========

214 ：

patterns.txtですが、Cドライブ直下の他のファイルと同じ場所にあります。

215 ：

PCが故障してしまいました…。

216 ：

それならパターンファイルの指定を"-f C:\MERIKENsTripcodeFinder_0.05\patterns.txt"に
なおしてやればちゃんと動くはずです。
しかし580 3-Way SLIですか。う〜ん、なかなかの勇者ですね…
PCが無事だといいんですけど…

217 ：

なるほど、有難うございます。
メインPCが復旧できたらやってみます。
CUIでの起動ですがオーバークロックして
GPU: 2400M tripcodes/s
CPU: 40M tripcodes/s付近出てた気がします。
まずはポンプを買わないと…。

218 ：

>>217
580が3枚あれば納得の速度です。2G TPS超は熱との勝負みたいですねえ。
自分も来週あたりに580+590の組み合わせで挑戦する予定です。
水冷が一番いいんでしょうけど、なかなか踏ん切りが付きません…

219 ：

さて、遅れに遅れている10桁CPU検索の高速化ですが、
未だにどうしたものか決めかねている状態です。
Intrinsicを使ってレジスタ割り付けを最適化するという方針は
そのままなんですが、どのようにするのか実に悩ましいところです。

220 ：

とりあえず手作業でS-Boxを1つ最適化してみてから、
最適化を自動化するかどうか決めてみよう…

221 ：

そうですね、こちらのソフトではひとつ起動すればGPUを纏めて動かしてくれるので大変に有難いです。
空冷では特にエアフローに気をつけないとカードの温度が90℃を超えてくるので大変と思います。
どちらも電力を必要とするカードですが、電源ユニットは大丈夫でしょうか？
導入に対して敷居や導入コストが高いのが難点ですが、ある程度まで理解できれば何とかなると思います。

222 ：

>>221
やっぱり何も考えてないで使えたほうが楽ですよね。
サブのデスクトップはおっぴろげのテストベンチなので大丈夫です。
http://www.newegg.com/Product/Product.aspx?Item=N82E16811112287
電源はCorsair AX1200なので、こっちも問題ないはずです。
水冷は後のお楽しみに取っておくことにしますｗ

223 ：

そうですね、初期設定さえ出来れば後の起動は楽なのがいいです。
こういった開放型のケース？で埃等は問題ないのでしょうか、その点怖い気がします。
これだけの容量であれば何も問題ないですね、あとは知識を収集して水冷化に挑戦といったところでしょうか。

224 ：

>>223
埃の掃除にはエアーコンプレッサーを使っています。
空冷の限界が見えたらぜひ水冷にも挑戦したいですね。

225 ：

水より冷える液体がいいですね。
>>206
間違いますよね。変えます
>>205
のたんぺさんは、引退ですか？
最強のトリップ検索人ですよね。

226 ：

>>225
そうしていただけると助かりますです。

227 ：

2時間以上S-Boxの書き換えに費やしましたが、まだ最初のS-Boxの作業すら
とても終わりそうにありません。こりゃ時間かかるわ…
しかしこれほんとうに効果があるのかしらん。

228 ：

結局これも読まんといかんのかな。まいったなあ…
Intel 64 and IA-32 Architectures Optimization Reference Manual
http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf

229 ：

Bitslice DESの各ゲートを、
A = OP(B, C)
という形から、よりSSEの命令セットに近い
A = OP(A, B)
という形に書き換えてるのですが、ようやくちょっとづつ速度が上がって来ました。
変換が終わったら、まとめられる一時変数をすべてまとめてしまう予定です。

230 ：

とりあえずS-Boxを1つだけ書き換えてみましたけど、
速度は微増といったところで劇的な変化は見られませんでした。
やはりIntrinsicsでの高速化には限界があるようです。
Intrinsicsで書きなおしたルーチンをさらにアセンブリで書きなおすという手も
あるのですがこれはにはかなり時間がかかるので、CPU検索の高速化はここまでにして
OpenCLへの移植に移りたいと思います。

231 ：

つhttp://yy51.60.kg/test/read.cgi/ra8plus/1298452105/

232 ：

新しい開発版です。今回の変更点は10桁トリップCPU検索の速度向上です。
MERIKEN's Tripcode Finder 0.06 Beta 1
http://www.meriken2ch.com/programming/merikens-tripcode-finder

233 ：

>>231
なるほど、これが>>200のブツですね。なんか普通にNVIDIAとIntelの
GPUで動いてますね… ちょっと自分でも試してみよう。

234 ：

結局OpenCLならどのベンダのライブラリを使っても他のベンダの
GPUが使えるということなんでしょうか。

235 ：

次のページを参考にしてAMD APP SDKのOpenCLのライブラリを
Tripcode Finderにリンクしてみました。
http://stackoverflow.com/questions/9595971/open-cl-with-amd
http://stackoverflow.com/questions/8969709/clgetplatformids-return-two-platforms-but-they-are-the-same
なんか普通にOpenCLからGTX 580もHD 5770も見えてます。
> OpenCL reports 2 platforms.
>
> Platform 0: NVIDIA Corporation NVIDIA CUDA OpenCL 1.1 CUDA 4.2.1
> Platform 1: Advanced Micro Devices, Inc. AMD Accelerated Parallel
> Processing OpenCL 1.2 AMD-APP (1016.4)
Core i7-3770KのGPUは見えていないようなのでIntelのドライバを入れて
もう一回試してみます。

236 ：

よく見たらこれGPUじゃなくてプラットフォームなのか。
なにはともあれドライバをインストールしたらIntelのプラットフォームも
見えるようになりました。
> Platform 0: NVIDIA Corporation NVIDIA CUDA OpenCL 1.1 CUDA 4.2.1
> Platform 1: Advanced Micro Devices, Inc. AMD Accelerated Parallel
> Processing OpenCL 1.2 AMD-APP (1016.4)
> Platform 2: Intel(R) Corporation Intel(R) OpenCL OpenCL 1.1

237 ：

デバイス一覧を取得しました。なぜかCore i7が2つあります。
JuniperってHD 5770のコードネームか。紛らわしいなあ…
> OpenCL reports 3 platforms.
>
> Platform 0: [NVIDIA Corporation] [NVIDIA CUDA] [OpenCL 1.1 CUDA
> 4.2.1]
> 　　0: [NVIDIA Corporation] [GeForce GTX 580]
> Platform 1: [Advanced Micro Devices, Inc.] [AMD Accelerated Parallel
> Processing] [OpenCL 1.2 AMD-APP (1016.4)]
> 　　0: [Advanced Micro Devices, Inc.] [Juniper]
> 　　1: [GenuineIntel] [ Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz]
> Platform 2: [Intel(R) Corporation] [Intel(R) OpenCL] [OpenCL 1.1 ]
> 　　0: [Intel(R) Corporation] [ Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz]

238 ：

2つ見えているIntelのは両方共CPUみたいです。
HD 4000はどこに行ったんだろう…

239 ：

もうどこからつっこめばいいのかわからんなこれ。ｗ
CPU Only のランタイムしかいれてないんじゃねーの？
やったことないから知らんけど。ｗｗｗ

240 ：

いや〜、これちょっとやばいですよね…
IntelのOpenCLのSDKをインストールしても見えなかったのでおかしいなと
思ってたんですけど、なんとマザボにディスプレイを繋いだらようやく
OpenCLのAPIからIntel HD 4000を認識できるようになりました。
> 1: [Intel(R) Corporation] [Intel(R) HD Graphics 4000] [GPU]
CUDAと違って、OpenCLはかなりカオスですねえ…

241 ：

やはりディスプレイをつながないとHD 4000はOpenCLデバイスとして
認識されないようです。ここでIntelの人がそう言っているので確実でしょう。
なんというか、いろいろ勿体無いです。
HD Processor Graphics failed to load as a device in Code Samples
http://software.intel.com/en-us/forums/topic/277886

242 ：

いやいや、つっこみどころが多いのは OpenCL に対してじゃなくて。
ちゃんとマニュアルとか読んだ方がいいんじゃね？
まあまだサンプル動かしてみただけの段階なんだろうけど。

243 ：

夫婦漫才ですね。　　このすれは・・・

244 ：

もともとマニュアルは絶対必要にならないと読まない方なんでｗ
それよりサンプル読んでたほうが参考になるし…
まあCUDAと似たようなものなので、近いうちに動くものが出来るように
なるでしょう。

245 ：

一時停止の状態を保存できないのでしょうか。

246 ：

>>245
それは難しいですね。
累計検索時間と生成されたトリップの累計を表示させることなら出来ます。
次のバージョンでプログラムの構造に大きく手を入れる予定なので、
これまでに希望のあった機能はまとめて追加する予定です。

247 ：

とりあえずこのサンプルを読んだら大体の流れはわかりました。
Getting started with OpenCL and GPU Computing
http://www.thebigblob.com/getting-started-with-opencl-and-gpu-computing/
まずSHA-1とDES cryptのルーチンを移植して、ちゃんと動くのが確認してから
実際の検索ルーチンを作成することにします。やることはCUDAの場合と
ほとんど変わらないので、割とすんなり行きそうな予感…

248 ：

そうそう、今日テストベンチ用の部品が届くので、後で580+590をそっちに
移してTripcode Finderを動かして見ることにします。
2G TPS超は確実ですが、どこまで上乗せできるか楽しみです。

249 ：

>>246
ありがとうございました。楽しみにしてます。

250 ：

SHA256ハッシュを取ると全ビットが0になるキーを探してください

251 ：

初めまして。
なんとなくトリップ検索(特に12桁)を再開したくなり、
ひょんなことから、こちらの安定版を頂きました。
残念ながらラデオン使用＋中古パーツ寄せ集めの自作なんで、
貴ソフトを100%活用できていませんが、表示される検索数には驚いていますw
CPU検索＋スレッド自動ですが、
Phenom �U Black x6 が、６コア100%稼動するのを初めて見ました。
ソフトの進化、期待しています。
(こっちのハードも進化させねばorz)

252 ：

テストベンチに580+590を移したのでまた最高速の測定をしてみました。
590は意外にOC耐性があります。ビデオカードはむき出しで間を空けてあるので
GPUの温度は84度に抑えられています。
【GPU】NVIDIA GeForce GTX 580 (OC: 940/2004MHz) + GTX 590 (OC: 830/1728MHz)
【CPU】AMD Phenom II X6 1100T (定格)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.06 Beta 1
【トリップの種類】12桁
【オプション】-x 192 -c -g
【Display Driver】306.23
【10分間の平均速度】 2291.56M tripcodes/s
【その他】7完1タゲ。CPUの速度は約19.6M TPS。

253 ：

>>251
12桁のCPU検索は限界に近い速度が出ていると思われます。
近いうちにラデにも対応する予定なのでその時はテストをお願いします。

254 ：

>>250
見つけるのに一体何世紀かかるんでしょうねえ…

255 ：

>>251
よく読み返したら安定版だったんですね。
それだったら次の安定版で5M TPSほど速くなります。

256 ：

最高速の測定の続きです。あの後まさかと思って580をもう一枚
追加したらあっさり3G TPS超えできました。さすがテストベンチｗ
でもGPUの温度は最高で89℃なのでそろそろ限界でしょう。
温度さえ何とかなれば590 3-Way SLIで4G TPS超えも出来そうですが…
【GPU】NVIDIA GeForce GTX 580 SLI (OC: 930/2004MHz) + NVIDIA GeForce GTX 590 (OC: 830/1728MHz)
【CPU】AMD Phenom II X6 1100T (定格)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.06 Beta 1
【トリップの種類】12桁
【オプション】-x 192 -c -g
【Display Driver】306.23
【10分間の平均速度】 3080.98M tripcodes/s
【その他】7完1タゲ。CPUの速度は約13.1M TPS。

257 ：

>>241
ディスプレイを繋がなくても、Windowsの設定で"画面を拡張"にしたらできますよ

258 ：

>>257
試してみたけどやっぱりOpenCLのAPIからは見えていません。
実際に物理的にディスプレイをつながないと駄目なようです。
折角の機能なのにもったいない… これって将来のドライバ更新で
改善されたりするものなんでしょうかねえ。

259 ：

あのあとテストベンチのGPUの電圧のクロック周波数をAfterburnerで細かくいじって、
普段使っている検索パターンで安定して2.3G tripcodes/s出せるようになりました。
正規表現を使ったかなり複雑なパターンなので、その分だけGPUの温度も上がって
しまい苦労しました。室温はだいたい30℃で、GPUの温度は最高で91℃です。熱すぎです。
GTX 580 (975mV 700/2004MHz)
GTX 580 (975mV 480/1000MHz)
GTX 590 (925mV 800/1728MHz)
このように上から順番に隙間なく並んでいるのですが、真ん中の580の放熱が
やはりというかうまくいかないらしく、クロック周波数を限界まで落とさざるを
得ませんでした。

260 ：

そこまでクロックを落とすのなら無理せず他のGPU乗せた方が…

261 ：

もともと真ん中の580は乗っけるつもりがなくて、
590を買って余ってたのを使っただけなのでこれでいいのですｗ
最初はグラボを3枚のっけるなんて考えてもいなかったので…
余った580はオクで売っぱらう予定だったんですけど、
今の構成が思いのほかうまく動いているので当分このままにしておきます。

262 ：

各マシンに分散したらいいんじゃないの？
ということで家庭内分散コンピューティング対応のネットワーク検索に期待してます
SETI@homeみたいな

263 ：

>>262
最終的にはそこに行きつくんでしょうねえ。
いずれぜひ取り組んでみたいけど、その前にスタンドアロンで
最高のトリップ検索プログラムを作るのを先にしたいと思います。

264 ：

>>258
BIOSで常に有効にしたり出来ないのでしょうかね？
>>259
冬も暖房不要になりそうですねｗ
グラボの冷却は最終的にはやはり水冷なのでしょうかねえ・・・

265 ：

>>264
BIOSの設定も色々いじってみたけど駄目でした。
>>241のリンク先でIntelの人がはっきりと無理だと言ってるので無理なんでしょう。
恐らく消費電力はシステム全体で1000W近いので、電気ヒーターなど目ではありませんw
まあ性能のことだけ考えるなら水冷のほうがいいんでしょうけど、
保証がなくなるのと手軽にグラボの交換ができなくなるのは痛いですね。
590 4枚差しとかちょっと見てみたい気がしますけどねｗ

266 ：

>>265
BIOS設定でもどうにもならないとなると厳しいですね。
手持ちの電気ヒーターの消費電力を測ってみたことがあるのですが
強では表示どおり1200W、弱で600Wだったのでなかなか手ごわいですよｗ
GTX590を4枚となると1500Wを超えて電源が2系統必要になりそうです。

267 ：

200V端子なら…
いや市販のプラグとコード見たことないけど

268 ：

家庭用電源だとさすがに厳しいですねｗ
590 3枚あたりが個人でできる限界でしょうか。

269 ：

Tesla K20がようやく発売開始になったみたいですね。
http://www.sabrepc.com/p-2920-nvidia-900-22081-2220-000-tesla-k20-kepler-gpu-computing-processor.aspx
$3500なのでK10と似たようなお値段ですが、手が出ないことにはかわりませんｗ
誰かTripcode Finderをこれで動かしてみてくれないかな〜

270 ：

>>247のサンプルをTripcode Finderのソースに組み込むことに成功しました。
ちゃんと実行ファイルと同じディレクトリにあるOpenCLのソースファイルが
コンパイルされて実行できてます。次はCUDAのSHA-1のルーチンを
コピペして動作するかどうか確認することにします。

271 ：

1年前に書いたCUDAのSHA-1のルーチンを読み返してみたけど、
やはりDES cryptに比べると相当簡単です。これならテストも割りと
すんなりといくかな。

272 ：

サンプルを書き換えてOpenCLのSHA-1のルーチンをテストするコードを
でっち上げたのですが、1発で12桁トリップの変換に成功しました。
10桁CPU検索の作業に比べてなんと楽なことよ…

273 ：

私の机の隣で爆音を立てて熱風を撒き散らしつつ24時間稼働している
「検索君1号(仮名)」ですが、あまりにうるさいので昔買って放置してあった
Sonyのノイズキャンセリングヘッドフォンを引っ張りだしてきました。
効果は抜群で、数ヶ月ぶりに自室に(見かけ上の)静寂が訪れました。
580 1枚でうるさいと持ってた頃が懐かしいです…

274 ：

これは12桁での速度を維持しながら10桁での検索も可能ということなのでしょうか？

275 ：

>>274
違います。NVIDIA以外のグラボでもGPU検索ができるようになるかも、という話です。
計算量が桁違いなので、理論的に10桁検索が12桁検索と同じぐらい速くなるということは
あり得えないです。
ただ、RadeonのグラボはNVIDIAのものに比べて10桁検索に向いているということは
ありそうです。というかCUDAと10桁検索が壮絶に相性が悪いだけなのかも
しれませんが…

276 ：

>>268
電源ユニット2台で別系統のコンセントを使えば大丈夫かと思いますｗ
そこまでするなら複数台に分けた方がいいですけど。

277 ：

>>275
Radeonがアーキテクチャ的にDES cryptの計算もやりやすいのでしょうか？
OpenCLならGeForceでもマシになったりするのかも気になります。

278 ：

>>277
ゲフォよりもラデのほうがレジスタの数が多いとかいう話をどこかで見かけました。
それにラデのほうが実際に速度が出てますしね。OpenCLはCUDAより遅くなるのが
目に見えているのでラデへの対応はありません。

279 ：

間違えた。>>278の最後の行は「ゲフォへの対応はありません」だった。

280 ：

やはりレジスタが一番の理由ですか。
GeForceはKeplerでの方向性とか見ていると厳しくなりそうですね。

281 ：

>>280
レジスタの数がそこまでなくても、高速なメモリがあればそれでいいんですけどね。
CUDAの10桁検索も共有メモリの量さえ増えれば多分倍以上の速度が出るでしょう。
オンダイの高速メモリをL1キャッシュに使うぐらいならもっと共有メモリを
増やして欲しいもんです。
GeForceでのGPGPUの今後はわかりませんね〜
GK110がGeForceに降りてきてくれればいいんですけど…

282 ：

>>276
やっぱそうですよね〜 トリップ検索を始めたときにはこんなに熱処理に悩まされるとは
思いもしませんでした。分散処理対応を真剣に考えよっと。

283 ：

こんばんは。
>>253
ちょっと古いグラボなんでどうなるか分かりませんが、データ取りにはなると思います。
年明けなら、うまくいけば上位のヤツが手に入りそうです。
>>255
おおっ、楽しみにしています。
>>282
コンピューターの歴史は熱との戦い・・・
真空管のENIACなんか、凄かったでしょうね。
//
とりあえず、ご報告。
CPUはAMD Phenom�U x6 1090T Black Edition 3.2Ghz
ターゲット５種・５完〜12完で稼動です。
最高で23.68Mtrip/sぐらいです。
ターゲットを12種にしたら、高21.88Mtrip/s、平21.66Trip/sぐらいです。
そちらと同じ検索条件にすれば、もっと早くなるのは分かってますが、つい・・・^^;
ではまた。

284 ：

>>283
データ取りでも有難いです。ぜひよろしく。

285 ：

あのあとOpenCLのSHA-1のルーチンの速度を測定しようとしたのですが、
適当な作りのテスト用コードではちゃんと測定できませんでした。残念…
やはりある程度検索ルーチンを作りこまないといけないようです。
まあしょうがないといえばしょうがないですね。
とりあえず前方一致検索の分だけ作ってみます。

286 ：

これはRadeon向けの最適化の資料です。あとでじっくり読もうっと。
AMD Accelerated Parallel Processing OpenCL Programming Guide
http://developer.amd.com/tools/hc/amdappsdk/assets/AMD_Accelerated_Parallel_Processing_OpenCL_Programming_Guide.pdf

287 ：

あまりも検索君1号(仮)のGPUの温度が高すぎて心臓に悪いので、
こんなものを注文しました。
BestDealUSA PCI-E Express 16X Riser Card Extender Extension Cable Ribbon Flex
http://www.amazon.com/gp/product/B00646VJDG
これで真ん中のグラボを浮かせてやって空気の流れを良くしようという狙いです。
まあ見た目は悪くなるだろうけど、効果は確実にあるでしょう。

288 ：

OpenCLのルーチンをデバッグしてるんですけど、
実行時にOpenCLのコードのコンパイルに失敗しても
結構詳しいエラーメッセージが取得できるので助かります。
CUDAほどお手軽ではないですけど、
思ったより手間がかからずに済みそうです。

289 ：

CUI版を少しずつOpenCL対応のために書き換え始めました。
CUI版での変更がGUI版に自動的に反映されるのが便利といえば便利です。
とりあえず"AMD HD 5770"と"Intel HD Graphics 4000"はGUI版から見えるように
なりました。OpenCL対応は単純作業が多そうなので、毎日少しづつ
進めていくことにします。

290 ：

つまりオンボだけどCore iしりーずな人でもGPUパワーが使えるのか……胸熱

291 ：

自分はOpenCLでSHA256ハッシュを探索して
ハッシュの先頭に0のビットが多く並ぶキーを探すプログラムを書いているんですが
Windows7で265MHash/s出ていたのが80MHash/sしか出なくなって
原因調査中です

292 ：

>>290
前に別のところで聞いた話だとすずめの涙みたいな計算速度だった覚えが

293 ：

8800ＧＴ　メモリ2GBのPCですが、検索停止ボタンを押すと完全に固まります
フリーズ中はGPUのファンは静かになっていて、HDDが規則的なリズムでガリガリと鳴りつづけていました
さきほど1分ほど動かして検索停止ボタンを押した時は15分経っても復帰しませんでした。多分、そのまま動かし続けてもフリーズするのは時間の問題だと感じました
再起動した後、とりあえず10秒（検索速度などの表示が出るまで）で止めてみたのですが、停止ボタンを押した後に一瞬画面が真っ黒になって「ディスプレイドライバの応答停止と回復」のポップアップが表示されました
この調子ですぐ止めればセーフか？と思い、続いてブロック数を自動から1に変更して開始したところ、同じように10秒で止めても完全にフリーズしてしまいました
メモリの容量か何かが関係しているのかとも思いましたが、それにしては検索中もメモリの利用率は別に増えてなかったのが不思議です。
使っていて変な汗が出たソフトナンバーワンなのは間違いないです

294 ：

>>293
多分問題は電源かGPUの温度でしょう。メモリは殆ど使わない作りになっているので
まず関係ないです。SpeedFanとかAfterburnerで温度をチェックすると
いいかもしれません。

295 ：

>>290
>>292
実際に検索させてみないことにはわからないですけど、
性能はあんまり期待できないでしょうね〜 まあおまけみたいなもんです。

296 ：

>>291
なかなか不思議なプログラムですねえ。手直しすると突然速度が落ちるという
ことはよくあります。バージョン管理は必須ですね。

297 ：

>>294
電源ですか！なるほどなるほど・・・なんだか靄が晴れた気分です

298 ：

>>296
すいません291はWindows8にしたらって書くのを忘れてました

299 ：

>>295
AMD APUの場合は
http://www.amd.com/jp/press-releases/Pages/second-generation-amd-a-series-2012may15.aspx
A10-5800Kで理論値はCPU部分が約120GFLOPS、GPU部分が約600GFLOPSと5倍程度差があるらしいので
うまく利用できるとそこそこ期待できそうですが、問題はVLIWへの最適化でしょうかね？

300 ：

いい機会なのでコードの整理をして、パターン処理の関数を1つのファイルに
まとめました。正規表現のパーサが含まれているので結構な大きさです。
これでコードもすっきりしたのでOpenCLデバイスの処理を追加しやすくなりました。
コード全体を眺めるのは久しぶりなんですけど、継ぎ足しに継ぎ足して
随分たくさん書いたもんです。

301 ：

>>299
トリップ検索では浮動小数点演算は使わないのでFLOPSはあんまりあてにならない
んですけど、AMDのAPUならそこそこ性能は出るでしょう。最適化については
今のところ全く分かりませんw とりあえず動くOpenCLのコードができてから
考えることにします。

302 ：

OpenCLデバイスの初期化の処理も実装し終わりました。
あとはスレッド周りを修正すれば、実際の検索ルーチンに取り掛かれます。
----
Using GPU(s) as a search device.
OPENCL DEVICE
=============
OpenCL Device Count: 2
Vendor: Advanced Micro Devices, Inc.
Name: Juniper
Clock Frequency: 850MHz
Global Memory Size: 1024M bytes
Version: OpenCL 1.2 AMD-APP (1016.4)
Driver Version: 1016.4 (VM)
Vendor: Intel(R) Corporation
Name: Intel(R) HD Graphics 4000
Clock Frequency: 350MHz
Global Memory Size: 1624M bytes
Version: OpenCL 1.1
Driver Version: 8.15.10.2761

303 ：

お久しぶりです。
ノート用でGTX680M発売決定らしいです。
http://www.geforce.com/hardware/notebook-gpus/geforce-gtx-680mx/specifications
GK104コアでCUDAコア数はGTX680同等、クロックはGTX680Mと同等
メモリクロックはGTX680M比で40%増し。
ノートも段々デスクトップと変わらなくなってきましたね。
性能次第じゃGTX680Mの時と同じでeBayからMXMカード取り寄せるかも…。

304 ：

>>303まちがい
新しいGTX680相当のSMX数で出るのは680MXです

305 ：

>>303-304
なるほど、こういうのでアップグレードするんですね。
http://www.ebay.com/sch/i.html?_nkw=MXM+%22680%22
ちょっと割高な気もするけど、これだけコンパクトにまとまっているのは凄いですねえ。

306 ：

OpenCL検索のスレッド周りの処理も一応仕上がりました。
これでいよいよ検索ルーチンの実装を始められます。

307 ：

検索ルーチンを作り始めたんですけど、Intelの実装とAMDのとで微妙に挙動が違って
きますね、これ。AMDのではエラーがでなくてもIntelのでエラーが出たりしてます。
思ったよりデバッグに時間がかかるかもしれません。
とりあえず両方のプラットフォームでトリップの変換ができていることは確認できました。
やっぱりIntelのほうが大分遅いですねえ。

308 ：

そうそう、検索君1号(仮)ですが、一番下のPCI-EスロットにGTX 590を移したら
温度の問題は全て解決しましたｗ いい具合に2番目と3番めのカードのあいだに
1スロット分の隙間が出来ました。590とマザボのピンが干渉するので
ケースの電源ボタン等は使えなくなったけど、別のがマザボについているので今のところ
困っていません。普段使っている検索パターンで安定して2.7G TPSでています。
1年前に800M TPS出して大喜びしていたのが遠い昔のようですｗ
もうさすがに買わないですけど、電源の容量から計算すると590 3枚でも
十分動作しそうです。3072コアで同時にトリップ検索なんて考えただけで
胸が熱くなりますｗ

309 ：

>>305
それです。
その一番大きなMXM3.0bという規格でもデスクトップ用の半分以下のサイズだと思いますよ。
ちょっと安いところのが撤退してますねぇ。
今出てる一番安いのはAlienware用のVRAM2GB版だけど
自分が買った時はVRAM4GB版でも799ドルだったのに。
さすがに999ドルなら自分も買ってなかったでしょうけども。
日本ってこういうパーツ全く出回らないんですよね。ニッチだけど需要はありそうなのに。

310 ：

>>309
部品が手に入りづらいとストレス溜まりますよね。
アメリカの人達はわりと大型のノートPCを好むというのもあるかもしれません。

311 ：

OpenCL検索のGPU側のコードを書き終えました。
とは言っても次の資料を見てCUDAのコードを書き換えただけですが…
Porting CUDA Applications to OpenCL
http://developer.amd.com/Resources/hc/OpenCLZone/programming/pages/portingcudatoopencl.aspx
あとはCPU側のコードを用意してやればOpenCL検索ができるようになるはずです。
OpenCLのコードは問題なくビルドできているので、あと残っているので
めんどくさそうなのはメモリ周りの処理ぐらいです。まあなんとかなるでしょう。

312 ：

CPU側のコードを用意ができたのでOpenCL検索を試してみたのですが、
Radeonだとwork-groupの数が不正だと怒られて動かせませんでした。
で、Intelのほうを試してみたら、奇跡的にトリップは生成されました。
が、めちゃくちゃ遅い! 遅すぎる! 仕方がないのでとりあえず
Radeonで動くようにしてからコードの見直しをすることにします。

313 ：

ちょっと手直ししたら今度はclEnqueueNDRangeKernelで
CL_OUT_OF_RESOURCESが出てしまいました。
仕様書を見たらレジスタやカーネルへの引数の数が多すぎるとこのエラーが出るらしいです。
いろいろ面倒くさいなあ…

314 ：

どうやらwork-groupのサイズはclGetKernelWorkGroupInfoで取り出さないと
いけない模様。これでうまくいくといいけど…

315 ：

あの後色々調べてみたけど原因はわかりませんでした。
う〜ん、CUDAの検索ルーチンをそのまま移植するんじゃなくて、
少しづつ動くのを確認しながら作り込んでいったほうがよかったのかなあ。
完全に煮詰まってしまったので食事をしてきます。

316 ：

AMDのOpenCLの実装で動かなかった理由がようやくわかりました。
16M bytesあるキービットマップの配列へのポインタをカーネルの引数で渡していたのが
原因でした。CUDAで実装したときも我ながら無茶な実装だと思ったものですが、
今の今まですっかり忘れていましたｗ 取りあえずなくても動くので
OpenCLではキービットマップを使わないことにしておきます。
多ターゲットの検索だとキービットマップがかなり有効なのはわかっているので、
あとで小さめのも作ることにします。

317 ：

というわけでOpenCLの12桁検索の試験実装がめでたくRadeon HD 5770で
動くようになりました。GPU使用率65%で190M TPS出ているので、CUDAの実装の
ベタ移植にしては上出来でしょう。ヒット率も綺麗に予想値に収束しています。
いや〜これでようやく安心できました。
あ、あとIntel HD 4000では同じコードで3M TPSしかでていませんｗ
こりゃほんとにおまけですねえ。

318 ：

GPU使用率を上げようといろいろ頑張ってみたのですが、
ちっとも上がってくれません。global_work_sizeとlocal_work_sizeを
いじっても駄目でした。mtyのときも似たようなことがあったし、
ドライバの仕様なのかなあ。

319 ：

ちっともGPU使用率が上がらないので、思いつきで1つの5770に対して
2つの検索スレッドを走らせたら、見事にGPU使用率が96%まで上がって
301M TPS出るようになりましたｗ 冗談みたいな話ですが
ヒット率は予測通りなのでちゃんとうごいているようです。
なんか釈然としないけど、きちんと動作しているのでこのままにしておきます。

320 ：

しかしRadeonは思った以上に性能が出ますねえ。
5770でこれなら7970だったら1枚で1G TPSを超えるかもしれません。
10進検索のほうも楽しみです。OpenCL検索の実装が順調に進んで、
GTX 780が噂通り680の改良版なら、次に買うのは8970になるかもしれません。

321 ：

>>318
それを知ってるのに秘孔は知らないのか？
ttp://sourceforge.jp/projects/naniya/svn/view/branches/mty-makai/hikou.c?root=naniya&view=log
効果があるかどうかはしらん。ｗ

322 ：

>>321
その処理をTripcode Finderに組み込もうとしたらAPIが古過ぎてコンパイル
できませんでした(´・ω・｀)

323 ：

>>322
効果があるか試すだけなら、バイナリもあるぜ。
http://trip2ch.net/wiki/index.php?%E3%81%BE%E3%81%82%E3%80%81%E5%BE%85%E3%81%A6%E5%B1%8B%E3%80%82
やってることは単純だから、今のAPIで同じことをやればいいんだろうけど。

324 ：2012/11/02

つhttp://yy43.60.kg/test/read.cgi/tripageruo/1274911652/