【トリップ検索】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版で動かしてますが問題なしですよ
ばっちり動いてます