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

こちらは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/

■動作環境

【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

テンプレは以上です。

なるほどね

>>1
乙です。

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

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

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

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

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

で、問題の組み合わせはこれです。すぐにヒットするはずの"^AAA\.\."が
ヒットしないのです。

#regex
^[Aa]+$
^\.+$
^\.*AAA\.*$
^AAA\.\.

正規表現のパターンは内部である程度展開されているんですけど、
問題があるとしたら、(1)展開の仕方か、(2)検索時の見逃しか
どちらかのはずです。

内部変数をダンプしたらあっさり原因がわかりました。

> expandedPatternArray[ 10] = {`AAA..', 0}
> expandedPatternArray[ 11] = {`AAA.........', 0}

この部分でexpandedPatternArray[11]の条件が
expandedPatternArray[10]の条件と重なっているのが問題だとおもわれます。
expandedPatternArray[11]を取り除くようなルーチンを書いてやれば
解決するはずです。今あまり時間がないので今晩やろっと。

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

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

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

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

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

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

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

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

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

サンプルを参考にして自分で新規のプロジェクトを作成して
OpenCLのカーネルを呼び出すことに成功しました。これで
環境は整ったので後はひたすらOpenCLのコードを書くだけです。

しかしこれ、アプリケーションを実行するたびにカーネルをコンパイル
するようになっているんですね。デバッグとか超めんどくさいことに
なりそうな予感…

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

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

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

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

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

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

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

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

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

>>31
すごく使いやすいですよ。

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

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

>>33
そのコンセプトからするといい方向かと。
DOS窓でコマンド打ってまでやろうと思わない人のほうが多いでしょうしｗ

ただ、CPUのオートについてはまだ改良の余地があるかもしれません。
オートより6スレッドの方が自分の3820QMじゃ安定して速度出てました。
オートだと100%使い切っちゃってましたし。GPUドライバ周りのCPU負荷が高そう。
自分の使った感想だと6スレッド≧7スレッド＞8スレッドでした。トータル速度的にも。

トリッパー回しながらPCを使うという場面を想定してもオートだときつかったです。
いちおCPUは非力じゃないはずなのにオートだとまともに文字打てなくなりましたから。

ただ、CPU単体検索という面に於いても従来のソフトの2倍近く速度は出てるんじゃないですかね。

手持ちの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も熱くしてしまうので要注意ですね

>>34
CPU検索の自動設定は、何も考えずにCPU検索スレッドの数を
「(論理スレッドの数) - (GPUの数)」に設定しているだけなので、
これも変える必要がありますね。たぶんIntelの石ではhyper-threadingの
おかげでスレッド数を下手に増やすと遅くなる場合もあるのでしょう。
ここらへんはもうちょっと調べる必要があります。

現在の実装だととにかく速度を出すために目一杯計算資源を使っているので、
利便性の点からはかなり改善の余地があるでしょうねえ。検索スレッドの
優先度を低く設定してやるのも手かもしれません。今考えているのは検索の設定で
速度を「速い」とか「最大」とか「ゆっくり」とかから選べられるようにすること
です。GUIの実装が一段落したらぜひ取り組みたいですね。

>>35
詳しい報告、ありがとうございました。スレッド数を増やしてもペナルティに
ならないのはやはりXeonだからなんでしょうかね。非常に興味深いところです。
8800GTXも結構速度が出てますね。テスト用に一個欲しいところです。

このプログラムはシステム全体にとんでもない負荷をかけるのでかなり注意する
必要がありますね。私のメインのデスクトップPCはケースの蓋が開けっ放しです。
次からははじめからこんなの
http://www.dangerden.com/store/popup_image.php?id=428
か、こんなの
http://www.dangerden.com/store/popup_image.php?id=250
にしておきます…

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

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

>>35
そこはどうなんでしょね。
Keplerは従来よりもCPU負荷がきついですから
Fermiまでとは違うという事も考えられます。

いずれにせよ色々なプラットフォームで自動で最高の結果を出そうとすると
相当にデータ集めが必要なんだと思いますよ。単純に。
ホントにプログラミングとかかじったこともないド素人の意見ですけども。

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

できることはできる範囲で全力でやります。

>>40
> Keplerは従来よりもCPU負荷がきついですから

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

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

CPU、GPUそれぞれの単体でも従来よりずっと速いです。

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

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

>>45
今までのことを考えるととんでもないスピードだと思いますよコレ
確かにFermiの方がCUDAは速いけどもKeplerでも十分に速いと思います
というか構造上KeplerにCUDAのスピード求めるのも酷ですしね

あとノートは数日前にGTX6xxMXが発表されてKepler化がどんどん進むと思われます
こんだけ省電力で3D性能(に限って言えば)上昇してればKeplerシフトは進むわなぁ

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

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

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

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

バージョン0.05のBeta版が出来ました。

MERIKEN's Tripcode Finder 0.05 Beta 1
http://www.meriken2ch.com/programming/merikens-tripcode-finder

今回の変更点は以下になります。

・ウィンドウの設定の保存。
・GUIの改善。
・正規表現のバグの修正。
・エラーチェックの改善。

このバージョンに問題がなければ、これをこのまま安定版にする予定です。

さっきうｐしたばかりのBeta版ですが、うっかりエラー処理の不具合を
見逃していました。すいません… 修正したバージョンに差し替えておいたので
ダウンロードされた方はお手数ですがもう1回お願いします。

MERIKEN's Tripcode Finder 0.05 Beta 2
http://www.meriken2ch.com/programming/merikens-tripcode-finder

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

しかし675Mは580Mのリネームな上に
今度は(多分)Keplerの675MXを出すとかなんで分かりづらすぎです。

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

>>53
90度で常用だとかなり不安ですねえ。一応設計上は97℃まで大丈夫なはずですけど…

>>54
どもども。CPU検索はもうちょっと速くしたいですね。

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

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

さて、バージョン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

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

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

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

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

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
> [email protected] equ 1
> section .text code align=64
> %else
> section .text code
> %endif
> ;extern _OPENSSL_ia32cap_P
> global _sha1_block_data_order

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

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

色々ググってたら面白いことが分かりました。
この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

これはかなり楽して速度を上げられそうな予感…

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

興味をお持ちの分野から着手なさるのがいいかと。
それが有限の時間の中で一番効率がいいと思います。

我々下々にくだるご光栄のおこぼれも増えると思われます。
must to do 事項はなかなかしんどいですから。

ああ私は他力本願‥‥‥

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

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

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

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

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/

>>68
とりあえず今はSSE3を使ったSHA-1のコードを動かすことが最優先です。

>>69
12完とか数世紀単位ですよw

>>70
新しいバージョンのテストをぜひよろしくお願いしますです。

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

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

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

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

>>77
こいつですね
http://www.openssl.org/docs/crypto/OPENSSL_ia32cap.html

CPUIDを読みだしてプロセッサを判別する…ってことか

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

>>78
ここまですんなりいくとは思いませんでしたｗ
何事もためしてみるもんですね〜

>>79
間違い無くそれですね。とりあえずその変数をチェックしている部分は
全部削除してしまうことにします。

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

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

32bit版と64bit版はGUIのほうで選ぶようにすれば楽に実装できるはずです。

あ、あとアプリケーションを終了させたときに.NETの例外が稀に発生するバグを
見つけました。バージョン0.05の安定版では直しておきます。

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

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

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

う〜ん、しかしこうなるとできることは限られてくるなあ。
とりあえず64bit版が大分速くなるということはわかったので、
これはバージョン0.06で使えるようにしておきます。

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

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

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

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

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

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

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

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

バージョン0.05の安定版をうｐしました。

MERIKEN's Tripcode Finder 0.05
http://www.meriken2ch.com/programming/merikens-tripcode-finder

>>84-85のバグを修正した以外は、Beta 2と同じです。

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.

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

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

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

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)

>>100
それはなによりです。自分もGUI版をしばらく使ってますけど、
色々気になるところを直してようやく馴染んできた感があります。

>>101
そうですそうです、エラー処理のいい加減だったところがちゃんと直っているようで
良かったです。しかし10桁検索のルーチンはCC1.0でも動くように書いといた
はずなんですけど、共有メモリかレジスタ数の関係で動かないみたいですね。
注意書きに追加しておきます。

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

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

私も楽しみです^q^

64bit版もすんなり動きました。12.21M TPS出ているのでこれまでのバージョンと
比べるとかなり速くなりました。まあでも同じCPUでmtyでは25.06M TPS出ているので
性能的にはまだまだこれからといったところです。

とりあえずはCUDAのときと同じようにS-Box内の一時変数の割り当てを手作業で
最適化することになりそうですが、アセンブラを使わずにSSE Intrinsicsのみで
どこまで最適化出来るかは未知数です。John the Ripperのアセンブラで書かれた
Bitslice DESのルーチンを使用することも考えたのですが、ABIの違いも考慮しなければ
いけないのが悩ましいところです。

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

今後の方針を考えてたんですけど、やっぱり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の実装を試して見ることにします。

>>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さん、ありがとうございました。

それはそうと、最近こんな話を見つけました。

http://www.obr-hardware.com/2012/09/exclusive-some-geforce-gtx-780-details.html

どうやらGTX 780はGK110ベースにはならないそうで…
今のうちにお安く590買っておいたほうがいいのかしらん。

遠くから期待してます

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

>>109
お役に立てて光栄です
今度の修正がきたら8800GTX+GT520の
組み合わせで再度試させてもらいます

それとGT520やCPUで10桁検索を行った場合に出る
○.○世紀という表記は何かのギャグかと思いましたよ

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

とりあえず64bit対応版は出来ました。「詳細設定」からCPUの
命令セットを切り替えられるようになりました。
やってることはCUI版のx86のビルドとx64のビルドを切り替えてるだけなんですが…

で、OCしてどれぐらいスピードが出るか試してみたんですが、
前スレの12桁検索の最高速の記録にきれいに6M TPSほど上乗せできてます。
10桁のほうも113M TPSほど出るようになりました。
楽して速度向上、おいしいです（＾q＾）

もうちょっと色々テストしてから日曜の夜までには新しい開発版をうｐする予定です。

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

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

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

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

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

>>119
うーん、それならばパターンの数が多過ぎて捌ききれていないということなんでしょうねえ。
もうちょっとループの回数を減らしたほうがいいのかな…

>>120
CPUクーラーはNoctuaのNH-D14です。でかいです。4.6GHzでの運用を試してみてたんですけど、
システムにかなり無茶させてるのでちょっと無理だったみたいです。これ以上は殻割りか水冷にでも
しないといけないんでしょうけど、ちょっと踏ん切りがつきません…

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

応援してます

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

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

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。

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

鳥検索が捗るな

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

原文では45GHzで90GFLOPSのCPU相当と言っているように見える。

5W以下らしいからワットパフォーマンスは悪くなさそうだし
10基とか20基積んでイーサネットとか付いた箱が安く出てくると面白そうだけど。

新しい開発版です。

MERIKEN's Tripcode Finder 0.06 Alpha 1
http://www.meriken2ch.com/programming/merikens-tripcode-finder

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

・64bit版の追加による高速化。
・10桁検索の高速化。
・複数のビデオカードが使用できないバグの修正。

おつ

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

>>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/

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

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

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

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

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

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の
ルーチンは相当速いことになります。なかなか面白いことになって来ました。

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

つらつらとJohn the Ripperのコードを読んでいたらだんだんと思い出してきました。
キーと一時変数と変換結果はまとめてDES_bs_allという構造体に
格納されていて、次の順番で関数を呼び出せば一回の変換が
行われるはずです。

DES_bs_init()
DES_bs_set_key()
DES_bs_set_salt()
DES_bs_crypt_25()

一応必要な関数は全てビルドできたので、あとはテスト用のコードを書いてやれば
いいだけなんですけど、なにせブラックボックスを相手にしているので
結構緊張します。ちょっと休んでから取り掛かることにしようっと。

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超えに期待しています。がんばって下さい。

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

大変な勘違いをしていたことが判明しました。
Xeon [email protected], 1CPU, 6コア, HT有効, 12スレッド
と、思い込んでいたのですが、中身を確認したら全然違いました。
Xeon [email protected], 2CPU, 12コア, HT無効, 12スレッド

通りでCPUが早い訳だ。orz
ウソ報告でごめんなさい。HT有効にして再計測してみますが、少し走らせた感じでは余り変わらないみたいです。

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

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

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

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

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

x64 Intrinsicsで頑張るしか

targetはこれなんですけどね？^MERIKEN.s

◆MERIKENXsUyM #ﾇ鋒ﾑﾅ徳6ｶﾙ3o (C7 96 4E D1 C5 93 BF 36 B6 D9 33 6F)

これがあれですかね？”."

>>149
IntrinsicsだとどうもSSEのレジスタの割り付けがうまくいってないみたいなんですよね〜

>>150
正規表現だと"."はすべての文字にマッチするのでそれはあってます。
正規表現で"."を指定したいときには"\."と書いて下さい。

これでしたか。　　

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

癖がついてて、”.”使うんですね。

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

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

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

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

CPU-Zぐらい使えよ

>>156
> 数値がおかしいんで蓋開けてみたらCPUが二個付いてた・・・

これはなかなかシュールな絵ですねｗ GPU-Zもお勧めです。

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

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

正直John the RipperのBitslice DESの実装を使えるようにするのも、
Bitslice DESのルーチンを1からアセンブラで書くのも時間がかかりすぎなので、
あともう一つだけアイディアを試してみて、それでうまくいかなかったら
CPU検索の最適化はとりあえず一旦お休みにします。

で、最後のアイディアというのは、Bitslice DESの最深部だけ別のコンパイラで
コンパイルしてやるということです。どうも調べてみるとVC++のSSE Intrinsicsの
最適化はGCCやICCに比べるといまいちなようなので、ある程度の効果は
期待できるでしょう。あとは32bit版だけインラインアセンブラを使って
最適化するという手もあるんですけど、それは後回しにします。

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

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

う〜ん、どうやら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を確保しておこうっと。

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

tesla待とうよ！

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

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

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

GTX590確保しました! ('◇')ゞ

CPU: PhenomeII X6 [email protected]
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

速ぇー

速すぎﾜﾛﾀ

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

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

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

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

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

| 冫､)ｼﾞｰ

linux版の登場が待たれるな

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

CUDA5来ましたね
http://developer.nvidia.com/cuda/cuda-downloads

NVIDIA，「CUDA 5」を正式発表。第2世代Kepler「GK110」に向けた準備が整う
http://www.4gamer.net/games/076/G007660/20121016013/

>>173
夜中に部屋の窓を全開にして両方とも80℃ちょい。窓を閉めると90℃超えます。
今の季節だと、クーラー無しに昼間に常用するのは難しいと思います。
580SLIに590を付け足すなら、エアフローに気をつけて下さい。
最初、エアフローが悪くて580の温度が90℃を軽く超えていって怖い思いをしました。
消費電力は、計算時に+690Wでした。

前日書き忘れたのですが、ブロック数の自動設定機能が安定しませんでした。
走らせるたびに96?〜168?の間をふらつきます。590の二つのGPUでも異なるブロック数になることもありました。

590は早々にXeonマシンに引っ越すつもりなのですが、まだ電源スペックが分からねぇヽ(´Д｀；)ノ

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

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

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

>>182
非常に参考になりますです。今ある580 SLIを580+590にする予定なんですけど、
2枚のグラボの間に隙間がないので、590は下側につけておいたほうが
よさそうですねえ。ケースにはまるといいんですけど…

ブロック数の設定の違いはいい解決方法が思いつかないです。まあ128以上
だったらほとんど誤差程度の違いしか出ないので大丈夫でしょう。

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

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

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

>>178
Radeonには次のバーションで対応する予定です。

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

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

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

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

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

同時に廻すならアプリケーションを使わない時の方がいいと思われ

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

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

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

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

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

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

Intelで動く…だと…？

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

そんなまさか

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

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

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

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

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

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

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

>>210
> 色々表示された後に

ここのところをもうちょっとｋｗｓｋ
あとpatterns.txtはどこにありますか?

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.

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)
=========

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

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

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

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

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

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

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

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

導入に対して敷居や導入コストが高いのが難点ですが、ある程度まで理解できれば何とかなると思います。

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

そうですね、初期設定さえ出来れば後の起動は楽なのがいいです。
こういった開放型のケース？で埃等は問題ないのでしょうか、その点怖い気がします。

これだけの容量であれば何も問題ないですね、あとは知識を収集して水冷化に挑戦といったところでしょうか。

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

水より冷える液体がいいですね。

>>206
間違いますよね。変えます

>>205
のたんぺさんは、引退ですか？

最強のトリップ検索人ですよね。

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

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

結局これも読まんといかんのかな。まいったなあ…

Intel 64 and IA-32 Architectures Optimization Reference Manual
http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf

Bitslice DESの各ゲートを、

A = OP(B, C)

という形から、よりSSEの命令セットに近い

A = OP(A, B)

という形に書き換えてるのですが、ようやくちょっとづつ速度が上がって来ました。
変換が終わったら、まとめられる一時変数をすべてまとめてしまう予定です。

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

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

新しい開発版です。今回の変更点は10桁トリップCPU検索の速度向上です。

MERIKEN's Tripcode Finder 0.06 Beta 1
http://www.meriken2ch.com/programming/merikens-tripcode-finder

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

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

次のページを参考にして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のドライバを入れて
もう一回試してみます。

よく見たらこれ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

デバイス一覧を取得しました。なぜか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]

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

もうどこからつっこめばいいのかわからんなこれ。ｗ

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

いや〜、これちょっとやばいですよね…
IntelのOpenCLのSDKをインストールしても見えなかったのでおかしいなと
思ってたんですけど、なんとマザボにディスプレイを繋いだらようやく
OpenCLのAPIからIntel HD 4000を認識できるようになりました。

> 1: [Intel(R) Corporation] [Intel(R) HD Graphics 4000] [GPU]

CUDAと違って、OpenCLはかなりカオスですねえ…

やはりディスプレイをつながないと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

いやいや、つっこみどころが多いのは OpenCL に対してじゃなくて。
ちゃんとマニュアルとか読んだ方がいいんじゃね？

まあまだサンプル動かしてみただけの段階なんだろうけど。

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

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

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

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

とりあえずこのサンプルを読んだら大体の流れはわかりました。

Getting started with OpenCL and GPU Computing
http://www.thebigblob.com/getting-started-with-opencl-and-gpu-computing/

まずSHA-1とDES cryptのルーチンを移植して、ちゃんと動くのが確認してから
実際の検索ルーチンを作成することにします。やることはCUDAの場合と
ほとんど変わらないので、割とすんなり行きそうな予感…

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

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

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

初めまして。

なんとなくトリップ検索(特に12桁)を再開したくなり、
ひょんなことから、こちらの安定版を頂きました。

残念ながらラデオン使用＋中古パーツ寄せ集めの自作なんで、
貴ソフトを100%活用できていませんが、表示される検索数には驚いていますw

CPU検索＋スレッド自動ですが、
Phenom �U Black x6 が、６コア100%稼動するのを初めて見ました。

ソフトの進化、期待しています。
(こっちのハードも進化させねばorz)

テストベンチに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。

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

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

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

最高速の測定の続きです。あの後まさかと思って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。

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

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

あのあとテストベンチの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の放熱が
やはりというかうまくいかないらしく、クロック周波数を限界まで落とさざるを
得ませんでした。

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

もともと真ん中の580は乗っけるつもりがなくて、
590を買って余ってたのを使っただけなのでこれでいいのですｗ
最初はグラボを3枚のっけるなんて考えてもいなかったので…

余った580はオクで売っぱらう予定だったんですけど、
今の構成が思いのほかうまく動いているので当分このままにしておきます。

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

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

>>258
BIOSで常に有効にしたり出来ないのでしょうかね？

>>259
冬も暖房不要になりそうですねｗ
グラボの冷却は最終的にはやはり水冷なのでしょうかねえ・・・

>>264
BIOSの設定も色々いじってみたけど駄目でした。
>>241のリンク先でIntelの人がはっきりと無理だと言ってるので無理なんでしょう。

恐らく消費電力はシステム全体で1000W近いので、電気ヒーターなど目ではありませんw
まあ性能のことだけ考えるなら水冷のほうがいいんでしょうけど、
保証がなくなるのと手軽にグラボの交換ができなくなるのは痛いですね。
590 4枚差しとかちょっと見てみたい気がしますけどねｗ

>>265
BIOS設定でもどうにもならないとなると厳しいですね。

手持ちの電気ヒーターの消費電力を測ってみたことがあるのですが
強では表示どおり1200W、弱で600Wだったのでなかなか手ごわいですよｗ

GTX590を4枚となると1500Wを超えて電源が2系統必要になりそうです。

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

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

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

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

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

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

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

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

>>274
違います。NVIDIA以外のグラボでもGPU検索ができるようになるかも、という話です。
計算量が桁違いなので、理論的に10桁検索が12桁検索と同じぐらい速くなるということは
あり得えないです。

ただ、RadeonのグラボはNVIDIAのものに比べて10桁検索に向いているということは
ありそうです。というかCUDAと10桁検索が壮絶に相性が悪いだけなのかも
しれませんが…

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

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

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

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

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

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

GeForceでのGPGPUの今後はわかりませんね〜
GK110がGeForceに降りてきてくれればいいんですけど…

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

こんばんは。

>>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ぐらいです。
そちらと同じ検索条件にすれば、もっと早くなるのは分かってますが、つい・・・^^;

ではまた。

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

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

これはRadeon向けの最適化の資料です。あとでじっくり読もうっと。

AMD Accelerated Parallel Processing OpenCL Programming Guide
http://developer.amd.com/tools/hc/amdappsdk/assets/AMD_Accelerated_Parallel_Processing_OpenCL_Programming_Guide.pdf

あまりも検索君1号(仮)のGPUの温度が高すぎて心臓に悪いので、
こんなものを注文しました。

BestDealUSA PCI-E Express 16X Riser Card Extender Extension Cable Ribbon Flex
http://www.amazon.com/gp/product/B00646VJDG

これで真ん中のグラボを浮かせてやって空気の流れを良くしようという狙いです。
まあ見た目は悪くなるだろうけど、効果は確実にあるでしょう。

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

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

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

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

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

8800ＧＴ　メモリ2GBのPCですが、検索停止ボタンを押すと完全に固まります
フリーズ中はGPUのファンは静かになっていて、HDDが規則的なリズムでガリガリと鳴りつづけていました

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

使っていて変な汗が出たソフトナンバーワンなのは間違いないです

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

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

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

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

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

>>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への最適化でしょうかね？

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

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

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

お久しぶりです。
ノート用でGTX680M発売決定らしいです。
http://www.geforce.com/hardware/notebook-gpus/geforce-gtx-680mx/specifications

GK104コアでCUDAコア数はGTX680同等、クロックはGTX680Mと同等
メモリクロックはGTX680M比で40%増し。
ノートも段々デスクトップと変わらなくなってきましたね。

性能次第じゃGTX680Mの時と同じでeBayからMXMカード取り寄せるかも…。

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

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

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

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

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

もうさすがに買わないですけど、電源の容量から計算すると590 3枚でも
十分動作しそうです。3072コアで同時にトリップ検索なんて考えただけで
胸が熱くなりますｗ

>>305
それです。
その一番大きなMXM3.0bという規格でもデスクトップ用の半分以下のサイズだと思いますよ。

ちょっと安いところのが撤退してますねぇ。
今出てる一番安いのはAlienware用のVRAM2GB版だけど
自分が買った時はVRAM4GB版でも799ドルだったのに。
さすがに999ドルなら自分も買ってなかったでしょうけども。

日本ってこういうパーツ全く出回らないんですよね。ニッチだけど需要はありそうなのに。

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

OpenCL検索のGPU側のコードを書き終えました。
とは言っても次の資料を見てCUDAのコードを書き換えただけですが…

Porting CUDA Applications to OpenCL
http://developer.amd.com/Resources/hc/OpenCLZone/programming/pages/portingcudatoopencl.aspx

あとはCPU側のコードを用意してやればOpenCL検索ができるようになるはずです。
OpenCLのコードは問題なくビルドできているので、あと残っているので
めんどくさそうなのはメモリ周りの処理ぐらいです。まあなんとかなるでしょう。

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

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

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

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

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

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

あ、あとIntel HD 4000では同じコードで3M TPSしかでていませんｗ
こりゃほんとにおまけですねえ。

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

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

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

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

効果があるかどうかはしらん。ｗ

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

>>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で同じことをやればいいんだろうけど。

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

目指せ純12連発見

HTがトラウマになったので、影響を調べてみました。

CPU: Xeon [email protected] x 2
GPU: Quadro FX 3800
Prg: 0.06a1
Len: 12
Targ: "TEST/"
Opt: -c -g -x 16
Drv: 306.79

この条件でOSとHTを買えて計測しました。

先ずはXPから。
Case 1-1
CPU: HT off (12 thread)
OS: WinXP SP2 64bit
1hrAv: 240.76M TPS
Others:
243.23M TPS (curr)
171.13M TPS (GPU)
72.11M TPS (CPU)

Case 1-2
CPU: HT on (24 thread)
OS: WinXP SP2 64bit
30minAv: 247.84M TPS
Others:
247.50M TPS (curr)
171.13M TPS (GPU)
76.72M TPS (CPU)

次は7です。
Case 2-1
CPU: HT off (12 thread)
OS: Win7 SP1 64bit
30minAv: 241.77M TPS
Others:
241.44M TPS (curr)
169.01M TPS (GPU)
72.43M TPS (CPU)

Case 2-2
CPU: HT on (24 thread)
OS: Win7 SP1 64bit
30minAv: 246.28M TPS
Others:
246.97M TPS (curr)
170.87M TPS (GPU)
76.10M TPS (CPU)

連投済みません。
XPから7にしても性能変わらんねぇ。(´・ω・｀)
HT on/offでも大して変わらんねぇ。(´・ω・｀)

GTX590を追加しようとしたのですが、電源容量が足りないことが判明。
GPU用に8ピンx2を用意する上手い方法は無いでしょうか?
ATX電源だと確かスイッチ入れないと出力されなかったような気が・・・

>>329
つ「ttp://www.freedom-pc.com/product/card_reader.html」
一台目の電源ユニットに連動するやつも見たことあるけど。

だがしかし、おすすめはしない。いろんな意味で【危険】だから。
素直に電源ユニットをいいやつに交換したほうが。

>>329
HTを有効にしても速度が上がらないのはかなり意外ですねえ。
Core i7-3770KではHTはかなり有効だったので…
電源は入れ替えたほうが早いような気もしますけど、
一応別に用意することもできます。
https://www.google.com/webhp#q=atx+%E9%9B%BB%E6%BA%90+%E3%82%B7%E3%83%A7%E3%83%BC%E3%83%88

>>323
hikou.exeは多少効果がありましたけど、それでもGPU使用率は70%ほどでした。
GPU検索スレッドを増やす方向で行きたいと思います。

一瞬、複数の電源系統を使って、1台での最速を目指すのかと思ってしまいましたｗ

>>311
こういった情報はありがたいですね。

>>317 >>319
Intelの方はグラフィック特化で、とりあえずOpenCLに対応はさせたということなのでしょうかね。
AMD APUの方は上位だと3桁行きそうな感じですね。

>>329
今から追加するならラデのほうが速くて良くね？
openCL版もそろそろ公開されそうだし
今更性能の悪いCUDAカード追加するのはクレバーとは言えないよ
暖房に使うならありかもしれないけどねwww

>>335
ん? OpenCL版は公開するなって? そうかそうかｗ

…という冗談は置いといて、正直GCNアーキテクチャのRadeonで
どれぐらいの性能が出るかは全くの未知数です。あとTripcode Finderの
Radeon対応版の公開はもうちょっと先になるでしょう。10桁検索の
実装はこれからだし、この先実生活のほうでかなり忙しくなるので
ひょっとしたら1月中旬までずれ込むかもしれません。まあ気長に
待ってて下さい。

>>334
IntelのはなぜハイエンドのCPUに統合したのか理解に苦しむレベルです。
AMDのAPUだったら3桁は余裕でしょう。

>>333
この資料のお陰で他の資料を読まずに済みましたｗ
あとで一応AMDの最適化のマニュアルには目を通しておきますけど…

コマンドライン上から1枚目のカードを検索の動作から外すのはどう指定すればいいのでしょうか。

>>339
今のところカードは1枚指定するか全部指定するかどちらかしか出来ないので、
CUI版を複数同時に起動する必要があります。
任意の複数のGPUを指定する機能は今後の課題として検討させて頂きます。

あれからOpenCL検索の最適化をすすめて、HD 5770で390M TPS出るようになりました。
とはいってもglobal_item_sizeとlocal_item_sizeの値をいろいろと
変えてみただけですが… これらの値の自動設定は無理そうなので、
GPUの種類を判別してあらかじめ決められた値を使うようにしておきました。
あとIntelのもちょこっと上がって3.7M TPSになりましたｗ

ゲフォを捨てる日も近いな

Amazon Cluster GPU Instances（$2.6/h）でやってみた
http://img11.imageshack.us/img11/8029/29089004.jpg

>>341
>GPUの種類を判別してあらかじめ決められた値を
性能別にざっくり分ける感じですか？

>>343
FermiベースのTesla C2075が2枚刺さってますね。
Amazon Web ServicesでCUDAが使えるとは知りませんでした。
2週間回し続けたらGTX 590が買えるお値段になっちゃうけど、
なかなか面白いですねえ。ネットワーク分散処理に対応したら
これで記録を立ててみようかなｗ

>>344
global_item_sizeとlocal_item_sizeはオプションで指定できるように
するつもりです。最初はGPUのアーキテクチャ毎にデフォルトの値を
設定しておいて、データが集まったらカード毎に値を変えるようにする予定です。

>>346
なるほど……

AMDのOpenCLのマニュアルをちょこっと読んだんですけど、
ベクターレジスタがこれでもかというぐらいあって思わず笑ってしまいましたｗ

AMD Accelerated Parallel Processing OpenCL Programming Guide
http://developer.amd.com/tools/hc/AMDAPPSDK/assets/AMD_Accelerated_Parallel_Processing_OpenCL_Programming_Guide.pdf

これによると5970は5770の3.41倍の速度が出るそうで、単純計算だと
391M TPS * 3.41 = 1333M TPS出ることになりますけど、本当なんでしょうか…

あ、5970はdual-GPUなんですね。あ〜びっくりしたｗ
しかしお値段を考えるとかなりお得で夢が広がります。
年末に日本に帰省してるあいだは開発はできなくなるので、
なんとかそれまでにRadeon対応版を仕上げたいです。

いろいろ情報ありがとうございます。
訳有って電源を変えることもCUDAを捨てることもできないのです。
電源を変えたいのは山々なんですが。

>>330 >>331
複数電源やってる人多いんですね。確かにいろいろな意味で危険だ。
でもこれしか今のところ手が無いので、この方法で行ってみます。

NehalemからSandy BridgeになったところでCPUコアに大幅に手が入っているから、HTの効果がより大きくなったのではないでしょうか? 詳しいことは全然知りませんが。

余った電源を探しに押入れを漁ったのですが見つからず。代わりに大昔のGTX480が出てきました。
見なかったことにするか・・・。

>>350
> 代わりに大昔のGTX480が出てきました。

いらないのでしたらテスト用に欲しいのでぜひ譲って下さいw

>>313と>>316のエラーですが、結局巨大なキービットマップが__constantの
メモリ空間に収まらなかったということみたいです。まあ当然ですよねｗ
で、代わりにかなり小さめのキービットマップを用意してやったら、
なんと407M TPSまで速度が上がりましたw これ、CUDAのでも使えるんじゃない
かしらん。

SHA256ハッシュだとこんな感じの速度になるらしい

ttps://en.bitcoin.it/wiki/Mining_hardware_comparison

やっぱりSHA-1よりは大分数字が落ちますねえ。
ここらへんの数字はなかなか面白いです。

> 5970 $421 Limited 704
> 6990 $622.99 Limited 772
> 7970 $420 Easy 685

トリップ検索が目的なら安い5970を中古で買ったほうが
いいのかもしれません。

小さめのキービットマップを追加するついでにコードを大分整理しました。
もう十分速度は出ているので、最適化は適当に切り上げて
OpenCLの12桁検索だけ先に仕上げてしまうことにします。

前方一致以外の正規表現の検索への対応も終わって、
CUI版のOpenCLでの12桁検索対応の作業はほぼ終了しました。
あとはglobal_work_sizeとlocal_work_sizeをオプションで
出来るようにして、GUI版を修正するだけです。
本当は10桁検索にも対応させてから公開する予定だったけど、
こっちは難物で最適化に時間がかかりそうなので後回しにします。

あ、あとIntelのコンパイラは新しいOpenCLのカーネルをコンパイル
できませんでしたｗ clGetProgramBuildInfoであっち側に行ったきり
帰って来ません。まあカーネルがマクロ使いまくりでちょっと
複雑なのは事実なんですが、どうせIntelのドライバのバグだろうし
HD 4000ちゃんは全く性能の出ないアホの子だということが
わかってしまったので、このままにしておきます。

>>356
峠は越えましたね乙です
公開を楽しみにしております

>>357
どもども。あとちょっとなので頑張ります。CUI版の作業は一応全部終わりました。
あとはGUI版だけです。

その前にバージョン0.06の正式版をうｐしなきゃ… すっかり忘れてた。

バージョン0.06の安定版です。

MERIKEN's Tripcode Finder 0.06
http://www.meriken2ch.com/programming/merikens-tripcode-finder

機能的にはBeta 1と変わりません。バージョン0.05の安定版からの変更点は
以下になります。

・64bit版の追加。
・CPU検索の速度向上。

>>360
早速テストしてみましたよー(検索ワードは「^TEST/」)

環境:ASUS K55VD(Corei5-3210M+GeForce610M,64bitWin7)
10桁結果:
　　　　　GPUのみ 　 GPUとCPU 　 　 　 CPUのみ
6.0β 　 2.92　　　　　7.00(3.0/4.0)　　　　5.26
6.0　　　 3.07　　　　　7.00(3.1/4.0)　　　　5.25
12桁結果:
　　　　　GPUのみ　GPUとCPU　　　　CPUのみ
6.0β 　 43.02　　　 53.54(42.8/10.8)　14.47
6.0　　　 43.02　　　 55.72(44.9/10.8)　14.50
(単位はM tripcode/s)

ところで、「検索の最適化中...」ってどんなことをしているんですか？
このテストの際も、その表示が消えるのを待ってやった方が良かったのか迷いました……

>>361
詳しい報告、ありがとうございます。検索の最適化では「詳細設定」の
「1SMあたりのブロック数」の自動設定をしています。この報告でもCPU検索の
正確な速度とGPU検索のおよその速度は分かりますが、GPU検索の正確な速度を
測定したい場合は手動でブロック数を設定する必要があります。
この場合CUI版を使えば最適なブロック数の目安を知ることができます。

安定版をビルドしたついでに一気にGUI版の作業も終わらせました。
これでちゃんとOpenCLでの12桁検索ができるようになりました。
機能的にもCUDA版に遜色ないはずです。というか全く普通に検索できているので
シュールに感じるぐらいですｗ しばらく手元で色々試してから、問題なければ
2、3日中に次の開発版として公開する予定です。

みんながゲフォを捨てる日も近いな

>>360
お疲れ様です。

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: "trip/"
Performing a forward-matching search for 1 pattern (1 chunk)
with 5 characters on CPU and GPU(s):
CUDA0: 278.7M TPS, 96 blocks/SM

0.150T tripcodes were generated in 0d 0h 9m 08s at:
302.83M tripcodes/s (current)
GPU: 281.89M tripcodes/s
CPU: 20.94M tripcodes/s
272.94M tripcodes/s (average)
On average, it takes 2.7 seconds to find one match at this speed.

123 matches found at 807.78 matches/h and 1.22G tripcodes/match.
The actual matching probability is 3% lower than expected.
9% of matching tripcodes were invalid.

アホの子（笑）Intel HD4000 の計算する姿が見れると聞き、3770 マザーボードを
設定変更して HD4000 Graphics を有効にし、これまで Radeon HD5770 につないで
いた２台のディスプレイのうちサブのほうを 3770 マザーボードのオンボードグラ
フィックに接続して使っています。　２〜３日後の開発版の公開が楽しみです。

HD5770 について、これまで非シバキ時の GPU CLOCK が 400MHz を下回るのを見た
ことがなかったのですが、今回デュアル接続をやめたら 157MHz まで下がるように
なり、非シバキ時の GPU 温度も１０℃近く下がりました。これはうれしい。

>>354
プロセスルール的に消費電力が気になりましたが、HD 5970は300W弱で8ピン+6ピンだったのですね。
VLIWや制御ユニットの集中などのアーキテクチャの違いでピーク時のワットパフォーマンスは良いのでしょうかね。

そろそろグラボの補助電源で6ピンx2はやめて8ピンx1にならないのでしょうかね・・・
6+2ピンの電源ユニットも増えていますし、6ピンx2を8ピンx1に変換するケーブルとかもありますし。

>>360 >>363
乙です。OpenCL版が楽しみです。

>>366
残念ながらIntelのドライバのバグが直るまでHD 4000では動きませんです。
エラーでプログラム自体が落ちるのでもとに戻しておいたほうが良いかもしれません。
5770だけでも十分に幸せになれますしね。昨日OCして速度を測ってみたら
7完1タゲで452M TPS出てました。

>>367
ワッパ的には5970はかなり美味しいでしょうね。5770もOCさせても
せいぜい60℃ぐらいまでしか上がらないのでやっぱりアーキテクチャの違いなんでしょう。
Fermiとはエラい違いですｗ 補助電源のコードの取り回しも普通のケースだと
結構面倒くさいですよね。うちの検索君1号(仮)の電源からはPCI-Eの補助電源用の
ケーブルが6本にょきにょきと伸びていますｗ

8970の出荷が思ったより遅くなりそうなので、さきほど7970を注文してしまいました。

AMDの新「Venus」コアは2013年3月のRadeon HD 8970から？
http://ascii.jp/elem/000/000/741/741077

OpenCLの10桁検索の作業を進めるにあたって、GCNアーキテクチャでの性能を
確認しておきたいというのが大きいですが、いくらなんでも散財し過ぎなので、
これで当分の間グラボを買うことはないでしょう。

意味不明なエラーが出て終了するのも何なので、Intel HD Graphicsシリーズは
最初に弾くようにしておきました。将来のドライバ更新に期待といったところです。
もう修正したいところは全部修正したので、これから配布パッケージを用意して
開発版を公開することにします。

というわけでRadeonに対応した開発版です。

MERIKEN's Tripcode Finder 0.07 Alpha 1
http://www.meriken2ch.com/programming/merikens-tripcode-finder

変更点は以下になります。

・AMD Radeonシリーズ等のOpenCL対応デバイスでの12桁トリップ検索への対応。

相変わらず出来立てほやほやの人柱専用です。

動作報告をしていただける方にはこちらのテンプレを使っていただけると
大変助かります。

【GPU】
【CPU】
【OS】
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【1CUあたりのワークグループの数】
【1WGあたりのワークアイテムの数】
【その他のオプション】
【Display Driver】
【10分間の平均速度】
【その他】

自分の環境ではこんな感じで動いています。
オプションが紛らわしいので「検索デバイス」と「CPUの命令セット」の
項目を追加しておきました。

【GPU】Sapphire Radeon HD 5770 (OC: 960MHz)
【CPU】Intel Core i7-3770K (OC: 4300MHz)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【検索デバイス】GPUとCPU
【1CUあたりのワークグループの数】5120
【1WGあたりのワークアイテムの数】64
【CPUの命令セット】x64 + SSE2
【その他のオプション】
【Display Driver】Catalyst 12.9
【10分間の平均速度】488.51M tripcodes/s
【その他】7完1タゲ。CPU検索の速度は約39.4M tripcodes/s。

普段使っている正規表現の検索パターンをRadeonで回してみましたが
ちゃんと動いているようです。しばらくこれで放っておいて、きちんと
動作するかどうか確認することにします。

これで12桁トリップ検索を常時3G TPSで回せる環境が整ったわけですが、
自分の部屋の電力使用量が常に1500W前後と、とんでもないことに
なっています。7970をもう1枚追加したら本当にギリギリです。

しかし2台で同時に検索しているとやはりネットワーク機能が欲しく
なりますねえ。まあこれは当分先の話ですね。

しかしこれ、CPU検索とGPU検索の平均が別々にわからないのは
結構大きな欠陥ですねえ。なんで今まで気づかなかったんだろう…

間違えた。これ、明日直しておこうっと。

☓平均が別々にわからないのは
○平均速度が別々にわからないのは

【GPU】Radeon HD 6970（880MHz）
【CPU】Intel Core i7-2600（3.40GHz）
【OS】Windows 8 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【1CUあたりのワークグループの数】5120
【1WGあたりのワークアイテムの数】64
【その他のオプション】
【Display Driver】Catalyst 12.10
【6分間の平均速度】 832M tripcodes/s
【その他】12完1タゲ。最初Catalystをインストールしてないことに気づかず回していたら 250M tripcodes/sくらいでした

非常に早くて驚きました。これは素晴らしいです

【GPU】N/A
【CPU】i7-2600
【OS】WIndows 7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【1CUあたりのワークグループの数】N/A
【1WGあたりのワークアイテムの数】N/A
【その他のオプション】なし
【Display Driver】N/A
【10分間の平均速度】19M
【その他】タゲは TEST// のみで 10 分ではヒット無し

同条件で hip2 だと 52M ぐらいで 2 個ヒット。
てか、CPU が 100% にはりつきっぱなのをみると、使い切ってるというよりも競合とかで無駄が出てるのでは？
hip2 だとだいたい 95% 前後をふらつく。

>>378
いきなり凄いのが来ましたねえ! GPUだけで800M TPS前後出ている計算になりますね。
全く素晴らしいとしか言いようが無い数字です。

【GPU】 Radeon HD 7970 (925MHz)
【CPU】 Intel Xeon E5645 (2.4GHz)
【OS】 Windows 7 x64 SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【1CUあたりのワークグループの数】 512
【1WGあたりのワークアイテムの数】 64
【その他のオプション】
【Display Driver】 Catalyst 12.10
【10分間の平均速度】 1175.36M tripcodes/s
【その他】GPUのみ

>>379
う〜ん、うちのi7-3770Kでは1タゲで43M TPS出ているのでi7-2600で
その数字は低すぎですねえ。Intelの開発者が書いたコードを使っておいたほうが
無難だったかな… CPU検索の高速化にはまた後で挑戦し直す予定です。
あ、あとよかったらぜひhip2を公開して下さいｗ

>>381
(　д)　ﾟ　ﾟ

あ〜、びっくりしたw しかし気になっていたNorthern Islandsと
Southern Islandsでちゃんと性能が出ているようで安心しました。
>>378さんと>>381さん、どうもありがとうございました。

>>383

GPUが少し暇そうにしている（使用率80%弱ぐらいで推移）のですが、
これ使用率上げられたらもう少し早くなるんですかねえ。

>>385
あ、それは間違い無く速くなります。
次の開発版では検索スレッドをもう一つ増やしておきます。
テンプレにも「GPU使用率」の項目を追加しておいたほうがいいのかな。
しかし物凄い性能ですねえ。

さようならゲフォ

【GPU】Radeon HD 5870(850MHz)
【CPU】Corei7 2600K(4.6GHz)
【OS】Windows 8 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【1CUあたりのワークグループの数】5120
【1WGあたりのワークアイテムの数】64
【その他のオプション】GPUのみ
【Display Driver】Catalyst 12.11beta
【10分間の平均速度】436.79M tripcodes/s
【その他】タゲはTEST/

ほとんどの場面でGPU使用率が50%まで行かないです。
42〜49%あたりをふらふらしてる感じたまーに50%超えてるときは
現在の速度が500M tripcodes/s前後まで行ってます

>>382
盛ってると思うよな、やっぱり。
自分でもそう思うぜ。ｗｗｗ

http://ra8.s31.xrea.com/
に仮置きしてみた。てーすとってのがそうだ。

i7 用ってか SSE4.2 仕様の 64bit 版。
CPU 以外では動かないようにいろいろ細工してある。

全数字は勝手に探す仕様だ。
実際に表示の速度が出てるか確認用に入れてた。
-N2 オプションあたりが最速じゃないかな、多分。

なんかの参考にでも。って、ソース非公開だが。ｗｗｗ
まあ開発途中で投げたやつなのでいろいろアレだが気にスンナ。ｗｗｗ

【GPU】N/A
【CPU】i7-860 2,8GHz
【OS】WIndows 7 32bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【1CUあたりのワークグループの数】N/A
【1WGあたりのワークアイテムの数】N/A
【その他のオプション】なし
【Display Driver】N/A
【10分間の平均速度】23.8M
【その他】タゲは TEST// のみで 10 分ではヒット無し
CPU
===
Number of Logical Cores: 8
Number of Search Threads: 8
TARGET(S)
=========
0: "TEST//"
TRIPCODES
=========

STATUS
======
Performing a forward-matching search for 1 pattern (1 chunk)
with 6 characters on CPU.

0.015T tripcodes were generated in 0d 0h 10m 10s at:
23.78M tripcodes/s (current)
23.77M tripcodes/s (average)
On average, it takes 33.0 minutes to find one match at this speed.

No matches were found yet.

GPU】HD7970 CFX 2GPUs ＠1150MHz
【CPU】FX8350 ＠５GHｚ
【OS】Win7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【1CUあたりのワークグループの数】default
【1WGあたりのワークアイテムの数】default
【その他のオプション】-g -c -t8
【Display Driver】Catalyst 12.10
【8分間の平均速度】1015.07M
【その他】12完1タゲ

待て屋。爆速版でもしばしば起きていましたがGPUが全力出してないみたいです

http://www.rupan.net/uploader/download/1352198271.png

あ、平均間違った

こういうのってどうなんでしょうね
http://techon.nikkeibp.co.jp/article/NEWS/20121106/249731/?ref=rss&utm_source=twitterfeed&utm_medium=twitter

メリケンさんに聞きたいのですが、
「1SMあたりのブロック数」をいろいろ弄って最速の設定はどれかを試していたら、
「上げれば上げるほど速い」という謎の結論に達しました……(ちなみにノーパソのGeForce)
目一杯上げてもハードに悪影響を与えたりしませんよね？

ラデ＋HD4000環境で起動するとMERIKENsTripcodeFinderCUI: Error: Failed to load an OpenCL kernel.って言われちゃうんだが……
とりあえずドライバ更新とOpenCL再インスコしたが駄目だった

.NETの修復をしてWindowsUpdateして再起動したらなんか悪化した
OPENCL FUNCTION FALL FAILED: CL_DEVICE_NOT_FOUND (file 'Source Files\MTF_CUI_Main.cpp', line 676)

http://i.imgur.com/xjVFI.png
ドライバ更新しないで起動したら量子コンピュータもびっくりでワロタ

>>397
averageで9完が2.4分で終わるレベルｗｗｗｗ

>>395
この段階なら、絶対パスで起動すれば動いただろうな。

>>396
ドライバ入れ直したほうがいいですね。>>395のはOpenCLのソースコードが
実行時に見つからないときに表示されるエラーですが…

>>394
気になるのでしたらSpeedFanとかMSI AfterburnerとかでGPUの温度を
確認するのがいいと思います。

>>393
こりゃおもしろそうですね。やることなくなったらハードウェアハックにも手を
出してみようかなw

>>390
>>391
やっぱり検索スレッドの数を増やしたほうがいいんでしょうねえ。
たくさん盛るのは簡単なんですけど、オーバーヘッドが心配なので
いま調べているところです。

>>390
ありがとうございます。CPUだけのデータもまとめておいたほうがいいのかな…

>>389
盛っているというか、Tripcode Finderの数字が低すぎなのが気になります。
hip2は次にCPU検索の最適化の作業をするときに参考にさせて頂きます。
他に比較対象がないので助かります。

あ、間違えてる。>>403は>>388さんと>>391さん宛でした。

開発版を修正しました。

MERIKEN's Tripcode Finder 0.07 Alpha 2
http://www.meriken2ch.com/programming/merikens-tripcode-finder

Alpha 1からの変更点は以下になります。

・AMDのGPUでGPU使用率が低くなる問題を修正。
・GPUとCPUの平均速度の表示。

とりあえず1つのAMDのGPUあたりの検索スレッドの数は4に決め打ちに
しておきました。

こちらは新しい報告用のテンプレです。ぜひよろしくお願いします。

【GPU】
【CPU】
【OS】
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 2
【トリップの種類】12桁
【1CUあたりのワークグループの数】
【1WGあたりのワークアイテムの数】
【その他のオプション】
【Display Driver】
【10分間の平均速度】tripcodes/s
【GPUの平均速度】tripcodes/s
【CPUの平均速度】tripcodes/s
【その他】

「GPU使用率」を付け足すのを忘れてたorz
動作報告はこちらのテンプレでお願いします。

【GPU】
【CPU】
【OS】
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 2
【トリップの種類】12桁
【1CUあたりのワークグループの数】
【1WGあたりのワークアイテムの数】
【その他のオプション】
【Display Driver】
【10分間の平均速度】tripcodes/s
【GPUの平均速度】tripcodes/s
【CPUの平均速度】tripcodes/s
【GPU使用率】
【その他】

>>391
よくみたら、これGPU使用率が35%しかないですねえ。
検索スレッドが1GPUあたり4個だとたりないかもしれません。
足りないようだったら次の開発版でオプションで検索スレッドの数を
変えられるようにしておきます。

【GPU】GeForce GTX 570 / Radeon HD 5870
【CPU】Core i7-2600K
【OS】Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 2 (CUI64)
【トリップの種類】12桁
【1CUあたりのワークグループの数】5120
【1WGあたりのワークアイテムの数】64
【その他のオプション】
【Display Driver】Catalyst 12.11 beta
【10分間の平均速度】1216.38M tripcodes/s
【GPU使用率】GeForce 96%, Radeon 未計測
【その他】8完1タゲ、GPU検索のみ


CUDA DEVICE
===========
Device No.: 0
Device Name: GeForce GTX 570
Multiprocessor Count: 15
Clock Rate: 1464MHz
Compute Capability: 2.0

OPENCL DEVICE
=============
Vendor: Advanced Micro Devices, Inc.
Name: Cypress
Number of Compute Units: 20
Clock Frequency: 875MHz
Global Memory Size: 1024M bytes
Max. Work Group Size: 256
Version: OpenCL 1.2 AMD-APP (1084.2)
Driver Version: 1084.2 (VM)

STATUS
======
Performing a forward-matching search for 1 pattern (1 chunk)
with 8 characters on GPU(s):
CUDA0: 565.0M TPS, 192 blocks/SM
OpenCL0-0: 139.0M TPS, 5120 work-groups/CU, 64 work-items/WG
OpenCL0-1: 176.8M TPS, 5120 work-groups/CU, 64 work-items/WG
OpenCL0-2: 175.5M TPS, 5120 work-groups/CU, 64 work-items/WG
OpenCL0-3: 175.6M TPS, 5120 work-groups/CU, 64 work-items/WG

0.740T tripcodes were generated in 0d 0h 10m 08s at:
1219.88M tripcodes/s (current)
1216.38M tripcodes/s (average)


連投失礼しました。
変則構成のせいかもしれませんが、どうにも挙動が怪しい気がします。
これらは実行ファイルのダブルクリックによる直接起動の結果です。
コマンドラインからオプション無しで起動した場合は、以下のエラーが発生しCUDA検索のみ有効となります。

TRIPCODES
=========
MERIKENsTripcodeFinderCUI: Error: Failed to load an OpenCL kernel.
MERIKENsTripcodeFinderCUI: Error: Failed to load an OpenCL kernel.
MERIKENsTripcodeFinderCUI: Error: Failed to load an OpenCL kernel.
MERIKENsTripcodeFinderCUI: Error: Failed to load an OpenCL kernel.

>>411
5870だったらもうちょっと速度が出てもいいはずですね。
GPU使用率が100% 近いなら、-yオプションでワークグループの数を調整したほうが
いいのかもしれません。
コマンドラインでエラーが出るのはOpenCLのソースが読み込めていないだけなので、
GTX 570とは関係ないはずです。ちょっと調べてみます。

コマンドラインから起動してエラーが出たのはOpenCLのソースへのパスが
きちんと取得できていないだけでした。なんという凡ミス…
argv[0]でフルパスが取得できないとなるとどのAPIを使えばいいんだろう。

>>412
_fullpath()を使ったらエラーは出なくなりました。
次の開発版ではちゃんとコマンドラインから起動できるようになるはずです。

>>415
どうもです。次の開発版で-yオプションを試したいと思います。
ついでに補足ですが、GeForceのドライバは310.33 BETAでした。

>>401
調べてみたのですがこんな感じです。
ttp://uploda.cc/img/img5099980c9f2a2.png
よく分かりませんが、負荷が掛かり過ぎると自動検知して時々休んだりするんですかね？
(なお速度は50M弱で安定している模様)

ついでに一つ。自動設定で走らせた場合に、
検索停止後にそのパラメータを「詳細設定」タブに反映して欲しい……
毎回検索の最適化されるのは辛いですので

>>417
最適なパラメータは検索の条件によって変わってくるので
「詳細設定」タブに反映させるのは難しいのです。
あらかじめ値がわかっているならその値を指定しておけば
最適化は行われません。

>>417
あ、あとこの温度だったら全然問題無いです。

>>416
次の開発版では検索スレッドの数も変えられるようになっているので、
そちらのほうも是非試してみて下さい。

>>420
-yと-zですね。5870に最適の数値が見つかりましたら報告致します。

【GPU】N/A
【CPU】i7-2600
【OS】WIndows 7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 2
【トリップの種類】12桁
【1CUあたりのワークグループの数】N/A
【1WGあたりのワークアイテムの数】N/A
【その他のオプション】なし
【Display Driver】N/A
【5分間の平均速度】26M
【その他】タゲは TEST// のみで 5 分ではヒット無し

同条件で hip2 だと 74M ぐらいで同じくヒット無し。

>>379 と CPU とかは同じだが、別個体なので SDK のバージョンとかが違うかも。
なんかしらんが、>>379 の個体は遅いな。ｗ

あとものすごくどうでもいい情報だが、Radeon HD 4000 番台では動かんな。

うーん。Alpha 2 だとパフォーマンスあまり出ないなあ。むしろ下がっている。
代わりに、OCしてAlpha 1で計測したものを。

【GPU】 Radeon HD 7970 (OC:1125MHz)
【CPU】 Intel Xeon E5645 (2.4GHz)
【OS】 Windows 7 x64 SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 1
【トリップの種類】12桁
【1CUあたりのワークグループの数】 512
【1WGあたりのワークアイテムの数】 64
【その他のオプション】
【Display Driver】 Catalyst 12.10
【10分間の平均速度】 1230.65M tripcodes/s
【その他】GPUのみ

>>423
結構OC耐性がありますねえ。あと検索スレッドの数を無闇に増やせばいいという
ものでもないみたいですね。自分の環境ではワークグループの数を半分に
したらGPU使用率が98〜99%で安定するようになりました。次の開発版では
デフォルトの値を調整しておきます。

【GPU】Sapphire Radeon HD 5770 (OC: 960MHz)
【CPU】Intel Core i7-3770K (OC: 4300MHz)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 2
【トリップの種類】12桁
【1CUあたりのワークグループの数】2560
【1WGあたりのワークアイテムの数】64
【その他のオプション】
【Display Driver】Catalyst 12.9
【10分間の平均速度】486.23 tripcodes/s
【GPUの平均速度】454.71 tripcodes/s
【CPUの平均速度】31.52 tripcodes/s
【GPU使用率】98〜99%
【その他】7完1タゲ。

>>422
う〜ん、それは全く謎ですね。>>389のリンクは切れていてダウンロード
できませんでした。

あしたあたりに7970が届くはずなので、それでいろいろ実験して
デフォルトのパラメータを調整してから次の開発版をうｐします。

若干スレチですが・・・
12-10をアンインストールしてから再インストールしても駄目でした。
12-8、12-6、12-4も試しましたが駄目でした。

AMD APP SDKで改善することはありえますか？

ちなみにBOINCのGPGPU(WCGのHCC)や待て屋GPU版はこの状態でも動作します。

>>427
GUI版は起動できますか? コマンドラインから起動できないバグかもしれません。

>>429
GUI版では使用出来るGPUが見つかりませんでしたと出ます。

それは謎ですねえ。AMD APP SDKで改善するかもしれませんけど…

>>425
>>405 の時点で落としたものと思って消したわ。ｗ
復活させたが、あんなもんをずっと置いとく気は無いので落としたら言ってくれ。

>>430
今コレを書いてるPCでも同じことになったんだが、CCC 12-6 入れて SDK v2.7 入れたら直ったぜ。
どっかの WindowsUpdate でなんかやられたのかもしれん。
12-6 なのは、4000 番台だからだ。このバージョンがいいとかいうわけではない。

>>432
あ、そうですか。今落としたのでもう消していただいて大丈夫です。
それにしても、うちのi7-3770Kで95M TPS出てますけど、これは一体どういう
仕組みなんでしょうか…

>>422
書き忘れてたけど、多分パラメータを替えれば4000番台でも動くと思いますよ。
CUI版ではどんなエラーが出ていますか?

>>433
実際に速度分ヒットしてるか確認したほうがいいな。ｗ
速度表示のバグとかかもしれんぞ。うひ。
なにせ途中で飽きてほうりだしたものだしな。

>>434
いや、処理そのものを書き換えないと動かないな。
理由はこれだ。

The 4XXX series does not have the requisite hardware to support byte addressable store, so it will never be supported.

つーかさ、これも多分そのぐらいの速度なんじゃないかな。
http://trip2ch.net/wiki/index.php?SHArp%20Tripper

MERIKEN's Tripcode Finder はまだまだチューニングの余地があるというか、
まだやりはじめたばっかりなんだろ。
そのうち hip2 なんざ超えるんじゃね？

>>435
ヒット率をチェックするルーチンを最初から組み込んでおくといろいろ安心ですよ。
Tripcode Finderの開発ではそれで随分助かりました。
4XXXシリーズの制限はちょっと厳しすぎですねえ。残念…

>>436
MERIKEN's Tripcode Finderは他のプログラムに比べてキーの探索空間が広いので
単純に比較できないんですけど、ちょっと気になったのでCPU検索の速度を
調べてみました。CPUはCore i7-3770K 4300MHz、ターゲットは前方一致の
"TEST/"のみで、検索時間は5分です。

SHArp Tripper 1.1
報告された速度: 74.6M TPS
ヒットしたトリップの数: 19個

hip264.exe
報告された速度: 102.6M TPS
ヒットしたトリップの数: 0

MERIKEN's Tripcode Finder 0.07 Alpha 2
報告された速度: 42.8M TPS
ヒットしたトリップの数: 11

hip2は5完のターゲットだとちゃんと動いていないようです。

>>438
hip2 は6完以上しか探せない仕様だ。ｗ

5完しかタゲにないと
0 ターゲット読み込みました。
ってなるはず。はず。はずなんだよなぁ・・・・・。

ちなみに hip2 の検索空間というかキーの組み合わせ数は、
81189040166334863750412839195508736 個
だ。
MERIKEN's Tripcode Finder はこれの何倍だ？
つか、トリップの総数を考えるとこの辺にすると思うんだが。

>>439
oi.
おい。
オイィィィ。

この辺、じゃねぇな。ｗ
これでもかなり多すぎるな。

なんでこんなに広げたんだよ。＞昔の俺

64^12=4722366482869645213696
だもんなぁ。

>>431-432
AMD APP SDKにはGPU向けのドライバは入ってなさそうでした。
アンインストールしてから12-6、SDKの順に入れても駄目でした。


他のOpenCL対応ソフトなんかの挙動を確認してみたんですが、
PhotoShopCS6ではRadeonを認識していて、「OpenCLを使用」のチェックも入れられました。
OpenCLを使用するというぼかしフィルターも使えています。

連レスすみません
大きい画像でぼかしフィルターを試すとぼかし処理の開始と同時にGPU Loadが増えるので、まず間違いなくPSでは動いていると思います。

>>439
なるほど、そういうことだったんですね。Tripcode FinderはShift-JISのキーを
全てカバーするようになっているのでその数字より大分大きいはずです。
トリップの変換は全単射ではないのでキーの組み合わせの数と
トリップの総数(64^12)は必ずしも一致しません。

hip2は全数字のターゲットは自動的に拾うようになっているようなので
そっちのほうでも比較してみました。検索時間は10分です。

hip264.exe
報告された速度: 102.6M TPS
ヒットしたトリップの数: 13

MERIKEN's Tripcode Finder 0.07 Alpha 2
報告された速度: 37.6M TPS
ヒットしたトリップの数: 7

hip2のほうが大分速度が出ているようですが、実際の速度が報告通りかどうかは
微妙なところです。

>>443
またそんなてきとーなことを。ｗｗｗ
hip2 の検索空間のほうが「かなり」広いぞ。
ちょっとは考えようよ。

つーかさ、全単射じゃないかもしれないからこうしてるんだし。

4722366482869645213696 = 64^12
81189040166334863750412839195508736 = hip2 の検索空間

俺のことどんだけバカだと思ってるんだよ。ｗｗｗ

>>444
自分でつくっといてなんだが、
>実際の速度が報告通りかどうかは微妙なところ
には同意だ。てへ。

まあ、10分じゃ運の要素が強いが・・・・・。

Ivy 買ったらまたやろうかとか考えてたけど、もうあの頃の情熱はない。うわぁ。

そもそも鳥屋がぐてやを投げるから悪いんだ。
ぐてやは試作段階でhip2よりも速かったんだぜ？
ﾁｸｼｮｳ
あの野郎やるやる詐欺でほったらかしだしな！！！！

>>445
見た感じでは1バイト文字のキーしか探索していないようでしたけど、違うんでしょうか。
Shift-JISのキーを網羅的に探索するTripcode Finderのほうがキーの探索空間が広いのは
自明だと思うのですが…

キー探索空間は
64 ^ 12
= 2 ^ 72
= 4722366482869645213696

だけで十分ではないのですか？
↓の資料を読む限りでは。

> 与えられたハッシュ値に対応する入力を求めるために必要な計算量は、
> ハッシュ値が n ビットであるとき、ハッシュ関数の計算を 2^n 回行うための計算量を超えない。
http://www.jnsa.org/seminar/2008/0703/data/09_panel03.pdf#page=7

>>447
なんだかなぁ。
なんで確認しないの？
なんでTripcode Finderのキー空間計算してみないの？

私、怒っちゃったから答えは教えてあげないよ〜だ。

>>448
簡単に言うと、
違うキーで同じトリップになることがあるかもしれない
ってことだよ。だから、総トリップ数よりも多くしておくべきなんだよね。

>>448
実用的な観点からはトリップのキーはわかりにくければわかりにくいほど良いので
自分としては妥協したくないところです。

>>446
> あの野郎やるやる詐欺でほったらかしだしな！！！！
ご愁傷様です… しかし実にもったいないですね。海外にいるとのことでしたけど
元気にされているんでしょうか。

Tripcode FinderのCPU検索はSHA-1のルーチン以外はサボりまくりなので
改善の余地はまだ大分あるんでしょうねえ。次に最適化に挑戦するのは
もうちょっと勉強してからにします。

>>449
ハッシュ値の衝突はわかります。
それも踏まえた上で
> ハッシュ値が n ビットであるとき、ハッシュ関数の計算を 2^n 回行うための計算量を超えない。
ということではないのですか？

>>449
私には

(1) 1バイト文字のみのキーの総数

と

(2) 1バイト文字とShift-JIS文字を含んだキーの総数

を比較したら後者のほうが大きいのは当然に見えるのですが違うんでしょうかねえ。
計算は面倒くさいのでしませんｗ

私がトリップ検索に興味を持ったのは、私のトリップを騙る荒らしが現れたのが
そもそもの原因なので、Tripcode Finderを作るときには実用性が全てにおいて
優先しています。いままで考えてもみなかったですけど、純粋な知的好奇心以外の
明白な動機があるというのが自分の作ったプログラムにも反映されているのかも
しれません。

あれ？
CPU側にhip2、GPU側にMERIKEN使えば最強なんじゃね？

>>455
hip2はホントにアルファレベルのでき。
タゲの制限も実用的なものじゃないし。
速度の検証しようとしたところで投げたから、マジで表示速度は怪しい。
もちろん、わざと盛るなんてことはやってないけど。ｗ


『ホンキで最速を目指すんなら、キーを○×△□にしろよ。』
と鳥屋に言われた。一部伏せ字。ｗ
最初意味がわからなかったけど、よく考えたらわかった。

ヤツは私の理解の外にいる。
待て屋のソース見るとよくわかる。
もったいないよなぁ・・・・。

部外者の俺が答え言っちゃっていいのかは知らんが、
MERIKEN氏は12桁トリップのキーが12バイト以上を取りうるということを失念しているのだと思う

10桁トリップと違って12桁トリップはキーを長くするだけで簡単にキー探索空間が広がる
hip2が手元にないので確認できんが、>>439の数=152^16からhip2はキー16バイトで探索しているのだと推測される
このことを考えれば現状のキー探索空間は圧倒的にhip2の方が大きいというのはすぐに分かる

ここからは俺の偏見的見解だが、両者の違いは
hip2はわざわざShift_JIS空間を探索するより、単にキーを長くして簡潔・高速に探索することが目的
一方MERIKEN氏の方は>>450>>454からわかるように、「わかりにくいキー」を探索することを優先している
ということなんじゃないかと思う

>>457
おっしゃる通り完全に失念していました。
ののたんさん、失礼しましたm(__)m

ののたんもわかりやすく伝えてあげればいいのに

>>459
まあこの件は私の勘違いが原因なので…
いろんなアプローチの仕方があることがわかってちょっと新鮮でしたｗ

>>457
あの桁の数字を152^16に分解できるとはやるね。ｗ
まあそゆ計算するコマンドもあるけど。

漢字を使わないのは単にそこまで使用文字を増やす必要がないから。
漢字使っても速度ってそんなに変わらないよ。
キーのバリエーションはうにでも魔改造でもさんざんやってるから、ノウハウはいっぱい。ｗ

ちなにみ16バイトってのはなんとなくとかじゃなくて、ちゃんと理詰めして出てきたものだよ。

技術力はあっても性格がアレな人は見てて不快だからNGに突っ込んだ

技術力があれば性格なんてどうでもいいんだよ

>>462
技術者同士のやり取りならこれが普通だろ
それにちゃんと答えにたどり着けるヒントは与えてくれてるし、
素直に自分の調べが甘かったなで終わりだよ

Intel/AMD/NVIDIAがOpenCL 1.1以上に対応している今、
cl_khr_byte_addressable_storeなんざもはや過去の遺物か…

>>465
正直こんなものがあった事自体が驚きです。

エラーコード14って何？

assertでエラーが出てますね。
CUI版ではどのように表示されますか?

http://www.dotup.org/uploda/www.dotup.org3596162.png
こんなん。1GPUだといけた

>>469
今ちょうどそこを直していたところですw
追って詳しく報告します。

がんばれー

>>469
Alpha 2でスレッド周りにバグが紛れ込んでました。修正が終わったので
次の開発版では直っているはずです。

GUI版の設定ファイルって
%LOCALAPPDATA%\MERIKENsTripcodeFinderGUIフォルダ以下にある
user.configだけが使われてて
それ以外のレジストリとかは使われてないということでいいんでしょうか？

なるほど、1GPUでは問題なく検索出来ますね
ただ、問題は1GPUでも900M程出てしまうこと
複数GPUを有効に働かせてませんね

それと、GPUを複数稼働させるとCPUの検索速度が落ちる
カードをドライブするのに相当リソースを持って行かれていると言うことですな
RdeonのアークテクちゃではCPU負荷が大きいのでこれは仕方がない

http://www.rupan.net/uploader/info/1352305227

貼り方間違えた

http://www.rupan.net/uploader/download/1352305227.png

とうとう7970が届きました。ぐへへへへ…
午後のミーティングが終わったら早速インストールしようっと。

>>473
その理解でいいはずです。

>>474
これは7970ですか? もうちょっと速度が出そうな感じですね。
CPU検索スレッドはGPUの数だけわざと減らすようにしています。
「詳細設定」の「CPU検索スレッドの数」をいじると面白いかもしれません。

>>476
>ぐへへへへ…
あかん……あかんでぇ

7970をさして起動したところです。わくわく…

手元のAlpha 3でいきなりGPUだけで1270M TPSでてます。なんだこの化物は…
しかしGPU使用率が結構バラつきます。75〜97%を行ったり来たりといった
ところです。

【GPU】H797F3G2M
【CPU】Xeon E5504
【OS】Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 2
【トリップの種類】12桁
【1CUあたりのワークグループの数】2560
【1WGあたりのワークアイテムの数】64
【その他のオプション】GPUのみ
【Display Driver】9.01.8-121022a-147510E-ATI
【10分間の平均速度】1124Mtripcodes/s
【GPUの平均速度】tripcodes/s
【CPUの平均速度】tripcodes/s
【GPU使用率】65〜80
【その他】GPUは1GHz　CPUは3GHz

>>482
どうも7970の場合はワークグループの数を1280にするといいみたいですよ。

MERIKEN様、お疲れ様です
その節は御世話になりました

これからも頑張って下さい
スレ違い申し訳ありません<(_ _)>

失礼しますm(_ _)m

>>483
使用率若干上がりました

X58マザーだしこのくらいいけばいいかな

>>484
こちらとしても使っていただけると嬉しいです。
またいつでもどうぞ。

ワークグループの数を変化させて10分間のGPUの速度の平均をとってみました。
とりあえず5770で有効だった320の倍数にしておきました。
960で使用率が綺麗に97%で安定しました。色々ためしてみるもんですねえ。
Alpha 3では1GPUあたりの検索スレッドの数を指定できるようになっていますが、
デフォルトの2のままにしてあります。

320 -> 910M TPS
640 -> 1250M TPS
960 -> *1370M TPS
1280 -> 1357M TPS
1600 -> 1240M TPS
1920 -> 1311M TPS
2240 -> 1331M TPS
2560 -> 1270M TPS

OCして速度を測定してみました。やっぱり化物ですね、これは。

【GPU】Gigabyte GV-R7970C-3GD Radeon HD 7970 (OC: 1130MHz)
【CPU】Intel Core i7-3770K (OC: 4300MHz)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 3
【トリップの種類】12桁
【1CUあたりのワークグループの数】960
【1WGあたりのワークアイテムの数】64
【その他のオプション】
【Display Driver】Catalyst 12.9 Beta
【10分間の平均速度】1517.35 tripcodes/s
【GPUの平均速度】1481.07 tripcodes/s
【CPUの平均速度】36.28 tripcodes/s
【GPU使用率】94%
【GPUの温度】80℃
【その他】7完1タゲ。

>>478
7970です
Alfa2では2GPUでの検索が出来ないので1GPUの結果です
1GPUでも速度駄変わらないという

新しい開発版です。

MERIKEN's Tripcode Finder 0.07 Alpha 3
http://www.meriken2ch.com/programming/merikens-tripcode-finder

Alpha 2からの変更点は以下になります。

・デフォルトのワークグループの数の調整。
・複数のOpenCL対応デバイスで検索できないバクの修正。
・デフォルトの検索スレッドの数の調整。
・検索スレッドの数を設定できるように修正。
・コマンドラインで起動できないバクの修正。

アルファ3パネェな　1300Mは軽く超えるわ

メインマシンの8 64bitはGPUは全部使ってるみたいだけどこんな状態だった
解凍したまんまで実行
http://www.dotup.org/uploda/www.dotup.org3597875.png

こちらは今までと変わらない速度です。
ただ、デフォの状態で起動しようとしたら「HD4000には対応してません」とかいうエラーが出て終了
GTX680Mを指定してあげないとダメだった
Optimusがあるからでしょうけども

>>493
もうゲフォの報告は要らないです

>>492
ありゃりゃりゃ… AfterburnerのGPU使用率は0%になってるけど、
これは一体どういうことだろう。CUI版ではどのように表示されていますか?

不具合報告したのに何で煽られなきゃいかんのよ

>>493
報告たすかります。そのメッセージはちょっと紛らわしいですねえ。
ちょっと無理してでも動くようにしたほうがいいのかしらん。

>>496
荒らしなので放っておきましょう。

>>492
ちょっと考えてみたけどこれは本当におかしいですね。
詳細設定の検索スレッドの数を1にしたら直るかもしれません。
Radeonが複数あっても大丈夫なはずだけどなあ…
あとでこちらでも試してみます。

>>497
Intelグラフィックスは無視するようにはできないですかねえ
さすがにデフォ状態でエラー出るのは一般ユーザは使いにくいかも

http://www.dotup.org/uploda/www.dotup.org3597940.png
64bitの方です
CPUロードは33%前後の状態です

Windows8 64bit Radeon HD 7660Dで初期設定のままで実行
Alpha 2ではエラーが出て実行出来なかったGPUとCPUを使用が利用可能に
http://www.dotup.org/uploda/www.dotup.org3597945.jpg

>>501
これは助かります。OpenCL検索スレッドはちゃんと走ってるみたいですね。
6970ではちゃんと動作するという報告が>>378であったので、
なんだかドライバのバグの臭いがしてきたぞ…
GUI版の「使用するGPU」で6990を1つだけえらんだ場合は
どれぐらい速度が出ますか?

>>500
無理に動かせない場合はHD 4000は無視したほうがいいですね。
アホの子からｱｯｶﾘｰﾝに格下げとは、なんて不憫な子…

>>503
1つだと70％くらいの使用率で700M前後ですね

>>505
やっぱりそっちは普通ですね。「使用するGPU」を「すべて」にして
「検索スレッドの数」を1にした場合はどうですか?

>>506
変わらず合計で200M程度　CPUが80Mで全てで300M前後です

キャプでも分かりますがcatalyst12.11βです
あとは12.10もリリースされていますがどうなんでしょう

>>507-508
6990を一枚だけ差した状態できちんとスピードが出るなら、
間違いなくドライバのバグでしょう。>>487のように
ワークグループの数をいろいろ変えてみたら治るかもしれませんけど…
うちでは未だに12.9 Betaです。12.10は試してみないとわかりませんねえ。

>>502
これはAPUですか。結構速度が出ていますねえ。うちのHD 4000ちゃんとは
エラい違いです(;_;)

>>502
APUで200Mt/s超えですか、凄い時代になりましたね・・・

>>502
A10カッケーな

>>477
ありがとうございます
もしよければREADME.txtにuser.configのことも書いておいてもらえるとうれしいです

>502さんに合わせてAlpha 3でA10-5700でやってみた。
Windows8 64bit Radeon HD 7660Dで初期設定のままで実行
#Alpha 2ではCPU+GPUで同じくエラー

順に、CPU、GPU、CPU+GPU(ファイルは400KBあるので注意)
ttp://www.dotup.org/uploda/www.dotup.org3598679.png
ttp://www.dotup.org/uploda/www.dotup.org3598686.png
ttp://www.dotup.org/uploda/www.dotup.org3598739.png

5800Kを下回る筈の速度がなぜか上回った。
ドライバとかメモリ(DDR3-1888)に差があるのかどうか。
#メモリはGPUでも影響しないのでしたっけ？

なお、Alpha 1よりCPU+GPUのGPU部分がざっくり４割速度向上しました。

テンプレに合わせて報告いたします。

【GPU】AMD Radeon HD 7660D (A10-5700内蔵)
【CPU】AMD A10-5700
【OS】Microsoft Windows 8 Pro 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 3
【トリップの種類】12桁
【1CUあたりのワークグループの数】960
【1WGあたりのワークアイテムの数】64
【その他のオプション】
【Display Driver】Catalyst 12.11 beta4
【10分間の平均速度】254.87M tripcodes/s
【GPUの平均速度】244.63M tripcodes/s
【CPUの平均速度】10.24M tripcodes/s
【GPU使用率】97〜98%
【その他】CPU+GPU

消費電力は110〜113W程度。GPUのみだと70W未満・・・GPUの効率スゴイっす。

関係ありませんが、「7完1タゲ」とかってどういう意味なんでせう。

任意の七文字　タゲを1つだけ記した状態

>>516
ありがとうございます。もやもやが晴れました。

>>515
>7完1タゲ
七文字のワード(YUKI.N/とか)を正規表現無しで1つだけ指定ってことじゃね

七文字完全一致1ターゲット

>>514
結構速度出てますねえ。次にマザボを変える機会があったらAMDのAPUに
しようかな…

アホの子HD 4000ちゃんがあまりにも不憫なのでカーネルをいじって
Intelのドライバでも動くようにしておきました。性能はあいかわらずですが…

【GPU】HD7970 CFX 2GPUｓ ＠1200MHｚ
【CPU】FX-8350 ＠5GHｚ
【OS】Windows7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 3
【トリップの種類】12桁
【1CUあたりのワークグループの数】1280
【1WGあたりのワークアイテムの数】24
【その他のオプション】-c -g -t 7 -y 1280 -z 24
【Display Driver】Catalyst 12.10
【10分間の平均速度】1705.24tripcodes/s
【GPUの平均速度】1654.95tripcodes/s
【CPUの平均速度】48.30tripcodes/s
【GPU使用率】92%
【その他】7完1タゲ

どうにか本気を出させることが出来ました
WG数が効いたようです。値を小さくすれば使用率は上がりますが数値が伴わないのでこの辺りがいいところ
7970の2枚挿しの割に低いですがCPUがネックなのでしょうｗ

画像貼り忘れ

http://www.rupan.net/uploader/download/1352402390.png

>>522
う〜ん、その構成だと性能的には3000M TPSでてもおかしくないはずなんですけどねえ。
>>492さんの報告( >>501 ) でもそうだったけど、どうもAMDのGPUが
複数あるとちゃんと速度が出ないみたいです。READMEには書かなかったけど、
"-a"というオプションで検索スレッドの数を指定できるので、それを増やして
みるのも手かもしれません。デフォルトは2です。
こういう場合CUDAだと綺麗にスケールしてくれるのですが
AMD APPはなかなかクセがありそうな感じです。

>>521
アホの子かわいいよアホの子

元よりAMDほどガチGPU目指してないからな気もするが＞HD 4000

>>492
>>522
AMDのGPUが複数あると速度が極端に落ちる問題ですが、5770と7970の組み合わせで
こちらでも再現できました。で、調べてみたところ、速度をきちんと出すためには
GPU毎にTripcode Finderを立ち上げる必要があることが分かりました＼(^o^)／

AMDのドライバを書いた人が何を考えているのかさっぱりわからないほどの
糞仕様ですが、このままではあまりにダサくて見るに耐えないので、
CUI版をハックしてなんとかすることにします。あんまり綺麗とはいえないですが、
CUI版からOpenCL対応デバイスの数だけ子プロセスを立ち上げればとりあえず
大丈夫でしょう。

>>525
ほんとに必要最低限ですよね。もうちょっと頑張って欲しかったなあ。

CUI版でそれぞれのAMDのGPUのために1つづつ子プロセスを
起動するところまではできました。あとは次のページを参考にして
子プロセスの出力を親プロセスにリダイレクトしてやるだけです。

How to spawn console processes with redirected standard handles
http://support.microsoft.com/kb/190351

非常にめんどくさいけど、あともうちょっとです。

うんざりするような書き換え作業が終わって、ちゃんと子プロセスの
標準出力が親プロセスで受け取れるようになりました。あとはこれを
親プロセスで処理してやるだけです。

団子もびっくりだな。

本職さんですねメリケンさん。

>>530
それが本業はプログラミングと全く関係ないんです。

修正もほぼおわり、生成されたトリップと速度などの情報が
CUI版できちんと表示されるようになりました。
定格の5770と7970の組み合わせで1700M TPS以上出ているので
性能的には申し分ありません。あと数箇所修正する箇所が
残ってますけど、まず問題ないでしょう。やれやれです。

……ところで、
>5文字未満、もしくは12文字以上のターゲットも無視されます
と書いてあるのは、
「ターゲットは5〜11文字まででお願いします」
ということですか(12完は含みませんか)？

>>533
ありゃりゃ、説明が間違ってますね。12完でも大丈夫です。

>>534
ですよね。でもありがとうございます

新しい開発版です。

MERIKEN's Tripcode Finder 0.07 Alpha 4
http://www.meriken2ch.com/programming/merikens-tripcode-finder

Alpha 3からの変更点は以下になります。

・複数のAMDのGPUで検索すると速度が低下する不具合の修正。
・Intel Processor Graphicsシリーズへの対応。

今度こそ6990や7970 CFXで性能通りの速度が出るはずです。
アホの子HD 4000ちゃんには期待しないでくださいｗ

しかしこういうの見ちゃうと、AMDのAPUも十分Intelと戦えるんだよなぁ

GPU部分を活用するのが難しいからなかなか陽の目見ないけど、
メモリ統合とかHSAとかすすんでGPUの演算力をもっと容易に使えるようになったら面白いな

>>536
DL→アホの子だけ指定してGPU検索(ゲス顔)→

ト　リ　ッ　プ　が　生　成　さ　れ　な　い　？

>>538
たしかになかなか出てこないですねえ。
この間はちゃんと検索できてたのにおかしいな。

あ、出てきた。まあアホの子はとんでもなく遅いので気長に待ってくださいｗ

低速のテスト用に4文字検索もOKにすればいいのに

>>536
CUI版でオプションスイッチが効かないような
設定してもデフォルトでの検索になります

>>541
ハッシュ値の計算の関係で5文字以上にしないと検索が遅くなるんです。
正規表現で"^TEST."のように指定してやれば4文字で検索できなくも無いです。

>>542
報告ありがとうございます。たしかにOpenCL対応のGPUが複数あると
オプションが効かないですね。直しておきます。

5870でAlpha 4を試しましたので、ちょい簡単に報告します
>>487を参考に数値を変えましたところ、-y 5120 -z 64 の設定で平均900M強出ました
どうやら先日の報告はGPU使用率が低かったようです

>>542で報告していただいたバグを修正した開発版をうｐしました。
複数のGPUを使わない方はダウンロードする必要はありません。

MERIKEN's Tripcode Finder 0.07 Alpha 5
http://www.meriken2ch.com/programming/merikens-tripcode-finder

>>545
CUの数が5770の倍なのでちょうどそれぐらいの速度ですよね。
5870のデフォルトの値だけ変えられないか検討してみます。

>>545
CL_DEVICE_NAMEとCL_DEVICE_MAX_COMPUTE_UNITの組み合わせで
型番が特定できることがわかったので、5870のデフォルトの値だけを変えて
おきました。次の開発版で反映されます。

【GPU】Radeon HD 6990
【CPU】i7-2600
【OS】Windows 7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 4
【トリップの種類】12桁
【1CUあたりのワークグループの数】2560
【1WGあたりのワークアイテムの数】64
【その他のオプション】なし
【Display Driver】CCC 12.10
【5分間の平均速度】1955.59Mtripcodes/s
【GPUの平均速度】1955.59Mtripcodes/s
【CPUの平均速度】N/A
【GPU使用率】97%前後
【その他】
GPUのみで検索
電力を20%盛って950MHzで計測

Performing a forward-matching search for 1 pattern (1 chunk)
with 7 characters on GPU(s):
OpenCL0: 1034.7M TPS, 2560 work-groups/CU, 64 work-items/WG
OpenCL1: 920.9M TPS, 2560 work-groups/CU, 64 work-items/WG

0.577T tripcodes were generated in 0d 0h 5m 00s at:
1991.28M tripcodes/s (current)
1955.59M tripcodes/s (average)
On average, it takes 25.6 minutes to find one match at this speed.

>>549
あ、ありがとうございます! ちゃんと性能通りの速度が出ているみたいですね。
よかったよかった。

> 【5分間の平均速度】1955.59Mtripcodes/s

しかしこれは1枚のグラボの数字には見えないですねｗ 素晴らしいです。

>>549
>【5分間の平均速度】1955.59Mtripcodes/s
2枚にすればMERIKEN超えだよ！やったね！

こんばんわ　alpha5　解凍したまんまです
http://www.dotup.org/uploda/www.dotup.org3605227.png
OSとそのドライバの影響でしょうか？うちの環境で40〜50％です

>>552
6990 なら、電力を盛らないとホンキださないぜ。
6990 使いなら常識だぜ。ｗ

【重要：盛って壊れても俺は責任持たないからな。】

>>553
盛っても変わらなかったからデフォでやったｗ

壊れてナンボがデフォ。

>>552
これは実にもったいない… ぶっちゃけAMDのOpenCLの実装がちゃんと
複数のGPUを生かしきれてないのが問題なんですけどねえ。
同じ設定でTripcode Finderを2つ同時に動かしたらどうなるか、
試してみていただけませんか?

GPUのみの並列実行しても使用率に変化はありません
CPU＆GPU　GPUの並列実行も同じです

>>557
あとはワークグループの数を5120とか10240にしてみるぐらいしか
思いつかないですねえ。スレッドの数を変えてみるといいのかもしれないんですけど、
このオプション、Alpha 5ではちゃんと動いてませんでした… 次の開発版で
直しておきます。

>>552のように、ラデ使いのSSに写ってるカッコイイ画面>>432
ってグラボ標準のユーティリティなん？
高いGPUなんて買ったことないからよく分かんない……
使用率見るのにGPU-Zより分かりやすいのはいいけど

ところでこの壁紙って誰のですか？

なんで>>432って付いてるの↑……
無視してください

http://www.dotup.org/uploda/www.dotup.org3605668.png
いろいろやった結果　CU=2560　WG=32　のみ固定し行けました
6990はクーラントブッカケしたものなんでたまにマザーが見失ったりするんでそのせいかもしれません

ツールはMSIのサイトから落とせますよ
壁紙は台湾MSから　日本MSのちっぱいには興味ありません

>>561
ウチMSIには縁がないもので……
↓壁紙はいただきました。冷静に考えるとM$キャラでちっぱいは少ないような……
http://www.microsoft.com/taiwan/silverlight/collection.htm

>>562
無料ツールだろｗ
MSI行って落とせよ

^0123456789$のように$で終わらせた検索条件を含む
１０桁トリップと１２桁トリップの複合検索は
トリップの種類１２桁
でもできますか？

>>562
どこのメーカーのものでも使えますよ

http://event.msi.com/vga/afterburner/download.htm

>>564
おっしゃっていることがさっぱりわからないんですが…
Tripcode Finderで10桁トリップと12桁トリップを同時に
検索することはできません。

>>565
thx！インストールしてみる→

---------------------------
MSI Afterburner
---------------------------
一部の MSI アフターバーナーのコンポーネントが期限切れ、紛失、または壊れています。
---------------------------
OK
---------------------------
起動しないよorz
ノートじゃ駄目か……

>>561
う〜ん、まだまだ力を出し切れていない感じですねえ。
自分でも試してみたいけど、さすがにこれ以上はグラボは買えません。無念なり…

【GPU】SAPPHIRE VAPOR-X HD5770 1G (OC: GPU 960MHz MEM 1265MHz)
【CPU】Intel Core i7-3770(無印)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 5
【トリップの種類】12桁
【1CUあたりのワークグループの数】3200
【1WGあたりのワークアイテムの数】64
【その他のオプション】
【Display Driver】Catalyst 12.10
【10分間の平均速度】498.00M tripcodes/s
【GPUの平均速度】463.44M tripcodes/s
【CPUの平均速度】34.56M tripcodes/s
【GPU使用率】99%
【GPUの温度】64℃ （室温20℃）
【その他】テスト時間10分33秒、7完1タゲ

Intel HD4000 にセカンドディスプレイを接続して使用していますが、Intel
社の OpenCL ドライバはインストールしていないので HD5770 だけでのテスト
となりました。

>>561
あの後ちょっと調べてみたんですけど、ひょっとしてCrossFireXが有効になってませんか?
Catalyst Control CenterでCFXを切れば、デフォルトの設定でうまくいくかもしれません。

>>570
切ってみます

>>569
詳しい報告、ありがとうございます。ワークグループの数は2560より3200のほうが
いいのかな。うちの5770でもうちょっと詳しく調べてみます。

切れてた…　2560/64は2560/32より遅かった模様

>>573
う〜ん、何で6990 CFXだけなかなか速度が出ないんでしょうねえ。
ほかのOpenCLアプリケーションでは6990 CFXでもちゃんと性能が出るという報告が
あったので、なにかしら方法はあると思うんですが… もうちょっと調べてみます。

Bitcoin Mining GPU Performance Comparison
http://www.hardocp.com/article/2011/07/13/bitcoin_mining_gpu_performance_comparison/3

>>569
>Intel社の OpenCL ドライバ
そんなのがあったのか……と思ってググってみたが、SDKのことか？
→インストールしたら、アホの子でOpenCL検索使えた！
(ただし4M/sぐらいだけど)
サンクス！

あ、後、タスクマネージャ見てたら隠しパラメータがあることに気づいたｗ
-a 2←1つのAMDのGPUに対する検索スレッドの数？
-m MutexForMERIKENsTripcodeFinder-6496←Intel HD Graphics 4000でOpenCLを使うおまじない？

>>576
> -a 2←1つのAMDのGPUに対する検索スレッドの数？

これはあってます。2番目のはGUI版とCUI版が通信するときに使うおまじないです。

これまで使っていた検索君1号のFermi軍団に加えて、開発用PCの7970でも同時に
検索をしているのですが、ここ数日で3回ブレーカーが落ちましたｗ
GTX 590の電圧を絞ることでなんとか対処しましたが、
消費電力のほうもそろそろ限界です。

単相200V契約しよう

前スレだったと思いますが、ドライバを触ったらこのソフトからGPUが認識されなくなったと書き込んだものです。
相変わらず認識されないままですが、今日system32に入っているclinfo.exeというプログラムでOpenCLの情報を取得できると知ったので、
取得できたテキストをアップロードしておきます。
http://cyclotron.moe.hm/up/small/src/cyclotron_s4856.zip

念のため正常に使用できるPCのぶんも入れておきます。

USAは、110ボルトですね。

>>580
ひょっとしてこのスレの>>395さんですか?
たしかに両方ともRadeonが見えていますね。
OSが64bit版ならCUI64ならうまく動くかもしれません。

>>579
したいのはやまやまなんですけど、今のアパートだと無理なんです…

>>581
120Vです。15Aなので1800Wまで大丈夫なんですが、グラボ4枚で1100Wぐらい
いってます。やばいです。

>>582
あ、このスレでしたか。
Alpha5をダウンロードしてCUI64を起動してみましたが
MERIKENsTripcodeFinderCUI: OPENCL FUNCTION FALL FAILED: CL_DEVICE_NOT_FOUND (file 'Source Files\MTF_CUI_Main.cpp', line 732)
と表示されてそこから進みません。

c++は門外漢でソースちらっと眺めただけですけど、プラットフォームが2個あって、最初の片方がCPUのみってところでなんかコケたりしてません？

>>584
CPUは無視するようにしているので問題はありません。
32bit版のMERIKENsTripcodeFinderCUI.exeではどうですか?

>>585
32bitでも同じエラーです。

う〜ん、やっぱりCL_DEVICE_NOT_FOUNDが返されているのかなあ。
うちのIntelのドライバではエラーは出なかったんですが…
これから修正して新しい開発版をうｐするので、そちらを試してみてください。

>>580で報告していただいた、環境によっては起動できないバグを修正した
開発版をうｐしました。というか、これで直っているといいんですけど…

MERIKEN's Tripcode Finder 0.07 Alpha 6
http://www.meriken2ch.com/programming/merikens-tripcode-finder

>>588
ありがとうございます。
起動できるようになりました。

>>589
それはよかった! こちらこそバグ報告をありがとうございました。

もうそろそろ安定してきたと思って10桁トリップ検索の移植の作業を
始めてたんですけど、まだ結構不具合が残っていますねえ。

>>588
全グラフィックチップ(680M+iHD4000)指定だと
検索開始後エラーメッセージなしでソフトごと落ちます
HD4000はバッサリ切った方がいいかと思われます

>>592
ありゃりゃ… こりゃいかんですねえ。テスト用には便利だったんですけど
しょうがないですね。次の開発版からは無視するようにします。

というわけで面倒くさいのでIntelのプラットフォームは最初から無視することに
しちゃいました。OpenCLはオープンスタンダードな分だけそれに伴う
問題も多いですね。

気を取り直して10桁トリップ検索の移植作業を続けます。
CPU側のコードは10桁の場合とほとんど同じなのですぐに終わりました。
問題はOpenCLのコードですが、バグが紛れ込むと見つけるのが
非常に困難になるので、慎重に作業を進めてます。

カーネルの入り口の部分の書き換えは終了しました。
あとはBitslice DESの本体だけですが、CUDAのコードをコピペするだけなので
問題はないでしょう。うまく動いてくれるといいんだけど、どうでしょうね〜

geforceでopenCL版って動くの？
動いてもcudaよりは遅い？

>>597
いまはNVIDIAのカードでは強制的にCUDAを使うようにしています。
OpenCLでも動くことは動くと思いますけど、基本的に全く同じコードなので
速度は変わらないでしょう。

OpenCLの10桁検索のコードは1発で動いたんですけど、Bitslice DESで使う変数を
何も考えずに全部__privateメモリ空間に突っ込んだら、案の定というか
まったく速度が出ていませんｗ まあでもコードの書き換え自体は問題なかったよう
なので、とりあえず一安心です。これから__globalと__localを試してみます。

khronosの姿勢として標準のカーネルコンパイラを用意しないのはわかるんだけど
やっぱりglslの轍をちょっとは生かしてほしかったってのが個人的な思い
meriken氏乙

>>594
当方では一応4M/sぐらいで動くので、
IntelHD4000を使うか否かをチェックボックスとかで決めればいいと思いまーす

>>598
そうなんだ
ありがとう

OpenCLで盛り上がっているところにCPUのみの結果を報告。

【GPU】Quadro FX 3800
【CPU】Xeon [email protected] x2CPU
【OS】MS Windows 7 Pro 64bit
【バージョン】0.07 Alpha 3 CUI64
【トリップの種類】12桁
【Display Driver】307.32

【その他】HT on
【その他のオプション】-c -t 24
【60時間の平均速度】80.51M TPS

【その他】HT off
【その他のオプション】-c -t 12
【2時間の平均速度】79.04M TPS

CPUだけで実行してもHTは殆ど効きません。NehalemとSandy Bridgeでは全然違うのかな?
ちなみにHT on の状態で、"-c -t 12"と指定すると、2CPU12コアに割り当てられずに、1CPU6コア12スレッドに割り当てられてスピードが出ません。

Alpha 6に上げて再度実行してみましたが、NVIDIAコントロールパネルの"3D設定"→"3D設定の管理"で"CUDA-GPU"を"なし"に設定すると、CUI64で"-c"オプションをつけても下記エラーが出て落ちます。
MERIKENsTripcodeFinderCUI: OPENCL FUNCTION FALL FAILED: Unknown (file 'Source Files\MTF_CUI_Main.cpp', line 715)

NVIDIA，第2世代Kepler「GK110」搭載の「Tesla K20」を正式発表。CUDA Core数は最大2688基に
http://www.4gamer.net/games/121/G012181/20121110004/

X5680はOCすりゃいいじゃん

DualCPUにQuadro突っ込んでるようなガチWS機でOCとかあり得んでしょ

倍率ロックフリーだろ？

今気づいたんですけど「1CUあたりのワークグループの数」じゃなくて
「1CUあたりのワークアイテムの数」ですね、これ。
こりゃ当分の間安定版は出せないな…

>>603-604
報告ありがとうございます。CPU検索ももうちょっと何とかしたいですね〜
"Unknown"のエラーが出ているのは謎ですが、そこのエラーは無視するように
直しておきます。

予想通りというべきか、10桁トリップ検索はなかなかスピードが出てくれません。
まじめにプロファイラを使わないと駄目ですね、こりゃ。
まあCUDAのときもそうだったので、のんびり時間をかけて取り組むことにします。

>>605
GK110も試してみたいんですけどね〜
Amazon Cluster GPU Instancesで使えるようにならないかしらん。

Bitslice DES用の一時変数をどのメモリ空間に置けばいいのかいまいち
よくわからないので、とりあえず#ifdefで切り替えられるようにしておきます。
あと、一回のBitslice DESを複数のスレッドで同時に処理するかどうかも
CPU側で設定できるようにする予定です。こういうところは実行時にカーネルを
ビルドできるOpenCLはいいですねえ。

【GPU】HD7970 CFX 2GUPｓ
【CPU】FX-8350
【OS】Win7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 6
【トリップの種類】12桁
【1CUあたりのワークグループの数】5120
【1WGあたりのワークアイテムの数】40
【その他のオプション】-c -g -t 6 -a 8 （-aオプションは有効なのか？）
【Display Driver】Catalyst 12.10
【10分間の平均速度】2614.21tripcodes/s
【GPUの平均速度】2575.40tripcodes/s
【CPUの平均速度】38.31tripcodes/s
【GPU使用率】95%
【その他】7完1タゲ

いろいろ調整したら瞬間最大風速では3000M程度出るようにはなりました
ラデはCPU負荷高いですね
フルにCPU8スレッドで回すと却って速度が出ないです
CPU単体でなら50M程出るんですが

それと、CFXの有効無効では速度は変わらないですよ

http://www.rupan.net/uploader/download/1352766539.png

ついにデュアルTahitiカードがAMDから登場。エーキューブ，サーバー向けグラフィックスカード「FirePro S10000」を国内発売
http://www.4gamer.net/games/133/G013322/20121113023/

XeonPhiってどうなんですかねえ

負荷で思い出したけど、同じGPU使用率でもmtyのGPU版は95℃までいくけどMERIKENは89℃までしか上がらないね。

>>615
サーバ向けのFireProだし、3599ドルらしい。

>>616
OpenMPが使えて既存アプリの移植が楽らしいけど、既にOpenCLになっている場合はメリット薄そう。

>>614
なかなか良い感じに仕上がってますね。それだけOCした7970なら単体で1500M TPS近く
いくはずなので、単純に2枚で2倍の速度という訳にはいかないみたいですが…
Alpha 6では-aオプションは有効なはずです。CFXの話は別のところで見かけたんですが、
関係無かったみたいですね。

>>617
Bitslice DESはSHA-1の処理に比べてメモリへのアクセスの量が段違いですからねえ。

>>615
いいですね〜 いつかこういうのをたくさんラックマウントサーバーに乗っけて
Tripcode Finderを動かしてみたいですｗ

Southern Islandsだとコンスタントメモリは場合によってはグローバルメモリと
同じぐらい遅くなるそうで…こりゃCUDAと同じコードじゃ遅くなるわけだわ。
頻繁に使うのは最初にローカルメモリに移しておいたほうがいいな。

> 3. Varying Index
> More sophisticated addressing patterns, including the case where each work- item
> accesses different indices, are not hardware accelerated and deliver the same
> performance as a global memory read.

あとローカルメモリにアクセスする際はuint2を使うといいみたいです。

> Currently, the native format of LDS is a 32-bit word. The theoretical
> LDS peak bandwidth is achieved when each thread operates on a
> two-vector of 32-bit words (16 threads per clock operate on 32 banks).

vector data typesの使い方はここに書いてありました。

Programming with OpenCL C
http://www.informit.com/articles/article.aspx?p=1732873&seqNum=3

>>614
壁紙についてｋｗｓｋ
MERIKENさんの公式記録が越される日も近いか……

>>624
この辺で拾ってます
これがいつのものだったかは忘れましたw

http://www.smashingmagazine.com/tag/wallpapers/

>>625
そのまま2012/11の記事を見ても出てこないorz
http://www.smashingmagazine.com/2012/10/31/desktop-wallpaper-calendar-november-2012/
よろしければ画像アップローダに上げてくれませんか？

>>624
それはどうでしょうね… (￣ー￣)ﾆﾔﾘ

>>626
ほい

http://www.rupan.net/uploader/download/1352820886.jpg

>>621
どうせならHD7970 X2に行きませんか？
消費電力が凄まじいのと、スロット占有が問題ですけどｗ
なんかリンクが貼れないので詳細は検索してください

デスクトップ向けにHD7950のデュアルが出てくれれば一番ですけどね。
HD7950のCFはグラフィックでも割りと良いというレビューもあったので、需要もある程度ありそうですし。

>>622-623
OpenCLは以前よりは情報も増えたようですが、まだ茨の道なのでしょうかね・・・

>>628
ありがとうございます！

>>630
>>622-623はJohn the Ripperのメーリングリストを見てて気づきました。

http://www.openwall.com/lists/john-dev/2012/08/13/8
http://www.openwall.com/lists/john-dev/2012/09/10/5

このAlexanderという方はJohn the RipperとBitslice DESの偉い人です。
流石です。

http://www.openwall.com/lists/john-users/2011/06/22/1

>>630
まあGPGPUの不条理な制約にはCUDAで慣れっこになっているので
どうということはありませんｗ

>>629
うちの検索用マシンにはGTX 580が2枚と590が1枚載っているので、
7970 2枚は余裕ですｗ 今590を売っぱらって6990を買おうかどうか
考えているところです。

僕はもうラデ2枚構成にしたのでゲフォ売ります
10桁検索対応が楽しみですよー

>>633
頼もしいです、頑張ってください。

>>634
HD7970を1ボードに2基載せたもので8ピンx3で3スロット占有という
モンスターというかクレイジーな代物が出るらしいですｗ
それの複数枚挿しは電源だけでなくマザボもかなり選びそうです。

HD7950のデュアルで8ピンx2で2スロットであればまだマシなのですけどねえ。

やっぱりさよならゲフォの流れになったね

RADEONは普及用チップでも倍精度が高速なのがいい

mtyGPUがRadeonしか対応してないから、むしろゲフォ対応検索は(10桁では)貴重なんだが

>>638
マジレスすると倍精度演算が速いのは7970だけだしトリップ検索に倍精度演算の出番は無いぞ

>>635
10桁トリップ検索は12桁よりかなり難しいので、実際どこまで速度を出せるかは
わかりませんけどね〜 というか12桁検索の移植は正直うまくいきすぎでしたｗ
地道に取り組む予定なので、のんびり待っていて下さい。

で、あれから色々試してみて、Bitslice DES用の一時変数はローカルメモリに
おかないと全く速度が出ないことが分かりました。ローカルメモリは
ワークグループ内で共有されるので、Bitslice DESを8個のスレッドで
並列処理するように書き換えてやりました。

その後、さらに性能を上げるためにAMD APP Profilerで解析してみました。
あんまり期待してなかったｗのですが、非常に使いやすいです。
で、気になっていたOccupancy Analysisを行なってみたら、
案の定ローカルメモリ(LDS)の使い過ぎであることが判明しました。

http://www.meriken2ch.com/files/2012-11-13-AMD-APP-profiler.jpg

>>642
へぇ〜
人目でボトルネックがLDSにあることが示されてる
凄いな

同じ問題はCUDA版でも起きていたので思わず頭を抱えてしまったのですが、
ソースを眺めていたら解決方法を思いつきました。Bitslice DESの
一時変数は次の構造体にまとめられています。

> typedef struct {
> DES_Vector keys[56]; // 224 bytes
> DES_Vector dataBlocks[64]; // 256 bytes
> unsigned int dummy[1];
> } DESContext;

で、56bitのDESのキーが32個keys[]に収められているのですが、
これらのキーは実際にはほとんど同じです。
というわけで、キーの生成の方法を工夫してやれば、32個のキーの共通部分
51bitだけを保持して、残りは5bitのインデックス(0〜31)から生成して
やればいいことに気づきました。

これで使用するメモリの量は半分近くに減って、うまくいけば
CUDA版ともども10桁検索の速度が倍になることになります。
アルゴリズムはかなり複雑になりますが、試してみる価値は十分にあります。
hip2の話を聞いて、キーの生成方法にかなりの工夫の余地があることに
気づいたのは僥倖でしたｗ

>>643
実際かなり便利です。CUDAのときはなんせExcelのスプレッドシートを
使わないとOccupancyのグラフが見れませんでしたからねｗ

>>645
>速度が倍
うおおおおお！？頑張って下さい！

GTX670では470Mt/sくらいしか出ません。倍精度を使うわけでもないのになんでだろう。

ゲフォはさよならですかそうですか。
GTX480が何とか復活したので速度計測。

【GPU】GeForce GTX 480
【CPU】Xeon [email protected] x2CPU
【OS】Win7Pro 64 SP1
【バージョン】0.07a6 CUI64
【トリップの種類】12桁
【1CUあたりのワークグループの数】N/A
【1WGあたりのワークアイテムの数】N/A
【その他のオプション】-c -g -x 128
【Display Driver】306.97
【10分間の平均速度】648.27M TPS
【GPUの平均速度】578.39M TPS
【CPUの平均速度】69.89M TPS
【GPU使用率】100%
【その他】"TEST/", HT off, GPU 92℃

Quadroをぶっちぎっているのですが・・・うるさい。とにかくうるさい。
常用は無理です。

>>642
これは便利そうですね。

>>644
DESは歴史もあり奥が深いですね。

>>648
レジスタ数がネックになって演算ユニットを使いきれていないのだと思います。

レジスタの仕様が違うのか。最適化しなおさないといけないわけね。

>>648
>>651
トリップ検索の速度は整数演算の性能に大きく影響されるんですけど、
GTX 600シリーズで使われているKeplerコアは残念ながら整数演算が
かなり遅いのです。この点は次の記事の「命令別スループット」の
項目で詳しく解説されています。

GTX680のグラフィック・GPGPU性能を調べる ≪ dokumaru
http://dokumaru.wordpress.com/2012/03/27/gtx680-spec/

Keplerではゲームで使われる単精度演算以外はほとんど無視して
性能を稼いでいるので、GPGPU的にはかなり残念なことになっています。

>>649
580とあまり遜色のない速度が出ていますね。
自分の部屋ではGeForceが3枚24時間フル稼働してますｗ
CUDA版の開発も続けるので安心して下さい。

ここ数カ月のjohn-devでのOpenCLでのBitslice DESの実装についての
やり取りを追って見たのですが、なかなか面白かったです。

http://www.openwall.com/lists/john-dev/2012/09
http://www.openwall.com/lists/john-dev/2012/10
http://www.openwall.com/lists/john-dev/2012/11

現在John the Ripperは7970で20M c/sしか出せていないのですが、
OpenCLの実装を担当しているSayantan氏に対して、
Alexander氏が7970なら300M c/sは出るはずからボトルネックを探せ、
と言っているのが非常に興味深いです。

> Something like 300M c/s at DES-based crypt(3) on HD 7970. Maybe more
> than that if we hard-code E (generate or patch code on the fly).
http://www.openwall.com/lists/john-dev/2012/10/14/1

手元のTripcode Finderのコードは現在のJtRの実装より大分速いのですが、
それでも300M TPSには遠く及びません。レジスタ数にもまだ大分余裕があるし、
工夫の余地はいろいろあるのでしょう。実に奥が深いです。

Bitslice DESをマルチスレッド化したときにエンバクした模様。
結構な確率で間違ったトリップが出力されます。
CUDAと同じコードのはずなんですけど、barrier()がうまく動作してないの
かしらん。
しかしこれ、どうやってデバッグするんだろう…

>>655
昔ながらの printf でおｋ。
手段として美しくないのは嫌いとかなら知らん。

やっぱりそれしかないんですねorz

>>657
私が hip2 つくってた頃は printf すらなかったのに。
贅沢ね。

>>658
まあそりゃそうなんですけどね…

あ、原因分かったかも。CUDA版を書いてたときに適当だったところが
今になって問題になっているのかもしれません。

う〜ん、違うな… もうちょっと全体的に腐ってる感じです。

まあいいや。マルチスレッド化の作業はまた明日やり直すことにしよっと。

コードをロールバックしたらちゃんと動作するようなのでやっぱり
マルチスレッド化が原因のようです。マルチスレッド化すると
速度が倍近くになるので次はなんとか成功させたいところです。

480が余りにもうるさいので、590に交換。

【GPU】GeForce GTX 590
【CPU】Xeon [email protected] x2CPU
【OS】Win7Pro 64 SP1
【バージョン】0.07a6 CUI64
【トリップの種類】12桁
【1CUあたりのワークグループの数】N/A
【1WGあたりのワークアイテムの数】N/A
【その他のオプション】-c -g -x 128
【Display Driver】306.97
【10分間の平均速度】978.15M TPS
【GPUの平均速度】922.60M TPS
【CPUの平均速度】55.55M TPS
【GPU使用率】0-100%
【その他】"TEST/", HT off, GPU 85℃

CPUの負荷変動がかなり激しいです。6コアx2が100％になることはまず無く、全コアが完全にストールすることも良く起こりました。
>>170 でもある程度CPUの負荷は変動しましたが、ここまで酷くは無かったです。
おまけにGPUもたまに完全にストールする始末。これは>>170 のマシンでは無かった。
タゲを増やすと負荷変動は落ち着きます。ここまで負荷がふらつく理由がさっぱり分かりません。

電源容量が足りないんじゃ

OpenCLの10桁検索ですが、もうちょっと調べたらどうも移植した直後から
問題があったようです。APP Profilerがメモリリークを報告しているので
もうちょっと調べてみます。

>>664
温度に問題がないなら電源の可能性が高いですね。
電源は何を使われていますか?

どうやら問題はBitslice DESの処理そのものではなく
他の処理にある模様。ちゃんと出力をチェックするルーチンを
作りこんで、徹底的にテストするしかないようです。
やなよかんはしてたけど、やはり10桁検索は楽ではないですねえ。

電源が届くのを待ちきれなくて、無理矢理繋げて実行していました。
電力不足でこんな挙動をするとは初体験で全然知らず。お恥ずかしい限りです。
素直に電源届くまで待っています。

>>669
そりゃそこにカードがあれば試したくなりますよね。
その気持、わかりますｗ
電源が届いたらまたぜひ報告して下さい。

OpenCLの10桁検索の出力が腐っていた問題ですが、カーネルをすこしづつ削って
原因を探ったところ、結果を書き込む__globalの配列へのアクセスの前後に
barrier()を入れてやると問題が出なくなることが分かりました。

Bitslice DES用の一時変数を__privateに置いても直らなかったし、
CUDA版やOpenCLの12桁検索では全く問題がなかった部分なので、
AMDのOpenCLの実装のバグの可能性が非常に高いです。
AMDの実装は性能は出るのにいちいち造りが甘くて非常にもったいない
感じがします。ここらへんもCUDAのほうが任期がある理由なんでしょうねえ。

この件でコードをロールバックした時に気がついたのですが、
Bitslice DESの一時変数を__private空間においても割と速度が出ることが
わかりました。こっちのほうが__localよりもベクトル化しやすいので、
このまま__localを使わずに最適化をすすめることにします。
Bitslice DESの深さを32bitから128bitにして速度も4倍といきたい
ところですが…

>>672
>ベクトル化
よく知らないのですが、GPUってベクトル演算なんですか……？
ベクトル化の意味は知っているのですが、なぜか「昔のスパコン」ってイメージが……ｗ

GPUはベクトル演算の極地だし、今のスパコンはほぼ全てベクトル演算ですが

もの自体がベクタプロセッサの集合体

>>673
そこがGPGPUの一番美味しいところですｗ
性能を引き出すのはなかなか難しいですけどね〜

あの後色々調べてみたんですけど、単純にDES_Vectorをuint2やuint4で置き換えて
やれば性能が出るというわけでもないようで、もうちょっと調べる必要が
あるみたいです。

あと、localなメモリに書き込んだ後は必ずbarrier()を呼び出さないと、
ちゃんとメモリ操作の結果が反映されないようです。おかしいなと思って
OpenCLの仕様書を見ると確かにこう書いてあります。

> The barrier function also queues a memory fence (reads and writes) to
> ensure correct ordering of memory operations to local or global memory.
http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/barrier.html

CUDAの場合は動機が必要なところで__syncthreads()を呼び出してやれば
後はなにも考えずに共有メモリとグローバルメモリに読み書きできたのですが、
どうも勝手が違うようです。

OpenCLでの10桁検索の話の続きです。
>>545の案を実際に実装してメモリの使用量を半分に抑えることで、
速度を50%ほど向上させることができました。キーを動的に生成することに
よるペナルティが割と大きく2倍とはいきませんでしたが、
まあそれでもかなりの進歩です。Kernel Occupancyはこんな感じです。

http://www.meriken2ch.com/files/2012-11-17-AMD-APP-profiler.jpg

ローカルメモリを使うと出力が化けまくるので、とりあえず
Bitslice DES用の一時変数はすべてレジスタ上においています。
このままレジスタの数を削ってOccupancyを上げてもいいし、
またローカルメモリに戻してみてもいいし、これでようやく先がすこし
見えてきた感じです。

一応ローカルメモリに戻して速度を測ってみたのですが、
思ったほど速度は出ませんでした。というわけで
一時変数はこのまま__private空間においたまま
最適化をすすめることにします。
カーネルをなるべく簡単にして、キーの生成の準備をすべて
CPU側で行うことにします。
またレジスタの数を削る日々がはじまるお…

あの後ちょこちょことカーネルをいじっていたんですけど、
適当なところにbarrier()を入れるとレジスタ数が減ったり
スピードが上がったりと不思議なことの連続でした。
色々実験してみるもんですね。こんなことは流石にマニュアルには
書いてあるわけないしｗ

奇妙すぎる仕様だ……

これは4日前に公開されたばかりのRadeon用のアセンブラです。

GCN ISA Assembler
http://devgurus.amd.com/message/1285111

HetPas
http://realhet.wordpress.com/2012/11/14/hello-world/

GCNの命令セットについてなかなか面白いことが書いてありました。
こういうので最適化したらものすごい速度が出るんでしょうねえ。
JtRのAlexsander氏は動的にコードを生成しろなんて言ってたけど…

>>681
まったく謎だらけですｗ カーネルアナライザを使えばもうちょっと詳しく
分かるんでしょうけど、goto文を使っているとエラーが出て動かないんですよね…

気分転換で、前から欲しかったトリップの自動保存と自動検索実行の機能を
つけてみました。ブレーカーが落ちるたびにうんざりしながら検索君1号を
立ち上げなおしていたのですが、これで再起動もボタンを押すだけで済んで
検索結果が失われることもなくなりました。この機能は次の開発版から
利用できるようになる予定です。

>>684
そんなにブレーカーが落ちる環境だったとは……
(開発以外)休んでも、いいのよ？

海を越えると電気も日本みたいに高品質じゃないんだよ

>>685-686
グラボ4枚で検索するようになってから急に落ちるようになりました。
ブレーカーがどうも古いみたいで、大家さんに言ったんですけど
ちっとも変えてくれません。まあでも消費電力に常に気を付けるように
したら大分ましになりました。

レジスタ数を107から90まで頑張って減らしました。
目標の84まであともうちょっとなんですけど、
コンパイラの挙動が全く予想できないのでなかなか難しいです。

カーネルアナライザが動かなくてカーネルのILとISAが見られなかったん
ですが、次のページを参考にしてようやく見れるようになりました。
カーネルをビルドするときにオプションで"-save-temps=[prefix]"と
していしてやればビルド時の一時ファイルが保存されます。

Looking for specific details of GPU_DUMP_DEVICE_KERNEL
http://devgurus.amd.com/thread/159168

Kernelanalyzer refuses to compile anything
http://devgurus.amd.com/thread/159924

最近のドライバではカーネルアナライザは動かないそうで…
AMDにはもうちょっと頑張ってもらいたいものです。

あの後レジスタ数を減らすためにいろいろと試してみたのですが、
どうやっても90から更に減らすことはできませんでした。
どうも本気でレジスタ数の割付を最適化するためには
GCNのコードを直接書く以外ないようです。

仕方が無いので、割と時間がかかっているカーネルへの入出力の処理を
効率よく行うようにするための作業にとりかかりました。
とりあえずオーバーヘッドの大きいclEnqueueWriteBufferを1つにまとめたら、
なぜか未だに完全に消えてなかった出力が化けるバグが綺麗さっぱり
なくなりました。やれやれです。

さっきjohn-devの11月のポストを読んでたんですけど、
何か問題が起きるとすぐにAMDのOpenCLドライバのバグが疑われてて
笑ってしまいましたｗ これは相当評判が悪いみたいですね…

> > All my accusations about driver bugs were... well they were based
> > on statistics, what can I say? :-)
> >
> > magnum
> We saw some craziness that justify our accusations.
http://www.openwall.com/lists/john-dev/2012/11/22/5

なんにせよドライバのバグを華麗に避けつつOpenCLの10桁検索を使い物に
するには相当時間がかかりそうなので、とりあえず12桁検索のほうを
先に仕上げてしまうことにしました。今週末に次の開発版を公開する予定です。

>>691
ドライバの完成度の問題ですか、厳しいですねえ・・・

鳥屋は凄腕だな。

鳥屋氏が凄腕なのは間違い無いですね。mtyのGPU版の速度は異常です。
ただCAL ILで書かれたmtyと同じ速度をOpenCLで出すのも無理な気がしますけどね〜
JtRの20M c/sは論外にしても、Hashcatですら7970で79M c/sしか出せていない
ですからねえ。もうちょっとJtRのSayantan氏に頑張ってもらいたいものですけど、
メーリングリストのやり取りを見ている限りではとても期待できそうにありませんorz

なにか10桁検索の参考にならないかと思ってJtRのソースを眺めていたら、
全然関係ない12桁検索の高速化のネタを見つけましたｗ
といってもハッシュ作成の際にbitselect()とrotate()を使うというだけの
話なんですけど、効果は抜群でOCした7970単体で1600M TPSを軽く超える
速度が出ています。いまだにこんなおいしいネタが転がっていたとは驚きです。

>>695-696
ということは12桁最高記録が300M/s以上増えることに！？

ところでmtyGPU版の10桁最高記録ってどれほどなのでしょう？
自分で(2chソースを)ググって分かったのは237M/s(1枚で)、枚数差しても〜750M/sぐらいだったのですが……

>>697
スレチだな。ｗ
こっちいけ。
http://yy43.60.kg/test/read.cgi/tripageruo/1274911652/

>>698
後半荒らされ放題じゃないですか………‥

なるほど、少なくとも>>79で714M/sという記録が出ていたんですね。失礼しました

最大公約数的なプログラミングじゃなくて、自分の持ってるカードに絞ってゴリゴリ書いていけばいいんじゃないの？
その方が速度も出ると思うんだけど

MERIKENさんってTOEIC満点とれる超人だったんですね・・・

>>697
今でも3.5G TPSあたりなら堅いでしょう。いろいろ弾を仕込んでいる最中なので、
次に記録を狙うときには目標は4.5〜5G TPSあたりになると思います。

>>700
最大公約数的なプログラミングはとっくの昔に諦めて7970にターゲットを絞って
ますけど、それでもなかなか難しいです。

>>701
私は大学からアメリカなのであれはいろんな意味で「おまけ」なのですｗ

1台のPCに積載できるGPUの量には限りがありますし、
そのうちサーバプログラム用意して検索条件の配布、検索結果の集計みたいな疎結合クラスタになりますん？

>>705
そのうちそうなるでしょうねえ。スタンドアロンでの性能がちゃんと出るようになって
からということになるので相当先の話だと思いますけど…

>>705
トリップ検索クラスタ(物理)か……
GPUが絡まないと有り難みが薄いですねｗ

トリップ検索p2pネットワークか‥胸熱

>>698
スレチと、言ってるののたんに　　（はぁはぁ

>>708
個人でクラスタするのは有りだけど、
参加フリーでみんなの検索条件を合算するようになると生成されたトリップの判定にパワー食っちゃって……

サーバーから検索条件をダウンロードしてみんなで12連とかのレアトリップを
探すというのも面白いかもしれませんねｗ

10桁検索のほうはAlexander氏の言っていた、動的にカーネルを書き換えて
DESのexpansion functionをソースに埋め込むという方法で以前に比べると
大分速くなりました。が、それと同時にドライバのバグによる出力が化ける問題が
再発生した模様。まったく地雷原を歩いているようです。

出力が化ける問題はなんとか解決できました。いや〜、まいったまいった。

というわけで実行時のカーネルの書き換えでようやくHashcatとほぼ同じ速度が
出るようになりました。Tripcode FinderのCUDA版の10桁検索はHashcatよりも
ちょっと速いぐらいなので、もうそろそろ限界のような気もしないでも
ないです。あとはGCNのコードを手書きしてS-Boxを最適化して
レジスタ数を削るぐらいしか思いつきません。とりあえず10桁検索は
しばらく置いておいて、次の開発版を用意することにします。

2週間ぶりの開発版です。

MERIKEN's Tripcode Finder 0.07 Alpha 7
http://www.meriken2ch.com/programming/merikens-tripcode-finder

Alpha 6からの変更点は以下になります。

・OpenGLの12桁トリップ検索の高速化。
・検索スレッドと検索プロセスの数を指定するオプションの追加。
・検索の自動実行と検索結果の自動保存を行うオプションの追加。
・様々なバグの修正。

検索スレッドと検索プロセスの数を増やすことによって、
複数のGPUを使用する場合のGPUの使用率を増やすことができます。
おいしいです（＾ｑ＾）

おつおつ
回してみるべ

この構成であるふぁ7
http://www.dotup.org/uploda/www.dotup.org3665284.png

Alpha 7用の新しい報告用のテンプレです。

【GPU】
【CPU】
【OS】
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 7
【トリップの種類】12桁・10桁
【1SMあたりのブロックの数(CUDA)】
【1CUあたりのワークアイテムの数(OpenCL)】
【1WGあたりのワークアイテムの数(OpenCL)】
【1GPUあたりの検索プロセスの数(OpenCL)】
【1検索プロセスあたりの検索スレッドの数(OpenCL)】
【その他のオプション】
【Display Driver】
【10分間の平均速度】 tripcodes/s
【GPUの平均速度】 tripcodes/s
【CPUの平均速度】 tripcodes/s
【GPUの使用率】
【GPUの温度】
【その他】

>>715
ぜひ色々試してみてくださいｗ

>>716
これは1枚ですか? かなり出てますね〜

書き忘れー
解凍したまんまで
GPUの温度は室温20度で41度まで上がった、負荷は100%
水冷だしこんなもんだね、ゲームだと36度くらいしか上がんないからいかにGPUが仕事してるかわかるw

>>719
ですよー、リファの7970

唐突だけどコマンドラインオプションの私的まとめ(☆はデフォルトでは自動設定される項目):
--redirection　　　　　 　?
-f [inputfile] 　 　 　 　 　入力ファイル名
-r [inputfile]　　　　　　　入力ファイル名(正規表現)
-o [outputfile]　　　 　 　出力ファイル名
-l [length]　　　　　　　 　検索するトリップ長(12 or 10)
-g　　　　　　　　　　　　　検索にGPUを使用　(デフォルト)
-d [device] 　 　 　 　 　 CUDAデバイス番号(0〜)　(デフォルトは全て使用)
-x [block/SM]　　　 　 　ブロック/SM(CUDA)　☆
-y [workgroup]　　　 　　ワークグループ/CU(OpenCL)　☆
-z [workitem] 　 　 　 　 ワークアイテム/WG(OpenCL)　☆
　　　　　　　　　　　　　 　※workgroup mod workitem=0、workitem mod 8=0とすること
-c　　　　　　　　　　　　　検索にCPUを使用(-gと併用可)
-t [threads] 　 　 　 　 　CPUにおける検索スレッドの数　☆
-a [threads]　　　　　　　1つのAMDのGPUに対する検索スレッドの数(OpenCL)　☆(〜0.07Alpha6)
　　　　　　　　　　　　　 　1検索プロセスあたりの検索スレッドの数(OpenCL)　☆(0.07Alpha7〜)
-b [processes]　　　　 　1GPUあたりの検索プロセスの数(0.07Alpha7〜)
-m MutexForMERIKENsTripcodeFinder-4648　GUI版とCUI版が通信するときに使うおまじない(〜0.07Alpha6)
-m MutexForMER　　 　GUI版とCUI版が通信するときに使うおまじない(0.07Alpha7〜)
-i　　　　　　　　　　　　 　2ちゃんねるで直接使用できないトリップを16進形式で出力
-w　　　　　　　 　 　 　 　検索スピードの急激な低下を警告

>>722
あ、-yは「ワークグループ」じゃなくて「ワークアイテム」です。
最初に書いたときに間違えちゃったんですよね〜

>>721
う〜ん、水冷は素晴らしいですね。空冷での温度を見慣れていると
別世界のようですｗ

>>723
つまりこうですね、分かります。
>-y [workitem1]ワークグループ/CU(OpenCL)(デフォルトは自動設定)
>-z [workitem2]ワークアイテム/WG(OpenCL)(デフォルトは自動設定)
>※workitem1 mod workitem2=0、workitem2 mod 8=0とすること

ところで--redirectionって何をリダイレクトしているんですか？

俺おっちょこちょいの素質あるのかな……
>-y [workitem1]ワークアイテム/CU(OpenCL)(デフォルトは自動設定)
>-z [workitem2]ワークアイテム/WG(OpenCL)(デフォルトは自動設定)
>※workitem1 mod workitem2=0、workitem2 mod 8=0とすること

次のVerからはREADMEに訂正が必要なようですね……＞MERIKENさん

>>725-726
リダイレクトしているのは標準出力です。
訂正はもう入ってますよ。

【GPU】Xeon E5-2687W×2
【CPU】HD6990×2
【OS】Windows８ Pro
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 7
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】-
【1CUあたりのワークアイテムの数(OpenCL)】解凍時のまま
【1WGあたりのワークアイテムの数(OpenCL)】解凍時のまま
【1GPUあたりの検索プロセスの数(OpenCL)】解凍時のまま
【1検索プロセスあたりの検索スレッドの数(OpenCL)】解凍時のまま
【その他のオプション】-
【Display Driver】Catalyst12.11β
【5分間の平均速度】 4816.85tripcodes/s
【GPUの平均速度】 4711.99tripcodes/s
【CPUの平均速度】 104.86tripcodes/s
【GPUの使用率】100%
【GPUの温度】一番高いコアで46℃
【その他】GPUはTDP450Wモード定格
http://www.dotup.org/uploda/www.dotup.org3665573.png

これはもしやメインも仕事してくれるのではと思ったら案の定
時間ないんでどちらも5分でスマヌ

>>728
これは最高速の記録ですね。素晴らしいです。
私も次に記録を狙うときにはもうちょっと弾を揃えないと…

>>728
脳内での　最　速　記　録　が　塗　り　替　え　ら　れ　た　瞬間であった

期待できないけどノートで回してくるー

因みにこれで1160W前後の消費電力

>>569 です。Alpha7公開お疲れ様です。

【GPU】SAPPHIRE VAPOR-X HD5770 1G (OC: GPU 960MHz MEM 1265MHz)
【CPU】Intel Core i7-3770(無印)
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 7
【トリップの種類】12桁
【1CUあたりのワークアイテムの数(OpenCL)】3200
【1WGあたりのワークアイテムの数(OpenCL)】64
【1GPUあたりの検索プロセスの数(OpenCL)】1
【その他のオプション】
【Display Driver】Catalyst 12.10
【10分間の平均速度】586.05M tripcodes/s
【GPUの平均速度】550.44M tripcodes/s
【CPUの平均速度】35.62M tripcodes/s
【GPU使用率】99%
【GPUの温度】72℃ （室温22℃）
【その他】テスト時間10分08秒、7完1タゲ

>>731
450W x 2 + αですか。こりゃすごいｗ

>>732
5770でもかなり速度が出てますね。
今回はかなり内部をいじったので、ちゃんと動いているようでほっとしました。

【GPU】HD7970 CFX 2GPUｓ ＠1150MHｚ
【CPU】FX-8350 ＠5GHｚ
【OS】Windows7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 7
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】
【1CUあたりのワークアイテムの数(OpenCL)】960
【1WGあたりのワークアイテムの数(OpenCL)】64
【1GPUあたりの検索プロセスの数(OpenCL)】default
【1検索プロセスあたりの検索スレッドの数(OpenCL)】default
【その他のオプション】-g -c -t 6
【Display Driver】Catalyst12.11 beta6
【10分間の平均速度】5277.77 tripcodes/s
【GPUの平均速度】5243.39 tripcodes/s
【CPUの平均速度】34.39 tripcodes/s
【GPUの使用率】99%
【GPUの温度】76℃
【その他】7完1タゲ

効率が上がったためか-t 6で回したら強制シャットダウン、恐らく冷却不足か電源容量不足
とりま、ぬるい設定で解凍したまま

※今までは検索始めるとマウスカーソルがカクカクになり、USB音源を見失っていましたが、そういった現象はなくなりました

http://www.rupan.net/uploader/download/1353865513.png

あ、-t 4 の間違いです

　ノーパソから計測実験。デスクトップでグラボぶん回すのと比べると雑魚レベルだが許してくれ。
【GPU】NVIDIA GeForce 610M(、Intel HD Graphics 4000)
【CPU】Intel Core i5-3210M
【OS】Windows Vista Home Ultimate SP1 64bit
【その他のオプション】-g -c -l 10か-g -c -l 12での計測(速度が安定した時点で記録)
【Display Driver】見方を教えて下さい……
↑の条件で、ソフトのVerと桁数を変更しながら計算するとこうなった↓

0.07Alpha6　　0.07Alpha6　　 0.07Alpha7　　 0.07Alpha7
10桁　　　　 　 12桁　　　　　　10桁　　　　　　12桁
----------------------------------------------
使用不可　　　160　　 　 　 　 使用不可　　　128　　　　　 ←blocks/SM
使用不可　　　64　　　　　　　 使用不可　　　使用不可 　 ←items/CU
使用不可　　　32　　　　　　　 使用不可　　　使用不可 　 ←items/WG
4　　　　　　　　2　　　　　 　 　 3　　　　　　　　3　　　　　　　←CPU演算スレッド数
使用不可　　　48.9M/s　　　　3.54M/s　　　　48.96M/s　　←速度(CUDA)
使用不可　　　4.9M/s 　 　 　 使用不可　　　使用不可 　 ←速度(OpenCL)
使用不可　　　9.66M/s　　　　4.03M/s　　　　10.91M/s　　←速度(CPU)
5.27/s　　　　　63.43M/s 　 　 7.57M/s　　 　 59.87M/s　　←合計速度
----------------------------------------------
確かに改良は効いているが、な　ぜ　ア　ホ　の　子　を　外　し　た　し

>>735
これはすごい数字ですねえ。いくらなんでも速すぎだろうと思って
Catalyst 12.11 Beta 8を試してみたら、うちの7970 1枚でも2497M TPS
出てて吹きましたｗ 12.9 Betaではここまでのスピードは出なかったので、
ここ2ヶ月でAMDのドライバにかなり手が入ってますね〜

7970の4wayやれば10Gか…
コンセントの端子が熱くなるな

公式サイト(http://www.meriken2ch.com/programming/merikens-tripcode-finder)とか見ていると
OpenGLとOpenCLが脳内でごっちゃになりそうなのでまとめ：

OpenGL……シリコングラフィックスが開発していたクロスプラットフォームな3DグラフィックスのAPI。
　　　　　　　　ハードウェアに近い低水準な機能も使えるので高速だが、文字列描画が苦手。
　　　　　　　　GPGPUの利用法は、OpenCLよりもグラフィックス寄り。
OpenCL……アップルのKhronos Groupが開発した、クロスプラットフォームな並列コンピューティング用のAPI。
　　　　　　　　要するに、「CPUやGPUなどの計算資源を、並列演算用にまとめて扱えるようにするよ！」
　　　　　　　　といったもの。GPGPUの利用法は、OpenGLよりは演算寄り。

>>740
あ、あれはOpenCLの間違いで、OpenGLは一切関係ないですｗ
ご自分用のまとめはここに書き込まないでいただけると有難いです。

>>737
OpenCL以外の検索ルーチンはいじってないので速度は変わっていないはずです。
Intelのはドライバのバージョンによってアプリケーションが落ちるろいう報告が
あったのでやむなしです。

>>741
了解しました。
>>742
そうだったんですか……。チェックボックス対応でも、というのは無茶でしょうか。
10桁の演算速度が上がっているのは確実な気がするのですが、
単に自環境ではAlpha6でGPU演算が使えなかっただけ(デバイスが対応していない)
なのかもしれません。次買うのはRadeonGPU搭載PCにするかな…‥

>>740
geforce君はもう書き込まないでくれるかな？

>>743
Intelのはドライバの出来がイマイチで性能が全く出ないのに
メンテの手間だけかかって、おいしいところが全くないんですよね。
Intel対応はXeon Phiが消費者向けに発売されたら考えますｗ

>>745
確かに、グラボが出す速度を考えたらIntelのは誤差の範囲ですよねｗ
もうその件については触れないことにします。回答ありがとうございました。

ドライバといえば、Catalystの新しいβ版で10桁検索を試してみたら、
速度が1/3になっていましたorz CUDAでもそうでしたけど、
GPGPUは開発環境やドライバによってアプリケーションの性能が
乱高下する傾向がありますねえ。ドライバの次のバージョンアップで
直っているといいんですけど…

新しいAMDのドライバで12桁トリップ検索のプロファイリングを行って見たのですが、
ベクターレジスタ(VGPR)の数が40まで減っていて、Occupancyが10から60にまで
上がっていました。どうりで検索速度が上がっているわけです。

どうやらAMDのコンパイラの最適化のアルゴリズムが、命令の数を増やしてでもレジスタ数を
減らすことを優先するものに変更されているようで、それが12桁の場合はうまく働いたけど
10桁の場合は完全に裏目に出ている、ということらしいです。やっぱり本気で10桁トリップ検索で
性能を出そうと思ったらILかGCNのコードを自分で書くしかないみたいですが、とりあえず
以前のドライバでOpenCLバイナリを生成して、実行時にはそれを使うように変えておくことにします。

AMDのOpenCLドライバをAMD APP 2.7のものにロールバックしたら
ようやく10桁検索の速度が元に戻りました。次のファイルは
ドライバのアンインストールでは削除されずに直接手で削除する
必要がありました。

SlotMaximizerBe.dll
SlotMaximizerAg.dll
amdocl.dll
OpenVideo.dll
OVDecode.dll

これがわかるまでエラく手間取りましたが、これでようやくOpenCLバイナリの
作成に取り掛かれます。

10桁トリップ検索のコードですが、なんとCatalyst 12.8以前のドライバでは
出力が化けることが判明しました。ドライバのバクにしても
いくらなんでもひどすぎるorz

>>746
手間がかからないならサポートしてもいいんですけど、テストの量が倍以上に
なりますからねえ。残念です。

>>739
これ2枚積めば10G TPS超できそうです。TDP 500Wの化物だけど、
普通に検索君1号に2枚収まりそうなんだけど、流石に20万は払えないよな…
あぶないあぶないｗ

Radeon最上位のデュアルGPU版「HD 7990」発売、重さを支える支柱付き カードは弩級
http://akiba-pc.watch.impress.co.jp/hotline/20121124/etc_club3d.html

Club 3D Radeon HD 7990 Dual GPU
http://www.club-3d.com/index.php/products/reader.en/product/radeon-hd-7990-dual-gpu.html

>>752
そんなに電源虐めたいかｗｗ

>>753
そこにハードウエアがあれば限界まで性能を出したくなるのが
男のさがというものですｗ

10桁酉が割られる日も近いな…ｺﾞｸﾘ

10桁検索ですけど、crypt()のseedの値に基づいてカーネルを動的に
書き換えていたことをすっかり忘れていましたｗ
これって実行時にOpenCLバイナリを書き換えるか、seedの数だけバイナリを
用意しなきゃいけないってことだよな…

>>756
最適化スゲェ……
でも、10桁のシード(ソルト)って確か2バイト分(最大256^2=65536通り)あるんじゃ

>>757
実際には2chの仕様のせいで65^2=4225通りなんですけど、
それでも結構な数です。とりあえず実験的に作ってみますけど、
さすがにこれを配布パッケージに含めるのは考えちゃいますねｗ

>>758
単純に考えて、3.5MB×2×4225≒30GBかぁ……

動的書き換えでお願いします(切望)

>>759
書き換えが必要なのはOpenCLのカーネルのバイナリだけなので
そこまでひどくはならないですｗ せいぜい数十MBのオーダーでしょう。
圧縮がかなり効くはずなので配布パッケージ自体はそこまで大きくならない
はずですけど、こればっかりは試してみないとわかりません。

新しいドライバで10桁検索をプロファイリングしてみたのですが、
SALBusyが80.84%なのに比べてVALUBusyが28.91%と妙に低いのに
気づきました。MemUnitBusyが66.81%とかなり高いのも気になります。
これは実際にS-Boxで費やされている実行時間は全体の3割程度ということで、
かなり効率が悪いことになります。ちょっとドライバのバージョンを落として
比較してみます。

>>747-748
バージョンによって最適化がかなり違うのですか、面倒ですねえ。

>>756
saltに応じてカーネルの動的書き換えとかできるのですか。
できるにしても実際にやるのが凄いですｗ

>>758
crypt(3)の仕様で64^2=4096通りではないのですか？

>>762
あれれ、そうでしたっけ? もうちょっと調べてみます。

>>762
CUDAでも開発環境のバージョンによってかなり速度差が出てましたけど、
OpenCLではドライバのバージョンで違ってくるので頭が痛いです。
HashcatはカーネルをLLVM IRで配布してるみたいですけど、
似たようなことをしたほうがいいのかもしれません。

Catalyst 12.9 Betaに戻してみたら、こんな感じでした。

VALUBusy: 28.91% -> 36.15%
SALUBusy: 80.84% -> 113.88%
MemUnitBusy: 66.81% -> 63.67%

VALUBusyがちょっと上がっただけで速度は3倍になってるので、
ベクターユニットが遊んでいるせいで7970は相当余力を残している
ことになります。かなりの性能向上が期待できそうなので、
OpenCLの実装が一段落したら、自分でGCNのコードをいじってみようかな…

>>765
> SALUBusy: 80.84% -> 113.88%
100%越えってどゆことー？

>>766
それはまったく謎ですｗ

>>762
調べてみましたけど、2chのトリップ生成でのsaltの扱いはcrypt (3)の仕様から
ずれているので、やっぱり4225通りであってました。

2ch トリップ仕様
http://sourceforge.jp/projects/naniya/wiki/2chtrip

最初に10桁トリップ検索の実装をした時にも思ったことですが、
見れば見るほどひどい仕様ですｗ

>>768
面妖な！

……ひょっとして10桁検索がどうしても遅くなるのはここにも理由があるんじゃ

7990ですけど別の会社からも発売されてますね。

PowerColor AX7990 6GBD5-2DHJ Radeon HD 7990 6GB
http://www.newegg.com/Product/Product.aspx?Item=N82E16814131483

一枚で$899なので>>752のカードより大分安いですが、がまんがまん…

>>769
10桁検索が遅くなるのはBitslice DESでメモリへのランダムアクセスが
大量に発生するのが大きいです。こればっかりは仕方ないですね。

isaファイルを出力させてGCNのコードを眺めてたんですが、
register spillsが発生している模様。"ScratchSize = 140;"なる記述が
isaファイルにありました。道理でなかなか速度が出ないわけです。
プロファイラのScratchRegsの欄がNAになってたので完全に油断してました。
NAはnot applicableじゃなくてnot availableの略だったのね…

なんにせよこれでMemUnitBusyやMemUnitStalledが高いのも、VALUBusyが
低いのも説明がつきます。これってCUDAのときみたいにS-Boxを書き換えたら
なんとかなるのかしらん。

S-Boxとおぼしき場所に倫理演算の命令に混じってbuffer_store_dwordと
s_buffer_load_dwordx4という命令が大量にあったので、
たぶんこれが速度が出ない原因なんでしょう。
ちょっとすっきりしたけど、これってコンパイラのレジスタの割付が
全然うまく行っていないということですよね。やれやれです。

倫理演算じゃなくて論理演算でした。

S-Boxの数を変えてISAファイルを調べてみたら、コンパイラがレジスタを
きちんと再利用していないことが判明。

S-Boxes: 1
Kernel occupancy: 10
NumVgprs = 180;
ScratchSize = 0;

S-Boxes: 7
Kernel occupancy: 10
NumVgprs = 239;
ScratchSize = 0;

S-Boxes: 8
Kernel occupancy: 20
NumVgprs = 105;
ScratchSize = 140;

register spillsが起きるとメモリアクセスが枷になって遅くなるし、
起きなければoccupancyが半分になるしでなかなかうまく行きません。
Bitslice DESに必要なレジスタの数は64 + 17 = 81ぐらいなので、
180〜245というのはいくらなんでも多すぎです。
CUDAだったら直接PTXのコードを書けばいいんだけど、OpenCLだと
そういうわけにもいかないので実に難しいです。使用するレジスタの数も
CUDAみたいにコンパイル時に指定できたらいいんですけどねえ。

駄目元でAMDのフォーラムに報告してみるとか

http://www.meriken2ch.com/programming/merikens-tripcode-finder
そんなにPC酷使したいならこれで12桁の酉でも探してろ

すまん間違えたｗちゃんと生贄連れてくるわ

よりによってこのスレに誤爆ｗｗｗ

Catalyst 12.11 Beta11が出たな

>>776
う〜ん、どうなんでしょうねえ。レジスタ割り付けを改善すれば
速度が上がるのは自明なので、特に報告するまでもない気もします。
実際12桁検索は倍近く速くなったので、今後に期待といったところです。

>>777-779
ぜひ活きのいいのをお願いしますｗ

>>780
かなり頻繁に更新してますね。現在ダウンロード中です。

>>287のPCIe用の延長ケーブルを使って、空冷用のスペースを
確保しつつ検索君1号にグラボを3枚積めることを確認しました。
見た目は最悪ｗですが、ちゃんと動いているので結果オーライです。
弾も色々揃えたので、帰省するまでに最高速の記録を更新できるかも
しれません。

>>784
6G級あるか!?

>>785
さあ、どうでしょうねえ… (￣ー￣)ﾆﾔﾘ

ターゲットが長くなるとヒットするまでの平均時間をいまいち正確に
出せなかった問題ですが、次のライブラリを使うことで解決できることが
わかりました。

Multiple Precision Integers and Rationals
http://www.mpir.org/

Visual C++だとlong doubleがdoubleと同じ精度なので困ってたのですが、
これなら全く問題ないでしょう。

MPIRのビルドはあっさり成功して、ちゃんとTripcode Finderに
リンクすることができました。サンプルで2の120乗を計算してみましたが、
ちゃんと正しい結果が出ています。このライブラリには分数計算のルーチンも
含まれているので、非常に正確に確率計算ができるはずです。わくわく…

おっと、間違えた。サンプルで計算したのは2の1920乗でした。
このライブラリ、logが計算出来ないから使うの結構面倒そうだな。
どうしたものか…

>>787-789
>ヒットするまでの平均時間をいまいち正確に出せなかった
そうだったのですか！？
ひょっとして有効桁数が2桁表示なのはそのせい……？

↓ところで、トリップ確率を計算するソフトを作っていたのですが、
http://up3.viploader.net/pc/src/vlpc012973.png
桁数が変わる「.」とかが入った時や準X連な時の正確な組み合わせ数を計算するのが難しいのデス……
どういった計算アルゴリズムで出しているのですか？大雑把でいいので教えて下さい！

>>790
基本的な流れは以下のとおりです。

(1) 正規表現のパターンを位置と固定長文字列の組み合わせに展開する。
(2) 各組み合わせごとの確率を計算する。
(3) (2)の確率の合計を求める。

注意しなければならないのは、各文字が特定の位置に出現する確率は
通常は1/64ですが、特殊文字の場合は違うということです。
例えば"."と"[:digit:]"がヒットする確率はそれぞれ64/64と10/64と
しておかなければ正確な結果が出ません。

具体的な例を挙げると、12桁トリップ検索における"^test./"の出現確率は

p = (1/64)*(1/64)*(1/64)*(1/64)*(64/64)*(1/64)

となります。

また、位置指定をしていない"/test[:digit:]/"の場合、出現位置が
0〜5の6通りなので、

p = (1/64)*(1/64)*(1/64)*(1/64)*(1/64)*(10/64)*(1/64)*6

になります。

MPIRの分数の型であるmpq_tを使って確率計算をすると、
遅くて使いものにならないことが判明orz
厳密にしすぎるのも考えものですね…
仕方ないので浮動小数点数の型のmpf_tを使うことにします。
任意の精度を指定できるのでこれで十分でしょう。

MPIRを使ってヒットまでの時間を予測するルーチンを書き直しましたが、
結局doubleを使った元のルーチンに比べて数パーセント精度が
向上しただけでした。元のルーチンもわりと正確だったということですが、
前からだいぶ気になっていた部分だったのでまあ良しとします。

>>790
あ、あと書き忘れてたけど、準x連の場合は該当する文字が出現する確率は
大文字と小文字をあわせて2/64になります。例えば"^[Aa]*$"のような
準12連が出現する確率は、

p = pow(2.0/64.0, 12)

となります。

>>791
>>基本的な流れ
これだと、あるパターンが複数行で当てはまる際重複して数えてしまうような……
「当てはまる全パターン」を正確に計算するのはカナリ厳しいことがよく分かりました
>位置と固定長文字列の組み合わせ
ほほう、なるほど。パーサを見直せば出来そうです
ただ、実際にトリップ検索スレに出てくる案件を見る限りでは、
「.」とか「*」とかとかを使う機会は無さそうですね……
>>794
あーいや、こちらが言うところの「準X連」とは、正規表現では「*[Aa][Aa][Aa]*」みたいなもののことです
(これが「純X連」になると、「*AAA*」となります)
もちろん「^[Aa][Aa][Aa]*」から「*[Aa][Aa][Aa]$」まで虱潰しに出して合計してみてもいいのですが、
そうすると「BGCAAAAAAfgt」みたいなものが重複ヒットしてしまうようで……
足し引きしてなんとかすることにします

確率計算での参考:
http://www.geocities.jp/trip_chaser/tripdata.html