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

こちらはMERIKEN's Tripcode Finderの本スレです。動作報告・質問・要望等は
こちらでどうぞ。

MERIKEN's Tripcode Finder(旧CUDA SHA-1 Tripper MERIKEN's Branch)は
2013年1月現在で最速の12桁トリップ検索プログラムです(最高速の記録は
7428.97M tripcodes/s)。CUDA対応のNVIDIAのビデオカード、もしくは
AMD Radeonシリーズのビデオカード等のOpenCL対応デバイスを使用すれば
非常に高速に検索を行うことができます。特徴は以下の通りです。

・ビデオカードのGPUによる超高速検索。
・CPUによる高速検索。
・GUIとCUIの両方に対応した柔軟なユーザーインターフェース。
・正規表現によるターゲットの指定。
・漢字等のShift-JIS文字を含むキーの探索。
・ヒット率、ヒットまでの平均時間等のさまざまな情報の表示。
・ターゲットの数の制限の撤廃。
・10桁トリップ検索への暫定的対応(CPUとNVIDIAのビデオカードのみ)。
・検索速度の実行時の最適化。
・GPLv3で公開されたソースコード。

■入手先
◆MERIKEN4.kのウェブサイト
http://www.meriken2ch.com/programming/merikens-tripcode-finder

■前スレ
【トリップ検索】MERIKEN's Tripcode Finder
http://anago.2ch.net/test/read.cgi/software/1348565078/

■過去スレ

初代 http://anago.2ch.net/test/read.cgi/software/1311428038/
無印 http://anago.2ch.net/test/read.cgi/software/1348565078/

■動作報告用のテンプレ

【GPU】
【CPU】
【OS】
【バージョン】MERIKEN's Tripcode Finder x.xx
【トリップの種類】12桁・10桁
【1SMあたりのブロックの数(CUDA)】
【1CUあたりのワークアイテムの数(OpenCL)】
【1WGあたりのワークアイテムの数(OpenCL)】
【1GPUあたりの検索プロセスの数(OpenCL)】
【1検索プロセスあたりの検索スレッドの数(OpenCL)】
【CPU検索スレッドの数】
【その他のオプション】
【Display Driver】
【10分間の平均速度】tripcodes/s
【GPUの平均速度】tripcodes/s
【CPUの平均速度】tripcodes/s
【GPUの使用率】%
【GPUの温度】℃
【その他】

■最高速の記録

以下は2013年1月現在における検索速度の最高記録です。

> 810 ： ◆MERIKEN4.k ：sage ：2012/12/09(日) 18:29:54.81 ID:D9EB7VO00
　　　　:
> 【GPU0】DIAMOND 6990PE54G Radeon HD 6990 4GB @ 900MHz (OC)
> 【GPU1】Gigabyte GV-R7970C-3GD Radeon HD 7970 @ 1120MHz (OC)
> 【GPU2】DIAMOND 6990PE54G Radeon HD 6990 4GB @ 900MHz (OC)
> 【CPU】AMD Phenom II X6 1100T (定格)
> 【OS】 Microsoft Windows 7 64bit SP1
> 【バージョン】MERIKEN's Tripcode Finder 0.07 Beta 1
> 【トリップの種類】12桁
> 【1SMあたりのブロックの数(CUDA)】N/A
> 【1CUあたりのワークアイテムの数(OpenCL)】自動
> 【1WGあたりのワークアイテムの数(OpenCL)】自動
> 【1GPUあたりの検索プロセスの数(OpenCL)】1
> 【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
> 【その他のオプション】-g
> 【Display Driver】Catalyst 12.11 Beta8
> 【10分間の平均速度】7428.97 tripcodes/s
> 【GPUの平均速度】7428.97 tripcodes/s
> 【CPUの平均速度】N/A
> 【GPUの使用率】97〜99%
> 【GPUの温度】83〜93℃
> 【その他】GPUのみ。
http://anago.2ch.net/test/read.cgi/software/1348565078/810n

テンプレは以上です。またよろしくお願いします。

【GPU】GeForce 610M
【CPU】Intel Core i5-3210M @ 2.5GHz
【OS】Windows 7 Ultimate SP1 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】256
【その他のオプション】なし
【10分間の平均速度】 79.20Mtripcodes/s
【GPUの平均速度】 48.81Mtripcodes/s
【CPUの平均速度】 30.40Mtripcodes/s
【その他】5完1タゲ

>>928に比べて4%ほどの速度上昇(CPUは8%)、か

Core 2 DuoでもAlpha 2の速度を測定してみました。
同じ条件でSHArp Tripper 1.1は13.57M TPSだったので、
まあ32bit OSでもAlpha 2の高速化の分だけMTFのほうが速くなったと
差し支えないと思います。

【CPU】Intel Core 2 Duo T9550 @ 2.66GHz (定格)
【OS】 Microsoft Windows 7 XP 32bit SP3
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
【トリップの種類】12桁
【CPU検索スレッドの数】自動(2)
【その他のオプション】なし
【10分間の平均速度】16.19M tripcodes/s
【GPUの平均速度】N/A
【CPUの平均速度】16.19M tripcodes/s
【その他】CPUのみ。5完1タゲ。

>>6
まあ落ち着いてｗ しかし今回のバージョンアップの効果はCPUによって
まちまちみたいですねえ。流石にIntelの石ではPhenom II X6みたいに
遅くなったりはしないでしょうけど…

>>8
ところがぎっちょん、AMDでも速くなった事例が発生しました……(但し結構古いCPU)

【CPU】Athlon X2 QL-64 @ 2.1GHz
【OS】Windows 7 Ultimate SP1 32bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 1→2
【トリップの種類】12桁
【10分間の平均速度】 3.40→4.65Mtripcodes/s
【その他】5完1タゲ

新スレで初めてツール知って落としてみたけど、何となく扱いやすそう。
情報集めてるなら、alpha1と2で、10分ずつ稼働させて比較してみればいいのかしらん。グラボ載ってないからCPU稼働だけど…

【CPU】Intel Core Duo T2500 @ 2.0GHz
【OS】WinXP Pro SP3 32bit
【バージョン】0.08 Alpha 2 CUI
【トリップの種類】12桁
【10分間の平均速度】7.86 Mtripcodes/s
【その他】5完1タゲ

なんと2割以上の速度上昇 ヽ(´Д｀)ノ

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows XP Professional 32-bit SP3
【バージョン】MERIKEN's Tripcode Finder GUI 0.08 Alpha 1→2
【トリップの種類】12桁
【10分間の平均速度】 6.41→7.77Mtripcodes/s

2割ほど強化されたらしい。…これで良いのかしら

なんとなく作ってみた。
Ver速度
0.0147.21M
0.0246.84M //正規表現に対応
0.03b156.53M //ここからCPUも利用するように
0.0458.74M //CMDオプションの説明でReadmeが長くなる
0.0558.80M
0.06a159.53M //64bit版が登場
0.06b159.58M
0.0659.58M
0.07a158.21M //OpenCLへの暫定的対応
0.07a258.04M(G48.69M/C 9.34M) //GPU・CPU毎の平均も表示
0.07a358.13M(G48.80M/C 9.33M)
0.07a462.94M(G53.64M/C 9.30M) //Intel HD Graphicsに対応
0.07a562.68M(G53.43M/C 9.25M)
0.07a662.68M(G53.42M/C 9.25M)
0.07a759.62M(G48.87M/C10.75M) //CPU高速化、IntelHDGを排除
0.07b159.64M(G48.81M/C10.83M)
0.0759.71M(G48.88M/C10.83M)
0.08a173.35M(G48.79M/C24.56M) //CPUの大幅な高速化
0.08a278.95M(G48.79M/C30.16M) //CPUの高速化

・全て12桁検索、平均値
・実行時間はいずれも5分程度(0.084 hour)
・「すっきり!!デフラグ」というソフトですっきり実行している
(つまり常駐ソフトは排除済み)
・CMDオプションは「-g -x 256 -c」で固定

物理32coreは無理ですけど、手持ち環境でそれぞれのバージョンを比較してみました

【CPU】AMD FX-8350 @4.95GHz
【OS】 Microsoft Windows 7 64bit
【トリップの種類】12桁
【CPU検索スレッドの数】自動(8になるのかな？)
【その他のオプション】なし
【その他】CPUのみ。5完1タゲ。

0.07
【CPUの平均速度】53.72M tripcodes/s
0.08 Alpha 1
【CPUの平均速度】114.78M tripcodes/s
0.08 Alpha 2
【CPUの平均速度】106.65M tripcodes/s

こちらの環境では、Alpha1、Alpha2で逆転現象は見られますが、00.7からはおおよそ50%の高速化は成されています
OpenCLの最適化、楽しみにしております

んにゃ
2倍の数値になってるから100%か

>>11
Intelの石だとちゃんと最適化の成果が出ているようですねえ。

>>10
>>12
それで問題ないです。情報提供、ありがとうございます。

>>13
GPU検索はもうちょっと速くなる予定です。期待してて下さい。

>>9
>>14
Alpha 2で遅くなるのはどうやらPhenom以降らしいですね。
CPUIDの仕様をみてゲンナリしたので、実行時に速度を計測してAlpha 2の最適化を
適用するかどうかを判断させることにします。しかしBulldozerはさすがに
速いですねえ。整数演算だけだったらCore i7-3770Kといい勝負ができてますね。

>>16
>実行時に速度を計測
CPUIDで決めつけるよりは安全だと思いますよ
ただ、場当たり的な対策な気もしますが

GPUがこれ以上速くなったら俺でも100M/s超えるかもﾜｰｲ

>>17
将来どんなアーキテクチャが出てくるかわからないのでこれでいいんですよ。
手元にないハードウェアのために性能の良いソフトウェアを書くのは難しいのです。

とりあえずAlpha 2の最適化を使用するかどうかを実行時に決定できるように
なりました。あとはCUDAのときと同じ要領で実行時に速度を測定して
最適なアルゴリズムを選択できるようにしてやるだけです。

う〜ん、なかなかうまくいかないなあ…
動的な最適化のためにループをもう一段回深くしたら速度が落ちてしまいました。
多分コンパイラの最適化を邪魔してしまってるんだろうけど、これは困った。

元はといえばGetTickCount()の精度が悪すぎるのが原因といえば原因なんだけど、
これってなんとかならないのかしらん。

>>20
つ「timeGetTime」

>>21
あ、その節は貴重な資料を本当にありがとうございました。
経過時間の測定は次の方法で何とかなりました。
http://stackoverflow.com/questions/2150291/how-do-i-measure-a-time-interval-in-c
一応最適化のルーチンは動いているようなので、あとは微調整をしてやるだけです。

>>20-22
まさか時間測定をGetTickCount()でやっていただなんて……
ところで、QueryPerformance系命令ははCPUクロックが動的に変化する場合、
「OSによっては値が信用できなくなる」なんてこともありえますゆえご注意を……
参考:
http://d.hatena.ne.jp/shiku_otomiya/20100218/p1
http://d.hatena.ne.jp/shiku_otomiya/20100504/p1
http://d.hatena.ne.jp/shiku_otomiya/20100917/p1

3,300円につられてWin8にするんじゃなかった・・・HD4000系つかえないのね。
なのでQuadro FX4800 (GTX265級）CUDAでWin8をやってみました。

【GPU】Nvidia Quadro FX4800 x2
【CPU】Xeon E5540 x1
【OS】Windows 8pro
【バージョン】MERIKEN's Tripcode Finder 0.08alpha2
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】auto (16)
【1CUあたりのワークアイテムの数(OpenCL)】
【Display Driver】310.90
【GPUの平均速度】330 tripcodes/s
【CPUの平均速度】50 tripcodes/s

抜ける時に固まってしまうので、GPUのみにした方がいいか・・・。

>>23
なるほど、こんなこともあるんですね。いやあ、助かりますｗ
そのせいかどうかわからないんですけど、動的な最適化は
完全には安定していないようです。やっぱりtimeGetTimeを使ったほうが
いいのかしらん。

あと色々コードをいじって気づいたんですが、Phenom IIで遅くなる原因は
どうやら命令のオーダーにあるようです。うまく命令のオーダーを
調節してやれば実行時の最適化は必要なくなるかもしれません。
ちょっとこれから用事があるので、また後で試してみます。

>>24
いや・・・Ver.0.07 alpha 7以降HD4000使えなくなったというのが俺の認識
(過去ログ見れば分かるが対応が難しいからだそう)

その分Ver.0.08 alpha 1以降CPU検索がグッと速くなってるからそっちで補えるけど

>>27
あらら。二重の意味でNGなんですね。AMDもHD2K3K4Kは去年の8月から
切っちゃってて、Win7までしかドライバ出てなかったんです。

Nvidiaがあるからいいや、みたいなのりでWin8にしてしまいましたが
HD4000も過去帳入りですね・・・。

【CPU】i7-3970x(OC 5.04GHz)
【OS】 Microsoft Windows 7 64bit
【トリップの種類】12桁
【その他のオプション】全てDL時のまま
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
【CPUの平均速度】186.21M tripcodes/s


さっきよりもうちょっと速くなったｗｗ
早すぎワロチｗｗｗ

>>28
>AMDもHD2K3K4K
え、AMDにもIntel HD Graphics 4000みたいなのあるの……？
ひょっとしてRadeonの方言ってる？？
>>6でも書いてるけど、自分はCorei5+GeForce環境だから、
CPU検索が遅い際にはMERIKENでゲフォ+HDG4000を使い、
SHArp TripperでCPUを使っていたんだ
でもVer.0.08以降CPU検索が速くなったからSHArp要らない→両方MERIKENでおｋになった
決して「MERIKENシリーズではRadeon HD 4000シリーズは使えない」って意味じゃないからね！

>>29
これも滅茶苦茶速いですねえ。たしかこれ、Sandy Bridgeですよね。
OCでここまで回せるとは…

実行時の最適化はなかなか安定してくれません。
まあ各検索スレッドがてんでバラバラに速度を測定してるので
仕方がないといえばそうなのですが…
とりあえずtimeGetTimeを試してみて、これが駄目だったら
また別の方法を考えて見ることにします。

計測用に別の実行ファイルを用意してそちらでテスト
　->設定書出
　->本体で設定ファイル読み込んで以下略

な感じで回避できないの? >>20

>>31
さすがにXeon２個には勝てないけどなｗｗ

>>33
別の実行ファイルを用意しなくても、テスト用のルーチンを別に作成すれば
恐らく大丈夫なはずなんですけど、出来ればこれ以上複雑にしたくないんですよね。
でもそれ以外方法がないような気がして来ました。

テスト用のルーチンを切り出してみたんですけど、それでも
実行時の最適化はうまくいきません。謎です。
まあ最悪オプションで切り替えるようにしてやればいいんですけど、
どうもスッキリしません。

う〜ん、どうやら単一のスレッドで速度測定用のルーチンを呼び出した場合と
複数の検索スレッドを同時に走らせた場合ではCPUの挙動が違ってくるようです。
仕方がないのでデフォルトではAlpha 2の最適化を有効にして、オプションで
無効にできるようにしてやることにします。あまり綺麗な解決方法とはいえませんが、
まあ仕方がありません。

というわけでGUIとCUIの両方に最適化を無効にするオプションを追加しました。
あとついでにデフォルトでGPUとCPUで同時に検索するようにしました。
これまでは正直なところCPU検索はおまけとして扱っていたのですが、
今回のアップデートでようやくちゃんとした戦力になってくれそうです。

次の予定ですが、今ちょうど開発機に580が入っているので、長い間ほったらかしに
なっていた12桁トリップ検索のCUDA版の最適化に取り組むつもりです。あのマクロの
嵐に手を入れるのはちょっと気が重いのですが、ちゃんとCPUで動いているルーチンが
すでにあるのでまあ大丈夫でしょう。

おつですおつです

どもども。CUDA版のソースを眺めていたのですが、まあ特に最適化を適用するのに
問題はないようです。一番問題になりそうなのは、カーネル内で変化させることが
できるのはSHA-1の入力ブロックの最初のワードだけという制約ですが、これも
ブロック数の最大値を128に引き下げてやれば特に問題は無さそうです。少し残念な
気もしますが、最適化の恩恵はそれを補って余りあるはずです。PW[]をCPU側で
__constant__メモリ空間に用意してやれば問題ないでしょう。

うわ〜PCが落ちてSSDが壊れてAlpha 2からの更新した分がパーになってしまったorz
幸い一番面倒くさかったGUIの部分は無事だったみたいだからまあいいか…

>>42
SSDはシステムファイルだけにしておけとあれほど……
「面倒」ってことは遂に個別GPU云々機能を実装したんですね!?

>>43
いや、そっちはまだ手付かずですｗ テストも含め数週間の作業になるはずなので
やるとしても当分先ですね。

ようやくこれまでの作業の復旧が出来ました。なくした部分は書きなおしたのですが、
流石に2度目だと大分楽ですね。CUDAのプログラミングは久しぶりだったので
忘れてたのですが、システム全体を巻き込んで落ちることが多いので気を
つけなきゃいけませんね。

気を取り直してCUDA版の作業を続けることにします。
これまではカーネル内部でkey[7]〜key[11]の5バイトを回してキーを生成していたの
ですが、最適化のためにはこれをkey[0]〜key[3]の4バイトを回すように変更しなければ
なりません。PCが落ちたときにはこれがうまくいかずに行き詰っていたのですが、
もう一回試して見ることにします。

あ、うまくいかなかった原因が分かったかも…
これやっぱり4バイトで回すのはかなりしんどいですねえ。

あ、でもPW[]をカーネル内部で計算して共有メモリに入れて使えばいいのか。
う〜ん、なかなかいい思いつきかも…

考えがまとまってあとはひたすらコードを書くだけなので、
今日はここまでにしておきます。いや〜続きが楽しみだなあ。

とか何とか書いておきながら、また待ちきれずに残りの作業を終わらせて
しまいましたｗ CPUほどではないですが、確実に速くなってます。
定格のGTX 580で719.38M TPS出ているので、以前のバージョンに比べて
とりあえず5%強の速度向上といったところです。やっぱり共有メモリを
使っている分だけオーバーヘッドがあるのかしらん。もう少し色々いじって
速度が上がらないか試してみます。

あのあと命令のオーダーを変えたりしていたら大化けして、速度は760.96M TPSまで
上がりました。前のバージョンに比べると11%の速度向上です。GPGPUなので
流石にCPUのようにはいきませんでしたが、CUDA版のスピードが上がるとは
ちょっと前までは全然思っていなかったし、ようやくHashcatより速度が出るように
なったので、個人的にはかなり満足です。

radeon超えは無理か…

気持ちはわからないでもないですけど、そりゃさすがに無理ですｗ
基本的なGPGPUの性能が全然違いますからねえ。
それに今回実装したのは、前スレで紹介されていたHashcatのJens氏による
最適化の手法で、これを使えばRadeon版も10〜20%高速化出来るはずです。

もっと一般的な話をすると、トリップ検索の速度の上限はJohn the Ripperや
Hashcatなどのパスワード解析プログラムの速度を見ればだいたい分かる
ようになっています。(トリップ検索のほうがパスワード生成の手間がない分
速いですが) MTFの12桁トリップ検索のこれらのプログラムより多少速いので、
実際かなり頑張っているほうです。JtRやHashcatの開発に携わっている人達は
相当頭がいいので、今後この人達を出しぬいて大幅に速度を上げるのは
至難の業でしょう。

あのあとCUDAの最適化したSHA-1のルーチンをぺたぺたとOpenCL版に
貼り付けて動かしてみたのですが、7970では効果がかなりあったものの、
5770と6990では逆にかなり遅くなるという、なんとも微妙な結果になりました。

まあ7970 1枚で2868M TPS出ていて12%速度が向上しているので成功と
いえなくもないのですが、他のカードで遅くなる原因がさっぱりわかりません。
やっぱり共有メモリより__constantを使ったほうがいいのかしらん。
もうちょっと色々調べる必要があるみたいです。

>>30
おぅ・・・ATIと言うべきでした。そのとおりRadeon HD4000系です。
夕べXP32でも試してみたのですが、やはりNGでして。
Radeon 5870やNvidia 450GTSなどは動いてくれるのですが。
またちょっとｺﾞｿｺﾞｿしてみます。

>>56
あ、Radeon HD 4xxxシリーズでは動かないです。
OpenCL 1.1に対応していなかったはずです。
READMEを書きなおしておこうっと。

試しにCUDA版のPW[]を共有メモリではなくコンスタントメモリに
入れてみたんですけど、かえって速度は低下してしまいました。
面白いもんですね〜

他のソフトでCUDA関係の不具合に有ってたんですが、検索でCUDAテストだのベンチマークで検索かけてもそれっぽいソフトってあんまり無いところ、
たまたま見たこのスレで神ソフト発見！
作者さんも居るしようですので、お礼。
作者ﾀﾝありがとう！
お陰で問題の切り分けが出来ました〜。

CUDAテストアプリ、CUDAベンチマークアプリとしてももっと宣伝しても良いと思う〜。

>>57
あ。そうなんですね。OpenCL対応でないとイカンと。そりゃそうだ・・・。
ありがとう御座います。
RadeonHD5450で30M、5870で800-1000M でした。

>>59
どもども。なんせハードウェアの性能を最後の一滴まで搾り取るために
全力を挙げてますからねｗ お役に立てて何よりです。

>>60
Radeon HD 4xxxはOpenCL 1.0対応で、MTFで使ってるOpenCL 1.1の機能が
使えなかったはずです。5870はやっぱり結構速度が出てますね〜

>>59
CUDAスレに発展(?)する可能性が微レ存……？

CUDAスレは別にあるので、CUDA一般の話はそっちでしたほうがよいでせう。

試しにOpenCL版のPW[]をコンスタントメモリに移してみたのですが、
やっぱりというか速度は落ちてしまいました。
今回の最適化はHD 7xxx以降限定ということになりそうです。
というかまたオプションを追加しなきゃならんのかorz

最強のツールを目指す上で避けて通れない苦労です（他力本願）

【CPU】[email protected] x2
【OS】Win7Pro64SP1
【トリップの種類】12桁
【その他のオプション】 -c
【その他】5完1タゲ

【バージョン】0.08 Alpha 1 CUI64
【30分間の平均速度】195.90 MTPS (HT off)
【40分間の平均速度】221.01 MTPS (HT on)

【バージョン】0.08 Alpha 2 CUI64
【40分間の平均速度】180.06 MTPS (HT off)
【40分間の平均速度】250.01 MTPS (HT on)


Σ(ﾟДﾟ；) HT offだとAlpha2の方が遅いだと・・・。
0.06a1ではHTのon/offの差は5%程度しか有りませんでしたが、今回は結構差が出てますね。
Phenomの件と言い、今回の最適化はハード依存が大きいのでしょうか?

>>28
>AMDもHD2K3K4Kは去年の8月から
>切っちゃってて、Win7までしかドライバ出てなかったんです。

違います。
ドライバ更新が半年に1回になっただけです。
先日ドライバ出てます
13.1 Windows 7/Vista drivers for 4000,3000,2000 Series are now live:
http://support.amd.com/us/gpudownload/windows/legacy/Pages/legacy-radeonaiw-vista64.aspx

>>66
貴重な報告、ありがとうございます。大変参考になります。

> Phenomの件と言い、今回の最適化はハード依存が大きいのでしょうか?

そうみたいですねえ〜 そんなつもりはまったくなかったんですけど…
純粋に計算量は減っているので遅くなる理由がわかりません。
命令のオーダーを見なおして大分ましになりましたが、
それでもまだPhenom IIだと最適化を切ったほうが多少速いです。

あ、あと命令のオーダーを見なおしたせいでCore i7-3770Kでは1M TPSほど
速くなりましたｗ

後これは全く関係ないんですけど、>>54を書いた後で6990だとHashcatのほうが
かなり速いことに気づきましたｗ MTFでは7970に合わせたせいでベクトル型を
使っていないのが原因と思われます。というわけで、HD 6xxx以前だと
まだかなり早くなる可能性が大です。

というわけでいい機会なので、OpenCLのカーネルをGCN (HD 7xxx以降)と
非GCN (HD 6xxx以前)で分けることにしました。こうすれば余計なオプションを
増やさなくて済むというのも大きいですｗ

>>65
一見してよくわかんないオプションがずらずら並んでるのって好きじゃないんですよね〜
クリックひとつで何も考えずに使えるのが理想ですｗ

>>70-71
RadeonはVLIWからGCNへの移行の最中ですし、
かなりアーキテクチャが異なるので大変ですね。

VLIWではまだ速くなるということはAPUがさらに凄いことになりそうですｗ

前スレ落ちたのでここに書くか。
配布パッケージに32bitのOpenCL.dllだけが入ってるんだが、
これはこれでいいのか？

まあ、実行できる環境もないし、プログラムの構造も知らんのだが。ｗ

OpenCLのソースファイルを2つ用意して、HD 6xxx以前では
最適化が無効になるようにしました。試しに速度を測定したら、
これまでの最高速の記録に綺麗に250M TPSほど上乗せできています。
あとはVLIWなRadeonでベクトル型を試してみるだけですが、
こちらは大化けする可能性があるので実に楽しみです。

>>73
最初から分けて開発していればよかったんですけど、VLIWでも結構性能が出ていたので
ここまでズルズルと来てしまいました。

>>74
あれはOpenCL.dllが原因ですか。たいていの環境ではOpenCL.dllはSystem32に
入ってるので、パッケージのはほとんどの場合必要ないのです。しかし弱ったなあ…
他にいい手が思いつかなかったら64bit版もパッケージに同梱することにします。

>>67
おう、嘘つきました。スマヌ。＆さんくす。

>>76
原因【かもしれない】と【思っただけ】だ。ｗ
だから試してみては、と書いたわけで。

いや、どうせdepend(rなんかやってみないだろうと思ってたんだが、
質問者はちゃんとやったし俺もやってみたんだよ。

そしたら、x64に混ざってx86なのがあって、それがOpenCL.dllだったと。

そもそも同梱する必要あるのか？ランタイムをインストールさせるべきじゃないのか？
的を外してたらすまん。ｗｗｗ

>>78
>ランタイムをインストール
だが待ってほしい
VCランタイムぐらい巨大ならともかく、1つや2つのDLL同梱で解決できるなら
その方が気軽に検索できるのでは？

>>78
> ランタイムをインストールさせるべきじゃないのか？

CPUだけで使う場合だと本当に必要なのはOpenCL.dllだけなんですよね。
適当なOpenCLのランタイムがあればそれをインストールしてもらうところなんですけど、
Intelのはインストーラーが英語しかないので普通の人には敷居が高いかなと思って…
この件はもうちょっと対応を考えてみます。

ランタイムが入ってないというのは2011年代の古いドライバ使ってるのかな？

あ、Intelの話か
Catalystと勘違いした

どの会社のでもいいのでOpenCLのランタイムがあればOpenCL.dllを同梱しなくて
済むんですけど、そういうわけにもいかないようで…

Intel プラットフォームを使ってんのか？
だったらそれだけじゃ動かないと思うんだが？？？？

私ぼけてきてるのカナ？

Intelのは例としてあげただけで、とにかくなんでもいいので
OpenCLのドライバがシステムに１つインストールされていれば
適当なOpenCL.dllがインストールされるので、自前でOpenCL.dllを
同梱する必要が無くなるということなんですけど…

OpenCLデバイスを使用しない場合でもOpenCL.dllがないとMTFが
動かないのが問題といえばなんですが。

VLIWなRadeonの最適化ですけど、どうやら効果はかなりあるようで、
とりあえず1タゲのルーチンだけ作ってテストしてるのですが、
6990で1.27倍、5770で約1.5倍の速度が出ています。
他のルーチンを作りこむのにちょっと時間がかかりそうですが、
なかなか期待できそうです。

あれから色々試してみたんですが、ベクトル型を使うと
どうやっても前方一致と後方一致以外の検索の速度が
遅くなってしまいます。まあ恐らく殆ど使わない機能なので
今回は割りきってしまうことにします。

VLIWなRadeonのための最適化の作業も終わったので、
ひと通りテストしてから新しい開発版をうｐすることにします。

新しい開発版です。

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

主な変更点は12桁トリップのGPU検索の高速化です。
10〜50%ほど速度が上がっているのでぜひ試してみてください。

乙です

【GPU0】SAPPHIRE Vapor-X HD5870 @ 875MHz
【GPU1】ASUS EAH5870 @ 850MHz
【CPU】Intel Core i7-2600K @ 3.4GHz
【OS】Microsoft Windows 7 Home Premium 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 3
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】N/A
【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【CPU検索スレッドの数】自動
【その他のオプション】N/A
【Display Driver】Catalyst 13.1
【10分間の平均速度】3149.69M tripcodes/s
【GPUの平均速度】3078.46M tripcodes/s
【CPUの平均速度】71.23M tripcodes/s
【GPUの使用率】未計測
【GPUの温度】未計測
【その他】5完1タゲ。TEST/

>>89
確かに50%ほど速度が上がっています。速すぎてゲロ吐きそうになりました。
実際のヒット率と予測の差もほぼ0%です。

>>74>>76
なんかやっかいなことになってしまいまして、申し訳ありません。
あれから、クリーンインストールして忍法帖レベルが１に・・・。
ちなみにOpenCL.dllはSystem32及びSysWOW64には用意されていません・・・。

>>92
やっぱそうでしょうね。CPUとビデオカードは何を使っていますか?

>>91
う〜ん、素晴らしい… やはりHD 5xxxに一番効果があるみたいですね。

> 速すぎてゲロ吐きそうになりました。

開発者冥利に尽きるというものですｗ

>>89
【GPU】GeForce 610M
【CPU】Intel Core i5-3210M @ 2.5GHz
【OS】Windows 7 Ultimate SP1 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 3
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】256
【その他のオプション】SHA-1最適化ON
【10分間の平均速度】 87.17Mtripcodes/s
【GPUの平均速度】 55.61Mtripcodes/s
【CPUの平均速度】 31.56Mtripcodes/s
【その他】5完1タゲ

>>6と比べて10%もの速度上昇だと!?

>>95
だからちゃんと速くなるといったでしょうｗ
なかなか順当な伸びですね。

現在検索君1号の調整中。Alpha 3で効率が上がったせいで、OC耐性は下がるという
よくわからないことになっています。なんとか通常の検索業務ｗで8.8G TPSあたりで
安定してくれるといいのですが…

8.8G TPSじゃなくて7.8G TPSでした。しかし10G TPSの壁は遠いですねえ。

HD7970をﾎﾟﾁることに決定しました・・・感謝。
【GPU】GeForce580 + RadeonHD5450 (310.90 & 13.1 driver)
【CPU】Intel Xeon W3520 2.66MHz
【OS】Windows 7 Pro SP1 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2&3
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】自動
【2分間の平均速度】 790.11->889.57Mtripcodes/s
【GPUの平均速度】
CUDA0 723.8 -> 808.3TPS
OpenCL0 17.5 -> 27.2TPS
OpenCL1 18.5 -> 28.6TPS
【CPUの平均速度】 45.75 -> 48.18Mtripcodes/s

>>99
速度の向上はおおよそ予想通りと言ったところですね。安心しました。
7970は素晴らしいGPUです。1GPUで3G TPS近く出るとか、色々おかしいですｗ

あの後多ターゲット時の処理を見なおして、12桁トリップ検索の
128ターゲットでの検索速度をCUDA版で9%、OpenCL版で5%ほど改善することが
出来ました。実際に使用する際にはこれはかなり大きいです。
いや〜、改善できるところってまだまだあるもんですねえ。

というわけで1日も経たないうちに新しい開発版をうｐしましたｗ

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

主な変更点は12桁トリップのGPU検索の多ターゲット時の高速化です。
今回の変更は某所での指摘を受けた予定外のものでしたが、
コードを見なおす良い機会になりました。

取りあえず今回はかなり大幅な変更をおこなったので、
バージョン0.08での機能追加はここまでにしておきます。
特に問題がなければAlpha 4をそのまま安定版にする予定です。

>>102
明日、ネカフェPCでギュンギュン回してみますわ

まだ新マシンの設定詰めている最中ですが、OCCTでは電力リミッターがかかりまくりなのでMTFも試してみました。
MTFもCSTと同様にメモリアクセスは極力避けるようになっているのですよね？
今まで使っていたGeForceと異なりメモコン使用率が見れないのは地味に不便ですｗ

Radeon HD 7950、Windows 8 64bitの環境で、OpenCLの12桁版をデフォルト設定でGPUのみで動かしています。
Catalyst 13.1で、OverDriveオフ、電力コントロール+0%、最大コアクロック800MHzのほぼデフォルトの設定です。

OCCT - 259W （リミッターでコアクロック低下）
MTF 0.07 - 約1594Mt/s - 約239W （リミッターかからず）
MTF 0.08 alpha3 - 約1794Mt/s - 約244W （リミッターかからず）

といった感じでした。

>>97
OC設定のチェックはどうやってされているのでしょうか？
メモコンにはあまり負荷がかからず、コアに負荷がかかるようなテストツールがあればいいのですけど。

>>100
そんなことを聞くとHD7970の投売りを見過ごしたことを後悔してしまいますｗ
でもやはりリテール版のHD8950が出るのを待ちます、それまで我慢しますｗ

>>102
乙です、更新速すぎですｗ
GUIでバージョンが表示されず不便に感じていましたが、タイトルに含まれるようになったのですね。

>>102乙です！
ということで早速テストテスｔ……ファ！？
【GPU】GeForce 610M
【CPU】Intel Core i5-3210M @ 2.5GHz
【OS】Windows 7 Ultimate SP1 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 3
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】256
【その他のオプション】SHA-1最適化ON
【10分間の平均速度】 87.10Mtripcodes/s
【GPUの平均速度】 55.27Mtripcodes/s
【CPUの平均速度】 31.82Mtripcodes/s
【その他】5完1タゲ

……気を取り直して。alpha3とaplha4とで、普段回している多タゲ
(現在371893パターン、1009チャンク、8〜12文字検索)で測定し直すと、
75.33M[51.89M@GPU/23.44M@CPU]→78.59M[54.91M@GPU/23.67M@CPU]
となりました。4%の速度改善です。ﾔｯﾀﾈ！

ついでにもう一つ。ネットワーク対応云々前スレで言っていた気がしますが、
自分の大学のオープンスペース全体で0.08 alpha 3を走らせた場合を適当に試算すると、
12.75MTPS(Dual Core E2180)×334+17.77MTPS(Core 2 Duo E7200)×100≒6.0GTPS
になりました……400台超えてるのにHD7970×2に勝てない不思議！

あ、tripcodes.txt(出力ファイル)への排他処理を追加するだけで、
「共有フォルダに置いて複数マシンで走らせる」的な意味でネットワーク対応できますよ！多分！

　.. .: ∬ ::::: ::: :::::: :::::::::::: : ::::::::::::::::::::::::::::::::::::::::::: 　 　 　 　
　　　　　　　 ∧＿∧ . |||.: : : ::: : :: ::::::::: :::::::::::::::::::::::::::::
　　ｽﾄﾝ 　 /:彡ミ゛ヽ;)ー､　. . .: : : :::::: :::::::::::::::::::::::::::::::::　なんで>>107を「Alpha 4」にしてなかったんだろう俺
　　　　||| / :::/:: ヽ、ヽ、 ::i . .:: :.: ::: . ::::::::::::::::::::::::::::::::::::::: 　
　　 　　 / :::/;;: 　 ヽ　ヽ ::ｌ　. :. :. .:: : :: :: :::::::: : ::::::::::::::::::　
￣￣￣（_,ノ ￣￣￣ヽ､_ノ￣

早くなっったけどGPU60〜70%だわ＠6990×2

前スレ986が今度は他アプリ止めてしっかり計測してみました

【CPU】AMD A10-5800Kデフォルト TurboCore ON(メモリDDR3-1600)
【OS】Windows 8 Pro 64bit
【トリップの種類】12桁
【その他】5完1タゲ
【その他のオプション】CPU設定デフォルト　OpenCL設定デフォルト
【Display Driver】Catalyst 13.2beta

【バージョン】0.07
　10分間の平均(Mtripcodes/s) CPU=19.38 GPU=236.12 OpenCL=252.85(240.26+12.61)

【バージョン】0.08 Alpha 1
　10分間の平均(Mtripcodes/s) CPU=41.54 GPU=235.51 OpenCL=266.90(242.99+23.91)

【バージョン】0.08 Alpha 2
　10分間の平均(Mtripcodes/s) CPU=37.61 GPU=236.17 OpenCL=265.42(242.82+22.60)

【バージョン】0.08 Alpha 3
　10分間の平均(Mtripcodes/s) CPU=44.66 GPU=192.02 OpenCL=216.70(191.86+24.89)

【バージョン】0.08 Alpha 4
　10分間の平均(Mtripcodes/s) CPU=41.56 GPU=188.31 OpenCL=216.17(191.40+24.78)

CPUだけ見ると0.08で倍化してますが、GPUの結果はかなり落ちてて、
OpenCLでは0.07を下回っています。最も成績がいいのが0.08 Alpha1ですね

Alpha3以降で11％程遅くなった…。

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows XP Professional 32-bit SP3
【バージョン】MERIKEN's Tripcode Finder CUI 0.08 Alpha 2→3→4
【トリップの種類】12桁
【10分間の平均速度】 7.87 → 6.98 → 6.97 Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）

回している間に新しいの来てたので3つ比較…Alpha3で速度が落ちて4でもそのまま。
検索条件の問題などもあったりするのでしょうか。


なんとなく、最速とは無関係の方向からもテスト。

【CPU】Intel Atom CPU N280（定格稼働）
【OS】Windows 7 Starter SP1
【バージョン】MERIKEN's Tripcode Finder CUI 0.08 Alpha 2→3→4
【トリップの種類】12桁
【10分間の平均速度】 3.03 → 2.41 → 2.40 Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）

こちらもAlpha3で低速化。
Logical Cores・Search Threadsの認識がおかしい気がする。１のはずが共に２と認識されてる（Alpha２〜４全て）。
２コアのメインマシンからexeその他をコピーした影響…なわけないよね…？
もし必要なら、Alpha1も回してみます。

>>105-106
GPUのグローバルメモリは遅いですからねえ。極力使わないようにしています。
OCの設定は実際にMTFを走らせて行なっています。

>>107-109
多ターゲットだと今回の最適化はそれなりに効果があるみたいですねえ。
ネットワーク対応もやってみたいけど、単体での性能に満足できるように
なった後ですねえ。

>>110
うちの検索君一号(6990x2+7970)も現在絶賛調整中です。
安定するようになったら報告します。

>>111
それはGPUの自動判別が上手く動いていないですねえ。
CUIで動かしたときに"OPENCL DEVICE"の"Name"と"Number of Compute Units"の
欄にはどのように表示されていますか?

>>112
CPU検索のルーチンはAlpha 3でかなり大幅に書き換えられたので、
その影響があるのかもしれません。後でAlpha 1のものに差し替えておきます。

検索速度が現象云々はCore系にはありませんよね……？
自分の経験上はVer.Up毎に性能はアップしているはずですので

ところで、ベンチマークしている時に思ったのですが、
5完で測定するのと6完、7完で測定するのとではどちらがいいのでしょう？
5完だと酉がポンポン生産されるので余計に速度が低下しそうですが、
自分で試したところどうも6完の方が遅い気がします。
後、CPU数を自動設定するより、コア数(HT含む)をそのまま設定したほうが速い気がするのですが。
(自環境では、5完1タゲで4コアに設定すると90.15M[55.14M@GPU/35.00M@CPU]出ました)

>>113
グローバルメモリは遅いというのに加えて、メモコンなのかメモリチップなのか分かりませんが
結構消費電力が増えてしまい、かなり高コストですね。

OCの場合は演算結果が正しいのか不安になりますが、ヒット率の予測との差で判断とかでしょうか？

>>111
調べてみたらA6, A8, A10はすべてGCNではなくてVLIWですね。
とりあえずOpenCLフォルダにあるMTF_CUI_OpenCL_SHA-1.clと
MTF_CUI_OpenCL_SHA-1_pre-GCN.clの中身を交換してやれば
Alpha 1よりはやくなるはずですｗ
>>114の質問に答えていただければ次の開発版で修正させて頂きます。

>>116
OCがうまくいかない場合はドライバーがエラーを返すか止まってしまうかどちらか
なので心配ないと思いますよ。これまでエラーが検出されずに演算結果が化けたことは
1回もありませんでした。

>>115
> 検索速度が現象云々はCore系にはありませんよね……？

そうなんですよねえ。最近のCPUではAlpha 3以降のほうが速いのです。
やっぱコードの差し戻しは止めておこうかな。

> 自分で試したところどうも6完の方が遅い気がします。

理論的には変わらないはずですが、実際の速度に違いはありますか?

> 後、CPU数を自動設定するより、コア数(HT含む)をそのまま設定したほうが
> 速い気がするのですが

これは環境によって随分違うのでなんとも言えないですねえ。

>>118
GPUでヒットした分はCPUでも検算しているのでしょうか？
だとすると完全なテストとは言えないかも知れませんが、GPUコアのOCがかなり捗りそうです。

OCCTでテストしていると、メモリアクセスの消費電力があるためか、すぐにリミッターがかかってしまいますし。
電力のリミットはある程度は変更できるのですが、それでも定格最大クロックより低いあたりで遷移して、
さらにシステム全体の消費電力が約40Wアップの300W程度になったりしますし・・・

電源ユニット自体には余裕があっても、グラボの補助電源のコネクタやケーブルそれにVRMの限界もありますしね。
何かの拍子にリミッターが狂って350Wを超えて電源が落ちた時はかなり焦りましたｗ

>>114
Ver0.07〜0.08 Alpha 1,2,3,4の全てのバージョンで
　Name：Devastator
　Number of Compute Unit 6

と表示されてます

前スレ 569, 732, 947 です。

【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.08 Alpha 4
【トリップの種類】12桁
【1CUあたりのワークアイテムの数(OpenCL)】3200
【1WGあたりのワークアイテムの数(OpenCL)】64
【1GPUあたりの検索プロセスの数(OpenCL)】1
【その他のオプション】 SHA-1最適化 ON
【Display Driver】Catalyst 13.1
【10分間の平均速度】949.87M tripcodes/s
【GPUの平均速度】853.22M tripcodes/s
【CPUの平均速度】96.65M tripcodes/s
【GPU使用率】99%
【GPUの温度】71℃ （開始時 32℃）
【その他】テスト時間10分0秒、7完1タゲ

前スレ 569 : MERIKEN's Tripcode Finder 0.07 Alpha 5
【10分間の平均速度】498.00M tripcodes/s (GPU 463.44 CPU 34.56)
前スレ 732 : MERIKEN's Tripcode Finder 0.07 Alpha 7
【10分間の平均速度】586.05M tripcodes/s (GPU 550.44 CPU 35.62)
前スレ 947 : MERIKEN's Tripcode Finder 0.08 Alpha 1
【10分間の平均速度】641.51M tripcodes/s (GPU 560.13 CPU 81.38)
今回 : MERIKEN's Tripcode Finder 0.08 Alpha 4
【10分間の平均速度】949.87M tripcodes/s (GPU 853.22 CPU 96.65)

>>115
自分が試した範囲では、ヒット数が多い場合はGPU, CPU共に5完より6完の方が早いです。
ヒット数が多いと画面表示やファイル書き込みなどのI/Oが多発するため遅くなるのかなと思っていました。

CPUの数は、GPUの負荷と数で変えています。
GeForceだとCPU負荷が小さいので、1GPUに付き-0.5コアとしています。480, 580, 590を同時に走らせる時は、コア数-2に設定しています。
TeslaだとCPU負荷が大きいので、1GPUに付き-1コアとしています。
余りCPUコア数を増やしすぎると、GPUの負荷が100%に張り付かず不安定になります。

ただマザボによって傾向が変わるので、ギリギリまで詰めた設定をしたいのなら、自分で納得の行くまで試行するしか無いでしょうね。

GPUのみでCUDA効果を確認。

【GPU】GTX590
【CPU】Xeon X5680 @3.33GHz x2
【OS】Win7Pro64SP1
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】192
【その他のオプション】-g -x 192
【Display Driver】310.70
【GPUの使用率】100%
【GPUの温度】90℃
【その他】HT on

【バージョン】0.08a2 CUI64
【40分間の平均速度】1070.16 MTPS

【バージョン】0.08a3 CUI64
【40分間の平均速度】1187.18 MTPS

丁度一割アップですね。

連投失礼します。
>>124のGTX590は、6完1タゲで実施しています。

【GPU】K20c
【CPU】Xeon X5680 @3.33GHz x2
【OS】Win7Pro64SP1
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】256
【その他のオプション】-g -x 256
【Display Driver】310.70
【GPUの使用率】N/A
【GPUの温度】N/A
【その他】HT on, 6完1タゲ

【バージョン】0.08a2 CUI64
【40分間の平均速度】705.20 MTPS

【バージョン】0.08a3 CUI64
【40分間の平均速度】832.18 MTPS

なんと二割近いアップ! さらなるアップが期待出来るかな?

Visual Studio 2012 + Intel C Compilerな開発環境があるのですが、これにToolkit 5をインストールすれば簡単にビルド出来るでしょうか?
簡単に済むなら、K20cを返す前に一度試してみたいなぁ。

GPUで1割、CPUで1割強UPって感じですかね。
On average, it takes が15年+から10年+にｗ

【GPU】SAPPHIRE HD7970 (OC: GPU 950MHz)
【CPU】Intel Core i7-980X 4.1GHz
【OS】Microsoft Windows 8 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【1CUあたりのワークアイテムの数(OpenCL)】960
【1WGあたりのワークアイテムの数(OpenCL)】64
【1GPUあたりの検索プロセスの数(OpenCL)】2
【その他のオプション】すべてデフォルト
【Display Driver】Catalyst 13.1
【10分間の平均速度】2476.39M tripcodes/s
【GPUの平均速度】2335.52M tripcodes/s
【CPUの平均速度】140.87M tripcodes/s
【GPU使用率】99%
【GPUの温度】83℃ （開始時 40℃）
【その他】テスト時間30分0秒、10完1タゲ

111ですが、>>117に書かれているように、
MTF_CUI_OpenCL_SHA-1.clとMTF_CUI_OpenCL_SHA-1_pre-GCN.clの
ファイル名を入れ替えて測定しなおしてみました

【CPU】AMD A10-5800Kデフォルト TurboCore ON(メモリDDR3-1600)
【OS】Windows 8 Pro 64bit
【トリップの種類】12桁
【その他】5完1タゲ
【その他のオプション】CPU設定デフォルト　OpenCL設定デフォルト
【Display Driver】Catalyst 13.2beta

【バージョン】0.08 Alpha 4 ファイル入れ替え後
　10分間の平均(Mtripcodes/s) CPU=40.60 GPU=335.79 OpenCL=358.27(334.23+24.04)

GPUの結果がファイル名入れ替え前に比べ30%もアップ。
0.07に比べてCPU結果の倍化の恩恵も受けていて最強の結果が出ました

>>120
OCによる異常の検出はもっぱらドライバだよりですけど、これまでそれで困ったことは
ありませんでした。検算は開発用に是非欲しい機能なんですけど、まだ手を
つけていません。

電源は結構重要ですよね〜 メインの検索用のPCを組み立てたときに電源は迷わず
Corsairの1200Wのものを購入したのですが、大正解でした。

HD5770 では動いている人が居るみたいですが、HD5750 では駄目なのでしょうか？
CPU のみで、GPU を使ってくれません。
どうすれば、CUDAとOpenCLの部分が淡色ではなくなるのでしょうか？

>>121
>>127
どうりで自動的に検出できなかったわけです。AMDの資料やWikipediaって
結構抜けがあるんですよね〜 あとで直しておきます。

> GPUの結果がファイル名入れ替え前に比べ30%もアップ。
> 0.07に比べてCPU結果の倍化の恩恵も受けていて最強の結果が出ました

それが本来の姿ですｗ お楽しみ下さい。

>>129
ちゃんと動くはずですよ。AMDの最新のディスプレイドライバは
インストールされていますか?
http://sites.amd.com/jp/game/downloads/Pages/downloads.aspx

>>124-125
CUDAではどのGPUでも10%ほど速度が上がっていますね。さすがの安定感です。
K20cで2割上がっているのはGPUの足回りが強いから何でしょう。
クセのない素直なアーキテクチャという印象です。GeForceシリーズでも
出してくれないですかね〜

> Visual Studio 2012 + Intel C Compilerな開発環境があるのですが、これに
> Toolkit 5をインストールすれば簡単にビルド出来るでしょうか?

なかなかの勇者ですねｗ IntelのとToolkit 5.0の組み合わせでどれぐらい性能が出るか
非常に興味がありますけど… なんならこちらでテスト用にToolkit 5.0でビルドして
みますけど、どうしましょう?

>>126
7970での伸びはそこそこでしたね。まあ元の速度が桁違いですけど…
10完は7970が10枚ぐらいないと難しいですねえｗ

>>122
こうやってみるとMTFもずいぶん速くなりましたよねえ。
OpenCL版をつくってよかったｗ

>>127
A10-5800Kであっさり350Mt/s超えですか・・・凄い時代になりましたね。

>>130
AMDは今は色々と大変な時期かもしれませんが、もう少し頑張って欲しいですね。
OpenCLやHSAをアピールしたりしていますし、目指しているアーキテクチャが
（サーバ的用途向け以外では）GPGPUをかなり重視しているように思えますし。

OpenCLにも興味があるのですが、まだハードルが高いでしょうかね？
まあ私の場合は頭が古くてオブジェクト指向が分かっていないので、そちらの方が先かもしれませんけど・・・ｗ

>>128
エラー検出はドライバ頼りでしたか。
検算は開発でもかなり役立ちそうですが、速度追及のためにGPUコアをOCする時にも便利だと思います
・・・とそそのかしてみますｗ

どうもGPUの場合はメモリアクセスはかなり電力を消費するようなので、
メモリアクセスが少ないプログラムでは、電圧を盛ってコアをOCした場合もリミッターに引っかからずに
最大クロックやその付近を維持できる可能性が高そうですし。

電源ユニット自体はSeasonic SS-760KMで350W程度ではどうということは無いはずで、
グラボの補助電源が6ピンx2でマザボからと合わせても規格上は225Wが上限なのでそちらの問題かと思います。

このあたりのこともあって、HD7970の8ピンx2のモデルの投売りを見過ごしたのを後悔中ですｗ

>>93
【CPU】Intel Core i7-620M @ 2.67GHz
【ビデオカード】Intel HD Graphics (CPUに内臓)

>>137
MTFの配布パッケージに同梱されているOpenCL.dllを削除して、
このCPU用のOpenCLドライバをインストールしてみて下さい。
http://registrationcenter.intel.com/irc_nas/2560/intel_sdk_for_ocl_applications_2012_runtime_setup.exe

>>136
だいたいいつもギリギリまでOCして24時間トリップ検索してますけど、
OCが原因で間違った結果が出たことはなかったですよ。
(ヒートシンクが熱膨張で破壊されたことは有りましたけど…)
まあでも検算機能はそのうちつけます。

問題は補助電源のコネクタでしたか。電源周りは気をつけないと
いけないですね〜

>>135
OpenCLやCUDAでのプログラミングはかなりハードウェアよりの思考をしないと
いけないので、そういうのが好きな方には面白いと思いますよ。
性能を出すのは難しいですけど、上手くいったときは実に気持ちいいですｗ

>>139
GPUコアのOCの場合は、ドライバがエラーをはいたりフリーズしなければ問題ない可能性が高いのでしょうかね。
とりあえずはその方向でOCを試してみます。
リアルタイムでの検算機能のほうも楽しみにしていますねｗ

ヒートシンクが熱膨張で壊れるのは色々と怖いですね・・・

>>140
CUDAの方は以前少しやっていたのですが、Radeon向けの方はまだ全く手をつけていないです。
OpenCLもオブジェクト指向が分からなくても扱えますかね？
実はプログラミング自体はそれほど好きではないのですよねえ・・・
仕組みの方に興味があってその道具であったり、作業を楽にするための手段であったりといったところでしょうかｗ

>>138
【CPU】Intel Core i7-620M @ 2.67GHz
【OS】Microsoft Windows7 Pro 64bit SP1 (DSP版)
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
【トリップの種類】12桁 5完1タゲ
【CPUの10分間の平均速度 x86】28.43Mtripcodes/s
【CPUの10分間の平均速度 x64】32.19Mtripcodes/s
【部屋の温度】16℃
【その他】MERIKENさん、ありがとうございました！

あちこちのPCで走らせて、データを取ってみました。
・5分間、5完を検索させた場合の平均速度
・ノートPCやデスクトップPCが混じっているので参考値
・GFLOPS、PassMark値はhttp://hardware-navi.com/cpu.phpから。
　整数演算的な意味でIPS値も載せたかったのですが、資料が見つかりませんでした。

CPU　　　　　　 　 　 GFLOPS PassMark CPU速度(MTPS) Ver
Celeron M 380 　 　 2.4　　　　549　 　 　 2.37　　 　 　 　 　 0.08a4
Dual Core E2180 　 16　　　　 1512　　　 14.60 　 　 　 　 　 0.08a4
Core 2 Duo E7200　20.24　.　 2322　　　 17.99 　 　 　 　 　 0.08a4
Core i5-560M　　 　 21.36　..　3602　　　 21.22 　 　 　 　 　 0.08a4　☆
Core 2 Duo E8500　25.36　 .　3199　　　 23.64 　 　 　 　 　 0.08a4　☆
Core i3-2100　　　　49.6　　　 5212　　　 24.77 　 　 　 　 　 0.08a4　☆
Core i3-2130　　　　54.4　..　　5972　　　 28.18 　 　 　 　 　 0.08a4　☆
Core i5-3210M　　　40　　　　 5222　　　 40.90 　 　 　 　 　 0.08a4
Core i5-661 　 　 　 26.64　.　 4457　　　 43.00 　 　 　 　 　 0.08a4
Core 2 Quad Q8400 42.72　.　4984　　　 45.67 　 　 　 　 　 0.08a2

ここでは触れていませんが、実は0.08a2より速度が下がってしまったものがあります。
表中に☆で示したものがそうです。中には8MTPS近く下がったものもあります。
とは言っても、「SHA-1の最適化」をOFFにするとどれも速度が下がったため、そのせいではなさそうです。

>>132
> GeForceシリーズでも出してくれないですかね〜

ttp://northwood.blog60.fc2.com/blog-entry-6506.html
余ったダイの流用なんでしょうね。名前がTitanということは、ORNLにスパコン納めた時に大量発生した不良品の在庫処分という意味かなw
確実に倍精度に規制が入るだろうし、それに合わせて実効帯域にも規制が入るかも。
CUDA狙いなら人柱の報告を待ってからにした方が良いと思います。
それ以前にこの値段では買えませんが・・・

> なんならこちらでテスト用にToolkit 5.0でビルドしてみますけど、どうしましょう?
恐縮です。お忙しいでしょうから、Kepler対応よりMTFの開発に専念して下さい。
こちらで試してみて、もし間に合ったら報告させて頂きます。

「そう言えば、>>125の「K20c」ってなんだろう？」
と思ってググったら、「Tesla K20」なるシロモノが……
http://www.google.co.jp/products/catalog?q=Tesla+K20&cid=1851801224179868559
39ﾏｿ((((;゜Д゜)))ガクガクブルブル

……い、いや、Xeon X5680も15ﾏｿが普通だし研究用だってきっと

>>145
それってすげー価格だけど、GTX690の3枚刺しより性能すごいの？

>>146
倍精度なら

alpha3からGPUが使われなくなった
5670はサポート落ち？

>>148
そんなことはないはずです。同じ環境でAlpha 2は今でも動きますか?
最近ディスプレイドライバを更新しましたか?
OSとディスプレイドライバのバージョンを教えて下さい。

>>141
OpenCLもCUDAとやってることはほとんど変わりないですよ。
オブジェクト指向は全く関係ないです。

>>142
どういたしましてｗ
こちらこそ最初に間違ったことを言ってしまってすいませんでした。

>>143
大変詳しい報告、ありがとうございました。
Alpha 2とAlpha 4では最適化されたルーチンの中身が変わっているので、
それが原因なんでしょう。この速度で8M TPSは痛すぎですね。
やっぱり元に戻しておきます。

>>144
とうとう来ましたね! でも残念ながら先立つものがないです…
ビルドの際はAMD APP SDKも必要なので注意して下さい。AMDのグラボが
なくてもインストール出来ます。
http://developer.amd.com/tools/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/

機能追加は次のバージョンまでしないつもりでしたが、
まだ安定版を出せそうにないので、前々から気になっていた
前方一致と後方一致のパターンを混ぜると速度が劇的に低下する問題を
なんとかすることにしました。すべての検索ルーチンにてをいれるので
テストの手間が膨大になりますが、変更自体は思ったより早く済みそうです。
これで後方一致の検索依頼も受けられるようになるといいんですけど…

>>150
>やっぱり元に戻しておきます
しかし☆マーク以外はAlpha 4の方が速い……
これはつまり「動的に切り替えておけ」ということなんですかね？
以前私がIntel HD(ryのために0.07Alpha5を使い続けたように、
複数Verを使い分ける路線でしばらくはやっていこうかと。
また新しい結果が出たら報告します。

>>152
> しかし☆マーク以外はAlpha 4の方が速い……

どれぐらい速いですか? それによってはオプションでの切り替えも検討します。

>>153
実はその記録は飛ばしてしまいまして……
スレに残っている結果だけ書くと、
QL-64　：　4.65M→5.31M
i5 3210M　：　78.95M(G48.79M/C30.16M)→90.15M(G55.14M/C35.00M)
Dual Core E2180　：　12.75M(0.08a3)→14.60M(0.08a4)
Core 2 Duo E7200　：　17.77M(0.08a3)→23.64M(0.08a4)

……つまりCore i3のHT機能はｼｮﾎﾞｲってことなんですかね？

貼り間違えたorz
Core 2 Duo E7200　：　17.77M(0.08a3)→17.99M(0.08a4)
に修正

>>154
こりゃ結構違いますねえ。やっぱりオプションで切り替えかなあ。

>>156
新Verはいつお披露目ですかね？

ぶるじょあやなあ
181 ：デフォルトの名無しさん [] ：2013/01/26(土) 02:29:08.92
質問
TESLA K20買おうと思ってるんだけど、プログラミングとは別にエンコでも使おうかなと思ってる。
やっぱりGTX680とかGTX580と較べて全然性能違う？（体感）
開発にはVS2012Pro持ってるからそれに追加しようと思ってる

ちょっといじったら正規表現の検索がめちゃくちゃ速くなってワロタｗ
やっぱりノウハウが溜まってくると今まで気づかなかったことにも
気づくようになんるんですねえ。

>>157
今>>151の作業にかかりきりなので、オプションの追加はちょっと先になりますねえ。

>>156
>>112ですけど、α3以降で所持機での検索が軒並み遅くなったパターンなので切替あると有り難いです…。
Atomだと20％も弱体化してますし。

>>144
予想通りかなり高いですねえ・・・

>>150
C99ベースということらしいので大丈夫だろうと思っていましたが、それを聞いて安心しました。
確か前スレで用語等のCUDAとの比較表も紹介されていましたし、落ち着き次第勉強しようかと思います。

>>159
正規表現ですか・・・面倒そうですがその分色々と工夫し甲斐もあるのでしょうか。

http://northwood.blog60.fc2.com/blog-entry-6513.html

次のAPUのRichlandの話が出てきたようですが、
GPU部分はVLIW4のままの可能性が高そうですね。

>>143に続いて、いくつかのPCで各VerでのCPU速度を比べてみました。
7完トリップを、12桁検索した時のものになります。Verは0.08 Alpha 1〜4としました。
単位は全てMTPS、()内は「SHA-1の最適化」を無効化した時のものです。
厳密な測定のため、原則10分間での平均値となります(時間掛かるわこれ……)。

CPU　　　　　　　 　 　 0.08a1　0.08a2.　0.08a3 　 　 　 0.08a4
Core i3-2130　　　　　27.98 　 37.41 　 28.22(25.99)　 28.22(25.99)
Core i5-661　 　 　 　 36.57 　 41.84 　 43.10(38.14)　 43.11(38.18)
Core 2 Duo E8500　　23.77 　 27.18 　 24.22(22.50)　 24.22(22.51)
Core 2 Quad Q8400　――　　45.67　　――(――)　　39.21(――) //都合上こいつだけ5分間です

ちなみに全部デスクトップPCです。

>>123の
>ギリギリまで詰めた設定
を久々に試してみたくなりました。
いつものレスで「-x 256」としているのは理由があって、0.07時代にオート指定の
「-x 160」より、目一杯の値にした方が速いと経験上判明したためです。
でも、今一度じっくり検証しようかと思ってやってみたところ(オートでは「-x 160 -t 3」)、
-x/-ｔ　3　　　　 4
128　　86.73　　89.77
160　　86.77　　89.52
192　　86.81　　89.99
224　　86.77　　90.12
256　　86.87　　90.49
(単位:MTPS)

となりました(7完12桁、10分平均)。
尚、「-x 160 -t 3 --suppress-sha1-optimization-for-cpu」だと、
82.06MTPSしか出ませんでした……。

>>165
以前メリケンさんが「128以上は誤差」と仰っていましたが、その通りの結果ですね。
0.08a4だと何となく傾向がある様に見えますが、誤差と言っても良いかと。
ちなみに上記も含めて全てHT onでの計測なんでしょうか?

ブロック数の自動設定機能は不安定(特にGTX590)なので、自動設定で大雑把に当たりを付けてから手動で最適値を探してます。
タゲの種類によっても変わるから、かなり面倒・・・(´・ω・｀)

>>166
一応10分は掛けたので、「数字は多めにした方が良い」的な
傾向自体はあるような気がするのですが……
ただ、GPU込みだとどうしてもCPU検索よりは誤差が出やすい
(数値が安定しない)ので、10分じゃ足りないかもしれませんね。
HT機能は全てONにしています。その方が数値出ますし

ところで、自動設定では、CUDAの場合「8,16,32,48,64,128,160,192」
といった順で出たのですが、高性能GPUだとその後に「224,256」と続くの
でしょうか？
また、Radeon側で自動設定を行った場合、どのような数値の推移で
設定値が変化するのかも気になります。

>>167の「」内は、「8,16,32,48,64,96,128,160,192」が正しい値です。入力間違えました。

>>167
すみません。自分は大雑把な人間なので、一割程度差が出なければ「誤差の内w」と思ってしまうのです。

> ところで、自動設定では、CUDAの場合「8,16,32,48,64,128,160,192」
> といった順で出たのですが、高性能GPUだとその後に「224,256」と続くの
> でしょうか？
Tesla K20cの時には自動で256まで行きました。実際256が一番速かったです。
Radeonは持ってないので分かりません。

>>169
>Tesla K20cの時には自動で256まで行きました
ということは、GTX云々の方は自動で256まで行かないのか……手厳しいｗ

>>151の変更の作業は終わりました。前方一致と後方一致のパターンが混在している
ケースでの速度がかなり改善されました。例えば次のパターンでの速度は
5770で14倍(!)、580でも4.5倍に上がっています。

#regex
^TEST../
/..TEST$

5完1タゲと比較してもでも5770で78%、580にいたっては98%の速度が出ています。
今回は高速化のために共有メモリをかなり贅沢に使用したのですが、やはり
アーキテクチャによって随分最適化の効果が違いますねえ。なんにせよ、
これで後方一致のパターンの検索依頼も受けやすくなるでしょう。

>>165-171
CUDAの実行時の最適化は、何も知らない人がお手軽にそこそこの速度を出せるように
設計されているので、やはり本当に性能を搾り取ろうと思ったら手作業でかなり
時間をかけないといけないですね。-xの値も確かに増やせば速度が上がるんですけど、
パターンが複雑だとカーネルの実行時間が長すぎてディスプレイドライバが
落ちてしまうこともあるので、自動設定ではある程度低めの値にするようにしています。

>>172
なるほど……小さめなのは理由があったんですね。自分の手持ちの
ノーパソに乗ってるGPUに37万パターン/1009チャンク与えても
平気で動作するので、自分は「-x 256 -t 4」を続けようと思います。
最新版(「Alpha 5」？　「Beta 1」？)、楽しみにしています。

>>162
> 正規表現ですか・・・面倒そうですがその分色々と工夫し甲斐もあるのでしょうか。

一番めんどくさいパーサは一番最初に作ってしまってて、
今やっているのはGPUの処理のほうです。結構簡単な工夫で速度が上がるので
面白いですねｗ

>>163
AMDは6990のVLIW4をかなり引っ張るつもりですね。正直以外です。
GCNって素直に性能が出てくれるので好きなんですけどね〜

>>173
GPUではチャンクしか処理していないんですけど、これがもっと多くなって
数万のオーダーになるとまずいんです。次のはAlpha 5です。とりあえず
CPU検索のルーチンを切り替えられるようにしてから、もう一回時間をかけて
テストする予定です。来週の早いうちに出せるといいですねえ。

>>176
>チャンク
>数万のオーダー
・・・アレ、そう言えばパターンとかチャンクとかってどんな風に数えているんですか？
例えば「^[Aa][Mm][Aa][Gg][Aa][Mm][Ii]」を展開したら何パターン・チャンクに？

>>171
HD5770ではそこまで速度低下があったのですか。
原因がVLIWなのか、命令ディスパッチなのか、それとも共有メモリ周りなのか気になるところです。

それにしても変更後のGF110での速度低下の少なさは驚きですね。

>>174
一番面倒なのはパーサかもしれませんが、GPUでの処理の工夫も大変そうに思えますけど
それを結構簡単と言えてしまうのが凄いですｗ

>>175
歩留まり絡みで急遽ファブを変更するという噂もありましたし、
AMDもVLIW4を引っ張りたいのではなく、やむなくではないでしょうかね・・・

意地でもシングルスレッド性能も上げて、SIMD等も強化して、GPUはグラフィック特化のIntelと、
シングルスレッド性能を多少犠牲にしてでもマルチタスクでの性能向上を目指し、
並列処理性能はCPUの方はそこそこに抑え、汎用のGPUに任せようとしているAMDと、
かなり方向性が異なり面白いです。

まあ引っ張ってくれてるおかげで
VLIW4系のRADEONのドライバサポートが長くなるのなら大歓迎ですが

>◆MERIKEN4.k様
Alpha 2までは普通に動いてて
OSはWin7でディスプレイドライバは11.6
言うまでも無く更新してません

古いドライバなのでお気になさらずに

>>177
パターンの数は普通に2^7=128です。
チャンクは最初の5文字、もしくは最後の5文字から生成される30bitのハッシュ値なので、
この場合は2^5=32ですね。

>>178
原因は多分共有メモリなんじゃないかと当たりをつけています。
GTX 580の共有メモリはバンクコンフリクトにさえ気をつければ
ものすごく速いですからねえ。6990や7970で速度が落ちるような
複雑なパターンでも、580では速度が落ちないということもありました。

正規表現のパターンはCPU側で展開されて、GPU側では30bitのハッシュ値のみを
扱っているので、実際GPU側の処理はそれほど複雑ではないのです。

AMDのアプローチは結構好きですｗ 次にマザボを買い換える機会があったら
AMDのAPUを是非試してみたいですねえ。

>>179
まあ今だにVLIW5系のサポートが続いているので当分の間は大丈夫でせう。

>>180
それなら多分問題はディスプレイドライバでしょうねえ。
13.1あたりにアップデートすれば直るかもしれません。

>>110
うちの6990x2は、ドライバを13.1にアップデートして、コア周波数を880MHzに
落として、Power Limitを+20%まで上げてようやく安定して24時間動作するように
なりました。GPUの使用率はGPU0が94%前後で、残りは全て99%です。
画面操作をするとGPU0の使用率が結構落ちるのですが、ほかっておくといつの間にか
元に戻っています。

>AMDのアプローチは結構好きですｗ 次にマザボを買い換える機会があったら
AMDのAPUを是非試してみたいですねえ。

参考に構成をご指導ください。

【CPU】Intel Xeon 5080 3.73GHz(x2CPU)
【OS】Microsoft Windows8 Pro MCE 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【CPUの平均速度 x86 4C/4T時】14.66Mtripcodes/s
【CPUの平均速度 x64 4C/4T時】22.02Mtripcodes/s
【CPUの平均速度 x86 4C/8T時】22.44Mtripcodes/s
【CPUの平均速度 x64 4C/8T時】28.14Mtripcodes/s
【その他のオプション】 SHA-1最適化 ON
【その他】5完1タゲ、テスト10分間、GPU未使用、4C/4Tと4C/8Tの違いを厳密に調べるためBIOSから変更。

【GPU】EVGA GeForce GTS450 1024MB 01G-P3-1450(x2GPU Core823MHz PCIEx16+x4)
【CPU】Intel Xeon 5080 3.73GHz(x2CPU)
【OS】Microsoft Windows8 Pro MCE 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】160
【Display Driver】306.97
【10分間の平均速度】444.81M tripcodes/s
【GPUの平均速度】421.41M tripcodes/s
【CPUの平均速度】23.40M tripcodes/s
【GPU使用率】99%
【GPUの温度】75℃/66℃ （開始時 37℃/31℃）
【その他のオプション】 SHA-1最適化 ON
【その他】5完1タゲ、テスト10分間、GPU使用 HTT有効、GPUは微OC品。

>>187
450でそのスコアってさすがEVGAだなw

【CPU】Intel Core i5-2410M 2.3GHz
【OS】Microsoft Windows7 Pro 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【CPUの平均速度 x86 2C/2T時】14.70Mtripcodes/s
【CPUの平均速度 x64 2C/2T時】24.61Mtripcodes/s
【CPUの平均速度 x86 2C/4T時】17.42Mtripcodes/s
【CPUの平均速度 x64 2C/4T時】28.71Mtripcodes/s
【その他のオプション】 SHA-1最適化 ON
【その他】5完1タゲ、テスト10分間、GPU未使用、2C/2Tと2C/4Tの違いを厳密に調べるためBIOSから変更。
2C/4TでNetburstXeonの4C/8Tと同クラスの性能とは流石といった感じ
でもCoreiのSMTはx64モードじゃないと効率が悪いっぽいなぁ…

【CPU】Intel Core 2 Quad Q6600 2.4GHz
【OS】Microsoft Windows Vista HP 32Bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【CPUの平均速度 x86】35.49Mtripcodes/s
【その他のオプション】 SHA-1最適化 ON
【その他】5完1タゲ、テスト10分間、GPU未使用。
Netburstとは格の差を見せつけた結果かねぇ

>>181
>30bitのハッシュ値
なるほど、ハッシュ検索していたのか……
道理で「理論的には変わらない」と言っていたんですね
>>186
あれ、Xeonってそんな遅かったっけ……と思ったら後ろの数字が違ってた
(PassMark値は5680が9933、5080が1939)

【CPU】AMD Opteron 3250 HE 2.5GHz(1M/2C時はTCで2.8GHz動作)
【OS】Microsoft Windows XP Home 32Bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【CPUの平均速度 x86 1M/2C】9.25Mtripcodes/s
【CPUの平均速度 x86 2M/4C】16.57Mtripcodes/s
【その他のオプション】 SHA-1最適化 ON
【その他】5完1タゲ、テスト10分間、GPU未使用、1M/2C,2M/2C,2M/4Cの設定はBIOSから変更。
ノートだと熱保護でクロックが下がりやすいのに
2M/4C時ですらx86 2C/4TのCorei5に負けるのか…
やはりBulldozer系は1M/2C≒Corei 1C/2T位に考えないとダメですね。

訂正ですが2M/2C動作はBIOS上からは再現できませんでした

【CPU】PentiumD930 3GHz(エラッタによりEIST無効)
【OS】Microsoft Windows Home Server 2011 64Bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【CPUの平均速度 x86 2C】6.17Mtripcodes/s
【CPUの平均速度 x64 2C】9.36Mtripcodes/s
【その他のオプション】 SHA-1最適化 ON
【その他】5完1タゲ、テスト10分間、GPU未使用、
x86 2C時だとBulldozerの1M/2Cよりも遅いんですね、
せめてSMTが使えさえすれば…

【GPU】玄人志向 GF-GT520-LE512HD(32BitDDR3-1066 PCIEx16)
【CPU】PentiumD930 3GHz(エラッタによりEIST無効)
【OS】Microsoft Windows Home Server 2011 64Bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】160
【Display Driver】306.97
【10分間の平均速度】 56.86M tripcodes/s
【GPUの平均速度】52.27M tripcodes/s
【CPUの平均速度】4.58M tripcodes/s
【その他のオプション】 SHA-1最適化 ON
【その他】5完1タゲ、テスト10分間。
ローエンドGPUだとこんなものですかね
てか常時稼働のサーバーには向いてませんよねこのマシン…

>>192
Bulldozer系はSHA-1ハッシュ生成の最適化を切ったほうがいい数字が出るみたいですよ。
>>14さんの報告ではFX-8350で114M TPS出ています。

>>185
「ご指導」というほどのものでもないですけど、基本的な構成は>>4で、
電源はCorsair AX1200、マザボはASUS R.O.G. Crosshair V Formula-Zです。
ケースはLian Liのテストベンチですべての部品はむき出しで、
7970はPCIeの延長ケーブルを使って6990x2の上に乗っけているので
熱対策は万全ｗです。モニタは6990につなげてますけど、こうすると
GPUの使用率が下がってしまうので、APUを画面表示用に使えないかなと
考えていたんです。

>>196
【CPU】AMD Opteron 3250 HE 2.5GHz(1M/2C時はTCで2.8GHz動作)
【OS】Microsoft Windows XP Home 32Bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【CPUの平均速度 x86 1M/2C】9.33Mtripcodes/s
【CPUの平均速度 x86 2M/4C】16.68Mtripcodes/s
【その他のオプション】SHA-1最適化 OFF
【その他】5完1タゲ、テスト10分間、GPU未使用、1M/2C,2M/4Cの設定はBIOSから変更。
調べてみましたが3250HEでOFFにした場合はほんの少し上がる程度の差ですね。

【CPU】AMD FX8350 4GHz
【OS】Microsoft Windows8 Pro MCE 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【CPUの平均速度 x86 SHA-1最適化OFF】60.31M tripcodes/s
【CPUの平均速度 x64 SHA-1最適化OFF】95.29M tripcodes/s
【CPUの平均速度 x86 SHA-1最適化ON】61.59M tripcodes/s
【CPUの平均速度 x64 SHA-1最適化ON】98.62M tripcodes/s
【その他】5完1タゲ、テスト10分間、DDR3-2133 x4のOCメモリを使用。

FX8350だとOFFにしたら逆に下がるという結果が出ましたが
これはOSの差なんでしょうかね？
あと指摘しておきますが>>14氏の結果は4.95GHzまでOCしての結果ですよ。

【CPU】Intel Core 2 Duo U7600 1.2GHz
【OS】Microsoft Windows Vista Business 32Bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【CPUの平均速度 x86 2C】8.41Mtripcodes/s】
【その他のオプション】SHA-1最適化 ON
【その他】5完1タゲ、テスト10分間
Merom 1.2GHz(FSB533 L2 2M 65nm TDP11W)が
Presler 3GHz(FSB800 L2x2M 65nm TDP95W)よりも早いことに驚愕
ホントNetburstとはなんだったのか…

追記ですがx86時での比較です
まあx64時でも負けることはないでしょう

>>182
GCNでも共有メモリはGeForceほど速くはないのですか？

GPU側では30bitの比較とはいっても、前方や後方に限定されない場合は特に
いかに速度を落とさずに処理するかが難しそうです。

私は今までAMD CPU + GeForceでしたが、GK104でのグラフィック特化とかもあり、GCNになったRadeonにしました。

APUの設計思想は非常に面白いですね。
古い家族共用のXPマシンをそろそろWin8のAPUマシンにリプレースしたいです。
そういえばWin8のアップデート版を追加で買っておくのを忘れそうになっていましたｗ

意地でもシングルスレッド性能を上げるHaswellも、あれはあれで面白そうですけど。

>>200
Core系が出た後に何じゃこりゃ状態でしたね。排熱設計の促進剤だったのかと
GPUの消費電力が上がっている昨今、思ったり思わなかったり。
AtomZ510(1.1GHz、1C1T)なら1.62M位でしたので、かわいいもんですが。
Celeronon C847(1.1GHz、2C2T) x64で16-7M出てるのはメモリの差も大きいのかしらん。

>>199
これは面白いデータですねえ。貴重な報告、ありがとうございます。
多分これはAlpha 1とAlpha 4の最適化ルーチンの違いなんでしょう。
新しいCPUではAlpha 4の最適化ルーチンのほうがAlpha 1のものよりも
速くなる傾向にあるようですが、FX8350も例外ではないようです。

最適化ルーチンの切り替えができるバージョンはもう出来上がっているので、
あと数日でうpできるはずです。こちらのもぜひお試し下さい。

>>204の訂正です。Alpha 1ではなくてAlpha 2でした。

>>202
少なくとも580の共有メモリのほうが使いでがあるということは言えると思います。
普通のケースでは7970は580の4倍ぐらいの速度ですが、共有メモリを使った最適化が
効いてくる複雑なパターンでは、580のほうがはやくなるなんてこともありました。
ほかにも共有メモリを使用した最適化の手法が580では有効だったけど7970では
そうではなかったなんてこともありました。逆に580では分岐処理が非常に大きな
ペナルティになるのに対して7970ではそうでもないので、ここらへんは
アーキテクチャの違いを常に意識する必要がありますね。

> GPU側では30bitの比較とはいっても、前方や後方に限定されない場合は特に
> いかに速度を落とさずに処理するかが難しそうです。

これはおっしゃる通りで、このケースの場合12桁なら比較の手間は7倍になるので、
スピードを落とさないためにはかなりの工夫が必要です。

あ、あと個人的にはAPUのようなasymmetricでparallelなアーキテクチャは
大好物ですｗ AMDには頑張って貰いたいものです。

ようやく重い腰を上げてテストを開始したけど、組み合わせを考えたら最低でも

パターンの種類: 8
トリップの種類: 2
デバイスの種類: CPU * 3 + CUDA + VLIW5 + VLIW4 + GCN = 7

で112通りあって、それぞれのケースでAlpha 4とAlpha 5を10分間走らせるから
合計で112 * 10 * 2 = 2240分 = 37.3時間 かかるってことだよな…
今回は本でも読みながら気長にやるけど、次回からは絶対に自動化しようっと。

CUIにテストモード(10分稼働→OSやGPUなどの情報と検索速度をファイル出力して終了するオプションがあれば楽なのかな

>>208
同じ事を考えていた……
PC前で10分待機は自身に辛い……

【GPU】gtx560ti
【CPU】i7-2600
【OS】win7 64Bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】128
【Display Driver】310.90
【10分間の平均速度】 562.18M tripcodes/s
【GPUの平均速度】490.37M tripcodes/s
【CPUの平均速度】71.81M tripcodes/s
【その他のオプション】 SHA-1最適化 ON
【その他】7完1タゲ、テスト10分間。

【GPU】gt620
【CPU】i3-2120
【OS】win7 64Bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】64
【Display Driver】310.90
【10分間の平均速度】 76.62M tripcodes/s
【GPUの平均速度】52.35M tripcodes/s
【CPUの平均速度】24.27M tripcodes/s
【その他のオプション】 SHA-1最適化 ON
【その他】7完1タゲ、テスト10分間。

#2ﾋZｹ/2lW/ﾃﾅﾜ

スレ間違えたorz

>>209
これ以上CUI版を複雑にしたくないので、CUI版には検算機能だけ追加して、
いずれGUI版から全自動でテストできるようにする予定です。結構面白い結果が
出ているのでそこまで苦にならないですけど、このテストを手作業でするのは
もう2度と御免ですねｗ

>>210-211
前スレの841〜848に0.07 Beta 1と560ti x2での報告がありましたけど、その時には
単体で381M TPSだったので、3割近く速くなっていますね。やっぱりNVIDIAの
カードでも最適化の効果の程度は大分違うようですねえ。

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【その他のオプション】 SHA-1最適化 ON
【Display Driver】Catalyst 13.1
【その他】11完1タゲ
で2つのPCで測定しました。

【OS】Microsoft Windows vista home premium 32bit
【GPU】radeon HD 7750×2(OC: GPU 900MHz)
【GPUの平均速度】1108.51M tripcodes/s

【OS】Microsoft Windows7 home premium 64bit
【GPU】radeon HD 7950×2(GPU 800MHz)
【GPUの平均速度】フリーズ（30秒で3600M程出て、のちフリーズ）
【その他】最適化がすごいのか普段高クロックで問題なく動いてるGPUが定格でもフリーズしたのが衝撃でした。
各1枚ずつ動作も試しましたが、結局フリーズでした・・・
相性とかあるのでしょうか？修理に出したいですけど受け付けてくれなさそうです。。

WCGの最適化ができるようになって現在は検索を休止していますー。

>>206
HD7970の共有メモリはレイテンシがかなり大きいのでしょうかね。
分岐処理の差も気になります。

AMDはサーバ向けにもAPUを投入するらしいですし、ヘテロジニアスな方に力を入れていくようですね。

私もこの方向性は面白いと思いますし、将来的にもいいと思いますが
やはり対応ソフトが増えるまでは世間一般からはあまり高い評価を得られないかもしれませんね。
特に今までの延長線上のハイエンドデスクトップを望む層からは散々な評価かもしれませんｗ

>>216
う〜ん、どうなんでしょう… 確かにOC耐性が減った可能性はありますけど、
うちでは定格が1000MHzの7970のカードを、これまで通り1130MHzまでOCして
問題なく動いているので、定格で動かないというのは予想外です。

>>217
> AMDはサーバ向けにもAPUを投入するらしいですし、

これは知りませんでした。AMDも大変な時期ですけど、ぜひ今後もとんがった
アーキテクチャの追求を続けてほしいものです。

WS用にはFireProAPUはあったはずだけど大半のサーバアプリケーションには無用なのでは？

よく知らないですけど、GPUサーバなんてものがあるぐらいだしどこかには
需要があるんでしょうｗ 私はそういう技術が一般消費者に下りてくるのを
待っているだけですけど…

あれから延々とテストを繰り返していたのですが、ようやく6割終了といったところです。
それにしても結構面白いデータが取れています。どうも5770の共有メモリの
レイテンシーはかなり大きいようで、そのせいでターゲットが増えると
速度がかなり落ちるようです。コンスタントメモリを使ったほうがいいのかも
しれません。

さらなる最適化のアイディアが色々湧いてきたのですが、
とりあえず新しい開発版のテストを優先させることにします。
しかしいつおわるんだろ、これ…

【GPU】N/A
【CPU】Intel Core i5 3210M
【OS】Windows 8
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha4
【トリップの種類】12桁・10桁
【CPU検索スレッドの数】4
【その他のオプション】Default
【Display Driver】Intel（R） HD Graphics 4000
【10分間の平均速度】30.87Mtripcodes/s
【GPUの平均速度】N/A
【CPUの平均速度】30.87Mtripcodes/s
【GPUの使用率】N/A
【GPUの温度】N/A
【その他】2013年購入

12桁でも生でキーをはきだせるの・???

>>216
MTFはメモリアクセスが少なくグラボ全体の消費電力が低めなので、電力リミッターに引っかかりにくく
コアクロックが最大クロックに張り付く可能性が高いことや
整数演算であることが一般的なグラフィック系ソフトと大きく違う点だと思いますが、
2枚あってその2枚とも定格でも動かないとなると原因の特定に手間取りそうですね・・・

>>219-220
すみません、記憶違いでワークステーション向けだったみたいです。
マザボとセットで7万円を切って、non-ECCメモリということはエントリー向けのワークステーションでしょうかね。

>>222-223
アーキテクチャの違いへの対応はかなり手間ですね。
アイデアが色々と湧いてきたということは期待していいのでしょうか？ｗ

ねんがんの　HD7970をてにいれた。

【GPU0】MSI HD7970 たぶん1GHz 3GB
【GPU1】? HD5870　@ x8 PCIe
【CPU】Intel Core i5-3470
【OS】MS Windows 8Pro 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】N/A
【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【CPU検索スレッドの数】自動
【その他のオプション】N/A
【Display Driver】Catalyst 13.1
【10分間の平均速度】4104.01M tripcodes/s
【GPUの平均速度】4087.20M tripcodes/s
【CPUの平均速度】16.81M tripcodes/s
【GPUの使用率】未計測
【GPUの温度】未計測
【その他】5完1タゲ。TEST/

50分放置でPower Saveモードに突入してしまったので途中終了。
君、計算しとるやん・・・。
とはいえ、言われるとおり3G+1Gの速度が出てNiceでした。
PCIe3.0とか、x16,x8とかありますが、5870の挙動を見る限りx8x16の差異は
見られなかったです。

うおおおおおおお

>>218
>>226
MERIKENさんがOCでも動いている以上、うちの環境に問題がありそうですねー。
私の今GPUでやっているWorld Community Gridもおそらくは演算系だとは思うので原因が正直な所分からないです。。
画面に出力しているGPUでMTFを開始するとブロックノイズが出てくるという症状はありました。
画面出力ではない方で開始したときはブロックノイズは出なかったです。

>>221
Amazon EC2のクラスタ GPU インスタンスなら容易に借りる事ができますよー。1時間2.6$とお高いですが。
MTFはネットワーク化すればスポットインスタンスを有効利用できそうな気がします。それでもやはり高いですけどね。

しっつもーん！
タゲは実用上何個ぐらいまでな設計なのかな？
CPU検索のみで試しに23万タゲほどつっこんでみたら、実用にはならないっぽいけど。
千個ぐらい？

>>230
数十万のオーダーならGPUなら全然問題ないはずですけど…
そういえばCPU検索では試したことがなかったですねえ。

>>231
昔テスト用に使っていた20万語ぐらいの英単語のリストは
どっかにいってしまったようです。また後で調べてみます。

>>224
一瞬◆YSRKENkO6Yさんのかと目を疑ってしまいましたｗ
問題なく動いているようですね。

>>225
試したことはないですけどキーの文字コードは表示されるようになっているので
それから作ることは出来るはずです。

>>226
VLIW4/5はもうちょっと盛れそうな感じです。Alpha 5をうｐした後で
色々試してみます。

>>227
7970はいいですよ〜ｗ 6990のほうがちょこっと速いんですけど、こっちは
7970と違ってなかなか素直に言うことを聞いてくれません。PCIeの転送速度は
全く問題にならないはずです。

>>229
最近のバージョンの最適化では共有メモリをほかのアプリケーションに比べて
酷使しているので、そのせいで隠れていた問題がでてきたのではないでしょうか。
Amazon EC2はテスト用に便利そうですねえ。

>>233
実は俺も目を疑ったわｗ
GPU使ってないし当方Win7だから違うなとは思ったけど
それに自分がCPUのみ・7完タゲ1つ・12桁で回した場合は40MTPSは出てるんだよね……
実はID:H8BERSFc0さんが大量タゲで動かしていた、なら話は別だけど
>>234
もはやベンチマークだな……

【CPU】Intel Core i5 2400
【OS】Windows 7 32bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha4
【トリップの種類】12桁
【その他のオプション】Default
【CPUの平均速度】45.50Mtripcodes/s
【その他】5完1タゲ

ノートPCは熱でCPUクロックが落ちることがあるからな

キーに1バイト文字だけ使用するようにするオプションを
CUI版に試しにつけてみました。これで同速度でのヒット率はWiz7と
同じになるので、某氏にうるさく言われずに済みそうですｗ

>>235-237
多分速度の違いは熱によるスロットルダウンなんでしょうね。
うちのXPのノートは長時間MTFを走らせると熱暴走で落ちてしまいますw

331431:
331432:
Preparing tables for patterns...


ﾑﾘﾎﾟ

新しい開発版です。

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

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

・前方一致と後方一致のパターンが混在する場合の高速化。
・キーに使用する文字の種類を指定するオプションの追加。

お。乙です。さっそくもらってきます。
Ver0.07になってましたが落ちてきたのは0.08 Alpha5で安心。

EC2で初年度無料のマイクロインスタンスで検索してみました。

【CPU】Amazon EC2 t1.micro
【OS】Windows 2008 RC2 32bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha5
【トリップの種類】12桁
【その他のオプション】Default
【CPUの平均速度】1.44Mtripcodes/s
【その他】5完1タゲ、最適化最大。64bit検索が動かないので32bitで検索。

無料とはいえちょっと使い物にならないですねー。

あれほんとだｗ 早速直しておきました。

速攻でブン回したいところだが……
今日はもう寝るぜ！

明日ブン回すとして…CPU検索の、SHA-1ハッシュ生成の最適化のパターンが増えてる？
それぞれでやってみればいいかな

1タゲと前後完全一致複合で試してみましたー。

【CPU】Core i5-3470　@OC 3.4Ghz
【OS】Windows 8 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha5
【トリップの種類】12桁
【その他のオプション】Default
【CPUの平均速度】81.14Mtripcodes/s
【その他】最適化最大、パターンを以下に指定しました。(192patterns,12chunks)[/.]は[:punct:]で検索しています。
#regex
^T(EST|est)[/.][/.][/.][/.][/.]
^test[/.][/.][/.][/.][/.]
[/.][/.][/.][/.][/.]T(EST|est)$
[/.][/.][/.][/.][/.]test$

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha4
【CPUの平均速度】26.34Mtripcodes/s
【その他】上記パターン

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha5
【CPUの平均速度】83.75Mtripcodes/s
【その他】9完1タゲ

CPUでは3倍強の高速化でしょうか？これで後方同時検索でも問題なく検索できそうですねー。

ちょっと補足ですー。
MERIKEN's Tripcode Finder 0.08 Alpha4では(192patterns,38chunks)でしたー。

あと32bitでGPUも試してみました。

【トリップの種類】12桁
【その他のオプション】 SHA-1最適化 ON
【Display Driver】Catalyst 13.1
【その他】testタゲ(192patterns,18or38chunks)
【OS】Microsoft Windows vista home premium 32bit
【GPU】radeon HD 7750×2(OC: GPU 900MHz)

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 5
【GPUの平均速度】1086.88M tripcodes/s

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 4
【GPUの平均速度】973.80M tripcodes/s

しっかりと効果が出てますねー。
7xxxシリーズは元から速度低下は低めでしたが、しっかり改善されてるようです。

超大量トリップ（ランダム文字列）を計算させてみました。

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 5
【トリップの種類】12桁
【その他のオプション】Default
【その他】8完、131071patterns

【CPU】Core i5-3470　@OC 3.4Ghz
【OS】Windows 8 64bit
【CPUの平均速度】28.30Mtripcodes/s

【GPU】radeon HD 7750×2(OC: GPU 900MHz)
【Display Driver】Catalyst 13.1
【OS】Microsoft Windows vista home premium 32bit
【GPUの平均速度】794.76M tripcodes/s

生成されたトリップが有効であることを確認しました。
普段からこんな量を探すことは無いでしょうけれど実用可能な速度が出るんですねー。

>>243
たしかにこれは使えないですねｗ 一体どのCPUを使ってるんだろう…

>>246
そうそう、これ書き忘れてたｗ 最適化のルーチンをAlpha 2のものと
Alpha 4のものとで切り替えられるようになっています。ぜひお試し下さい。

>>247-248
前方一致と後方一致のみの場合を特殊なケースとして最適化しています。
検索依頼を受けてると結構よくあるんですけど、MTFを作り始めたときには
自分のトリップしか探してなかったので気づかなかったんですよね。内部処理を
かなり変更する必要があったのですが、効果はあったようですね。

>>249
あ、ちゃんと動いてますね。安心しました。
でも英単語のリストとかを使うとすぐにそれぐらいの数になってしまうので、
もうちょっと速くしたいところですねえ。

【GPU】NVIDIA GeForce 610M
【CPU】Intel Core [email protected]
【OS】Windows 7 Ultimate SP1 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 alpha 5
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】256
【CPU検索スレッドの数】4
【Display Driver】310.90
【検索時間】5分
この条件で、
○「HARUKA/」を前方一致で検索
→alpha 4は89.16MTPS(G54.81MTPS/C34.35MTPS)、alpha 5は90.06MTPS(G54.98MTPS/C35.08MTPS)
○「HARUKA/」を前方一致、「/NONOWA」を後方一致で検索
→alpha 4は60.71MTPS(G49.03MTPS/C11.68MTPS)、alpha 5は88.13MTPS(G54.28MTPS/C33.85MTPS)
○「DOUGHNUT」を位置指定無しで検索
→alpha 4は63.54MTPS(G51.67MTPS/C11.86MTPS)、alpha 5は79.14MTPS(G51.99MTPS/C27.16MTPS)

>>250
>あ、ちゃんと動いてますね。安心しました。
当方では406309 patterns (1909 chunks)で回しているが、
これに準10連(^[Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm])を
追加するとパターンの展開が終わらない(検索できない)……
この辺が限界だとでも言うのか……ぐぬぬ
(40万の限界は別の環境でも確認済み)

ちなみに例の1バイトオプションを掛けた状態で7完・12桁・先頭一致検索すると、
89.96MTPS出ました……別に高速化するわけじゃないのね

個人的には、ネットワーク対応やテスト用モードも欲しいですが、
10秒毎に表示される速度表示(平均値でなく瞬時値の方)をテキストで自動ロギングしてくれる機能があると、
それはとっても嬉しいなって
(解析ユーティリティ作れるぜひゃっほい的な意味で)

>>250
EC2は仮想PCなのでリソースを制御しています。
マイクロインスタンスは最大2ECUで、普段はさらに制限されてますからねー。
（ECUとは1つの 1.0-1.2 GHz 2007 Opteron または 2007 Xeon プロセッサの CPU能力に等しい能力）

>>251
全数・準12連・最長・最短の展開は問題ありませんでしたよ。

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 5
【トリップの種類】12桁
【その他のオプション】Default
【その他】全数・準12連・最長・最短、1269374patterns(101314chunks)

【CPU】Core i5-3470　@OC 3.4Ghz
【OS】Windows 8 64bit
【CPUの平均速度】75.73Mtripcodes/s

【GPU】radeon HD 7750×2(OC: GPU 900MHz)
【Display Driver】Catalyst 13.1
【OS】Microsoft Windows vista home premium 32bit
【GPUの平均速度】975.69M tripcodes/s

>>251
その程度で動かなくなるような設計ではないので、なんかバグ臭いですね…
再現できるパターンを送ってもらえたら調査してみます。
[email protected]

>>252
> ちなみに例の1バイトオプションを掛けた状態で7完・12桁・先頭
> 一致検索すると、89.96MTPS出ました……別に高速化するわけじゃないのね

そりゃあのオプションをつけた一番の理由は、いいんちょがうざかったから、
ですからねえｗ でも速度は同じでもヒット率は確実に数%上がるので、
使いたいという人もいるかもしれません。私は使わないですけど…

> 10秒毎に表示される速度表示(平均値でなく瞬時値の方)をテキストで自動ロギング

デバッグ用のログを作成するのも悪く無いですね。ちょっと検討してみます。

>>253
> EC2は仮想PCなのでリソースを制御しています。

やっぱそうですよねｗ Amazon EC2のアカウントは以前作成したんですけど、
当時はGPU Instancesのことを知らなかったので放ったらかしになってました。
ネットワーク化、やってみたいですねえ。

>>224ですが、一日ほど連続使用してみました
すると、最新の速度は34M/s位の速さが出ているのですが、平均速度は2.53M/sという低速になってます
ちなみに、走らせている間はパソコンをロックしていました

>>256
なんでそんなに遅いん……？
省エネモードとか熱対策でCPUのクロックが下がっているとかかな？

>>254
了解です。自分の検索パターンをそのまんま送るのも気が引けるので、
状況が再現できるサンプルが作れるかちょっとやってみます。
ログについてですが、単に「全体,GPU,CPU」みたいにコンマ区切りなCSVでも全然構いませんので
(個人的には平均値だけでなく標準偏差とかが知りたいけど……まあ自分でCSV解析するコード書くわ)

そう言えば、GUI版を走らせて分かったのですが、どうやら隠しオプションがあるようですね↓！？
--suppress-sha1-optimization-for-cpu　　　　 　 SHA-1の最適化を「無効」にする。PhenomII以降推奨
--enable-sha1-optimization-for-cpu　　　　 　 　 SHA-1の最適化を「有効」にする。Core 2 Quad迄推奨？
--enable-maximum-sha1-optimization-for-cpu　SHA-1の最適化を「最大」にする(デフォルト)。Core i以降推奨？

>>253の言う通り、全数・準12連・最長・最短をやってみましたが、こちらはどうも上手く通るようです。
とりあえず、以下のパターンだけにしても状況が再現出来ました。
----------------------------------------
#regex
^[mMW][mMW][mMW][mMW][mMW][mMW][mMW][mMW][mMW][mMW][mMW]
^[Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm]

----------------------------------------

>>256
多分省電力設定が問題なのではないかと…
CPUの温度はどれぐらいですか?

>>257
> ログについてですが、単に「全体,GPU,CPU」みたいにコンマ区切りなCSVでも全然構いませんので

それならすぐに出来るはずです。次の開発版で対応します。
オプションはREADME.txtに書いておくのを忘れてましたｗ

>>258
こりゃ完全にバグですね。調べてみます。

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 5
【トリップの種類】12桁
【その他のオプション】Default
【その他】100patterns
【CPU】Core i7-2600k
【OS】Windows7 64bit
【CPUの平均速度】78.45Mtripcodes/s
【GPU】Radeon HD6770
【Display Driver】Catalyst
【GPUの平均速度】636.52M tripcodes/s

MERIKEN's Tripcode Finder 0.07だとCPU30M GPU270M
すごい進化ですね

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows XP Professional 32-bit SP3
【バージョン】MERIKEN's Tripcode Finder GUI 0.08 Alpha 5
【トリップの種類】12桁
【10分間の平均速度（括弧内は「SHA-1の最適化」の設定）】7.96(無効)、10.26(有効)、8.77(最大) Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）
参考：同条件でAlpha 2（3〜4より速い）では7.80

このCPUだと「SHA-1の最適化」は「有効」にしたときが一番速い！　10Mtripcodes/sこえたー！
Alpha 2から比べて13％も速くなってます。

【CPU】Intel Atom CPU N280（定格稼働）
【OS】Windows 7 Starter SP1
【バージョン】MERIKEN's Tripcode Finder GUI 0.08 Alpha 2→3→4
【トリップの種類】12桁
【10分間の平均速度（括弧内は「SHA-1の最適化」の設定）】 2.54(無効)、3.57(有効)、2.82(最大) Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）
参考：同条件でAlpha 2（3〜4より速い）では2.68

こちらも13％高速化してます、「有効」がベスト。

>>260
>忘れてましたｗ
忘れたと言えば、「■作者の連絡先」が未だに前々スレのままで、同梱パターンファイルも簡素版なんですけど……。
テキストエディタで確認したところ、「-t [スレッドの数]」がある行の行末に謎の空白がありますし。
些細なことですが、一応確認しておいて下さい。

>>261
なんせ、ここ2週間ぐらい本業ほったらかしでMTFの最適化ばかり
してましたからねｗ

>>262
やっぱりこのオプションは付けて正解でしたね。

>>263
これはひどいｗ 直しておきます…

1台のPCで水冷+カスタム水枕で7990x4を試してみた方がいたそうで。

http://devgurus.amd.com/thread/159833

結局ドライバの問題でWindowsではちゃんと動かなかったそうです。
(Linuxだと大丈夫だったようですが) コメント欄を見ていると、
どうやらWindowsのドライバは5GPUまでしかサポートしてないようです。

で、このPCはC++からOpenCLへの並列化コンパイラのためのものだそうです。
テスト機にこれだけお金をかけられるのが正直うらやましい…

◆TFinder/tKq3 #3ﾅTﾖLMuﾜyPLﾆ
支援

>>265
HD7990×4枚差した絵が不気味すぎる……
ttp://i36.photobucket.com/albums/e6/stargliderx/4x7990.jpg
ttp://i36.photobucket.com/albums/e6/stargliderx/7990stripped.jpg

ブラケットさえあれば7枚差しも逝けるな

-r ってREADMEに載っていますけど、もう使われていないオプションですよね？

>>269
これ、正直いつのだったか記憶に無いですｗ 削除しておきました。

コレを連想した
http://dl10.getuploader.com/g/dion555/2099/jikken0716.jpg

水冷チューブ蠢いて車のエンジンルームのようだ

HD7970x2枚挿しの方の構成って、電源1200wにX79 Extreme9？
マザー変えるのメンドイ
x8レーンだとどれぐらい速度オチるんでしょう

1200も要らねーよ
x8の差とか誤差範囲だよ

>>272
TripcodeFinderでは
HD5870のx16とx8で差がわからなかったので
同じと考えていいと思います。

素晴らしい性能

>>258
これ再現出来ました。正規表現関連のバグは見つけにくいので有難いです。
これから調べてみます。

>>257
CUI版の出力をログに記録するオプションをGUI版につけておきました。
ログの内容は見ればわかると思いますが、わからなかったらいつでも聞いて下さい。

予定4時間で一つだけど15時間で一つもでなかった…あるあるですか

>>278
それは完全にあるあるです。1時間で出ることもあれば1日でもでないこともあります。

>>275
今回の高速化で性能的にはほぼ満足できるようになったのですが、
唯一残念なのが6990での速度がHashcatに負けていることです。
絶対に何か見落としているはずなので、なんとかしたいところです。

>>258
これ、最初はバグが再現できたかと思ったのですが、正規表現のパターンの
展開に時間がかかっていただけでした。OCしたCore i7-3770Kで1分40秒
かかったので、◆YSRKENkO6Yさんの環境でも多分5〜10分ぐらい放って
おけば検索が開始されるでしょう。どこで時間がかかっているのか、
もうちょっと調べてみます。

----

TARGET(S)
=========
0: "^[mMW][mMW][mMW][mMW][mMW][mMW][mMW][mMW][mMW][mMW][mMW]" (regex)
1: "^[Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm][Mm]" (regex)

TRIPCODES
=========

STATUS
======
Performing a forward-matching search
for 175099 patterns (243 chunks) with 10 to 11 characters on CPU and GPU(s):

>>259
遅れまして&ご迷惑をおかけしてすみません
やはり原因は電源設定だったようで、なぜか「バランス」を設定していたので「高パフォーマンス」に変更したところ直りました
また、報告としては0.08 alpha4から0.08 alpha5にバージョンアップしたところ>>224に比べて30%~40%ほど速度が向上しました

>>281
展開後に同じものができるパターンがダメなんじゃね？

>>281
>パターンの展開に時間がかかっていただけ
「そっかーならマターリ待てば解決だね」とはちょっと言いたくないかも……
暇があったら再実験するかもしれません

>>283
流石ですねｗ 重複したパターンを取り除く処理に時間がかかっていただけでした。

>>258
上の処理を修正して問題を解決することができました。次の開発版では
パターンの展開は一瞬で終わるはずです。

>>282
それはなによりです。わざわざ報告をしていただいてありがとうございました。

>>285
>パターンの展開は一瞬で終わる
良かった。

ところで>>277で思ったのですが、その出力する数値の有効精度はどれほどなのでしょう？

>>287
> ところで>>277で思ったのですが、その出力する数値の有効精度はどれほどなのでしょう？

さあどうなんでしょう… 生成されたトリップの個数はかなり正確ですけど、
経過時間のほうはWindows次第ですからねえ。

>>288
timeGetTime的に考えると1ms程度……と言うことは、10秒毎の瞬時値表示は
多く取っても有効精度5桁ですね。とは言っても速く出力できればそれ以上でも気にしませんが

>>289
そんなところでしょうかね。ただ、トリップを生成しているスレッドと
速度を測定しているスレッドは別なので、瞬間的な速度はかなり偶然に
左右されます。CPU検索の区間速度はかなり正確ですけど、GPU検索の場合は
カーネルの実行時間によりまちまちです。まあ速度測定するときは
長時間の平均速度を使っているので問題ないんですけど、瞬間的な速度の
測定の方法も見なおしたほうがいいかもしれません。

>>290
>GPU検索の場合はカーネルの実行時間によりまちまち
道理でGPU速度の方が数値のばらつきが大きいと……

まあログが出力されるようになったら標準偏差の形でハッキリと分かるのですが

1GPUの場合は瞬間速度の分布はbimodalになるはずです。

しかしこれ、安定版を早めに出すか、AMDのVLIWのための最適化を続けるべきか
迷うところだな…

>>292
>bimodal(二峰性)
道理でGPUの速度が(ry

うぐぐ……その2択なら、最適化(高速化)の方に注力してくださいっ！

>>293
もうちょっと速くならないか試してみて、時間が掛かり過ぎるようなら
次の安定版を出してしまうことにします。

MTFのユーザーを不安にさせるのもなんなので、一応これ貼っておきます。

MERIKEN's Tripcode Finder‎ > ‎実効ヒット率について
http://www.meriken2ch.com/programming/merikens-tripcode-finder/hit-ratio

検索速度を予測できないかなと、
PassMark値と検索速度(12桁)を比較したら妙なことになった(0.08a5)

　　　　　　 　 　 　 　 　 x 　 　 　 y
CPU　　　　　 　 　 　 PM値　 MTPS
Athlon X2 QL-64　 　.765　　　 8.56
Core i5-3210M　　　　3822　　40.61
Celeron M 380　 　 　 395 　 　 2.77
Core 2 Quad Q8400　3248　　46.13
Core 2 Duo E8500　　2313　　27.37
Core i3-2130　　　　　4024　　36.58
Core i5-3210M　　　　3822　　41.78
Core i5-560M 　 　 　 2651 　 27.47
Dual Core E2180　 　 1038　　16.02
Core 2 Duo E7200　　1646　　20.68
Core 2 Duo E7400　　1744　　23.77
Core i7-2600k　　　　 8527　　78.45
Athlon X2 5050e　　　1406　　10.26
Atom N280　　　 　 　 300　　　 3.57
※検索方法は全てCPUのみのもので、SHA-1最適化は最速になるものにした

ここから回帰分析すると、
y=(0.009272±0.000654)x+(3.786±2.147)　補正R^2:0.9389　//通常
y=(0.009116±0.000471)x+(3.234±1.545) 補正R^2:0.9689 //C2Qを除いたもの
となる。そこまではいいんだが、Core i7-2600kを除いて散布図を描いてみると、
Core 2 Duo,Core 2 Quad系列とそれ以外とに分布が分かれているような気がする……
自作のグラフで示すとこんな感じ↓
ttp://up3.viploader.net/pc/src/vlpc013286.png

>>296
MTFの性能に関係あるのはSSE2の、しかも整数演算だけなので、一般的な
ベンチマークの値とは多少ずれるのは仕方がないですね。やっぱりCPUによって
得手不得手があるんでしょう。

あれからVLIW向けのさらなる最適化を試みたんですが、
なかなかうまくいきません。Jens氏の最適化の手法がVLIWにだけ
無効な理由を探っているところですが、なかなか時間がかかりそうです。
というわけで、0.08の安定版を先に出してしまうことにしました。

新しい開発版です。

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

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

・ログを保存するオプションをGUI版に追加。
・OpenCLドライバがインストールされていないと起動できない不具合を修正。
・正規表現のパターンの展開に時間がかかりすぎるバグの修正。

間違えた! 新しいバージョンは"Alpha 6"ではなく"Beta 1"でした。

恒例の最高速の測定です。最適化の結果が順当に反映されています。

【GPU0】DIAMOND 6990PE54G Radeon HD 6990 4GB @ 910MHz (OC)
【GPU1】Gigabyte GV-R7970C-3GD Radeon HD 7970 @ 1130MHz (OC)
【GPU2】DIAMOND 6990PE54G Radeon HD 6990 4GB @ 910MHz (OC)
【CPU】AMD Phenom II X6 1100T (定格)
【OS】 Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.08 Beta 1
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】N/A
【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【その他のオプション】-g
【Display Driver】Catalyst 12.11 Beta8
【10分間の平均速度】8879.39 tripcodes/s
【GPUの平均速度】8879.39 tripcodes/s
【CPUの平均速度】N/A
【GPUの使用率】73〜99%
【GPUの温度】75〜86℃
【その他】GPUのみ。6990のCore Voltageを1150mVに、Power Limitを
　　　　　+15%に設定。

またやらかしてしまった。 "8879.39 tripcodes/s"って一体…
今日はミスが多いなあ。もう一回貼り直したらちょっと休もう。

恒例の最高速の測定です。最適化の結果が順当に反映されています。

【GPU0】DIAMOND 6990PE54G Radeon HD 6990 4GB @ 910MHz (OC)
【GPU1】Gigabyte GV-R7970C-3GD Radeon HD 7970 @ 1130MHz (OC)
【GPU2】DIAMOND 6990PE54G Radeon HD 6990 4GB @ 910MHz (OC)
【CPU】AMD Phenom II X6 1100T (定格)
【OS】 Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.08 Beta 1
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】N/A
【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【その他のオプション】-g
【Display Driver】Catalyst 12.11 Beta8
【10分間の平均速度】8879.39M tripcodes/s
【GPUの平均速度】8879.39M tripcodes/s
【CPUの平均速度】N/A
【GPUの使用率】73〜99%
【GPUの温度】75〜86℃
【その他】GPUのみ。6990のCore Voltageを1150mVに、Power Limitを
　　　　　+15%に設定。

10Gに達するのが先か、検索君の寿命が先か・・・

ログ文法わっかんねｗｗｗｗ
とりあえず、左端が経過秒数なんだろうけど……
ttp://up3.viploader.net/pc/src/vlpc013302.png

……なんて言ってたら唐突に理解したでござる
「経過秒数,合計速度(瞬時値),GPU速度(瞬時値),CPU速度(瞬時値),合計速度(平均値),予測時間(秒),
ハズレ率,総生成数,？,？,GPU速度(平均値),CPU速度(平均値),？」
※速度単位はTPS。「？」は不明ということ

MERIKENさん詳説お願いします

>>306
ほとんどあってます。「ハズレ率」は「実際のヒット率と予測の差」で、
不明な部分は、「有効なヒット数」「CUDAデバイスの最適化の進行状況(1で進行中)」
「無効なヒット数」です。

>>304
さあどっちでしょうｗ 検索君1号の電源とマザボにはお金をかけたので
結構保ってくれるような気もしますけど、なんせ使い方がめちゃくちゃですからねえ。
まあどう転んでもいいケーススタディになるでしょう。

MTF圧倒的大勝利！！！！！

【GPU】たぶんIntel HD2000
【CPU】Intel Celeron 847 (1.1GHz)
【OS】 Microsoft Windows 8 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Beta 1
【トリップの種類】12桁
【10分間の平均速度】11.35M tripcodes/s

もちろんCPU Onlyですが、参考まで。

予告していた通り、解析ツールを公開します↓。
ttp://www1.axfc.net/uploader/so/2780060.zip
ttp://up3.viploader.net/pc/src/vlpc013309.png

画像リンクを見れば分かる通り、このソフトは、
出力ログを解析してグラフとして表示することができます。
また、平均値・平均二乗誤差を表示する機能も備え、
平均値はどこまで信頼できるのかも一目で分かる仕様に。
ぜひ使ってみて下さい。

あ、Beta1も試しました。正規表現の展開が一瞬になっとるｗｗｗ
ただ、なぜか後方一致含みのを回すと、なぜか表示が愉快なこと↓になるのですが……
--------------------------------------------------------------------------------
TRIPCODES
=========




STATUS :
====== :
Performing a forward- and backward-matching search :
for 517808 patterns (102094 chunks) with 8 to 12 characters on CPU and GPU(s):
CUDA0: 42.5M TPS, 256 blocks/SM
CUDA0: 42.5M TPS, 256 blocks/SM

0.002T tripcodes were generated in 0d 0h 0m 30s at:
68.38M tripcodes/s (current)
GPU: 44.48M tripcodes/s
CPU: 23.90M tripcodes/s
64.74M tripcodes/s (average)
GPU: 40.76M tripcodes/s
CPU: 23.97M tripcodes/s
On average, it takes 5.4 hours to find one match at this speed.

No matches were found yet.
--------------------------------------------------------------------------------
※検索速度が2割ぐらい落ちる(80→60)のはまだしもなぜ表示が分身するんでしょう……？

トリップ検索ソフトでの正規表現のマッチングって高速にやるのはどうやってるんですか？

Windows8 Pro x64+ Driver306.97
QuadroFX4600(G80)+GeForce8800GTS(G80)の同時利用の組み合わせで
MERIKENsTripcodeFinder_0.08_Beta_1のGUI検索をすると
CUDA検索(12桁)を利用している最中に検索停止を直接押すとドライバが応答停止に陥るので
一時停止を押してから検索停止を押すという手順を取らないといけないみたいですが
CUI検索では問題ないみたいですしこれは不具合ではないですかね？

追記ですが使用したPCは>>187の環境にGPUだけを乗せ換えた状態です

後もう一つ報告。
「^[il.][il.][il.][il.][il.][il.][il.][il.][il.][il.][il.]#[il.]」というターゲット指定が、
GUI版だと通らないのにCUI版だと通る(#の前にスペースを開けると大丈夫)
検索中に速度表示が結構な頻度で更新されないし、>>314もあるし、謎すぎるぜGUI版!

なぜログ出力機能がGUI版だけなんだorz

>>314
これはドライバの問題で、カードの組み合わせやブロック数の大きさにによって
稀に発生するんですよね。まあでもアプリ側の処理で回避できそうなので
なんとかしてみます。

>>312
これはおかしいですね。調べてみます。この問題を再現できるパターンがあると
有難いんですが…

>>316
> 「^[il.][il.][il.][il.][il.][il.][il.][il.][il.][il.][il.]#[il.]」というターゲット指定が、
> GUI版だと通らないのにCUI版だと通る(#の前にスペースを開けると大丈夫)

これは仕様です。GUI版ではコメントは使えません。

> 検索中に速度表示が結構な頻度で更新されないし、>>314もあるし、謎すぎるぜGUI版!

YSRKENさんの場合はブロック数が大きすぎるんだと思います。
ブロック数が大きいとGPUに負荷がかかり過ぎて画面表示が安定しなく
なっちゃうんですよね。

> なぜログ出力機能がGUI版だけなんだorz

あれはCUI版がGUI版に投げているデータを保存してるだけで、
CUI版だけを走らせているときはあのデータは作られないんですよ。
CUI版をこれ以上複雑にしたくなかったのでこんなことになっています。

>>313
正規表現のパターンを部分的に展開してハッシュ値を計算しておいて、
生成されたトリップをまずハッシュ値と比較するようにしています。
こうすればマッチしないほとんどのトリップを弾けるので、非常に
高速に検索出来ます。

>>311
ちょっと試してみましたけど、視覚化されるのはなかなか面白いですね。
ただ途中でトリップがヒットするとちゃんと動作しないようですが…

>>316
> なぜログ出力機能がGUI版だけなんだorz

あ、あと書き忘れてたけど、CUI版でも--redirectionオプションを最初に
指定してやればログの内容は標準出力に出力されます。

>>312
これ再現出来ました。直しておいたので、次の開発版では直っています。

>>314
これも直しておきました。これで検索停止時にフリーズすることはないはずです。

素人が単純に考えると、桁数の少ない１０桁の方が速い様な気がするんだけど、
これは何故に１２桁の方が速いの？？
本来なら、１０完とか１２完が欲しいんだけど、まぁそんなの出る訳ないので、
６〜７程度で妥協してるのですが、桁数が多いと、その分、後ろに余計な文字が
沢山付くので、出来れば１０桁で検索したいんだけど、遅くなるからなぁ・・・

>>324
これ、12桁と10桁の計算方法が全然違ってて、10桁のほうが猛烈に遅いんですよ。
12桁が一段落したら、また10桁に挑戦したいですねえ。

>>319
>GUI版ではコメントは使えません
！？

>>321
早速修正しますぜ！

>>322
ほほう……φ(.. )ﾒﾓｼﾃｵｺｳ

>>324
10桁(DES)と12桁(SHA-1)では後者の方が計算しやすいから
と言うか9完までは(前方一致なら)理屈上発見確率自体は同じなので
純粋に検索速度が速い方＝お目当てが速く出る方と思えばOK

ちなみに全数とか飛石とか、全桁使うのが前提のトリップは
速度差を考慮しても10桁の方が速いことが多い
(GPUの頑張りによってはなんとか12桁側が勝つことも)

>>320
ありがとうございました

MTF's LogAnalyzer Ver.1.1を公開しました。
　ver.1.1 2012/02/04
　・トリップが発見されている時に表示がおかしくなる不具合を修正。
　・Ctrlキーを押すと動作が「高速化」するように改良。
　・グラフの配色を見やすいように変更。

DL→http://www1.axfc.net/uploader/so/2780423.zip

MERIKENさんにお願いがあります。GUIの生成されたトリップの数は、
数字の羅列でいまいちピンとこないので、【万、億、兆、京、垓、予、
穣、溝、澗、正、載、極、恒河沙、阿僧祇、那由多、不可思議、無量大数】
という単位を表示してくれたらな〜って思います。
常に【無量大数】が表示されるわけではなく、単位が上がるたびに次の単位が
表示されると、TEXT-GUI的に自己満足度が上がりますｗ

>>329
そ の 発 想 は な か っ た
まあ、確かに桁数が多すぎると見づらくなるもんね……
せめてGUIだけでもカンマ区切りとかが出来るようにとはちょっと思った

>>329
それ、最初にGUI版を作った時にやったら面白いかなと思ったんですけど、
急いでたので結局ほったらかしになってたんですよね。
次のバージョン(0.09)で対応します。

>>328
早いですねｗ 今日はもう寝るのでまた明日チェックします。

すみません。検索実行ボタンを押すと、
「アプリケーションを正しく起動できませんでした(0xc000007b)。」
と出てしまい、強制終了になるんですが、どうしたらよいでしょうか？

>>333
OSとCPUとビデオカードとMTFのバージョンを教えて下さい。

詳細設定 > 検索デバイス > CPU > CPUの命令セット

から「x86+SSE2」を選んで実行するとどうなりますか?

>>333
前スレのこの報告と同じ問題かもしれません。
最新の開発版を試してみて下さい。

> 【CPU】Intel Core i7-620M @ 2.67GHz
> 【OS】Microsoft Windows 7 64bit SP1 (DSP版)
> 【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
> 【トリップの種類】12桁
> 【CPUの10分間の平均速度】28.07Mtripcodes/s
> 【部屋の温度】20℃
> 【その他】MTF0.07から使い始めている初心者ですが、CPUの命令セットを
> 　x64+SSE2にすると「0xc000007b」のエラーが出て終了してしまいます。
> 　x86+SSE2は正常に検索してくれます。PCのスペックの問題でしょうか？

すみませ〜ん質問です〜
正規表現のn回繰り返し
{n}の{}は使えないみたいですが、n回繰り返しを使う方法はありますか？

正規表現の使用可否が書かれたページか書類を見た記憶があるのですが見つけられず…

遅くなって申し訳ありません。
ディスプレードライバを念のため更新していたら、PCが不安定になってしまいました。
今、安定させるためにあれこれ試しております。
もう少ししたら報告させて頂きます。
申し訳ありませんm(_ _)m

新しい開発版です。新しいバグが見つからなければこれを新しい安定版に
する予定です。

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

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

・検索終了時に動作が不安定になる不具合の修正。
・CUI版の画面表示が乱れるバグの修正。

>>336
このソフトで使える正規表現については、ソフトに付属するpatterns.txtにコメントで記してある
……場合もある(うっかり書き忘れたパターン)。とりあえず最新のBeta1には入っているよ

{n]は自力で展開するしか無いんじゃね？
自分のソフトでおまけ機能として加えてみるかな＞n回繰り返し

>>336
> n回繰り返しを使う方法はありますか？

残念ながらありません。{n}には次のバージョンで対応する予定です。

> 正規表現の使用可否が書かれたページか書類を見た記憶があるのですが見つけられず…

バージョンによってpatterns.txtにかかれていたりいなかったりするのですが、
0.08 Beta 2の配布パッケージには入れておきました。

>>337
了解しました〜

>>339>>340
どうもありがとうございます。
patterns.txtの説明部分をアプデの時のどこかで削除してしまったみたいです。
ご迷惑おかけしましたぁ。
次バージョン{n}楽しみにしております。

>>340
>{n}には次のバージョンで対応する予定
個人的には、懐かしの鏡だの山彦だのを再現させたいので、
後方参照(\1〜\9みたいな)を実装してもらいたいです。

#仮にもし実装されたとして、待て屋への変換どうしよう……

遅くなりまして申し訳ありません。

【OS】Microsoft Windows 7 Professional 64-bit SP1
【CPU】Intel Core i5 750 @ 2.67GHz
【ビデオカード】ATI Radeon HD 5700 Series (Sapphire/PCPartner)
【MTF】ver.0.07

ビデオカードのドライバが最新で13-1だったのでインストールしようとしたのですが、
わたしのPCではドライバが弾かれてしまうようで、仕方なく12-4に戻してようやくPCが安定しました。

すると、MTFも問題なく動作しました。現在安定して走っております。

現在、GPU:500.25M, CPU:10.02Mで動作しています。


お騒がせして申し訳ありませんでした。今後ともどうぞよろしくお願いしますm(_ _)m

>>339
>>342
{n}とか{n,m}とかはめんどくさくなりそうだったので、最初に正規表現の
ルーチンを書いたときには入れなかったんです。まあでもちょっと
正規表現のルーチンに気になるところもあるし、この際なので
追加することにします。

>>343
後方参照か〜 おもしろそうだからちょっとやってみようかな。

>>344
それはよかった。安心しました。

コマンドラインオプションで複数パターンファイルの読み込みに対応して欲しいなー、なんて要望があるんですが如何でしょう。
数万行のパターンを小分けにして管理するのに便利かなと思います。

>>328
「#Error 3」って出て動かないですよ〜

>>347
いいですね。やりませう。

>>349
やった！ありがとうございますー。

OpenCL対応のグラボだと10桁トリップ未対応というのは、
いつか対応する予定があるのでしょうか？

>>344
これ書き忘れていましたけど、Catalyst 13.1だとどうも安定しないみたいですね。
私もCatalyst 12.11 Beta8に戻しました。

>>351
7xxxシリーズ限定の試験的なルーチンは既に出来上がっているのですが、
性能がイマイチなのでどうしようか考えているところです。

>>352
情報有難うございます。12.11探して入れてみたら、ちゃんとインストール成功しました。Beta11しか見つかりませんでしたが……。

現在ver.0.07で使わせて頂いてますが、マザーの温度が85℃くらい行っちゃいます。そういうものでしょうか？
あと、7文字のトリップ作りたいんですが、5時間かけても見つかりませんでした。何度もトライすれば、そのうち生成されますでしょうか？

>>353
CPU検索速度がそれぐらいならGPUオンリーにした方が安全かも？

>>354
そうなんですか。じゃあそれでやってみます！ありがとうございます。

マザボ温度が85てやばくね

やばいです。GPUだけのほうがいいですね。

>>353
> 7文字のトリップ作りたいんですが、5時間かけても見つかりませんでした。

そのうち見つかりますので辛抱強く待ちましょう。

>>348
え！？状況を詳しく教えて下さい。
再現可能なログファイルがあると助かります。

>>353
えーと、「GPU:500.25M, CPU:10.02M」が平均値とすると、7完の
発見予定時間は1.7時間ぐらいなはず(5時間ぶん回して出ない確率は12%)
なんだけど……こればっかりは運としか言えないな

とりあえず次の開発版の作業をはじめました。
System.Numerics.Bigintegerクラスを使って累計の表示の実装をしています。
しかしやっぱりC#は便利ですね〜

>>359
じゃああとでログをうｐしときます。

>>356-357見て思ったんだけど、
自分の(ノート)PC大丈夫かな……

HD0 : 32℃(内蔵)
Temp1 : 84℃(マザボ)
Core 0 : 84℃
Core 1 : 80℃
HD2 : 41℃
GPU : 78℃
(検索中。SpeedFan調べ)

ノートで検索する人って基本バカだよな

>>362
う〜ん、取りあえずもうちょっと冷したほうがいいですねえ。

>>363
お金持ちとも言う
壊れたら買い換えればいいんですよ

>>362
Temp1って石の温度じゃないの

>>352
自分が使っているのは7750なので、いつか対応することを期待しています！

>>359
自分の環境でも同様のエラーが起きました
外部DLLを同封し忘れたとか、ファイルの宛先に不備があったとかありませんか？
環境はwindows 8 Proです

自分の環境･検索パターンでバグが出ないか一応回してみました。

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows XP Professional 32-bit SP3
【バージョン】MERIKEN's Tripcode Finder GUI 0.08 Beta 2
【トリップの種類】12桁
【10分間の平均速度（括弧内は「SHA-1の最適化」の設定）】10.26(有効) Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）

【CPU】Intel Atom CPU N280（定格稼働）
【OS】Windows 7 Starter SP1
【バージョン】MERIKEN's Tripcode Finder GUI 0.08 Beta 2
【トリップの種類】12桁
【10分間の平均速度（括弧内は「SHA-1の最適化」の設定）】3.62(有効) Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）

>>262から比べて速度変わらず、バグは無さそう。

>>331
数字の単位の「…垓、予、穣、…」の中の「予」という漢字は、
実は「禾予」Unicode 𥝱という漢字を書きたかったんですけど、
２ちゃんの一部の板ではUnicodeに変換されて表示されてしまうので、
しかたなく書いた次第であります。累計表示の形式はカンマで区切るか
どうかわかりませんが、補足ということでよろしくお願いします。

>>361
早めにお願いします
>>363
言うほど？
前のノーパソも長時間ぶん回すのが普通だったから、感覚が鈍ってるのかな……
>>369
「禾+予」(U+25771) は、本来は別の漢字(U+79ED) で、代用字として杼が使われることもあるようですよ？

ログと言えば、なぜか今日、WinXP32bitGeForce積みC2Qマシンで10桁検索(CPU+GPU)しようとしたら、
「CUDA FUNCTION FALL FAILED」ってエラーが出てGPUが使えなかったんですが……
(-x 48ぐらいに下げても出てくるという謎な事態。12桁の方はCPU+GPUも普通に動いたんだけど)
ファイル(コマンドプロンプトのをコピペしただけ)→http://www1.axfc.net/uploader/so/2782436.txt

>>358 >>359
了解しました。ありがとうございます！

GTX560、core i7 3770にてGPUで検索すると、
検索速度が 0.05　0.06　0.07　0.08beta2 の順に
300M　295M　295M　273M とだんだん下がってきてるなあ。
いずれもGUI版で、1SMあたりのブロック数は4にしてる。
ブロック数を増やすとかなりスピード上がるみたいだけど、
PC作業中に裏で走らせてるから軽さ重視なんだ。
ちなみにパターンは7-9桁の先頭一致が85パターン。

>>370
今やってる作業がおわったらログをうｐしときます。
Compute Capabilityが1.1なので、そのPCだとGPUの共有メモリが足りなくて
10桁トリップ検索は動かないかもしれないですねえ。
-xの値をもっと下げたらどうなりますか? 8まで下げられるはずです。

>>372
報告ありがとうございます。ブロック数を128辺りにすれば
多分0.08のほうが速くなるでしょう。基本的にブロック数をそこまで低くしての
使用は想定していないので… 0.08での最適化をきるオプションを
CUDA版に付けられないか検討してみますが、検索ルーチンがさらに複雑になって
しまうので難しいかもしれません。

【GPU】GeForce GTX 650
【CPU】Core i3-3220 @ 3.3GHz
【OS】Win 7 Pro 64bit
【バージョン】MERIKEN's Tripcode Finder 0.08 Beta 2
【トリップの種類】10桁
【その他のオプション】--use-one-byte-characters-for-keys
【Display Driver】3.10.90
【10分間の平均速度】13.47M tripcodes/s
【GPUの平均速度】8.96M tripcodes/s
【CPUの平均速度】4.51M tripcodes/s
【その他】7桁先頭一致(2パターン)

GUI版の場合は、検索終了時特に問題がないのですが
CUI版を終了するとき不安定なようです

ところで、CUI版の停止方法って「閉じる」でいいんです？

>>375
Ctrl+Cでは

>>368
わざわざありがとうございます。ちょっと安心しましたｗ

>>369
さっきこの機能を付け終わりました。一応「無量大数」まで表示できるように
なってますけど、さすがにここまでは無理でしょうねえｗ

>>375
> CUI版を終了するとき不安定なようです

次のバージョンで直せないか検討してみます。

> ところで、CUI版の停止方法って「閉じる」でいいんです？

Ctrl+Cですけど、大して違いはないかもしれません。

>>370
はいどうぞ。
http://www.meriken2ch.com/files/2013-02-05-CUIOutput.log.zip
検索デバイスはGPUとCPUです。

>>379
さーて展開してD&D……おお、確かにエラーが出る。と言うか、
トリップ発見しまくっている状況では同秒数の報告が連発している……だと！？
--------------------
×
[status],80
[tripcode],◆
[tripcode],◆
[status],90
[tripcode],◆
--------------------
○
[status],80
[tripcode],◆
[status],80
[tripcode],◆
[status],80
[status],90
[tripcode],◆
--------------------
しかも、「[started]\n[tripcode],◆\n[started]」なんかも平気で起こる仕様……
なんとか修正しました。

[MTF's LogAnalyzer Ver.1.2]
　・特定パターンにおいてソフトが落ちる不具合を修正。
　・エラー時の耐性を強化。
　・Readmeのlog文法の項目に大幅な加筆。それに伴って、読み込みルーチンも書き直した。
http://www1.axfc.net/uploader/so/2782688.zip

>>378
公式はCtrl+Cですか、了解です
Ctrl+Cで終了した場合でも不安定だった気がしますが、また試してみますね

ところで、1バイト文字制限ですが
半角カナも除外できるオプションとか…ないですかね？

>>380
今度はちゃんと動いてますね。よかったよかった。

>>381
> 半角カナも除外できるオプションとか…ないですかね？

これ検討したんですけど、これをやると文字の数が少なすぎてこれまでの
検索ルーチンが動かなくなっちゃうので今回は見送りました。
あとでもうちょっと詳しく検討する予定ですけど、検索のスピードが全体的に
落ちてしまう可能性があるので実現するかどうかは微妙なところです。

>>383
お返事ありがとうございます
スピード落ちちゃったら本末転倒ですもんね
望みはうすいようですが、淡い期待を胸に仕舞っておきます

CUI版の終了時ですが、Ctrl+Cで終了しても同じ症状です
再現性は今のところ100%ですね
GUI版のほうもちょっと触ってましたら、まれに不安定になるようです
再現条件は不明です

というかGUI版も結果の自動保存あったんですね！
おとなしくGUI版使います！

>>384
> CUI版の終了時ですが、Ctrl+Cで終了しても同じ症状です
> 再現性は今のところ100%ですね
> GUI版のほうもちょっと触ってましたら、まれに不安定になるようです
> 再現条件は不明です

これだと原因は電源かマザボあたりかもしれないですねえ。
検索中はかなりの負荷がシステムにかかるので、電源供給が安定しないと
こういうことが起こりやすいんです。GUI版は結構使いやすさに気を使って作ったので
全然悪くないと思いますよｗ

ついさっき新しい開発版(0.09 Alpha 1)のGUI版に累計と稼働率を表示させる機能を
付けました。ずっと欲しかった機能なので個人的に非常に満足度が高いですｗ
0.09では使い勝手を良くするための細かい機能の追加を行う予定です。
次は何にしようかな〜

>>386
> ついさっき新しい開発版(0.09 Alpha 1)のGUI版に累計と稼働率を表示させる機能を
> 付けました。ずっと欲しかった機能なので個人的に非常に満足度が高いですｗ
何処からダウンロード出来ますか？
サイトには、まだあありませんが・・・

>>387
現在絶賛制作中ですw 多分今週末辺りにうｐできると思います。

取りあえず次は正規表現に手を付けてみました。試しに'?'を付けてみたけど
結構すんなりいきました。これなら"{n}"と"{n,m}"もなんとかなりそうです。

>>382
　　_n
　（　l　　　　_、_
　 ＼ ＼　（ <_,`　）
　　　ヽ___￣￣　 ） 　　ｵｯｹｰ!!
　　　　　/ 　 　/

>>386
>累計と稼働率
何の累計と稼働率かｋｗｓｋ。

>>385
電源は結構余裕あるはずなんですがねー
マザボが貧弱？なのかなー

まあ終了時に不安定になるだけだから実害ないですしね！
もっとクリティカルなことが発生したらまた報告させていただきます！
ありがとでした！

今の季節で不安定なら夏場は酷いことになりそう

>>373
報告遅れましたが、-x 8でも同じエラーが出ます＞>>370のC2Qマシン
いや12桁だけでも十分に助かる（7完1タゲで163.48M出る）のですが、まったく不思議です……

>>390
検索時間と、生成されたトリップと、ヒットしたトリップです。
「稼働率」は最初にアプリを起動したときから計算した、実際に検索が行われている
時間の割合です。つけてみてわかったけど、両方共かなり面白い機能です。

>>393
そりゃGeForce 9800 GTですからねえ。CUDAをサポートしている
グラボではかなり古い部類でしょう。MTFの10桁トリップ検索の
CUDA版は580のリソースを目一杯使うようになっているので、
間違いなくレジスタ数が足りないか共有メモリが足りないかのどちらかです。

正規表現の"{n}"と"{n,m}"の実装も終わりました。
正規表現のルーチンに手を入れるのは1年半ぶりでちょっと心配だったんですけど、
割りとすんなり実装出来ました。後は後方参照だけど、これは今の正規表現の
ルーチンに組み込むことが出来るかどうかすらわからないので、のんびり
取り組むことにします。

MERIKENさんのって古いグラボ使うより新しいの使うほうが
速度でるようなチューンなのでしょうか？
うちのHD6770もそこまでいいグラボではないけど600Mもでる

それと
もし10桁がスピードでるようになったら10/12桁同時検索ってムリですかね笑
それがムリなら時間指定で自動切換え検索とか
現状はまてや10桁、MERIKEN12桁の2台でやってますがいずれ1台環境になるので
10桁捨てるしかないのかなーと思案中です

そりゃ新しい方が速いんじゃ

>>386
個人的にはGPUでヒットしたものを検算する機能が欲しいです。
整数演算というのもありますし、メモリアクセスが極端に少なくて電力リミッターに引っかかりにくいなど
他のアプリとはかなり傾向が異なり、一般的なツールでは動作テストも難しいですし。

指定時刻に検索を開始したり停止したりする機能とかも面白いかもしれません。

>>399
ゲフォに計算ミスをする個体があるって話を心配してるのか？
421枚テストして72枚がゴミだったってやつか。ｗｗｗ

なにそれこわい

GDDR5ではメモコンにECC導入されてかなりマシになったよ

>>397
> MERIKENさんのって古いグラボ使うより新しいの使うほうが
> 速度でるようなチューンなのでしょうか？

12桁はそうでもないですよ。10桁は色々と条件が厳しいのです。

> もし10桁がスピードでるようになったら10/12桁同時検索ってムリですかね笑

10桁でスピードが出るようになったらまた考えますｗ
速度向上のためのアイディアがないこともないんですけど、
今でもかなりアクロバティックなことしてるので、どうしようか思案中です。

>>399
> 個人的にはGPUでヒットしたものを検算する機能が欲しいです。

「デバイス診断」の機能をつけるときに一緒につけます。

> 指定時刻に検索を開始したり停止したりする機能とかも面白いかもしれません。

一定時間検索を実行したら停止する機能はつける予定です。

１０桁も、１２桁みたいにDESじゃなくてSHA-1ってやつで計算すれば速くなるの？

>>405
これは新しいですねｗ 2ちゃんねるが10桁にDES、12桁にSHA-1を
使っているのでそれに合わせる必要があるんです。

基本的なこと分かってない奴が無理難題書くのはやめろ

聴くだけなんだし別にええやろ
あんまりアレなら答えないだろうし

そういうのからたまに良いものが生まれるんだよ

じゃ、よく分かってる私が書くのはいいのね！！！！
ウェブブラウザからアクセスしたら、>>386 みたいなのとか各種内部情報をグラフィカルに表示できるようにしよう！

いや、うにでやろうと計画してたことなんだけどネ。ｗ

>>400
そんな話もありましたねｗ
OC時の心配をしていたのですが、定格でも安心できないですね。

>>402
GeForceやRadeonでは無効化されていたりしないのでしょうか？

>>404
デバイス診断ですか、どのようなものになるのかも含めて楽しみに待ちます。

深夜等の特定時間帯にだけ実行したいという需要もあるかと思ったのですが、
一定時間で停止の機能があれば、タスクスケジューラ等と組み合わせたりもやりやすそうですね。

こんにちは。
トリップがヒットしないうちにPCの電源を落とすと、これまで生成されたトリップはリセットされてしまうと思うのですが、
次のPC立ち上げ時に、前回生成されたトリップを引き継いで検索再開、というのはできませんでしょうか？
ヒットするまで何日かかかる場合、ずっとPCを立ち上げておくのも難しいものでして……。

>>412
> 次のPC立ち上げ時に、前回生成されたトリップを引き継いで検索再開、というのはできませんでしょうか？
その疑問というか要望は、検索を始めた当初、必ず皆が持つモノですな。ｗ
しかし、そんな事は一切心配する必要がない程、８桁トリップですら、
同じトリップを検索してしまう確率はゼロに近いらしい。
まして、このソフトでメインなのは１２桁だしね。

>>412
> これまで生成されたトリップはリセットされてしまうと思うのですが、

トリップのキーは乱数で生成されていて、ヒットしなかったトリップは全て
破棄されるので、心配する必要は全くないです。

前にもこの質問あったし、FAQ作ってテンプレに書いておいたほうが
いいのかな、これ。

>>413
早速の返信ありがとうございます。
ということは、仮に検索再開できたとしても、一からやり直しとヒットする確率は変わらないってことなんですね。
おかげさまで、PC落としたい時には落とすことができますｗ　有難うございましたm(_ _)m

>>414
返信ありがとうございます。
全て破棄、ですか。安心しました。ありがとうございます。
以前にあった質問だったようですね。チェックしてませんでした。申し訳ないです……。

>>416
だいぶ前の話なので心配しないで下さいｗ
次スレからテンプレに追加しておきます。

>>410
> じゃ、よく分かってる私が書くのはいいのね！！！！

どうぞどうぞｗ

> ウェブブラウザからアクセスしたら、>>386 みたいなのとか各種内部情報を
> グラフィカルに表示できるようにしよう！

ブラウザ用のインターフェースは分散処理の実装とセットで作成する予定です。

>>410
>ウェブブラウザからアクセス
つまり、出先から家のマシンにアクセスして状況を知りたい、みたいな……？
>>414
おｋ。修正しとく
尚テンプレは依頼スレが>>900超えた時に改めて公開する模様

>>419
>>417はこのスレのテンプレの話です。

> 尚テンプレは依頼スレが>>900超えた時に改めて公開する模様

依頼スレのテンプレはこちらで既に加筆・修正しているので、
新しい案があったら早めにお願いします。

>>420
現状はこんな感じ。突き合わせてくれるなら助かります
http://www1.axfc.net/uploader/so/2784966.txt

>>421
分かりました。「希望の9文字以上のﾄﾘｯﾌﾟはここだよな」スレの次スレを
立てるときは参考にします。

正規表現の後方参照は予想以上に実装に手間がかかるようです。
なによりも括弧内の[:alpha:]や[:digit:]などの特殊文字をあらかじめ
すべて展開しなければいけないのが性能的に非常に痛いです。
最初にパターン全体を調べて後方参照の有無を調べるようにすれば
必要以上の性能低下は避けられるんですが、めんどくさいことには
変わりありません。まあ乗りかかった船なので、ゴリ押しで
実装することにします。

とりあえず特殊文字のことは考えないで"\n"を実装してみました。
例えばこれを検索すると、

^([1-9]{3})\1/

このようなトリップがヒットして、

◆971971/NuqW2 #yF@ﾀwKyｱﾑ<ﾓｺ (79 46 40 C0 77 4B 79 B1 D1 3C D3 BA)
◆836836/ro3Wa #Bﾆ殲IPIﾏ∋5. (42 C6 9F 72 49 50 49 CF 81 B9 35 2E)
◆172172/XeNE8 #｣)N(Ｓ0ﾓｸaﾅﾋ (A3 29 4E 28 82 72 30 D3 B8 61 C5 CB)

この正規表現で検索すると、

^([1-9])([1-9])([1-9])\3\2\1/

次のようなトリップがヒットします。

◆571175/0Y/HV #f髓f+!迥L怒･ (66 E9 92 66 2B 21 E7 8A 4C 93 7B A5)
◆429924/EjLuK #ﾂ$ﾁ-ﾀxm膠7Cｪ (C2 24 C1 2D C0 78 6D E4 50 37 43 AA)
◆793397/COoHO #猝ﾄｸ画*ЙﾄC[ (E0 CA C4 B8 89 E6 2A 84 4A C4 43 5B)

あとは後方参照があるときに括弧内の特殊文字を展開する処理を追加して
やるだけです。

>>424
お、良い感じです。
正規表現らしくなってきましたね。

まてやに慣れてるとこの氷原難しい笑
早く慣れなきゃ

>>413
それはない
比較対象が少ないからそうなるだけで、10桁トリップでストックが670万行あるとそうとう目減りするよ。

>>421
乙です。テンプレが役立つのは一ヶ月以上先になりそうですが……
>>424
そうですこれですよこれ！提案した甲斐があったというものです
(最初のパターンで^を[]内のものと誤認してしまったのは秘密)

確かに後方参照は新しいですね。正直使いどころがいまいちよくわからないけど、
取りあえずつけといたら皆さん使ってくださるでしょうｗ

特殊文字の処理の実装も終わって、とりあえず後方参照が使えるように
なりました。しかし今回は正規表現のルーチンに手を入れたので結構緊張しました。
バグの混入だけは絶対に避けたいので、じっくりテストしてから
新しい開発版を公開することにします。

試しにテストしたパターンをもう一つ。

^([:digit:]){5}\4\3\2\1

これで次のような数字が左右対称に並んでいるトリップがヒットします。

◆309616903/Cc #W[]=｡&ｺｦKv7ｶ (57 5B 5D 3D A1 26 BA A6 4B 76 37 B6)
◆934272439AcX #Uw:｣U2*ﾄ5私ｫ (55 77 3A A3 55 32 2A C4 35 8E 84 AB)
◆006737600Rgd #<ｸ･=菻z騰ｹ5a (3C B8 A5 3D E4 D0 7A 93 AB B9 35 61)
◆615474516uSv #_.｢w3cB;W逵8 (5F 2E A2 77 33 63 42 3B 57 E7 9C 38)
◆133727331EA/ #ｷﾜ｣`uヶd､衝ﾀ (B7 DC A3 60 75 83 96 64 A4 8F D5 C0)

しかし分かる人にしかわからないですね、これｗ

新しい開発版の前に安定版を公開しておきます。

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

機能的には0.08 Beta 2と同等です。0.07からの主な変更点は以下の通りです。

・12桁トリップ検索の大幅な高速化。
・正規表現の検索の大幅な高速化。

>>429-430
キター！

N1とか言う冷却ファンを手に入れたので、6時間ほど回してみました(夜〜朝にかけての検索)。すると、
HD0 : 30℃(内蔵)
Temp1 : 80℃
Core 0 : 80℃
Core 1 : 76℃
HD2 : 40℃
GPU : 73℃
……下がっていますね。確かに

>>432
これTemp1は本当にマザボの温度ですか?
Core 0と同じだったら心配する必要はないですよ。

speedfunなんかで温度見てるからチップセットやVRMの温度なんて出てないだろうな
それ以前にノートがあり得ない

>>431
乙です！
ソースの差異を取って調べたところ、ほぼ全てVer表示の違いによるものでした。
でも、「MERIKENsTripcodeFinder.sln」の中で、27・28行目の一部分が
「Release|Win32」→「Release|x64」となっているのが気になります

>>433
ひょっとするとそうなのかも、とふとSpeedFanを見るとTemp1が44℃、Core0が45℃でした……
まあ気にしないことにします
>>434
「ノートPCじゃ値がデスクトップPCより正確に出ないだろ」という意味だと好意的に(？)受け止めることにします

>>435
> 「Release|Win32」→「Release|x64」となっているのが気になります

あ、これは問題ないです。Win32とx64の両方ビルドしてるので。

テストしてるCPUで個体認識されてたりするんだろうか。

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows XP Professional 32-bit SP3
【バージョン】MERIKEN's Tripcode Finder GUI 0.08 Beta 2→正式版
【トリップの種類】12桁
【10分間の平均速度】10.15 → 10.15 Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）。SHA-1の最適化：有効。

【CPU】Intel Atom CPU N280（定格稼働）
【OS】Windows 7 Starter SP1
【バージョン】MERIKEN's Tripcode Finder GUI 0.08 Beta 2→正式版
【トリップの種類】12桁
【10分間の平均速度】3.63 → 3.55 Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）。SHA-1の最適化：有効。

誤差の範囲内か。

熱は、CPUだけでブン回す分には関係無いんだろうなぁ。
一応常駐ソフトでチェックはしてるけど。

こっちは新しい開発版です。

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

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

・GUI版に累計と稼働率の表示を追加。
・正規表現に"?"と"{n}"と"{m,n}"と"\n"を追加。

今回は正規表現のルーチンにかなり手を入れているので、人柱専用です。
色々な正規表現のパターンを試してちゃんと動作するか確認して
いただけると助かります。

>>437
ちゃんと動いてますね。CPUの個体認識はしていません。
速度の変化は誤差の範囲内でしょう。

CPU検索が15Mだったのに、0.09 Alpha 1にしたらいきなり30Mになった・・・

>>440
いや自分のミスでした・・・＿|￣|○

人柱報告一番目のようだ。

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows XP Professional 32-bit SP3
【バージョン】MERIKEN's Tripcode Finder GUI 0.09 Alpha 1
【トリップの種類】12桁
【10分間の平均速度】0.08は>>437 → 10.19 Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）。SHA-1の最適化：有効。

誤差。
参考までに、私の検索パターンは「^([Aa]bdcef|ABCDEF)[:punct:]」（先頭一致で全部大文字もしくは小文字、または先頭だけ大文字で後小文字、その後に"."か"/"）といったところです。アルファベットは変えてありますが。
パターン少なく単純だから問題起こらないか。

どうやら大ポカをやらかしてしまっていたようで、
パターンによっては展開に時間が掛かり過ぎることが判明orz
今すぐ修正版を用意します。

>>442
わざわざ試してもらったのにすみません…

新しい開発版です。

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

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

・正規表現の展開に時間が掛かり過ぎる不具合を修正。

今度こそちゃんと動くはずです。

{n}
で、n桁のゾロ目ってどうやりますん？
例えば、7桁の数字のゾロ目が欲しい時、
[:digit:]{7}だと7桁の数列という事になりますよね。
これ7桁のゾロ目数列(文字列）ってどうしたらいいです？

>>445
「7桁のゾロ目数列」は

([:digit:])\1\1\1\1\1\1

ででます。

([:digit:])\1{6}っていうのもできるのかね

連投失礼
GUIの検索設定って保存されないです？
バージョンアップするたび設定する必要があるんですかね
何か見落としてるのかな…

>>447
出来るはずですけど、"([:digit:])\1{5}"を試してみたら、
同じトリップがダブってヒットしてますねえ。またデバッグが始まるお…

>>448
同じフォルダに新しい配布パッケージの.exeファイルとOpenCLフォルダを
上書きすれば設定は引き継がれます。

>>446>>447
どうもありがとうです。

(.)\1{6}
テストでこれぶん回して即停止したら、ディスプレイドライバブラックアウト、再起動したす。
これまでもちょくちょく有ったけど、今回はかなり長めにフリーズ

【GPU】GeForce GTX650Ti
【CPU】Corei5 3570
【OS】win8 pro
【バージョン】MERIKENsTripcodeFinder_0.09_Alpha_2
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】自動
【1CUあたりのワークアイテムの数(OpenCL)】
【1WGあたりのワークアイテムの数(OpenCL)】
【1GPUあたりの検索プロセスの数(OpenCL)】
【1検索プロセスあたりの検索スレッドの数(OpenCL)】
【CPU検索スレッドの数】4
【その他のオプション】
【Display Driver】310.90
【10分間の平均速度】tripcodes/s
【GPUの平均速度】tripcodes/s
【CPUの平均速度】tripcodes/s
【GPUの使用率】%
【GPUの温度】℃
【その他】

バージョン上がるに連れて徐々にGPUもCPUも遅くなってる気が・・・
同一検索条件で比べてないので、時間見て、調べてみますん。

>>449
ほうほう...〆
patterns.txt　と　tripcodes.txt　以外全部上書きしてたのがいけなかったのですね
ありがとうです

デバッグ頑張ってください！

と言いながら、以下要望
GUI　の　CPU　オプションに　優先度　があったらそれはとっても嬉しいなって
起動するたびにタスクマネージャから「低」を選択しているのは私だけかもしれないですけど…

バージョン上がるたびに徐々にSPEEDが遅くなってる気がする件は、検索条件同じにしたらさほど変わりませんでした。
お騒がせしました。

で、
正規表現で
(.)\1{11}
(.)\1{5}(.)\2{5}
(.)\1{3}(.)\2{3}(.)\3{3}
(.)\1{2}(.)\2{2}(.)\3{2}(.)\4{2}
(.)\1{1}(.)\2{1}(.)\3{1}(.)\4{1}(.)\5{1}
と列挙して検索しようとすると、結構な時間の準備後、検索前にエラーで止まります。
一番下のパターンを削除すると、結構な時間準備した後、正常に検索始まりました。
マッチパターンが多くなるのでそれは時間がかかるのは仕方ないと思いますが、検索前にエラーで止まるというのは初めてです。
メモリ不足と出たことはありますが。

で、今更気づいた一番下のパターンはもう一回繰り返さないと12桁になりませんね…orz

テストの共は携帯ゲーム機か文庫本。

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows XP Professional 32-bit SP3
【バージョン】MERIKEN's Tripcode Finder GUI 0.09 Alpha 2
【トリップの種類】12桁
【10分間の平均速度】0.08は>>437 → >>442 → 10.13 Mtripcodes/s
【その他】７桁先頭一致検索（6パターン）。SHA-1の最適化：有効。
　検索パターン「^([Aa]bdcef|ABCDEF)[:punct:]」（先頭一致で全部大文字もしくは小文字、または先頭だけ大文字で後小文字、その後に"."か"/"）

これも誤差。展開も時間かからず。

>>453
一番下だけで試してみたけど、私はメモリ不足になりまんたー
桁数減らしたら問題なく
ところで、{1}っていらなくないです？

>>455
{1}は直前の1回繰り返しで2文字ゾロ目の為なんで、要ると思ってるのですが・・・

>>377
MERIKENさん、生成されたトリップの累計表示の単位表示化の対応ありがとうございました。
昔、FM-7のF-BASICをかじっていたので、print usingとか思い出して懐かしかったです。
生きているうちに「1無量大数個」の表示が見られるのを楽しみにしています。
あと、README謝辞欄に名前が…。照れるな〜ｗ

トリップがごくまれにダブるバグは少なくとも0.05の頃からあった模様orz
たまたまさっきテストしたときにめったにないぐらい派手にエンバグして
目立ってただけのようです。これ、直すの結構めんどそうだな〜

>>451
GPUの温度は大丈夫ですか? うちの環境ではそのパターンで検索しても
ちゃんと動きましたが…

>>452
そういえばそんな話もありましたねえ。検討します。

>>453
このように具体的な例を挙げてもらえると非常に助かります。後で調べてみます。

>>454
エンバグしている最中にちゃんと動いている報告をいただくとほっとしますねｗ

>>455-456
"{1}"はいらないですよ〜

>>457
私もベーマガとPC-8001mkIIでプログラミングを始めたクチですｗ
あの報告がなかったらOpenCL.dllの問題はほったらかしでしたからねえ。
助かりました。

>>452
> GUI　の　CPU　オプションに　優先度　があったらそれはとっても嬉しいなって
これに関してだけど、優先度を下げるのと、コア数を減らすのはどっちが良いんだろう・・・
負荷はより低く、検索速度はより速く、て事で。

>>453の下から2番目と一番下試したよ。
環境はXP-SP3の32ビット、メモリ4G。
下から2番目は結構長い時間の後動く。
一番下は、>>455同様メモリ不足。

で、3回試してそれぞれタスクマネージャ見てたらメモリ使用量45〜46万k当たりで落ちてた。
マシン自体のメモリは「メモリの掃除屋」さんで見てるけど、落ちた段階でも1Gほど余裕あるからこちらは問題ない。

よく分からないけど32ビットOSの壁とかそういうのだろうか。

>>449と>>458のバグは位置指定なしのパターンでのみ発生する模様。
どうりで今まで気づかなかったわけだ… こりゃ当分の間はバグ取りですねorz

OSの表記を正確に　Windows8 Pro 64bit です

>>459
その時は確認出来てないのですが、検索開始数秒程度で停止なので熱関係は大丈夫かと。
他のベンチで叩いてもメッシュケースでこの季節なんで60度超えることはないです。
他の時は正常に終了で来てるので、その時何かの拍子で反応が重くなったのかと。

>>455>>460
＞"{1}"はいらないですよ〜
よく見りゃですね・・・あう。やっちゃいましたw・・・orz

>>462
メモリ不足は16G積んでる状態で、数ギガ消耗して残量が1G程度になってからメモリ不足になる時と、1G程度の消費でもメモリ不足と出る場合がある気が・・・

>>458
(.)\1{6}
うちもこれ系でいろいろ検索してみると、盛大に被ること多いです。
4回連続リストに並んだりが多いような。
うちでは被りは連続で出てくるばかりなんで、追記するときに前候補と同じなら追記しない
で行けそうな・・・
バラバラに被りが出てくる場合もあるんですか？

>>452
優先度か……
自分はランチャから起動(起動優先度も設定できるもの)してるから、
あまり意識したことはなかったな
(ちなみに待て屋なんかはデフォルトの優先度が「低」になっている)
>>454
>テストの共は携帯ゲーム機か文庫本
ﾅｶｰﾏ

さて自分もデバッグに参加するとするか

>>464
> うちもこれ系でいろいろ検索してみると、盛大に被ること多いです。

被りは連続のケースしかなかったです。
間違いなくCPU側のヒット判定のルーチンに問題があるので、
これからゆっくり調べてみます。

あ、かぶりの原因分かったｗ やっぱり問題はCPU側のヒット判定のルーチンでした。
しかしこんなバグ今までよく残ってたな… 結局今回の正規表現の拡張で
バグが見つかりやすくなったということらしいです。
問題を修正したらかぶりは綺麗サッパリなくなったし、よかったよかった。

>>464
> 他のベンチで叩いてもメッシュケースでこの季節なんで60度超えることはないです。

それだと熱の線はないですね。あとブロック数ぐらいしか思い当たることは
ないですが…

いわゆる「特殊パターン」について、順に調べてみました。
・全数(全ての桁が数字)
→10桁は([:digit:]){10}、12桁は([:digit:]){12}。
　パターン/チャンクはどちらも100000/100000。
・飛石(1文字毎に.か/で区切られる)
→10桁は(.[:punct:]|[:punct:].){5}、12桁は(.[:punct:]|[:punct:].){6}なのだが、
　「Resolving collisions in the array of expanded patterns...」と表示されたまま止まる。
　「|」を使わず2行にしても、今度は「片方だけだとなんとか展開するが両方だと無理」てなことになる。
　片方のパターン/チャンクは10桁で4194304/1048576、12桁で16777216/1048576。
　「[:punct:].」か「.[:punct:]」を5個or6個書くベタ書きでも、片方づつしか展開できない。
・純拡飛(1文字毎にある特定文字で区切られる)
→10桁は((.).(\1.){4}|.(.)(.\1){4})、12桁は((.).(\1.){5}|.(.)(.\1){5})なのだが、
　こいつの場合「Expanding a regex pattern...」がなかなか終わらない。
　(150M states; 36938K expanded patterns)となったところで一旦止めた。
・山彦(5文字or6文字のワードを繰り返す)
→10桁は(.)(.)(.)(.)(.)\1\2\3\4\5、12桁は(.)(.)(.)(.)(.)(.)\1\2\3\4\5\6でOKなはずだが、
　こちらも展開が終わらないパターン。
・双連(2文字連続のペアを繰り返す)
→10桁は(.)\1(.)\2(.)\3(.)\4(.)\5、12桁は(.)\1(.)\2(.)\3(.)\4(.)\5(.)\6。
　こちらも展開が(ry
・鏡(左右対称)
→(.)(.)(.)(.)(.)\5\4\3\2\1か(.)(.)(.)(.)(.)(.)\6\5\4\3\2\1。展開しすぎるパターン。
　まあ山彦が無理な段階で分かりきっていたけどね！
・最長、最短
→それぞれ[MWm]、[.il]しか使わない(MSPゴシックで一番長くなるor短くなる)。
　([MWm]){10}か([MWm]){12}、([.il]){10}か([.il]){12}となる。
　パターン/チャンクは10桁が19683/243、12桁が531441/243。

>>453
このパターンを試してみましたけど、メモリ不足で落ちますねえ。
まあ単純に考えて、'.'が5個あると展開後のパターンの数は64^5、
6個だと64^6ですからねえ。ちと無理があります。

>>469
飛石で (.[:punct:]|[:punct:].){6} っておかしくありませんか？
意図してるのは (.[:punct:]){6}|([:punct:].){6} のような・・・純拡飛の方はちゃんとそうなってるようですし

あとこれは人によると思うけど、山彦は (.{6})\1 とか、双連も ((.)\2){6} とか書いてもいいんでしょうか？

>>471
飛石は、「.[:punct:]」か「[:punct:].」が6連続すればいいんだろ？
「|」は「どちらか」ってことだから、「(A|B){6}」と「(AAAAAA|BBBBBB)」・「((A){6}|(B){6})」は等価
だから短く書ける方で書いたつもり
山彦と双連は……ああ、「((.){6})\1」「((.)\1){6}」と書いてもいいのね
展開できない理由はきっと>>470なんでしょうな。一番期待していた部分なだけにちょっと残念かも

いっそ[1]とかみたいに特殊パターンとして専用処理を組めば楽ちん……いやそこまでしてもらうのは悪いですかね？
参考：http://www.geocities.jp/trip_chaser/million.html#option

10桁用

全数 [:digit:]{10}
飛石 ([:punct:])(.\1){4}
拡飛 ([:alnum:])(.\1){4}
山彦 (.{5})\1
双連 (.)\1(.)\2(.)\3(.)\4(.)\5
鏡 (.)(.)(.)(.)(.)\5\4\3\2\1
最長 [MWm]{10}
最短 [.il]{10}

こうじゃないかな？

>>472
実際に (A|B){6} で試してくれれば分かると思いますが、等価じゃないんですよ
あと、双連は ((.)\2){6} と書かないとループすると思います

>>473
ああ、そうでした。飛石でも\n使わないとごちゃ混ぜになっちゃいますね

>>474
>(A|B){6} とは等価じゃない
そうじゃんAABABAとかも含んじゃうじゃん何言ってんだ俺
>双連は ((.)\2){6} と書かないと
\2とかってアタマから数えた(の位置で評価しているのか？
だから、"("+"("+"."+")"+"\2"+")"+"{"+"6"+"}"で、
2つ目の"("の中身を参照したいんだから\2でなきゃ駄目ってこと？

>>469
>>471-475

>>473さんが正解で〜す。しかしこれは弱りましたねえ。
特殊なケースとして実装しようとしても、CPUはともかくGPUだと
実用的なスピードにはならないでしょう。もうちょっと考えてみますけど、
難しいかもしれません。

>>475
自分はプログラミングとかさっぱりで、正規表現はbregonig.dllで知ってるくらいなのですが、
> 2つ目の"("の中身を参照したいんだから\2でなきゃ駄目ってこと？
そういうふうに認識してます。正規表現テスターでいくつか試してみましたが、\2で双連がヒットする模様
ですが、((.)\2){6} を0.09Alpha2で試してみたら正規表現が不正だと判定されてしまいますね

自分の感覚だと>>430のような定義（{n}で略した式集合も\nで参照できる）はできないと思ってたのですが、
それが今回の独自性なのでしょうか？

>>477
括弧が入れ子になっている場合は確かに番号の割り当てがおかしくなりますね。
これって直せるんだろうか…
>>430のパターンは完全にMTFの実装に依存しています。

時間かかりそうなら無理に直すこともないのかなーと
探すだけなら>>473さんのパターンでいいわけですし。もっと複雑なことする人いるのかな？
とりあえず今は入れ子使えないということが分かっただけでも自分には収穫でした

>>479
入れ子は使えることは使えるんですけど、実装の都合で内側の括弧から
最初に番号が振られてしまうんです。例えば、

(A(B(C)(D)))

の場合は、

\1: C
\2: D
\3: BCD
\4: ABCD

となります。直すのはかなり面倒ですが混乱のもとなので何とかしたいですね。

>>477
>>479
後方参照の番号の割り振り方を直すいい方法を思いたので、
問題を修正することができました。こんな感じで動いています。

----

TARGET(S)
=========
0: "^((.)\2)((.)\4)((.)\6)((.)\8)" (regex)

TRIPCODES
=========
◆00AADDFF7CSR #g柑ｱ┼c定ﾅ履 (67 8A B9 B1 84 A9 63 92 E8 C5 97 9A)
◆yyppAAyyrLXb #}ﾉ:ﾆ襍Pﾒzq徳 (7D C9 3A C6 E8 B5 50 D2 7A 71 93 BF)
◆ppyyppoo5Pvb #ﾕo.ｩ｣ﾕ@]ﾋﾍ濳 (D5 6F 2E A9 A3 D5 40 5D CB CD E0 4A)
◆33vvddJJO0He #AQ.z｣ﾕ@]ﾋﾍ濳 (41 51 2E 7A A3 D5 40 5D CB CD E0 4A)
◆99dd11uu7fuT #cG%ｭ｣ﾕ@]ﾋﾍ濳 (63 47 25 AD A3 D5 40 5D CB CD E0 4A)
◆mm//HHFF5Jod #O}ﾊﾆoﾒV緬f腴 (4F 7D CA C6 6F D2 56 96 C9 66 E4 4A)

>>473のいわゆる「特殊パターン」の件は結局いい解決策を
思いつきませんでした。特に「山彦」や「鏡」は30bitのハッシュ値空間を
完全に潰してしまうので、GPUでの検索は現実的ではありません。
CPU検索なら対応できるはずですが、もうちょっと考えがまとまるまで
この件は寝かしておくことにします。

というわけで、とりあえずCUI版で複数のパターンファイルを
扱えるようにする作業を開始しました。これはすぐに終わるでしょう。

>>347
> コマンドラインオプションで複数パターンファイルの読み込みに対応して
> 欲しいなー、なんて要望があるんですが如何でしょう。

実装出来ました。次の開発版から使えるようになります。

GUI版で、パターンの横にチェックボックスなんか付けて、オンオフしたいなぁ　なんて要望。

>>485
それはかなり良さげですね…
でも実装するのはかなりの手間になりそうです。
いずれパターンへのコメントを入力できる機能を付ける予定なので、
そのときに一緒にセットで実装することにします。

次は検算機能にしようっと。SHA-1は昔テスト用に使っていたコードが
残っているのですぐに出来るはずです。

# stat /usr/sbin/suexec
Access: (4510/-r-s--x---) Uid: ( 0/ root) Gid: ( 48/ UNKNOWN)
# chgrp apache /usr/sbin/suexec
# stat /usr/sbin/suexec
Access: (0510/-r-x--x---) Uid: ( 0/ root) Gid: ( 501/ apache)
# tail /var/log/httpd/host-zerochplusv-error_log
[Sun Feb 10 21:40:21 2013] [error] [client 192.168.0.7] suexec failure: could not open log file
[Sun Feb 10 21:40:21 2013] [error] [client 192.168.0.7] fopen: Permission denied
[Sun Feb 10 21:40:21 2013] [error] [client 192.168.0.7] Premature end of script headers: test.cgi

ちょっと進んだ

すまん超誤爆った、何やってんだ俺

Apache鯖の構築？

>>490
誤爆を引きずるのもアレなのですが、仮想鯖でCGIの負荷実験をしたいなと思って

スレ汚しすみません

>>484
ありがとうございます。パターン管理が楽になります。

>>492
確かに、複数パターンファイルを管理出来れば、俺のように
「自分用」「検索依頼用」「倉庫用」と分けて書きたい人にもピッタリですな
(USBメモリで持ち歩く際、テキストエディタ上で書き換えなくてもファイルコピペで更新できる)

ところでsupernovaさんはどれほどのパターン/チャンク数で……？
(当方は1147649/2634です)

>>493
管理のしやすさ、速度を重視して大幅に削っちゃったので今は全然ありませんなー
111763/1246くらいです。これから英単語リストを復活させようと思います。

12桁トリップの検算機能の実装が終わりました。
拍子抜けするぐらい楽でした。こんなことならもうちょっと早めに
やっておくんだった… 問題は10桁の方ですけど、こちらは
Bitslice DESではないcrypt()の実装をどっかから拾ってくることにします。

過去スレのリンクからUFC-cryptのソースを拾って来ました
https://aff4.googlecode.com/hg/libreplace/crypt.c
これで後はこれを使って検算用のルーチンを作成するだけです。

>>496のソースに、時々間違った結果が出るかも、と書いてありましたorz
こっちのほうがいいかもしれないな。
http://ftp.vim.org/security/coast/libs/libdes/

楽しみに待ってます頑張ってください

>>498
どもども。頑張りま〜すｗ

結局>>497はライセンスの関係で使えないことが判明したので、
UFC-cryptのソースを別の場所から拾って来ました。
http://packetstormsecurity.com/files/download/20603/ufc-crypt.tar.gz
これでうまく動くといいんですけど…

>>499のcrypt()はちゃんと動いている模様。
あとはこれを使って出力をチェックするだけです。

10桁トリップ検索の検算機能の実装も終わりました。
UFC-cryptがthread-safeでなかった点を除けば、かなりすんなりいきました。
こんなに簡単ならもうちょっと早めに実装しておけばよかった…

先程ブルースクリーンになってしまい、再起動したら、
「設定の読み込みに失敗しました」
で、起動しなくなってしまいました。
何をどうすれば、また起動する様になりますでしょうか？
patterns.txtやtripcodes.txtは、特に壊れてないみたいですが・・・

>>502
"C:\Users\****\AppData\Local\MERIKENsTripcodeFinderGUI"フォルダを
削除して下さい。AppDataは隠しフォルダなのでExplorerの設定を変える
必要があります。

Windows 7 隠しファイルを表示する
http://windowss7.web.fc2.com/file/sfile/

>>503
有難う御座います、直りました。
しかし、.NETアプリだから仕方がないのかもしれませんが、
EXEと同じ場所に.Iniファイルとかを置いてくれればいいのに・・・

なんかCUDAエラーが出て解析が約4分くらいで終了してしまいます

【GPU】GeForce GTS 250M
【CPU】Intel Core i7 Q820 1.73GHz
【OS】Windows7 Pro x64 SP1
【バージョン】MERIKEN's Tripcode Finder 0.09 A2 (0.08でも発生しました）
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】自動
【CPU検索スレッドの数】自動
【その他】GeFo ドライバーバージョン 313.96
　（エラーが出るので最新β版をクリーンインストールした状態にしましたが、やはり出ます）

>>504
こればっかりは仕方がないですね〜

>>505
恐らく熱暴走ではないかと思われます。
0.07以前のバージョンでは動作しますか?
( >>1の配布ページの下の方にリンクがあります)
GPUの温度は何度ぐらいですか?

>>505
ドライバの313.96ってベータでしょ？
正式版に入れ替えてみては？

あ、下のカッコはドライバの話だったのかな。

>>506
0.07Aでほんの3日前からエラーが出るようになったので、0.08、0.09Aとやってみたのですが
熱暴走じゃ仕方ないかもですね、とりあえずCPUのみで動かす事にします・・・

>>507-508
正式版を常に最新で使っていて、やっぱり出るなあって事でβ版のドライバーにしてみた感じです

まあでもハードの問題を一番疑っていたので、そう指摘されたら仕方ないかもなあとは思ってました

ちなみにGPUの温度は50度くらいで、最近はほぼ4分きっかりで落ちます
ドライバーもろとも落ちる感じで、ドライバー自体は自動的に再起動がなされるみたいです

>>510
それだとディスプレイドライバがタイムアウトで落ちてますね。
ブロック数(-x)をオプションで64以下にするか、
README.txtに書いてある方法でレジストリを修正してみて下さい。

ありがとうございます、その旨対処してみました

READMEに記されていたwikiのアドレスが変更になっているみたいなので連携します
http://www.slis.tsukuba.ac.jp/~fujis/cgi-bin/wiki/index.php?CUDA%A5%AB%A1%BC%A5%CD%A5%EB%BC%C2%B9%D4%A4%CE%A5%BF%A5%A4%A5%E0%A5%A2%A5%A6%A5%C8

>>511
了解しました。README.txtを直しておきます。

試しにCPUで特殊パターンを検索できるようにしてみました。
おまけの機能としてはわるくないですね。オプションで切り替えられるように
しておきます。

◆/r/s/S/z/X/M #a(qy難0盒<g= (61 28 71 79 93 EF 30 E1 B4 3C 67 3D)
◆I.m.S.4.W.V. #ﾈ踉@ｫﾇ徠憮ｸ" (C8 E6 F2 40 AB C7 9C 71 9C E1 B8 22)
◆dhdA6WW6Adhd #I鎭s豚ｪ惴ｬ*V (49 E8 4E 73 93 D8 AA 9C B6 AC 2A 56)
◆Q6YIUxQ6YIUx #冕S$ﾗｭ黠捌ﾑｭ (99 6A 53 24 D7 AD EA 7B 8E 4A D1 AD)
◆MMkkmmOOHHVV #ﾐﾓﾇ{湍ﾙﾈｧ;繚 (D0 D3 C7 7B 9F D8 D9 C8 A7 3B E3 87)

CPUで特殊パターンを検索する機能の実装が終了しました。
GPUでは検索できないので確率計算はしないようにしておきましたけど、
結構な確率でヒットするのでまあ問題ないでしょう。
結構色々機能を追加したので、明日あたりに新しい開発版をうｐします。

GPU検索が有効にならないので、cccってやつを入れてドライバも更新しました。
しかし、まだ有効になりません。
後は何を入れれば良いのでしょうか？

まてやなんかでは純8連を自動で拾うのですが
>>514はそういった特殊なパターンを自動で拾うモードの
オン/オフが搭載されるということでしょうか？
正規表現がちんぷんかんぷんな自分には嬉しい機能です（恥

>>516
OSとビデオカードとMTFのバージョンとディスプレイドライバのバージョンを教えて下さい。

>>517
>>514で指定できるのはとりあえず正規表現では処理できないものだけです。
純8連は"^(.)\1{8}"で拾えますけど、手軽に特殊パターンを指定できると
面白いかもしれないですね。

>特殊パターン
今ふと思ったけど、Million_seekerみたく
3パターン展開（全大文字、全小文字、先頭大文字後小文字）
できる記号があったら便利じゃね？
ただし本家では「+」記号でそれを表していたから別の記号で……

>>520
正規表現以外の記号は紛らわしいので追加する予定はありません。

GUI版の「検索パターン一覧」に「コピー」「全てコピー」「貼り付け」
「全て削除」の4つのボタンを追加しました。だいぶ前に要望があって
無いのが不思議なぐらいの機能だったので、大分ほっとしましたｗ

忙しいです。(´・ω・｀)
Kepler対応する暇が全然ありません。
ムシャクシャしたので、ぽちっちゃいました。反省はしています。

【OS】Win7 Ultimate 64bit
【バージョン】MTF 0.09a2
【トリップの種類】12桁
【その他】6完1タゲ

【CPU】Phenom II X6 [email protected]
【CPU検索スレッドの数】6
【その他のオプション】 -c --suppress-sha1-optimization-for-cpu
【10分間の平均速度】61.60 MTPS
【その他のオプション】 -c --enable-sha1-optimization-for-cpu
【10分間の平均速度】53.12 MTPS
【その他のオプション】 -c --enable-maximum-sha1-optimization-for-cpu
【10分間の平均速度】57.42 MTPS

【CPU】[email protected]
【CPU検索スレッドの数】8
【その他のオプション】 -c --suppress-sha1-optimization-for-cpu
【10分間の平均速度】96.53 MTPS
【その他のオプション】 -c --enable-sha1-optimization-for-cpu
【10分間の平均速度】86.95 MTPS
【その他のオプション】 -c --enable-maximum-sha1-optimization-for-cpu
【10分間の平均速度】99.90 MTPS

二歩下がって二歩進むって感じですかね。FXは幾分マシの様に見えますが、最適化は素直にオフにしていた様が良さそうです。

新しい開発版です。

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

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

・クリップボード関連のボタンをGUI版の検索パターン一覧に追加。
・ヒットしたトリップを検算する機能を追加。
・CUI版で複数のパターンファイルを指定できる機能を追加。
・CPUで特殊パターンを検索するオプションの追加。
・正規表現の後方参照の番号の割り振り方を修正。
・特定の条件で同じトリップが重複して表示される不具合を修正。

>>523
お疲れ様です。しかしこれはわかりやすいですね。やはりVisual Studioの
最適化はIntel向けなんですかねえ。Intelのコンパイラも試してみる予定
なので、結果が出たらまた報告します。

Core i7-3770KでもVSでコンパイルしたほうがIntelのコンパイラよりも
速かったです。やっぱそんなうまい話はないかorz

>>524
> ・CUI版で複数のパターンファイルを指定できる機能を追加。
指定した全てのファイルを読み込んでくれました。
ご対応くださりありがとうございます。

特殊トリップも検索出来る様になりましたが、最長／最短／純連（８、１０、１２桁それぞれ）等も是非・・・

>>518
> OSとビデオカードとMTFのバージョンとディスプレイドライバのバージョンを教えて下さい。
OS Vista 32bit
VIDEO Radeon HD5750
Driver Ver 9.012-121219a-152192C
MTF ってのは分かりませんでした。
何らかのチェックをしてエラーだったから、GPU のメニューが淡色になっていると思うのですが、
その理由を表示する様にして頂けませんでしょうか？
例えば、「xxxx.DLL がありません」みたいな感じで。
それなら、その DLL を探してくればいいし・・・

>>526
なん……だと……
そんなことってあるんだ

>>527
そりゃよかったｗ あると便利な機能ですよねえ。

>>528
> MTF ってのは分かりませんでした。

あ、これはMERIKEN's Tripcode Finderの略です。

> 何らかのチェックをしてエラーだったから、
> GPU のメニューが淡色になっていると思うのですが、

これは別にエラーが出てる訳じゃなくて、アプリケーションから
ビデオカードが見えていないだけなんです。その様子だと
配布パッケージに添付されているOpenCL.dllが悪さしているかも
しれないですねえ。MERIKENsTripcodeFinder.exeと同じフォルダにある
OpenCL.dllを削除して、OpenCLフォルダ内のx86フォルダを削除してから
もう一回試してみて下さい。

>>530
> OpenCL.dllを削除して、OpenCLフォルダ内のx86フォルダを削除してから
> もう一回試してみて下さい。
駄目でした。
アプリからビデオカードが見えるかどうかの確認が出来る方法とか
ツールってないでしょうか・・・
それなら、何故見えないか理由が分かるかも。

>>531
> アプリからビデオカードが見えるかどうかの確認が出来る方法とか
> ツールってないでしょうか・・・

C:\Windows\System32\clinfo.exeを試してみて下さい。
あとMERIKENsTripcodeFinderCUI.exeを起動させるとどんなメッセージが
表示されますか?

>>532
> C:\Windows\System32\clinfo.exeを試してみて下さい。
問題が発生したため・・・ってエラーで起動しませんでした・・・

> あとMERIKENsTripcodeFinderCUI.exeを起動させるとどんなメッセージが
GPU に関する事は特に何も表示されません。

MERIKEN's Tripcode Finder 0.09 Alpha 3
[compiled at 12:57:00 on Feb 12 2013 (PST)]
Copyright (C) 2011-13 ◆MERIKEN4.k
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.

CPU will be used as a search device.

CPU
===
Number of Logical Cores: 4
Number of Search Threads: 4

TARGET(S)
=========
　・
　・
　・
で、後は速度とかの表示ですね。

>>533
それだとやっぱりアプリケーション側ではエラーは発生していないので、
問題はディスプレイドライバですね。ドライバを一度アンインストールして、
もう一回インストールしなおせば直るかもしれません。
http://sites.amd.com/jp/game/downloads/Pages/downloads.aspx
あとは別のバージョンのドライバを試すという手もあります。

OpenCLデバイスの初期化ルーチンを見なおしていて気づいたんですが、
OpenCL.dllの処理の関係で、64bit版のOSでGUI版から32bit版のCPU検索の
ルーチンが利用できなくなっていることに気づきましたorz

問題はすぐに修正できたのですが、汎用のOpenCLアプリを書くのはやはり
楽ではないですねえ。ここらへんはCUDAとはだいぶ差があるようです。

次に何をするか迷ったんですが、とりあえず検索プロセスの
優先度を設定する機能をGUI版につけることにします。
これも今までなかったのが不思議なぐらいの機能ですが、
まあ問題ないでしょう。

>>535
64bitOSで走らせるのに32bitCPU検索なんか利用する意味はあるのだろうか……
でもバグが直るのは良いことなので乙

自分の「検索人の友」も改良したいけど、{}とか\nとか処理しきれないっすorz

>>537
今のところ命令セットの切り替えは完全におまけですねｗ
あれはいずれAVXやAVX2に対応するための布石なのです。
新しく追加した演算子はまじめにパーサを書かないと難しいですね〜

【GPU】 GTX680（OC1.378GHｚ　メモリ8GHｚ）
【CPU】 i7-3970x　(OC4.944GHｚ)
【OS】Win7
【バージョン】MERIKEN's Tripcode Finder 0.09 α3
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】初期値
【1CUあたりのワークアイテムの数(OpenCL)】初期値
【1WGあたりのワークアイテムの数(OpenCL)】初期値
【1GPUあたりの検索プロセスの数(OpenCL)】初期値
【1検索プロセスあたりの検索スレッドの数(OpenCL)】初期値
【CPU検索スレッドの数】初期値
【その他のオプション】初期値
【Display Driver】？
【10分間の平均速度】957.46Mtripcodes/s
【GPUの平均速度】784.48Mtripcodes/s
【CPUの平均速度】172.98Mtripcodes/s
【GPUの使用率】100%
【GPUの温度】計測時モニタ非表示
【その他】全てDL時の設定のまま

1Ttripcodes/s行きたかったなｗｗｗ
でも一瞬だけ現在検索速度が1002.12Mtripcodes/sいったｗｗｗ

>>539
これは速いですねえ! かなり驚きました。なんせ初代スレでの
バージョン0.04での680の報告が509M TPSでしたからねえ。
非常によい感じでOCできてるし、最適化もかなり効果が
あったみたいですね。

どもども。
やっぱり計測ならGPU単体で動かしたほうがイイのかな

>>541
そのほうが正確な値が出ますね。でも>>539の値も十分速いですよ。

検索プロセスの優先度はちゃんと変えられるようになりました。
平均以下あたりにしておくと、CPUで検索中でもストレスなく他の作業ができます。
次は他の特殊パターンもGUI版で簡単に指定できるようにする予定です。
これは正規表現のパターンを内部的に追加するだけなのですぐに実装できるでしょう。

【CPU】Intel Atom CPU N280（定格稼働）
【OS】Windows 7 Starter SP1
【バージョン】MERIKEN's Tripcode Finder GUI 0.09 Beta 2→3
【トリップの種類】12桁
【10分間の平均速度】 3.47 → 3.54 Mtripcodes/s
【その他】1バイト文字のみ、７桁先頭一致検索（6パターン）。SHA-1の最適化：有効。

検索条件を軽く変更…2バイト文字のキーに出しゃばられてもが3DSで入力できる気がしないので。
この子は別に良かった、しかし。

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows XP Professional 32-bit SP3
【バージョン】MERIKEN's Tripcode Finder GUI 0.09 Beta 2→3
【トリップの種類】12桁
【10分間の平均速度】 10.35 → 9.94 Mtripcodes/s
【その他】1バイト文字のみ、７桁先頭一致検索（6パターン）。SHA-1の最適化：有効。

あれ？少し遅くなった？2バイト文字有りで軽く回してみても結果は同じ。

>>542
ちょっとやってみるｗｗｗ

>>543
プロセス変更はありがたいｗｗ
OC調整だと、まずプロセスを最低にするところから始まるわけだし

MTF0.09Alpha2の累計をMTF0.09Alpha3に引き継がせることはできますか？
ある野望を成し遂げるためには継続が必要なのですｗ

>>538
ん、AVXはビットシフト出来ないから使わないとか前スレ>>961で言ってませんでしたっけ……？
ただ、AVX2による(整数演算含む)パフォーマンス向上は色々と気になりますね
>>541
個別の速度は単体＞両方同時だけど、余程GPUが速くない限り
全体の検索速度は両方同時＞単体というのが俺の認識

>>547
あくまでGPU単体でどの程度の働きを見せてくれるのかなって思っただけ
CPUもお荷物って遅さじゃないみたいだから、実稼動時は同時運用がイイのかな


GPUのOC調節ががががが
さっきは良くできてたんだけどなぁ

回文とか山彦とかは、自分で正規表現で検索させると速度が落ちるのに、
あそこをチェックしただけで見つかるのに大して速度が落ちないのは何故？？

>>549
そりゃ判定用に専用ルーチンでも組み込んでいるんだろ……

いやソース読んでないからあくまで予想ですけどね

>>539 1Tとかどんだけww

>>544
> あれ？少し遅くなった？

特殊パターンの検索ルーチンを組み込んだせいでしょう。
ほとんどの場合通常の検索には影響は出ないはずですけど、
CPUによっては稀に遅くなるケースもあるということでしょうか。

>>546
3つの実行ファイル(*.exe)とOpenCLフォルダを上書きすれば大丈夫です。

>>547
それはSHA-1の話です。Bitslice DESはビットシフトを使わないので
恐らく大丈夫でしょう。

>>549
速度があまり落ちないのは専用の判定ルーチンを作ったからです。
CPUだとこういう乱暴なこともできますけど、GPUだと分岐処理の
ペナルティが大きいので無理でしょうねえ。

>>552
累計検索時間:　　　　　　3日11時間22分19秒(2013年2月9日 15時55分に起動)
生成されたトリップの累計:8兆4806億1223万0272個
ヒットしたトリップの累計:2541個
稼働率:　　　　　　　　　70%

ちゃんと累計を引き継がせることができました。ありがとうございます。
あと、フォルダ名の変更をすると(Alpha2→Alpha3)累計は引き継がれなくなるのは仕様でしょうか？

>>554
> あと、フォルダ名の変更をすると(Alpha2→Alpha3)累計は引き継がれなくなるのは仕様でしょうか？

フォルダ名の変更をすると設定が引き継がれないのは.NETの仕様です。
どうしようか現在思案中です。

「全数」「二構」「最長」「最短」を検索するオプションをGUI版に付けました。
あとは「純n連」と「準n連」を実装したら特殊パターンへの対応は終了です。

>>556
をををを、滅茶苦茶嬉しいです。
後、

安定版: MERIKEN's Tripcode Finder 0.08 [ダウンロード]
開発版: MERIKEN's Tripcode Finder 0.09 Alpha 3 [ダウンロード]

ここにリリース日時も表示してくれると嬉しいな。

>>557
つ■変更履歴

>>557
> ここにリリース日時も表示してくれると嬉しいな。

直しておきました。

「純n連」と「準n連」もGUI版で指定できるようにしておきました。
検索君1号でも純10連と準12連を仕掛けておいたので、そのうち採れるでしょう。
また明日あたりに新しい開発版を用意します。

>>560
>そのうち
ん？
確率的には40日ぐらい掛からね？＞準12連
純10連(@12桁)も平均16日ぐらいは掛かるはずだし……

>>561
だから「そのうち」でいいんですよ。うちでは基本的に24時間検索してるので
1ヶ月もあればどちらか出るでしょう。

新しい開発版です。

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

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

・特殊パターンの設定をするオプションをGUI版に追加。
・検索プロセスの優先度を設定するオプションをGUI版に追加。

1ヶ月も待つ必要なかったですｗ
仕掛けておくとかかるもんですねえ。

>>563
そのページのスレ検索リンクはタイトル限定にした方がいいと思うのです。念のため
（ログインしてると本文検索させられそうになる）
http://find.2ch.net/?STR=MERIKEN%27s+Tripcode+Finder&TYPE=TITLE

0.09 Alpha 4 にしてから、起動時にエラーが出るようになりました
そのあと起動はしますが、検索実行すると同じエラーが出て検索できないです

【GPU】 なし
【CPU】 Intel Core i3 530
【OS】 Windows 7 Ultimate [Service Pack 1]
【バージョン】 MERIKEN's Tripcode Finder 0.09 Alpha 4
【その他】
以下、エラーのコピペ
---------------------------
MERIKENsTripcodeFinderCUI.exe - 正しくないイメージ
---------------------------
C:\MERIKENsTripcodeFinder_0.09_Alpha_4\OpenCL.dll は Windows 上では実行できないか、エラーを含んでいます。
元のインストール メディアを使用して再インストールするか、
システム管理者もしくはソフトウェアの製造元に問い合わせてください。
---------------------------


---------------------------
MERIKEN's Tripcode Finder 0.09 Alpha 4
---------------------------
検索プロセスが異常終了しました。
検索を中断します。
---------------------------

>>566

おっと、間違えて送信してしまった…

>>566
それはおかしいですね… 多分>>535の変更が影響しているんでしょう。
OSは64bit版ですか? あとビデオカードを教えていただけると助かります。

>>566
あとC:\Windows\System32にOpenCL.dllがあるかどうか調べていただけと
助かります。

う〜ん、どうやらOpenCL\x86\OpenCL.dllが壊れていたようです。
ちゃんとしたのに差し替えてうｐし直すのでしばしお待ちを。

>>568-569
遅れてすみません
OSは32bitです。ビデオカードは付けてないです
C:\Windows\System32\OpenCL.dll は無いですね

>>571
いやいや、報告していただいてありがとうございました。
今新しい開発版をうｐしているところです。

新しい開発版です。

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

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

・OpenCL\x86\OpenCL.dllが壊れていた問題を修正。

>>565
あ、これも修正しておきました。わざわざありがとうございました。

0.09 Alpha 5 で問題なく検索開始できました
ありがとうございました

いや〜、よかったよかった。
OpenCL.dllの問題は解決していたと思ってたのでびっくりしましたｗ

ウィンドウが
http://up.null-x.me/poverty/img/poverty45004.png

>>577
これはひどいｗ
開発には英語版のWindows 7 64bitを使ってるのでそれが原因かもしれないですね。
OSはなんですか?

>>577
Windows XP 32bit English SP3で試してみたけど問題はありませんでした。
Microsoft .NET Framework 4に最新のアップデートを当てたら直るかもしれません。
しかし弱ったなあ。日本語版のWindowsは持ってないんですよね…
他に同じ問題が出ている方は見えますか。

>>579
Windows7 Pro 64bit SP1でも「下半身」が見えませんｗ
http://i.imgur.com/CecCIRI.jpg

>>578
Windows8 Pro 64bitです

>>580
なんということでしょう＼(^o^)／
うちではちゃんと正常に表示されているというのに…

>>580-581
取りあえず下を引き伸ばしたものを作ってみました。
http://www.meriken2ch.com/files/2013-02-15-MERIKENsTripcodeFinder.exe.zip
Alpha 5のものと差し替えて試してみていただけると有難いです。

>>582
「下半身」ってこうなっていたのか〜ｗ
http://i.imgur.com/bo9plhu.jpg

>>583
うちではこんな感じになっちゃってますけどねｗ
http://www.meriken2ch.com/files/2013-02-15-Special-patterns.jpg
なんか.NETのバグ臭いけど、うまく動いているようなので
このままにしておきます。

>>584
了解しました。フォルダ名の変更の件は、タスクバーにショートカットを
置くことによってAlpha2を意識せずに起動できるので、問題解決しています。

最新版試してみました。
……ん？　何か検索パターンを入れないと検索できない
(特殊パターンのみで検索、ができない)のは仕様なんですかね？

これって例えば純8連以上を検索したい場合は>>577さんのように5つチェックする必要があるんですよね？
純8連をチェックしただけでは純12連は含まれない、と

0.09 Alpha 5なかなか検索の準備中から進まないんですが自分だけ？
パターンは0.09 Alpha 3からコピペ
特殊パターン全チェック
いま1分以上準備中…

>>586
特殊パターンの検索はあくまでもおまけなので、それは仕様です。

>>587
実は必要ないですｗ やっぱまぎらわしいですかね〜 ちょっと考えてみます。

>>588
二構は準備に時間がかかる上に超遅いです。要注意です。

>>590
よかった…ありがとうございます
超遅いというのはパターン読み込みで検索スピードが落ちるわけではないですよね？

>>591
検索速度も遅くなっちゃいます。5770だと半分以下ですね。

>>587
わかりやすいようにGUIを直しておきました。

まあ純n連を除く二構は、12桁トリップの場合

(64 * 64 / 2 - 32) * (2 ^ 12 - 2) = 2016 * 4094 = 825万3504通り

ありますからねえ。気軽に検索できないのは残念ですけど、
正直動いているだけでもうけものですｗ

　　　　　　　 Λ＿Λ 　 　 　 各特殊パターン毎の準備秒数を測ってみました。
　　　　　 　 （´∀｀　）-､　　　純X連・準X連・全数・飛石・拡飛・回文・山彦・双連→2s
　　　　　 　,(mｿ)ヽ 　　i.　　　最長・最短→18s
　　 　　 　/　/　ヽ ヽ　ｌ.　　　二構→1m45s(速度は57.4MTPS)
￣￣￣　（_,ノ￣　ヽ､_ノ￣.　 ……やっぱり二構は時間が掛かりますね。



:::::::::::.:　.:. . ∧＿∧ . . . .: ::::::::.
:::::::: :.: . .　/彡ミ゛ヽ;)ヽ、. ::: : :: 　　だけど、拙作「検索人の友」で二構を作って検索してみると、
::::::: :.: . . / :::/:: ヽ、ヽ、i . .:: :.: :::.　 50sで展開して59.2MTPSでした……。
￣￣￣（_,ノ ￣￣ヽ､_ノ￣

>>595
これ、展開が速いのは理解出来ますけど、検索速度がちょびっと速くなるのは
なぜでしょうねえ…

ちなみに「検索の友」を使ったほうが展開が速いのは、
検索の友が'*'を使わないで最初から12個の文字にばらしているからです。
これはいい事を知りましたｗ 後で直しておこうっと。

こうしてどんどん改良されてくのを見てるのが楽しいｗ
HD6770で特殊パターン全チェックで速度600→250M
パターン数が物凄いことが如実にｗ

一応もうちょい真面目な計測の方をば。

○本体機能
検索実行から「6分4秒」と表示されるまでに掛かった時間→7分49秒
平均検索速度→画面表示は58.32M(44.70M@GPU 13.62M@CPU)
　 　 　 　 　 　 　 MTFlogだと58.31±0.4117M(44.69±0.4002M@GPU 13.63±0.1929M@CPU)

○自作パターン
検索実行から「6分10秒」と表示されるまでに掛かった時間→6分48秒
平均検索速度→画面表示は59.69M(45.77M@GPU 13.92M@CPU)
　 　 　 　 　 　 　 MTFlogだと59.68±0.5449M(45.76±0.5403M@GPU 13.93±0.1235M@CPU)

尚、MTFlogで観察したところ、前者は後者に比べてGPUの速度変化が少なかった模様

>>597
実際すぐに反応が見られるのは面白いですｗ
VLIWなRadeonは結構速度低下が激しいんですよね。
共有メモリが比較的遅いのが効いてるんだと思います。

>>598
検索速度が遅かったのはうっかり二構に純n連を含めていたせいでしたｗ
あとで直しておきます。調べていただいて助かりました。

>>600
ん？　検索人の友が吐くパターンには純n連・準n連も含んでいるのですが？
*云々は最長・最短にも言えること(各3秒ほどで展開完了)ですね
……まあ、検索時間・速度に比べれば展開時間なんて気にしなくてもいいところですが

二人の力を合わせて超高速展開方法を発見するとか胸熱

>>601
私の手元にある「検索の友」の二構には純12連は含まれてませんでしたよ。
含まれてたら2080パターンになるはずですけど、2016パターンしかないですからね。

おっと、>>603は私の勘違いでした。う〜ん、それじゃあなにが違うんだろう…

>>603
いや、例えば
>[Dd][Dd][Dd][Dd][Dd][Dd][Dd][Dd][Dd][Dd][Dd][Dd]
という行がその2016パターンの内に入っていたと思うのですが、
これってどう見ても準12連・純12連を内包していますよね？
二構の場合、1文字につき(64×63)/2＝2016通りあり得ますので、行数が2016行なのです

>>605
いやあ、うっかりしていましたｗ でもそれだと速度が違ってくる説明が
つかないんですよね。なんとなくMTFのバグの香りがします。

う〜ん、展開されたパターンとチャンクの数も全く同じみたいだから
バグじゃないのか… ますます謎です。

新しい項目を幾つかチェックしたら、「検索の準備中・・・」のまま、
全く検索が始まらないのですが、何時間位待てば良いのでしょう？

>>608
つ>>595

検索の友の二構のパターンとMTFの二構のパターンを展開したものを較べてみましたが
全く同じでした。どうやらこれ、MTFのルーチンで二構を展開すると、検索速度の
立ち上がりが遅くなるということらしいです。いや〜、びっくりしたｗ

これは、12桁検索の場合も、10桁の時の様に、最後の文字は一部だけ、という制限があるのでしょうか？

>>611
ないで〜す。

>>612
> ないで〜す。
お、そうなのですか。それは嬉しいです。
ところで、現在、特殊検索オプションに何をチェックしているか、
検索途中でも確認出来る様にして頂けませんでしょうか？
ステータスバーに流して表示でも、ダイアログでも何でも良いので。
私はウィンドサイズを大きくしているので、検索結果の
色々表示されている部分の右側が大きく空いていますが、
通常サイズだと空いてないですしね。

MTFの二構のルーチンを"{n}"を使って書きなおしてやったら、
準備にかかる時間も検索速度もほぼ「検索人の友」のパターンと
おなじになりました。

検索人の友: 24s 51.21M TPS
MTF:　　　　24s 51.13M TPS

いや〜、しかし'*'の展開の遅さは予想外だったな。
YSRKENさんに感謝、感謝ｗ

>>613
表示する場所がないので、「特殊パターンの設定」のボタンを
検索中も有効にするようにしておきます。

>>613
>>615の実装は終わりました。次の開発版から使えます。

「検索人の友」というツールは、何処からダウンロード出来るのでしょうか？

>>617
使ってみるかい？
機能としては、
・検索依頼の各種形式への変換
・特定パターンの検索ワードの自動生成
・各種トリップ検索ワードの相互変換
・任意の検索ワードに対する出現確率を計算
・トリップテスト
といったところ。http://www1.axfc.net/uploader/so/2732376.zipに上げてある。
(画面キャプ：http://blog-imgs-52.fc2.com/y/s/r/ysrken/tf2nd.png)

ただ、自分で使っててもちょくちょくバグが見つかってきたのでまとめて修正したいけど時間が……

>>618
有難う御座います。
早速色々使ってみます。

そろそろユーザーインターフェースをいじるのにも飽きてきたｗので、
前から予定していたデバイス診断の機能をつけてバージョン0.09での
機能追加は終わりにします。この機能の実装には時間がかかるので、
先にバクフィックスをした開発版をうｐしておきます。

新しい開発版です。

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

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

・ダイアログボックスがきちんと表示されない不具合( >> 577 )を修正。
・特殊パターンの展開に時間が掛かり過ぎる問題( >>595 )を修正。

>>621
乙です。

ところで、>>167でも聞きましたが、Radeonで自動設定させた時、そのパラメータはどのように動かしているのですか？
CUDAと異なり、考慮する要素が4つもある(-y、-z、-a、-b)ので、凄くややこしい変移だと想像しているのですが
(値の範囲は、-yが8〜32768、-zが8〜128、-aが1〜4、-bが1〜32)

今更ながらの希望です
patterns.txtについては配布ファイルに同梱とせず
「ファイルが無い場合には起動時に空ファイルを作成」
という動きにしてはいかがでしょうか

>>623
そういえばそれが無いのが不思議だな

バージョンアップ時はpatterns.txtさえ気を付ければ、あとは全て上書きしても大丈夫なんですよね
初回起動時など、ファイルが無い場合はMiscフォルダにあるデフォルトを使うようにできれば、上書きするとき楽だと思います

>>622
Radeonの自動設定はGPUで決め打ちです。最近のAMDのドライバはスレッドが2個
あればGPU使用率はほぼ100%になるので"-a 2 -b 1"は確定で、-zは
GPUのアーキテクチャの仕様で32の倍数になって、-yはOpenCLの仕様で
-zの値の倍数です。

>>623
はじめて使う人にはpatterns.txtが最初からあったほうが便利なんですけど、
バージョンアップの時にはたしかにちょっと不便ですね。
ちょっと考えてみますけど、初回利用者の敷居をなるべく下げたいというのもあるので
今のままにしておくかもしれません。

tripcodes.txt の内容に関してですが、見つかったトリップの右側に、
それが見つかった年月日時分秒も書き込む様にして頂けませんでしょうか？

>>628
オプションで選べるようにしておくといいかもしれませんね。
気が向いたときにやるのでいつになるかわかりませんけど、
いずれ実装します。

張り切って並べてみたけど、これ全部実装するのはえらい手間だなorz
http://www.meriken2ch.com/files/2013-02-16-MTF-diagnoses.jpg

【CPU】AMD Athlon 64 X2 5050e（定格稼働）
【OS】Windows 7 Professional 32-bit SP1
【バージョン】MERIKEN's Tripcode Finder GUI 0.09 Beta 3→6
【トリップの種類】12桁
【10分間の平均速度】 9.98 → 9.81 Mtripcodes/s
【その他】1バイト文字のみ、７桁先頭一致検索（6パターン）。SHA-1の最適化：有効。

OSをXPから7に入れ替えてたらバージョンが飛ぶ飛ぶ。

>>620-621
お疲れ様です。
ヒットしたトリップの検算機能とかも付いていたのですね。
これは常に有効になっていてエラーが見つかると警告メッセージが出るとかでしょうか？

>>630
各パラメータを変更しながら検索速度を記録、というのを自動的に行ったりでしょうか？
実装はかなり面倒そうですが、完成すればアーキテクチャによる傾向がさらに分かりやすくなりそうですね。

仕方がない事なのでしょうけど、二構をチェックすると、ガクッと速度が落ちますね。

>>632
> これは常に有効になっていてエラーが見つかると
> 警告メッセージが出るとかでしょうか？

ヒットしたトリップは全て検算されていて、エラーがあれば
問答無用で異常終了しますｗ

> 各パラメータを変更しながら検索速度を記録、というのを
> 自動的に行ったりでしょうか？

その通りです。いままで手作業でやっていたんですけど、
この間10分間のテストを140回繰り返して流石に懲りましたｗ
自動化すればテストをさらに複雑にできるので、
もっと色々とわかるでしょう。

>>633
残念ですけど仕方がないですね〜
こればっかりはなんともなりません。

>>631
7はいいですよねｗ しかし特殊パターンへの対応でやっぱり微妙に速度が
落ちてますねえ。仕方がないとはいえ、ちと残念…

>>634
やっぱり自動化は大切なんだね……クッソ高いテストツールが売れるのも分かる気がするわ
(※ただし銀の弾丸は存在しない)
しかしエラーが発生した瞬間に強制終了というのは必要なことなのかな？
ログに×印を入れるぐらいでいい気がするんだけど……
>>636
さて……>>13をちょっと更新しますかね(暗黒微笑)

>>637
> しかしエラーが発生した瞬間に強制終了というのは必要なことなのかな？
> ログに×印を入れるぐらいでいい気がするんだけど……

そりゃグラボやCPUがぶっ壊れてもいいならそうしますけどねw
だいたいハードウェアに異常がない限り検算に失敗することはないですからねえ。
熱暴走でおかしくなってるのに動かしつづけるなんて考えられません。

>>634
警告を出して停止とかかと思っていましたが、異常終了ですか・・・
10分間のテストを140回手作業でとか面倒すぎますねｗ

>>638
な、なるほど……まあ、「実はプログラムのバグだった」場合でも、
計算ミスには違いないので落とすのは対応としては間違っていませんね

>>639
あ、異常終了といったのは言いすぎでしたね。ちゃんとエラーを出して
停止します。

>>641
そうでしたか。
本当に異常終了だと、検算に引っかかったのかそれとも別の理由か分かりにくそうだったので、それを聞いて安心しました。

>>627
自家製pattern.txtと同梱parrern.txtを別に扱えたらよいかと。
複数ファイルのpattern定義をチェックボックスでの選択制にしたり、pattern*.txt（オリジナルパターン）が有る場合、そちらを優先して読み込むなど、
要は同梱pattern.txtが上書きされてもオリジナルのpatternが残ってれば問題ないきがしますぅ。
pattern*.txtは複数存在できるので、エクスプローラー順ということにするとか。

あるいはconfigフォルダを用意して
(1)起動時最初にconfigフォルダ内をチェックし、パターンファイルが無ければコピー
(2)情報取得はconfigフォルダ内のパターンファイルを参照

あと、これも必要かも？
(3)パターンファイルのフォーマットを変えざるをえない場合には別途移行手順をアナウンス

>>643-644
patterns.txtの扱いはなるべくユーザーにわかりやすいようにしておきたいんですよね。
複数のワイルを扱いたい場合はCUI版を使うという選択肢もありますし。

>>645
どちらかと言うと、バージョンアップ時に設定が消えてしまう、というのを問題視しているだけですので
被せればいいんだと思ってたら設定が消えた、というような事が無いようにする為の回避策ですが・・・

まあ一度失敗すれば二度は失敗しないのかもしれないですけども・・・

サンプルとして提供するのは、patterns.txt.smpl みたいに
ファイル名を変更しておけばいいだけの様な気が。

>>646-647
私としては>>627で書いた理由もあって、パッケージを解凍したら
すぐにGUI版もCUI版も動くという現在の形を変えたくないのです。
バージョンアップの方法についてはREADME.txtに追加しておきます。

>>648
むしろパターンファイルの記入の仕方をREADMEに書いたらどうでしょ・・・

一応提案しているのは
「初回利用者にも常連利用者にも作業の手間を省略させる改善方法」
のつもりなのです

例えば配布ファイルを「初期設定用」と「アップデート用」とで分けるのも一つの手ですが
安定的に半年から1年に1回程度のアップデートってんならそれでもいいでしょうけど
週に数回のα版配布がある状況なので、MERIKENさんの手間なんじゃないかなとも思ったりして
なら自動化をするか、目先の手順をちょっと変えるかで実現できるんじゃないかな？なんて感じです

>>650
う〜ん、これってバージョンアップのときにpatterns.txtを上書きしなければ
いいだけの話ですよね? どこが手間なのかさっぱりわからないのですが…

>>651
確かに「知ってれば」上書きしなければいい、という事なんですけど
初めてバージョンアップした際にしてしまったミスを、次の誰かもするんじゃないかな？と思ったので

で、バージョンアップの仕方についても、DLしてダウンロードフォルダやデスクトップ等に解凍し
(1)作られるフォルダの名称を変えてフォルダごとツール格納用フォルダに移動させる事で上書き
(2)解凍したフォルダ内にてCtrl+A→Ctrl+X→ツール格納用フォルダにてCtrl+V、という手法で上書き
(3)丁寧に1フォルダ1ファイル単位で一つずつD&Dでツール用フォルダに移動させる方法で上書き
(4)解凍したツールを特に移動させる事なく、そのまま使う
その辺は人それぞれでなんとも言えなかったりもしますが
上2つの「バッサリ被せる」タイプの人だと、先にパターンファイルを削除しないといけなくなります
（(2)は選択状態時に対象ファイルを選択から除外すればいいですけど）
この辺は習慣の問題なので、手間が発生する人もいるし、手間で無い人もいる、そんな感じじゃないでしょうか

ユーザ設定部分は上書きによって消えるべきではないので、「バージョンアップさせても残るファイル」化しておけば
多分ミスの心配そのものが無くなるんじゃないかなあ、って感じです

>>652
誰もバージョンアップのときに全部ファイルを上書きしろなんて言っていませんけど…
ファイルを上書きすれば元のファイルが消えるのは当たり前です。
次からは気をつけましょう。

当たり前だから構造的に上書きできないようにしよう、ってID:kEEWUjgm0は言いたいんだろう
起動時にpatterns.txtが存在しなかったら自動生成するようにすれば両者の希望が叶うんじゃないかな

それだとはじめてCUI版を使うときにpatterns.txtが見つからないということに
なっちゃうでしょう。

なんか説明すればするほどこちらも興奮してしまって逆効果な気がするので、ちょっと冷静になる為に自重します

>>656
そのほうがいいでしょうねえ。

とにかくCUI版をサポートしている以上、パッケージに添付されているpatterns.txtは
今のままです。ちゃんと理由のあることですし、もう説明は十分にしたので、
この件についてはこれ以上の発言は控えます。

起動して patterns.txt が無い場合、patterns.txt.default を patterns.txt にリネームするようにすればいいと思うけどなあ

僕も初期処理でNOTFOUNDエラー例外処理としてデフォルト状態の設定ファイルを作るようにしてやれば
多分メインの検索処理への負荷も無いはずですし、パフォーマンス劣化等の弊害も無いとは思うんですが
GUIだからできるとかCUIだからできないとかあまり考えてないんですよね
どのプロセスであっても起動時チェック処理としてやれば良いかな程度に思ってました

とりあえず、この先についてはMERIKENさんのお考え次第だと思うので、静観します

>>655は「はじめてCUI版を使うときにユーザーがpatterns.txtを
見つけられない」という意味です。

Readmeに
バージョンアップの場合
　三種のexeとOpenCLフォルダだけを上書き

って書いておけば解決
設定と累計の引き継ぎについてはスレでのやり取りしかないと思うので、合わせて書いておくと優しいかも？

以下、個人的な意見。
確かにpatterns.txtを避けてコピペするのはちょっと面倒だけど、無ければ無いで戸惑う面もあるかもしれない。
他のソフトの話だけど、待て屋の魔改造ブランチにはReadme・target.txtの両方が付いていない。
もちろん本家版をDLすれば使い方は分かるんだけど、最新版でいいや、と適当にDLした人は最初戸惑うと思う。
上書きミスはそれこそ二度も起こさないようなものだし、patterns.txt内に記述方法を書いておく現在の手法で問題はないと思う。
もっとも待て屋の場合、「sample_target.txt」と、ファイル名は別にしていたが。

キミたちにこの実話を送ろう。（せりふはきゃくしょくしています。ｗ

私「待て屋にこんな機能どうかな？」
鳥○「んな改悪しねぇよ、はげ」
私「えぇ〜・・・・・。」
○屋「GPL」
私「魔改造ブランチつくってそこで好き勝手にしろと？」
鳥○「好きにしろよ、はげ」

静観ｗｗｗ
もっとファビョれよ

お前ら調子にのり過ぎ
このスレはアップデート報告に速度報告ぐらいでいいんだよ
日記じゃねーんだから要望なんて書いてんじゃねーぞ？

速度追求してくれればお腹いっぱいだお

>>648
ﾜﾀｽの言ってることが上手く伝わってなかったかなぁ・・・という感じなので追記＾＾；

初期配布ファイルは今のままで全くOKかと思います。
で、自分で色々とpatternファイルに記したものを、pattern*.txt等の、任意の別ファイル名で置いておくと、そちらを優先して読みこんでくれる。
という実装にしてもらうと、サイトからダウンロードしたアーカイブを解凍して中身をごっそり置き換えてもpatternが消えることは無いかなぁ。ということです。

Windowsのオンラインソフトってアップデートの際、アーカイブの中身をごっそり上書きでOKなソフトが多いので、そういう話がでたのかと思いますん。

その際、
pattern.txt
pattern_original01.txt（自家製）
pattern_original02.txt（自家製）
という風に複数のpattern*.txtが有る場合、pattern.txt以外のpatternフイルの中から、エクスプローラー順に読みこんでくれるといいかなぁというお話でした。

一回、自分も前上書きでやちゃったもんで、今は別ファイル名でバックアップ置いてますけど。

>>667
ちゃんと理解しているので同じことを繰り返して書く必要はないです。
>>645と>>653と>>657をもう一度読んで下さい。

> Windowsのオンラインソフトってアップデートの際、アーカイブの中身を
> ごっそり上書きでOKなソフトが多いので、そういう話がでたのかと思いますん。

MERIKEN's Tripcode Finderは違いますし、それを変える気はありません。

要望をここに書いてくださるのは一向に構わないしむしろ歓迎なんですけど、
受け入れるかどうかを決めるのはあくまでも私です。
これでも機能の取捨選択はかなり考えて行ってるし、
しつこくされると完全に逆効果なので、ほどほどにお願いします。

デフォルトでは検索タゲファイルをpattern.txtにしておいて、
必要に応じてユーザー側で検索タゲファイルを選択できるようにするってのもありかもしれない

普通にやってれば、pattern.txtを上書きすることなんてないと思うけどね

同梱配布するサンプルの pattern.txt の日付を、思いっ切り古くしておくとか。ｗ

なぜファイルを上書きとかの話が出ているのかと思ったら、
.NETの設定ファイルの保存場所の仕様ですか・・・

設定ファイルのディレクトリを見に行って笑ってしまいました。
保存場所を手軽に変更したりも出来ないみたいですし、面倒な仕様ですね・・・

>しつこくされると完全に逆効果なので、ほどほどにお願いします。

よーし
しつこく要望して開発中止に追い込んでやるぞー

>>673
いい加減にしろ！

こんなの出ました。割と綺麗に出たほうだけど、色々惜しいｗ
やっぱりまだまだこれからですねえ。

>>675
ノイズはないけど惜しい！
12完が現実的になりましたね。

>>672
インストーラーがあることが前提なんでしょうけど、
不便な事この上ないですｗ まあいずれ設定をインポート・
エクスポートする機能をつけるからいいんですが…

>>676
12完、いつかでるといいですねえｗ
本当はもうちょっと速度がほしいんですけどね〜
7990CFXでも10G TPS強なのでちょっとコストに見合いません。
もうしばらく我慢ですね。

>>675
どういった検索パターンでそれを……？
ひょっとして、「[:punct:]*(MERIKEN|[Mm]eriken|MeriKen)[:punct:]*」として検索を延々掛けていたんですか？

パターンはこれです。

^[:punct:]*[Mm][Ee][Rr][Ii][Kk][Ee][Nn][:punct:]*$

こんなのでも9完より出にくいので>>675はかなり運がいいんですけど、
今一歩といったところですね。

>>677
UACやリダイレクト等の関係もあるのかもしれませんが、不便ですねえ。

設定プロバイダを自作するという裏技的な方法もあるようですが、
クラスの継承やオーバーライドとかさっぱり分かりませんｗ

設定ファイルのパスを取得する方法もあるようですし、ポータブルにこだわらなければ
インポート・エクスポートの機能を実装する方が楽かもしれませんね。

>>680
> 設定プロバイダを自作するという裏技的な方法もあるようですが、

へえ〜なるほど〜と思って調べてみたらこんなものがありました。

https://github.com/crdx/PortableSettingsProvider/

で、MTFに組み込んでみたら、あっさりと設定が

MERIKENsTripcodeFinder.settings

に保存されるようになりました。いや〜、助かりましたｗ

>>681
うおおお
これはありがたいですね

あとはGUI番も複数のパターンファイルに対応してくれたらなぁ（ﾁﾗﾁﾗ

これはもしかして知らな（ｒ

ttp://msdn.microsoft.com/ja-jp/library/yx9zd12s(v=vs.110).aspx

>>681
そういうのが公開されていたのですかｗ
やはり悩む人が少なくないのでしょうね。

>>682
それはないですｗ

>>683
OpenCL.dllの問題は解決しましたけど、
それを使うといいことがあるんでしょうか?

>>684
なんせ元の仕様が意味不明ですからねえｗ

もし、気が向いたなら、特殊パターンに「鏡トリップ」も追加して頂けると嬉しいです。

>>686
「回文」が「鏡」と一緒のはずです。

>>687
> 「回文」が「鏡」と一緒のはずです。
や、似てるけどちょっと違うのですが、まぁ面倒そうだし、取り下げます。
ちなみに例えば、
◆.AqMdbMpA.
これは鏡ですけど、回文ではありません。
回文だと、
◆.AqMddMqA.
こうなります。

>>688
もまいの言う「鏡」な文字列の定義はなんじゃらほい
「回文」とは比較にならないほど判定が難しくなる予感しかしないんだが……

そろそろ10桁酉の方は速くなりませんかね(要望)

>>688
ははあ、なるほど。ちょっと面白いですね。今やってる作業が終わったら
試してみます。

>>689
> そろそろ10桁酉の方は速くなりませんかね(要望)

「各種診断」の実装が終わったらとりかかる予定ですけど、
かなり時間がかかりますよ。

>>689
> もまいの言う「鏡」な文字列の定義はなんじゃらほい
え？
そんなに沢山の定義が考えられますか？？

> 「回文」とは比較にならないほど判定が難しくなる予感しかしないんだが……
実際にコードにすると難しいのかな？
回文トリップかどうかを判定する部分をちょっと変更するだけで
出来そうな気がしたのですが、そんなに複雑になるなら
速度も遅くなるでしょうし無理ですね。

>>690
> ははあ、なるほど。ちょっと面白いですね。今やってる作業が終わったら
あ、興味を持って頂けたみたいで嬉しいです。
優先順位最低で良いので、心の片隅にでも・・・

>>692
テーブル使えば実装は楽勝でしょう。
ちょっと今から作ってみます。

>>685
まっとうな方法じゃなくても動くんだし問題ないだろ、ということであればそれでもいいとは思う。
商用ソフトじゃないんだしな。

>>695
OpenCL.dllはどのみち初期化のときに必ず必要になので
いまいち使いどころがわからないんですが…

「鏡」のコードは一応出来ました。今テストしてますけど、
これ結構ヒットするのに時間がかかりそうですねえ。

「鏡」に使えるのは24文字なので出現確率は6完の半分ぐらいなのかな。
うまくいけば今日中に何個か採れるかな。

使えるのは [AHIMOTUVWXYbdilopqvwx80.] ですかね

そうです、そうです。

試しに部分的にマッチしたものを拾ってみました。これはおもろいｗ

----

◆Nl.XooX.hc #Yｭ懃Wf蜂m. (59 AD 9C E7 57 66 96 49 6D 2E)
◆ByAxqpxApA #:ωｻ\Pf揆ﾅ (3A 83 D6 BB 5C 50 66 9D 84 C5)
◆H5vbwwdvLc #ﾀｽEV`Q-札E (C0 BD 45 56 60 51 2D 8E 44 45)
◆qrdIVVIbjQ #4慊uJUﾀｶｿﾘ (34 9C C2 75 4A 55 C0 B6 BF D8)
◆sDVIHHIVGc #ﾃﾈ印[^oX缺 (C3 C8 88 F3 5B 5E 6F 58 E3 9E)
◆YROqllpOec #ﾙUｩﾓ`Oﾒ{bﾜ (D9 55 A9 D3 60 4F D2 7B 62 DC)
◆fAl0bd0lpw #踝湲OQｰﾌﾄq (E6 F4 9F D1 4F 51 B0 CC C4 71)
◆NroTHHTo7A #ﾟ麹BN_爽ｾ｣ (DF 8D 8D 42 4E 5F 91 75 BE A3)
◆2OUo00oUOw #ﾍ~ｬ?ﾋﾎ/ﾏ0ｶ (CD 7E AC 3F CB CE 2F CF 30 B6)

それ、回文よりいいな。w
早く検索したい。w

どうやらちゃんと動いているようですねえ。

◆UwbvllvdwU #ﾀ_ｦj%%霙7{ (C0 5F A6 6A 25 25 E8 C2 37 7B)
◆YWXpooqXWY #ｸh1=(@C\#ﾋ (B8 68 31 3D 28 40 43 5C 23 CB)
◆wXlAwwAlXw #Lﾂ3d='ixﾇn (4C C2 33 64 3D 27 69 78 C7 6E)

bdpqが無ければ回文でもあるってことか

そういうことです。私は好きですね、これｗ
今12桁のほうもテストしてますけど、こっちはもっと時間がかかりそうです。

tripcodes.txt のログですけど、例えば

◆YWXpooqXWY #ｸh1=(@C\#ﾋ (B8 68 31 3D 28 40 43 5C 23 CB)

これが、

◆YWXpooqXWY #ｸh1=(@C\#ﾋ (B8 68 31 3D 28 40 43 5C 23 CB)　2013/02/20 07:30:12　鏡

こんな風になると、結果はテキストだから、様々にフィルタ処理出来ていいなぁ、と・・・
日付があると、曜日や時間帯によってのヒット率とかどんなのがヒットするか調べられるし（無意味）、
特殊パターンのうちどのトリップか、が分かれば、それをキーにして抽出したり、ソートしたりも。

>>706
日時については>>629です。

> 特殊パターンのうちどのトリップか、が分かれば、
> それをキーにして抽出したり、ソートしたりも。

これはフィルタ処理する側でやればいいんじゃないでしょうか。
例えば鏡なら"^◆[AHIMOTUVWXYbdilopqvwx80.]+ #.*$"でほぼ確実に
マッチしますからね。

多分、複雑な正規表現を使うと検索速度が遅くなると思うのですが、
なるべく遅くならない様にする為の注意点って、具体的には何でしょう？
例えば、[0-5] より [012345] の方が速い、とか、[01][01][01][01] より
[01]{4} の方が速い、とか。
それとも、そんな事気にしても大して速度は変わらない？？

そういや昔、まだ「見知らぬ国のトリッパーw」が主流だった頃
出来るだけ先頭一致にまとまるように記述すると良い、って話は聞いたことあったな
それがどれほどの効果なのか、ずぶの素人にはとんと分からなかったが

>>706
それぐらいだったら秀丸でマクロ書けそう・・・

おーし誰か使いたい奴マクロ書いてうｐしてくださいお願いします

フィルタ処理するときに自分が突っ込んだ正規表現そのまま突っ込めばいいだけだろ
少しは頭使うようにしないと早く馬鹿になるぞ

>>708
600あたりで話してる内容はつまり検索パターンをまず展開して
それとバルクに照合してるということじゃねーの

俺が正しいこと言ってるとするとだが
つまり同一パターンを表す書き方の違いはファイル読み込みと検索開始前の展開時間にしか影響しない

いやログに「山彦」とか「最短」とか「準９連」とか表示されてた方がすぐ分かるじゃん。
それなら、フィルタ処理なんかする必要ないし、何よりも、見た目が賑やかで楽しい。ｗ
つーか、折角色んな特殊パターンをわざわざ内部で別処理してるんだから、私なら、
むしろログに書き込みたいけど。ｗ

って、
>>669
の
> 受け入れるかどうかを決めるのはあくまでも私です。
なので、100% 採用されない事はもう自明だけどね。

>>713
> つまり同一パターンを表す書き方の違いはファイル読み込みと検索開始前の展開時間にしか影響しない
ちょっと前に、何かを変更したら、二構の展開時間が相当速くなったみたいだし、
「検索開始前の展開時間」も十分重要だと思う。
まぁ、一回スタートしたら一ヶ月位そのまま、って人には関係ないかもだけど。

>>711
なんかすげーめんどい気がしてきた。
回文はともかく、鏡は正規表現抜きでやろうとすると指数関数的に置き換え処理が増える……

>>716
> 回文はともかく、鏡は正規表現抜きでやろうとすると指数関数的に置き換え処理が増える……
秀丸のマクロって、正規表現使えないの？