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

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

Meriken's Tripcode Finderは2013年8月現在で最速の12桁トリップ検索ツールです
(最高速の記録は11112.48M tripcodes/s)。CUDA対応のNVIDIAのビデオカード、
もしくはHD 5xxx以降のAMD Radeonシリーズのビデオカード等のOpenCL対応デバイスを
使用すれば非常に高速に検索を行うことができます。特徴は以下の通りです。

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

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

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

■関連リンク
トリップ総合ウェブサイト「tripcode.net」
http://tripcode.net/

分散トリップ検索サービス「MERIKEN's Tripcode Ygdrasil」
http://tripcode.net/yggdrasil

■関連スレ
【分散トリップ検索】Meriken's Tripcode Yggdrasil
http://toro.2ch.net/test/read.cgi/esite/1379214816/

■過去スレ
初代 http://anago.2ch.net/test/read.cgi/software/1311428038/
無印 http://anago.2ch.net/test/read.cgi/software/1348565078/
その2 http://anago.2ch.net/test/read.cgi/software/1358640741/
その3 http://anago.2ch.net/test/read.cgi/software/1362648003/
その4 http://anago.2ch.net/test/read.cgi/software/1373110438/

■過去スレのログ
初代 http://unkar.org/r/software/1311428038
無印 http://unkar.org/r/software/1348565078
その2 http://unkar.org/r/software/1358640741
その3 http://unkar.org/r/software/1362648003
その4 http://unkar.org/r/software/1373110438

■最高速の記録
> 139 ： ◆MERIKEN4.k ：sage ：2013/07/20(土) 13:00:49.05 ID:FlwZiche0!
> 5ヶ月振りの新記録ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
> 【診断の種類】検索速度(1パターン)
> 【Meriken's Tripcode Finderのバージョン】0.10
> 【OS】Microsoft Windows 7 64bit SP1
> 【ディスプレイドライバ】Catalyst 13.5 Beta2
> 【検索デバイス】GPUのみ
> 【使用するGPU】すべて使用
> 【GPU0】DIAMOND 6990PE54G Radeon HD 6990 4GB @ 910MHz (OC)
> 【GPU1】Gigabyte GV-R799D5-6GD-B Radeon HD 7970 @ 1130MHz (OC)
> 【GPU2】VisionTek Radeon HD 7990 @ 1100MHz (OC)
> 【CPU】AMD Phenom II X6 1100T (定格)
> 【1CUあたりのワークアイテムの数(OpenCL)】自動
> 【1WGあたりのワークアイテムの数(OpenCL)】自動
> 【1GPUあたりの検索プロセスの数(OpenCL)】1
> 【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
> 【検索プロセスの優先度】通常
> 【GUIフロントエンドの優先度】通常
> 【トリップの種類】12桁
> 【キーに使用する文字】すべて
> 【検索パターン】 10文字完全前方一致1個
> 【10分間のGPU検索の平均速度】11112.48M tripcode/s
> 【GPUの使用率】93〜99%
> 【GPUの温度】80〜97℃
> 【その他】Power Limit (6990): +15%, Power Limit (7990): +5%, Fan Speed: 100%
http://anago.2ch.net/test/read.cgi/software/1373110438/139n

テンプレは以上です。このスレでもよろしくお願いします。

新しい開発版をうｐしました。

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

Alpha 2からの主な変更点は以下の通りです。

・全角文字をキーに使用したときのヒット率の向上。
・キーに使用する文字の種類の追加。
・12桁トリップのCPU検索の速度向上。
・10桁トリップのOpenCL版のGPU検索の速度向上。

あ、あとこれを>>5にたしとくのをわすれてましたｗ

・破損した設定ファイルを自動的に修復する機能の追加。

おお、お疲れさまです。試してみますね。

さっそくAlpha 3にバグがorz
Radeonを使っててGPUが複数あると、検索がいつまでたっても始まりません。
原因はわかっているのですが、これどうやって修正しようかな…

一応修正は出来ました。これから配布パッケージを用意します。

この前α1とα2で速度に差が出ると言っていた者です

α3はα1のときの速度になりました
(21MT/sです)

12桁の方も戻ってました

85MT/sです

新しい開発版をうｐしました。

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

Alpha 3からの主な変更点は以下の通りです。

・Radeonのビデオカードを使用していてGPUが複数あると検索できない
　不具合の修正。

>>10-11
摩訶不思議ですね〜
いずれにせよ戻ってて安心しました。

修正おつかれさまです

α4も大丈夫でした

>>8

バグでしたか。モロそのバグに引っかかって悩んでました。
今Alpha 4で動作を確認しました。

>>15
いや〜申し訳ないです… そろそろプロセス間通信周りを綺麗に書き直したいんですが、
デバッグの手間を考えるとなかなか踏ん切りがつきません。

質問すみませんが
Alpha 4の「キーに使用する文字」の
「半角と全角」と「すべて」の違いは何でしょうか？
Alpha 4のデフォルトですと「すべて」ではなく「半角と全角」が選択されるようですが
Alpha 2以前の「すべて」に相当するのは
Alpha 4の場合は「半角と全角」になるのでしょうか？

上で質問した者ですが
各種診断を使ってみましたところ
1.1FE Alpha 4で「キーに使用する文字」が「半角と全角」の場合は

> 【キーに使用する文字】1バイト文字のみ

になって「すべて」の場合は

> 【キーに使用する文字】すべて

になっているようですので
1.1FE Alpha 2以前の「すべて」と同じ設定にするには
1.1FE Alpha 4でも「すべて」にしないといけないということでしょうか

実はこちらで12桁検索に使っているPCが
Core2 Duo E7600＋Radeon HD6850の古いPCなのですが
1.1FE Alpha 2→1.1FE Alpha 4に入れ替えましたところ
12桁の検索速度が落ちてしまいましたので
「キーに使用する文字」が原因がどうかを知りたかったのです
長くなりますが以下診断の結果を張っておきます
OSはWin7 x64＋Catalyst 13.5beta2です

※こちらの環境ではCatalyst 13.6beta以降（〜13.10betaまで）を使うと
MTFのバージョンに関係なく12桁のGPU検索速度が落ちてしまうので13.5beta2を使っています

・1.1FE Alpha 2で「キーに使用する文字」が「すべて」の場合

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 2

【検索デバイス】GPUとCPU
【使用するGPU】すべて使用

【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】1
【SHA-1ハッシュ値生成の最適化(CPU)】最大
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 819.11M tripcode/s
【GPU検索の平均速度】 805.41M tripcode/s
【CPU検索の平均速度】 13.70M tripcode/s

・1.1FE Alpha 4で「キーに使用する文字」が「半角と全角」の場合

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 4

【検索デバイス】GPUとCPU
【使用するGPU】すべて使用

【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】1
【SHA-1ハッシュ値生成の最適化(CPU)】最大
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】1バイト文字のみ
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 817.08M tripcode/s
【GPU検索の平均速度】 802.93M tripcode/s
【CPU検索の平均速度】 14.16M tripcode/s

・1.1FE Alpha 4で「キーに使用する文字」が「すべて」の場合

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 4

【検索デバイス】GPUとCPU
【使用するGPU】すべて使用

【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】1
【SHA-1ハッシュ値生成の最適化(CPU)】最大
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 814.97M tripcode/s
【GPU検索の平均速度】 800.87M tripcode/s
【CPU検索の平均速度】 14.11M tripcode/s

ということで1.1FE Alpha 4で確かに12桁のCPU検索速度は上がっているのですが
逆にGPU検索速度が落ちてしまっていて
全体としては1.1FE Alpha 2の方が検索速度が上になります
検索デバイスをGPUのみにしても傾向は変わりません

あと診断ですと差はわずかですので無視してもよかったのですが
実際にYggdrasilに参加した状態では

・1.1FE Alpha 2での場合GPU検索速度が約675MTPS〜約700MTPSの間で変動（約700MTPSの場合が優勢）
CPU検索速度は約13MTPSでほぼ一定

・1.1FE Alpha 4の場合は「キーに使用する文字」が「半角と全角」の場合でも「すべて」の場合でも
GPU検索速度が約650MTPS〜約675MTPSの間で変動（ほぼ均等）
CPU検索速度は約13MTPS〜約13.1MTPSの間で変動

となって平均検索速度で言えば1.1FE Alpha 2の方が30MTPS程度上になります

まあこれでも誤差の範囲と言われればそうなると思いますが
Free Editionが出て以降ほぼ変わっていなかった12桁の検索速度が1.1FE Alpha 4で落ちてしまいましたので
一応ご報告しておきます

>>17
> 「半角と全角」と「すべて」の違いは何でしょうか？

「半角と全角」の場合は全角文字の一部は使用されませんが、
「すべて」の場合は全部使用されます。
その代わり、「すべて」を選ぶとヒット率が3%ほど落ちます。

> Alpha 2以前の「すべて」に相当するのは
> Alpha 4の場合は「半角と全角」になるのでしょうか？

Alpha 2以前の「すべて」は、Alpha 4の「すべて」と同じです。

>>18
あ〜診断の表示を変更するのを忘れてましたorz 診断の結果は正しいはずです。

>>19-22
詳しい報告有り難うございます。HD 5xxx/6xxxだとOpenCLコンパイラのバックエンドが
あまり賢くないせいか、ちょっとコードを変更するだけですぐに速度が落ちちゃうんですよね。
速度を戻すことが出来ないか試してみますが、難しいかもしれません。

>>18
5770ではほぼ元の速度を出せるようになりました。
6850と5770のアーキテクチャは同じVLIW5なので、多分大丈夫でしょう。

TITANでalpha4を試したところ、
1500M tripcode/s
いきました。

>>26
お、こっちは速くなってますね。
しかしTITANももっと速くてもいいぐらいなんですけどね〜
自分でいじれないのがちと歯がゆいです。

12桁トリップのCPU検索をアセンブラを使って書き直せないか現在思案中。
多分SSE2だけでも数割速くなるだろうし、AVX/AVX2ならさらにそこから
上乗せ出来そうなんですけど、どうかなあ。

というわけでちょっと調べたら、VecTripperに再利用出来るアセンブラのコードが
あったので、これを使うことにしました。ライセンス的にも問題ないようです。
1から書くのはなかなかしんどそうなので、ありがたいことです。

そういやSHA-1のルーチンはかなり最適化してたから、
このままじゃ使えないんだよなあ。どうしたものか。

SHA-1のルーチンをじっと眺めていたら、
キーの長さをSHA-1のブロックのサイズにあわせて64文字に
することによって、更に最適化出来そうなことに気づいてしまいましたｗ
今のままでも工夫してやればラウンドを2つループの外に追い出せそうです。

あ、448bitだから64文字じゃなくて54文字か。
で、最大で最初の13個のラウンドを追い出せるわけね。
80個のラウンドのうちの13個ってかなり大きいよな。
単純に考えれば2割ほど高速化できる計算です。
だけど2chで56文字のキーなんて使えるのかしらんｗ

54文字じゃなくて56文字だった。
56文字のキーは2chで普通に使えました。
でもMTFを56文字のキーに対応させるのは
さすがに手間が大きすぎるような…
まあこのネタは取っておいて、とりあえずアセンブラで書き直そうっと。

>>23-25
どうもありがとうございます

アーキテクチャの違うハードを
それぞれ最適な性能が出るようにサポートするというのは
ものすごく手間のかかることと思います
お手数をおかけして申し訳ありませんでした

>>27
どうもです。余分なグラフィックを切ってなかったり、
TITANのくせにPCI-Express2.0接続だったりするので、
TITANとしては遅いかもしれません。
GPGPUコンピューティンの時にはPCI-Expressバスの問題は
どうせCudaMemcopyなどは最小限にしてるでしょうから
関係ない気もしますが。

MERIKENsTripcodeFinder_1.1_FE_Alpha_2 だと全く問題ないのに、
MERIKENsTripcodeFinder_1.1_FE_Alpha_4 だとエラーで動かないのは
何が原因と考えられますか？

>>35
エラーの種類とか、出現条件とか、もうちょっと詳しくおながいします。


■ バグ報告用のテンプレ

バグを報告する際には下のテンプレを使ってなるべく詳しく
具体的に報告して下さい。

【症状】
【バージョン】MERIKEN's Tripcode Finder x.xx
【トリップの種類】12桁・10桁
【GPU】
【CPU】
【OS】
【Display Driver】
【その他】

12桁のトリップのYggdrasilでの分散探索についてですが

2chは64文字より長いトリップキーが使えるということは

SHA1で1ブロック目の計算はサーバーでやって

1ブロック目で使われる最初の64文字のキーはクライアントに送らずに
2ブロック目以降で必要になる1ブロック目から計算される情報だけをクライアントに送り

クライアントは2ブロック目以降をランダムに生成してトリップを探索する

こうすれば1ブロック目のキーはサーバしか分からないからリバースエンジニアリングされてもクライアントに漏洩されずに済む


こんなのを考えたんですがどうでしょうか

発見されるトリップのキーが常に64文字以上になるのが欠点ですが

>>33
いや〜これ気づかずに放置するところでした。ありがとうございました。
MTFはトリップ検索ツールの決定版を目指しているので、
まだまだこれからですｗ ちょっとまとまったお金が入りそうなので、
物欲に任せてi7-4770Kとマザボを買おうかどうか迷っているところです。

>>37-38
これは非常に面白いですねえ。キーの漏洩が原理的に不可能というのは
かなり美味しいです。キーの長さは実際どうなんでしょうねえ。
試しに遊びで56文字モードを付けてみようかしらん。

>>40
非常に面白いけど、メッセージの途中までを依頼側が制御できてしまうってのは色々アレですね。
SHA-1で署名されてるメッセージのラスト以外を捏造したSHA-1中間状態で依頼して…みたいな。
MD5で衝突させた実験はいくつかあったけどSHA1でやれるとちょっと面白い(では済まない？)かも。

>>41
私はクラッキングには興味が無いですけど、クラッキングに分散処理を利用するというのは
ありなのかもしれませんねえ。Bitcoinマイナーみたいなのにそういうコードを
入れといてもわからないでしょうからね。

一応>>30-32をまとめておきます。

・トリップのキーの長さをSHA-1のブロックの大きさに合わせて56文字にすることで、
　12桁トリップ検索をさらに2割ほど高速化出来る。

・ループの内部ではW[13]に対応するキーの53文字目から56文字目のみを変化させる。

・SHA-1の最初の13個のラウンドはW[13]に依存しないので、
　あらかじめループの外で計算しておく。

・この方法はJens Steube氏のSHA-1ハッシュ値生成の最適化の手法と
　組み合わせることも可能。その際はW[0]ではなくW[13]を中心にして計算を行う。
　http://passwords12.at.ifi.uio.no/Jens_Steube/Jens_Steube_Passwords12.pdf

鳥屋氏はこのことに気づいていたみたいですが、なかなかにコロンブスの卵的な発想です。

これ、こちらにも貼っておきますね。

> 24 : ◆Meriken//XXX : sage : 2013/09/19(木) 04:54:27.08
> そうそう、そろそろYggdrasilのAPIを新鯖に一本化したいので、バージョン1.0 (FE)以前の
> MTFをお使いな方はバージョン1.0.1 (FE)以降に更新をお願いします。

次のα版に乗り換えるかな…

>>45
結構いろいろ改善されているのでぜひどうぞｗ
>>43の実装がいつになるのかはちょっと分かりませんが…

現在VecTripperのSHA-1のアセンブラのコードをせっせとMTFに移植中です。
とりあえずAVXで最初の14個のラウンドが動作することを確認しましたが、
かなり速いです。さすがです。これはかなり期待できそうです。

20回目のラウンドまで変換出来ました。
かなり最適化されたコードみたいで期待大ですが、
気を使う作業なのでとにかく疲れます。
続きは明日以降にしておきます。

アセンブラまで手を出していたのですね。おつかれさまです。

アセンブラでないと限界まで速度を出せないですからね〜
10桁は書き換えたので次は12桁というわけです。

ご飯を食べて元気が出たので、素のSHA-1のルーチンを一気にAVXで書き換えてしまいました。
結果は上々で、2割ほど速度が上がっています。もうちょっといじれば3割まで行きそうな
感じです。

ここまではわりとすんなりと行きましたが問題はこれからで、今度は特殊な最適化を施してある
SHA-1のルーチンを書き換えなければなりません。これは1から書くしかないので、
少しづつ進めていくことにします。

あれから素のSHA-1のルーチンの関数呼び出しのオーバーヘッドを
削って、合わせて27%の速度向上となりました。
VecTripperのルーチンは命令を削れるだけ削ってあるという印象です。
素晴らしいです。

最適化済みのルーチンもこんなふうに自分で書き直せればいいけど、
どうでしょうねえ〜

>>39
AVX2対応キターーー! ヽ(´Д｀)ノ

AVX2が目的でHaswellを選ぶなら、高いK付きを選ぶ必要は無いと思います。
HaswellはAVXを使うと極端にOC耐性が落ちます。更に殻割り+液体金属必須です。
K無しを定格で使うのが良い、とK付きで殻割りOCまで試した私は思います。

>>53
確かにK付きはいらないですねえ。開発機の3770KもOC切っちゃったし…
その代わりにマザボを奮発してQuad CrossFireが出来るのにしようかな。
AVX-512がコンシューマー市場に下りてくるのは当分先でしょうしね。

最適化されたルーチンをじっと眺めてたらなんだか出来そうな気がしてきたぞ。

おもむろに少し書き換えてみたらうまくいきましたｗ
こりゃ思ったよりずっと簡単かも。

開発が進んでいるようで何よりです
自分はPCの計算力を提供するぐらいしかできませんけど…

いやいや、それだけで十分すぎですｗ
うろつきさん、めちゃ速いですしね。

最適化済みのSHA-1のルーチンのアセンブラでの書き換えは
半分終わりました。既に元のSSE2 Intrinsicsでの実装より大分速くなっています。
思い切って手を付けてみて正解でした。

x64版のAVXでの書き換えは一応終了。
最適化されたルーチンは15%ほど速くなりました。
もうちょっと命令を削れそうな感じです。

>>54
Z87のマザーだと、ASUS MAXIMUS VI EXTREMEがPCIe 3.0(x8/x16/x8/x8)駆動で最大だからQuad CrossFireするには勿体無さそうに思うけどな。
ttp://www.asus.com/jp/Motherboards/MAXIMUS_VI_EXTREME/#specifications

Quad CrossFireがPCIe 3.0(x16/x16/x16/x16)で動作保障してくれるマザーってあるんだっけ？

>>61
MTFでつかうぶんにはPCIeの帯域はほとんど関係ないので問題なしです。
買うとしたら検索君1号用なので他の用途には使わないですしね。
もうちょっと安いのでもいいんですけど、スロットの配置がいいのが
ないんですよね〜

命令を2つばかり削ってちょびっと速くなりました。
さすがに疲れたのこのへんにしときます。
後はこれをSSE2に移植して、32bit版を作らなきゃいけないんだよなあ。
まあのんびりやろうっと。

とりあえずAVX2対応の準備はできたので十分でしょう。
CPUだけで250M TPS出せるかもしれません。ぐへへへへ…

SSE2版を作って命令を2オペランド化してみたらかえって元のより遅くなったぞorz
たくさん作ってもメンテするの大変だし、アセンブラのルーチンは
64bit AVX/AVX2専用にしちゃおうかなあ。

…と、ここまで考えてから試しにVecTripperの真似をしてvmovdqaをmovaps に
変えたら、それだけでもとより速くなりましたｗ　なぜだ…

>>61
ブリッジ挟んだなんちゃって仕様ならコレ。Haswellではありませんが。
ttp://www.asus.com/jp/Motherboards/P9X79E_WS/
なんちゃってなので、グラフィック用です。
大量のデータ転送を同時に行うGPGPU用途には使えません。

Nativeならこれくらい逝かないと無理です。
ttp://www.supermicro.com/products/motherboard/Xeon/C600/X9DRG-QF.cfm

>>65
今回の購入のメインはHaswellなので、やっぱりASUSのM6Eですかね〜
いやあ、楽しみだなあ。

最適化されたルーチンのSSE2への移植は完了しました。かなり速いです。
今まで58M TPSしか出ていなかったPhenom II X6で92M TPSでました。
Visual C++、効率が悪すぎだろう…

というわけで、64bit版は最適化されたルーチンに
一本化することにしました。これで大分すっきりとしました。
あと32bitだとxmmレジスタの数が足りなさすぎなので、
アセンブラで書きなおすのはやめにしました。
これで後は念の為にもう一回テストするだけです。

あ、でも最適化されたルーチンだけならレジスタ周りはそんなに厳しくないのか。
せっかくだから32bit版も書きなおそうかな。そうすれば大分すっきりするし…

>>67
>Visual C++
iclですらない……そりゃ徹底的にアセンブラしたら速いでしょうねｗ
これで私もCPUのみで15MTPS逝きそうですな……

>>70
お、お久しぶりです。
Intelのも一応試してみたけどほとんど速度は変わりませんでしたよ。
まあそんなにうまい話は転がってないですね。
限界まで性能を出したいならコンパイラに頼らずに自分でやるしかないですね。

>>71
>お久しぶりです
すみません、実は久しぶりというわけでもないのです。
うろつき ◆Urotsuki/1Caさんに見つけてもらったこの酉で最近はレスしてました。
諸事情により最近はノーパソをぶん回したまま放置ということができなかったので、レベルが上がりようがないという悲しみ……

ところで、複数PCで同じアカウントでログインしてゆぐちゃんに参加するとポイント(ﾟдﾟ)ｳﾏｰなんですよね？

>>72
そういえばそうだったｗ そのトリップを見たのが久しぶりだったのでうっかりしてしまいました。
経験値はちゃんと加算されますよ。

新しい12桁トリップのCPU検索のルーチンの32bit版も出来ました。
手元のCore 2 Duoで試したら4割近く速度が上がっています。
やっぱコンパイラの最適化は当てにならないなあ。
とにかく検索ルーチンのアセンブラでの書き直しは終わったので、
明日あたりにGUIの修正と最終テストを行って、新しい開発版をうｐします。

wktk

wktkですねこれは
しかし相変わらずの化け物じみた速度…
自分は契約Aの問題でこれ以上速度あげられないんだよなぁ

同一トリップ　別キー　なんてのもちゃんと出てくるんですな

TITANより速いとか、これはもう買うしかないのではなかろうか。
発表は25日か〜

http://wccftech.com/amd-hawaii-r9290x-gpu-volcanic-islands-benchmark-results-exposed-fastest-gpu-planet-1020-mhz-clock-speed/=

>>76
7970 CFにしては抑え気味だなと思ってたんですけど、
そういうことだったんですね。私もこれで結構ギリギリで、
しょっちゅうブレーカーを飛ばしていますｗ

>>78のリンクが壊れてました。

http://wccftech.com/amd-hawaii-r9290x-gpu-volcanic-islands-benchmark-results-exposed-fastest-gpu-planet-1020-mhz-clock-speed/

>>72
あ、そうそう。私はアマガミはモジャ子で挫折しましたｗ
梨穂子ちゃんと先輩はなかなか良かったです。

新しい開発版をうｐしました。

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

Alpha 4からの主な変更点は以下の通りです。

・12桁トリップのCPU検索のAVXへの対応。
・12桁トリップのCPU検索の高速化。

CPUによってはかなり速くなっているようです。
診断の結果や前のバージョンとの比較を報告していただけると助かります。

現在Meriken's Tripcode Engineの英語版を作成中。
プログラムに変更はすぐに終わったけど、
ドキュメントの翻訳が超めんどくさいです。

>>82
お疲れ様です。
12桁検索（CPUのみ）の速度を見てみました。
検索パターンは、先頭一致6完一つと特殊の純8連です。

【OS】Win7 Pro 64bit SP1
【CPU】Core i5 3570
【CPU検索スレッドの数】4

検索開始10分後の平均速度
MTF 1.1 FE Alpha4 74.21M tripcode/s
MTF 1.1 FE Alpha5 91.94M tripcode/s

めっちゃ高速化してます。

>>84
いい感じに速度が上がっていますね〜
AVXがかなり効いてるのかな?
i7-3770Kより差が大きいのはおいしすぎですね。

おー新しいのきましたか
CPU関連の効率化だけかなー?
GPUメインにはあまり縁がないかなー…
取り敢えず測定してみようっと

ぜひお願いします。CPUによってほんとに速度の変化がバラバラなんですよね。

CPUの冷却が不安なので長い時間ぶん回せませんね…
取り敢えず結果です

【OS】Windows7 Pro 64bit SP1
【CPU】Intel Core i7-3930K(自動的に3.9GHzまでOC)
【CPU検索スレッドの数】12
【検索中の温度】　46〜59度(簡易水冷)
【検索パターン】先頭一致10完　1つ

検索開始5分後の平均速度
MTF 1.1 FE Alpha4 129.19M tripcode/s
MTF 1.1 FE Alpha5 160.65M tripcode/s

速度がかなり上がりました
OCしているので定格だとどうなるかわかりませんが上がり幅は同じだと思います

【診断の種類】検索速度(1パターン)
【MERIKEN's Tripcode Finderのバージョン】1.1 Free Edition Alpha 4, 5
【OS】Microsoft Windows 7 Ultimate 64bit SP1
【検索デバイス】CPUのみ
【CPU】Intel Core i7 [email protected]
【CPU検索スレッドの数】8 (HTon)
【検索プロセスの優先度】通常
【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個
【10分間のCPU検索の平均速度】104.66(a4) → 122.57(a5) M tripcode/s
【その他】MTEngine64 -c -t 8 -l 12

2割近く速度が上がってますね。AVX2対応が楽しみです。

Win7 x64 / C2Q Q9650定格（3GHz）CPUのみ / 4スレッドでの
1.1FEα2 / 1.1FEα4 / 1.1FEα5の各バージョンの12桁検索の「各種診断」の実行結果です
共通
【診断の種類】検索速度(1パターン)
【検索デバイス】CPUのみ
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】自動　※4スレッド
【SHA-1ハッシュ値生成の最適化(CPU)】最大　※1.1FEα2 / 1.1FEα4のみ
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常
【トリップの種類】12桁
【検索パターン】 10文字完全前方一致1個

1.1FEα2
【キーに使用する文字】すべて
【10分間のCPU検索の平均速度】 53.94M tripcode/s

1.1FEα4
【キーに使用する文字】1バイト文字のみ　※半角と全角
【10分間のCPU検索の平均速度】 55.22M tripcode/s
【キーに使用する文字】すべて
【10分間のCPU検索の平均速度】 55.17M tripcode/s

1.1FEα5
【キーに使用する文字】半角と全角
【10分間のCPU検索の平均速度】 62.22M tripcode/s
【キーに使用する文字】すべて
【10分間のCPU検索の平均速度】 62.20M tripcode/s

結果
・1.1FEα4 / 1.1FEα5の【キーに使用する文字】の「半角と全角」と「すべて」の検索速度の違いはわずか
・1.1FEα2→1.1FEα4：約2.5%UP　1.1FEα2→1.1FEα5：約15.3%UP　1.1FEα4→1.1FEα5：約12.7%UP

すいません、MTF1.1FEのalpha2〜4はどこかでDL出来ますでしょうか？
手違いで消してしまいましたｗ

リンク先のファイル名を変えるだけで落とせたと思う。

あ、なるほど気が付きませんでした
無事落とせました

【検索デバイス】GPUとCPU
【OS】 windows7 HP 64bit SP1
【使用するGPU】AMD Radeon HD 5570/5670 (OpenCL)
【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】自動
【SHA-1ハッシュ値生成の最適化(CPU)】最大
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個
α2
【10分間の平均速度】 366.70M tripcode/s
【GPU検索の平均速度】 340.43M tripcode/s
【CPU検索の平均速度】 26.27M tripcode/s
α4
【10分間の平均速度】 366.74M tripcode/s
【GPU検索の平均速度】 340.08M tripcode/s
【CPU検索の平均速度】 26.66M tripcode/s
α5
【10分間の平均速度】 364.47M tripcode/s
【GPU検索の平均速度】 340.61M tripcode/s
【CPU検索の平均速度】 23.86M tripcode/s

計測報告は初めてですがこんな感じでいいのでしょうか？
因みにα3はバグがあるとスレの初めに話題になってたようなので除外しました

診断ではα5のCPU効率が若干低下してますが
検索実測でもα5はα2、4に比べてGPUCPU共
似たような効率低下傾向があるようです

あ、これだとCPUが載ってないですね
CPUは intel core i5-750 2.66GHz定格使用です

>>17-22を書いた者ですが
1.1FE Alpha 5で1.1FE Alpha 2と同等以上の検索速度になりました
どうもありがとうございました

・1.1FE Alpha 5の各種診断で「キーに使用する文字」が「半角と全角」の場合
【トリップの種類】12桁
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 820.98M tripcode/s
【GPU検索の平均速度】 805.08M tripcode/s
【CPU検索の平均速度】 15.90M tripcode/s

・1.1FE Alpha 5の各種診断で「キーに使用する文字」が「すべて」の場合
【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 820.92M tripcode/s
【GPU検索の平均速度】 805.02M tripcode/s
【CPU検索の平均速度】 15.90M tripcode/s

・Yggdrasilに参加して検索開始10分後の平均検索速度
1.1FE Alpha 2: 694.95MTPS (GPU: 681.99M, CPU: 12.96M)
1.1FE Alpha 4: 665.13MTPS (GPU: 652.14M, CPU: 12.99M)
1.1FE Alpha 5: 695.23MTPS (GPU: 680.68M, CPU: 14.56M)

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 4　→　Alpha 5

【検索デバイス】GPUとCPU
【使用するCPU】Intel Core i7-3770 CPU @ 3.40GHz
【使用するGPU】NVIDIA GeForce GTX 660 (CUDA)

【1SMあたりのブロック数(CUDA)】自動
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】自動
【SHA-1ハッシュ値生成の最適化(CPU)】最大
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 622.09M tripcode/s　→　635.74M tripcode/s
【GPU検索の平均速度】 535.55M tripcode/s　→　534.50M tripcode/s
【CPU検索の平均速度】 86.54M tripcode/s　→　101.25M tripcode/s

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1FEα5/1.1FEα4/1.0.1(安定版)

【検索デバイス】CPUのみ (i7 M620 @2.67GHz)

【CPUの命令セット】x64 + SSE2
【CPU検索スレッドの数】自動
【検索プロセスの優先度】アイドル
【GUIフロントエンドの優先度】アイドル

【トリップの種類】12桁
【キーに使用する文字】半角(※1バイト文字のみ)
【検索パターン】 10文字完全前方一致1個

【10分間のCPU検索の平均速度(TPS)】

　　1.1FEα5 　1.1FEα4　 1.0.1(安定版)
------------------------------------
1) 　27.84M　　　30.51M　　　31.67M
2) 　27.80M　　　30.50M　　　31.77M
3) 　27.69M　　　30.58M　　　31.67M
4) 　27.85M　　　30.54M　　　31.68M
5) 　27.83M　　　30.54M　　　31.64M

皆さん詳しい報告を有り難うございます。
どうもNehalemだけ遅くなっているようですね。難しスギィ！

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 3 -> 1.1 Free Edition Alpha 5
【OS】Windows 7 Professional SP1

【検索デバイス】GPUとCPU
【使用するGPU】すべて使用
【GPU】GeForve GTX 650
【CPU】Ibtel Core i3-3220 CPU @ 3.30Ghz

【1SMあたりのブロック数(CUDA)】8
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】1
【SHA-1ハッシュ値生成の最適化(CPU)】最大
【検索プロセスの優先度】アイドル
【GUIフロントエンドの優先度】アイドル

【トリップの種類】12桁
【キーに使用する文字】1バイト文字のみ
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 215.90M tripcode/s -> 221.77M tripcode/s
【GPU検索の平均速度】 205.58M tripcode/s -> 207.19M tripcode/s
【CPU検索の平均速度】 10.32M tripcode/s -> 14.58M tripcode/s


すごい改善率

>>101
こりゃ凄いですねw 結構さがでるもんですね〜

■Alpha 3/4とAlpha5の12桁トリップのCPU検索の速度の比較

>>67 +58% Phenom II X6 AMD K10
>>101 +41% i3-3220 Ivy Bridge
>>84 +24% i5-3570 Ivy Bridge
>>88 +24% i7-3930K Sandy Bridge
>>89 +17% i7-4770K Haswell
>>98 +17% i7-3770 Ivy Bridge
>>90 +13% C2Q Q9650 Core
>>97 +12% C2D E7600 Core
>>99 -9% i7-M620 Nehalem
>>94 -11% i5-750 Nehalem

やっぱNehalemだけ遅くなってますねえ。残念…
VC++ 2010はNehalemに合わせて最適化されていたのかしらん。
まあでも他のアーキテクチャでは順当に速度が上がっていますね。
Hyper Threadingはないほうが効果がはっきり出るみたいです。

英語版を作って本家Slashdotにストーリーを投稿してみました。
ぜひVote Upをよろしくお願いいたしますｗ

Meriken's Tripcode Engine English 0.01 Released
http://slashdot.org/submission/2986003/merikens-tripcode-engine-english-001-released

Meriken's Tripcode Engine English
http://www.meriken2ch.com/programming/merikens-tripcode-engine-english/index.html

1.1FEα5の鯖との定期通信の間隔は
・検索開始3分後までが10秒ごと
・以降3分ごと
でよろしいでしょうか？

>>105
そうで〜す。このパラメーターはサーバー側で調整できるので、
サーバーが重くなってきたら増やすかもしれません。

【診断の種類】検索速度(1パターン)

【検索デバイス】CPUのみ
【CPU】Ibtel Core i7-980X CPU @ 4Ghz

【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】自動
【SHA-1ハッシュ値生成の最適化(CPU)】最大
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】1バイト文字のみ
【検索パターン】 10文字完全前方一致1個

【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 4
【10分間のCPU検索の平均速度】 148.51M tripcode/s

【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 5
【10分間のCPU検索の平均速度】 129.78M tripcode/s

結構落ちますね。 -15%弱ってところでしょうか。

>>107
これもWestmere-EPだからNehalemの仲間ですね。
うまい具合にNehalemだけ検出できないかなあ。

WikipediaにCPUIDが載ってたけど、これほんとに当てになるのかな〜

> 0x0206e6, 0x0106a4, 0x0106a5, 0x0106e4, 0x0106e5
http://en.wikipedia.org/wiki/Nehalem_(microarchitecture)

> 0x0206f2, 0x0206c2, 0x020652, 0x020655
http://en.wikipedia.org/wiki/Westmere_(microarchitecture)

> 0x0206c0, 0x0206c1, 0x0206c2, 0x0206c3, 0x0206c4,
> 0x0206c5, 0x0206c6, 0x0206c7, 0x0206c8, 0x0206c9,
http://en.wikipedia.org/wiki/Gulftown

>>81
棚町(と七咲)は☆獲得に会話イベントでアタック成功させないと駄目な娘なので……
順番を見るに、WikiのFAQを読みながらやったパターンですかね？
>>82
乙です。早速ベンチしてみますね。
>>108
前に「GPU毎に処理方法変える為にデータベース作るか」と言われていたことを思い出しました……

こんな情報がありました

Intel Architecture and Processor Identification With CPUID Model and Family Numbers
ttp://software.intel.com/en-us/articles/intel-architecture-and-processor-identification-with-cpuid-model-and-family-numbers

Nehalem / Westmere世代は

[45nm]
Bloomfield / Nehalem-EP : 0x106Ax
Lynnfield / Clarksfield / Jasper Forest : 0x106Ex
Nehalem-EX : 0x206Ex

[32nm]
Clarkdale / Arrandale : 0x2065x
Gulftown / Westmere-EP : 0x206Cx
Westmere-EX : 0x206Fx

あたりでしょうか

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 5

【検索デバイス】CPUのみ
【CPU】Intel Xeon W5590 ×2 (3.33GHz)

【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】自動
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間のCPU検索の平均速度】 84.98M tripcode/s

>>112
やっぱりNehalemだと駄目ですね〜

>>111
これで正解ですね。助かります。
Nehalemを検出したら元のルーチンを使うように修正しておきました。
時間のあるときに次の開発版をうｐします。

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 4→5

【検索デバイス】GPUとCPU
【使用するGPU】すべて使用

【1SMあたりのブロック数(CUDA)】256
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】4
【SHA-1ハッシュ値生成の最適化(CPU)】最大
【検索プロセスの優先度】通常
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】1バイト文字のみ
【検索パターン】 10文字完全前方一致1個

【 5分間の平均速度】 96.97→102.79M tripcode/s
【GPU検索の平均速度】 64.32→64.30M tripcode/s
【CPU検索の平均速度】 32.64→38.49M tripcode/s

※CPUのみだと36.95→42.76M tripcode/s。ちなみに当方はi5-3210M＝Ivy Bridge。

core i7 2700K 定格 HTオン 8スレッド

84Mから105Mに上がりました

>>104
> 英語版を作って本家Slashdotにストーリーを投稿してみました。
って事は、これからは外人さんも参加してくれる？
一気に人数が増えるといいな。

>>106
ご回答ありがとうございました

>>114
>>115
やっぱりNehalem以外では速くなってるんですよねえ…
コンパイラの吐いたコードを調べてみようっと。

新しい開発版をうｐしました。

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

Alpha 5からの主な変更点は以下の通りです。

・Nehalem系のCPUで12桁トリップのCPU検索が遅くなる不具合の修正。

引き続き前のバージョンとの速度の比較を報告していただけると助かります。

コンパイラの吐いた無駄だらけのコードを見てたら、movapsの代わりに
movdqaを使っていました。まさかこれが原因じゃあるまいな…

古いバージョンもあると比較しやすいのかな？

【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 6
【10分間のCPU検索の平均速度】 148.50M tripcode/s

とりあえず、戻ったようです。

α6試してみました
条件は>>94と同一です

【10分間の平均速度】 366.80M tripcode/s
【GPU検索の平均速度】 340.25M tripcode/s
【CPU検索の平均速度】 26.55M tripcode/s

α4の水準に戻ったようです
中身的には暫定的にNehalemを検出してα4のプログラムで
処理してる感じでしょうか？
共通プログラムで全CPUを網羅するのは
なかなか難しいのですね

条件は>>99と変わらず、1.1FEα6のみ検索速度(1パターン)を診断

【10分間のCPU検索の平均速度(TPS)】

　　 1.1FEα6 　1.1FEα5 　 1.1FEα4　 1.0.1(安定版)
----------------------------------------------
1)　　31.89M　　　27.84M　　　30.51M　　　31.67M
2)　　31.88M　　　27.80M　　　30.50M　　　31.77M
3)　　31.97M　　　27.69M　　　30.58M　　　31.67M
4)　　31.88M　　　27.85M　　　30.54M　　　31.68M
5)　　31.89M　　　27.83M　　　30.54M　　　31.64M

よかったよかったｗ

修正お疲れ様ですー
明日以降入れとこう…

そろそろ本気だす

ちゃんとNehalemを検出できているようですね。かったよかった。

Nehalemを使っている人(Alpha 5で遅くなった人)は
ぜひこちらも試してみてください。

http://www.meriken2ch.com/files/2013-09-23-Nehalem.zip

元のファイルに上書きすれば使えます。
あくまでも実験なので、元のファイルは取っておいてください

>>125
> そろそろ本気だす

おお、期待してますよｗ

と書いたあとでゆぐちゃんの速度見たら凄いことになってたｗ
うろつきさんもさすがですし、◆QZshizo.ptHさんもおひさしぶりですね〜

これ、こっちにも貼っておこうっと。

> 43 ：◆Meriken//XXX ：sage ：2013/09/24(火) 06:42:26.23
> ゆぐちゃんの紹介のために、今度は日本語版のSlashdotにストーリーを
> 投稿してみました。採用されるように、是非評価を上げてやってくださいｗ
>
> http://slashdot.jp/recent
>
> GPGPUによる分散トリップ検索サービス「Meriken's Tripcode Yggdrasil」
> http://slashdot.jp/submission/52745
http://toro.2ch.net/test/read.cgi/esite/1379214816/43n

>>123
> 中身的には暫定的にNehalemを検出してα4のプログラムで
> 処理してる感じでしょうか？

その通りです。

> 共通プログラムで全CPUを網羅するのは
> なかなか難しいのですね

実際かなり難しいですね。試せる環境が手元にないのが大きいです。
>>126のバージョンでは新しいルーチンに手を入れてるので、
Nehalemでも高速化できるかもしれません。

Yggdrasilで検索中のPC一覧で見ることの出来る「名前」の項目のデータは編集できますか？

お疲れ様です
>>126を試してみました
条件は>>94です

【10分間の平均速度】 370.88M tripcode/s
【GPU検索の平均速度】 340.61M tripcode/s
【CPU検索の平均速度】 30.27M tripcode/s

診断ではCPUの効率向上
実測でもCPU24.54→27.47Mt/sという結果でした

>>132
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!! やっぱりmovapsが原因だったんですね。

他のCPUだとSSE2でmovapsを使ったほうが速いのに、
Nehalemだけmovdqaを使ったほうが速いようです。
こんなの普通わからないっちゅうねん。
なんにせよ助かりました。次の開発版に取り込んでおきます。

>>126でα5からの性能向上を確認
Before
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 5
【10分間のCPU検索の平均速度】 84.98M tripcode/s
After
【Meriken's Tripcode Finderのバージョン】>>126 のNehalem用
【10分間のCPU検索の平均速度】 97.66M tripcode/s

>>131
MTFの「分散処理」タグで編集できますよ。次からはゆぐちゃんスレでお願いします。

【分散トリップ検索】Meriken's Tripcode Yggdrasil
(p)http://toro.2ch.net/test/read.cgi/esite/1379214816/

>>134
ありがとうございます。ようやくこれで安心して寝られますｗ

電気料金の関係で当分稼働できそうにない…
すみません…

On some (but not all) micro-architectures, there are timing differences due to "domain crossing penalties".
For this reason, one should generally use movdqa when the data is being used with integer SSE instructions,
and movaps when the data is being used with floating-point
instructions. For more information on this subject,
consult the Intel Optimization Manual,
or Agner Fog's excellent microarchitecture guide.
Note that these delays are most often associated with register-register moves instead of loads or stores.

だそうな、integerだったらmovqdnなんだと。マニアックすぐるw

>>138
ところがNehalem以外だとintegerでもmovapsのほうが
movdqaよりも速いんですよねえ…
VC++ 2010はマニュアル通りにmovdqaを使ってましたけど、
それだとうまくいかないようです。

>>137
電気料金は大きな壁ですよねえ…
今までお疲れ様でした。またいつでもお越しください。

>>139
何となくですが、
http://2chnull.info/r/jisaku/1326108518/338-354
これの347辺りからの話が、ヒントになりそうな？
これ以上は、各アーキ毎の最適化マニュアルの比較と、
マイクロアーキテクチャ自体の変更情報を全部追わないと、どこがネックになってるのかは
分からない気がするｗ

ちなみに>>107の環境で>>126を回した結果
【10分間のCPU検索の平均速度】 146.58M tripcode/s

あれ・・・あまり変わってない・・・なんでだろ。

>>141
> これ以上は、各アーキ毎の最適化マニュアルの比較と、
> マイクロアーキテクチャ自体の変更情報を全部追わないと、
> どこがネックになってるのかは分からない気がするｗ

リンク先の話は非常に興味深いですねえ。なかなか奥が深いです。

> あれ・・・あまり変わってない・・・なんでだろ。

同じNehalem系でもGulftown(Westmere-EP)は違うのかな?
難しすぎですねｗ

新しい開発版をうｐしました。

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

Alpha 6からの主な変更点は以下の通りです。

・Nehalem系のCPUでの12桁トリップのCPU検索の高速化。
・10桁トリップのCPU検索の高速化。

>>126の成果を取り込んだついでに、10桁トリップ検索でもmovapsを使うように
しました。AVXに対応していない、Nehalem系以外のCPUでは、10桁トリップの
CPU検索は少し速くなっているはずです。
前のバージョンとの速度の比較を報告していただけると助かりますです。

>>143は私(x64+SSE2/AVX、Ivy Bridge)でも10桁が高速化するのでしょうか？

この週末に彼女が日本から遊びに来るので、開発はしばらくお休みです。
次の更新はHaswell購入後のAVX2対応になる予定です。

>>144
Ivy BridgeはAVXに対応しているので今回は速くなりません。
AVX版はまた今度書きなおす予定です。

/.Jから飛んできました。
ちょっと面白そうなのでしばらく回してるかもです・・・

あぁこれって何か。分散のみに参加するって出来ないのね
それはつまらんなぁ。

9文字ぐらいの適当な長いパターンをローカルで1つだけ指定してやれば、
分散のみに参加しているのと変わりないですよ。

Linux版を作っていた◆znjnB.IJwZLUさん、最近見かけないなあ。
忙しいのかしらん。AVXに最適化されたS-Boxをぜひ見せてもらいたかったんだけど、
自分でやったほうが早いのかな。

まあやることといったら全部レジスタで回すようにして、なるべく2バイトのVEX Prefixを
使うようにするだけだからなあ。でも言うのは簡単だけど、実際にやるのは大変そうだorz

定格のi7-3770Kだと10桁トリップのCPU検索の速度はこんなんです。

mty_win_x64_20071012: 21.72M TPS
MTF (AVX): 25.56M TPS

大分速くなったけど、もうちょっといけそうなんだよなあ…

6番目のS-Boxにvmovdqaが6個も残ってるぞ…
まずこいつらからやっつけないと。

vmovdqaを2つに減らすことが出来ましたが、一時変数が1つ増えて
速度は横這いです。難しすぎる…

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 5 -> 1.1 Free Edition Alpha 7
【OS】Windows 7 Professional SP1
【ディスプレイドライバ】320.57

【検索デバイス】GPUとCPU
【使用するGPU】すべて使用
【GPU】GeForve GTX 650
【CPU】Ibtel Core i3-3220 CPU @ 3.30Ghz

【1SMあたりのブロック数(CUDA)】8
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】1
【検索プロセスの優先度】アイドル
【GUIフロントエンドの優先度】アイドル

【トリップの種類】10桁
【キーに使用する文字】ASCII
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 11.49M tripcode/s -> 11.68M tripcode/s
【GPU検索の平均速度】 9.20M tripcode/s -> 9.24M tripcode/s
【CPU検索の平均速度】 2.29M tripcode/s -> 2.44M tripcode/s

>>154
報告有り難うございます。やっぱりちょこっとだけ速くなっていますね。
動的書き換えを行っているコードをいじるのに結構神経を使ったんですが、
6.5%の速度向上だから上出来なのかな?

中間ステートを利用したら受け渡し所がなくても2ch上だけで安全にキーの交換ができるのか

80文字くらいのキーのテスト

なかなか面白い発想ですけど、キーの一部が依頼ごとに違ってくると
複数の依頼を同時に検索することが出来ないので、ちと現実的ではないですねえ。

たしかに個人に依頼する場合はやっぱり一度に一人からの依頼しか処理できなくなりますが、Yggdrasilを使うなら大丈夫ですよね？
Yggdrasilに参加しながら自分の設定した文字列も検索する場合それの結果のキーまで64文字以上になっちゃいますが
あと自分のPCで発見した場合でもサーバから64文字を受け取らないといけなくなります

このときサーバが全クライアントに同じ64文字を使ってたら困るのは
サーバはクライアントごとにキーの最初の64文字を別のにして探索してもらえばよさそうです

あと依頼を1個解決した場合最初の64文字を切り替えないと次に他の依頼を解決したときに2人の別の人に同じ64文字が流出するので
依頼を解決するごとにサーバから新しい最初の64文字を受け取る必要があります

で、OpenCLの1回のワークのまとまりに全部同じ中間状態を最初に渡すことになりそうですが、
1回のワークで複数の依頼を解決しちゃった場合どれか1個しか使えなくなります（同じ最初の64文字が2人以上に使われることになるので）
これの解決法は思いつきませんでした

最初の64文字を依頼人が指定するんじゃなくてYggdrasilがランダムに生成するって方式です

>>158
2ちゃんねる受け渡しを行うのはちょっと無理がありますが、ゆぐちゃんでは
ありでしょう。あ、あと私は最初に間違えてしまっていたのですが、
SHA-1のブロックの長さは64バイトですがメッセージの長さを格納するのに
8バイト必要なので、キーの長さは56文字が最適になります。

実装する際にはW[12]までの途中経過(A, B, C, D, E)を検索開始時に
クライアントに渡してやればいいだけです。最初の依頼を解決した時点で
検索をやり直すようにしてやればセキュリティ上の問題もないでしょう。

条件は>>99と変わらず、1.1FEα7のみ検索速度(1パターン)を診断

【10分間のNehalem系のCPU検索の平均速度(TPS)】

　　　1.1FEα7　 1.1FEα6 　1.1FEα5 　 1.1FEα4　 1.0.1(安定版)
---------------------------------------------------------
1)　　31.47M　　　31.89M　　　27.84M　　　30.51M　　　31.67M
2)　　31.49M　　　31.88M　　　27.80M　　　30.50M　　　31.77M
3)　　31.50M　　　31.97M　　　27.69M　　　30.58M　　　31.67M
4)　　31.48M　　　31.88M　　　27.85M　　　30.54M　　　31.68M
5)　　31.51M　　　31.89M　　　27.83M　　　30.54M　　　31.64M

>>161
Nehalem系でも新しいルーチンの効果に結構差がでますね。
1.0.1に比べて微減なのでまあここらへんが落とし所ですね。
報告していただいて本当に助かりました。

VEX Prefixの謎はstackoverflowで怒られながらヒントを貰って
ある程度解決することが出来ました。

Which AVX registers should I use to avoid 3-byte VEX prefixes?
http://stackoverflow.com/questions/19016174

なるべくソースオペランドにxmm0〜xmm7を使ってやればいいようですが、
それだけではないみたいですね…

----

176 %line 611+1 Source Files\CPU10_x64_AVX.asm
177 000000F0 C5F96FFC vmovdqa xmm7, xmm4
178 %line 611+0 Source Files\CPU10_x64_AVX.asm
179 000000F4 C5D9DFE0 vpandn xmm4, xmm0
180 000000F8 C551EBD2 vpor xmm10, xmm5, xmm2
181 000000FC C569EFE8 vpxor xmm13, xmm2, xmm0
182 00000100 C551EFDF vpxor xmm11, xmm5, xmm7
183 00000104 C559EFF3 vpxor xmm14, xmm4, xmm3
184 00000108 C44111DFE3 vpandn xmm12, xmm13, xmm11
185 0000010D C44111DBEA vpand xmm13, xmm10
186 00000112 C521EFFA vpxor xmm15, xmm11, xmm2
187 00000116 C511EFC3 vpxor xmm8, xmm13, xmm3
188 0000011A C44109DFC8 vpandn xmm9, xmm14, xmm8
189 0000011F C511EBED vpor xmm13, xmm5
190 00000123 C5D1EBE8 vpor xmm5, xmm0
191 00000127 C539DFC7 vpandn xmm8, xmm7
192 0000012B C44101DFFE vpandn xmm15, xmm14
193 00000130 C44111EFEF vpxor xmm13, xmm15
194 00000135 C4C151EBF5 vpor xmm6, xmm5, xmm13
195 0000013A C5D1DFEB vpandn xmm5, xmm3

コードの動的書き換えまでやってるんだ。頑張るなぁ

>>164
速くするためにできることは全部やるつもりですｗ
10桁トリップのCPU検索だと2〜3M TPS違ってくるので、かなり大きいです。

3オペランドの命令を2-byte VEX Prefixになるように
書き換えたら遅くなったぞ。なぜだ…

うーん、やっぱりわからん…
まあいいや、また今度にしよっと。

290Xが噂通りの性能なら、検索君1号の6990をリプレースしたいところですが、
どうなんでしょうねえ〜

AMD，新世代GPUシリーズ「Radeon R9」「Radeon R7」を発表
http://www.4gamer.net/games/234/G023455/20130926001/

>>168
絶対に値段がヤバそう、かと思いましたがそれほどでもないのかな＞R9 280X(のメーカー想定売価)は299ドル

AMDがMantleとかいう新しいLow Level APIも発表したが
使えるのグラフィック用途だけなのかな

>>151
お久しぶりです。
日々の仕事をこなしつつトリップ検索のための正規表現エンジンのためのJITコンパイラを作るという作業にエタってました。

DESのS-Boxですがmovdqaが２個あるくらいなら速度差は出ないでしょう。
AVXでターゲットをSandy以降とする場合、ベクタ整数Logicは3op/cycleです。
従って速度を稼ぐには常に3命令を供給できるようにコードを書かなければなりません。
命令フェッチが16Byte/cycle、デコードが4op/cycleなので2ByteVEX（レジスタ間で4Byte）、3ByteVEX（レジスタ間で5Byte）
のどちらでも達成可能ですし、数個のメモリオペレーションはOoOのキューで隠蔽されます。
ただし、メモリオペレーションを含む場合はLodeポートが2本、Storeポートが１本で命令長が多くの場合4Byteほど長くなることを意識する必要があります。
これはメモリオペレーションを含む論理演算は2ByteVEXの場合で2op/cycle、3ByteVEXの場合は1op/cycleしか命令を供給できないということですので、
間にレジスタ間演算を入れて供給命令数を維持するかループにしてuOPキャッシュを当て込むか、そういうものだと諦めるかしなければなりません。

2ByteVEXにすること自体は簡単で、VEX prefixのフォーマットを見るとわかりますが
AVXop　dist，src1，src2
という場合src2をxmm0〜xmm7に制限するだけです。
distとsrc1にはxmm0〜xmm15までの全てのレジスタを指定可能です。
まあ、レジスタ割付は面倒になります。

>>171
なるほど、そういう頭が必要なんですね。道理でなかなか速くならなかったわけだ。
実に勉強になりますです。

> 日々の仕事をこなしつつトリップ検索のための正規表現エンジンのための
> JITコンパイラを作るという作業にエタってました。

MTFの正規表現のルーチンもC#で綺麗に書きなおそうと考えてたんですけど、
この発想は斬新ですねｗ 流石です。

>>170
Mantleからだと直接GCNを叩けるみたいですね。
オープンソースになるという噂もあるみたいです。
GCNは性能的に化物としか言い様がないので、ｗｋｔｋが止まらないですｗ

>>172
maleで拙作のavxDESを送ったので時間があれば見てみてください。
あまり参考にならないかもしれませんが

>>174
トリわすれてました

>>174-175
わざわざ有り難うございます。さっきまで送っていただいた
S-BoxをMTFに実際に組み込んで動かしていたんですが、確かに速くなっていますね。
素晴らしい出来です。

　 ｀¨ −　､　　　　　＿_　　　　　 _,. -‐' ¨´
　　　　　　| ｀Tｰて＿,＿｀　`ー<^ヽ
Meriken　.|　 !　　　　　　｀ヽ　　 ヽ ヽ znjnB
　　　　　 r　/　　　　　　ヽ　 ヽ　　_Lj
　､　　　 /´ ＼　　　　 ＼　＼_j／ヽ
　　｀ ー　　　ヽｲ⌒r-､ヽ ヽ__j´　　　｀¨´
　　　　　　　　　 ￣ー┴'^´

maleで送ったとか・・・






ｱｯｰ!!!

>>176
何の説明もなく失礼しました。
cryptのつくりが全く違うのにすんなり対応されて流石です。

拙作ではS-Boxの最適化は>>171で述べた通りですが、cryptに関しては
キャッシュの最適化を目論んだつくりになっています。
MTFではkey[56]をexpandedKeySchedule[0x300]に展開していますが、
expandedKeySchedule[0x300]で12kBのL1Dキャッシュを占有します。
これはハイパースレッディングで2スレッド走らせる場合、L2キャッシュへのアクセスが生じると
大きなペナルティになりえます。
それでなくても12kB分のstoreはコストが高いのです。
というわけでkeySchedulは命令のほうに展開しています。

最終転置とblock初期化もcrypt関数内に隠蔽してあります。
従ってcrypt関数にはblock[64]をわたして、帰ってきたのをそのまま使えます。

saltはMTFと同じ手法で0x7FFFFFFFがシグネチャになっているのでここを変えればそのまま使えると思います。

>>187
mailだった

>>179
> これはハイパースレッディングで2スレッド走らせる場合、
> L2キャッシュへのアクセスが生じると大きなペナルティになりえます。

ああなるほど、それでL1Dキャッシュが潰れて遅くなっていたんですね。
前スレでスレッドの数ごとに速度の比較を行われていたのにも合点がいきました。

KSを命令のほうで展開するやり方はOpenCL版では使っていたんですが、
CPUでは試していませんでした。ただ、STFの展開の仕方は随分独特で
スッキリしているように見えます。できることはまだまだたくさんありますねえ。
明日から1週間ほど家を空けるので、AVX2版の実装と一緒に試してみます。
いや〜、楽しみだなあ。

よくわかっていないのですが、MTFでの検索パターンとのマッチング処理ってどういう風になっているのかな
１トリップ生成する毎にマッチング処理ですか？

MERIKENさんの彼女って美人さんかな

400年生きてるけど容姿は14歳くらいの
押しかけ女房という設定でよろしくお願いします

MERIKENさんのOpenCLのカーネルを参考に作ったら

MTFで900MHash/s出るGPUで590MHash/s出せた

900M目指す

と思ったら900Mは簡単に出せた

ただしキーの判定がA,B,C,D,EのAが0かどうか、だけですが

MERIKENさんのカーネルすごいなー

>>183
ロリババアじゃねえか……最高だな

質問です
自分が見つけたトリップのキーが既に割れているかどうか調べる方法ってあります?
トリップでググってみたけど出てこなかった

◆WWmMMmWmmM
◆mmmmMMWmmM

ぐぐって出てこないなら割れてないんじゃないかな
キーが割れてるか調べるならキーでぐぐれば良いかと
別キー同トリは酉でぐぐってみるしかないですねぇ

あとはデータベース調べるくらい？
ttp://trip2ch.net/

例の流出騒動で割れた(けどネット上でまだ使われていない)人もいるしなぁ……
俺のように

自分が見つけた、ということなので未使用前提のレスなのら
自分が使ってないなら誰かが先に見つけて、晒したり使用したりしていない限り
割れていることはないからね

別キー同トリって、ハッシュの衝突ということだよね？
SHA-1ってそんなに衝突起きてたっけ？

>>189-191
個人で使うこんな感じで↑一般的なものなら神経質にはなりませんが、
最長や最短のように変わったトリップは他にも使っている可能性もあるので、
調べてみようと思いました
データベースとグーグルを活用したいと思います

ありがとうです　m(_　_)m

12Mt/s程度のPCには8完9完はきついです
見つかる気がしませんw

>>193
8完程度なら他の人が見つけてくれることもあるよ
それがクラスターの良いところ

＃今日は気温が上がってしまったので落ちまくりｗ

>>192
SHA-1をBASE64にした先頭12文字らしいから、
160bitのうち6bit×12文字で72bitしか使わない計算だからねぇ…
有効空間で309485009821345068724781056分の1、かな。
誕生日のパラドックスで衝突率を求めると…どうなるんだ？

>>194
なるほど
確かに分散処理が出来ましたね

金さえあれば3Way CFXしてブン回せるのに…うぐぐ

あなたは10桁トリップを発見しました。プラチナ貨8192枚が支払われます。 (19時間前)

文字数がないということは特殊なトリップかな？

あなたは8文字一致の10桁トリップを発見しました。プラチナ貨4096枚が支払われます。 (3ヶ月前)
あなたは9文字一致の10桁トリップを発見しました。プラチナ貨262144枚が支払われます。 (3ヶ月前)

8文字超、9文字未満の報酬ね

妙な質問ですが、
http://tripcode.net/yggdrasil/screensaver.php
って1920x1200に最適化しているんですか？
HTML Screensaverで表示させると12桁トリップのグラフと上位数名のリストしか表示されませんorz
(1366x768のノートパソコンでの話)

>>199
893 ： ◆Meriken//XXX ：2013/09/08(日) 07:55:22.82 ID:9LBqP7z/0 (2/2)
スクリーンセーバー用のページを新しいグラフに合わせて変更してみました。
これでPCの台数が増えてもしばらくは安心です。相変わらず1920x1080専用です。

http://tripcode.net/yggdrasil/screensaver.php

スクリーンセーバーはこちらがお勧めです。

HTML Screensaver
http://myweb.tiscali.co.uk/djmclean/htmlscreensaver.html

>>198
過去ログにも出てるけどそれは準10連を見つけた場合の報酬
純10連だと6815744枚もらえるらしい

ところで昨日10/2の11:00頃に12桁のmaxが66.3G TPSになってるのは一体…

どっかの大学か専門学校あたり教室から誰か遊んだのかなｗ

>>202
まあでもグラフを見る限りでは50GTPSは上がってるしな……
一台あたり100MTPSでも500台は牛耳らないとああはならないはず

バグである可能性もあるが

>>203
そういうところだとPXEブートしてたりする。
PXEサーバへの線を切って起動後即アプリ起動するイメージ持ったPXEサーバを設置すれば、
後は片っ端から電源入れるだけで利用できるから、100台くらいは案外乗っ取れるかと。
あとはGPUの相性次第？

>>204
参加者の中でばかっ速いのはほんの数人、実質Merikenさんだけで半分以上稼いでるようなもんだけどｗ
うちの１年くらい前の普及価格帯GTX660ですら、開発版MTFならGPUのみ単体でも400Mtpsくらいでるから
ちょっといいグラボ乗せていそうなところだったら教室1つで行けそうな気がするよｗ

1人で数百台所有してる方も見かけますし、あながち団体とも言い切れないのがおそろしいところｗ
案外、海外の方とかもありえる？

>>201
なるほどなるほどー
使うためには将来実装されるフリマ？バザー？で買い戻すしかないのかな？
しかし見つけたトリップが何かわからないからそれもかなわないのだけど…

そういえば有償版は"参加しない"設定はあるけど"参加するけどトリップは提供しない"設定は無理なのかしら？
依頼と手元の検索対象が被った場合に、手元を優先して提供しないみたいな

今は丁度留守だけど
ユグドラの機能絡みの話はあっちのスレでやった方が話題を共有できるしMerikenさんもノリやすいと思うよーｗ

AMD Catalyst? Display Driver for Windows Vista 32-bit って、最新版は 13.4 なんですか？
検索しても、13.10 が見つからない・・・

ようやくアリゾナへの小旅行から戻ってきました。
セドナっていうインディアンの古い聖地に行ってきたんですけど、
岩山が並ぶ景観が素晴らしかったです。
地元の人達も面白い方が多かったので、またぜひ行ってみたいですねえ。

>>183-184
彼女はころっとしてて愛嬌のある感じです。
無事に日本に辿り着ければいいんですが…

MERIKENさんおかえり！！

おかえりー!行ってみたいなぁ…

>>210
> 無事に日本に辿り着ければいいんですが…
ヒッチハイクで帰国したとか？？

どもどもｗ

>>213
彼女、ロスの空港で1人で乗り継ぎだったんですけど、
英語が殆どできないんですよね… まあ大丈夫だとは思いますが。

>>184
検索エンジンのソースコードはGPLで公開されているので、
じゃんじゃん使ってやって下さいｗ

>>197
電気代は盲点でしたね〜
私ももうちょっとお金があったら専用電源を備えたPC専用の部屋が
欲しいところですけど、先は長いですねえ。

>>207
これどうしようかかなり迷ったんですけど、
参加していただく以上は条件を揃えておきたかったので
こんな風になっています。

誰も怒らねえからまんどくさいのでと正直に言えよw

60A契約だと不足気味になるから、75Aにしようかと思ったりしたり。

R9 290Xがもう少しで発売ですね。いや〜、楽しみだなあ。

しかし旅行から帰ってきたら2chの規制が更に厳しくなっていますね。
忍法帳のレベルを上げないとリンクも貼れないとか、どうかしてます。
海外規制は相変わらずだし、流出事件以降VPNも規制されて、
●で規制を回避できなくなっちゃったし…
これで公式p2も海外規制されたらどうしようかしらん。

てすと

>>218
実装自体は判定の処理の順番を入れ替えるだけなので、
そんなにめんどくさくないですｗ
経験値は非常に重要な指標なので、
を獲得するための条件は同じにしておきたいんですよね。

>>219
いいですね〜 ほんとに検索速度の限界は電気の供給によって決まってきますね。

半導体プロセスが28nmから20nmになったら同じ電力で倍の速度出せるようになるかな

さすがにそこまではいかないでしょうけど、
確実にワットあたりの性能は上がるでしょうね。
R9 290Xが7970と比べてどれぐらい性能が上がっているのか、
非常に気になるところです。

>>180の続きですが、STFのS-Boxを使わせていただいた結果、
速度は26.05M TPSまで上がりました。>>151の数字より確実に
良くなっていますが、key scheduleを命令のほうに展開してやれば
更に速くなりそうです。取りあえずMTFのルーチンで展開を試してみてから
送っていただいたSTFのルーチンを移植してみることにします。

現在せっせAVXのルーチンを書き換え中。
動的書き換えを行っているルーチンを修正するのは結構大変です。
うまくいくかな〜

ttp://www.fileformat.info/tool/hash.htm?hex=1dc72653c09d8eb383671d18bcca2d02470a3c6b43ea547bafb69c4227188498

ビットコインのクライアントのRPCを使ってブロックのハッシュ値を列挙して連続する0のビットが一番多いハッシュを探した後、

ビットコインのハッシュはSHA256(SHA256(key))なのでブロックのヘッダをblockexplorerで持ってきて
SHA256(header)を計算して　1dc72653c09d8eb383671d18bcca2d02470a3c6b43ea547bafb69c4227188498　を出して

これをHEX表示としたバイナリのSHA256ハッシュが実際に00が連続することを確認した

ちなみに73ビット0が連続する　もし2chのトリップのSHA1で72ビット以上0が連続したら12連の"AAAAAAAAAAAA"になる

でもBitcoinは先頭と末尾が逆だった(連続する0ビットの位置の）

特にエラーも出てないのに、GPU 検索が止まってる事があるけど、
エラーが出ないので情報を提供出来ない・・・

お、Merikenさんおかえりなさい。

>>220
2ch書き込み規制等の場合は、したらばのMerikenさんの掲示板の辺りへ移動かな？
でも、したらばって12桁トリップ使えないんでしたっけ？う〜ん…

>>230
環境や状況等を詳しく書いた方がいいかも。

>>230
こういう場合はまずハードウェアがらみなんですけど、
エラー処理を見なおしたほうがいいかもしれませんね。
ハードウェアの構成を教えていただけると助かります。

7970の場合だと90℃を超えた辺りで不安定領域
95℃まで行ったらまずGPUが脱落する
保護回路かな？
動作保証のあるメーカー品でも強烈な連続負荷が掛かるので油断出来ない

>>231
緊急時にはとりあえずしたらばに移動ですね。
2ちゃんねるVPNを使えば海外規制は回避できるんですが、
有料だし不便なのでできれば避けたいところです。

とうとう4770とM6Eをポチってしまいました。
これで思う存分AVX2をいじれます。ぐへへへへ…

私はFX-9370をポチってしまいました
TDP200Wゴクリｗ

AMDのCPUもきちんと書いてやれば>>67のようにちゃんと速度が出ますしね。
何より独立したコアが8個あるのは魅力的です。楽しみですね〜

1日かけてAVXのルーチンのkey scheduleをコードに展開してみました。
で、うまく動いたのは良かったのですが、速度はかえって落ちてしまいましたorz
やはりSTFみたいにDES crypt(3)の二種類のラウンドを畳み込んでやらないと
今度はコードがキャッシュから溢れてしまうようです。

最近のCPUは投機的実行したりパイプライン深かったりだから、
アセンブラレベルでの高速化って大変そうだな。

確かにかなり難しいですねえ。畳み込みも試してみましたが、それでも書き換え前の
速度には届きませんでした。アセンブラのルーチンはほとんどSTFと
おなじになってしまったので、>>179で教えていただいたとおりに
やってるはずなのに速くならないのはかなり謎です。

まあいいや、また今度STFのルーチンを試してみようっと。
そうすれば少なくとも問題の切り分けはできるはず…

>>235
おぉ、遂にですね。
アマゾンで購入する時には極力ゆぐ経由で注文していたのですが、少しは足しになりましたかね?

M6Eの一番下のPCIeに、2若しくは1.5スロット幅のカードが刺さるかどうか教えて下さい。
Z87 Extreme 9を使っているのですが、一番下のPCIeはスイッチケーブル等が干渉して水枕付きの7990が刺さらないのです。

>>242
確実に足しになっていますよ。ありがとうございます。
写真を見る限りでは干渉するようですが、一応届いたら確認してみます。
検索君1号でも干渉しているのですが、R.O.G.シリーズのマザボは
電源ボタンが別に付いているので私は普段はそれを使っています。

あれからいろいろ実験してみたのですが、>>179のようにL1Dキャッシュを
有効活用するためにはキー生成とヒット判定のルーチンに相当手を入れないことが
いけないことが分かりました。◆znjnB.IJwZLUさんはかなり色々工夫されているようです。

まあでも原因がわかったので、取りあえずこの件は置いておくことにして、
AVX2対応の準備を勧めることにします。

着々と高速化されていて期待する日々
ちょっとだけぶん回す

熱と電気代の壁を乗り越えて頑張ってください

熱はこれからの季節ではともかく電気代の壁には参っております，いつ脱落してもおかしくない‥‥

電気代のほうが深刻です
1〜2時間フル稼働が限界かも

ラスボス：電気代

ハイエンドのグラボを2枚使って24時間稼働させると
電気代は月10000円前後なのでたしかに痛い出費ですねえ。
長い目で見たら1枚だけ使って電気代を抑えたほうがいいのかもしれません。
7970 1枚だけでも現在のゆぐちゃんでは十分トップクラスですしね。
私としては無理の無い範囲で長く続けていただきたいところです。

嫌な感じだな。

そこまでして・・

まあもともと本格的なトリップ検索にはお金がかかりますしね。
他にもっとお金のかかる趣味なんていくらでもあるし、
人の趣味にケチを付けるのは無粋というものです。

GPU を使う場合はともかく、最近の CPU は一杯コアがあるし、
PC の電源が入っている間は、一部のコアでずーっと検索させてても
全く何の問題もないよね。
２つ位コア開けておけば、通常の使用に影響出ないし。

まあだからこその、分散処理なんですよね。
自分一人で1垓のトリップの中から好きなトリップ1個を探し出すのにかかる電気代と、
50人で1垓のトリップの中から好きなトリップをそれぞれ探し出すのにかかる電気代では、
単純計算で前者の50分の1の電気代で済むわけですからね。
皆で協力する事で必要経費も人数分の一に分散出来て、それでいて人数分の一の時間で必要なものも見つけられる。
お互いが得する大変良い仕組みだと思います。
開発頑張って下さい。

ところで、検索は完全にランダムにやってるんだと思うけど、何故か、頻繁に見つかるトリップと、
全く、一切、全然、ちっとも見つからないトリップがあって、かなり偏るんだよね。不思議だ。

>>255
短い回数だと乱数が偏ったように見えることはよくあること

ところで、前にも聞きましたが、この状態だと検索時間が16倍速なんですよね？
ttp://up3.viploader.net/net/src/vlnet016276.png

16・倍・速！ 16・倍・速！

>>256
なんか妙に台数が増えてた時間があったのはYSRKENさんだったんですねｗ

> この状態だと検索時間が16倍速なんですよね？

違います。同時に何台稼働しても検索時間は一緒です。

>>258
なん、だと……！？

まあこのキャプ撮りたいがために16台を一時的に乗っ取ったのですがｗ

>>254
分散トリップ検索は長い間あたためてきたアイディアなので、
実現できて結構嬉しいですｗ トリップ検索はパターンの数が増えても
速度は急に落ちないので、実に分散処理向きといえます。

17時前後の青グラフと"max: 31"があなたの仕業ですかー！
ttp://up3.viploader.net/net/src/vlnet016277.png

>>261
そうでーすｗ

トライして気がついたのですが、これってWeb上では同じ「4MTPS」でも、
ソートする際は小数点以下も含めているんですか？

>>262
そうですよ。

>>263
良かったです。このソフトでは小数点以下を切り捨てているわけじゃなかったんだね！

今日あたりHaswellが届いているはずだけど、ちょっと見に行ってみるか。

>>256
> 短い回数だと乱数が偏ったように見えることはよくあること
いや２４時間３６５日検索してるんだけど・・・

ロト7を毎週1年買っても当たらないようなものです

>>266
トリップってA-Za-zの26*2文字＋0-9の10文字＋./の2文字＝64文字で構成されているんだろ？
12桁ならそれが64＾12のパターン数、64^12=(2^6)^12=2＾72=(2^10)^7.2≒(10＾3）^7.2=10^21.6
10垓(ガイ)=Z(ゼタ)の単位の数の中から、ちょっと取り出した程度で偏りが無くなるわけないじゃないか。
例え1京(ケイ)=10P(ペタ)パターンのトリップを発見したとしても、それは全体の万分の一以下の数でしかない。

>>255
もうちょっと具体的に書いてもらえれば詳しいことがわかると思いますよ。
MTFのバグという可能性もありますしね。

例えば9桁完全一致トリップが欲しいとして、
12桁で検索するのと10桁で検索するのでは、
どちらが確率が高いのでしょうか？

>>270
確率は同じだが普通は前者の方が高速に検索できるからお勧め
ユーYggdrasil に依頼しちゃいなYO

ゆぐちゃんの実績から言っても12桁ですよねー

ttp://tripcode.net/yggdrasil/
平均検索時間(12桁):13.9日(9文字)
平均検索時間(10桁):1.4ヶ月(9文字)

YSRKENさん、ときどき名無しで書き込んでますね。

Haswellが届いたことは確認済みなので、これから取ってきます。
今日はちょっと用事があるので組み立ては明日あたりかな。

>>273
えっと、はいそうです。とは言っても、
「専ブラでコテハン記憶しているはずなのになぜか消えてて面倒になった」
というのが主な理由ですが。
>>274
遂にMerikenさんがHaswellに挑戦するんですね……ﾄﾞｷﾄﾞｷ

>>275
そうですか。まあ何事もほどほどに、ね。

>>270
12桁の方がトリップ生成速度が格段にはやいし（環境によるけど）、なんだか12桁ってあんまり「安全」じゃないような気がしてきた‥‥

>>277
前方数文字が同じで「ぱっと見で似ている」トリップ探すなら12桁の方が危険かもしれないけれど、
完全一致なら空間的にも時間的にも12桁の方が安全性は高いと思うよ。
検索速度が何倍で、トリップ数が何倍か計算してみよう。
トリップ数ではなく使用可能な鍵空間で計算してみても良い。

あーでも捻ってないからレインボーテーブル的なアプローチには弱いかも。

検索速度は12桁のほうが数倍速いですけど、10桁トリップのキー空間の狭さを考えたら
12桁トリップのほうがはるかに安全ですよ。12桁トリップの数は2^72個ですけど、
10桁トリップはキーが56bitだから最大で2^56個しかありません。
キーがShift-JISの場合はさらに少なくなります。

>>378
2^34TPS (≒16G TPS)で検索しても12桁トリップをすべて出すには
最低で2^38秒(≒87世紀)かかるのでまあ大丈夫でしょう。

>>280は>>278さん宛でした。

確かに鍵空間的に2^16 違うのであれば、不安がる根拠はありませんね、いろいろ教えていただきありがとうございます

時代は12桁

>>278
>前方数文字が同じで「ぱっと見で似ている」トリップ探すなら12桁の方が危険かもしれない
前に「いや先頭合ってるだけで誤解されかねないからそれはそれでマズい」って声があったような……
でもまあ完全一致や全桁対象の酉（例：全数、二構）だと10桁の方が断然見つけやすいんですけどね

>>283
そのかわりきれいなトリップは10桁のほうが断然出しやすいですけどね。
一長一短といったところです。

>>285
10桁酉の場合、最後に使える文字が16種類しかないってのが
きれいな酉を探すにはネックになるかもしれないですけどねｗ

>>286
でも12桁で最後まで揃っているトリップを出すのは至難の業ですからねえ。
もうちょっと速度を向上させたいところです。

Haswellちゃんが届いたのでさっさと検索君1号にインストールしてしまうことに
しました。マザボとCPUを交換してから試しに立ち上げてみたら平然と動いていますw
OSを再インストールしなくていいのには助かりました。うまく行けば今日中に終わるかな。

試しにi7-4770で10桁トリップのCPU検索を動かしてみましたが、
定格の3770Kよりちょびっと遅いぐらいです。
しかしなぜか3枚目の7970が認識されません。むぐぐ…

システムもイマイチ安定しなかったので結局OSを再インストール
することにしました。やっぱりサボろうとするといけませんねえ。

>>251
keyword: 浪漫

男のマロン

中々
ttp://www.youtube.com/watch?v=_rzNFvJIF28
良い歌だよね。

8bit機が現役でどんどん新作でていた頃　はっきりしないけど25年も昔だろうか・・ｗ
HDDが20Mで20万とかした記憶があるｗ
1Tあたりに換算すると100億くらいか・・

今のHDDは1Tあたり4000円程度
容量単価で250万分の1くらいｗ

12桁トリップ全保存計画を実行しようとすると
2^72の空間でキーとトリップのペアが24バイト
2^72*24

2^40が1Tで、その1000億倍くらいｗ　4,000,000,000,000,000 ＝4000兆円
日本の国家予算の10倍くらいかなｗ
でも容量単価が250万分の1になれば・・・

2^40 * 2^32 * 24
100,000,000,000 / 2,500,000 = 1,000,000/25 = 40,000 今の1Tハードディスク4万個分くらいの予算
4000*40000=1億6千万円

25年後　1億6千万円分のHDD容量で12桁のキーとトリップのペアを全部保存できる？
計算合ってるかな？
どこかの自治体のプロジェクト予算って感じか・・・ｗ

さらに25年後　250万分の1の値段になると
160,000,000 / 2,500,000 = 1600 / 25 = 64円　ｗｗｗ

２ちゃんねるが出来てから、既に14年たっているんだよねー
月日が立つのは速いｗ

リアルではかなえられないような夢や冒険に憧れる気持ちを込めて、
「男のロマン」などということもあります

>>294

＞2^40が1Tで、その1000億倍くらいｗ　4,000,000,000,000,000 ＝4000兆円

ここで桁間違えているな　400兆円だな
そうすると、25年後は1600万円か

物好きな小金持ちの年寄りでも出来ないことはない感じか・・・ｗ

でも、保存しようにも計算が追っつかない気が……真面目に計算してないからよく分からないけど

ずっと前にどこかで似たような話を見たと思ったら
http://anago.2ch.net/test/read.cgi/software/1205766220/529
だった

>>297
現状では、検索パターンに指定したパターン以外は全て捨てて
新たにパターンを探す時は最初から検索しなおしているわけだけど
保存計画は、計算済みのトリップをかたっぱしから保存していくので
計算済みのトリップならばデーターベースに検索命令入れるだけで1発で取り出せることｗ

とはいえ、高速ループで生成し続けるトリップを、生成する速度で未保存トリップか否かをチェックして未保存なら保存していく処理はスタンドアロンでは難しそう
こういうことにこそ、分散処理が威力を発揮しそうですよね

分散処理でトリップ範囲を分担し
ループで計算しながら、挿入ソートでメモリ展開しつつ、担当範囲の分担PCに計算済みトリップを分配していく



>>298
既出の話題でしたか＾＾；

結構夢があっていいですねー
SSDがもっと早くなってかつ低価格化すれば実現可能性は十分あります
現状のネックである消費電力と速度を打開してくれるのがSSDですから　価格面ならHDDですけど

>>294>>296
そこでレインボーテーブルのアプローチですよ。
始点トリップ+終点トリップで72*2/8=18byte
長さ2^20(1MTrip)で(2^72/2^20)*18=72PiB
トリップの頭20bit=0(平均長さ1M)を終点にして残りをオフセットとして読めば
始点トリップ=9byteで9*2^(72-20)=36PiB
1Tあたり4000円で計算するなら1億4745万6000円
20MTPSくらいは出てるようだし平均1分の1GTPSを目標にすれば
始点トリップ=9byteで9*2^(72-30)=36TiB
1Tあたり4000円で計算するなら144万4000円……うん、中々現実的な範囲じゃない？

テーブル作成に掛かる時間は普通に全トリップ計算に掛かる時間(…を超える？)なので、そっちで死にますがｗｗ

>>301
む〜ん、レインボーテーブルが理解できない＞＜
ウィキペディアみてみたけどちんぷんかんぷんでした＞＜

1回総当りでテーブル作るって事はわかるんだけど
なんでその時作ったテーブルが、別のハッシュから結果を取り出すことに使えるのか想像できないｗ

そこでつまづくから、その先の容量削減とかチェイン化とかちんぷんかんぷん
（っていうか、微積とか行列とかの記号出てくると、そっちでお手上げｗ）

トリップと遂になるハッシュ値を保存して行く時に、トリップ12桁全部をDBに保存せずにトリップ最初4文字でソート＋ハッシュで保存していくとか？
残り8文字はDBから取り出したハッシュ群から計算して探す。12桁の残り8文字一致だけなら結構速く計算出来ると思う。
そうすると1トリップに付き8文字分データを減らせる。

>>303
あーーっｗ
言われてみれば、トリップは保存しないでもアドレスから一意に決まる事に出来ますね
ディスクは半分で済みそうです

トリップから一意に決まるアドレス位置に　そのトリップを計算するのに使ったキーを保存していけばいいのね

ああ、更に削る方法もあるかな？
例えば最初1文字までにして、2文字目は大文字か小文字か数字か記号で4パターン(00：01：10：11の2ビット)に分ける。
更に3文字目も同じく分ける。更に4文字目も…
そうやってトリップを区分分けする事で、残りの文字列のパターンを分類し、探すハッシュの数を絞っていくとか？

>>305
トリップ　◆AAAAAAAAAAAA のトリップキーはアドレス0に保存
トリップ　◆AAAAAAAAAAAB のトリップキーはアドレス1に

こんな感じで、トリップから一意に決まる保存アドレスにキーだけを保存していく感じで良さそうｗ

>>302
自分も全容や応用までは把握はできてないのですが…
まずH(key)→hashなハッシュ関数(SHA-1関数の先頭72bit)と、C(hash)→keyな変換関数(仮にBASE64関数)を準備。
適当な始点hashから「H(C(hash))→hash」を複数回チェインして終点hashを得るってのを沢山やって終点hash→始点hashのテーブルを作って保存しておく。
検索時は「H(C(hash))→hash」な処理を延々繰り返して、記録済みの終点hashと一致するまで検索を続ける。
一致する終点hashを見つけたら対応する始点hashから「H(C(hash))→hash」を繰り返して、H(C(hash))が目標と一致したらそのときのC(hash)が目的の値。
…ってのがレインボーテーブルの概要だったはずです。終点hash→始点hashのペア情報だけでチェイン回数分のハッシュを代用できるのが利点ですね。

C(H())チェインがキレイに全ハッシュ空間が一周するC()を組めれば繰り返し長を固定して探索時間の保障が出来ますが、
H(C())の鎖が短い繰り返しで一周してしまう部分とかをテーブルに含ませる(または検索時にループを発見する)必要もあり、
C()の出力鍵空間内でH()が衝突すると鍵空間＜ハッシュ空間になって全てのハッシュを網羅できなくなる問題もあり、
その辺の工夫とかが多分レインボーテーブルのキモになるところだった筈です。
ハッシュ衝突とかは…異なるC()を使ったテーブルで補完するとかでしたっけ。

>>304
ちな301で書いた「トリップの頭20bit=0(平均長さ1M)を終点にして残りをオフセット」ってのもそれです。
↑に書いてるC(H())チェインが短くて頭20bit=0等が出ないと悲しい事になりますorz…ケチらず72TiB使うべきか。
>>305
単純にハッシュの頭nbitを削るだけでも行けそうですね。

>>306
似たようなことコンテストの重複チェックルーチンでやったー懐い
FDDの物理アドレスだからエラーになったらおしまいという綱渡り・・・若かった
脇からすまそ

>>308
まぁ何もOSのFAT管理を無視してトラックセクタ直指定するわけでも
ましてやトラックのギャップにデーター入れるわけでも（笑）ないので
単に、巨大なデータファイル（別に単一ファイルじゃなく適当な大きさのファイル郡でいいのですが）に
先頭からのオフセットで位置を決定するっていうだけなのでｗ
トリップ文字列からキーの保存オフセットに変換する関数を１つ用意するだけで
知りたいトリップのキーを保存するオフセットアドレスをトリップから直接得ることが出来るですよｗ

盛り上がってますね〜
私はいまだに検索君1号の調整中です。
これ、ちゃんと使えるようになるのかな…

MTFを起動しようとするとatimpag.sysでBSOD(0x00000116)が発生。
やっぱGPUが5個もあるのがいけないのかなあ。弱った弱った。

いろいろいじってたらいつの間にか動くようになりましたｗ
後は微調整だけど、取りあえず動作確認は出来たので一安心です。

何て贅沢で羨ましい悩み。ｗ

さすがにちょっとやり過ぎかもしれませんｗ
あれからまた安定しなくなったのでもっと調整が必要なようです。
実に難しいですねえ。

おはようございます
いい感じに設定作業が進んでいそうですねー

Linux版の予定ってありますか？

>>315
いやあ、それが結局あれから全然安定しなくて、とりあえず
7970をはずしちゃいました。残念なことにM6Eだと5GPU以上だと
安定しないようです。これまで使ってたCrosshair V Formula-Zが
特別だったのかもしれません。

ちょうどAVX2の次はGCNのアセンブラに取り組もうと考えてたので、
7970は開発機に移してしまうことにします。GCN版はかなりの長丁場になりそうなので、
まあ妥当なところでしょう。

>>316
私自身がLinux版を作ることはないで〜す。

7970を外してもまだ調子が悪いので、今度は7990だけにしてみました。
6990が原因だとまだ助かるんだけど、マザボの初期不良というのだけは勘弁して欲しいなあ。

皆様お疲れ様です

すいませんが質問させて頂きます
トリップの回文と双連の違いは何でしょうか？

宜しくお願いします。

回文 abcdeffedcba
双連 aabbccddeeff

現時点で12桁トリップ全てを保存するのは非現実的ってのはわかったけれど
現実問題として、計算しながら、計算した分をどんどん保存していくということを考えた場合どうなるのか・・・

現時点でユグが調子いい時で20GTpsくらいかな
1年スパンで考えた場合

20G=2^30*20
1年＝311万秒≒2^20*3
(2^30*20)*(2^20*3) = 2^50*60

とりあえず計算しやすいってことと、速度増加見込みってことで4倍の速度　80GTpsを見込めると仮定して
2^50*2^6 = 2^56

80GTpsで1年間ぶん回すと2^16 T = 65536Tのトリップを生成


うーん、分散処理で実現するには容量以外にもネットワーク負荷の事や
>>294の用に全空間分容量のHDDに記録していくわけじゃないので
ハッシュインデックス化する必要があり、それを記録分担する仕組みを考えるとか
色々課題はあるものの
1年で65536T*12 のトリップキー容量とハッシュインデックス化に必要なインデックス容量考えただけで
現時点ではまだ厳しそうですね・・・ｗ

HDDに1か所保存とか分散だと失われる可能性高そう

1キーでも失われたらそれを再びみつけるのはものすごく大変だろうなー

>>321
分かりやすい説明
ありがとうございますm(_ _)m

せっかく買ったM6Eですが、カードの選り好みが非常に激しく
なかなか性能を出せません。とりあえずうまく動いた7990と7970の
組み合わせで10桁トリップ検索専用にしておきました。
まあもともと種類の違うグラボを挿すこと自体かなり特殊なのですが、
この展開は完全に予想外です。やっぱり実際にやってみないとわかりませんねえ。

まあいいや。今後どうするかはAVX2版の開発が終わってから考えようっと。

>>325
ご愁傷様です。
私も同じZ87チップセットですが、7990とTITANx2の混在で何も問題無くさくっと動きました。
謎ですねぇ。グラボと配線が干渉するので、これ以上追加して試すことは出来ません。

しかし、7990+TITANx2より7990+7970の方が速いって・・・。

Maxwell世代でMTFでもGeForceがRadeonに逆転したりしなんですかね

>>327
7990を一番上のスロットに挿さないとまともに動かないし、
これまで使っていたPCIeの延長ケーブルとM6Eの相性も良くないようです。
AMDのドライバも最新のものでないと動きませんでした。不思議なもんです。

そうか、M6Eは開発機にまわして、検索君1号はこれまで通りでもいいのか。
時間かかるけどそうしよっかな。

今調べたら電源のPCie用のケーブルの端子の先が少し溶けてました。
どうも不安定だった原因の一部はこれにあるようです。
やっぱり無茶させすぎですね。新しいのを注文することにします。
これでうまく行けばかなりおいしいけどどうかな〜

>>327
>>328
現在CUDA版の10桁トリップ検索のボトルネックになっているのは共有メモリの量なので、
これが増えない限りは速度は上がらないはずです。TITAN用に書き直せば
もちろん話は別ですが…

電源のPCIe用のケーブルを開発機から持ってきて取り付けたら
ようやく検索君1号が12桁トリップ検索でも安定して動くようになりました。
7990を一番上に乗っけているので見た目は前よりさらにやばくなりましたが、
前より冷えるようになったので速度は上がっています。
これで心置きなくAVX2対応の作業を始められます。

あれからまた不安定になったので、今度は7990+6990+6990の組み合わせを
試してみましたが、今までで一番安定して動いています。
M6Eはなるべくビデオカードの種類を揃えてやると安定して動作するようです。
すんなり動かなくてエライ目に遭いましたが、もう大丈夫でしょう。

コネクタが溶けるとかどんだけｗ

http://www.eurogamer.net/articles/digitalfoundry-radeon-hd-7990-review

凶器ですねｗ

7990は化物ですｗ 空冷だと12桁トリップ検索で本気を出しきれないのが
残念ですが…

AVX2対応のためにコードを見直してたのですが、
12桁トリップ検索はすぐに対応できそうです。楽しみだな〜

自作なんてしたのも、もう遥か昔のことで最近のPC事情とか、全然ついていけない話になっているのですがｗ
「グラボ」にメモリ６Gってなんじゃそりゃｗｗｗ　って感じですよｗ

Powercolor HD 7990 Devil 13 6 GB
ttp://www.techpowerup.com/reviews/Powercolor/HD_7990_Devil_13/25.html
ttp://tpucdn.com/reviews/Powercolor/HD_7990_Devil_13/images/power_maximum.gif
最大消費電力551W　(； ･`д･´)…ｺﾞｸﾘ

もはや電子レンジクラス

>>341
なるほど、つまり電子レンジで中のものを温めながら、同時にファンで中のものが熱くならないよう冷やしているのがHD7990なんだね。
拷問の域だな…(;´д`)

暖めながら冷やすって言ったって
空冷だろうと水冷だろうとたとえ油冷であってもｗ
換気するか冷房でもしない限り、冷ました熱は全て部屋にたまるわけでして・・・

1年中強力ハロゲンヒーター部屋の中で動かしてるようなものですよねｗ

液体窒素の中に沈めて冷却する選択肢

>>342
自分で言っててアレだが、レンジとかオーブンって1000W↑が普通だからちょっと違うかも
(ハロゲンヒーターとか電気ポットとかの方が近い)

その辺の冷蔵庫で250kWhぐらい(一日700Wh)だからそれより断然金が掛かるって……

>>343
6990も2枚あるから、ヒーターは3台ですｗ
7990はともかく、6990のうるさいのなんのって…

いや、だから同じですってｗ
クーラーだって、室外機を部屋に持ち込めば、コンプレッサ動かしている分立派な暖房ですしｗ
冷蔵庫が部屋の中にあれば、冷蔵庫の中身は冷えても部屋の温度は上がるしｗ
液体窒素だって、液体窒素自体を冷やす装置が室内にあったら、冷やしたい部分を効果的に冷やす事はできても
部屋全体の温度はどんどんあがって・・・ｗ

>>345
検索君1号だけで1300W超えてますｗ

あｗ　>>347は　>>344にですｗ

とりあえずAVX2を検知するルーチンを追加しました。
まあ時間はたっぷりあるのでのんびりやることにします。

冷蔵庫inで、検索。

もういっそ、豪快にアメリカらしくガレージに検索君を置いて、水冷モーターは排水ポンプ用のを使って、ラジエーターは自宅のプールに沈めるのが良いのかもね…
日本なら逆にエコを意識して、発熱で発電をしてその電気で冷却をする装置を開発し、電気代を節約とか。
普通のPCの発熱程度じゃ無理でも、それぐらいの消費電力になれば流石にいくらか還元は出来ないものか？
何か良い発電装置のアイデア無いですか？

冷蔵庫in、検索してみたら想像してたのと全然違ったｗ


冷蔵庫搭載PC
http://weekly.ascii.jp/elem/000/000/093/93313/
http://weekly.ascii.jp/elem/000/000/093/93292/120610_com_omoshirocaseimg09_cs1e1_1000x.jpg

とか
冷蔵庫の中にマザー入れちゃって冷やすやつとか

そーいうのを想像してたのに、最近流行りのアレだったのね・・・ｗ

新生検索君1号大勝利！！！！！

>>347
とりあえず最終的な廃熱を室内空気じゃなくて外気に捨てるところからですね。
>>352
温度差で発電すると発電機が熱抵抗になっちゃいますからねぇ…
温度差発電による稼動効率補助つきDCの噂は聞いたことありますが、
発電電力による冷媒循環での効率上昇が発電の熱抵抗を上回れるかどうか。
>>353
冷蔵庫/冷凍庫は温度差が稼げるだけで熱交換速度が遅いから、
断熱性のお陰で逆に蒸し風呂になるってアレですねｗｗ

664 ：名無しさん？ [↓] ：2013/10/11(金) 23:58:53.30 ID:???
AMD Catalyst 13.11 Beta Driver for Windows
http://support.amd.com/en-us/kb-articles/Pages/latest-catalyst-windows-beta.aspx

>>356
15日に発表のR9 290Xは対応カードの一覧には入っていませんね。
発表の日が楽しみです。

とりあえずAVX2で12桁トリップ検索を動かしてみました。
CPU(i7-4770)だけで209M TPS出てます。

http://www.meriken2ch.com/files/2013-10-11-AVX2-1.png

ただ、リテールクーラーでは冷却が追いつかないようで、
しばらくしたらCPUがスロットルダウンして速度が下がってしまいました。

http://www.meriken2ch.com/files/2013-10-11-AVX2-2.png

まあでも実際に倍近い速度が出せたのでまずまずの成果と言っていいでしょう。

>>358
CUI画面がすごく懐かしく感じる……あれ、
無料版でもCUI実行で検索できましたっけ？

>>359
出来ませんよ。開発用に有効にしてるだけです。

32bit AVX2版も作ってみたのですが、こっちでは検索開始直後に
230M TPS出ています。かなり謎です。キャッシュの使い方とか、
OoO向けの最適化とか、工夫の余地はまだ大分ありそうです。

5970x2ですがやっぱりデバイス判定に時々失敗します．
再現性をみるのにどこから手をつけたらいいですか？

CPUのクロック周波数を3.5GHzまで落としたらようやく熱ダレを起こさなくなりました。
速度はこんなかんじです。

64bit版: 186.84M TPS
32bit版: 209.06M TPS

同じ条件でのDayトリッパーの速度は次になります。

DayTripper2101: 154M TPS

MTFはかなりの速度を出しているのですが、
64bit版のほうが32bit版より遅いことの説明がつきません。
やっぱりCで書いたルーチンを見なおした方がいいのかな…

>>362
それはおかしいですね。とりあえず開発版のMerikensTripcodeEngine.exeを
動かして、デバイス判定の失敗したときに"OPENCL DEVICE"の"Name"の部分に
何が表示されているか調べてみて下さい。ドライバのバグの可能性が高いので、
ドライバを変えてみるのもいいと思います。

64bit版が遅くなっていた理由がわかりました。
yasmのビルトインマクロであるsave_xmm128が
vmovdqaではなくmovdqaを使っていました。
まったく、油断も隙もあったものではありませんｗ
これで速度差は妥当なものになりました。やれやれです。

64bit版: 211.96M TPS
32bit版: 209.06M TPS

キャッシュに乗りやすいようにテーブルの一部を関数ローカルにコピーしてやったら、
それだけで2〜4M TPSほど速度が上がりました。結構まだ工夫の余地がありますねえ。

64bit版: 216.11M TPS
32bit版: 210.78M TPS

>>353
VAX Barで通った道なのに今更感が強いですね、これ

>>352
一軒家に住んでたら間違いなく検索君1号はガレージ行きですねw
自室に置いているのは、我ながら正気の沙汰ではありません。
冬に暖房が全く必要ないのは助かりますが…

>>366
お疲れ様です。
同じCPUで定格(3.7GHz)だと約120MTPSなので、ほぼ倍のスピードが出ていますね。
水冷だとサーマルスロットリングは起きないだろうから、楽しみです。

>>367
VAXを知らない畑にいたわけじゃないけど
直接端末に触れた事はほとんどない・・・
ただ、あいつがあるコンピュータルームってのは肌寒くてねぇ・・・ｗ

触れたこともほとんどないから、VAX Barなるものもはじめて聞いたんだけどググってみたよｗ
感想は、メリケン野郎の考えることはクレイジーだぜｗ　って感じｗ

メリケンさんに引っ掛けたけど、別に罵倒でも卑称でもないのであしからずですｗ
っていうか、メリケンさんの名前　ハンドルはその意味から取ってて、今住んでるのもソッチのほうなんだろうけど日本人ですよね？

VAX って、VAX/VMS の事？？
それなら懐かしいな・・・

>>371
ですですｗ

今更なことですが、検索文字列がヒットしたら、該当する依頼を無効にする
(ゆぐちゃんではなくローカルでの話)機能って付けられますかね？

グラボごとの速度をまとめたWikiとかってどっかにありますか？

ローマ字っぽい４文字を適当に作ってみる正規表現の超適当版
^[KSTNHMRGZDBP][aiueo]([kstnhmrgbp][aiueo]){3}/
こんな感じで検索回してみたものの・・・


確かにローマ字なんだけど、まともな単語が出来る確率の低さにがっかりｗ

>>375
昔、ローマ字のみで意味が通るトリップを生成するための正規表現を自作したことがある
1文字の類(母音)、2文字の類(母音以外の1文字カナ)、3文字の類(拗音を含む類)を
長さが12桁(or10桁)になるように並べたデータをプログラム組んで用意して、
patterns.txtに書き込んで回したもんだ……展開が物凄いことになったがな！

で、上に出ている酉がその成果の一つだったり……

>>374
データの蓄積自体は相当量ありますが、なにせアップグレードでガンガン速度向上しますもので……
このスレだけ見ると、
「HD6990+HD7970+HD7990≒11.1GTPS」(>>3、Ver.0.10)
「HD6850≒805MTPS」(>>19,Ver.1.1FEα2)
「HD 5570/5670≒340MTPS」(>>94,Ver.1.1FEα5)
「GTX660≒536MTPS」(>>98,Ver1.1FEα4)
「GTX650≒207MTPS」(>>101,Ver1.1FEα5)
「GeForce610M≒64.3MTPS」(>>114,Ver1.1FEα5)←参考記録
「GTX650≒9.24MTPS」(>>154,Ver1.1FEα7)←！？
といった感じですかね。他は前スレを当たることをお勧めします

>>377
> 「GTX650≒9.24MTPS」(>>154,Ver1.1FEα7)←！？
これは10桁ですよ

>>378
あ、本当だﾃﾍｯ

>>377
グラボ、ドライバ、バージョン、設定値・・・手集計はミスが怖いし、
ゆぐちゃんでグラボと速度の情報とって公開してくれたら面白そう

>>370
日本人ですよ〜

10桁トリップ検索のAVX2への対応がなかなかうまく行きません。
ぐぬぬぬぬ…

一応AVX2対応の10桁トリップ検索のルーチンは動くようになったのですが、
なかなか思ったような速度が出てくれません。

AVX(8スレッド): 23.95M TPS
AVX2(8スレッド): 37.98M TPS
AVX2(4スレッド): 35.09M TPS

まあそれなりに速くはなっているのですが、L1Dキャッシュが潰れているみたいで、
倍の速度にはなりませんでした。ちなみに8スレッドから4スレッドにても
あまり速度は落ちていません。やはりキャッシュの使い方を工夫するしかないですねえ。

>>376
10桁の方はまだマシなんですが、12桁だと特に
ちょっと無茶なパターンを作ると、すぐに展開サイズがシャレにならない事になって
MTFで検索開始しても、パターンを展開中・・・　まではまだ何とか動いても
そのあとのパターンを処理中で帰ってこなくなってｗ
帰ってきても、なぜかその後のユグと通信に失敗して何分後に再通信しますとなって、その時間になると展開から再開になって繰り返すのよねｗ
なんかエラーのアラート窓が出た時もあったな・・ｗ　10秒くらいでその窓消えちゃったから内容確認できなかったけど・・ｗ

まぁそんな感じで、パターンは展開後のサイズがあんまりでかくなり過ぎないように気をつけているのと
パターン定義の入力欄、一応長い定義も書き込めるみたいだけど入力窓あんまり大きくないし、どうせ表示も表示窓の横幅までだから
あんまり複雑な定義もなーって思ってたけど
patterns.txtに直接かーｗ
patterns.txt　って、相当長くなってしまってもしっかり読み込んでくれるのかな（使用可能なメモリの上限チェックとかもろもろ、そういう処理コミコミで）
というか、上記のエラーとか不安定だったのはグラボのメモリの制限なのかなって、自分のグラボを今更ながらみてみたら2Gもメモリあるのね・・・ｗ
7990が6Gも積んでて信じられんとおもったけど、2Gでも十分に信じられないレベルだったｗ

閑話休題

古い人間なもので、「グラフィックシステム」でユーザープログラムを動かす　なんていうと
FM-7のグラフィックサブシステムにYAMAUCHIコマンドで数バイトの共有メモリを使ってプログラムを転送して・・・ｗ
なんてイメージが湧いてきちゃうのですよｗ（「YAMAUTIコマンド」はググると出てくるはずｗ）

とはいえ、今のグラボにユーザー処理させるってのも、やっぱり転送して走らせるとかするのでしょうね
動かすプログラムは・・・・・・・むむっ・・・ｗ　うーん、スレみてるとアセンブラに置き換える話がでてきてるのはわかるんだけど
GPUに対応したコード吐くコンパイラとかあるって事なのか・・


うーん、我ながら話が飛びまくったわけのわからんレスに・・・ｗ

>>384
昔書いた展開用コードを引っ張りだしてみました。
まず、ローマ字でカナを表現すると、
・アルファベット1文字　([aiueo]|n)
・アルファベット2文字　([kstnhmyrwgzjdbp][aiueo]|sh[aiuo]|ts[aiuo]|ch[aiuo]|fu|oh)
・アルファベット3文字　([kstnhmrwgzjdbp]y[aiueo]|kwa|gwa)
となります。流石にこのままだとハズレ率が半端なくなるので、実際には
[aiueon]と([kstnhmr][aiueo]|y[auo])と[kstnhmr]y[auo]に限定していましたが。
後は「3322」「13231」など長さ「のみ」記述したデータをループ回しで全生成し、
数字部分を上記正規表現文字列に置換すれは完成です。
ちなみに今適当に回したら10桁用で1760行ありました……。

まあこれですらハズレまくるのは目に見えている(感覚としては砂金採りに近い)ので、
あらかじめ豚辞書(フリーの単語リスト)データから「文字の組み合わせ」情報を抽出し、
それに当てはまらないような文字列(日本語っぽくならなさそうなもの)を弾くコードを別に書いて篩に掛けました。
最終的には、ヒットした結果の文字列ファイルを用意すると、
ワンクリックでかな変換→篩に掛けて出力までしてくれるようなものまで作った思い出があります。

結論：HSP様々。なんならお手軽検索キットでも送りましょうか？ｗ

皆さん私が考えてもみなかったような使い方をされてますね。
かなり新鮮ですｗ

キャッシュを潰さないためにお蔵入りになったルーチンを引っ張り出してきました。
AVXだけだと微妙に遅くなるのですが、このさい文句はいってられません。
これをAVX2で書き直せばそれなりの性能が出るはずです。

>>385
ローマ字じゃなく
英文生成もどきみたいなのも、ちょっと考えてみようとしたんですけどねｗ

(名詞A|名詞B|名詞C)(動詞A|動詞B|動詞C)(名詞D|名詞E|名詞F) とか
適当な構文と品詞の組み合わせで・・・ｗ

そんな風に考えたんだけど、既に検索中の正規表現だけでも
たとえば
^i[il][il][iIl][iIl][iIl][iIl][iIl][iIl][il][il]i$　とか
^[.]*[vwW]+[.]*$　　とか
これでもあんまりサイズがでかくなり過ぎないようにセーブしながら作ってはいるんだけど
それでも地味に容量食うパターンが大量にあって気軽にパターンを増やせない状況になってて英作文正規表現はおあずけ中ですｗ

>>387
Haswell導入おめでとうございます。

DESですが私のほうではあのcryptをそのまま256bit化して素直に倍の50MTPS出てます。
まあもともと256bit化したときにキャッシュに乗り切るようにあんな構造にしたので。

それよりもSHA-1で躓いてます。
アセンブラで書いてみたのはいいんですがハイパースレッディングがある状況ではあまり恩恵がありません。
イントリで書いてコンパイラに投げても同じ速度が出ます。
まあ、HT切るとスレッドあたり3MTPS差が付くんですが、HTがあると実行ポートを埋めきってしまえるみたで
107MTPSあたりで頭打ちになります。

アセンブラのほうは一週間かけてバイトコードと睨めっこしながら手動パイプライン化までしたのに・・・泣。

>>372
> ですですｗ
あれって、何かバッチファイル的な言語があったよね。
あれで擬似ログアウト画面を作って、色んな人のユーザ名とパスワードを集めまくった思い出が・・・
VAX/VMS 上でのクロス開発はかなりやったので、本当に懐かしいわ。

:::::::::::.:　.:. . ∧＿∧ . . . .: :::::::: 　 　 引っ張りだしたコードを元に、自動生成した
:::::::: :.: . .　/彡ミ゛ヽ;)ヽ、. ::: : ::　　　patterns.txtを食わせてみたらメモリ不足で落ちた……
::::::: :.: . . / :::/:: ヽ、ヽ、i . .:: :.: :::.　　ttp://up3.viploader.net/desktop/src/vldesk007817.jpg
￣￣￣（_,ノ ￣￣ヽ､_ノ￣.　　　　　左のタイマは検索実行と同時な。4GBほどメモリ食ってから
　　　　　　　　 　 　 　 　 　 　 　 　 落ちたことからして、よほど工夫しないと検索不可能かもorz

参考までにpatterns.txtをば：http://www1.axfc.net/u/3057287.txt

>>390
フィッシング詐欺の手法のハシリみたいなかんじですなｗ
今となっては、セキュリティとかパスワードとか、色々そういう考え方が社会的に認知されてきたりしているけど
そもそも一般の人は銀行の暗証番号以外、パスワードで何かを守るなんてこと自体がなかったような時代だし
根本的に考え方が違ってた気がしますねぇｗ

>>391
いろいろと酷い

>>391
展開後のパターンじゃなく、途中まで展開した正規表現群みたいな感じですねｗ
12桁でこれを全パターンやったら、そりゃキますわｗ
[AIUEO]{12} これだけでも　約2^28 ですよｗ
これに加えて、1文字目から12文字目まで母音が入るパターンまで加えたらそりゃ大変なことにｗ

>>391
壁紙が気になる・・・

>>394
>[AIUEO]{12} これだけでも　約2^28 ですよｗ
一応、元々のコードでは「母音か拗音組が三連続したら弾く」というルーチンが
含まれていたので、そいつを組み込んだら行数が半分以下に。ただ、それでも
メモリ食い過ぎで検索できないのは変わらず。念のため、

[aiueo][aiueon][kstnhmr][aiueo][aiueon][aiueon][kstnhmr][aiueo][kstnhmr][aiueo]

だけ書き込んで回してみると、展開に4分ほど掛かった末にメモリを720MBほど消費しましたｗ
そりゃ無理ゲーだわ、と言うか確か最初に作った時(今年の1月始め)は待て屋で回してたような……

「ロリ・義母
ンデレ・孕ま

>>395
http://www.pixiv.net/member_illust.php?mode=medium&illust_id=12189369
ですね。
>>397
勘違いしないでよね！　全体のフォルダ名は
「ロリ・義母・ツンデレ・孕ませ・寝取られ･･･すべての萌えは源氏物語が産んだ！」
http://blog.livedoor.jp/geek/archives/50949346.html
なんだから！！

:::::::::::.:　.:. . ∧＿∧ . . . .: :::::::: 　 　 ちなみに、>>396で書いたパターンを待て屋で回したら
:::::::: :.: . .　/彡ミ゛ヽ;)ヽ、. ::: : ::　　　メモリ消費量僅か5MB……現実は非情である
::::::: :.: . . / :::/:: ヽ、ヽ、i . .:: :.: :::.
￣￣￣（_,ノ ￣￣ヽ､_ノ￣

待て屋ってソース公開されてたっけ？
それなら、メモリ消費の少ないその方法を採用してみるとか。

>>400
自分は　ずっと前のトリッパーをちょこちょこ使っていた程度で、待てやとかも使ったことはないんですが
ただ、展開するから高速にマッチ出来るんじゃないかと思うｗ
このスレの過去ログとかほとんど見てないけど、初期はパターン数制限あったのがある時期に制限がなくなったってのが

たぶんその時に、パターンを展開して（おそらくはマッチする法のトリップも相当数メモリに展開してからまとめて）
アルゴリズム検索（２分検索みたいな？）を取り入れたんじゃないかと予想

メモリ展開して最適化するからこその、大量検索パターンを高速にマッチできてるんだと思いますよｗ

一応、パターン作成＋結果からトリップ抽出＋ローマ字変換＋篩い掛けできるセットを配布しておきます。
ソースコードも添付しますので、参考までにどうぞ。

ttp://www1.axfc.net/u/3057797.zip

あ、私はID:KYI8bH6i0です。

>>391
>>> 正規表現の場合、展開数で制限を設ける方式ですか？
>> おおまかに言えばそうですね。
>> 厳密に言えばハッシュ値の数で決まります。
> http://toro.2ch.net/test/read.cgi/esite/1379214816/100-101
なんかもう全部展開しちゃってる感じ？

>>401
先にメモリに展開する場合、展開したテーブルがキャッシュやメモリから溢れると思いっきりロスしそう。
展開数が一定範囲を超えたら正規表現とのマッチ処理をJITするのが最速なのかな・・・

MTFではパターンの一部(5文字)からハッシュ値を作成していて、
ハッシュ値の生成に必要な分は最初に全て展開しています。
この方法だと非常に強力な正規表現が使える代わりに
メモリの消費量は大きいです。

正規表現の部分は2年前に作ってからほとんどいじっていないので
改善の余地がかなりあります。待て屋のマッチングのアルゴリズムは
かなり特殊なのですが、これについては鳥屋氏にいろいろ教えて
いただいたので、ぜひMTFに取り込みたいところです。

>>369
どもども。10桁トリップ検索のAVX2対応の作業がおわったら新しい開発版を
うｐするのでお楽しみに。

>>389
> まあもともと256bit化したときにキャッシュに乗り切るようにあんな構造にしたので。

なるほど、そういうことだったんですね。流石です。

> 107MTPSあたりで頭打ちになります。

これはおかしいですねえ。ちょっとMTFがどうなってるか調べてみます。

10桁トリップのAVX2対応のルーチンがようやく動きました。

AVX(8スレッド): 23.65M TPS
AVX2(8スレッド): 43.44M TPS
AVX2(4スレッド): 39.04M TPS

>>383よりだいぶましになりました。
CPUを定格に戻せば48.40M TPS出る計算です。
HTの効きは今ひとつなので、まだキャッシュの使い方に
改善の余地がありそうです。
あとは最終転置やキー生成の処理の見直しですね。

>>389
12桁トリップ検索はこんな感じです。速度が出ないのはなかなか謎ですねえ。

AVX(8スレッド): 117.31M TPS
AVX2(8スレッド): 215.71M TPS
AVX2(4スレッド): 184.12M TPS

キー生成のルーチンを見なおして、10桁トリップ検索の速度が
少し上がりました。

AVX2(8スレッド): 43.44M TPS -> 46.02M TPS

定格で51.28M TPS相当なので、まずまずといったところでしょう。
もうちょっと搾り取れそうな気もしますが、かなり疲れたので
取りあえず休憩することにします。

しかしこうなるときちんと定格で動かしてみたくなりますねえ。
これ買ってHaswellと7990を一緒に冷やそうかしらん。

http://koolance.com/ex2-755-exos-2-v2-liquid-cooling-system-aluminum

>>411
120x2では7990フルパワーの発熱を受けきれないと思います。
4770K+7990+TITANx2では、120x5でギリギリ耐えきれませんでした。発熱の大半は、7990のはずです。
今120x7にして何とか12桁検索も定格で出来る状態です。

あと出来ればKOOLANCEは避けた方が良いかと。

この様な出来合の物は、今の所簡易型(≒おもちゃ)しか有りません。
GPGPU用途で耐えられる様な物は、自分でパーツを買い集めて組み立てるしか有りません。
幸い米国だとパーツの入手性は日本よりずっと良いので、お勧めです・・・というか羨ましい(笑)。

ポンプ、ラジエータ、ヘッダーをホースで繋いで車やバイクのクーラントを流すだけです。簡単ですよ!

なるほどなるほど。もうちょっとまじめに考えた方がよさそうですねえ。
こういうのが出来合いであればいいんですけど…

http://i11.photobucket.com/albums/a190/Fuganater987/DIY%20Radiator%20Stand/DSC02337.jpg
http://www.techpowerup.com/forums/showthread.php?t=166624

もういっそこっちにしたら？
ttp://akiba-pc.watch.impress.co.jp/docs/news/news/20131008_618673.html
ttp://shop.aquacomputer.de/product_info.php?products_id=2965
ttp://shop.aquacomputer.de/product_info.php?products_id=2725

AVX2対応が終わったつもりでいたんですが、10桁トリップ検索の32bit版がまだでしたｗ
一応作っておきますが、Haswellで32bit版を使う人なんているのかしらん。

>>415
お金があったら間違いなくそれを買っていますｗ

>>405
全部展開しているわけじゃないんですねー


なんで５文字なんだろうって、なんとなしにぐぐりながら、
「はー、ソースの名前についてたshaとか生成アルゴリズムの名前なのね」とか
その先まで追ってみようと思ったけど、もう頭がついていかなくなってるや　ざんねんｗ

ハッシュが5文字なのは、トリップの一文字が6bitで表せるので、
5文字だと30bitになって32bitワードに収まるからです。

ソースはある程度予備知識がないとちょっと追うのは厳しいかもしれません。
昔Knuth先生のLiterary Programmingを読んで非常に面白いなと思ったんですけど、
いつかあんな形でソースコードの解説を書きたいですね。

Knuth先生のはLiterate Programmingでした。

10桁トリップ検索の32bit AVX2版もえいやっと作ってしまいました。
AVX版の8割増の速度で動いているので、まあいいことにしておきます。
今日はここまでにして、明日以降にひと通りテストして新しい開発版を用意する予定です。

>>415
650EURなら安いじゃないと思ったけど、今円安でしたね・・・ってそう言う問題じゃ無い(笑)。

>>414
出来合には期待できませんね。ニッチすぎて市場規模が小さすぎます。
そこまで細かい所まで自作しなくても大まかなパーツなら有るので、自分で組み立てるしか!
ttp://www.performance-pcs.com/catalog/index.php?main_page=product_info&products_id=36764
ttp://www.performance-pcs.com/catalog/index.php?main_page=product_info&products_id=33261

>>402の更新版です。
・ローマ字文生成用パターン作成ソフト
・検索結果からトリップのみを抽出するソフト
・文字列をローマ字変換するソフト
・文字列を文字列長・文字コードでソートするソフト
・平仮名を篩に掛けるソフト(旧版とMecab利用の改良版)
・検索結果を利用して、検索ワードを自動削除するソフト
(通常の大量検索用)
・普通の単語リストを検索タゲ用に整形するソフト

以上のソフトの袋詰めです。
http://www1.axfc.net/u/3058958.zip

>>422
なかなか良さげなパーツですねえ。もうちょっといろいろ調べてみます。

>>423
YSRKENさん、前にも言ったと思いますが自作のプログラムの話は
よそでお願いします。

空回り間凄いし空気読めよとは思うけど、
いちおうMTF用ユーティリティらしいし、スレチかっていうと微妙な気が

この手の話もほどほどなら一向に構わないんですけど、
延々とひっぱられるのはちょっと…

了解しました。しばらくROMります。

そこまでする必要はないですけど、前にもこういうことがあったので、
気をつけていただけると助かります。

ソフト開発できる人全員を尊敬します

水冷のパーツ、やっぱり結構高いですねえ。
取りあえずCPUだけで試してみようかな。

関係ないけど、磯のいい石さんってアクアリウムが趣味？

>>432
いや、意味が繋がる中で一番面白そうなものを挙げただけです。
他に「◆IENOHUKUYA」「◆MENMASENSI」などをストックしています。

>>433
なるほど　了解ですｗ

メンマ戦士www

やだーメンマ戦士のほうが面白いじゃないですかー

メンマ先生はちょっと面白いですねｗ

とうとう水冷用のパーツをポチってしまいました。
取りあえずCPU用だけですが、ラジエーターとポンプは
よさげなのを買ったのでうまくいったらグラボ用の水枕を
追加する予定です。当面の生活費がちと心配ですが、
まあなんとかなるでしょうｗ

>>438
遂に逝かれましたか。GPGPUでフル回転させるには避けて通れない道なので頑張って下さい。
水冷は高価ですがパーツの流用が効きますので、後々無駄にはなりません。
12桁検索を回した時、水温が上がりすぎてリザーバーの内圧が上がり、リザーバーが裂けてしまいました。
安定するまではリザーバーの内圧を逃がす様にしておいた方が無難です。
リザーバーに圧力逃がし弁を付けるのが確実ですが、蓋を緩めておくだけでもとりあえずは十分だと思います。

宜しければどんなパーツを選んだのか教えて下さい。私は以下のパーツです。
ポンプ: Laing D5
リザーバ: Bitspower円筒タイプ
ラジエータ: EK CoolStream 120x4, Black Ice Xtreme III 120x3
CPU: Alphacool NexXxoS XPI Light
GPU: EK (TITAN & 7990)

R9 290の温度が公開されていました。
ttp://videocardz.com/images/2013/10/R9-290X-baidu-1.png

コア温度が90℃を超えているとするとVRMは一体何度なのか・・・怖くて想像出来ません。
Fire Strikeでこの温度だと、空冷で12桁検索検索は絶望的ですね。

メンマ戦士がそこまでウケるとは……
>>440
き、きききき93度Σ(ﾟдﾟ`)・・・!?
それでなぜ壊れないんですかっ！？

R9 290Xは温度の耐久性が上がったと考えていいのか?
いずれにせよ水冷パーツ出るまで待機

Xeon W5590x2 Geforce GTX TITAN, Geforce GTX 690
でやってみました。電源がヤバイですw
【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 7
【1SMあたりのブロック数(CUDA)】自動
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】自動
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 2243.59M tripcode/s
【GPU検索の平均速度】2133.68M tripcode/s
【CPU検索の平均速度】 109.91M tripcode/s

冷却関連・・
よくわかってないんだけども・・・

外付けラジエターだけ単体で買って、水冷のシステムに繋いでしまうってことなのだろうか

外部のラジエターにつなぐなら、車の廃品ラジエターとかではダメなのだろうか・・ｗ
っていうか、筐体開いて扇風機が最強な気も・・ｗ

水冷用のパーツはこんなんです。とりあえずファンは9個注文しました。
これで7990もちゃんと冷えてくれるといいんですけどね〜
18個のファンはあまり想像したくありませんｗ

ポンプ: Alphacool VPP655 Variable Speed Pump - HF Top Edition - Acylic
リザーバ: EK-MultiOption RES X3 250
ラジエータ: Phobya G-Changer XTREME Nova 1080 120x9
CPU: EK Supremacy Universal CPU Liquid Cooling Block - Plexi

>>443
なかなか頑張ってますねｗ
「1SMあたりのブロック数」を128か192に設定するともうちょっと速くなりますよ。
それにしてもこれだとかなり電源には厳しいでしょうねえ。
うちでも電源に結構無理をさせているのでちと心配です。

>>441
93度だったら7970でもギリギリ大丈夫です。
6990なら100度でも普通に動きますよ。

>>444
市販の「冷却のシステム」に碌な物が無いので、「冷却のパーツ」を買ってきて自分で組み立てるしか無いのです。
ラジエータに車の物を流用するのは有りです。実際にやっている人も居ます。
ラジエータと冷却系のホースを繋げるフィッティングを自作できて、尚且つ巨大なラジエータを置く場所が確保できるならお勧めです。
私も一時期本気で解体屋から買ってこようかと悩みました。

MTFレベルでGPGPUをぶん回すと、幾ら裸扇風機でも冷却が間に合いません。
冷媒が気体と液体では熱伝達率が全然違いますから。

>>445
情報ありがとうございます。
Techpowerupのアレにかなり影響を受けていますね(笑)。大は小を兼ねますから、ラジに奮発するのは良いと思います。
EKのCPUブロックは今までダメだったけど新型は違うと聞きました。組み上がったら効果の程を聞かせて下さい。

まあGPUの配線だってリフローでやるのを考えれば
100度程度で壊れたら全滅ですしね

気温はどんどん下がっているのに何て熱いスレだ！

AVX2対応版の配布パッケージを準備中。
やっぱり10桁トリップのCPU検索で50M TPS近く出ると
テンションが上りますねｗ
はやく定格で動かしてみたいな〜

>>448
もちろんですｗ 将来的にはぜひ6990の爆音ファンx2とも
おさらばしたいところです。

新しい開発版をうｐしました。

Meriken's Tripcode Finder 1.1 Free Edition Alpha 8
http://www.meriken2ch.com/programming/merikens-tripcode-finder

Alpha 7からの主な変更点は以下の通りです。

・AVX2対応によるCPU検索の大幅な高速化。

前のバージョンとの速度の比較を報告していただけると助かります。

試してみました。

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 8
【OS】Windows 7 Ultimate SP1 64bit
【検索デバイス】CPUのみ
【CPU】Core i7 4770K
【CPU検索スレッドの数】8
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個
【その他】水冷

【トリップの種類】10桁
【CPUの命令セット】x64 + SSE2/AVX → x64 + SSE2/AVX/AVX2
【10分間のCPU検索の平均速度】 24.97M → 47.87M tripcode/s
【CPUの温度】45〜51℃ → 46〜54℃

【トリップの種類】12桁
【CPUの命令セット】x64 + SSE2/AVX → x64 + SSE2/AVX/AVX2
【10分間のCPU検索の平均速度】 122.06M → 224.74M tripcode/s
【CPUの温度】43〜50℃ → 45〜53℃

8〜9割増しですね。ここまで速くなると、十分CPUも戦力になります。
AVX2の発熱が大きいですが、水冷だと問題ありません。

>>450
GTPS級の猛者になると暖房要らずだそうで……

冬に暖房がいらない熱源がある部屋の夏・・・　恐ろしいｗ

そんなPC組んでみたい…

欲しかったトリップを見つけていただきました
ありがとうございます

さっそくですが試してみましたので貼り

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 7　→　Alpha 8

【検索デバイス】GPUとCPU
【使用するCPU】Intel Core i7-3770 CPU @ 3.40GHz
【使用するGPU】NVIDIA GeForce GTX 660 (CUDA)

【1SMあたりのブロック数(CUDA)】自動
【CPUの命令セット】x64 + SSE2/AVX
【CPU検索スレッドの数】自動
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 616.58M tripcode/s → 633.56M tripcode/s
【GPU検索の平均速度】 515.53M tripcode/s → 534.46M tripcode/s
【CPU検索の平均速度】 101.06M tripcode/s → 99.10M tripcode/s

しばらく再起動かけてないからかちょっと不安定だったかもしれません
参考までに前回測ったAlpha7の数値>>98

ごめんなさい>>98はAlpha5でした
でもあまり速度は変わってない気がします

12桁検索をフルパワーで実行すると、消費電力が1200W前後。電源容量が1200W・・・。
やばいです。
部屋の窓を全開にしても、風が無いと室温があっという間に30℃を超えます。

電気代は見なかったことに。

1.1FEα8+AVX2圧倒的大勝利！！！！！

私もテストしてみました。Ivy世代なのに性能が微妙に上がっているのはなんでだろう……

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 7　→　Alpha 8

【検索デバイス】GPUとCPU
【使用するCPU】Intel Core i7-3770 CPU @ 3.40GHz
【使用するGPU】NVIDIA GeForce GTX 660 (CUDA)

【1SMあたりのブロック数(CUDA)】256
【CPUの命令セット】x64 + SSE2/AVX → x64 + SSE2/AVX2
【CPU検索スレッドの数】4
【検索プロセスの優先度】アイドル
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【 5分間の平均速度】 106.68M tripcode/s → 109.24M tripcode/s
【GPU検索の平均速度】 74.75M tripcode/s → 74.10M tripcode/s
【CPU検索の平均速度】 31.93M tripcode/s → 35.14M tripcode/s

i7 980X 4GHz + HD7970 1GHz
ようやく涼しくなってきて、サファリテールのファン50〜55%固定で
80度超えなくなってきた。
90度って怖いスクショも出てたけれど、>>443をHD7970 1枚でぶち抜ける事を考えると、
R9 290X全開で回したら、どうなっちゃうんでしょ・・・ｗ

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 8

【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【CPUの命令セット】x64 + SSE2/AVX/AVX2
【CPU検索スレッドの数】自動
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 2805.95M tripcode/s
【GPU検索の平均速度】2664.54M tripcode/s
【CPU検索の平均速度】 141.41M tripcode/s

めりけんさんに素朴な質問です
MTFのXP対応はいつまでと考えていますか？

余ったパーツで1台組んで、使わなくなってたXPで
MTFを回そうと考えたのですがXPサポート切れるのが
来年の4月上旬というのを思い出して、漠然とどうするのかなー
と思いまして

心構え的なものとして一応知っておきたい気分になりました

>>454
>>461
順当に速度が上がってますね。検索君1号の電源容量も完全に足りなくなったので、
とうとう電源を追加しました。マザボとその他(PCIeを含む)で分けましたが、
今のところうまく動いているようです。

>>458
なかなかきれいなトリップでよかったですねえ。
3770は残念ながらAVX2には対応していません。
CPU検索が微妙に遅くなっているのは
GPU検索の効率が上がったためだと思われます。

>>463
12桁もいじったかもしれませんが、よく覚えていませんｗ

>>464
確か性能は40%増しだったはずです。
290Xの4枚差しとかぜひやってみたいですｗ

>>465
どうなんでしょう。当分の間開発環境を変えるつもりはないので、
今のところ使えなくなる理由は見当たりません。

ところで今、短めの検索ワードをちょくちょく流しているのですが、
トリップキーを「まとめて」受け取れないものでしょうか。

複数のトリップを取得するのに、いちいち一つづつページを開いてボタンを押すのは大変です。
だったらとタブブラウザで開きまくったら、ボタンを押した時に
「不正なリクエストです。サポートに連絡してください。」と表示されたり、
いつの間にかログアウトされたりしてしまいます。

>>471
ゆぐちゃんの話はなるべくこちらのスレでお願いします。

【分散トリップ検索】Meriken's Tripcode Yggdrasil
http://toro.2ch.net/test/read.cgi/esite/1379214816/

>>471
トリップの一覧で受け取りたいトリップを選択して
「受取」ボタンを押せばまとめて受け取れますがな。

>>472
あ、そうでした。ごめんなさい。
>>473
乙です。

いや、まとめて受け取る機能は最初からついてますが…

まあでもよく考えたらゆぐちゃんにはマニュアルすらなかったですねｗ
MTFを含め、いろいろドキュメントを整備したいところです。

いえ、「教えて下さりありがとうございました」の意味で言いました。

>>477
了解しました〜

検索君1号に電源を追加したら、消費電力が数十W下がりました。
やっぱり容量ギリギリで運用していると効率が悪いみたいです。
これで安心して水冷化して思う存分ファンを追加できますｗ

>>449
部品が焼けなくても温度が上がると熱雑音が増えますから、
クリティカルな部分で信号が乱れたら止まるしかないかとー
>>461
ダクト的なものつけて廃熱を直接外に捨てないと！

>>453
お疲れ様です。
診断＆通常使用に比較的近い条件での速度を見てみました。

【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 7 → Alpha 8
【OS】Win7 Pro 64bit SP1
【CPU】Core i5 3570
【CPUの命令セット】x64 + SSE2/AVX/AVX2
【CPU検索スレッドの数】4
【CPU温度】72℃位

・診断
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【トリップの種類】10桁
【10分間のCPU検索の平均速度】　21.39M tripcode/s →　21.06M tripcode/s
【トリップの種類】12桁
【10分間のCPU検索の平均速度】 104.52M tripcode/s → 104.10M tripcode/s

・通常の使用に比較的近い検索条件の方（普段は、もっと検索パターン数多いです）
検索パターン、先頭一致6完一つと特殊の純8連。

【トリップの種類】10桁
【10分間のCPU検索の平均速度】 19.71M tripcode/s → 19.34M tripcode/s
【トリップの種類】12桁
【10分間のCPU検索の平均速度】 91.56M tripcode/s → 90.91M tripcode/s

うちのIvy環境では、やはり僅かに速度低下しています。しかしIvyで速度アップの報告も有るのかｗ
それにしても、HaswellのAVX2の効果凄まじいですね。報告を見たスレ住人の何人位が触手を
うねらせている事やらｗ
Yggdrasilの方にもかなり好影響が有りそうだ。

>>481
あっちを立てればこっちが立たずでなかなか難しいですねえ。
AVX2はそのままにして、AVX版だけもとに戻そうかなあ。

>>481
AVX2はかなりおいしいことが分かってたんですけど、実際に今までCPUでは
ありえなかった速度が出ると結構嬉しいですねｗ
あと、10桁トリップ検索では◆znjnB.IJwZLUさんの助けが実に大きかったです。
次のバージョンのREADMEでその功績が讃えられることでしょうｗ

う〜ん、検索君1号に電源を追加してしばらく動かしてみたけど、
やっぱり安定しませんねえ。別の電源で稼働させるのはポンプとファンだけに
しておきます。

R9 290Xのベンチ結果が出ています。
ttp://northwood.blog60.fc2.com/blog-entry-7149.html

グラフィック性能はどーでも良いのですが、280Xと比べて消費電力と温度がかなり高いです。
これを4枚差しは、かなりきつそう。

GTX 780は値下げされるだろうから、メリケンさん買いませんか? (ボソッ)

さすがAMD、某220Wに続いて爆熱伝説を残そうとしているのか……！？

>>482
現在（MTF 1.1 FE Alpha8）のルーチンとは別に、Alpha7のルーチンも内部に持つという事でしょうか？
もしそうだとすると、今後のコード修正や動作テスト等のMerikenさんの手間が増え過ぎてしまって、
得策では無い様な気がします（ソフト開発の事をよく知らないので、的外れだったらすいません）

>>483
スレ内にコード最適化等の話をできる人が数人？居るのが凄いｗ
MTFユーザーとしても有り難いです。

>>485
Merikenさんの部屋が、ますます暑くなるな…

検索君1号が不安定になっていた理由は電源ではなくて熱でヘタれた6990でした。
不安定なコアだけ電圧を戻したらちゃんと動くようになりました。
もう一回電源を2個にして稼働させてますが、今のところ問題はでていません。
電源を2個にできるとかなりおいしいので、このまま安定して動作してほしいものです。

>>485
こりゃ冷やすの大変ですねｗ 電源も工夫しないと4枚は無理ですねえ。

> GTX 780は値下げされるだろうから、メリケンさん買いませんか? (ボソッ)

その発想はなかったｗ グラボの水枕を買ってお金が余ったら考えます。

>>487
AVX用のルーチンは元に戻しておきました。他の部分が最適化されているので
微妙に速くなっているはずです。もともとAVXとAVX2は別扱いなので手間が
増えるわけではないです。

>>491
手間が増えてしまうわけでは無いんですか。
ちょっと気になっていたので安心しました。

AMDがAVX2をサポートするそうです。
ttp://northwood.blog60.fc2.com/blog-entry-7150.html

鬼が笑うというやつですね。それよりもStreamrollerコアのFXをはよう。

ゲーム用に組んだはいいが全然使ってないPCで起動してますが上位の方には適いませんね
あまり起動しませんがよろしくです。

GTPS超えの方々は電気代の怒涛のボディーブロー攻撃を堪え忍んで長時間稼働がんばって下さい

>>493
temashコアのA6-1450ちゃんなら10桁検索で頑張ってくれてます。
手ごろなモバイルノートをと思って買ったAcerのノートPCですがお買い得でした。

>>495
酒も煙草も博打もしない健やかな体にはこの程度の攻撃、効かぬわ〜！！

なんか・・・・ｗ

【笑い者】Windowsのパスワードは、たった6分で突破が可能と判明
http://kohada.2ch.net/test/read.cgi/pcnews/1355233376/

http://gigazine.net/news/20121211-gpu-brute-force-attack/

＞このシステムは5つのサーバーで構成されており、25個のAMD Radeonのグラフィックカードを搭載。
＞LinuxベースのOpenCLクラスタ・プラットフォームを使用し、複数のグラフィックカードが
＞あたかも単一のコンピューター上で動作しているようにふるまうことが可能です。


英文の元記事はこっちか
http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/


なんかグラボが８枚乗っているようにみえるし
記事でも単一システムにグラボ８枚までって書いてあるみたいだけど
５サーバーで25GPUってどういうことだろ

http://cdn.arstechnica.net/wp-content/uploads/2012/12/radeon_city.jpg
見てどのGPUかわかる？

>>498
耐障害性のため、3枚は予備になってるとか？

写真に写ってる4台のサーバー見ると
GPU3枚のサーバーが3台とGPU8枚のサーバーが1台見えてるから
3+3+3+8+8の5台構成なんじゃない？

>>492
なんせアセンブラで書かれたトリップ生成のルーチンが
16個ありますからねえｗ まあでももう慣れちゃったので大丈夫です。
AVX2の次のAVX-512が出てもすぐに対応できるようにしておきました。
しかし何年後になることやらｗ

>>498
これHashcatで記録を出したやつでしょう。夢のようなシステムですw

>>494
どもども、よろしくお願いしま〜す。

>>493
AMDも頑張りますねえ。AM3+のCrosshair V Formula-Zがあるので
いつでもばっちこいですｗ

ｱｯｰ!!!

どうも新しいマザーボードはビデオカードを同じ種類ので揃えないと
起動時に安定しないみたいだし、このままだとやっぱり消費電力が心配なので、
思い切って余っているビデオカードを全部売って、そのお金で新しく7990を
もう1枚買うことにしました。これで水冷化も多少楽になるはずです。

おお、思い切ったことだけど私もそれで正解な気がする。
何かそのうち>>498を本当に作ってしまいそうでな道ではあるけどｗ

>>506
ebayを見ると、7990は$600前半まで落ちていますね。
水枕代等考えると、それで正解だと思います。
もうプログラムに必要なデータ取は終わったでしょうし。

これMTFに使えませんかね
http://akizukidenshi.com/catalog/g/gM-06926/

>>507
>>508
ですよね〜 せっかく水冷にしてもシステムが不安定じゃ意味ないですしね。
消費電力が少ない10桁トリップ検索なら7990 3枚でも十分いけますよｗ

>>509
使えることは使えますがメリットがあるかというと怪しいですね。
以前試算しましたが、このゲート規模だとSHA-1で50MTPSあたりがいいとこで、アクセラレータとしては微妙な数字です。
Radeon HD 7750あたりをつんだ方がよっぽどスピードが出て安くて汎用性があります。
唯一の取り柄としてはワットパフォーマンスですかね。
FPGAによるアクセラレートは電気代（電力容量）というランニングコストでは優秀ですが
如何せんイニシャルコスト（FPGAボードの値段）が高くなりがちで、トータルのライフサイクルコストで見るとGPGPUのほうがよかったり。

ただ、昨今では電力バジェットが演算上限を規定し始めているのでGPGPUの限界の先を目指すなら
避けては通れない道でしょう。

つーか私はFPGAをLinuxマシンにつなげるためにSTFを書き始めたんですが・・・
そろそろ本来の目的に進まないといけませんね

>>511
BitcoinマイナーではSpartan 6-150が3個で7970相当の速度が出ていたみたいですね。
それで消費電力が30Wだからおいしすぎです。やっぱりGPGPUの次はFPGAかなあ。
私は当分の間はGCNのアセンブラに取り組む予定なので、STFが出来るのを楽しみに
しています。

>>512
GCNのアセンブラは一時期検討しましたが、微妙によくわからんとこが多くて投げましたｗ

OpenCLでコンパイルしたGCNのバイナリは、LLVMを使ってるだけあって結構いいところまで最適化されています。
問題はメモリアクセスの部分で、GPGPUの場合どうしてもプロセッサあたりのメモリ帯域が狭くなるので、
変数をいかにベクタレジスタに割り付けるかが勝負どころだと思っています。

CPUに慣れた身としては演算器ごとに16kBのL1Dキャッシュが欲しくなってきます。
そういう向きにはXeon Phiの方が向いているんでしょうが如何せんお高いので。

富豪達が語らうのを傍目に，今日も電気代のボディーブローをひしひしと感じつつ，ユグちゃんを起動するのであった……
祝ゴールド勲章！

作業の負担にならない程度だと1600Mが精一杯かー
AMD軍団には適いません

久々の参戦
290Xは買うべきか悩む…

検索速度上位の皆さんがんばれ！

>>514
おめ！
でも２〜５位は団子状態で油断できないですね。
私も頑張ってそのうち参戦します！

>>516
あれ？スコア的にCFX効いてないような？

>>517
感謝しきれません。私も今更検索時間を伸ばしてみているのですが、
14日経過でまだレベル6……道のりはまだ遠いようです

>>518
…CFXケーブルつけ忘れてました　ハイ

>>519
自分のペースで無理のない程度にまったり行けばいいんですよ。
コツコツ参加していけば登録できるトリップも増えますから、それで運よく良いトリップが見つかれば後々実装予定の
オークションで一攫千金も狙えます。
私もつい先ほど、◆CrossFireA/Xや◆SilentCFXer0のような面白いトリップを見つけて頂きました。
かっこいい英/ドイツ語等や印象深い固有名詞を登録していけば自力でトリップを発見せずとも、ほかの人が羨ましがる
トリップを手に入れることは出来ると思いますので、頑張っていきましょう♪

>>520
機器の故障とかじゃなくて幸いでした。

>>521
検索に参加するメンバーには一体何がウケるんですかね……？
まあネタは一応ある(現在Jargonを検索リストにして洗っているところ)のですが

>>522
10桁12桁にどんな意味を込めるかその人のセンスが問われるところだから、オークション実装まではお楽しみですね。
個人的には英語力が無いから、花言葉や諺を上手くまとめてくれたものとか憧れますね。
LoveIsBlind.(恋は盲目)とか？

>>513
> 変数をいかにベクタレジスタに割り付けるかが勝負どころだと思っています。

これはその通りだと思います。特にBitslice DESはregister pressureが
大きいので、手作業でレジスタ割り付けを工夫すればかなりoccupancyを引き上げることが
出来るはずです。今のレジスタの数から見て数割の高速化は堅いでしょう。

> LLVMを使ってるだけあって結構いいところまで最適化されています。

でもAMDのドライバって結構酷いバグが残ってるんですよね〜
バグでローカル変数が吹っ飛んでたのには本当に参りました。
カーネルのビルド時のオプションで最適化は切っておいたほうが良いなんて話もありました。
今のOpenCLの実装はバグを避けるために妥協しているところもあるので何とかしたいですね。

> そういう向きにはXeon Phiの方が向いているんでしょうが如何せんお高いので。

Xeon PhiのAVX-512はぜひ試してみたいですねえ。そのためにはもっと稼がないと…

>>514
とうとう来ましたね。おめでとうございます!
結構ランキングも接戦になってきましたね〜

>>516
お、戻ってきましたね。
290Xは私も欲しくてしかたがないんですけど我慢してますｗ

全然関係ないことなのですが、スレタイの Tripcode を見るとどうしても
往年の無料ホームページサービスだった Tripod に見えて仕方ありませんｗ

>>527
「Tripper」表記を避けた結果似てしまうという偶然……！

ところで、スレタイが「MERIKEN's」のままなのは検索を考慮してですか？

昨日は気分転換にLISPの方言のClojureで遊んでました。
Java VMで動作するんですけど、なかなか面白いです。
これでMTFのGUIを書き直したら別のプラットフォームにも
移植できるだろうけど、どうかなあ。

>>528
まあそんなところです。次スレでは「Meriken's」にしておきます。

CPUだけだとレベル10が果てしなく遠い
GPU積むべきか…？！！！！

>>531
レベルだけが目的ならGTX660だと常時稼動でも12桁経験値レベルが時間レベルを超えるのは難しいレベルです
経験値レベルが時間レベルを超えたいならそれ以上のGPUを使うか複数マシン起動をｗ

あとユグの話はなるべくユグスレにしましょう　レスもしにくいのでｗ
http://toro.2ch.net/test/read.cgi/esite/1379214816/

AMD，CPUとGPUの深い連携を可能にする新要素「hQ」発表。HSAの姿が見えてきた？
http://www.4gamer.net/games/147/G014731/20131021024/

次世代のAPUは面白くなってきそうだな

恐ろしい

Bitcoinマイニングはまさに軍拡競争、素人お断りの現状とは？
http://gigazine.net/news/20131021-bitcoin-mining-as-arms-race/

>>534
ん、Bitcoinってバブル弾けたんじゃありませんでしたっけ？
はたしてそこまでハードウェアをつぎ込むほど儲かるのかどうかよく分かりませんな……

>>534
なんかものすごいミステリアスで面白そうに見えてくる

ttp://www.youtube.com/watch?v=Smc7ZvnVFzk

Mac Pro
浮動小数点で7TFLOPSならトリップ検索でどれくらい出るのかな

放熱はすごくよさそうに見えるんだけど

新生検索君1号は12TFLOPSだったか・・・

>>442
まだ290Xが発表されていないのに、既に水枕が開発されました。
相変わらずEKの仕事早いな。
http://www.ekwb.com/news/407/19/EK-FC-R9-290X-for-AMD-Radeon-R9-290X-makes-it-s-debut/

どうもAlpha 8にはバグが残っているようです。
こちらでも確認しました。表示された検索速度は落ちていないのに
GPUのうちのひとつが使用率0%になってしまいます。
Radeonのグラボで起きるみたいです。
このバグに遭遇された方は是非詳しい報告をお願いします。

> 135 ：名無しさん＠お腹いっぱい。 ：sage ：2013/10/22(火) 22:09:40.38
> α8にしてからたまに検索が止まってるような気がする
> クライアントは動き続けてるんだけどその間の検索がされてないような
【分散トリップ検索】Meriken's Tripcode Yggdrasil
http://toro.2ch.net/test/read.cgi/esite/1379214816/135

>>539
やっぱり水冷化が必須ということなんですかねえ。
だれか290XでMTFを動かす勇者はいないものだろうか。

CPUを水冷化するための部品が届きました。
巨大なラジエーターのせいかめちゃでかい箱ですｗ
今ちょっと忙しいので少しづつ組み立てることにします。

>>540
どうも私の見つけたバグは報告されたものとは違うようですorz
詳しく調べないと…

アプリじゃなくてドライバやハードウェアの可能性もあるので
切り分けがかなり面倒ですねえ。まぎらわしすぎですｗ

巨大なラジエーターってこれじゃないのか
http://shop.aquacomputer.de/product_info.php?products_id=2965

>>539
もうできたのか…
資金がたまったらやってみたい

>>542
いよいよ水冷ですね　期待します

CPUブロックをマザボに取り付ける前に仮組みしてループを稼働させてみたんですけど、
いきなりEKのポンプから水漏れして超ビビリましたｗ ポンプのねじを締め直したら
収まりましたが、これは相当慎重にやらないと駄目みたいですね…

水冷化したCPUはちゃんと動いているようです。
定格のi7-4770での速度は次のとおりです。

10桁トリップ検索: 51.70M (CPUコアの温度: 43〜52℃)
12桁トリップ検索: 239.15 (同上: 41〜47℃)

静音ファンが9個ついてる割には温度が高い気がしますが、
なにせ水冷化は初めてなのでさっぱりわかりませんｗ
これでMaltaを2枚冷やせるといいんだけど、どうかな〜

Radeon R9 290シリーズ「Hawaii」のアーキテクチャを丸裸にする
http://www.4gamer.net/games/234/G023455/20131021060/
「Radeon R9 290X」レビュー。シェーダプロセッサ2816基を統合した“モンスター”の実力はいかに
http://www.4gamer.net/games/234/G023455/20131023061/

暖房器具ですね。

水冷というのはやはり同じ熱を空冷で冷やそうとするのに比べると電力がかさむもんなんでしょうか

>>551
同じ熱を、同じ廃熱先に、同じ廃熱装置で捨てる場合はポンプ分＋αで嵩むだろうけど、
水冷にすることで廃熱装置を離して設置したり大型化したりできるから比較できないと思う。
大型のヒートシンクに繋げば冷却ファンを省エネにしたり排除できるし、
廃熱場所を屋外や屋外直結のダクトや水源まで延長して温度差を維持して効率上げたりもできる。

R9 290Xが$579.99とは随分お買い得ですね。でも我慢我慢…

SAPPHIRE 100361BF4SR Radeon R9 290X 4GB GDDR5 PCI Express 3.0 BattleField 4 Game Edition Video Card $579.99
http://www.newegg.com/Product/Product.aspx?Item=N82E16814202058

>>549
Fire Strikeの90℃超えは、「良く訓練された90℃超え」だったみたいですね(笑)。

>>553
BF4のプレミア無しなら$549。780はこれより安くなるだろうから、両方IYHしませんか!

R9 290XからCF用のケーブルが不要になったのは大きいですね。
今後はヒートシンクの自由度も少し上がりそうです。
いっそMacProみたいにケーブルの代わりにヒートシンクを繋げていく形にして、
VGA正面とPCIスロット背面に吸排気のファンを取り付けられるようにしてくれれば
空冷でもかなり冷却能力を稼げそうで面白そうなんですけどね。
ttp://www.apple.com/jp/mac-pro/

R9 290Xの性能は結構期待できるますね。
水冷化するとしてどれぐらいの冷却力が必要なのかが気になるなぁ…
現状の冷却系統を流用していいのかちと疑問。発熱量がよくわからない。

>>551
ここのスレで話している水冷は、空冷では間に合わないGPGPUの発熱への対処なので、比較はできません。

静音化のための水冷(簡易水冷キットとか)なら比較が成り立つでしょうが、興味無いので分かりません。
ポンプ分の電力が必要だから、水冷の方が消費電力が大きいんじゃ無いのでしょうか?

>>548
>>454に書いてある私の場合の温度と変わらないので、問題ないかと。
ラジエーターで冷媒を冷やすのであれば室温を下回ることは無いので、あとはCPUの発熱量と熱伝達で決まります。
ラジの容量は十分なはずなので、Malta二枚なら余裕かと。
ダメならファンを高回転させれば対処できると思います。

Haswellを殻割り液体金属にしたかどうか、教えて頂けませんか?

「生成されたトリップの累計」がようやく「京」の桁まで行きました
次は「累計検索時間」に「年」が出るまでがんばろうと思います

>>559
ユーザー名が気になります
常時1GTPSでも4ヶ月ほど動かさないと「京」の桁は出ないから、
例のランキングでは間違いなく上位ランカーなはずなのですが……

大勢で集団分散検索して総合的な検索スピードも早いし、
殆ど１０文字ばっかり登録してるんだけど、流石に全然出ないね。
９文字でも、たまーに見つかる程度だし。

ユグの方は検索速度は当然高いわけだけど、前方完全一致の指定だから難しいですねー
ローカル指定は各自のマシンの速度しかでませんが正規表現を駆使したパターン指定を数多く登録することで
何かしら見つけるっていう意味ではユグより発見の敷居は相当下がりますね

10文字クラスになると特にねｗ

>>562
例えば、ユグのほうで
「^MIKISAYAKA」
「^MikiSayaka」
「^Mikisayaka」
「^mikisayaka」
と登録していて、ローカルの方に
「^[Mm][Ii][Kk][Ii][Ss][Aa][Yy][Aa][Kk][Aa]」
と登録していたとします。
前者を10GTPS(12桁)・500MTPS(10桁)で回すと、発見予定時間は
それぞれ7.7ヶ月・51年です。ですが、後者を同じぐらいの時間で
出すにはせいぜい39MTPS・970kTPSぐらいで十分なんですよね……。
これは極端な例ですが、展開後検索パターンが多ければ、
ローカルが遅くとも勝負になるということです。

ユグでは12桁メイン、自分は10桁メインの運用が効率

さやかちゃんさやさや

ここに来るようになって覚えた単語だけど
誕生日のパラドックスって奴ですね〜

昨日は指導教授との面談があって、博士論文の資料の作成でくたくたでした。
ここしばらくはトリップ検索で遊びまくってたけど、
本業のほうも忘れないようにしないとｗ

2枚目の7990が届いたので水枕が届くまで
空冷で10桁トリップ検索をさせることにしました。
ゆぐちゃんに接続して560Mほど出ているので上出来でしょう。

7990を水冷化したら空冷の7970をもう1枚足して
10桁トリップ検索の最高速の記録を狙う予定です。
mtyでの700M TPSがこれまでの最速の報告のはずなので、
問題はないはずです。

>>567-568
お疲れ様です。
新システムを組むのは色々ワクワク感がたまりませんね♪

7970CFXですがPCI周辺温度が60℃を超えるので空冷の限界を感じつつ
M/Bの痛みが気になるこの頃

因みにMerikenさん同様、PCI-E6ピンケーブルを燃やしてしまいました
セッティング中に電圧を上げすぎたのが敗因orz

>>570
諦めるな！！
空冷大好きな私としては、付属をファンは取り外して自分のお気に入りのファンを増設しまくればまだまだ行けないかな〜と思います。
サイズ KAZE-JYUNIスリムは厚さ12mmなので、Ainex FST-MAG-Bに取り付ける際に薄さを生かしてゴムワッシャとナットで角度を付ければPCIスロット背面に風を誘導できます。
更にVGA正面とPCIスロット背面にファンを取り付ければVGA正面からの風を効率的にPCIスロットから排気出来ます。
通常使うファンはNoctua NF-F12 PWMが二重反転ファンの仕組みをファンガードに取り入れているので静音性を保ちながら静圧を確保するにはお勧めです。
静音性を多少無視していいのなら、XINRUILIAN RDL1225S(12LN)とサイズ 隼120 PWM SY1225HB12SH-Pの組み合わせが既存のPC用ファンで可能な範囲の静音性を保った静圧を
最も強く発揮できる組み合わせだと思います。

通常のファンより高い静圧を得られる二重反転ファンの資料については以下のリンクを参考にどうぞ。
ttp://www.mitsubishifan.com/catarog2009/280.html
ttp://www.youtube.com/watch?v=BYTwrdpUHBs

>>572
既にGPU正面にはRDL1238S-PWMを装備しております
これ以上となると予備のBW-1238B-PWMも御座いますがさすがにこれは・・・

まぁ電流的には十分ありえるんだけどほんと最近のGPUは猛獣かなんかみたいでﾜﾛｴﾅｲｗ

HD7970をCFXして検索していると時々止まるなぁ…
水冷だから冷却には問題ないし電源も足りてる…うーむ

>>575
GPUは1GHｚでしたっけ
止まるのは電圧ちょい上げで防げます
発熱とのトレードオフですが

>>568
ｗｋｔｋしながら待ってます。ついでに12桁最高速も更新ですか？

>>568
期待してますー
10桁やってみるかなぁ…

>>576
電圧上げてみたら少し安定してきました
様子見してみます

>>560
すみません
>>559は◆kwkkkkkkkkです

MTFで12桁の検索を始めたのはYggdrasilサービス開始前の5/10（10/24の167日前）で
平均約700MTPSで動かしてローカルでの稼働率98.75%ですので

700*10^6*60*60*24*167*0.9875≒10^16

ということで大体計算通りと思います

5ヶ月半くらいがんばれば12桁は自力で「京」まで行けそうな感じでしたので
「京」の桁を見るのを当面の目標にしてました

>>579
◆kwkkkkkkkkさんでしたか。
(「お知らせ」を見ながら)ユグではよくお世話になっております。
不幸なマシントラブルに見舞われないことを祈ります。

変なフラグ立てんじゃねーよ

フラグはへし折るものですよ

Win8.1へアップデートしたところ検索速度がダウンしました
5500Mtrips/s→5000Mtrips/s
OSの制約によるものかRadeonのドライバが熟れていないのか・・・

>>554
> BF4のプレミア無しなら$549。
> 780はこれより安くなるだろうから、両方IYHしませんか!

水枕を買ったら軍資金は完全に底をつきましたｗ
水冷化は効果は抜群ですけど、やっぱりお金がかかりますねえ。
780は気になっているので次にまとまったお金が手に入ったら買うことになると思います。

>>558
なるほどなるほど。それでは安心して水枕の到着を待つことにします。
Haswellには特別なことはしていません。EKのCPUブロックについてきた
サーマルペーストをそのまま使っただけです。

>>559
>>579
◆kwkkkkkkkkさん、頑張ってますからね〜
これからもぜひよろしくお願いします。

>>570-573
なかなか苦労されてますねえ。
まあでも7970 CFXなら空冷でも問題ないはずです。
Maltaだと空冷で12桁トリップ検索は厳しいですが…

>>569
水冷化は初めてなので結構おっかなびっくりですけどねｗ
まあでもCPUでの効果は期待通りだったので、
?GPUの水冷化が楽しみです。

>>582
名言ですね

>>540と>>543の問題は無事に解決できました。
が、今度は新生検索君1号で表示に使っているGPUの使用率が徐々に下がる
謎の現象が発生。どうせまたドライバの問題なので
今日うｐされたCatalyst 13.11 BetaV6を試してみることにします。

う〜ん、新しいドライバにしたら速度が40M TPSほど落ちちゃいました。
これは痛いですねえ。まあでもこれで安定してくれるならやむを得ないです。
早くGCNのアセンブラで書きなおしたいところですね。

>>583
これもドライバの問題のような気がします。
なかなか頭がいたいですねえ。

相変わらずドライバの問題が出てますね…
AMDはさっさとこういう所どうにかして欲しいです

検索君来ましたね

あれからいろいろ試してみて、Catalyst 13.9では速度が遅くなるものの安定して
動作することが確認できました。で、これまで使ってた13.5 beta2がASUSのマザボ用の
ユーティリティと相性が悪いことが判明。現在アンストールして様子見中です。

>>577
7990x2+7970で12桁トリップ検索をさせると1200Wの電源だとギリギリですねえ。
10分だけなら大丈夫でしょうけど、24時間稼働はちときびしいです。

MTFの内部構造で色々気になる部分が目につき始めたので、
次のバージョンで大幅に刷新することにしました。
検索デバイスを動的に変更したり、12桁トリップ検索でキーを
56文字にして速度を2割増にする機能をつけたりする予定です。

というわけでバージョン1.1での機能の追加はこのへんにして、
近いうちにBeta 1をうｐします。

期待

新しい開発版をうｐしました。

Meriken's Tripcode Finder 1.1 Free Edition Beta 1
(p)http://www.meriken2ch.com/programming/merikens-tripcode-finder

Alpha 7からの主な変更点は以下の通りです。

・10桁トリップのGPU検索が停止する不具合の修正。

10桁トリップのCPU検索も微妙に速くなっているはずです。

乙です。TITANさんが時々落ちる不調です。無理させちゃったかなー

TITANは犠牲になったのだ……古くから続くトリップ検索の伝統……その犠牲にな……

>>600
OCしていると結構グラボも普通にへたりますからねえ。
なかなか難しいところです。電圧をちょびっと盛るか、クロック周波数を
下げてやれば直るかもしれません。24時間稼働させるなら
ギリギリまでOCするのではなく心持ち余裕を持たせておくと良いようです。

:::::::::::.:　.:. . ∧＿∧ . . . .: ::::::::　　>>599で10桁検索を試してみたら、
:::::::: :.: . .　/彡ミ゛ヽ;)ヽ、. ::: : ::　　全体的には微妙に遅くなってしまいました……
::::::: :.: . . / :::/:: ヽ、ヽ、i . .:: :.: :::　GPU4.54M/CPU8.37M(1.1a8)→4.67M/7.30M(1.1b1)
￣￣￣（_,ノ ￣￣ヽ､_ノ￣

12桁をα8で動かしたまま
10桁のほうをβにしてみたのですが、βで動かしている10桁検索がユグに表示されないみたい

>>604
検索中のPCで表示される検索中PCの一覧の話です

>>605
ごめん　10桁に設定してなかったです＞＜

>>603
CPUは何ですか? Haswell/Ivy Bridge向けの最適化なので、
他のアーキテクチャだと遅くなるかもしれませんねえ。
CPU検索のスレッドの優先度も下げたのでそのせいかも…
CPU検索だけでの速度も教えていただけますか。

>>604-605
あ〜、びっくりしたｗ

>>603
まあでも多分CPU検索のスレッドの相対的な優先度を下げたのが
効いてるんでしょうねえ。う〜ん、どうしようかなあ。

βで幾つかパターン設定して
10桁検索、特殊設定に準8連、二構、最短を設定して検索を開始すると

http://kie.nu/1rVa


特殊設定から二構をはずしたら普通に動きました
必要なら環境その他説明します

>>603
あ、そうそう。「CPU検索スレッドの数」を目一杯上げてやれば速くなるかもしれません。
自動設定の値も変えておいたほうがいいのかな。

>>609
二構はCUDAの10桁トリップでは元から動かなかったような…

> 必要なら環境その他説明します

お願いします。

>>611

【OS】Win7 Pro 64bit SP1
【CPU】Core i7-3770K
【CPUの命令セット】x64 + SSE2/AVX/AVX2
【CPU検索スレッドの数】4
【CUDA1SMあたりのブロック数】4

GeForce GTX 660
ドライバのバージョン 327.23


とりあえずこれくらいあればいいでしょうか

>>611
＞二構はCUDAの10桁トリップでは元から動かなかったような…

10桁の特殊設定は今回はじめて設定したので、もとからなのかもしれないですー

>>612
ありがとうございます。Alpha 8で二構は検索できていましたか?

>>613
了解しました。二構についての注意書きを足しておいたほうがいいのかもしれませんね。

>>614
今、α７にて、同一のpattern.txt、同一特殊設定（準8連、二構、最短）での正常起動を確認しました

α８にて、同一のpattern.txt、同一特殊設定（準8連、二構、最短）での正常起動を確認しました
が・・・、正常にパターン展開を終え検索開始を確認してからα８を終了させたらなぜかFireFoxがクラッシュ＾＾；

>>616
βを入れていろいろ試している最中、先ほどのドライバクラッシュとともにFireFoxのエラー再起動も何度も起きていたので
その影響かも・・

>>616
CUDAのほうはいじってないのでおかしいですねえ。
取りあえずCPU検索スレッドの優先度は元に戻しておくことにします。

とりあえず試したので貼っておきます

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 8 → Beta 1

【検索デバイス】GPUとCPU
【使用するGPU】NVIDIA GeForce GTX 660 (CUDA)
【使用するCPU】Intel Core i7-3770 CPU @ 3.40GHz

【1SMあたりのブロック数(CUDA)】自動
【CPUの命令セット】x64 + SSE2/AVX/AVX2
【CPU検索スレッドの数】自動
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 623.67M tripcode/s → 620.78M tripcode/s
【GPU検索の平均速度】 525.63M tripcode/s → 522.63M tripcode/s
【CPU検索の平均速度】 98.04M tripcode/s → 98.16M tripcode/s

【トリップの種類】10桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 45.82M tripcode/s → 46.43M tripcode/s
【GPU検索の平均速度】 25.91M tripcode/s → 25.84M tripcode/s
【CPU検索の平均速度】 19.91M tripcode/s → 20.60M tripcode/s

>>607-608,610
CPUはいつもの通りi5-3210M(Ivy)ですよ。
もう遅いかもですが、真面目に測り直してみました。
設定は、「256block/SM(GPU)＋4thread,64bit,AVX(CPU)」です。
結果、Alpha 8→Beta 1で、12.43M(G4.61+C7.81)→12.01M(G4.67+C7.34)となりました。
ちなみにCPUだけだと、9.57M→9.72Mでした。

>>599
お疲れ様です。
診断機能（CPU検索のみ）の結果報告です。

【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Beta 1
【OS】Win7 Pro 64bit SP1
【CPU】Core i5 3570
【CPUの命令セット】x64 + SSE2/AVX/AVX2
【CPU検索スレッドの数】4

【診断の種類】検索速度(1パターン)
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【トリップの種類】10桁
【10分間のCPU検索の平均速度】 21.42M tripcode/s
【トリップの種類】12桁
【10分間のCPU検索の平均速度】 104.46M tripcode/s

最近は10桁（CPU検索）をしている事が多いので、これは嬉しい。

>>90と同じWin7 SP1 x64 / C2Q Q9650定格（3GHz）CPUのみ / 4スレッドのPCでの
1.1FEα7 / 1.1FEα8 / 1.1FEβ1の各バージョンの12桁 / 10桁それぞれの「各種診断」の実行結果（各3回測定）です

【診断の種類】検索速度(1パターン)
【検索デバイス】CPUのみ
【CPUの命令セット】x64 + SSE2/AVX/AVX2　※1.1FEα7は x64 + SSE2/AVX
【CPU検索スレッドの数】自動　※4スレッド
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【10分間のCPU検索の平均速度】
【トリップの種類】12桁
1.1FEα7： 62.71M　62.57M　62.69M
1.1FEα8： 61.80M　61.80M　61.86M
1.1FEβ1： 61.85M　61.97M　61.88M
【トリップの種類】10桁
1.1FEα7： 12.54M　12.51M　12.52M
1.1FEα8： 13.05M　13.00M　13.04M
1.1FEβ1： 13.03M　13.02M　13.02M

12桁は1.1FEα7→1.1FEα8/1.1FEβ1で微減（-1.3%）
逆に10桁は1.1FEα7→1.1FEα8/1.1FEβ1で微増（+4%）といったところです

ちなみに10桁に関して同じPCでmty_win_x64_20071012.zipの64XMMフォルダのmty.exeを使った場合は
target.txtを作らない「勝手にベンチマークモード(128ビット級)」の状態で起動10分後の平均検索速度は13434ktrips/s
mty_cal_20081222.zipのmty_cal_x64.exeを
Catalyst13.11beta v6からaticalcl64.dllとaticalrt64.dll（どちらもバージョン6.14.10.1848）を取り出して
それぞれamdcalcl64.dllとamdcalrt64.dllにリネームして同じフォルダに入れてCPU検索のみで使った場合は
同じ「勝手にベンチマークモード(128ビット級)」で起動10分後の平均検索速度は13.896Mtrips/sでした

TITANさんが増えました。
GPUがちと遅くなったのは何故だろう？
【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 8 → Beta 1

【検索デバイス】GPUとCPU
【使用するGPU】NVIDIA GeForce GTX TITAN (CUDA) x2
【使用するCPU】Intel Xeon W5590 ×2
【1SMあたりのブロック数(CUDA)】自動
【CPUの命令セット】x64 + SSE2/AVX/AVX2
【CPU検索スレッドの数】自動
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】すべて
【検索パターン】 10文字完全前方一致1個

【10分間の平均速度】 2778.09M tripcode/s → 2308.74M tripcode/s
【GPU検索の平均速度】 2668.57M tripcode/s → 2203.67M tripcode/s
【CPU検索の平均速度】 109.52M tripcode/s → 105.07M tripcode/s

報告有り難うございます。なるべく安定したバージョンを出したいので
助かりますです。

>>620
>>621
やっぱり10桁トリップのCPU検索だけ見れば
ちょこっとはやくなっているようですね。

>>622
C2Qあたりだとまだmtyのほうが速いのかなあ。
それともベンチマークモードではヒット判定を省略してるのかしらん。

>>623
これはちょっとどころではないですねえ。
何でCPU検索スレッドの優先度を下げたらGPU検索が遅くなるんだろう…
ちゃんとCC3.5用のバイナリも生成されてるし、ソースコードの差分も
チェックしたけど怪しいところは見つかりませんでした。
今日中にBeta 2をうｐするので、そちらも試していただけると助かります。

新しい開発版をうｐしました。

Meriken's Tripcode Finder 1.1 Free Edition Beta 2
http://www.meriken2ch.com/programming/merikens-tripcode-finder

Beta 1からの主な変更点は以下の通りです。

・CPU検索スレッドの優先度の調整。

これでTITANでの速度低下は直っていればいいのですが…

環境>>619から変化なし
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 8 → Beta 1 → Beta 2

【トリップの種類】12桁
【10分間の平均速度】 623.67M tripcode/s → 620.78M tripcode/s → 620.04M tripcode/s
【GPU検索の平均速度】 525.63M tripcode/s → 522.63M tripcode/s → 520.77M tripcode/s
【CPU検索の平均速度】 98.04M tripcode/s → 98.16M tripcode/s → 99.27M tripcode/s

【トリップの種類】10桁
【10分間の平均速度】 45.82M tripcode/s → 46.43M tripcode/s → 43.67M tripcode/s
【GPU検索の平均速度】 25.91M tripcode/s → 25.84M tripcode/s → 23.01M tripcode/s
【CPU検索の平均速度】 19.91M tripcode/s → 20.60M tripcode/s → 20.66M tripcode/s

>>626
う〜ん、これはおかしいですねえ。
やっぱりスレッドの優先度を変えたときの速度への影響は
環境によってかなり差があるんでしょうねえ。
CPUの速度を上げたらGPUの速度が下がるなんて予想してませんでした。
こりゃどうしようかな。

あ、忘れていましたがGPU回りといえば
今朝にGeForce R331 Game Ready Driver (WHQL) Ver.331.65へアプデしてました
その影響とかもあるかも…？

>>627
CPUのスレッド数をギリギリまで増やしているため、GPUがストールしたとかは考えられませんか？

>>628
その可能性は大いにありますね。私のところではドライバは
320.57のままなんですが、速度低下は見られませんでした。
念のためもう一度測定してみます。

>>629
スレッド数の自動設定のルーチンはいじっていないので、
スレッド数は変わっていないはずなんです。不思議なもんですね。

Alpha8→Beta2で、>>620と同じ設定で動かしてみると、
12.01M(G4.66+C7.35)→12.10M(G4.68+C7.43)となりました。
速度低下が無くなったようです。ありがとうございました。

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Beta 2
【OS】Microsoft Windows 7 English
【ディスプレイドライバ】NVIDIA Display Driver 320.57

【検索デバイス】GPUとCPU
【使用するGPU】すべて使用
【GPU】NVIDIA GeForce GTX 580 @ 830MHz (OC)
【CPU】Intel Core i7-3770K (定格)

【1SMあたりのブロック数(CUDA)】192
【CPUの命令セット】x64 + SSE2/AVX/AVX2
【CPU検索スレッドの数】自動
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】10桁
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 8
【10分間の平均速度】 81.95M tripcode/s
【GPU検索の平均速度】 59.09M tripcode/s
【CPU検索の平均速度】 22.87M tripcode/s

【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Beta 2
【10分間の平均速度】 82.55M tripcode/s
【GPU検索の平均速度】 59.09M tripcode/s
【CPU検索の平均速度】 23.46M tripcode/s

測定してみましたけど、やっぱりBeta 2のほうが速度が上がっています。
なんかやっぱりドライバが怪しいですねえ。
FermiよりKeplerのほうがドライバの負荷が大きいのかしらん。
速度低下がひどいようならCPU検索スレッドの数を下げるのも手かもしれません。

数カ月ぶりに再起動して余計なものを起動させずに測定しなおしてみました
【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Beta 1 → 2
【トリップの種類】10桁
【10分間の平均速度】 48.25M tripcode/s → 48.37M tripcode/s
【GPU検索の平均速度】 26.18M tripcode/s → 26.19M tripcode/s
【CPU検索の平均速度】 22.07M tripcode/s → 22.18M tripcode/s

ttp://pc.watch.impress.co.jp/docs/column/kaigai/20120322_520640.html

Kepler世代ではハードウェアスケジューラをシンプルにして、
一部をドライバで行うようにしたらしいので、Fermiと比べるとCPU負荷が大きいのだと思います。

GK110でもそのあたりの特徴は共通しているのではないかという話もあるようですし、
KeplerはやはりGPGPUでは処理によって向き不向きが大きそうですね。

a8とb2でディスプレイドライバを変えて走らせてみました。

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 8 → Beta 2
【OS】Windows 7 Ultimate SP1 64bit
【検索デバイス】GPUのみ
【使用するGPU】すべて使用
【GPU0】GeForce GTX TITAN
【GPU1】GeForce GTX TITAN
【CPU】Intel Core i7 4770K
【1SMあたりのブロック数(CUDA)】256
【検索プロセスの優先度】アイドル
【GUIフロントエンドの優先度】通常
【トリップの種類】12桁
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個
【その他】画面表示にはCPU内蔵GPUを使用

【ディスプレイドライバ】GeForce 331.58
【10分間のGPU検索の平均速度】 3884.68M → 3873.72M tripcode/s

【ディスプレイドライバ】GeForce 331.65
【10分間のGPU検索の平均速度】 3876.84M → 3870.58M tripcode/s

誤差の内でどの条件でも変わらない様に見えます。

>>636
やっぱりGPU検索だけだと遅くはならないですね。安心しました。
まあ手を付けてすらいないから当然なんですけど…

恐らく問題になっていたのはCPUとGPUで同時に検索した場合で、
CPU検索スレッドとNVIDIAのドライバとのあいだで
スケジューリングの問題が発生していたものと思われます。

>>634
いや〜、遅くなるはずがなかったので、この報告でホッとしましたｗ

Catalist13.11betav7は検索遅くなりますね
Win8.1系のドライバに置き換わっている様子です
まぁ、動くなら別に開発するコストは無駄ですから仕方ないですね
今後もこの方針で行くことでしょう

あれ、錯覚だった

>>638
普段からゲームサーバーとしてMTFと並行で常時稼働してるPCなので
ゲームのオンライン人数に相関して速度が微妙に変わってくる気がしてきました

次からは再起した直後に測ろう…

これだけVerUpでの速度低下を気にしなければいけないのなら、
検索ルーチンを過去数種類分を最初から内蔵させておいて、
ベンチ取って最も速いのに自動切り替えとか出来ないのかな。
検索ルーチンを返すIFに簡易JIT(アセンブラモドキ)持たせて、
CPU別movaps/movdqa選択を始め、パラメータ最適化の夢も。

ベンチ取りながら勝手にチューニングしてくれるモード作ろう（）

>>642
なんのために「自動」設定があると……

>>642
ただでさえ検索ルーチンが多すぎでメンテとテストの手間が大変なのに
これ以上増やすのはありえないですｗ 今でも23個もあるんですからね。
見つけにくいバグが紛れ込んだら収拾がつきません。

>>644
動的に最適化してるのはCUDAのブロック数だけですよ。

>>643
動的な最適化はいろいろ試してみたんですけど、動かしてる時の状況で
速度が全く違ってくるので全然安定した結果が出ないんですよね。

更新おつかれさまです
CPUのみということもあって特に変化はないようですが
>>622に1.1FEβ2の結果を追加しておきます

【OS】Win7 SP1 x64
【CPU】C2Q Q9650定格（3GHz）
【診断の種類】検索速度(1パターン)
【検索デバイス】CPUのみ
【CPUの命令セット】x64 + SSE2/AVX/AVX2　※1.1FEα7は x64 + SSE2/AVX
【CPU検索スレッドの数】自動　※4スレッド
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【10分間のCPU検索の平均速度】

【トリップの種類】12桁
1.1FEα7： 62.71M　62.57M　62.69M
1.1FEα8： 61.80M　61.80M　61.86M
1.1FEβ1： 61.85M　61.97M　61.88M
1.1FEβ2： 61.83M　61.95M　61.93M

【トリップの種類】10桁
1.1FEα7： 12.54M　12.51M　12.52M
1.1FEα8： 13.05M　13.00M　13.04M
1.1FEβ1： 13.03M　13.02M　13.02M
1.1FEβ2： 13.02M　13.01M　13.01M

ありがとうございます。これで特に問題がなければ
Beta 2を次の安定版にすることにします。

予想通りGTX780の値下げが「米国で」来ました。
やはり市場競争はこうでなくては。
ttp://northwood.blog60.fc2.com/blog-entry-7180.html

一方、九十九は在庫処分と称してHD7990を11万越えで売り出しました・・・

7990は何故かアメリカでも値上げされてましたよ。
一時期neweggで$599で買えてたのが$769になってます。
いずれにせよ11万は高すぎですけど…

7990とM6Eの水枕が金曜日に届くんですけど、もう待ちきれないお…
まあそれまでおとなしくゆぐちゃんの相手をすることにします。

新しいドライバが来ましたね。

AMD Catalyst 13.11 Beta8
http://support.amd.com/en-us/kb-articles/Pages/latest-catalyst-windows-beta.aspx

24コア/48スレッド・・・これだとどんぐらい速度出るんだろ・・・
http://weekly.ascii.jp/elem/000/000/181/181422/

>>652
>>548で、4コア8スレッドのi7-4770では51.70M/239.15Mらしいので、
その6倍の310M/1435Mぐらいは行くんじゃないですかね(小並感)

更新乙です。
Beta2の診断（CPU検索10桁＆12桁）、通常の検索共にBeta1と変わらず快調です。

>>652-653
それって、中身はIvy（AVX2非対応）じゃなイカ？

・MTFでの同一クロック/同一スレッド数のIvy(AVX2非対応) vs Haswell(AVX2使用)≒1:2
・12コア/24スレッド vs 4コア/8スレッド＝3:1
・定格クロック 2.7G(12コア全ブースト時最大3G) vs 3.4G(4コア全ブースト時最大3.7G)
と考えると
Xeon E5-2697 v2(AVX2非対応)はCore i7-4770(AVX2使用)比で推定0.5*3*2.7/3.4(3/3.7)≒1.2倍
デュアルで約2.4倍
CPUのみで10桁120MTPS/12桁575MTPSくらい？

10桁の方は、もうちょい速度出そうな気がするけど実際はどうなんだろう？

しかし62万円って金額も凄いが、タスクマネージャーの画像ｗ
http://weekly.ascii.jp/elem/000/000/181/181414/20131030ippei_jisaku06_cs1e1_1000x.jpg

>>656
　　　　　　　 Λ＿Λ　　　　　とりあえず、前にIYHスレに貼られてた画像貼っておきますね
　　　　　 　 （´∀｀　）-､　 　 .http://anago.2ch.net/test/read.cgi/jisaku/1379787364/664
　　　　　 　,(mｿ)ヽ 　　i　　　 ttp://up3.viploader.net/desktop/src/vldesk007857.jpg
　　 　　 　/　/　ヽ ヽ　ｌ
￣￣￣　（_,ノ￣　ヽ､_ノ￣

>>657
(;ﾟдﾟ)ｺﾞｸﾘ……これはIYHerの鑑だ。
だが、このPCをナニに使っているのかが気になるｗ

>>658
> だが、このPCをナニに使っているのかが気になるｗ
いやトリップ検索以外の何に使うのかと・・・

>>498のようなパスコード突破とか
Team2chとか
トリップ検索とか

個人的には、クラック方面の事でも、人の役に立つ（とされる）事でも、どっちにもいいイメージはもっていないな
何の役にも立たないトリップ検索が最高ｗ



どーでもいいけど、Windowsの（に限らないけど）パスワードアタックを
無制限に最高速でアタックし続けられるような認証システムなんて現存してるのかな？ｗ

トリップ検索は、趣味・嗜好性が高い感じがいいねぇ。
特徴的な文字列を持つトリップを見ただけでニヤけてしまう変態（俺）としては、
高速でトリップが生成・発見されていく様は垂涎ものだｗ

はっはっは
擬似準12連きたｗ

>>654
こんどこそ大丈夫なようですね。
もう1週間ぐらい待ってから安定版をうｐすることにします。

>>656
62万あったらXeon Phi 7120Pが買えますよ。
1.238 GHz, 61 coreでAVX-512が使えます。
いつかいじってみたいなあ。

トリップ検索は意外性があるのが面白いですね。
今使ってるトリップが出たときには驚いたもんですｗ

水枕が届いたのでこれから取付作業に入ります。
うまくいくといいけど…

自分も壊れてしまったグラボ買い換えたいです
先立つものはないですけどね！

ここしばらく12桁トリップ検索で見ないと思ってたら壊れてたんですね。
ご愁傷様です… これはなにか考えないといけないな。

新生検索君1号の水冷化は無事に成功したようです。
7990 2枚を1100MHzまでOCしてもGPUの温度は57〜61℃に抑えられています。
ゆぐちゃんに接続して10.5G TPSでるわ、音はほとんどしないわ、
熱はうまく逃げてくれて部屋は涼しくなるわでいいことずくめですｗ

おめでとうございますー
水冷化の効果絶大で何より
こちらもPCの修理をさっさとして再開せねば

もはや他の追随を許さないほど水冷化新生検索君1号大勝利！！！！！

ブログを久しぶりに更新しました。写真付きです。

世界最速のトリップ検索専用PC「新生検索君1号」http://www.meriken2ch.com/blog/archives/135

>>672
早速ブログを拝見しました。ブルーのファンがかっこいいですね。
3枚目の画像はちょっとピンボケですけど、緊張していたんでしょうかｗ

>>672
お疲れ様です。
本格水冷はかなりインパクトありますね。

最近、朝晩は冷えるようになってきて、検索に参加しようかと思っていたところなので、
次回予定の手引きが楽しみです。

新生検索君一号を作るにはいくらかかりますか？

かっこよすぎる・・・・・・

やっぱり注水とかも自分でやるんですか？

水冷はあまり水足す必要はない気が
蒸発はするけど微々たるもんだし

>>672
完動おめでとうございます。

>>678
最初作った時に注水してポンプ動かして徐々に全体に通って行くところが楽しそうでした

少しでも速度を上げようと、ドライバを最新のにしたいんだが、インストーラが途中で止まってしまう。
じゃぁってんで、アンインストールしてから新規に入れようとしたが、アンインストールも途中で止まってしまう。
何か、手動で新規インストールと同じ状態でインストール出来る方法ないですかね・・・
もう面倒臭いから、C:\Program Files\ATI Technologies 以下をセーフモードで全部消すか・・・

>>681
昔はドライバクリーナーでやってた。
最近やったことないから今もこの方法が有効なのかはわからん。
ttp://www.guru3d.com/files_details/display_driver_uninstaller_download.html

>>669,672
おお、無事に完成しましたか！見た目も格好いいし、効果も凄いですね。
そして検索君がリミッター解除状態になっててﾜﾛﾀｗ

>>665
トリッパーが発見してくれた大量のトリップの山の中から、純度の高めな美しい
トリップや面白い感じのトリップを見つけ出した時の喜びってのは、いいものですね。
レアアイテムを入手した様な、なんかそんな感覚。

>>672の記事が結構好評だったようで何よりですｗ
記事に水冷化のためのパーツの一覧を追加しておきました。
ピンぼけだった写真も差し替えておきました。

現在新生検索君1号に空冷の7970を追加して記録を測定中です。
電源にかなり無茶をさせてますが、平気で動いています。さすがAX1200。

>>682
> ttp://www.guru3d.com/files_details/display_driver_uninstaller_download.html
これで消したけど、新しいカタリストはインストール出来なくて、
結局グラボ添付のやつ (13.1) を入れたら、MTF が GPU を
見つけてくれなくて、GPU 検索が出来なくなってしまった。
カタリストの 13. 幾つからサポートしてるんだっけ？
まぁ、「最新を使え」とは書いてあるけど・・・

>>686
13.1だったら動くはずですよ。デバイスマネージャのディスプレイアダプタの項目には
どのように表示されていますか? こういう場合はデバイスマネージャから直接
グラボを有効にしたりドライバを更新したりすると解決できることが多いんです。

12桁トリップ検索の記録に挑戦したらブレーカーが落ちまくったので
取りあえず10桁トリップ検索の記録を測定することにしました。
検索の立ち上がりが遅いので1時間の平均速度を使う予定ですが、
これまでの記録である700M TPS超は確実です。いやあ、長かったなあ。

>>684
中々立派な水冷ですね。部屋が広くて羨ましいです。
透明なクーラントを使うのは珍しいですね。
透明だとじわじわ漏れる場合に気付きにくいので、私は色付きのクーラントを使っています。
ちなみに私が使っているのは、YAMAHAの青いクーラントです(笑)。

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Beta 2
【OS】Microsoft Windows 7 64bit SP1 English
【ディスプレイドライバ】Catalyst 13.11 Beta6

【検索デバイス】GPUとCPU
【使用するGPU】すべて使用
【GPU0】VisionTek Radeon HD 7990 @ 1100MHz (OC)
【GPU1】Gigabyte Radeon HD 7990 @ 1100MHz (OC)
【GPU2】Gigabyte GV-R799D5-6GD-B Radeon HD 7970 @ 1100MHz (OC)
【CPU】Intel Core i7-4770 (定格)

【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【CPUの命令セット】x64 + SSE2/AVX/AVX2
【CPU検索スレッドの数】6
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】10桁
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【60分間の平均速度】 711.22M tripcode/s
【GPU検索の平均速度】 665.16M tripcode/s
【CPU検索の平均速度】 46.06M tripcode/s

【GPUの使用率】92〜99%

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Beta 2
【OS】Microsoft Windows 7 64bit SP1 English
【ディスプレイドライバ】Catalyst 13.11 Beta6

【検索デバイス】GPUのみ
【使用するGPU】すべて使用
【GPU0】VisionTek Radeon HD 7990 @ 1100MHz (水冷OC)
【GPU1】Gigabyte Radeon HD 7990 @ 1100MHz (水冷OC)
【GPU2】Gigabyte GV-R799D5-6GD-B Radeon HD 7970 @ 1100MHz (空冷OC)
【CPU】Intel Core i7-4770 (定格)

【1CUあたりのワークアイテムの数(OpenCL)】自動
【1WGあたりのワークアイテムの数(OpenCL)】自動
【1GPUあたりの検索プロセスの数(OpenCL)】1
【1検索プロセスあたりの検索スレッドの数(OpenCL)】2
【検索プロセスの優先度】通常以下
【GUIフロントエンドの優先度】通常

【トリップの種類】12桁
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【10分間のGPU検索の平均速度】13250.59M tripcode/s

【GPUの使用率】99%
【GPUの温度】58〜62℃(7990) 81℃(7970)

>>690-691
うおおおおおおぉぉぉぉぉぉぉ
おめ〜〜〜〜〜！！！！！

というわけで新しい記録は次になります。まあ上出来でしょう。
これ以上は電源を買い替えてもう一枚7990を買わないと無理ですねｗ

12桁トリップ検索: 13250.59M tripcode/s ( >>691 )
10桁トリップ検索: 711.22M tripcode/s ( >>690 )

すげぇ世界だw

>>689
水冷化できたのはJouJakuさんの後押しがあったからですｗ
バイク用のクーラントとはさすがですね。新生検索君1号の冷媒は蒸留水で、
銀製のKill Coilをリザーバに入れています。
最初の一時間はへばりついて監視してましたｗ

>>692
>>695
どもどもｗ 限界への挑戦はこれからも続きます。

>>687
> どのように表示されていますか? こういう場合はデバイスマネージャから直接
正常に表示されています。

> グラボを有効にしたりドライバを更新したりすると解決できることが多いんです。
駄目でした。
13.11 が正式リリースされたらまたやってみます。

>>695
蒸留水だと微量の漏れに気付きにくいですね。
数週間後にホースがクーラントの自重でゆがんでフィッティングの部分から微量に漏れたりします。
特にKoolanceのクイックリリースは漏れやすいので気をつけて下さい。

>>697
う〜ん、残念… ドライバ周りは本当に難しいんですよねえ。

>>692,696
初期の頃の記録を貼っておきますね

【トリップ検索】CUDA SHA-1 Tripper【GeForce】
http://anago.2ch.net/test/read.cgi/software/1311428038/
16 名前：1[sage] 投稿日：2011/08/01(月) 01:38:03.10 ID:QqRMCqFa0 [1/3]
GTX 580を951/1902/2203にオーバークロックして808.54M tripcodes/sが
出ました。

もともと772/1544/2004だったのでかなり無理をしています。
ファンは85%でこれ以上はMSI Afterburnerでは上げられないようです。
GPUの温度は68℃なので問題ないはずですが、ファンが掃除機のようです…

166 名前： ◆MERIKEN4.k [sage] 投稿日：2011/08/13(土) 16:16:02.74 ID:qrBcmYtV0 [8/10]
というわけで>18、>>30と>>62に続けて最高速の測定をしてみました。

> Searching for 1 pattern with 7 characters.
> 0.096T tripcodes were generated in 0.032 hours at:
> 831.07M tripcodes/s (current)
> 845.02M tripcodes/s (maximum)
> 836.98M tripcodes/s (average)
> No matches were found yet.

最高速がやたらと大きいのは測定の間隔を短くしたためですが、
平均を>>62と比べても微妙に速くなっています。
やはり1タゲだとかなり無茶ができます。
明日配布パッケージをまとめて、うｐしよっと。

>>698
なるほどなるほど… 朝晩まめにチェックすることにします。

>>700
あの頃はまさか速度が2年で15倍になるなんて考えてもみませんでしたからねえ。
思えば遠くへ来たものですｗ

>>698-701
何か、水冷って敷居がそれほど高くも無いのかな？っと思った瞬間に叩き落された気分です。
読んでいるこっちが液漏れしてPCを駄目にしてしまわないか心配で胃が痛くなりそうｗ
自分は取りあえずまだまだ空冷で良いかな？

Win8.1にアップデートしてRadeonの検索速度が500Mも低下し悲しんでいたのですが
解決策が見つかりました
CPUにも2スレッド検索を割り当てたところ（CPU40M）
5000M→5700Mへと上昇しました

うーん、AMD環境ですけどCPUが本気出さないとドライブ能力が落ちるんですかね？
Win8.1ふしぎ！

インフレに追いつけない！

水冷って、車みたいに特殊な液体なの？
それとも、普通の水？

水冷は精製水とか使います
専用の水も売られているので調べてみたらどうでしょう

>>706
　>>695 バイク用のクーラント 蒸留水

>>699
> う〜ん、残念… ドライバ周りは本当に難しいんですよねえ。
グラボの検出って、どうやってるのですか？
例えば何かの関数コールだったら、その部分だけを実行して、
どんなエラーコードが返ってるのか見てみたい・・・

>>709
とりあえずclinfoしてGPUがOpenCLとして認識されるか見てみてはどうだろうか。
あと自分も同じように認識されなかったときは、GPU-ZしてみたらOpenCLのバグがどうたら言われたので、
これ参考にOpenCLを再インストールしたら直った
http://ameblo.jp/crazyhand/entry-11146554730.html

>>710
> とりあえずclinfoしてGPUがOpenCLとして認識されるか見てみてはどうだろうか。
clinfo ってのが見当たらないので実行出来なかったけど、

> あと自分も同じように認識されなかったときは、GPU-ZしてみたらOpenCLのバグがどうたら言われたので、
GPU-Z では正常に認識しました。

> http://ameblo.jp/crazyhand/entry-11146554730.html
後はこれか・・・

>>703
まあ組み立てはかなり気を使ってやったので大丈夫だと思いますよｗ
水冷化でグラボの温度を全く気にしなくても良くなったのは大きいです。
またなにかあったらここで詳しく報告するので是非参考にして下さい。

>>709
グラノの検出の処理はごく簡単で、clGetPlatformInfo()とclGetDeviceIDs()を呼び出している
だけです。グラボが検出されないときにはCL_DEVICE_NOT_FOUNDが返ってきているので、
それ以上アプリケーションの側で出来ることはないのです。「難しい」と書いたのは、
ドライバの問題はアプリケーションの側から解決することは難しい、という意味です。

【科学】東大、コンピューター消費電力を１万分の１以下にできる技術を開発
http://uni.2ch.net/test/read.cgi/newsplus/1383587175/

>>704
それはよかった。相変わらずAMDのドライバの挙動はワケがわかりませんねえ。

>>705
だんだんドラゴンボール的な何かになってきましたねｗ

>>715
AMDはMSのほうで省電力関係の実装が変わったのでしょう
C'n'Qを切ってしまえば問題なくなると思いますが
人は検索のみに生きるにあらず(^^;

>>675
> 新生検索君一号を作るにはいくらかかりますか？

色々買い足していったので二昔前ぐらいのPCが買えるぐらいになってます。

> やっぱり注水とかも自分でやるんですか？

もちろんです。リザーバ(真ん中の透明な筒)に蒸留水を溜めてから、
ポンプを動かしてやります。何回か繰り返せばループが水で満たされます。

>>716
ははあ、なるほど。こういうのって実に紛らわしいですねえ。

>>717
アクアリウムの外部濾過器を連想しちゃいますねｗ

トリップ戻すの忘れてたｗ

自分もアクアリウムやってるんですけど
外部ろ過で水流を回して”水槽内にグラボを設置"するのもアリかなと思いました。
だれかが水冷ＰＣ上部で金魚飼ってたので可能なのかなとｗ

テスト

>>717
PC98のころの1台30万円みたいな感じですかね

他の人が注水をやっているところの動画を見たんですが
子供のころにやった水遊びを思い出してすごく楽しそうに見えましたｗｗ

>>327とか見るとTITANはCUDA(OpenCL)がかなり弱いみたいな感じだけど、下の記事みたいにDPフルスピードに切り替えてもnVIDIA系は速くなれないの？
ttp://www.4gamer.net/games/204/G020420/20130220002/

>>724
トリップ計算は整数演算なので、DPオンにしても早くなりません。むしろ遅くなります。
MTFがRadeonと比べてTITANで遅いのは、前の世代のFermiに最適化されていているのも大きいと思います。

>>725
> MTFがRadeonと比べてTITANで遅いのは、前の世代のFermiに
> 最適化されていているのも大きいと思います。

これ、確かに10桁トリップ検索についてはその通りなんですけど、
比較的単純な12桁トリップ検索の場合だとちょっとよくわからないですねえ。
実際12桁トリップ検索のCUDA版とOpenCL版はほとんど同じで、
アーキテクチャ毎の最適化の余地は殆ど無いものと思われます。

>>726
> 実際12桁トリップ検索のCUDA版とOpenCL版はほとんど同じで、
> アーキテクチャ毎の最適化の余地は殆ど無いものと思われます。

これ、前から不思議に思っていました。
以前、GPGPUへの移植を手掛けるソフトウェアハウス数社に聞き取り調査を行いました。
全ての企業が、Teslaを使う場合はOpenCLよりCUDAの方が早いと言っています。(nvidiaバイアスがかかっている可能性有り)
これは、メリケンさんの手作業最適化が凄いのか、整数と倍精度で違うのか、その他の要因が有るのか、よく分かりません。
私は、メリケンさんが凄いのだろうと何となく思っています。

MTEのソース、早く読まないと。(涙)

OpennCLにしろCUDAにしろハードを叩くソフトウェアレイヤーなわけで
徹底的に最適化すれば性能はハード依存になるのではないのかな？
メリケンさんがそこまで到達しているのでしょう

＃AMD環境でのWin8.1で本気出さない問題はC1Eを有効にすることで最終的解決を見ました
これでOSに拠らずCPU側の省電力機能を使ってくれるようになります

Radeonと比べてTITANで遅いのは単に整数演算が遅いからでは無いでしょうか？
スループットの表なんかを見た感じではGeForceは整数が遅そうです

GCNなRadeonからはまだかなり搾り取れそうですけどね〜
今年いっぱいは本業が忙しいので、来年から本格的にGCNのアセンブラに取り組む
予定です。

GCNな環境になったので動作報告を。

【診断の種類】検索速度(1パターン)
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Beta 2
【OS】Win7 Pro 64bit SP1
【CPU】Core i5 3570
【GPU】RADEON HD 7790(1030MHz動作)
【ディスプレイドライバ】Catalyst 13.9
【検索デバイス】GPUのみ

【トリップの種類】12桁
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【1CUあたりのワークアイテムの数(OpenCL)】自動
【10分間のGPU検索の平均速度】 735.20M tripcode/s

【1CUあたりのワークアイテムの数(OpenCL)】5120
【10分間のGPU検索の平均速度】 1008.71M tripcode/s

【1CUあたりのワークアイテムの数(OpenCL)】10240
【10分間のGPU検索の平均速度】 1043.68M tripcode/s

【1CUあたりのワークアイテムの数(OpenCL)】20480
【10分間のGPU検索の平均速度】 1062.77M tripcode/s

【1CUあたりのワークアイテムの数(OpenCL)】32768
【10分間のGPU検索の平均速度】 1067.86M tripcode/s


1CUあたりのワークアイテムの数を極端に大きな数値にした方が
速度が出ます。うちのPC環境がなんか変なんだろうか？ｗ

続いて10桁トリップ検索です。
環境等は、>>731と同一です。

【トリップの種類】10桁
【キーに使用する文字】半角と全角
【検索パターン】 10文字完全前方一致1個

【1CUあたりのワークアイテムの数(OpenCL)】自動
【10分間のGPU検索の平均速度】 45.63M tripcode/s

【1CUあたりのワークアイテムの数(OpenCL)】512
【10分間のGPU検索の平均速度】 38.72M tripcode/s


こちらは自動が一番速いです。
（512に設定するとGUI周りが軽くなるので、通常はこちらを使用しています）

GCNだと10桁トリップ検索をできるのが(・∀・)ｲｲ!!

GCN大勝利！！！！！

うちのA6-1450も「初のクアッドコアSoC」とか初の「GCN搭載APU」なKabini/Temash世代なんだけど、
全部を1チップに収めるのには成功したけど、メモリ空間はまだCPUと内臓GPUで別々なせいか、
同じ10桁検索でもCPUと内臓GPUで別々のプログラムで探索させた方が速度が出るんだよね。
また、APU本体の消費電力が8WでもノートPC全体では22Wに増えてしまうのはワッパに対してどうなんだろうですが…

これが次のKaveri世代になるとバーチャルメモリ空間をCPUと内臓GPUで同じにするというらしい。
この辺の詳細は11月11-13日のAPUサミットで語られるというので楽しみですね。
ttp://developer.amd.com/apu/
製品自体は来年の2月頃との事ですので、安くてよさげなら買ってA6-1450と比べてみたいです。
ttp://northwood.blog60.fc2.com/blog-entry-7176.html

あ、トリップ忘れてた…失礼。

>>731
>>732
7790は新しい世代のGCNなので違うのかもしれませんねえ。
「各種診断」の「デバイス診断」の結果を貼っていただけたら
次のバージョンでパラメータを調整しておきます。

>>732
7790でも結構速度が出ますねえ。これは290Xにはかなり期待できそうです。

>>734
ようやくAPUにもGCNが下りてきたんですね。

> メモリ空間はまだCPUと内臓GPUで別々なせいか、
> 同じ10桁検索でもCPUと内臓GPUで別々のプログラムで
> 探索させた方が速度が出るんだよね。

ちょっとこれは不思議ですね。CPU検索スレッドの数をめいっぱいあげれば
1つのプログラムで同じ速度が出るかもしれません。

朝起きたら新生検索君1号が止まってて再起動してもGPUを全部認識して
くれなくてかなり焦りました。が、片方の7990を無効にしたりして何回か
再起動を繰り返してたらもとに戻りました。

原因がはっきりしなかったので、とりあえず電圧を少し盛って1250mVに
しておきました。これでも問題が出るようならクロック周波数を落とす予定です。
やっぱり構成をいじると安定稼働させるのにかなり時間がかかりますねえ。

>>738
内臓GPUというのが関係しているのか解りませんが、A6-1450はOpenCLの設定の変化でCPUの速度までも変化するんですよ。
結果「GPUとCPU」で内臓GPUの性能を上げるとCPU性能が下がってしまい、CPUのみと変わらないスコアに…
だから個別のプログラムでCPU用の設定と、GPU用の設定を施すと両方の最大性能が引き出せるという…
良く解りませんねorz

うーん、また止まってしまった… やっぱり7990を1100MHzにしての常時稼動には
ちょっと無理があったみたいです。電圧を戻して1050MHzまで下げてみました。
今度はどうかな〜

>>740
スレ的にはこの手の実践的な知識を蓄積するのは大事ですね。
新生検索君1号も体を張って貢献してくれていますｗ

初心者ですが今、インストールしました。
使い方などを教えてくれませんか？
初歩的な質問ですみません

>>742
まずREADME.txtを読んで下さい。

うーん、まだ安定しないなあ。新しいドライバを試してみようかしらん。

>>743
解凍は出来ています。
色々検索したところ私の使っているPCはx32の為、開けないようです。
この場合、このソフトを使うのは無理なんですかね？

>>745
どんな環境で何をしたらどうなったかを具体的にお願いします。
ちゃんとREADME.txtに書かれている手順には従いましたか?

>>746
README.txtを調べたのですが解凍ソフトしか出てきません。。。
win7、x32で、ダウンロードしたMERIKEN's Tripcode Finderを開こうとした結果、x68かx84のどちらか確認のうえ開発者に問い合わせしてくださいと表示されました。

>>747
README.txtというのは解凍して出来たフォルダの中に入っているものですよ
解凍出来ないということですか？

>>748
一般ブラウザで検索できるんですね
解決しましたありがとうございました。

>>747
zip形式だから、Windows標準の方法で開けるはず(Vista以降とXPとで方法は違うが)
……ひょっとして今まで拡張子が「.exe」のソフト(インストーラ形式)しかダウンロードしたことがない？

ああ、配布されてるMERIKEN's Tripcode Finderは拡張子が「.zip」、
要するにデータが圧縮されてるから、ファイル解凍ソフトを使えば解凍できるってことね。
(親切にもzip形式なら別途ソフトをダウンロードしなくてもExplorer付属のソフトで解凍できる)
XP：http://www.rescueme.jp/support/faq/00017.html
Vista以降：http://faq.epsondirect.co.jp/faq/edc/app/servlet/relatedqa?QID=010809

よくわからないけど
ファイルを右クリックから展開ですよー

>>749
これはゆぐちゃんのことなんだろうか…

検索君が不安定になっていた原因が分かりました。
またPCIeの電源ケーブルが溶けていたという笑撃の結果でしたｗ
取りあえずケーブルを交換してGPUの電圧を下げて対処することにしました。
次からはまっさきに疑わないといけないですね。
水漏れの心配もあったので心臓に悪すぎでしたけど、
簡単に解決できる問題でよかったです。

電源ケーブルを溶かす程の圧倒的パワー恐るべし！

>>754
ケーブルはPowerLimitを20％とかに上げているとヤバいです
私の経験上7970だと1.2Vを超えた辺りから過電流の危険、コネクタ溶けます
うちの7970はこんな感じに落ち着きました（各種ベンチが通る電圧）

http://uproda11.2ch-library.com/e/e00008027-1383883488.png

>>756
かなり盛ってますね〜
PowerLimitは0%だったんですが、7990の電圧がデフォルトで1200mVと高めに
設定してあったらしく、1100MHzで稼働させてたらやられてしまいました。
Afterburnerのバージョンを上げて電圧がいじれるようになったので、
1120mVに設定しておきました。消費電力はかなり下がったのでもう大丈夫でしょう。

MTF1.1FEβ2を使っています。
睡眠時に検索を停止するのを忘れ実行したまま
ハイバネートし、帰宅後PC立ち上げました。
するとMTFの検索時間が18時間となっておりハイバネートしていた時間も含まれていました。
累計時間はTMF上では1日12時間で
ユグドラシル上では21時間となっています。

おそらくですが開始時刻と現在時刻の差を
検索時間としているのではないかと考え
仕様かなとは思いますがお伝えします。

>>736
すいません。デバイス診断というのが見当たらないのですが、検索デバイス一覧でしょうか？

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

CPU
===
Processor Info: 0x0306a9
Number of Logical Cores: 4
Number of Search Threads: 2


あと、気になって過去ログを検索してみたのですが、7790の12桁トリップ検索（設定は自動）で
普通に速度が出ている方も居る様です。

【トリップ検索】MERIKEN's Tripcode Finder その3
http://anago.2ch.net/test/read.cgi/software/1362648003/774

>>758
たしかにこれはありますね。検索君は24時間稼働が基本なので全く気づきませんでしたｗ
次のバージョン(1.2)で修正できないか検討してみます。

>>759
それのことです。同じカードで違う結果が出ているのは不思議ですねえ。
CPU検索の有無が関係してるんでしょうか。

>>760
CPUとGPUの同時検索を試してみましたが、GPU検索速度は同様でした。
あと、キーに使用する文字で”すべて”を試してみましたが、変化は有りませんでした。

なんか、こちらの固有の現象っぽい様な感じがｗ

SkyLake世代のAVX-512は楽しみですね。
SHA-1のアクセラレーション命令も別途載るので、どっちが速いのか
（あるいは併用できるのか）は興味が尽きません。

検索君の画面が映らなくなってかなりビビったのですが、
原因はディスプレイ用の変換アダプタの故障でした。
やれやれです。しかしこのPC、心臓に悪すぎるだろう…

酷使しているといつ

途中で送信してしまった…
酷使しているといつガタがきてもおかしくないですからね
何か起こるとヒヤッとします

ほんとにそうですよね〜
水冷化して保証が効かなくなったのでスリル満点ですｗ

水冷化して温度の問題が解決しても油断禁物ですね

>>762
AVX-512は本当にメインストリームに下りて来るんですかねえ。
まあでもyasmさえ対応してくれればMTFは拡張可能なようにしてありますけど…

AVX-512ってまた浮動小数点演算だけ前回と同じテクニック(256ビットの整数パイプを使う)でできるようになって
AVX2みたいに次のマイクロアーキテクチャで整数もできるようになる
みたいな感じなのかな

>>767
まあかかってる負荷が滅茶苦茶ですからねえ。
以前ブログで7990x4を試してみたいなんて書いちゃいましたけど、
2枚だけでもえらいことです。

>>769
今回は出し惜しみは勘弁してほしいところですｗ

>>761
ドライバの違いかもしれないし、ちょっとよくわからないですねえ。
GCN2.0の環境も揃えたいところです。

>>768
AVX,AVX2だってメインストリームPC向けのほうがXeonDPより
1年先行してたし、XeonとCore*は共通設計なので、
意図的に無効にしない限りは使えるものかと。

SHA-1アクセラレーションサポートに至ってはARMv8でも
標準機能として組み込まれてますし。

>>769
319433-015.pdfの
> Figure 2-1. Procedural Flow of Application Detection of AVX-512
> Foundation Instructions
を見る限り特に整数用と浮動小数点用でフラグが分かれてるような
記載も無いので、

AVX512FのFってなんだって思ったけど、正式名称が「AVX-512 Foundation」なんです。
じゃあFoundation(基本)じゃないAVX-512って何なんだって思うわけだけど。。
(Knights CornerのSIMD命令は公式名称らしい名前がないけどあれがそれにあたるのかなと)

YASMはでかすぎてソース読んでないけどXbyak程度ならちょっと改造すれば
512対応できますよ。というかXeon Phiの命令セット仕様書読んで
なんとなく書きなぐったコードが手元にあったり。

C++で{}は演算子として使えないので()か[]で代用することになりますが・・・

ああそうだ。これを言わないと。

>>28
1〜5ラウンド目は初期値が定数なのでほんの少しショートカットできますよ。
というか、キーの変更方法をちょっと弄るだけでぶっちゃけ
10ラウンド目くらいまではショートカットできてしまいます。

DESクラックも実効10ラウンドまで削れるという論文が出てたけど
あれはStandard DESの場合で、16ラウンド×25の400ラウンドなので
せいぜい394ラウンドのショートカットになる程度です。
（salt処理を考慮すすと実際にはここまでは削れません）

あと今更だけどVecTripperのこれが気になりました。

> いまさらAVXに対応してみた (12桁のみ)
> 3オペランド化で余計なmovdqaを消して、VEXエンコーディングで命令長が
> 削れるものを削った程度なのですが、何故かSSE版と比べて25%ぐらい
> 高速です。16bytes/clkのフェッチ帯域がクリティカルだったのだろうか。

SSEのコードだとぱっと見2000命令軽く超えてるのでそれだけで
μOPs cache流しちゃってますね（AVX*でギリギリ？）
SHAコアのコードを分割して何十個か単位でまとめてループ処理させると
μOPs cacheの利用効率あがるんじゃないかと思ったり。


ああ、おいらはこっちには復帰しませんけどね

あ、2chに書き込めるようになったんですね。いらっしゃいませ〜

>>773
なるほどなるほど。しかしSHA-1専用命令ってそんなに効率がいいんですか。
f1, f2, f3やROTLを処理してくれるのかな? AVX-512より速いわけ無いと
思ってましたけど、興味が出てきました。

こんにちは。

SHA-1拡張は複数

16並列

> f1, f2, f3やROTLを処理してくれるのかな? AVX-512より速いわけ無いと
> 思ってましたけど、興味が出てきました。

SHA-1はAVX-512の命令セットマニュアルのChapter8に載ってますが
専用回路が載るっぽいですね。
SHA1RNDS*とSHA1NEXTEの組み合わせで各ラウンドを処理できるようになってます
理屈上160命令＋α程度でSHA-1の80ラウンドを処理出来てしまいます。

AVX-512による16並列処理とどっちが速いかといえば、16並列のほうが
スループットは稼げる気はしますが
命令発行ポートの制約さえなければ両方を同時に動かすことだって
おそらく可能なわけで、割と気になる命令です。

上にノイズが載りましたが気にしないでください

>>778
SHA-1専用回路なんだからきちんと全部計算するんだよな。
それだったらトリップ用に削りまくった自作処理のほうが高速かもよ。
インテルコンパイラのSHA-1関数とかそんなに速くなかったし。

俺の嫁ktkr

＞SHA-1専用回路なんだからきちんと全部計算するんだよな。

いや、AESと同様に、各ラウンドを2命令でこなせる命令を追加するだけよ。
VIAのPadLockみたいなレジスタにセットして1命令発行したらハイ完了
みたいなインターフェースではない。
どのみちAESほどには並列化できるところがないからそれほど速くなんない
と思われ。

差分解読法はSSEだろうがAVXだろうがOpenCLだろうが使えるテクだけど。
前半を事前計算してキー変更の差分だけ計算するにしても、70ラウンド程度はかかるでしょ。
数学的にエレガントなショートカット方法があるなら俺も知りたい。
（どのみちSHA-3がアナウンスされてるご時勢にSHA-1はオワコンな気がするけど）

> インテルコンパイラのSHA-1関数とかそんなに速くなかったし。
ソフト処理じゃんあれ。
ハード超えられるわけが無いよ

>>774
XbyakのJITアセンブラのアプローチはなかなか面白そうですねえ。
これってMTFで使って効果あるものなのかしらん。