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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>381
(　д)　ﾟ　ﾟ

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

>>383

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

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

さようならゲフォ

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

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

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

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

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

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

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

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

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

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

No matches were found yet.

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

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

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

あ、平均間違った

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発版を修正しました。

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

64^12=4722366482869645213696
だもんなぁ。

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>449
私には

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

と

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エラーコード14って何？

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

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

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

がんばれー

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

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

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

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

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

貼り方間違えた

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

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

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

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

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

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

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

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

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

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

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

失礼しますm(_ _)m

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

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

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

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

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

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

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

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

新しい開発版です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>502
A10カッケーな

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

画像貼り忘れ

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

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

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

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

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

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

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

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

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

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

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

団子もびっくりだな。

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

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

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

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

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

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

新しい開発版です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

壊れてナンボがデフォ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>570
切ってみます

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

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

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

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

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

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

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

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

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

単相200V契約しよう

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

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

USAは、110ボルトですね。

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

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

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

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

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

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

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

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

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

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

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

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

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

>>588
全グラフィックチップ(680M+iHD4000)指定だと
検索開始後エラーメッセージなしでソフトごと落ちます
HD4000はバッサリ切った方がいいかと思われます

>>592
ありゃりゃ… こりゃいかんですねえ。テスト用には便利だったんですけど
しょうがないですね。次の開発版からは無視するようにします。

というわけで面倒くさいのでIntelのプラットフォームは最初から無視することに
しちゃいました。OpenCLはオープンスタンダードな分だけそれに伴う
問題も多いですね。

気を取り直して10桁トリップ検索の移植作業を続けます。
CPU側のコードは10桁の場合とほとんど同じなのですぐに終わりました。
問題はOpenCLのコードですが、バグが紛れ込むと見つけるのが
非常に困難になるので、慎重に作業を進めてます。

カーネルの入り口の部分の書き換えは終了しました。
あとはBitslice DESの本体だけですが、CUDAのコードをコピペするだけなので
問題はないでしょう。うまく動いてくれるといいんだけど、どうでしょうね〜

geforceでopenCL版って動くの？
動いてもcudaよりは遅い？

>>597
いまはNVIDIAのカードでは強制的にCUDAを使うようにしています。
OpenCLでも動くことは動くと思いますけど、基本的に全く同じコードなので
速度は変わらないでしょう。

OpenCLの10桁検索のコードは1発で動いたんですけど、Bitslice DESで使う変数を
何も考えずに全部__privateメモリ空間に突っ込んだら、案の定というか
まったく速度が出ていませんｗ まあでもコードの書き換え自体は問題なかったよう
なので、とりあえず一安心です。これから__globalと__localを試してみます。

khronosの姿勢として標準のカーネルコンパイラを用意しないのはわかるんだけど
やっぱりglslの轍をちょっとは生かしてほしかったってのが個人的な思い
meriken氏乙

>>594
当方では一応4M/sぐらいで動くので、
IntelHD4000を使うか否かをチェックボックスとかで決めればいいと思いまーす

>>598
そうなんだ
ありがとう

OpenCLで盛り上がっているところにCPUのみの結果を報告。

【GPU】Quadro FX 3800
【CPU】Xeon [email protected] x2CPU
【OS】MS Windows 7 Pro 64bit
【バージョン】0.07 Alpha 3 CUI64
【トリップの種類】12桁
【Display Driver】307.32

【その他】HT on
【その他のオプション】-c -t 24
【60時間の平均速度】80.51M TPS

【その他】HT off
【その他のオプション】-c -t 12
【2時間の平均速度】79.04M TPS

CPUだけで実行してもHTは殆ど効きません。NehalemとSandy Bridgeでは全然違うのかな?
ちなみにHT on の状態で、"-c -t 12"と指定すると、2CPU12コアに割り当てられずに、1CPU6コア12スレッドに割り当てられてスピードが出ません。

Alpha 6に上げて再度実行してみましたが、NVIDIAコントロールパネルの"3D設定"→"3D設定の管理"で"CUDA-GPU"を"なし"に設定すると、CUI64で"-c"オプションをつけても下記エラーが出て落ちます。
MERIKENsTripcodeFinderCUI: OPENCL FUNCTION FALL FAILED: Unknown (file 'Source Files\MTF_CUI_Main.cpp', line 715)

NVIDIA，第2世代Kepler「GK110」搭載の「Tesla K20」を正式発表。CUDA Core数は最大2688基に
http://www.4gamer.net/games/121/G012181/20121110004/

X5680はOCすりゃいいじゃん

DualCPUにQuadro突っ込んでるようなガチWS機でOCとかあり得んでしょ

倍率ロックフリーだろ？

今気づいたんですけど「1CUあたりのワークグループの数」じゃなくて
「1CUあたりのワークアイテムの数」ですね、これ。
こりゃ当分の間安定版は出せないな…

>>603-604
報告ありがとうございます。CPU検索ももうちょっと何とかしたいですね〜
"Unknown"のエラーが出ているのは謎ですが、そこのエラーは無視するように
直しておきます。

予想通りというべきか、10桁トリップ検索はなかなかスピードが出てくれません。
まじめにプロファイラを使わないと駄目ですね、こりゃ。
まあCUDAのときもそうだったので、のんびり時間をかけて取り組むことにします。

>>605
GK110も試してみたいんですけどね〜
Amazon Cluster GPU Instancesで使えるようにならないかしらん。

Bitslice DES用の一時変数をどのメモリ空間に置けばいいのかいまいち
よくわからないので、とりあえず#ifdefで切り替えられるようにしておきます。
あと、一回のBitslice DESを複数のスレッドで同時に処理するかどうかも
CPU側で設定できるようにする予定です。こういうところは実行時にカーネルを
ビルドできるOpenCLはいいですねえ。

【GPU】HD7970 CFX 2GUPｓ
【CPU】FX-8350
【OS】Win7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 6
【トリップの種類】12桁
【1CUあたりのワークグループの数】5120
【1WGあたりのワークアイテムの数】40
【その他のオプション】-c -g -t 6 -a 8 （-aオプションは有効なのか？）
【Display Driver】Catalyst 12.10
【10分間の平均速度】2614.21tripcodes/s
【GPUの平均速度】2575.40tripcodes/s
【CPUの平均速度】38.31tripcodes/s
【GPU使用率】95%
【その他】7完1タゲ

いろいろ調整したら瞬間最大風速では3000M程度出るようにはなりました
ラデはCPU負荷高いですね
フルにCPU8スレッドで回すと却って速度が出ないです
CPU単体でなら50M程出るんですが

それと、CFXの有効無効では速度は変わらないですよ

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

ついにデュアルTahitiカードがAMDから登場。エーキューブ，サーバー向けグラフィックスカード「FirePro S10000」を国内発売
http://www.4gamer.net/games/133/G013322/20121113023/

XeonPhiってどうなんですかねえ

負荷で思い出したけど、同じGPU使用率でもmtyのGPU版は95℃までいくけどMERIKENは89℃までしか上がらないね。

>>615
サーバ向けのFireProだし、3599ドルらしい。

>>616
OpenMPが使えて既存アプリの移植が楽らしいけど、既にOpenCLになっている場合はメリット薄そう。

>>614
なかなか良い感じに仕上がってますね。それだけOCした7970なら単体で1500M TPS近く
いくはずなので、単純に2枚で2倍の速度という訳にはいかないみたいですが…
Alpha 6では-aオプションは有効なはずです。CFXの話は別のところで見かけたんですが、
関係無かったみたいですね。

>>617
Bitslice DESはSHA-1の処理に比べてメモリへのアクセスの量が段違いですからねえ。

>>615
いいですね〜 いつかこういうのをたくさんラックマウントサーバーに乗っけて
Tripcode Finderを動かしてみたいですｗ

Southern Islandsだとコンスタントメモリは場合によってはグローバルメモリと
同じぐらい遅くなるそうで…こりゃCUDAと同じコードじゃ遅くなるわけだわ。
頻繁に使うのは最初にローカルメモリに移しておいたほうがいいな。

> 3. Varying Index
> More sophisticated addressing patterns, including the case where each work- item
> accesses different indices, are not hardware accelerated and deliver the same
> performance as a global memory read.

あとローカルメモリにアクセスする際はuint2を使うといいみたいです。

> Currently, the native format of LDS is a 32-bit word. The theoretical
> LDS peak bandwidth is achieved when each thread operates on a
> two-vector of 32-bit words (16 threads per clock operate on 32 banks).

vector data typesの使い方はここに書いてありました。

Programming with OpenCL C
http://www.informit.com/articles/article.aspx?p=1732873&seqNum=3

>>614
壁紙についてｋｗｓｋ
MERIKENさんの公式記録が越される日も近いか……

>>624
この辺で拾ってます
これがいつのものだったかは忘れましたw

http://www.smashingmagazine.com/tag/wallpapers/

>>625
そのまま2012/11の記事を見ても出てこないorz
http://www.smashingmagazine.com/2012/10/31/desktop-wallpaper-calendar-november-2012/
よろしければ画像アップローダに上げてくれませんか？

>>624
それはどうでしょうね… (￣ー￣)ﾆﾔﾘ

>>626
ほい

http://www.rupan.net/uploader/download/1352820886.jpg

>>621
どうせならHD7970 X2に行きませんか？
消費電力が凄まじいのと、スロット占有が問題ですけどｗ
なんかリンクが貼れないので詳細は検索してください

デスクトップ向けにHD7950のデュアルが出てくれれば一番ですけどね。
HD7950のCFはグラフィックでも割りと良いというレビューもあったので、需要もある程度ありそうですし。

>>622-623
OpenCLは以前よりは情報も増えたようですが、まだ茨の道なのでしょうかね・・・

>>628
ありがとうございます！

>>630
>>622-623はJohn the Ripperのメーリングリストを見てて気づきました。

http://www.openwall.com/lists/john-dev/2012/08/13/8
http://www.openwall.com/lists/john-dev/2012/09/10/5

このAlexanderという方はJohn the RipperとBitslice DESの偉い人です。
流石です。

http://www.openwall.com/lists/john-users/2011/06/22/1

>>630
まあGPGPUの不条理な制約にはCUDAで慣れっこになっているので
どうということはありませんｗ

>>629
うちの検索用マシンにはGTX 580が2枚と590が1枚載っているので、
7970 2枚は余裕ですｗ 今590を売っぱらって6990を買おうかどうか
考えているところです。

僕はもうラデ2枚構成にしたのでゲフォ売ります
10桁検索対応が楽しみですよー

>>633
頼もしいです、頑張ってください。

>>634
HD7970を1ボードに2基載せたもので8ピンx3で3スロット占有という
モンスターというかクレイジーな代物が出るらしいですｗ
それの複数枚挿しは電源だけでなくマザボもかなり選びそうです。

HD7950のデュアルで8ピンx2で2スロットであればまだマシなのですけどねえ。

やっぱりさよならゲフォの流れになったね

RADEONは普及用チップでも倍精度が高速なのがいい

mtyGPUがRadeonしか対応してないから、むしろゲフォ対応検索は(10桁では)貴重なんだが

>>638
マジレスすると倍精度演算が速いのは7970だけだしトリップ検索に倍精度演算の出番は無いぞ

>>635
10桁トリップ検索は12桁よりかなり難しいので、実際どこまで速度を出せるかは
わかりませんけどね〜 というか12桁検索の移植は正直うまくいきすぎでしたｗ
地道に取り組む予定なので、のんびり待っていて下さい。

で、あれから色々試してみて、Bitslice DES用の一時変数はローカルメモリに
おかないと全く速度が出ないことが分かりました。ローカルメモリは
ワークグループ内で共有されるので、Bitslice DESを8個のスレッドで
並列処理するように書き換えてやりました。

その後、さらに性能を上げるためにAMD APP Profilerで解析してみました。
あんまり期待してなかったｗのですが、非常に使いやすいです。
で、気になっていたOccupancy Analysisを行なってみたら、
案の定ローカルメモリ(LDS)の使い過ぎであることが判明しました。

http://www.meriken2ch.com/files/2012-11-13-AMD-APP-profiler.jpg

>>642
へぇ〜
人目でボトルネックがLDSにあることが示されてる
凄いな

同じ問題はCUDA版でも起きていたので思わず頭を抱えてしまったのですが、
ソースを眺めていたら解決方法を思いつきました。Bitslice DESの
一時変数は次の構造体にまとめられています。

> typedef struct {
> DES_Vector keys[56]; // 224 bytes
> DES_Vector dataBlocks[64]; // 256 bytes
> unsigned int dummy[1];
> } DESContext;

で、56bitのDESのキーが32個keys[]に収められているのですが、
これらのキーは実際にはほとんど同じです。
というわけで、キーの生成の方法を工夫してやれば、32個のキーの共通部分
51bitだけを保持して、残りは5bitのインデックス(0〜31)から生成して
やればいいことに気づきました。

これで使用するメモリの量は半分近くに減って、うまくいけば
CUDA版ともども10桁検索の速度が倍になることになります。
アルゴリズムはかなり複雑になりますが、試してみる価値は十分にあります。
hip2の話を聞いて、キーの生成方法にかなりの工夫の余地があることに
気づいたのは僥倖でしたｗ

>>643
実際かなり便利です。CUDAのときはなんせExcelのスプレッドシートを
使わないとOccupancyのグラフが見れませんでしたからねｗ

>>645
>速度が倍
うおおおおお！？頑張って下さい！

GTX670では470Mt/sくらいしか出ません。倍精度を使うわけでもないのになんでだろう。

ゲフォはさよならですかそうですか。
GTX480が何とか復活したので速度計測。

【GPU】GeForce GTX 480
【CPU】Xeon [email protected] x2CPU
【OS】Win7Pro 64 SP1
【バージョン】0.07a6 CUI64
【トリップの種類】12桁
【1CUあたりのワークグループの数】N/A
【1WGあたりのワークアイテムの数】N/A
【その他のオプション】-c -g -x 128
【Display Driver】306.97
【10分間の平均速度】648.27M TPS
【GPUの平均速度】578.39M TPS
【CPUの平均速度】69.89M TPS
【GPU使用率】100%
【その他】"TEST/", HT off, GPU 92℃

Quadroをぶっちぎっているのですが・・・うるさい。とにかくうるさい。
常用は無理です。

>>642
これは便利そうですね。

>>644
DESは歴史もあり奥が深いですね。

>>648
レジスタ数がネックになって演算ユニットを使いきれていないのだと思います。

レジスタの仕様が違うのか。最適化しなおさないといけないわけね。

>>648
>>651
トリップ検索の速度は整数演算の性能に大きく影響されるんですけど、
GTX 600シリーズで使われているKeplerコアは残念ながら整数演算が
かなり遅いのです。この点は次の記事の「命令別スループット」の
項目で詳しく解説されています。

GTX680のグラフィック・GPGPU性能を調べる ≪ dokumaru
http://dokumaru.wordpress.com/2012/03/27/gtx680-spec/

Keplerではゲームで使われる単精度演算以外はほとんど無視して
性能を稼いでいるので、GPGPU的にはかなり残念なことになっています。

>>649
580とあまり遜色のない速度が出ていますね。
自分の部屋ではGeForceが3枚24時間フル稼働してますｗ
CUDA版の開発も続けるので安心して下さい。

ここ数カ月のjohn-devでのOpenCLでのBitslice DESの実装についての
やり取りを追って見たのですが、なかなか面白かったです。

http://www.openwall.com/lists/john-dev/2012/09
http://www.openwall.com/lists/john-dev/2012/10
http://www.openwall.com/lists/john-dev/2012/11

現在John the Ripperは7970で20M c/sしか出せていないのですが、
OpenCLの実装を担当しているSayantan氏に対して、
Alexander氏が7970なら300M c/sは出るはずからボトルネックを探せ、
と言っているのが非常に興味深いです。

> Something like 300M c/s at DES-based crypt(3) on HD 7970. Maybe more
> than that if we hard-code E (generate or patch code on the fly).
http://www.openwall.com/lists/john-dev/2012/10/14/1

手元のTripcode Finderのコードは現在のJtRの実装より大分速いのですが、
それでも300M TPSには遠く及びません。レジスタ数にもまだ大分余裕があるし、
工夫の余地はいろいろあるのでしょう。実に奥が深いです。

Bitslice DESをマルチスレッド化したときにエンバクした模様。
結構な確率で間違ったトリップが出力されます。
CUDAと同じコードのはずなんですけど、barrier()がうまく動作してないの
かしらん。
しかしこれ、どうやってデバッグするんだろう…

>>655
昔ながらの printf でおｋ。
手段として美しくないのは嫌いとかなら知らん。

やっぱりそれしかないんですねorz

>>657
私が hip2 つくってた頃は printf すらなかったのに。
贅沢ね。

>>658
まあそりゃそうなんですけどね…

あ、原因分かったかも。CUDA版を書いてたときに適当だったところが
今になって問題になっているのかもしれません。

う〜ん、違うな… もうちょっと全体的に腐ってる感じです。

まあいいや。マルチスレッド化の作業はまた明日やり直すことにしよっと。

コードをロールバックしたらちゃんと動作するようなのでやっぱり
マルチスレッド化が原因のようです。マルチスレッド化すると
速度が倍近くになるので次はなんとか成功させたいところです。

480が余りにもうるさいので、590に交換。

【GPU】GeForce GTX 590
【CPU】Xeon [email protected] x2CPU
【OS】Win7Pro 64 SP1
【バージョン】0.07a6 CUI64
【トリップの種類】12桁
【1CUあたりのワークグループの数】N/A
【1WGあたりのワークアイテムの数】N/A
【その他のオプション】-c -g -x 128
【Display Driver】306.97
【10分間の平均速度】978.15M TPS
【GPUの平均速度】922.60M TPS
【CPUの平均速度】55.55M TPS
【GPU使用率】0-100%
【その他】"TEST/", HT off, GPU 85℃

CPUの負荷変動がかなり激しいです。6コアx2が100％になることはまず無く、全コアが完全にストールすることも良く起こりました。
>>170 でもある程度CPUの負荷は変動しましたが、ここまで酷くは無かったです。
おまけにGPUもたまに完全にストールする始末。これは>>170 のマシンでは無かった。
タゲを増やすと負荷変動は落ち着きます。ここまで負荷がふらつく理由がさっぱり分かりません。

電源容量が足りないんじゃ

OpenCLの10桁検索ですが、もうちょっと調べたらどうも移植した直後から
問題があったようです。APP Profilerがメモリリークを報告しているので
もうちょっと調べてみます。

>>664
温度に問題がないなら電源の可能性が高いですね。
電源は何を使われていますか?

どうやら問題はBitslice DESの処理そのものではなく
他の処理にある模様。ちゃんと出力をチェックするルーチンを
作りこんで、徹底的にテストするしかないようです。
やなよかんはしてたけど、やはり10桁検索は楽ではないですねえ。

電源が届くのを待ちきれなくて、無理矢理繋げて実行していました。
電力不足でこんな挙動をするとは初体験で全然知らず。お恥ずかしい限りです。
素直に電源届くまで待っています。

>>669
そりゃそこにカードがあれば試したくなりますよね。
その気持、わかりますｗ
電源が届いたらまたぜひ報告して下さい。

OpenCLの10桁検索の出力が腐っていた問題ですが、カーネルをすこしづつ削って
原因を探ったところ、結果を書き込む__globalの配列へのアクセスの前後に
barrier()を入れてやると問題が出なくなることが分かりました。

Bitslice DES用の一時変数を__privateに置いても直らなかったし、
CUDA版やOpenCLの12桁検索では全く問題がなかった部分なので、
AMDのOpenCLの実装のバグの可能性が非常に高いです。
AMDの実装は性能は出るのにいちいち造りが甘くて非常にもったいない
感じがします。ここらへんもCUDAのほうが任期がある理由なんでしょうねえ。

この件でコードをロールバックした時に気がついたのですが、
Bitslice DESの一時変数を__private空間においても割と速度が出ることが
わかりました。こっちのほうが__localよりもベクトル化しやすいので、
このまま__localを使わずに最適化をすすめることにします。
Bitslice DESの深さを32bitから128bitにして速度も4倍といきたい
ところですが…

>>672
>ベクトル化
よく知らないのですが、GPUってベクトル演算なんですか……？
ベクトル化の意味は知っているのですが、なぜか「昔のスパコン」ってイメージが……ｗ

GPUはベクトル演算の極地だし、今のスパコンはほぼ全てベクトル演算ですが

もの自体がベクタプロセッサの集合体

>>673
そこがGPGPUの一番美味しいところですｗ
性能を引き出すのはなかなか難しいですけどね〜

あの後色々調べてみたんですけど、単純にDES_Vectorをuint2やuint4で置き換えて
やれば性能が出るというわけでもないようで、もうちょっと調べる必要が
あるみたいです。

あと、localなメモリに書き込んだ後は必ずbarrier()を呼び出さないと、
ちゃんとメモリ操作の結果が反映されないようです。おかしいなと思って
OpenCLの仕様書を見ると確かにこう書いてあります。

> The barrier function also queues a memory fence (reads and writes) to
> ensure correct ordering of memory operations to local or global memory.
http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/barrier.html

CUDAの場合は動機が必要なところで__syncthreads()を呼び出してやれば
後はなにも考えずに共有メモリとグローバルメモリに読み書きできたのですが、
どうも勝手が違うようです。

OpenCLでの10桁検索の話の続きです。
>>545の案を実際に実装してメモリの使用量を半分に抑えることで、
速度を50%ほど向上させることができました。キーを動的に生成することに
よるペナルティが割と大きく2倍とはいきませんでしたが、
まあそれでもかなりの進歩です。Kernel Occupancyはこんな感じです。

http://www.meriken2ch.com/files/2012-11-17-AMD-APP-profiler.jpg

ローカルメモリを使うと出力が化けまくるので、とりあえず
Bitslice DES用の一時変数はすべてレジスタ上においています。
このままレジスタの数を削ってOccupancyを上げてもいいし、
またローカルメモリに戻してみてもいいし、これでようやく先がすこし
見えてきた感じです。

一応ローカルメモリに戻して速度を測ってみたのですが、
思ったほど速度は出ませんでした。というわけで
一時変数はこのまま__private空間においたまま
最適化をすすめることにします。
カーネルをなるべく簡単にして、キーの生成の準備をすべて
CPU側で行うことにします。
またレジスタの数を削る日々がはじまるお…

あの後ちょこちょことカーネルをいじっていたんですけど、
適当なところにbarrier()を入れるとレジスタ数が減ったり
スピードが上がったりと不思議なことの連続でした。
色々実験してみるもんですね。こんなことは流石にマニュアルには
書いてあるわけないしｗ

奇妙すぎる仕様だ……

これは4日前に公開されたばかりのRadeon用のアセンブラです。

GCN ISA Assembler
http://devgurus.amd.com/message/1285111

HetPas
http://realhet.wordpress.com/2012/11/14/hello-world/

GCNの命令セットについてなかなか面白いことが書いてありました。
こういうので最適化したらものすごい速度が出るんでしょうねえ。
JtRのAlexsander氏は動的にコードを生成しろなんて言ってたけど…

>>681
まったく謎だらけですｗ カーネルアナライザを使えばもうちょっと詳しく
分かるんでしょうけど、goto文を使っているとエラーが出て動かないんですよね…

気分転換で、前から欲しかったトリップの自動保存と自動検索実行の機能を
つけてみました。ブレーカーが落ちるたびにうんざりしながら検索君1号を
立ち上げなおしていたのですが、これで再起動もボタンを押すだけで済んで
検索結果が失われることもなくなりました。この機能は次の開発版から
利用できるようになる予定です。

>>684
そんなにブレーカーが落ちる環境だったとは……
(開発以外)休んでも、いいのよ？

海を越えると電気も日本みたいに高品質じゃないんだよ

>>685-686
グラボ4枚で検索するようになってから急に落ちるようになりました。
ブレーカーがどうも古いみたいで、大家さんに言ったんですけど
ちっとも変えてくれません。まあでも消費電力に常に気を付けるように
したら大分ましになりました。

レジスタ数を107から90まで頑張って減らしました。
目標の84まであともうちょっとなんですけど、
コンパイラの挙動が全く予想できないのでなかなか難しいです。

カーネルアナライザが動かなくてカーネルのILとISAが見られなかったん
ですが、次のページを参考にしてようやく見れるようになりました。
カーネルをビルドするときにオプションで"-save-temps=[prefix]"と
していしてやればビルド時の一時ファイルが保存されます。

Looking for specific details of GPU_DUMP_DEVICE_KERNEL
http://devgurus.amd.com/thread/159168

Kernelanalyzer refuses to compile anything
http://devgurus.amd.com/thread/159924

最近のドライバではカーネルアナライザは動かないそうで…
AMDにはもうちょっと頑張ってもらいたいものです。

あの後レジスタ数を減らすためにいろいろと試してみたのですが、
どうやっても90から更に減らすことはできませんでした。
どうも本気でレジスタ数の割付を最適化するためには
GCNのコードを直接書く以外ないようです。

仕方が無いので、割と時間がかかっているカーネルへの入出力の処理を
効率よく行うようにするための作業にとりかかりました。
とりあえずオーバーヘッドの大きいclEnqueueWriteBufferを1つにまとめたら、
なぜか未だに完全に消えてなかった出力が化けるバグが綺麗さっぱり
なくなりました。やれやれです。

さっきjohn-devの11月のポストを読んでたんですけど、
何か問題が起きるとすぐにAMDのOpenCLドライバのバグが疑われてて
笑ってしまいましたｗ これは相当評判が悪いみたいですね…

> > All my accusations about driver bugs were... well they were based
> > on statistics, what can I say? :-)
> >
> > magnum
> We saw some craziness that justify our accusations.
http://www.openwall.com/lists/john-dev/2012/11/22/5

なんにせよドライバのバグを華麗に避けつつOpenCLの10桁検索を使い物に
するには相当時間がかかりそうなので、とりあえず12桁検索のほうを
先に仕上げてしまうことにしました。今週末に次の開発版を公開する予定です。

>>691
ドライバの完成度の問題ですか、厳しいですねえ・・・

鳥屋は凄腕だな。

鳥屋氏が凄腕なのは間違い無いですね。mtyのGPU版の速度は異常です。
ただCAL ILで書かれたmtyと同じ速度をOpenCLで出すのも無理な気がしますけどね〜
JtRの20M c/sは論外にしても、Hashcatですら7970で79M c/sしか出せていない
ですからねえ。もうちょっとJtRのSayantan氏に頑張ってもらいたいものですけど、
メーリングリストのやり取りを見ている限りではとても期待できそうにありませんorz

なにか10桁検索の参考にならないかと思ってJtRのソースを眺めていたら、
全然関係ない12桁検索の高速化のネタを見つけましたｗ
といってもハッシュ作成の際にbitselect()とrotate()を使うというだけの
話なんですけど、効果は抜群でOCした7970単体で1600M TPSを軽く超える
速度が出ています。いまだにこんなおいしいネタが転がっていたとは驚きです。

>>695-696
ということは12桁最高記録が300M/s以上増えることに！？

ところでmtyGPU版の10桁最高記録ってどれほどなのでしょう？
自分で(2chソースを)ググって分かったのは237M/s(1枚で)、枚数差しても〜750M/sぐらいだったのですが……

>>697
スレチだな。ｗ
こっちいけ。
http://yy43.60.kg/test/read.cgi/tripageruo/1274911652/

>>698
後半荒らされ放題じゃないですか………‥

なるほど、少なくとも>>79で714M/sという記録が出ていたんですね。失礼しました

最大公約数的なプログラミングじゃなくて、自分の持ってるカードに絞ってゴリゴリ書いていけばいいんじゃないの？
その方が速度も出ると思うんだけど

MERIKENさんってTOEIC満点とれる超人だったんですね・・・

>>697
今でも3.5G TPSあたりなら堅いでしょう。いろいろ弾を仕込んでいる最中なので、
次に記録を狙うときには目標は4.5〜5G TPSあたりになると思います。

>>700
最大公約数的なプログラミングはとっくの昔に諦めて7970にターゲットを絞って
ますけど、それでもなかなか難しいです。

>>701
私は大学からアメリカなのであれはいろんな意味で「おまけ」なのですｗ

1台のPCに積載できるGPUの量には限りがありますし、
そのうちサーバプログラム用意して検索条件の配布、検索結果の集計みたいな疎結合クラスタになりますん？

>>705
そのうちそうなるでしょうねえ。スタンドアロンでの性能がちゃんと出るようになって
からということになるので相当先の話だと思いますけど…

>>705
トリップ検索クラスタ(物理)か……
GPUが絡まないと有り難みが薄いですねｗ

トリップ検索p2pネットワークか‥胸熱

>>698
スレチと、言ってるののたんに　　（はぁはぁ

>>708
個人でクラスタするのは有りだけど、
参加フリーでみんなの検索条件を合算するようになると生成されたトリップの判定にパワー食っちゃって……

サーバーから検索条件をダウンロードしてみんなで12連とかのレアトリップを
探すというのも面白いかもしれませんねｗ

10桁検索のほうはAlexander氏の言っていた、動的にカーネルを書き換えて
DESのexpansion functionをソースに埋め込むという方法で以前に比べると
大分速くなりました。が、それと同時にドライバのバグによる出力が化ける問題が
再発生した模様。まったく地雷原を歩いているようです。

出力が化ける問題はなんとか解決できました。いや〜、まいったまいった。

というわけで実行時のカーネルの書き換えでようやくHashcatとほぼ同じ速度が
出るようになりました。Tripcode FinderのCUDA版の10桁検索はHashcatよりも
ちょっと速いぐらいなので、もうそろそろ限界のような気もしないでも
ないです。あとはGCNのコードを手書きしてS-Boxを最適化して
レジスタ数を削るぐらいしか思いつきません。とりあえず10桁検索は
しばらく置いておいて、次の開発版を用意することにします。

2週間ぶりの開発版です。

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

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

・OpenGLの12桁トリップ検索の高速化。
・検索スレッドと検索プロセスの数を指定するオプションの追加。
・検索の自動実行と検索結果の自動保存を行うオプションの追加。
・様々なバグの修正。

検索スレッドと検索プロセスの数を増やすことによって、
複数のGPUを使用する場合のGPUの使用率を増やすことができます。
おいしいです（＾ｑ＾）

おつおつ
回してみるべ

この構成であるふぁ7
http://www.dotup.org/uploda/www.dotup.org3665284.png

Alpha 7用の新しい報告用のテンプレです。

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

>>715
ぜひ色々試してみてくださいｗ

>>716
これは1枚ですか? かなり出てますね〜

書き忘れー
解凍したまんまで
GPUの温度は室温20度で41度まで上がった、負荷は100%
水冷だしこんなもんだね、ゲームだと36度くらいしか上がんないからいかにGPUが仕事してるかわかるw

>>719
ですよー、リファの7970

唐突だけどコマンドラインオプションの私的まとめ(☆はデフォルトでは自動設定される項目):
--redirection　　　　　 　?
-f [inputfile] 　 　 　 　 　入力ファイル名
-r [inputfile]　　　　　　　入力ファイル名(正規表現)
-o [outputfile]　　　 　 　出力ファイル名
-l [length]　　　　　　　 　検索するトリップ長(12 or 10)
-g　　　　　　　　　　　　　検索にGPUを使用　(デフォルト)
-d [device] 　 　 　 　 　 CUDAデバイス番号(0〜)　(デフォルトは全て使用)
-x [block/SM]　　　 　 　ブロック/SM(CUDA)　☆
-y [workgroup]　　　 　　ワークグループ/CU(OpenCL)　☆
-z [workitem] 　 　 　 　 ワークアイテム/WG(OpenCL)　☆
　　　　　　　　　　　　　 　※workgroup mod workitem=0、workitem mod 8=0とすること
-c　　　　　　　　　　　　　検索にCPUを使用(-gと併用可)
-t [threads] 　 　 　 　 　CPUにおける検索スレッドの数　☆
-a [threads]　　　　　　　1つのAMDのGPUに対する検索スレッドの数(OpenCL)　☆(〜0.07Alpha6)
　　　　　　　　　　　　　 　1検索プロセスあたりの検索スレッドの数(OpenCL)　☆(0.07Alpha7〜)
-b [processes]　　　　 　1GPUあたりの検索プロセスの数(0.07Alpha7〜)
-m MutexForMERIKENsTripcodeFinder-4648　GUI版とCUI版が通信するときに使うおまじない(〜0.07Alpha6)
-m MutexForMER　　 　GUI版とCUI版が通信するときに使うおまじない(0.07Alpha7〜)
-i　　　　　　　　　　　　 　2ちゃんねるで直接使用できないトリップを16進形式で出力
-w　　　　　　　 　 　 　 　検索スピードの急激な低下を警告

>>722
あ、-yは「ワークグループ」じゃなくて「ワークアイテム」です。
最初に書いたときに間違えちゃったんですよね〜

>>721
う〜ん、水冷は素晴らしいですね。空冷での温度を見慣れていると
別世界のようですｗ

>>723
つまりこうですね、分かります。
>-y [workitem1]ワークグループ/CU(OpenCL)(デフォルトは自動設定)
>-z [workitem2]ワークアイテム/WG(OpenCL)(デフォルトは自動設定)
>※workitem1 mod workitem2=0、workitem2 mod 8=0とすること

ところで--redirectionって何をリダイレクトしているんですか？

俺おっちょこちょいの素質あるのかな……
>-y [workitem1]ワークアイテム/CU(OpenCL)(デフォルトは自動設定)
>-z [workitem2]ワークアイテム/WG(OpenCL)(デフォルトは自動設定)
>※workitem1 mod workitem2=0、workitem2 mod 8=0とすること

次のVerからはREADMEに訂正が必要なようですね……＞MERIKENさん

>>725-726
リダイレクトしているのは標準出力です。
訂正はもう入ってますよ。

【GPU】Xeon E5-2687W×2
【CPU】HD6990×2
【OS】Windows８ Pro
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 7
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】-
【1CUあたりのワークアイテムの数(OpenCL)】解凍時のまま
【1WGあたりのワークアイテムの数(OpenCL)】解凍時のまま
【1GPUあたりの検索プロセスの数(OpenCL)】解凍時のまま
【1検索プロセスあたりの検索スレッドの数(OpenCL)】解凍時のまま
【その他のオプション】-
【Display Driver】Catalyst12.11β
【5分間の平均速度】 4816.85tripcodes/s
【GPUの平均速度】 4711.99tripcodes/s
【CPUの平均速度】 104.86tripcodes/s
【GPUの使用率】100%
【GPUの温度】一番高いコアで46℃
【その他】GPUはTDP450Wモード定格
http://www.dotup.org/uploda/www.dotup.org3665573.png

これはもしやメインも仕事してくれるのではと思ったら案の定
時間ないんでどちらも5分でスマヌ

>>728
これは最高速の記録ですね。素晴らしいです。
私も次に記録を狙うときにはもうちょっと弾を揃えないと…

>>728
脳内での　最　速　記　録　が　塗　り　替　え　ら　れ　た　瞬間であった

期待できないけどノートで回してくるー

因みにこれで1160W前後の消費電力

>>569 です。Alpha7公開お疲れ様です。

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

>>731
450W x 2 + αですか。こりゃすごいｗ

>>732
5770でもかなり速度が出てますね。
今回はかなり内部をいじったので、ちゃんと動いているようでほっとしました。

【GPU】HD7970 CFX 2GPUｓ ＠1150MHｚ
【CPU】FX-8350 ＠5GHｚ
【OS】Windows7 64bit
【バージョン】MERIKEN's Tripcode Finder 0.07 Alpha 7
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】
【1CUあたりのワークアイテムの数(OpenCL)】960
【1WGあたりのワークアイテムの数(OpenCL)】64
【1GPUあたりの検索プロセスの数(OpenCL)】default
【1検索プロセスあたりの検索スレッドの数(OpenCL)】default
【その他のオプション】-g -c -t 6
【Display Driver】Catalyst12.11 beta6
【10分間の平均速度】5277.77 tripcodes/s
【GPUの平均速度】5243.39 tripcodes/s
【CPUの平均速度】34.39 tripcodes/s
【GPUの使用率】99%
【GPUの温度】76℃
【その他】7完1タゲ

効率が上がったためか-t 6で回したら強制シャットダウン、恐らく冷却不足か電源容量不足
とりま、ぬるい設定で解凍したまま

※今までは検索始めるとマウスカーソルがカクカクになり、USB音源を見失っていましたが、そういった現象はなくなりました

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

あ、-t 4 の間違いです

　ノーパソから計測実験。デスクトップでグラボぶん回すのと比べると雑魚レベルだが許してくれ。
【GPU】NVIDIA GeForce 610M(、Intel HD Graphics 4000)
【CPU】Intel Core i5-3210M
【OS】Windows Vista Home Ultimate SP1 64bit
【その他のオプション】-g -c -l 10か-g -c -l 12での計測(速度が安定した時点で記録)
【Display Driver】見方を教えて下さい……
↑の条件で、ソフトのVerと桁数を変更しながら計算するとこうなった↓

0.07Alpha6　　0.07Alpha6　　 0.07Alpha7　　 0.07Alpha7
10桁　　　　 　 12桁　　　　　　10桁　　　　　　12桁
----------------------------------------------
使用不可　　　160　　 　 　 　 使用不可　　　128　　　　　 ←blocks/SM
使用不可　　　64　　　　　　　 使用不可　　　使用不可 　 ←items/CU
使用不可　　　32　　　　　　　 使用不可　　　使用不可 　 ←items/WG
4　　　　　　　　2　　　　　 　 　 3　　　　　　　　3　　　　　　　←CPU演算スレッド数
使用不可　　　48.9M/s　　　　3.54M/s　　　　48.96M/s　　←速度(CUDA)
使用不可　　　4.9M/s 　 　 　 使用不可　　　使用不可 　 ←速度(OpenCL)
使用不可　　　9.66M/s　　　　4.03M/s　　　　10.91M/s　　←速度(CPU)
5.27/s　　　　　63.43M/s 　 　 7.57M/s　　 　 59.87M/s　　←合計速度
----------------------------------------------
確かに改良は効いているが、な　ぜ　ア　ホ　の　子　を　外　し　た　し

>>735
これはすごい数字ですねえ。いくらなんでも速すぎだろうと思って
Catalyst 12.11 Beta 8を試してみたら、うちの7970 1枚でも2497M TPS
出てて吹きましたｗ 12.9 Betaではここまでのスピードは出なかったので、
ここ2ヶ月でAMDのドライバにかなり手が入ってますね〜

7970の4wayやれば10Gか…
コンセントの端子が熱くなるな

公式サイト(http://www.meriken2ch.com/programming/merikens-tripcode-finder)とか見ていると
OpenGLとOpenCLが脳内でごっちゃになりそうなのでまとめ：

OpenGL……シリコングラフィックスが開発していたクロスプラットフォームな3DグラフィックスのAPI。
　　　　　　　　ハードウェアに近い低水準な機能も使えるので高速だが、文字列描画が苦手。
　　　　　　　　GPGPUの利用法は、OpenCLよりもグラフィックス寄り。
OpenCL……アップルのKhronos Groupが開発した、クロスプラットフォームな並列コンピューティング用のAPI。
　　　　　　　　要するに、「CPUやGPUなどの計算資源を、並列演算用にまとめて扱えるようにするよ！」
　　　　　　　　といったもの。GPGPUの利用法は、OpenGLよりは演算寄り。

>>740
あ、あれはOpenCLの間違いで、OpenGLは一切関係ないですｗ
ご自分用のまとめはここに書き込まないでいただけると有難いです。

>>737
OpenCL以外の検索ルーチンはいじってないので速度は変わっていないはずです。
Intelのはドライバのバージョンによってアプリケーションが落ちるろいう報告が
あったのでやむなしです。

>>741
了解しました。
>>742
そうだったんですか……。チェックボックス対応でも、というのは無茶でしょうか。
10桁の演算速度が上がっているのは確実な気がするのですが、
単に自環境ではAlpha6でGPU演算が使えなかっただけ(デバイスが対応していない)
なのかもしれません。次買うのはRadeonGPU搭載PCにするかな…‥

>>740
geforce君はもう書き込まないでくれるかな？

>>743
Intelのはドライバの出来がイマイチで性能が全く出ないのに
メンテの手間だけかかって、おいしいところが全くないんですよね。
Intel対応はXeon Phiが消費者向けに発売されたら考えますｗ

>>745
確かに、グラボが出す速度を考えたらIntelのは誤差の範囲ですよねｗ
もうその件については触れないことにします。回答ありがとうございました。

ドライバといえば、Catalystの新しいβ版で10桁検索を試してみたら、
速度が1/3になっていましたorz CUDAでもそうでしたけど、
GPGPUは開発環境やドライバによってアプリケーションの性能が
乱高下する傾向がありますねえ。ドライバの次のバージョンアップで
直っているといいんですけど…

新しいAMDのドライバで12桁トリップ検索のプロファイリングを行って見たのですが、
ベクターレジスタ(VGPR)の数が40まで減っていて、Occupancyが10から60にまで
上がっていました。どうりで検索速度が上がっているわけです。

どうやらAMDのコンパイラの最適化のアルゴリズムが、命令の数を増やしてでもレジスタ数を
減らすことを優先するものに変更されているようで、それが12桁の場合はうまく働いたけど
10桁の場合は完全に裏目に出ている、ということらしいです。やっぱり本気で10桁トリップ検索で
性能を出そうと思ったらILかGCNのコードを自分で書くしかないみたいですが、とりあえず
以前のドライバでOpenCLバイナリを生成して、実行時にはそれを使うように変えておくことにします。

AMDのOpenCLドライバをAMD APP 2.7のものにロールバックしたら
ようやく10桁検索の速度が元に戻りました。次のファイルは
ドライバのアンインストールでは削除されずに直接手で削除する
必要がありました。

SlotMaximizerBe.dll
SlotMaximizerAg.dll
amdocl.dll
OpenVideo.dll
OVDecode.dll

これがわかるまでエラく手間取りましたが、これでようやくOpenCLバイナリの
作成に取り掛かれます。

10桁トリップ検索のコードですが、なんとCatalyst 12.8以前のドライバでは
出力が化けることが判明しました。ドライバのバクにしても
いくらなんでもひどすぎるorz

>>746
手間がかからないならサポートしてもいいんですけど、テストの量が倍以上に
なりますからねえ。残念です。

>>739
これ2枚積めば10G TPS超できそうです。TDP 500Wの化物だけど、
普通に検索君1号に2枚収まりそうなんだけど、流石に20万は払えないよな…
あぶないあぶないｗ

Radeon最上位のデュアルGPU版「HD 7990」発売、重さを支える支柱付き カードは弩級
http://akiba-pc.watch.impress.co.jp/hotline/20121124/etc_club3d.html

Club 3D Radeon HD 7990 Dual GPU
http://www.club-3d.com/index.php/products/reader.en/product/radeon-hd-7990-dual-gpu.html

>>752
そんなに電源虐めたいかｗｗ

>>753
そこにハードウエアがあれば限界まで性能を出したくなるのが
男のさがというものですｗ

10桁酉が割られる日も近いな…ｺﾞｸﾘ

10桁検索ですけど、crypt()のseedの値に基づいてカーネルを動的に
書き換えていたことをすっかり忘れていましたｗ
これって実行時にOpenCLバイナリを書き換えるか、seedの数だけバイナリを
用意しなきゃいけないってことだよな…

>>756
最適化スゲェ……
でも、10桁のシード(ソルト)って確か2バイト分(最大256^2=65536通り)あるんじゃ

>>757
実際には2chの仕様のせいで65^2=4225通りなんですけど、
それでも結構な数です。とりあえず実験的に作ってみますけど、
さすがにこれを配布パッケージに含めるのは考えちゃいますねｗ

>>758
単純に考えて、3.5MB×2×4225≒30GBかぁ……

動的書き換えでお願いします(切望)

>>759
書き換えが必要なのはOpenCLのカーネルのバイナリだけなので
そこまでひどくはならないですｗ せいぜい数十MBのオーダーでしょう。
圧縮がかなり効くはずなので配布パッケージ自体はそこまで大きくならない
はずですけど、こればっかりは試してみないとわかりません。

新しいドライバで10桁検索をプロファイリングしてみたのですが、
SALBusyが80.84%なのに比べてVALUBusyが28.91%と妙に低いのに
気づきました。MemUnitBusyが66.81%とかなり高いのも気になります。
これは実際にS-Boxで費やされている実行時間は全体の3割程度ということで、
かなり効率が悪いことになります。ちょっとドライバのバージョンを落として
比較してみます。

>>747-748
バージョンによって最適化がかなり違うのですか、面倒ですねえ。

>>756
saltに応じてカーネルの動的書き換えとかできるのですか。
できるにしても実際にやるのが凄いですｗ

>>758
crypt(3)の仕様で64^2=4096通りではないのですか？

>>762
あれれ、そうでしたっけ? もうちょっと調べてみます。

>>762
CUDAでも開発環境のバージョンによってかなり速度差が出てましたけど、
OpenCLではドライバのバージョンで違ってくるので頭が痛いです。
HashcatはカーネルをLLVM IRで配布してるみたいですけど、
似たようなことをしたほうがいいのかもしれません。

Catalyst 12.9 Betaに戻してみたら、こんな感じでした。

VALUBusy: 28.91% -> 36.15%
SALUBusy: 80.84% -> 113.88%
MemUnitBusy: 66.81% -> 63.67%

VALUBusyがちょっと上がっただけで速度は3倍になってるので、
ベクターユニットが遊んでいるせいで7970は相当余力を残している
ことになります。かなりの性能向上が期待できそうなので、
OpenCLの実装が一段落したら、自分でGCNのコードをいじってみようかな…

>>765
> SALUBusy: 80.84% -> 113.88%
100%越えってどゆことー？

>>766
それはまったく謎ですｗ

>>762
調べてみましたけど、2chのトリップ生成でのsaltの扱いはcrypt (3)の仕様から
ずれているので、やっぱり4225通りであってました。

2ch トリップ仕様
http://sourceforge.jp/projects/naniya/wiki/2chtrip

最初に10桁トリップ検索の実装をした時にも思ったことですが、
見れば見るほどひどい仕様ですｗ

>>768
面妖な！

……ひょっとして10桁検索がどうしても遅くなるのはここにも理由があるんじゃ

7990ですけど別の会社からも発売されてますね。

PowerColor AX7990 6GBD5-2DHJ Radeon HD 7990 6GB
http://www.newegg.com/Product/Product.aspx?Item=N82E16814131483

一枚で$899なので>>752のカードより大分安いですが、がまんがまん…

>>769
10桁検索が遅くなるのはBitslice DESでメモリへのランダムアクセスが
大量に発生するのが大きいです。こればっかりは仕方ないですね。

isaファイルを出力させてGCNのコードを眺めてたんですが、
register spillsが発生している模様。"ScratchSize = 140;"なる記述が
isaファイルにありました。道理でなかなか速度が出ないわけです。
プロファイラのScratchRegsの欄がNAになってたので完全に油断してました。
NAはnot applicableじゃなくてnot availableの略だったのね…

なんにせよこれでMemUnitBusyやMemUnitStalledが高いのも、VALUBusyが
低いのも説明がつきます。これってCUDAのときみたいにS-Boxを書き換えたら
なんとかなるのかしらん。

S-Boxとおぼしき場所に倫理演算の命令に混じってbuffer_store_dwordと
s_buffer_load_dwordx4という命令が大量にあったので、
たぶんこれが速度が出ない原因なんでしょう。
ちょっとすっきりしたけど、これってコンパイラのレジスタの割付が
全然うまく行っていないということですよね。やれやれです。

倫理演算じゃなくて論理演算でした。

S-Boxの数を変えてISAファイルを調べてみたら、コンパイラがレジスタを
きちんと再利用していないことが判明。

S-Boxes: 1
Kernel occupancy: 10
NumVgprs = 180;
ScratchSize = 0;

S-Boxes: 7
Kernel occupancy: 10
NumVgprs = 239;
ScratchSize = 0;

S-Boxes: 8
Kernel occupancy: 20
NumVgprs = 105;
ScratchSize = 140;

register spillsが起きるとメモリアクセスが枷になって遅くなるし、
起きなければoccupancyが半分になるしでなかなかうまく行きません。
Bitslice DESに必要なレジスタの数は64 + 17 = 81ぐらいなので、
180〜245というのはいくらなんでも多すぎです。
CUDAだったら直接PTXのコードを書けばいいんだけど、OpenCLだと
そういうわけにもいかないので実に難しいです。使用するレジスタの数も
CUDAみたいにコンパイル時に指定できたらいいんですけどねえ。

駄目元でAMDのフォーラムに報告してみるとか

http://www.meriken2ch.com/programming/merikens-tripcode-finder
そんなにPC酷使したいならこれで12桁の酉でも探してろ

すまん間違えたｗちゃんと生贄連れてくるわ

よりによってこのスレに誤爆ｗｗｗ

Catalyst 12.11 Beta11が出たな

>>776
う〜ん、どうなんでしょうねえ。レジスタ割り付けを改善すれば
速度が上がるのは自明なので、特に報告するまでもない気もします。
実際12桁検索は倍近く速くなったので、今後に期待といったところです。

>>777-779
ぜひ活きのいいのをお願いしますｗ

>>780
かなり頻繁に更新してますね。現在ダウンロード中です。

>>287のPCIe用の延長ケーブルを使って、空冷用のスペースを
確保しつつ検索君1号にグラボを3枚積めることを確認しました。
見た目は最悪ｗですが、ちゃんと動いているので結果オーライです。
弾も色々揃えたので、帰省するまでに最高速の記録を更新できるかも
しれません。

>>784
6G級あるか!?

>>785
さあ、どうでしょうねえ… (￣ー￣)ﾆﾔﾘ

ターゲットが長くなるとヒットするまでの平均時間をいまいち正確に
出せなかった問題ですが、次のライブラリを使うことで解決できることが
わかりました。

Multiple Precision Integers and Rationals
http://www.mpir.org/

Visual C++だとlong doubleがdoubleと同じ精度なので困ってたのですが、
これなら全く問題ないでしょう。

MPIRのビルドはあっさり成功して、ちゃんとTripcode Finderに
リンクすることができました。サンプルで2の120乗を計算してみましたが、
ちゃんと正しい結果が出ています。このライブラリには分数計算のルーチンも
含まれているので、非常に正確に確率計算ができるはずです。わくわく…

おっと、間違えた。サンプルで計算したのは2の1920乗でした。
このライブラリ、logが計算出来ないから使うの結構面倒そうだな。
どうしたものか…

>>787-789
>ヒットするまでの平均時間をいまいち正確に出せなかった
そうだったのですか！？
ひょっとして有効桁数が2桁表示なのはそのせい……？

↓ところで、トリップ確率を計算するソフトを作っていたのですが、
http://up3.viploader.net/pc/src/vlpc012973.png
桁数が変わる「.」とかが入った時や準X連な時の正確な組み合わせ数を計算するのが難しいのデス……
どういった計算アルゴリズムで出しているのですか？大雑把でいいので教えて下さい！

>>790
基本的な流れは以下のとおりです。

(1) 正規表現のパターンを位置と固定長文字列の組み合わせに展開する。
(2) 各組み合わせごとの確率を計算する。
(3) (2)の確率の合計を求める。

注意しなければならないのは、各文字が特定の位置に出現する確率は
通常は1/64ですが、特殊文字の場合は違うということです。
例えば"."と"[:digit:]"がヒットする確率はそれぞれ64/64と10/64と
しておかなければ正確な結果が出ません。

具体的な例を挙げると、12桁トリップ検索における"^test./"の出現確率は

p = (1/64)*(1/64)*(1/64)*(1/64)*(64/64)*(1/64)

となります。

また、位置指定をしていない"/test[:digit:]/"の場合、出現位置が
0〜5の6通りなので、

p = (1/64)*(1/64)*(1/64)*(1/64)*(1/64)*(10/64)*(1/64)*6

になります。

MPIRの分数の型であるmpq_tを使って確率計算をすると、
遅くて使いものにならないことが判明orz
厳密にしすぎるのも考えものですね…
仕方ないので浮動小数点数の型のmpf_tを使うことにします。
任意の精度を指定できるのでこれで十分でしょう。

MPIRを使ってヒットまでの時間を予測するルーチンを書き直しましたが、
結局doubleを使った元のルーチンに比べて数パーセント精度が
向上しただけでした。元のルーチンもわりと正確だったということですが、
前からだいぶ気になっていた部分だったのでまあ良しとします。

>>790
あ、あと書き忘れてたけど、準x連の場合は該当する文字が出現する確率は
大文字と小文字をあわせて2/64になります。例えば"^[Aa]*$"のような
準12連が出現する確率は、

p = pow(2.0/64.0, 12)

となります。

>>791
>>基本的な流れ
これだと、あるパターンが複数行で当てはまる際重複して数えてしまうような……
「当てはまる全パターン」を正確に計算するのはカナリ厳しいことがよく分かりました
>位置と固定長文字列の組み合わせ
ほほう、なるほど。パーサを見直せば出来そうです
ただ、実際にトリップ検索スレに出てくる案件を見る限りでは、
「.」とか「*」とかとかを使う機会は無さそうですね……
>>794
あーいや、こちらが言うところの「準X連」とは、正規表現では「*[Aa][Aa][Aa]*」みたいなもののことです
(これが「純X連」になると、「*AAA*」となります)
もちろん「^[Aa][Aa][Aa]*」から「*[Aa][Aa][Aa]$」まで虱潰しに出して合計してみてもいいのですが、
そうすると「BGCAAAAAAfgt」みたいなものが重複ヒットしてしまうようで……
足し引きしてなんとかすることにします

確率計算での参考:
http://www.geocities.jp/trip_chaser/tripdata.html

>>795
> これだと、あるパターンが複数行で当てはまる際重複して数えてしまうような……

この問題はパターンを固定文字列に展開したあとで重複するものを
取り除くことでほとんどの場合回避できます。Tripcode Finderでは
qsort()とuniq()の組み合わせで対処しています。

> あーいや、こちらが言うところの「準X連」とは、正規表現では
> 「*[Aa][Aa][Aa]*」みたいなもののことです

正規表現では"*"は先頭に来ないのでいまいちよくわからないですが、
"^[^Aa]*[Aa][Aa][Aa][^Aa]*$"のことでしょうか。

> もちろん「^[Aa][Aa][Aa]*」から「*[Aa][Aa][Aa]$」まで虱潰しに出して合計してみてもいいのですが、
> そうすると「BGCAAAAAAfgt」みたいなものが重複ヒットしてしまうようで……

確かにそうなんですけど、実際には上の処理さえ施しておけば
重複ヒットは無視できる確率でしか発生しないので、Tripcode Finderでは
そこまで厳密に処理はしていません。あまり気にしなくてもいいんじゃないで
しょうかｗ

>>796
なるほど……固定文字列に展開する作戦ですか。勉強になります。
「トリップ検索人のための便利ツール」的なものを、頑張って完成させようと思います。それでは。

ご無沙汰しております。
電源が届いた後、色々試してみましたがどうも上手く行きません。
Quadro FX 3800, GTX480, GTX590をPCに挿してNVIDIAコンパネでQuadroだけCUDA offにして0.07a7 CUI64を[-c -g -x 128]で走らせると、下記エラーが発生して落ちます。

MERIKENsTripcodeFinderCUI: CUDA FUNCTION FALL FAILED: the launch timed out and was terminated (file 'C:/Users/Nullpo/Documents/Visual Studio 2010/Projects/MERIKENsTripcodeFinderCUI/Source Files/MTF_CUI_CUDA_SHA-1.cu', line 554)
MERIKENsTripcodeFinderCUI: CUDA FUNCTION FALL FAILED: all CUDA-capable devices are busy or unavailable (file 'C:/Users/Nullpo/Documents/Visual Studio 2010/Projects/MERIKENsTripcodeFinderCUI/Source Files/MTF_CUI_CUDA_SHA-1.cu', line 461)
MERIKENsTripcodeFinderCUI: CUDA FUNCTION FALL FAILED: all CUDA-capable devices are busy or unavailable (file 'C:/Users/Nullpo/Documents/Visual Studio 2010/Projects/MERIKENsTripcodeFinderCUI/Source Files/MTF_CUI_CUDA_SHA-1.cu', line 461)
MERIKENsTripcodeFinderCUI: CUDA FUNCTION FALL FAILED: all CUDA-capable devices are busy or unavailable (file 'C:/Users/Nullpo/Documents/Visual Studio 2010/Projects/MERIKENsTripcodeFinderCUI/Source Files/MTF_CUI_CUDA_SHA-1.cu', line 461)

Quadro+GTX590だと発生しません。三枚挿すと発生します。仕方が無いので、現在はGTX480+GTX590で運用しています。

とりあえず
ガッ!

>>798
　　||//　∧＿∧|∧＿∧
　　||/　r(　　　 (n´・ω・`n)　ぬるぽついてないのに「がっ」される
　　||　　ヽﾟﾎllﾇ）|（ 　 　 ）
　　 ￣￣￣￣￣　ｕ―ｕ'

line 554とline 461はそれぞれ

> CUDA_ERROR(cudaMemcpy(outputArray, CUDA_outputArray, sizeOutputArray * sizeof(GPUOutput), cudaMemcpyDeviceToHost));

と

> cudaError = cudaMalloc((void **)&CUDA_outputArray, sizeof(GPUOutput) * sizeOutputArray);
> ERROR0(cudaError == cudaErrorMemoryAllocation, ERROR_NO_MEMORY, "Not enough memory.");
> CUDA_ERROR(cudaError);

なので、両方共CUDA側のメモリの処理ですね。480と590のCCが2.0で、
Quadro FX 3800のCCが1.3なのでそれが原因かとも思ったのですが、
Quadro + GTX 590で発生しないみたいなのでそうでもないようですねえ。

エラーメッセージを見る限りではCUDAが無効担っているにもかかわらず
APIからQuadroが見えているようです。NVIDIAコンパネでQuadroの
CUDAをonにした場合はちゃんと動作しますか?

>>798
ユーザー名がぬるぽなのかガッ!と言いたいためにぬるぽにしたのか……

エラーメッセージでググる限りでは、
>the launch timed out and was terminated
「Primary Device(ディスプレイデバイス)に指定されているGPUで長時間カーネル関数を実行しすぎている」
(探したページではPrimary Deviceを切り替えて対処していたが、基本全部使うGPU検索ではどうか……)
>all CUDA-capable devices are busy or unavailable
「ゾンビプロセスがGPUを占有している」(1つ目のエラーのせいで発生したエラーってことか？)
「fork()する前にcudaThreadExit()すればいいんじゃね」(要するに処理のミス？)
「ドライバを少し古いものに戻してみるのはどうか」(GPUあるある)
てなかんじかな。

参考URL:
http://d.hatena.ne.jp/ang65/20100721
http://septieme-sens.blogspot.jp/2011/09/cuda_10.html
http://tsubame.gsic.titech.ac.jp/node/610
https://devtalk.nvidia.com/default/topic/479529/cuda-programming-and-performance/all-cuda-capable-devices-are-busy-or-unavailable-problem-in-a-multi-process-linux-application/#entry1140557

>>800
ユーザー名がもともとNullpoなのですｗ
本名にしておかなくてよかった…

普通はlaunch time outはカーネルの処理時間が長すぎて発生する
エラーなんですけど、このケースではCUDAが無効になっているはずの
Quadroに対して検索スレッドが実行されているようなので、ドライバーの
バグ臭いです。Quadroが無効になっていて480と590だけで検索が実行されて
いるなら、エラーの数(=検索スレッドの数)は3個のはずなので…
時間ができたらこちらで再現できないか試してみます。

>>800
もうちょっと調べてみたら、特定のGPUでCUDAが無効になっている場合、
cudaDeviceProp::computeModeをいちいちチェックして
そのGPUが有効かどうか確認しなければいけないことがわかりましたorz

http://stackoverflow.com/questions/8784572/how-to-choose-device-when-running-a-cuda-executable
http://www.clear.rice.edu/comp422/resources/cuda/html/group__CUDART__DEVICE_g5aa4f47938af8276f08074d09b7d520c.html

直すのにちょっと時間がかかりますが、作業が終わったらここで報告するので
しばらくお待ちください。

>>801
別に恨みはないが言わせてもらおう……
　　 （　・∀・）　　　|　|　ｶﾞｯ
　　と　　　　）　 　 |　|
　　　 Ｙ　/ノ　　　 人
　　　　 /　）　 　 < 　>__Λ∩
　　 ＿/し'　／／. Ｖ｀Д´）/ ←>>801
　　（＿フ彡　　　　　 　　/


話は飛びますが、検索していると、トリップキーの発見予定時間が
「it takes 2.3 days」などと表示されますよね？
あれが単純に、「出現確率の逆数÷検索速度」だとした場合、
検索し始めて表示時間だけ待ってトリップキーが出現する確率は

せ　い　ぜ　 い　6　3　%　ぐ　ら　い　し　か　な　い

ことを最近発見しました。要するに、「1/XのくじをN回引く間に1回でも当たる確率」ということですが。
この確率は、Nが極端に大きいと二項展開やテイラー展開で近似することができ、それによると
確率E=1-EXP(-N/X)。1/Xを「出現確率」、Nを「検索速度(毎秒)×時間(秒)」とすれば、
上記の値が出るということです。しかもこの値は比で考えることができるため、
「予想時間までに出てくる確率は63.2%」
「予想時間の半分の時間で出てくる確率は39.3%」
「予想時間の倍掛けて出る確率は86.5%」
などといったことが分かります。分かりやすくグラフにしてみました。
http://up3.viploader.net/pc/src/vlpc012980.png
……いや別になんとなく思いついただけなのですが(震え声)

>>803
表示されているのはあくまでも「平均の」待ち時間なので、
「検索し始めて表示時間だけ待ってトリップキーが出現する確率」は
50%になるように調整されています。

> 単純に、「出現確率の逆数÷検索速度」だとした場合

これだと上の確率がちゃんと50%にならないので次のように計算しています。
pをパターンの出現確率とすると、n回のトリップの生成で
パターンが出現*しない*確率q_nは、

q_n = (1 - p)^n

になります。これから50%の確率でパターンが出現するのに必要な
トリップ生成の回数n'は、

0.5 ≒ (1 - p) ^ n' ⇔ n' = ceiling(ln(0.5)/ln(1 - p))

となります。これから発見予定時間sは、次の式で求められます。

s = n' / [平均速度(TPS)]

この計算はMTF_CUI_Patterns.cpp内のLoadTargetPatterns()の
後半で行われています。詳しくはソースを参照してくださいと言いたい
ところですが、公開されているソースのこの計算の部分は非常にわかり
にくいですｗ MPIRを使って書きなおしたので次のバージョンでは
前よりわかりやすくなったはずですが、大して変わらないかもしれません。

>>800
580+590の組み合わせでは問題は再現できませんでした。
バージョン306.97のディスプレイドライバで
NVIDIA Control Panelで580でCUDAを使用しないように設定してやると、
ちゃんとCUDAのAPIからは580は隠蔽されるようになっていました。
というわけで、この問題はディスプレイドライバのバグである可能性が高いです。
一応cudaDeviceProp::computeModeをチェックする処理を追加しておいたので、
次の開発版を試してみて下さい。

>>804
それぐらい折込済み、だと……!? 　おみそれいたしました。
でも、その場合でも、q_nは、「発見予定時間だけ経つと0.5である」「発見予定時間のX倍経つと0.5のX乗になる」
ことから、発見確率の予測はそれほど難しくないようです(X=2だと発見確率が75%、X=0.5だと29.3%ほど)。
当該ソースは「// Calculate the matching probability etc.」あたりでしょうか。一度読んでみます。

というわけでバージョン0.07のβ版を用意しました。

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

主な変更点はヒットまでの待ち時間の予測の改善と>>798で報告された
問題への対処です。

>>806
たしかにその場所ですけど、n'を計算する部分を書いたときには
うごかすことしか考えていなかったので本当に分かりにくいですよｗ

>>807
対応して頂きありがとうございます。これから試してみます。
そもそもGeForceとQuadroではドライバが別パッケージになっているので、同時差しでバグが発生する可能性は大きそうですね。
Quadro使うやつはTesla使えってことか・・・。ついていけねぇ。

12桁トリップ検索のRadeonへの対応の作業もほぼ終了したので、
最高速を測定してみました。オクでお安く手に入れた中古の6990を2枚使って
速度を稼いでいます。真ん中の7970は延長ケーブルでマザボにつなげて
2枚の6990の上に乗っけています。温度の心配はしなくても良くなったので
ギリギリまでOCしています。動くかどうか半信半疑だったのですが
なんとかなるもんですねｗ

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

6990×2に5870付けて待て屋やったときは1500W超えたな（ワットチェッカー上限超えたｗ
そんときはCPUも使ってたけど同等に電気食ってそうだｗｗ

>>810
ぐおおおおお！
CPUが空気ｗｗｗｗｗ

最速記録の塗り替えか

6990って水冷にすれば1スロット化出来るよな
でPCIex16スロット7本有るマザー結構な数有るよな
7枚刺したらいいんじゃないかな〜

>>811
CPUには負荷はほとんどかかっていないのでそこまではいってないはずです。
恐らく検索君1号だけで1100〜1200Wぐらいです。

>>812
ここまでGPUが速いとCPU検索を同時実行すると却って速度が落ちるのです。

>>813
前スレを立てたときにくらべて10倍以上の速度が出せたので満足ですｗ

>>814
お金があればもっと色々試したいんですけど、自分はさすがにもう限界ですねえ。
勇者の登場を待ちましょうｗ

あ、そうそう。Beta 1に問題がなければ今週の金曜日ぐらいに
バージョン0.07の正式版をうｐする予定なので、
不具合があればそれまでに報告していただけると有難いです。

　　|￣￣￣￣￣￣￣|
　　|　 速くなったな 　 |
　　|　　 　　|
　　| 　　 |　 　,. . _
　　|＿＿＿＿＿＿＿| --' 、　 ￣￣ヽー- ､
　　　　　　　| |　 ヽ￣7　, ,　＼　 、　　 「￣ 7
　　　　　　　| |　　ヽ / /_ /ハ　|ヽ、＼　V ./
　　　　　　　| |　　　 i　il/　　 ヽl　　＼ヽ. V
　　　　　　,. -{-､ __ .| ii i!　 ｏ　　 ｏ　 | il　|
　　　　 　 { 　 Y/　　l il |､　　 Д　　　| li　|
　　　　　　`t-く　　　ヽN　` 　---　＜ﾘiレ'
　　　　　　　| |　`ー-- ､　 / II - ２ ヽ　 ｀丶、
　　　　　　　| |　　　　　 ￣ !.ギ 子_ﾉ >-'　　 !
　　　　　　　| |　　　 　 　 ,r`''ｰ─''｡r'^ヽ､_,／- 、
　　　　　　　| |　　　　　 /　｀ヽ、　, '~~｀V-─ ､　）
　　　　　　　| |　　　　 /　　　／´｀､　　　!　　(_ノ
　　　　　　　i_j.　　　 / 　 .／　　　 ﾞ､　　 !
　　　　　　　　　 　 /＿／　　　　　　ﾞ､　　!
　　　　　　　　　　:::`ー':::::::::::::::::::::::::::::ヽこﾉ:::

スレ発見しましたー。
MERIKENさんなら./の10完12桁出そうな予感！

酉ありがとうございます(ﾉ^^)ﾉ

>>816
WinXP 32bit、GPUなしでver0.07 beta1の.exeを起動させると、「OpenCL.dllが見つかりませんでした…。」と出て起動できない（検索出来ない）。
ver0.06の安定版では起動させることが出来る

>>807
対応ありがとうございます。
最初にQuadro, 480, 590を繋げて"CUI64 -c -g"で実行。エラーも出ずに実行されました。自動ブロック数設定は相変わらず安定しませんが・・・
次にNVIDIAコンパネでQuadroだけCUDA offにして"CUI64 -c -g -x 192"で実行。下記エラーが出るも、検索自体は実行されます。
MERIKENsTripcodeFinderCUI: CUDA FUNCTION FALL FAILED: unknown error (file 'C:/Users/Nullpo/Documents/Visual Studio 2010/Projects/MERIKENsTripcodeFinderCUI/Source Files/MTF_CUI_CUDA_SHA-1.cu', line 560)

画面の表示はこんな感じです。
CUDA0: (Quadro?)
CUDA1: 560.5M TPS, 192 blocks/SM (480)
CUDA2: 518.7M TPS, 192 blocks/SM (590)
CUDA3: 518.6M TPS, 192 blocks/SM (590)

^Cで強制終了させて、もう一度実行させると、例のエラーが三行出てCPUでのみ検索が実行されます。
挙動が良く分からない・・・

OpenGL用にQuadroを残しておきたいけど、熱的にやばそうなので480と590だけで運用することにします。

>>819
GPUでOpenCLかCUDA扱えないと使いづらいってのが俺の中でのこのソフトの認識
CPUだけなら待て屋とかSHArpとかがあるし(探索空間が違うから一緒にしてはいけない気もするが)

>>819
報告ありがとうございます。こちらでも確認できました。
取りあえずOpenCLを添付することで対処したいと思います。

>>821
実際Tripcode FinderのCPU検索は待て屋やSHArp Tripperほど速度は出ないですからねえ。
GPUが使用出来ないと警告が毎回出るのはさすがにやりすぎなのでこれは直しておきます。

>>818
有難うございます。正規表現でいろいろパターンを指定できるので、
結構遊べますよw

>>820
やっぱりドライバのバグみたいですねえ。
今度試す機会があったら"CUDA DEVICES"の"Compute Mode"の値を
調べてみて下さい。問題を回避できるかもしれません。

なんかやってます

WindowsのパスワードはGPUを25個使えば約6分から6時間で突破が可能、
毎秒3500億通りもの総当たりが可能な方法とは？
http://gigazine.net/news/20121211-gpu-brute-force-attack/

>>819
ついさっき修正が完了しました。次の安定版では直っているはずです。

>>826
これ5台のラックマウントサーバーですよね。グラボが25枚だそうですけど、
サーバーによって構成が違うみたいです。8枚載っているサーバーの
写真があるので、8枚+5枚+4枚*3という構成でしょうか。他のサーバーの
GPUを仮想化してHashcatで利用しているのは非常に興味深いです。
いつか自分でもこんな豪勢なクラスターを組み立ててみたいですねえ。

>>828
やろうと思えば、個人レベルでも出来てしまう辺りがおもしろいですね

古いPCが沢山あるのでネットワーク対応型MTFを待ってます

>>826の記事のグラボが8枚載ったラックマウントサーバーはどうやら
これのようです。

http://www.advancedhpc.com/gpu_computing/B7015F72V2.html

しかしこうやってみると壮観ですねえ。

http://gigazine.jp/img/2012/12/11/gpu-brute-force-attack/snap0787.jpg

はりにきたらすでにはられてたか>>826

>>821
常用しているのはうにだけど、
このソフトはCPUのみでも動くようになっているから、動かないのは問題かなと思って報告した。
>>827
早い対応ありがとうございます。
OpenCL.dllをいれようと思ったものの、検索してもよく分からなかったもので……。

>>828
控えめに一枚500M/sだとしても×25で12.5G/sか・・・
8完が(ln(0.5)/ln(1-1/64^8))/(12.5*10^9)≒4.3時間で出てくる計算に

>>830
とりあえず10桁トリップ検索とコードの整理をするのが先ですけど、
ネットワーク対応はいずれぜひやりたいですねえ。

>>834
研究発表のスライドにはSHA-1で63G hashes/sでているとありましたよ。

http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf

これはパスワード解析での数字なので、トリップ検索ならもうちょっと
速くなるでしょう。なかなか豪気ですねえｗ

>>830
ネットワーク対応の暁には学校のPCルーム総動員で検索させてみたいな・・・
いやGPU買えよと言われそうだが

>>836
>トリップ検索ならもうちょっと速くなるでしょう
要するに単にハッシュ出して比較、だけじゃない最適化が掛かっているのか……
8完が1時間切るとかどんなモンスターだｗｗ

>>825
Compute Modeは全てcudaComputeModeDefaultでした。
違うのはCompute Capabilityだけで、Quadroは1.3、他は2.0です。
他の手を考えてみます。

>>839
そうですか。それは残念… 将来的には各GPUを使用するかしないかを個別に
設定できるようにする予定なのでいずれ解決できるかもしれませんが、
今の段階では難しいですねえ。

>>343のteslaがGTX5シリーズに負けてるのが印象的です
fermiコアの解析速度はプロセッサクロック×メモリバンド幅ですかね？

うちの560tiが580の報告の半分の速度しか出ないもので

>>841
メモリバンド幅は関係ないです。
580と560tiはそれぞれGF110とGF114なので単純には比較できないですけど
半分だとちょっと遅すぎるような気がしますね。ちゃんとCC 2.1用のバイナリは
入ってるはずだけど…

GF114はSMあたりのコア数はGF110の32コアから48コアに増えていますが、
レジスタ数は増えていなくて、GF110は16SMでGF114は8SMなので
GF114ではレジスタがボトルネックになりがちだったと思います。

とはいえSMあたりのコア数が増えている分少しは向上しているようでしたし、
リファレンスではクロックもGTX560Tiの方が上なので、半分となると遅すぎる気もしますが、
OCされたGTX580との比較でしょうか？

【GPU】Geforce GTX560ti ×2
【CPU】core i5 3470
【OS】Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07 Beta 1
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】192
【その他のオプション】-g -x 128
【Display Driver】306.97
【10分間の平均速度】 762.15Mtripcodes/s
【GPUの使用率】99％
【GPUの温度】71〜80℃
【その他】 CUDA0,1:約381M TPS

さっき測ったら定格の580が683M TPSぐらいなので560tiの速度は
55%ぐらいですか。CUDA GPU Occupancy Calculatorで調べてみても
特にCC 2.1でOccupancyが下がるということもなかったので、ちょっと
原因がよくわからないですねえ。

GF114はGPGPUには向いてないのですかねー。
現在最速はやはりGF110かな？

つttp://dokumaru.wordpress.com/tag/gf110/

55%ですか・・・もう少し出てもよさそうな気もしますが、おかしいというほどではないかと思います。

単精度や32ビット整数の演算性能自体は、GTX560Tiはコア数とクロック的にGTX580の80%近くありますが、
それはピーク性能であって、SHA-1ハッシュの演算ではレジスタがそれなりに必要になります。

SM数とクロック的にはGTX560TiはGTX580の53%程度であり、
それぞれのSMの違いはコア数（と倍精度や特殊関数など）でレジスタ数に変化は無いので
レジスタがネックでコアを使いきれていないのだと思います。

GF114はグラフィックよりではあると思いますが、GPGPUでもレジスタを大量に使うものばかりではないでしょうし
消費電力や値段を考えると、GPGPUにはベストではないけどそれなりにではないでしょうかね。

GK104はGPGPUにはピーキー過ぎてお勧めしませんけど・・・

GK110買えそう
楽しみ

>>848
なるほどなるほど… CUDA Toolkit 5.0に添付されているOccupancy Calculatorでは
このあたりの事情が反映されていないようです。カーネルのレジスタ数は46〜48で
Occupancyは42%なのでレジスタ数が特に多いというわけではないのですが、
これがボトルネックになっているのは確実ですね。

>>849
Tesla K20ですか? いいな〜 買えたら是非報告をお願いします。

>>838
パスワード解析に比べてトリップ検索ではキーの生成が比較的単純なので、
それをうまく利用してやれば速度は1〜2割上がる傾向があります。
GPUクラスタの場合はノード間通信がボトルネックにならないので
更に速くなるものと思われます。しかしもう12桁トリップだと9完以上でないと
危ないですねえ。

>>852
いやいやいや
あくまでも12桁ですから、キーを割られる危険という意味では何完であろうと関係はないです
我々のような好き者にとっては問題なんですが

>>853
> あくまでも12桁ですから、キーを割られる危険という意味では何完であろうと関係はないです

あ、「危険」と書いたのはそういう意味じゃないです。
トリップの場合はある程度一致すればなりすましができるので
キーが割られなくても十分危ないんですよね。トリップが一致しているか
どうかを判断しているのは一般のユーザーで、普通の人はわざわざ
12桁目まで細かく確認しているわけではありません。ここらへんは普通の
パスワードとはぜんぜん違うところです。

今唐突に12桁トリップのCPU検索を高速化するアイディアを思いついたん
ですけど、1月の中旬まで帰省しているので実装はそれまでおあずけです。
残念…

なんでMTFのCPU検索がSHArp Tripperやhip2に比べて遅かったのか
不思議で仕方がなかったんですけど、よく考えたら普通のSHA-1の
ルーチンを使いまわしてたせいで、SSE2のレジスタをトリップ検索に
特化した形で効率的に使用していなかっただけでしたｗ
1個のハッシュの生成を高速化するより、SSE2の128bitレジスタを使って
4個同時に生成したほうが速いに決まってますよねえ。

あと、よく考えたらキーの動的生成とBitslice DESのルーチンの動的書き換え
( >>712-713 )で10桁トリップのCPU検索も高速化できることに気づきました。
なんで時間のないときに限って面白い考えを思いつくんだろうorz

>>855
えっ！？
SIMD ってなかったの！(SIMD るってなんだよ。ｗ
まさか、Radeon でもやってないとか・・・・・。

ソースを読んでみる気は無い。ｗｗｗ

あとまあ Hashcat 知ってるんなら知ってるかもしれんが。
ttps://hashcat.net/p12/js-sha1exp_169.pdf

もうこれはMERIKENさんにメチャクチャ頑張ってもらうしかない展開

>>857
SSE2を使ってるルーチンを拾ってきたんですけど、
ベクター化されてないのであんまり速度が出てなかったみたいです。
RadeonのほうはCUDA版のベタ移植なのでそれこそなにもしていませんｗ
OpenCLドライバが頑張ってるのでせう。Southern Islandsだとベクトル化しても
あんまり意味ないみたいですし… 資料のほうはあとでありがたく読ませて頂きます。
これでさらなる高速化が出来るかもしれないですね。ぐへへへへ…

>>858
明日の朝の飛行機の便に間に合わせるのに徹夜で荷物をつめはじめたところなので
さすがに帰省前は無理ですｗ 来月を楽しみにしていて下さい。
家を出る前に0.07の安定版はうｐしておきます。

>>806です。
検索作業をサポートするソフトをリリースしてみます(実験版だけど)。
依頼を検索パターンに変換したり、特定パターンを自動生成したりできます。
良かったらどうぞ。
http://www1.axfc.net/uploader/so/2713626.zip

レジューム機能がほしいです

>>862
なんで検索空間＞＞酉空間なのにみんなレジューム機能が欲しくなるんだろうな……いや俺も思ってたことあったけど
自動実行と自動保存はAlpha 7で既に実装されてるから除くとして

Radeon HD8000シリーズ楽しみすぎる

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

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

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

・OpenCLドライバがインストールされていないと起動できないバグの修正。

飛行機の時間ギリギリなってしまったのでレスはまた明日させて頂きます。
それではまた〜

>>861の更新版、「検索人の友 Ver.0.6」のお知らせ。
待て屋・SHArp・MERIKENの検索パターンを相互変換することができます。
(リンクはhttp://ikura.2ch.net/test/read.cgi/qa/1321792877/667に貼りました)

「検索人の友 Ver.0.8」のお知らせ。検索パターンと検索速度から、出現予定時間を算出する機能を追加。
(リンク:http://ikura.2ch.net/test/read.cgi/qa/1348736616/317に記載)

SHA256ハッシュを取ると全てのビットが0になるキーが知りたい

>>862
レジューム機能は原理的に無理ですけど、
累計を保存する機能は近いうちにつけておきます。

>>868
依頼変換は便利そうですね。スレから依頼を直接引っ張ってきたり、
「大小区別指定」をチェックボックスにして条件を複数同時に指定できると
もっと便利かもしれません。帰省中で今は検索用のPCが使えない状態なので、
来月の中旬頃にはもっと詳しいことが書けると思います。

>>871
依頼引張り→依頼者が「正しい」形式で依頼してくるかが未知数という問題が・・・
全部まとめたシステム的なものはムズカシイけど、コピペから自動認識程度なら検討可
チェックボックス→次のバージョン(Ver.2.0)で対応予定。

Ver.1.0に更新のお知らせ:
http://ikura.2ch.net/test/read.cgi/qa/1348736616/320

>>869
なんでSHA256？
2chの12桁はSHA1だと思ったが……


仮に2chのトリップがSHA256に対応したとして、BASE64で000000はAなのでAのx完のトリップになると思う

おつかれさまです
現行では10酉探索にはradeonが使えないってことですが
いつか改善される予定ってありますか？

>>874
一応7xxxシリーズ限定で使えるものがほとんど出来上がっているんですけど、
速度に満足できないので公開を見合わせている状況です。
今考えているのはAMD ILをいじってレジスタ数の割付を最適化することです。
またまとまった時間が取れるようになったら色々試してみる予定なのでしばらく
お待ちください。

自作ソフトウェアの更新のお知らせ。ぜひお試しを。

[検索人の友 Ver.2.0]
　このソフトは、以下のような作業を自動化します。
・検索依頼の各種形式への変換
　→依頼スレでのテンプレに準拠。各種形式に変換して表示できます。
　　今回は大小指定の複数指定に対応。全大と全小を同時表示、なんてこともできます。
・特定パターンの検索ワードの自動生成
　→「純・準Ｘ連」「全数」「二構」「飛石」「最長」「最短」といったパターンの検索
　　ワードを自動的に作成します。10桁(待て屋)、12桁(MERIKEN)両方に対応。
・各種トリップ検索ワードの相互変換
　→「まあ、待て屋。」「SHArp Tripper」「MERIKEN's Tripcode Finder」の 3種類の検
　　索ソフトの検索ワードを互いに変換します。今回は「*」「+」といったパターンや、
　　「(|)」にて|が二つ以上の場合にも対応。
・任意の検索ワードに対する出現確率を計算
　→上記 3種類の検索ソフトでの検索ワードと検索速度を入力すると、発見予定時間を有
　　効数字4桁で表示します。発見予想順位を表示する機能も。
・トリップテスト
　→10・12桁トリップをテストできます。生キー対応。

URL:http://www1.axfc.net/uploader/so/2732376.zip

参考画面キャプ:
http://blog-imgs-52.fc2.com/y/s/r/ysrken/tf2nd.png

俺はHD5750なので、7xxx限定だと寂しい。

そんなグラボ使ってもゴミみたいな速度だからさっさと7990買った方がいい

CPU単体より速いし。

ハイエンドグラボだと暖房つけなくていいし。

>>876
お疲れ様です。チェックボックスに対応して下さったんですね。
ありがとうございます。

>>878
自分も5770を持ってるので対応したいのはやまやまなんですけど、
性能を出そうと思ったら最適化を1からやりなおして相当頑張らないと
だめでしょうね〜 OpenCLじゃなくてAMD ILで書かないとうまくいかないと思います。
方法がないこともないみたいなんですけど、コードはGPU依存みたいだし
実際どうなんでしょうねえ。

AMD IL
http://openwall.info/wiki/john/development/AMD-IL

いや性能を出す必要はなく、動作すればいいのですよ。
CPUと併用すれば、単体より絶対速くなるしね。
勿論、速い方がいいけど、所詮5750だし。
パフォーマンスアップは、ソフトじゃなく
ハードでやるべき。

>>882
MERIKENさんが帰ってきた、だと・・・！？
>>884
同意
パフォーマンスに拘るのはCOOLだと思うけど、
ちゃんと動くものがあればあるだけ欲しいと思う層もいるのですよ

>>884
7970用のルーチンも一応5770でも動きますけど、CPUよりずっと遅いですよ。
GPGPUの最適化は難しいのです。

>>885
その「ちゃんと動」かすのが10桁トリップ検索の場合結構大変なんですよ。
ソフトウェアの最適化なしだったらGPUでもせいぜい2〜3M TPSといったところで、
ここから数十M TPSまで持って行くにはGPUのアーキテクチャに合わせてかなり
いろいろ工夫しないといけないのです。

>>887
>2〜3MTPS
そうなのか・・・勉強になります
私の自作ツールの場合スクリプト言語で書かれたものですので
最適化とか心配しなきゃならないものでもありませんゆえ

Ver.2.0では正規表現の再現度を上げるのが大変だた・・・よく「*」「+」の展開法思いついたなあの時の俺

正規表現は結構めんどくさいですよね。
あと、ご自分のツールのお話は新しくスレを立ててそちらでされてはいかがでしょうか。

追い出されててﾜﾛﾀw

待て屋スレ過疎ってるからそっちでいいんじゃね

コレって
先頭から1234・・・・・・・みたいな場合はどうすればいいの？

どうするじゃない、ちゃんと詳しく書け。
子供かお前は、人に伝える努力をしろ

◆1234********
みたいなトリップがほしいのですが
正規表現だけだと
◆**1234********
とかになってしまうので
希望の文字を先頭に持ってくる方法を教えて下さい

^ググれよhttp://www.mnet.ne.jp/~nakama/regexp2.html

>>892
このソフトの文法から言えば、
----------
#regex
^1234
----------
か、
----------
#noregex
1234
----------
でいい

>>895−896
ありがとうございます

HD7750 だとどのくらい出てるんでしょうか。

>>898
7750での報告はなかったはずです。コア数が7970の1/4なので、
クロック周波数の差を考え合わせると12桁トリップ検索で450M TPSぐらい
じゃないでしょうか。

>>899
今使ってる HD6670 だと 267M くらいなので 1.6倍かー

時間ができたので>>857の資料を読んでみました。MTFではトリップのキーの
長さは12桁に決め打ちしてしまっているのでかなりの速度向上が期待できそう
です。資料では最適化の結果命令数が21%減ったとのことでしたが、もう
ちょっと減らせるかもしれません。

それにしても、やっぱりソフトウェアの最適化についてあれこれ考えるのは
面白いですねえ。工夫一つで性能が数割から数倍に向上するのが
GPGPUの醍醐味ですしね。

>工夫一つで
プログラミングの腕って結局そこに結実するんでしょうな……
上手くSIMDやGPGPUが決まった時の快感は異常

>>902
ですよね〜 GPGPUにはなんとも言えない緊張感があります。

>>857の資料の内容は大体理解できました。要はSHA-1のブロックの最初の
ワード以外を決め打ちにして計算の手間を省こうという話で、トリップ検索に
そのまま応用できることがわかりました。PW[]を定数の配列にして
CPU側であらかじめ計算してからカーネルに渡せばいいはずです。
これはかなり楽して速度が稼げる美味しい話みたいです。

>>839
「QuadroにGeForceが合わないなら、Teslaを使えばいいじゃない。」

【GPU】Tesla K20c
【CPU】[email protected] x2
【OS】Win7Pro64SP1
【Ver】0.07
【Len】12
【BLK/SM】256
【Opt】-c -g -x 256
【Drv】310.70
【15minAv】777.25 MTPS
【GPU Av】705.03 MTPS
【CPU Av】72.22 MTPS
【GPU Ld】-
【GPU Tmp】-
【Oth】HT off, QuadroはCUDA off

今回はエラーも出ずに正常に動きました。
K20cはCPU負荷がGeForce5xxに比べて大きく、1枚でX5680の1コアを使い切る位です。
Open Hardware MonitorもGPU-ZもK20cにはまだ対応してないので、GPUの負荷や温度は分かりません。
整数演算はこんなものですかね。もう少し頑張って欲しかった。(´・ω・｀)

IDにgpu

>>905-906
報告ありがとうございます。Tesla K20cにしてはちょっと遅いですねえ。
CC 3.5用のバイナリを実行ファイルに埋め込めば速くなるのかもしれませんが、
Toolkit 5.0を使うと他のカードでの速度が露骨に遅くなってしまうのが
悩みの種です。NVIDIAのカードでもOpenCL版を使えるように出来ないか
検討してみます。

てすと

>>909
(´；ω；`)ｳｯ…

ようやくアメリカに戻ってきたのでMTFの作業に
また取り掛かれます。いろいろ速度改善について美味しいネタを
手に入れたので、次のバージョンでは12桁トリップ検索の
速度改善を中心にしつつ、これまで出来なかった累計の表示や
前方一致と後方一致のパターンを混在させると速度が低下する問題に
取り組んでいきたいと考えています。

>>908
もしかしてCPUがボトルネックになっているのかと思い、GPUのみで実行してみましたが変わらず。
貼り忘れていたのを追加。

Device Name: Tesla K20c
Multiprocessor Count: 13
Clock Rate: 706MHz
Compute Capability: 3.5
Compute Mode: cudaComputeModeDefault

希望する機能は、GPU毎にオプション設定できることですかね。
うちみたいに余り物を寄せ集めて動かしていると辛いです。(ちなみにTeslaは借り物です。)
でもCUDAとOpenCL混在とかなると、UIが大変なことになりそう。

>>912
リストボックス+コンボボックス……アカン、GUIとコマンドラインオプションがエライことになる
だけどどうせCPUが余ってるなら制御用に数スレッド回しても大丈夫……なのかな？

>>912-913
GPU毎のオプション設定は前々から欲しいと思っていた機能なんですけど、
コマンドラインの設定はともかくGUIのほうがかなり面倒くさそうで先延ばしに
なっていたんですよね。12桁トリップ検索の高速化が一段落したら
また考えてみたいと思います。

とりあえず12桁トリップのCPU検索の高速化( >>855 )から手を付けることに
しました。これと>>857のネタを組み合わせれば上手く行けば速度は3〜4倍に
なるはずです。ぐへへへへ…

というわけでつらつらとソースを眺めてたんですけど、一番単純なCUDA用の
実装をSSE2 Intrinsicsで書き直すことにしました。Intrinsicsの使い方さえ
間違えなければ特に問題はないでしょう。

ちなみに現在のCPU検索の速度はこんな感じです。
ちゃんとSIMD化していない割にはかなり頑張ってるのですが、
それでもSHArp Tripperに比べるとかなり見劣りします。
最低でも倍の速度は出したいところです。

【GPU】N/A
【CPU】Intel Core i7-3770K @ 4.3GHz (OC)
【OS】 Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.07
【トリップの種類】12桁
【1SMあたりのブロックの数(CUDA)】N/A
【1CUあたりのワークアイテムの数(OpenCL)】N/A
【1WGあたりのワークアイテムの数(OpenCL)】N/A
【1GPUあたりの検索プロセスの数(OpenCL)】N/A
【1検索プロセスあたりの検索スレッドの数(OpenCL)】N/A
【CPU検索スレッドの数】自動(8)
【その他のオプション】
【Display Driver】Catalyst 12.11 Beta8
【10分間の平均速度】41.74M tripcodes/s
【GPUの平均速度】N/A
【CPUの平均速度】41.74M tripcodes/s
【GPUの使用率】N/A
【GPUの温度】N/A
【その他】CPUのみ。5完1タゲ。

>>916
その環境ででSHArp走らせたらどんなもんなん？
今の俺のようにSHArpをCPU担当にしている人って結構いそうだから期待

>>917
SHArp Tripperは同じ条件で65.73M TPSでした。
どれぐらいMTFの速度が上がるか楽しみですねえ。

とりあえずCUDAのルーチンをunsigned intを使ってCPUに移植してみました。
速度もあまり遅くならなかったので、いままでのSSEの使い方はかなり
まずかったことになりますorz あとはこれを__m128iで書きなおしてやれば、
SIMD化の効果が正確にわかることになります。わくわく…

移植したルーチンをそのまま__m128iで書き換えたのですが、
なんと25M TPS出ています。トリップの計算もちゃんと行われているようです。
実際にはこれの4倍の速度が出るはずなので、CPU単体で100M TPS超が出来る
可能性が高まって来ました。これは美味しすぎるｗ

オラなんだかワクワクしてきたぞ

取りあえずやっつけでトリップを4個同時に生成するルーチンをでっち上げたら
90M TPS超が来たけど、ちゃんと動いてるのかな、これ?
しばらく動かして様子を見てみようっと。

生成されたトリップは問題なく使えるみたいです。
あとはヒット率と無効なトリップの割合だけど、おおむね予測通りといったところです。
これはひょっとしたらSHArp Tripperどころかhip2にも追いついたかもしれません。

＊　 　　　+　　 　　巛 ヽ
　　　　　　　　　　　　〒　!　　　+　　　　。　　　　　+　　　　。　　　　　＊　 　　　。
　 　　　　+　　　　。　 | 　|
　　　＊　 　　　+　　 /　/　　　イヤッッホォォォオオォオウ！
　　　　　　 ∧＿∧ /　/
　　　　　　（´∀｀　/　/　+　　　　。　　　　　+　　　　。　　　＊　 　　　。
　　　　　　,-　　　　　ｆ
　　　　　 / ｭﾍ　　　　| ＊　 　　　+　　　　。　　　　　+　　　。　+
　　　　　〈＿｝ ）　　　|
　　　　　　　 /　　　　! +　　　　。　　　　　+　　　　+　　　　　＊
　　　　　　 ./　　,ﾍ　 |
　ｶﾞﾀﾝ　||| j　　/　|　 | |||
――――――――――――

やっぱこれ、hip2よりも微妙に速いですね。2M TPSぐらいですけど…
速度が25M TPSの4倍に綺麗にスケールしなかったのは謎ですが、まあいいでしょうｗ
どうせまた>>857のネタのために大幅に検索ルーチンをいじることになるので、
最適化は程々にして、とりあえずちょっとだけテストしてからこのバージョンを
新しいα版として公開することにします。

というわけで新しい開発版を用意しました。

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

主な変更点は12桁トリップのCPU検索の大幅な高速化です。

新しいバージョンでもう一度速度を測定してみました。
0.07と比べると2.3倍の速度向上となりました。美味し過ぎです。
CPUが熱でスロットルダウンしていた問題を解決したので
最初に測った時よりさらに速くなっています。
同じ条件でSHArp Tripper 1.1は71M TPS、hip2は6完1タゲで87M TPSほどなので、
まあ大成功といっていいでしょうｗ

【CPU】Intel Core i7-3770K @ 4.3GHz (OC)
【OS】 Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 1
【トリップの種類】12桁
【CPU検索スレッドの数】自動(8)
【その他のオプション】なし
【10分間の平均速度】96.54M tripcodes/s
【GPUの平均速度】N/A
【CPUの平均速度】96.54M tripcodes/s
【その他】CPUのみ。5完1タゲ。

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

Intel HD Graphicsが使えない分を補なえるこの速度向上……ありがてぇ！

>>926
試しにDLしてみました
検索が早いっすねー　育成されたトリップ数が桁違いだ

ｗｗｗｗｗｗｗｗｗGPUが85度ｗｗｗｗｗｗｗｗｗｗ

GPUって書いちゃった　CPUの間違いね

俺のノートだとマザボが80度超えちゃうのでネカフェのPCでやりますわ。
漫画読んでりゃヒットするでしょ。

>>931
うっかりクラッシュさせたりすんなよ……人様のPCなんだから

>>857のネタをMERIKENさんが実行すればもっと速くなるとか胸熱すぎ

MERIKENさん、お疲れ様です
トリップありがとうございます。
あちらのスレで私に成り済まして書き込みしてる
人が居ました

間違いなくトリップは仮酉で頂いてますので！
改めまして、ありがとうございますm(_ _)m

11M位だったCPUが57Mぐらい出たわｗ

>>928
まだIntelのにこだわっていたんですねw
前回のは>>361でGPUはGeForce 610Mでしたよね。
CPU検索の速度が10.8M TPSから28.09M TPSに上がってるのでなかなか
良い感じですね。ソフトウェアの最適化もなかなか面白いでしょう。

>>929-931
効率が上がったせいか、CPUの発熱もこれまでに比べて大分上がっていますねえ。

>>933
どうもどうも。あの程度では騙されませんよｗ

>>934
CPUはなんですか? どうもCPUによって大分最適化の効果が違うようですね。

>>936
ごめんなさい　+GPUの時のSS見てた
+GPUはCPU28Mだったわ

>>857のSHA-1ハッシュ生成の最適化の方法は問題なくMTFに適用出来るようです。
昨日は丸一日プログラミングに使ってしまったので、また数日後に集中して取り組む
予定です。

>>937
ですよね〜ｗ それぐらいが妥当だと思います。

>>935
あるものはIntelでも使えればと思っていたんだぜ……
でもアレ使うと画面表示のタスク時々ソフトに乗っ取られる的な意味で常用しづらかったから、
CPUが改善された現状では特に使う理由はないね、うん
SIMD化ひとまずお疲れ様でした

さっきのはXeon　E5504

【GPU】Xeon E5-2687W×2
【OS】Windows８ Pro
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 1
【トリップの種類】12桁
【その他のオプション】解凍したまんまで
【CPUの10分間平均速度】 279.66tripcodes/s

こっちも同じくらいの上昇率でした

>>941
> 【CPUの10分間平均速度】 279.66tripcodes/s

こ、これは… 2CPUで16コア32スレッドですか。
もはやCPUの数字には見えないですねえｗ

>>942
ちょっとしたGPU並でｗ
暖房入れてない自室の暖房にはもってこいです

catalyst 13.1
http://www.4gamer.net/games/022/G002212/20130118002/

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

5完位なら意外と行けますね。

>>945
一瞬Core 2 Duoと誤読した……
単純な計算だけど、SHArpでも10Mtrip/s行かない感じ？

>>569 >>732 です。　お疲れ様です。

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

(*1) Catalist 12.10 では 630M でした（ただし３分程度のテスト）
(*2) CPU検索が倍以上！！

【GPU】GTX680
【CPU】i7-3960x(4.5GHz)
【OSWindows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 1
【トリップの種類】12桁
【CPUの平均速度】142.47M tripcodes/s
【GPUの温度】62℃ （開始時 27℃）
【その他】テスト時間2分09秒

はええｗｗｗ

>>943
そうでしょうねえｗ 自分の部屋も今年は暖房いらずです。

>>944
やっと正式版が来ましたね。あとでためしてみようっと。

>>945-948
報告ありがとうございます。順当に速度が伸びてますねえ。
あとどれぐらい伸ばせるか楽しみです。

>>945-946
Core 2 Duo T9550 @ 2.66GHzで較べてみたら、SHArp TripperがMTFより微妙に
速いぐらいでした。Core iシリーズでMTFのほうが大分速いのは、MTFがx64で
動いているのが大きいのでしょう。恐らく次の改良で32bit OSでもMTFのほうが
速くなるものと思われますが、どうなることやら。

もうちょっと日を開けようと思ってたけど我慢ができず、高速化の作業を再開して
しまいました。うまい具合にループの内部でSHA-1のブロックの最初のワードだけを
変化させるようにできたので、あとは>>857のコードをMTFに埋め込むだけです。

PW[]の実装はすんなりいったので、あとはP[]を計算するだけです。
しかし本当にうまくいくのかいな、これ。

P[]じゃなくてW[]だった。こっちも終わったので、あとはソースをもう一回
チェックしてから動作確認します。うまく動くといいけど、どうかな〜

やっぱりというか最初の試行ではうまくいきませんでしたorz
速度はかなり出ているので期待大ですが、これデバッグするの大変なんだろうな…

よく見たら元のソースにはW[75]までしか載ってないぞ。わざとやってんのか…
これでは正しい結果が出る訳ありません。しょうがないのでW[76]〜W[79]までを
でっち上げることにします。

W[76]〜W[79]をとりあえず最適化なしで計算してやったら、なんとちゃんと
動くようになりました。>>916や>>927と同じ条件で112M TPS出ています。
>>916の約2.6倍、>>927の1.16倍なので上出来でしょう。
これでCUDA版とOpenCL版の12桁トリップ検索を高速化出来る目処が立ったのも
大きいです。

>>857のリンク先にあったPerlスクリプトを動かして、W[76]〜W[79]の計算を
最適化してやったら119.6M TPS出るようになりました。
これで速度は>>916の2.83倍、>>927の1.23倍になったことになります。

いや〜、しかし今回のアップデートは達成感があるなあ。
>>58-88あたりで行き詰っていたのが嘘のようですｗ

>>957
速度が2割向上……>>927,>>957によると7完が出る時間が8.8時間から7.1時間(2割減)に短縮ですな

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

AVX版も作ったらもっと速くなる予感

いや〜、どうもどうもｗ あのあといろいろいじって、無効なトリップが生成される
確率もかなり引き下げることが出来ました。現在は4%で安定しているので
上出来でしょう。ついでにGPU検索の無効なトリップの割合を引き下げることまで
出来ました。こんなにうまく言っていいのかしらん。

>>960
AVXだとビットシフトが出来ないのでAVX2待ちですねえ。Xeon Phiだとさらに
同時処理できるビット数が上がっているのでこちらも実に楽しみです。

新しい開発版です。

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

主な変更点は12桁トリップのCPU検索の高速化です。

乙

なお、Alpha 2をPhenom II X6 1100Tでも試してみたところ、不思議なことに
Alpha 1よりも遅くなるのが確認されました。
次の開発版ではAMDのCPUが検知されたらAlpha 2の最適化を自動的に切るようにする
予定ですが、いかんせんデータが足りないので、AMDのCPUを持っている方に
Alpha 1とAlpha 2のCPU検索の速度を比較していただけると有難いです。
(Alpha 1はウェブサイトに残しておきました)

AMDは持ってないから協力できなかった…
だが今回してるマシンは300M超えそう

というわけでCPU検索の速度の測定をやり直してみました。
>>927や>>957に比べるとかなり速くなっています。
個人的には120M TPSを超えることが出来たので、非常にすっきりしましたｗ

【CPU】Intel Core i7-3770K @ 4.3GHz (OC)
【OS】 Microsoft Windows 7 64bit SP1
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
【トリップの種類】12桁
【CPU検索スレッドの数】自動(8)
【その他のオプション】なし
【10分間の平均速度】120.15M tripcodes/s
【GPUの平均速度】N/A
【CPUの平均速度】120.15M tripcodes/s
【その他】CPUのみ。5完1タゲ。

>>965
Dual Xeonの方ですか? 報告を楽しみにしています。

【GPU】Xeon E5-2687W×2
【OS】Windows８ Pro
【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
【トリップの種類】12桁
【その他のオプション】解凍したまんまで
【CPUの10分間平均速度】 321.75tripcodes/s

あとは誰かAMDの物理32コアの報告を待つだけ

テンプレ集の日本人の限界のページにあるリンクは、
やたらime.nuに飛ばされるけど何か意味はあるのかしら

>>968
う〜ん、素晴らしい数字です。CPUでは間違いなく最速ですね。

しかしAMDのCPUはSSEの性能はいまいちみたいですね。
SSEなしだとPhenom II X 1100TはCore i7-3770Kより少し速いぐらいだったのですが、
SSEありだと速度は半分といったところです。AMDのBulldozerアーキテクチャで
どれぐらい性能がでるか非常に興味深いところです。

>>969
どのページですか? アドレスを張っていただければあとで確認しておきます。

おっと、そろそろ次スレを用意しないと…
食事を食べ終わったら立てておきます。

>>971
http://www.meriken2ch.com/threads/templates/japanese

次スレ立てました。続きはこちらでお願いします。

【トリップ検索】MERIKEN's Tripcode Finder その2
http://anago.2ch.net/test/read.cgi/software/1358640741/

>>973
報告ありがとうございます。早速直しておきました。
しかし全然気づかなかったな…

【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%)、か

【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%)、か

新スレに貼ろうと思ったら2度も誤爆したんだぜorz

【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のスペックの問題でしょうか？

【CPU】AMD Phenom II X6 1090T @ 3.2GHz
【OS】 Microsoft Windows 8 64bit
【トリップの種類】12桁
【CPU検索スレッドの数】自動(6)
【その他のオプション】なし

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 1
【CPUの平均速度】59.90M tripcodes/s

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
【CPUの平均速度】50.51M tripcodes/s

確かに遅くなってるね

12桁トリップのCPU検索がだいぶはやくなったけどこの技術は10桁トリップのCPU検索の高速化には活かせないのかな？

>>979
次のソフトウェアをインストールしてみて下さい。

Microsoft Visual C++ 2010 再頒布可能パッケージ (x64)
http://www.microsoft.com/ja-jp/download/details.aspx?id=14632

>>980
やっぱりPhenom IIだと遅くなりますね。実行時に自動的に最適化を切るように
しておきます。

>>981
10桁トリップのCPU検索はSSE Intrinsicsで出来ることは全部やってしまったので、
これ以上はアセンブラで書きなおさないと難しいでしょうね。またいずれ取り組む
予定です。

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


はええｗｗｗ
速くて面白くてOCが捗ったｗｗｗ

Webブラウズしながら裏で測定したので参考程度に

【CPU】AMD A10-5800Kデフォルト TurboCore ON
【OS】Windows 8 Pro 64bit
【トリップの種類】12桁
【その他】5完1タゲ
【その他のオプション】デフォルト

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 2
【CPUの10分間平均速度】 36.93Mtripcodes/s

【バージョン】MERIKEN's Tripcode Finder 0.08 Alpha 1
【CPUの10分間平均速度】 38.59Mtripcodes/s

【バージョン】MERIKEN's Tripcode Finder 0.07
【CPUの10分間平均速度】 18.45Mtripcodes/s

でもやっぱりVer0.08 Alpha 2は、Alpha1よりちょっと遅いことは間違いないと思ふ

>>982
そのソフトウェアでは無理です。同じエラーが出てしまいます。
Norton360のインストールも失敗していまして、これはサポートチャットにて、
ダウングレードインストール(6.4.0.9 => 6.3.0.14)で解決できました。
恐らく一部(俺)のPCではx64-SSE2は対応していないということでしょうね。
あきらめも肝心なので、x86-SSE2で暖をとることにします。

>>987
いわゆるDLL地獄ってやつだな。
dependency walkerで調べりゃどれが原因かわかるとは思うが、シロウトには無理か。

>>987
> 恐らく一部(俺)のPCではx64-SSE2は対応していないということでしょうね。

多分他のソフトウェアが悪さしているはずなので、クリーンインストールして
地道に調べれば解決できるはずですけど、そこまでは流石になかなかできない
ですよねえ。

>>986
やっぱりAPUでも遅くなりましたか… 次のバージョンではオプションで
速い方を選べるようにしておきました。

>>988
ののたんさん、助言ありがとうございます。dependency walkerで調べたところ、

エラー：異なるCPUの種類が搭載されたモジュールが見つかりました。
警告：少なくとも1つのモジュールは遅延ロードに依存するモジュールで
不足しているエクスポート機能により、未解決のインポートを持っています。

ということです・・・。

>>989
検索用にF社OEM中古PC(Win7Pro32bit)を購入したあと、HDDのOEM管理領域を残したまま
Win7Pro64bit(DSP版)をインストールしたのがまずかったんでしょうか？
HDDをフォーマットしてからWin7Pro64bitをインストールしてみようと思います。

>>991
OpenCL.dll の名前を変えてみてもだめかな？
OpenCL.dll.dist とかに。

つか、CPU のとこに x86 と x64 が混在してないか？

？

は

どの

GUIの方で設定した内容はCUIで引き継げるのか
検索速度も少し上がる、これは有り難い

【トリップ検索】MERIKEN's Tripcode Finder その2
http://anago.2ch.net/test/read.cgi/software/1358640741/

【トリップ検索】MERIKEN's Tripcode Finder その2
http://anago.2ch.net/test/read.cgi/software/1358640741/

【トリップ検索】MERIKEN's Tripcode Finder その2
http://anago.2ch.net/test/read.cgi/software/1358640741/


1000ﾄﾞｿﾞｰ

1000!

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。