13/09/15 12:33:10.50 yp7r3EBt0
■関連リンク
トリップ総合ウェブサイト「tripcode.net」
URLﾘﾝｸ(tripcode.net)
分散トリップ検索サービス「MERIKEN's Tripcode Ygdrasil」
URLﾘﾝｸ(tripcode.net)
■関連スレ
【分散トリップ検索】Meriken's Tripcode Yggdrasil
ｽﾚﾘﾝｸ(esite板)
■過去スレ
初代 ｽﾚﾘﾝｸ(software板)
無印 ｽﾚﾘﾝｸ(software板)
その2 ｽﾚﾘﾝｸ(software板)
その3 ｽﾚﾘﾝｸ(software板)
その4 ｽﾚﾘﾝｸ(software板)
■過去スレのログ
初代 URLﾘﾝｸ(unkar.org)
無印 URLﾘﾝｸ(unkar.org)
その2 URLﾘﾝｸ(unkar.org)
その3 URLﾘﾝｸ(unkar.org)
その4 URLﾘﾝｸ(unkar.org)
3: ◆Meriken//XXX
13/09/15 12:35:55.96 yp7r3EBt0
■最高速の記録
> 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%
ｽﾚﾘﾝｸ(software板:139番)n
4: ◆Meriken//XXX
13/09/15 12:37:42.95 yp7r3EBt0
テンプレは以上です。このスレでもよろしくお願いします。
5: ◆Meriken//XXX
13/09/16 10:55:31.85 qZcMxCLl0
新しい開発版をうｐしました。
MERIKEN's Tripcode Finder 1.1 Free Edition Alpha 3
URLﾘﾝｸ(www.meriken2ch.com)
Alpha 2からの主な変更点は以下の通りです。
・全角文字をキーに使用したときのヒット率の向上。
・キーに使用する文字の種類の追加。
・12桁トリップのCPU検索の速度向上。
・10桁トリップのOpenCL版のGPU検索の速度向上。
6: ◆Meriken//XXX
13/09/16 11:15:29.67 qZcMxCLl0
あ、あとこれを>>5にたしとくのをわすれてましたｗ
・破損した設定ファイルを自動的に修復する機能の追加。
7:やんやん ◆yanyan/Pails
13/09/16 11:56:10.30 p7PA/eiR0
おお、お疲れさまです。試してみますね。
8: ◆Meriken//XXX
13/09/16 15:53:52.35 qZcMxCLl0
さっそくAlpha 3にバグがorz
Radeonを使っててGPUが複数あると、検索がいつまでたっても始まりません。
原因はわかっているのですが、これどうやって修正しようかな…
9: ◆Meriken//XXX
13/09/16 17:09:07.51 qZcMxCLl0
一応修正は出来ました。これから配布パッケージを用意します。
10:名無しさん＠お腹いっぱい。
13/09/16 17:09:42.52 okVXgfDbP
この前α1とα2で速度に差が出ると言っていた者です
α3はα1のときの速度になりました
(21MT/sです)
11:名無しさん＠お腹いっぱい。
13/09/16 17:10:54.81 okVXgfDbP
12桁の方も戻ってました
85MT/sです
12: ◆Meriken//XXX
13/09/16 17:34:07.90 qZcMxCLl0
新しい開発版をうｐしました。
MERIKEN's Tripcode Finder 1.1 Free Edition Alpha 4
URLﾘﾝｸ(www.meriken2ch.com)
Alpha 3からの主な変更点は以下の通りです。
・Radeonのビデオカードを使用していてGPUが複数あると検索できない
不具合の修正。
13: ◆Meriken//XXX
13/09/16 17:35:12.77 qZcMxCLl0
>>10-11
摩訶不思議ですね～
いずれにせよ戻ってて安心しました。
14:名無しさん＠お腹いっぱい。
13/09/16 17:44:07.15 okVXgfDbP
修正おつかれさまです
α4も大丈夫でした
15: ◆JouJaku.IYSv
13/09/16 18:26:02.56 E6LpH9zS0
>>8
バグでしたか。モロそのバグに引っかかって悩んでました。
今Alpha 4で動作を確認しました。
16: ◆Meriken//XXX
13/09/16 18:40:29.99 qZcMxCLl0
>>15
いや～申し訳ないです… そろそろプロセス間通信周りを綺麗に書き直したいんですが、
デバッグの手間を考えるとなかなか踏ん切りがつきません。
17:名無しさん＠お腹いっぱい。
13/09/16 23:59:46.48 Hbh3MH0b0
質問すみませんが
Alpha 4の「キーに使用する文字」の
「半角と全角」と「すべて」の違いは何でしょうか？
Alpha 4のデフォルトですと「すべて」ではなく「半角と全角」が選択されるようですが
Alpha 2以前の「すべて」に相当するのは
Alpha 4の場合は「半角と全角」になるのでしょうか？
18:名無しさん＠お腹いっぱい。
13/09/17 01:08:10.52 cQ7VTAce0
上で質問した者ですが
各種診断を使ってみましたところ
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を使っています
19:名無しさん＠お腹いっぱい。
13/09/17 01:09:10.52 cQ7VTAce0
・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
20:名無しさん＠お腹いっぱい。
13/09/17 01:10:13.06 cQ7VTAce0
・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
21:名無しさん＠お腹いっぱい。
13/09/17 01:11:01.48 cQ7VTAce0
・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
22:名無しさん＠お腹いっぱい。
13/09/17 01:12:47.88 cQ7VTAce0
ということで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で落ちてしまいましたので
一応ご報告しておきます
23: ◆Meriken//XXX
13/09/17 04:36:22.46 7sJN/t4X0
>>17
> 「半角と全角」と「すべて」の違いは何でしょうか？
「半角と全角」の場合は全角文字の一部は使用されませんが、
「すべて」の場合は全部使用されます。
その代わり、「すべて」を選ぶとヒット率が3%ほど落ちます。
> Alpha 2以前の「すべて」に相当するのは
> Alpha 4の場合は「半角と全角」になるのでしょうか？
Alpha 2以前の「すべて」は、Alpha 4の「すべて」と同じです。
24: ◆Meriken//XXX
13/09/17 04:55:34.82 7sJN/t4X0
>>18
あ～診断の表示を変更するのを忘れてましたorz 診断の結果は正しいはずです。
>>19-22
詳しい報告有り難うございます。HD 5xxx/6xxxだとOpenCLコンパイラのバックエンドが
あまり賢くないせいか、ちょっとコードを変更するだけですぐに速度が落ちちゃうんですよね。
速度を戻すことが出来ないか試してみますが、難しいかもしれません。
25: ◆Meriken//XXX
13/09/17 11:23:18.74 7sJN/t4X0
>>18
5770ではほぼ元の速度を出せるようになりました。
6850と5770のアーキテクチャは同じVLIW5なので、多分大丈夫でしょう。
26:やんやん ◆yanyan/Pails
13/09/17 11:31:20.26 VA97SuCR0
TITANでalpha4を試したところ、
1500M tripcode/s
いきました。
27: ◆Meriken//XXX
13/09/17 20:30:57.15 7sJN/t4X0
>>26
お、こっちは速くなってますね。
しかしTITANももっと速くてもいいぐらいなんですけどね～
自分でいじれないのがちと歯がゆいです。
28: ◆Meriken//XXX
13/09/17 21:13:17.75 7sJN/t4X0
12桁トリップのCPU検索をアセンブラを使って書き直せないか現在思案中。
多分SSE2だけでも数割速くなるだろうし、AVX/AVX2ならさらにそこから
上乗せ出来そうなんですけど、どうかなあ。
というわけでちょっと調べたら、VecTripperに再利用出来るアセンブラのコードが
あったので、これを使うことにしました。ライセンス的にも問題ないようです。
1から書くのはなかなかしんどそうなので、ありがたいことです。
29: ◆Meriken//XXX
13/09/17 21:24:16.96 7sJN/t4X0
そういやSHA-1のルーチンはかなり最適化してたから、
このままじゃ使えないんだよなあ。どうしたものか。
30: ◆Meriken//XXX
13/09/17 21:40:56.67 7sJN/t4X0
SHA-1のルーチンをじっと眺めていたら、
キーの長さをSHA-1のブロックのサイズにあわせて64文字に
することによって、更に最適化出来そうなことに気づいてしまいましたｗ
今のままでも工夫してやればラウンドを2つループの外に追い出せそうです。
31: ◆Meriken//XXX
13/09/17 22:16:20.98 7sJN/t4X0
あ、448bitだから64文字じゃなくて54文字か。
で、最大で最初の13個のラウンドを追い出せるわけね。
80個のラウンドのうちの13個ってかなり大きいよな。
単純に考えれば2割ほど高速化できる計算です。
だけど2chで56文字のキーなんて使えるのかしらんｗ
32: ◆Meriken//XXX
13/09/17 22:40:57.21 7sJN/t4X0
54文字じゃなくて56文字だった。
56文字のキーは2chで普通に使えました。
でもMTFを56文字のキーに対応させるのは
さすがに手間が大きすぎるような…
まあこのネタは取っておいて、とりあえずアセンブラで書き直そうっと。
33:名無しさん＠お腹いっぱい。
13/09/18 07:15:46.99 OzF80bCr0
>>23-25
どうもありがとうございます
アーキテクチャの違うハードを
それぞれ最適な性能が出るようにサポートするというのは
ものすごく手間のかかることと思います
お手数をおかけして申し訳ありませんでした
34:やんやん ◆yanyan/Pails
13/09/18 08:38:51.53 mB6Net9h0
>>27
どうもです。余分なグラフィックを切ってなかったり、
TITANのくせにPCI-Express2.0接続だったりするので、
TITANとしては遅いかもしれません。
GPGPUコンピューティンの時にはPCI-Expressバスの問題は
どうせCudaMemcopyなどは最小限にしてるでしょうから
関係ない気もしますが。
35:名無しさん＠お腹いっぱい。
13/09/18 17:03:41.23 5Sc3kbYV0
MERIKENsTripcodeFinder_1.1_FE_Alpha_2 だと全く問題ないのに、
MERIKENsTripcodeFinder_1.1_FE_Alpha_4 だとエラーで動かないのは
何が原因と考えられますか？
36: ◆Meriken//XXX
13/09/18 17:16:42.94 0UI9u6yeP
>>35
エラーの種類とか、出現条件とか、もうちょっと詳しくおながいします。
■ バグ報告用のテンプレ
バグを報告する際には下のテンプレを使ってなるべく詳しく
具体的に報告して下さい。
【症状】
【バージョン】MERIKEN's Tripcode Finder x.xx
【トリップの種類】12桁・10桁
【GPU】
【CPU】
【OS】
【Display Driver】
【その他】
37:名無しさん＠お腹いっぱい。
13/09/18 18:01:45.41 VtUincUUP
12桁のトリップのYggdrasilでの分散探索についてですが
2chは64文字より長いトリップキーが使えるということは
SHA1で1ブロック目の計算はサーバーでやって
1ブロック目で使われる最初の64文字のキーはクライアントに送らずに
2ブロック目以降で必要になる1ブロック目から計算される情報だけをクライアントに送り
クライアントは2ブロック目以降をランダムに生成してトリップを探索する
こうすれば1ブロック目のキーはサーバしか分からないからリバースエンジニアリングされてもクライアントに漏洩されずに済む
こんなのを考えたんですがどうでしょうか
38:名無しさん＠お腹いっぱい。
13/09/18 18:03:53.95 VtUincUUP
発見されるトリップのキーが常に64文字以上になるのが欠点ですが
39: ◆Meriken//XXX
13/09/18 18:50:04.20 0UI9u6yeP
>>33
いや～これ気づかずに放置するところでした。ありがとうございました。
MTFはトリップ検索ツールの決定版を目指しているので、
まだまだこれからですｗ ちょっとまとまったお金が入りそうなので、
物欲に任せてi7-4770Kとマザボを買おうかどうか迷っているところです。
40: ◆Meriken//XXX
13/09/18 19:07:56.67 0UI9u6yeP
>>37-38
これは非常に面白いですねえ。キーの漏洩が原理的に不可能というのは
かなり美味しいです。キーの長さは実際どうなんでしょうねえ。
試しに遊びで56文字モードを付けてみようかしらん。
41:名無しさん＠お腹いっぱい。
13/09/18 20:07:49.89 f7vVWxxs0
>>40
非常に面白いけど、メッセージの途中までを依頼側が制御できてしまうってのは色々アレですね。
SHA-1で署名されてるメッセージのラスト以外を捏造したSHA-1中間状態で依頼して…みたいな。
MD5で衝突させた実験はいくつかあったけどSHA1でやれるとちょっと面白い(では済まない？)かも。
42: ◆Meriken//XXX
13/09/19 02:49:03.85 sTJqqQfeP
>>41
私はクラッキングには興味が無いですけど、クラッキングに分散処理を利用するというのは
ありなのかもしれませんねえ。Bitcoinマイナーみたいなのにそういうコードを
入れといてもわからないでしょうからね。
43: ◆Meriken//XXX
13/09/19 03:23:02.42 sTJqqQfeP
一応>>30-32をまとめておきます。
・トリップのキーの長さをSHA-1のブロックの大きさに合わせて56文字にすることで、
12桁トリップ検索をさらに2割ほど高速化出来る。
・ループの内部ではW[13]に対応するキーの53文字目から56文字目のみを変化させる。
・SHA-1の最初の13個のラウンドはW[13]に依存しないので、
あらかじめループの外で計算しておく。
・この方法はJens Steube氏のSHA-1ハッシュ値生成の最適化の手法と
組み合わせることも可能。その際はW[0]ではなくW[13]を中心にして計算を行う。
URLﾘﾝｸ(passwords12.at.ifi.uio.no)
鳥屋氏はこのことに気づいていたみたいですが、なかなかにコロンブスの卵的な発想です。
44: ◆Meriken//XXX
13/09/19 04:55:49.99 sTJqqQfeP
これ、こちらにも貼っておきますね。
> 24 : ◆Meriken//XXX : sage : 2013/09/19(木) 04:54:27.08
> そうそう、そろそろYggdrasilのAPIを新鯖に一本化したいので、バージョン1.0 (FE)以前の
> MTFをお使いな方はバージョン1.0.1 (FE)以降に更新をお願いします。
45: ◆Urotsuki/1Ca
13/09/19 07:23:10.54 Ywt2cZ170
次のα版に乗り換えるかな…
46: ◆Meriken//XXX
13/09/19 07:46:53.91 sTJqqQfeP
>>45
結構いろいろ改善されているのでぜひどうぞｗ
>>43の実装がいつになるのかはちょっと分かりませんが…
47: ◆Meriken//XXX
13/09/19 07:56:24.04 sTJqqQfeP
現在VecTripperのSHA-1のアセンブラのコードをせっせとMTFに移植中です。
とりあえずAVXで最初の14個のラウンドが動作することを確認しましたが、
かなり速いです。さすがです。これはかなり期待できそうです。
48: ◆Meriken//XXX
13/09/19 09:55:12.24 sTJqqQfeP
20回目のラウンドまで変換出来ました。
かなり最適化されたコードみたいで期待大ですが、
気を使う作業なのでとにかく疲れます。
続きは明日以降にしておきます。
49:やんやん ◆yanyan/Pails
13/09/19 13:04:17.26 yhS2wnZ30
アセンブラまで手を出していたのですね。おつかれさまです。
50: ◆Meriken//XXX
13/09/19 14:09:31.68 sTJqqQfeP
アセンブラでないと限界まで速度を出せないですからね～
10桁は書き換えたので次は12桁というわけです。
51: ◆Meriken//XXX
13/09/19 15:17:00.67 sTJqqQfeP
ご飯を食べて元気が出たので、素のSHA-1のルーチンを一気にAVXで書き換えてしまいました。
結果は上々で、2割ほど速度が上がっています。もうちょっといじれば3割まで行きそうな
感じです。
ここまではわりとすんなりと行きましたが問題はこれからで、今度は特殊な最適化を施してある
SHA-1のルーチンを書き換えなければなりません。これは1から書くしかないので、
少しづつ進めていくことにします。
52: ◆Meriken//XXX
13/09/19 18:40:13.43 sTJqqQfeP
あれから素のSHA-1のルーチンの関数呼び出しのオーバーヘッドを
削って、合わせて27%の速度向上となりました。
VecTripperのルーチンは命令を削れるだけ削ってあるという印象です。
素晴らしいです。
最適化済みのルーチンもこんなふうに自分で書き直せればいいけど、
どうでしょうねえ～
53: ◆JouJaku.IYSv
13/09/19 19:10:47.14 SvlqUu4y0
>>39
AVX2対応キターーー! ヽ(´Д｀)ノ
AVX2が目的でHaswellを選ぶなら、高いK付きを選ぶ必要は無いと思います。
HaswellはAVXを使うと極端にOC耐性が落ちます。更に殻割り+液体金属必須です。
K無しを定格で使うのが良い、とK付きで殻割りOCまで試した私は思います。
54: ◆Meriken//XXX
13/09/19 19:52:17.36 sTJqqQfeP
>>53
確かにK付きはいらないですねえ。開発機の3770KもOC切っちゃったし…
その代わりにマザボを奮発してQuad CrossFireが出来るのにしようかな。
AVX-512がコンシューマー市場に下りてくるのは当分先でしょうしね。
55: ◆Meriken//XXX
13/09/19 19:53:29.45 sTJqqQfeP
最適化されたルーチンをじっと眺めてたらなんだか出来そうな気がしてきたぞ。
56: ◆Meriken//XXX
13/09/19 22:14:58.88 sTJqqQfeP
おもむろに少し書き換えてみたらうまくいきましたｗ
こりゃ思ったよりずっと簡単かも。
57: ◆Urotsuki/1Ca
13/09/19 22:45:49.09 Ywt2cZ170
開発が進んでいるようで何よりです
自分はPCの計算力を提供するぐらいしかできませんけど…
58: ◆Meriken//XXX
13/09/20 04:43:57.64 PXGklweqP
いやいや、それだけで十分すぎですｗ
うろつきさん、めちゃ速いですしね。
59: ◆Meriken//XXX
13/09/20 04:50:36.76 PXGklweqP
最適化済みのSHA-1のルーチンのアセンブラでの書き換えは
半分終わりました。既に元のSSE2 Intrinsicsでの実装より大分速くなっています。
思い切って手を付けてみて正解でした。
60: ◆Meriken//XXX
13/09/20 11:51:06.76 PXGklweqP
x64版のAVXでの書き換えは一応終了。
最適化されたルーチンは15%ほど速くなりました。
もうちょっと命令を削れそうな感じです。
61:名無しさん＠お腹いっぱい。
13/09/20 12:28:27.30 rdeXteVM0
>>54
Z87のマザーだと、ASUS MAXIMUS VI EXTREMEがPCIe 3.0(x8/x16/x8/x8)駆動で最大だからQuad CrossFireするには勿体無さそうに思うけどな。
URLﾘﾝｸ(www.asus.com)
Quad CrossFireがPCIe 3.0(x16/x16/x16/x16)で動作保障してくれるマザーってあるんだっけ？
62: ◆Meriken//XXX
13/09/20 12:39:25.81 PXGklweqP
>>61
MTFでつかうぶんにはPCIeの帯域はほとんど関係ないので問題なしです。
買うとしたら検索君1号用なので他の用途には使わないですしね。
もうちょっと安いのでもいいんですけど、スロットの配置がいいのが
ないんですよね～
63: ◆Meriken//XXX
13/09/20 12:52:41.54 PXGklweqP
命令を2つばかり削ってちょびっと速くなりました。
さすがに疲れたのこのへんにしときます。
後はこれをSSE2に移植して、32bit版を作らなきゃいけないんだよなあ。
まあのんびりやろうっと。
とりあえずAVX2対応の準備はできたので十分でしょう。
CPUだけで250M TPS出せるかもしれません。ぐへへへへ…
64: ◆Meriken//XXX
13/09/20 17:44:03.41 PXGklweqP
SSE2版を作って命令を2オペランド化してみたらかえって元のより遅くなったぞorz
たくさん作ってもメンテするの大変だし、アセンブラのルーチンは
64bit AVX/AVX2専用にしちゃおうかなあ。
…と、ここまで考えてから試しにVecTripperの真似をしてvmovdqaをmovaps に
変えたら、それだけでもとより速くなりましたｗ なぜだ…
65: ◆JouJaku.IYSv
13/09/20 20:53:24.14 BxgeVqsj0
>>61
ブリッジ挟んだなんちゃって仕様ならコレ。Haswellではありませんが。
URLﾘﾝｸ(www.asus.com)
なんちゃってなので、グラフィック用です。
大量のデータ転送を同時に行うGPGPU用途には使えません。
Nativeならこれくらい逝かないと無理です。
URLﾘﾝｸ(www.supermicro.com)
66: ◆Meriken//XXX
13/09/21 01:51:06.93 axiLYME3P
>>65
今回の購入のメインはHaswellなので、やっぱりASUSのM6Eですかね～
いやあ、楽しみだなあ。
67: ◆Meriken//XXX
13/09/21 02:05:15.56 axiLYME3P
最適化されたルーチンのSSE2への移植は完了しました。かなり速いです。
今まで58M TPSしか出ていなかったPhenom II X6で92M TPSでました。
Visual C++、効率が悪すぎだろう…
68: ◆Meriken//XXX
13/09/21 02:41:57.42 axiLYME3P
というわけで、64bit版は最適化されたルーチンに
一本化することにしました。これで大分すっきりとしました。
あと32bitだとxmmレジスタの数が足りなさすぎなので、
アセンブラで書きなおすのはやめにしました。
これで後は念の為にもう一回テストするだけです。
69: ◆Meriken//XXX
13/09/21 02:55:33.92 axiLYME3P
あ、でも最適化されたルーチンだけならレジスタ周りはそんなに厳しくないのか。
せっかくだから32bit版も書きなおそうかな。そうすれば大分すっきりするし…
70: ◆YSRKEN.ceVZZ
13/09/21 10:51:27.68 oxIT9/ma0
>>67
>Visual C++
iclですらない……そりゃ徹底的にアセンブラしたら速いでしょうねｗ
これで私もCPUのみで15MTPS逝きそうですな……
71: ◆Meriken//XXX
13/09/21 14:05:50.24 axiLYME3P
>>70
お、お久しぶりです。
Intelのも一応試してみたけどほとんど速度は変わりませんでしたよ。
まあそんなにうまい話は転がってないですね。
限界まで性能を出したいならコンパイラに頼らずに自分でやるしかないですね。
72:最近アマガミをオールクリアしました ◆Ayatsuji/uFC
13/09/21 18:39:07.87 oxIT9/ma0
>>71
>お久しぶりです
すみません、実は久しぶりというわけでもないのです。
うろつき ◆Urotsuki/1Caさんに見つけてもらったこの酉で最近はレスしてました。
諸事情により最近はノーパソをぶん回したまま放置ということができなかったので、レベルが上がりようがないという悲しみ……
ところで、複数PCで同じアカウントでログインしてゆぐちゃんに参加するとポイント(ﾟдﾟ)ｳﾏｰなんですよね？
73: ◆Meriken//XXX
13/09/22 01:22:54.37 PJsMgXLsP
>>72
そういえばそうだったｗ そのトリップを見たのが久しぶりだったのでうっかりしてしまいました。
経験値はちゃんと加算されますよ。
74: ◆Meriken//XXX
13/09/22 05:48:35.29 PJsMgXLsP
新しい12桁トリップのCPU検索のルーチンの32bit版も出来ました。
手元のCore 2 Duoで試したら4割近く速度が上がっています。
やっぱコンパイラの最適化は当てにならないなあ。
とにかく検索ルーチンのアセンブラでの書き直しは終わったので、
明日あたりにGUIの修正と最終テストを行って、新しい開発版をうｐします。
75:やんやん ◆yanyan/Pails
13/09/22 06:06:23.54 RUJc3/SX0
wktk
76: ◆Urotsuki/1Ca
13/09/22 07:42:38.57 B2mxp/B40
wktkですねこれは
しかし相変わらずの化け物じみた速度…
自分は契約Aの問題でこれ以上速度あげられないんだよなぁ
77: ◆shiexn/ngc
13/09/22 07:50:16.88 XeDsKN+sP
同一トリップ 別キー なんてのもちゃんと出てくるんですな
78: ◆Meriken//XXX
13/09/22 09:52:31.01 PJsMgXLsP
TITANより速いとか、これはもう買うしかないのではなかろうか。
発表は25日か～
URLﾘﾝｸ(wccftech.com)
79: ◆Meriken//XXX
13/09/22 10:39:11.32 PJsMgXLsP
>>76
7970 CFにしては抑え気味だなと思ってたんですけど、
そういうことだったんですね。私もこれで結構ギリギリで、
しょっちゅうブレーカーを飛ばしていますｗ
80: ◆Meriken//XXX
13/09/22 10:41:44.63 PJsMgXLsP
>>78のリンクが壊れてました。
URLﾘﾝｸ(wccftech.com)
81: ◆Meriken//XXX
13/09/22 11:16:46.05 PJsMgXLsP
>>72
あ、そうそう。私はアマガミはモジャ子で挫折しましたｗ
梨穂子ちゃんと先輩はなかなか良かったです。
82: ◆Meriken//XXX
13/09/22 13:39:01.91 PJsMgXLsP
新しい開発版をうｐしました。
MERIKEN's Tripcode Finder 1.1 Free Edition Alpha 5
URLﾘﾝｸ(www.meriken2ch.com)
Alpha 4からの主な変更点は以下の通りです。
・12桁トリップのCPU検索のAVXへの対応。
・12桁トリップのCPU検索の高速化。
CPUによってはかなり速くなっているようです。
診断の結果や前のバージョンとの比較を報告していただけると助かります。
83: ◆Meriken//XXX
13/09/22 17:15:27.23 PJsMgXLsP
現在Meriken's Tripcode Engineの英語版を作成中。
プログラムに変更はすぐに終わったけど、
ドキュメントの翻訳が超めんどくさいです。
84: ◆MOYASIMaXI
13/09/22 17:54:35.42 B1RUuJ9x0
>>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
めっちゃ高速化してます。
85: ◆Meriken//XXX
13/09/22 18:58:57.07 PJsMgXLsP
>>84
いい感じに速度が上がっていますね～
AVXがかなり効いてるのかな?
i7-3770Kより差が大きいのはおいしすぎですね。
86: ◆Urotsuki/1Ca
13/09/22 19:02:33.93 B2mxp/B40
おー新しいのきましたか
CPU関連の効率化だけかなー?
GPUメインにはあまり縁がないかなー…
取り敢えず測定してみようっと
87: ◆Meriken//XXX
13/09/22 19:14:24.81 PJsMgXLsP
ぜひお願いします。CPUによってほんとに速度の変化がバラバラなんですよね。
88: ◆Urotsuki/1Ca
13/09/22 19:24:33.69 B2mxp/B40
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しているので定格だとどうなるかわかりませんが上がり幅は同じだと思います
89: ◆JouJaku.HzIz
13/09/22 20:09:04.92 vk+5V6ZE0
【診断の種類】検索速度(1パターン)
【MERIKEN's Tripcode Finderのバージョン】1.1 Free Edition Alpha 4, 5
【OS】Microsoft Windows 7 Ultimate 64bit SP1
【検索デバイス】CPUのみ
【CPU】Intel Core i7 4770K@3.7GHz
【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対応が楽しみです。
90:名無しさん＠お腹いっぱい。
13/09/22 20:28:27.32 Nb3CcrYX0
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
91:名無しさん＠お腹いっぱい。
13/09/22 20:32:12.34 K2dEp/NJ0
すいません、MTF1.1FEのalpha2～4はどこかでDL出来ますでしょうか？
手違いで消してしまいましたｗ
92:名無しさん＠お腹いっぱい。
13/09/22 20:34:35.19 TkU21XXd0
リンク先のファイル名を変えるだけで落とせたと思う。
93:名無しさん＠お腹いっぱい。
13/09/22 20:36:50.06 K2dEp/NJ0
あ、なるほど気が付きませんでした
無事落とせました
94:名無しさん＠お腹いっぱい。
13/09/22 22:59:02.04 K2dEp/NJ0
【検索デバイス】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はバグがあるとスレの初めに話題になってたようなので除外しました
95:名無しさん＠お腹いっぱい。
13/09/22 23:11:48.99 K2dEp/NJ0
診断ではα5のCPU効率が若干低下してますが
検索実測でもα5はα2、4に比べてGPUCPU共
似たような効率低下傾向があるようです
96:名無しさん＠お腹いっぱい。
13/09/22 23:14:16.64 K2dEp/NJ0
あ、これだとCPUが載ってないですね
CPUは intel core i5-750 2.66GHz定格使用です
97:名無しさん＠お腹いっぱい。
13/09/23 00:19:21.07 s2zOHAYz0
>>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)
98:shirawa@mmo ◆GTExxuWcjk/9
13/09/23 05:07:53.88 jhI3+7LxP
【診断の種類】検索速度(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
99:累計 ◆wop.8OO8.qow
13/09/23 05:25:17.49 J8box9ZP0
【診断の種類】検索速度(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
100: ◆Meriken//XXX
13/09/23 05:48:41.37 PDVnzk32P
皆さん詳しい報告を有り難うございます。
どうもNehalemだけ遅くなっているようですね。難しスギィ！
101: ◆LoveNico9g
13/09/23 06:02:36.35 f6HE7yZK0
【診断の種類】検索速度(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
すごい改善率
102: ◆Meriken//XXX
13/09/23 06:25:27.19 PDVnzk32P
>>101
こりゃ凄いですねw 結構さがでるもんですね～
103: ◆Meriken//XXX
13/09/23 06:38:01.05 PDVnzk32P
■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はないほうが効果がはっきり出るみたいです。
104: ◆Meriken//XXX
13/09/23 09:20:51.29 PDVnzk32P
英語版を作って本家Slashdotにストーリーを投稿してみました。
ぜひVote Upをよろしくお願いいたしますｗ
Meriken's Tripcode Engine English 0.01 Released
URLﾘﾝｸ(slashdot.org)
Meriken's Tripcode Engine English
URLﾘﾝｸ(www.meriken2ch.com)
105:名無しさん＠お腹いっぱい。
13/09/23 09:21:02.61 X4S3sHdy0
1.1FEα5の鯖との定期通信の間隔は
・検索開始3分後までが10秒ごと
・以降3分ごと
でよろしいでしょうか？
106: ◆Meriken//XXX
13/09/23 09:25:06.77 PDVnzk32P
>>105
そうで～す。このパラメーターはサーバー側で調整できるので、
サーバーが重くなってきたら増やすかもしれません。
107:名無しさん＠お腹いっぱい。
13/09/23 09:40:34.70 rVyLE6uw0
【診断の種類】検索速度(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%弱ってところでしょうか。
108: ◆Meriken//XXX
13/09/23 10:18:13.77 PDVnzk32P
>>107
これもWestmere-EPだからNehalemの仲間ですね。
うまい具合にNehalemだけ検出できないかなあ。
109: ◆Meriken//XXX
13/09/23 10:42:19.95 PDVnzk32P
WikipediaにCPUIDが載ってたけど、これほんとに当てになるのかな～
> 0x0206e6, 0x0106a4, 0x0106a5, 0x0106e4, 0x0106e5
URLﾘﾝｸ(en.wikipedia.org)(microarchitecture)
> 0x0206f2, 0x0206c2, 0x020652, 0x020655
URLﾘﾝｸ(en.wikipedia.org)(microarchitecture)
> 0x0206c0, 0x0206c1, 0x0206c2, 0x0206c3, 0x0206c4,
> 0x0206c5, 0x0206c6, 0x0206c7, 0x0206c8, 0x0206c9,
URLﾘﾝｸ(en.wikipedia.org)
110: ◆YSRKEN.ceVZZ
13/09/23 11:16:32.76 R2WGY9Wb0
>>81
棚町(と七咲)は☆獲得に会話イベントでアタック成功させないと駄目な娘なので……
順番を見るに、WikiのFAQを読みながらやったパターンですかね？
>>82
乙です。早速ベンチしてみますね。
>>108
前に「GPU毎に処理方法変える為にデータベース作るか」と言われていたことを思い出しました……
111:名無しさん＠お腹いっぱい。
13/09/23 11:25:52.53 FllI0LcA0
こんな情報がありました
Intel Architecture and Processor Identification With CPUID Model and Family Numbers
URLﾘﾝｸ(software.intel.com)
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
あたりでしょうか
112:やんやん ◆yanyan/Pails
13/09/23 11:37:42.83 BVWtjWSi0
【診断の種類】検索速度(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
113: ◆Meriken//XXX
13/09/23 12:30:59.59 PDVnzk32P
>>112
やっぱりNehalemだと駄目ですね～
>>111
これで正解ですね。助かります。
Nehalemを検出したら元のルーチンを使うように修正しておきました。
時間のあるときに次の開発版をうｐします。
114: ◆YSRKEN.ceVZZ
13/09/23 13:28:13.13 R2WGY9Wb0
【診断の種類】検索速度(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。
115:名無しさん＠お腹いっぱい。
13/09/23 14:06:20.22 C6NktFR4P
core i7 2700K 定格 HTオン 8スレッド
84Mから105Mに上がりました
116:名無しさん＠お腹いっぱい。
13/09/23 16:21:00.62 L5Ap3lnA0
>>104
> 英語版を作って本家Slashdotにストーリーを投稿してみました。
って事は、これからは外人さんも参加してくれる？
一気に人数が増えるといいな。
117:名無しさん＠お腹いっぱい。
13/09/23 19:43:23.12 dFD9pehG0
>>106
ご回答ありがとうございました
118: ◆Meriken//XXX
13/09/23 20:09:33.41 PDVnzk32P
>>114
>>115
やっぱりNehalem以外では速くなってるんですよねえ…
コンパイラの吐いたコードを調べてみようっと。
119: ◆Meriken//XXX
13/09/23 20:12:23.78 PDVnzk32P
新しい開発版をうｐしました。
MERIKEN's Tripcode Finder 1.1 Free Edition Alpha 6
URLﾘﾝｸ(www.meriken2ch.com)
Alpha 5からの主な変更点は以下の通りです。
・Nehalem系のCPUで12桁トリップのCPU検索が遅くなる不具合の修正。
引き続き前のバージョンとの速度の比較を報告していただけると助かります。
120: ◆Meriken//XXX
13/09/23 20:36:25.71 PDVnzk32P
コンパイラの吐いた無駄だらけのコードを見てたら、movapsの代わりに
movdqaを使っていました。まさかこれが原因じゃあるまいな…
121:名無しさん＠お腹いっぱい。
13/09/23 21:10:26.07 zKQ1y1q50
古いバージョンもあると比較しやすいのかな？
122:107
13/09/23 21:39:06.57 rVyLE6uw0
【Meriken's Tripcode Finderのバージョン】1.1 Free Edition Alpha 6
【10分間のCPU検索の平均速度】 148.50M tripcode/s
とりあえず、戻ったようです。
123:94
13/09/23 21:52:01.56 AdWli9Lo0
α6試してみました
条件は>>94と同一です
【10分間の平均速度】 366.80M tripcode/s
【GPU検索の平均速度】 340.25M tripcode/s
【CPU検索の平均速度】 26.55M tripcode/s
α4の水準に戻ったようです
中身的には暫定的にNehalemを検出してα4のプログラムで
処理してる感じでしょうか？
共通プログラムで全CPUを網羅するのは
なかなか難しいのですね
124:累計 ◆wop.8OO8.qow
13/09/23 23:33:54.95 J8box9ZP0
条件は>>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
よかったよかったｗ
125: ◆Urotsuki/1Ca
13/09/23 23:47:40.78 fLgQz4cK0
修正お疲れ様ですー
明日以降入れとこう…
そろそろ本気だす
126: ◆Meriken//XXX
13/09/24 03:05:07.93 SuYpLKhoP
ちゃんとNehalemを検出できているようですね。かったよかった。
Nehalemを使っている人(Alpha 5で遅くなった人)は
ぜひこちらも試してみてください。
URLﾘﾝｸ(www.meriken2ch.com)
元のファイルに上書きすれば使えます。
あくまでも実験なので、元のファイルは取っておいてください
127: ◆Meriken//XXX
13/09/24 03:06:37.34 SuYpLKhoP
>>125
> そろそろ本気だす
おお、期待してますよｗ
128: ◆Meriken//XXX
13/09/24 03:12:46.79 SuYpLKhoP
と書いたあとでゆぐちゃんの速度見たら凄いことになってたｗ
うろつきさんもさすがですし、◆QZshizo.ptHさんもおひさしぶりですね～
129: ◆Meriken//XXX
13/09/24 06:44:32.39 SuYpLKhoP
これ、こっちにも貼っておこうっと。
> 43 ：◆Meriken//XXX ：sage ：2013/09/24(火) 06:42:26.23
> ゆぐちゃんの紹介のために、今度は日本語版のSlashdotにストーリーを
> 投稿してみました。採用されるように、是非評価を上げてやってくださいｗ
>
> URLﾘﾝｸ(slashdot.jp)
>
> GPGPUによる分散トリップ検索サービス「Meriken's Tripcode Yggdrasil」
> URLﾘﾝｸ(slashdot.jp)
ｽﾚﾘﾝｸ(esite板:43番)n
130: ◆Meriken//XXX
13/09/24 08:00:59.39 SuYpLKhoP
>>123
> 中身的には暫定的にNehalemを検出してα4のプログラムで
> 処理してる感じでしょうか？
その通りです。
> 共通プログラムで全CPUを網羅するのは
> なかなか難しいのですね
実際かなり難しいですね。試せる環境が手元にないのが大きいです。
>>126のバージョンでは新しいルーチンに手を入れてるので、
Nehalemでも高速化できるかもしれません。
131:名無しさん＠お腹いっぱい。
13/09/24 12:09:59.10 aK0ZMOZo0
Yggdrasilで検索中のPC一覧で見ることの出来る「名前」の項目のデータは編集できますか？
132:94
13/09/24 12:11:45.67 XhDzCs6d0
お疲れ様です
>>126を試してみました
条件は>>94です
【10分間の平均速度】 370.88M tripcode/s
【GPU検索の平均速度】 340.61M tripcode/s
【CPU検索の平均速度】 30.27M tripcode/s
診断ではCPUの効率向上
実測でもCPU24.54→27.47Mt/sという結果でした
133: ◆Meriken//XXX
13/09/24 12:29:58.12 SuYpLKhoP
>>132
ｷﾀ━━(ﾟ∀ﾟ)━━!! やっぱりmovapsが原因だったんですね。
他のCPUだとSSE2でmovapsを使ったほうが速いのに、
Nehalemだけmovdqaを使ったほうが速いようです。
こんなの普通わからないっちゅうねん。
なんにせよ助かりました。次の開発版に取り込んでおきます。
134:やんやん ◆yanyan/Pails
13/09/24 13:55:53.22 yDbtGzZA0
>>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
135: ◆Meriken//XXX
13/09/24 14:22:53.52 SuYpLKhoP
>>131
MTFの「分散処理」タグで編集できますよ。次からはゆぐちゃんスレでお願いします。
【分散トリップ検索】Meriken's Tripcode Yggdrasil
(p)ｽﾚﾘﾝｸ(esite板)
136: ◆Meriken//XXX
13/09/24 14:24:13.91 SuYpLKhoP
>>134
ありがとうございます。ようやくこれで安心して寝られますｗ
137: ◆Urotsuki/1Ca
13/09/24 15:36:32.45 hElffOfN0
電気料金の関係で当分稼働できそうにない…
すみません…
138:やんやん ◆yanyan/Pails
13/09/24 16:26:07.84 yDbtGzZA0
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
139: ◆Meriken//XXX
13/09/24 16:37:03.17 SuYpLKhoP
>>138
ところがNehalem以外だとintegerでもmovapsのほうが
movdqaよりも速いんですよねえ…
VC++ 2010はマニュアル通りにmovdqaを使ってましたけど、
それだとうまくいかないようです。
140: ◆Meriken//XXX
13/09/24 16:39:21.48 SuYpLKhoP
>>137
電気料金は大きな壁ですよねえ…
今までお疲れ様でした。またいつでもお越しください。
141:名無しさん＠お腹いっぱい。
13/09/24 19:22:40.85 HJd6RTmw0
>>139
何となくですが、
URLﾘﾝｸ(2chnull.info)
これの347辺りからの話が、ヒントになりそうな？
これ以上は、各アーキ毎の最適化マニュアルの比較と、
マイクロアーキテクチャ自体の変更情報を全部追わないと、どこがネックになってるのかは
分からない気がするｗ
ちなみに>>107の環境で>>126を回した結果
【10分間のCPU検索の平均速度】 146.58M tripcode/s
あれ・・・あまり変わってない・・・なんでだろ。
142: ◆Meriken//XXX
13/09/25 15:05:37.51 Q0OWgfvvP
>>141
> これ以上は、各アーキ毎の最適化マニュアルの比較と、
> マイクロアーキテクチャ自体の変更情報を全部追わないと、
> どこがネックになってるのかは分からない気がするｗ
リンク先の話は非常に興味深いですねえ。なかなか奥が深いです。
> あれ・・・あまり変わってない・・・なんでだろ。
同じNehalem系でもGulftown(Westmere-EP)は違うのかな?
難しすぎですねｗ
143: ◆Meriken//XXX
13/09/25 16:18:00.34 Q0OWgfvvP
新しい開発版をうｐしました。
MERIKEN's Tripcode Finder 1.1 Free Edition Alpha 7
URLﾘﾝｸ(www.meriken2ch.com)
Alpha 6からの主な変更点は以下の通りです。
・Nehalem系のCPUでの12桁トリップのCPU検索の高速化。
・10桁トリップのCPU検索の高速化。
>>126の成果を取り込んだついでに、10桁トリップ検索でもmovapsを使うように
しました。AVXに対応していない、Nehalem系以外のCPUでは、10桁トリップの
CPU検索は少し速くなっているはずです。
前のバージョンとの速度の比較を報告していただけると助かりますです。
144: ◆YSRKEN.ceVZZ
13/09/25 16:21:29.38 HNdGVGJA0
>>143は私(x64+SSE2/AVX、Ivy Bridge)でも10桁が高速化するのでしょうか？
145: ◆Meriken//XXX
13/09/25 16:23:53.73 Q0OWgfvvP
この週末に彼女が日本から遊びに来るので、開発はしばらくお休みです。
次の更新はHaswell購入後のAVX2対応になる予定です。
146: ◆Meriken//XXX
13/09/25 16:26:41.10 Q0OWgfvvP
>>144
Ivy BridgeはAVXに対応しているので今回は速くなりません。
AVX版はまた今度書きなおす予定です。
147: ◆e7m8FSZy3U
13/09/25 19:34:02.12 CggXwBge0
/.Jから飛んできました。
ちょっと面白そうなのでしばらく回してるかもです・・・
148: ◆e7m8FSZy3U
13/09/25 19:58:17.69 CggXwBge0
あぁこれって何か。分散のみに参加するって出来ないのね
それはつまらんなぁ。
149: ◆Meriken//XXX
13/09/25 20:04:12.63 Q0OWgfvvP
9文字ぐらいの適当な長いパターンをローカルで1つだけ指定してやれば、
分散のみに参加しているのと変わりないですよ。
150: ◆Meriken//XXX
13/09/25 20:42:15.70 Q0OWgfvvP
Linux版を作っていた◆znjnB.IJwZLUさん、最近見かけないなあ。
忙しいのかしらん。AVXに最適化されたS-Boxをぜひ見せてもらいたかったんだけど、
自分でやったほうが早いのかな。
まあやることといったら全部レジスタで回すようにして、なるべく2バイトのVEX Prefixを
使うようにするだけだからなあ。でも言うのは簡単だけど、実際にやるのは大変そうだorz
151: ◆Meriken//XXX
13/09/25 20:56:27.53 Q0OWgfvvP
定格のi7-3770Kだと10桁トリップのCPU検索の速度はこんなんです。
mty_win_x64_20071012: 21.72M TPS
MTF (AVX): 25.56M TPS
大分速くなったけど、もうちょっといけそうなんだよなあ…
152: ◆Meriken//XXX
13/09/25 20:59:08.78 Q0OWgfvvP
6番目のS-Boxにvmovdqaが6個も残ってるぞ…
まずこいつらからやっつけないと。
153: ◆Meriken//XXX
13/09/25 22:23:57.84 Q0OWgfvvP
vmovdqaを2つに減らすことが出来ましたが、一時変数が1つ増えて
速度は横這いです。難しすぎる…
154: ◆LoveNico9g
13/09/26 02:43:02.74 sJOvmiPd0
【診断の種類】検索速度(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
155: ◆Meriken//XXX
13/09/26 04:07:26.63 6FvOHAWcP
>>154
報告有り難うございます。やっぱりちょこっとだけ速くなっていますね。
動的書き換えを行っているコードをいじるのに結構神経を使ったんですが、
6.5%の速度向上だから上出来なのかな?
156: ◆HwAeH9HsBC.d
13/09/26 04:34:59.26 b6mTXvYaP
中間ステートを利用したら受け渡し所がなくても2ch上だけで安全にキーの交換ができるのか
80文字くらいのキーのテスト
157: ◆Meriken//XXX
13/09/26 06:00:51.07 6FvOHAWcP
なかなか面白い発想ですけど、キーの一部が依頼ごとに違ってくると
複数の依頼を同時に検索することが出来ないので、ちと現実的ではないですねえ。
158:名無しさん＠お腹いっぱい。
13/09/26 06:35:44.10 b6mTXvYaP
たしかに個人に依頼する場合はやっぱり一度に一人からの依頼しか処理できなくなりますが、Yggdrasilを使うなら大丈夫ですよね？
Yggdrasilに参加しながら自分の設定した文字列も検索する場合それの結果のキーまで64文字以上になっちゃいますが
あと自分のPCで発見した場合でもサーバから64文字を受け取らないといけなくなります
このときサーバが全クライアントに同じ64文字を使ってたら困るのは
サーバはクライアントごとにキーの最初の64文字を別のにして探索してもらえばよさそうです
あと依頼を1個解決した場合最初の64文字を切り替えないと次に他の依頼を解決したときに2人の別の人に同じ64文字が流出するので
依頼を解決するごとにサーバから新しい最初の64文字を受け取る必要があります
で、OpenCLの1回のワークのまとまりに全部同じ中間状態を最初に渡すことになりそうですが、
1回のワークで複数の依頼を解決しちゃった場合どれか1個しか使えなくなります（同じ最初の64文字が2人以上に使われることになるので）
これの解決法は思いつきませんでした
159:名無しさん＠お腹いっぱい。
13/09/26 06:36:45.74 b6mTXvYaP
最初の64文字を依頼人が指定するんじゃなくてYggdrasilがランダムに生成するって方式です
160: ◆Meriken//XXX
13/09/26 09:06:01.86 6FvOHAWcP
>>158
2ちゃんねる受け渡しを行うのはちょっと無理がありますが、ゆぐちゃんでは
ありでしょう。あ、あと私は最初に間違えてしまっていたのですが、
SHA-1のブロックの長さは64バイトですがメッセージの長さを格納するのに
8バイト必要なので、キーの長さは56文字が最適になります。
実装する際にはW[12]までの途中経過(A, B, C, D, E)を検索開始時に
クライアントに渡してやればいいだけです。最初の依頼を解決した時点で
検索をやり直すようにしてやればセキュリティ上の問題もないでしょう。
161:累計 ◆wop.8OO8.qow
13/09/26 09:10:52.97 BeI6EFic0
条件は>>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
162: ◆Meriken//XXX
13/09/26 09:28:13.49 6FvOHAWcP
>>161
Nehalem系でも新しいルーチンの効果に結構差がでますね。
1.0.1に比べて微減なのでまあここらへんが落とし所ですね。
報告していただいて本当に助かりました。
163: ◆Meriken//XXX
13/09/26 09:34:36.24 6FvOHAWcP
VEX Prefixの謎はstackoverflowで怒られながらヒントを貰って
ある程度解決することが出来ました。
Which AVX registers should I use to avoid 3-byte VEX prefixes?
URLﾘﾝｸ(stackoverflow.com)
なるべくソースオペランドに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:やんやん ◆yanyan/Pails
13/09/26 09:42:28.26 rTRwfDJk0
コードの動的書き換えまでやってるんだ。頑張るなぁ
165: ◆Meriken//XXX
13/09/26 10:03:07.79 6FvOHAWcP
>>164
速くするためにできることは全部やるつもりですｗ
10桁トリップのCPU検索だと2～3M TPS違ってくるので、かなり大きいです。
166: ◆Meriken//XXX
13/09/26 10:21:16.12 6FvOHAWcP
3オペランドの命令を2-byte VEX Prefixになるように
書き換えたら遅くなったぞ。なぜだ…
167: ◆Meriken//XXX
13/09/26 11:03:10.06 6FvOHAWcP
うーん、やっぱりわからん…
まあいいや、また今度にしよっと。
168: ◆Meriken//XXX
13/09/26 12:42:38.98 6FvOHAWcP
290Xが噂通りの性能なら、検索君1号の6990をリプレースしたいところですが、
どうなんでしょうねえ～
AMD，新世代GPUシリーズ「Radeon R9」「Radeon R7」を発表
URLﾘﾝｸ(www.4gamer.net)
169: ◆YSRKEN.ceVZZ
13/09/26 21:45:53.97 dy4WW+LZ0
>>168
絶対に値段がヤバそう、かと思いましたがそれほどでもないのかな＞R9 280X(のメーカー想定売価)は299ドル
170:名無しさん＠お腹いっぱい。
13/09/26 22:52:10.88 K0nbDP0R0
AMDがMantleとかいう新しいLow Level APIも発表したが
使えるのグラフィック用途だけなのかな
171: ◆znjnB.IJwZLU
13/09/26 23:28:01.94 6DsB6fP10
>>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までの全てのレジスタを指定可能です。
まあ、レジスタ割付は面倒になります。
172: ◆Meriken//XXX
13/09/27 01:05:59.70 8wnFvcpWP
>>171
なるほど、そういう頭が必要なんですね。道理でなかなか速くならなかったわけだ。
実に勉強になりますです。
> 日々の仕事をこなしつつトリップ検索のための正規表現エンジンのための
> JITコンパイラを作るという作業にエタってました。
MTFの正規表現のルーチンもC#で綺麗に書きなおそうと考えてたんですけど、
この発想は斬新ですねｗ 流石です。
173: ◆Meriken//XXX
13/09/27 01:11:08.04 8wnFvcpWP
>>170
Mantleからだと直接GCNを叩けるみたいですね。
オープンソースになるという噂もあるみたいです。
GCNは性能的に化物としか言い様がないので、ｗｋｔｋが止まらないですｗ
174:名無しさん＠お腹いっぱい。
13/09/27 01:17:32.97 lkqItC0o0
>>172
maleで拙作のavxDESを送ったので時間があれば見てみてください。
あまり参考にならないかもしれませんが
175: ◆znjnB.IJwZLU
13/09/27 01:18:39.25 lkqItC0o0
>>174
トリわすれてました
176: ◆Meriken//XXX
13/09/27 01:42:29.83 8wnFvcpWP
>>174-175
わざわざ有り難うございます。さっきまで送っていただいた
S-BoxをMTFに実際に組み込んで動かしていたんですが、確かに速くなっていますね。
素晴らしい出来です。
177: ◆YSRKEN.ceVZZ
13/09/27 01:59:44.23 3xFrfLPD0
｀¨ － ､ ＿_ _,. -‐' ¨´
| ｀Tｰて＿,＿｀ `ー<^ヽ
Meriken .| ! ｀ヽ ヽ ヽ znjnB
r / ヽ ヽ _Lj
､ /´ ＼ ＼ ＼_j／ヽ
｀ ー ヽｲ⌒r-､ヽ ヽ__j´ ｀¨´
￣ー┴'^´
178:名無しさん＠お腹いっぱい。
13/09/27 02:20:44.90 0ZtIGcs50
maleで送ったとか・・・
ｱｯｰ!!!
179: ◆znjnB.IJwZLU
13/09/27 02:35:31.94 lkqItC0o0
>>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だった
180: ◆Meriken//XXX
13/09/27 06:52:13.34 8wnFvcpWP
>>179
> これはハイパースレッディングで2スレッド走らせる場合、
> L2キャッシュへのアクセスが生じると大きなペナルティになりえます。
ああなるほど、それでL1Dキャッシュが潰れて遅くなっていたんですね。
前スレでスレッドの数ごとに速度の比較を行われていたのにも合点がいきました。
KSを命令のほうで展開するやり方はOpenCL版では使っていたんですが、
CPUでは試していませんでした。ただ、STFの展開の仕方は随分独特で
スッキリしているように見えます。できることはまだまだたくさんありますねえ。
明日から1週間ほど家を空けるので、AVX2版の実装と一緒に試してみます。
いや～、楽しみだなあ。
181:混沌 ◆Chaos/geeeIV
13/09/28 19:26:50.26 3+QdwiIO0
よくわかっていないのですが、MTFでの検索パターンとのマッチング処理ってどういう風になっているのかな
１トリップ生成する毎にマッチング処理ですか？
182:名無しさん＠お腹いっぱい。
13/09/29 19:57:56.89 puciZRd6P
MERIKENさんの彼女って美人さんかな
183:名無しさん＠お腹いっぱい。
13/09/29 20:29:14.46 Er9GkfO70
400年生きてるけど容姿は14歳くらいの
押しかけ女房という設定でよろしくお願いします
184: ◆AAAAAIgElTYM
13/09/29 21:09:53.00 puciZRd6P
MERIKENさんのOpenCLのカーネルを参考に作ったら
MTFで900MHash/s出るGPUで590MHash/s出せた
900M目指す
185:名無しさん＠お腹いっぱい。
13/09/29 21:30:42.42 puciZRd6P
と思ったら900Mは簡単に出せた
ただしキーの判定がA,B,C,D,EのAが0かどうか、だけですが
186:名無しさん＠お腹いっぱい。
13/09/29 21:32:17.66 puciZRd6P
MERIKENさんのカーネルすごいなー
187:名無しさん＠お腹いっぱい。
13/09/29 21:33:58.75 UQDnvd/B0
>>183
ロリババアじゃねえか……最高だな
188:名無しさん＠お腹いっぱい。
13/10/02 09:12:18.65 c9bt88M30
質問です
自分が見つけたトリップのキーが既に割れているかどうか調べる方法ってあります?
トリップでググってみたけど出てこなかった
◆WWmMMmWmmM
◆mmmmMMWmmM
189:名無しさん＠お腹いっぱい。
13/10/02 12:12:15.95 RmatBROi0
ぐぐって出てこないなら割れてないんじゃないかな
キーが割れてるか調べるならキーでぐぐれば良いかと
別キー同トリは酉でぐぐってみるしかないですねぇ
あとはデータベース調べるくらい？
URLﾘﾝｸ(trip2ch.net)
190: ◆YSRKEN.ceVZZ
13/10/02 12:29:57.48 rovLnW6/0
例の流出騒動で割れた(けどネット上でまだ使われていない)人もいるしなぁ……
俺のように
191:名無しさん＠お腹いっぱい。
13/10/02 12:38:17.05 HrAyM4RZ0
自分が見つけた、ということなので未使用前提のレスなのら
自分が使ってないなら誰かが先に見つけて、晒したり使用したりしていない限り
割れていることはないからね
192:やんやん ◆yanyan/Pails
13/10/02 13:54:06.66 V6M1LhCI0
別キー同トリって、ハッシュの衝突ということだよね？
SHA-1ってそんなに衝突起きてたっけ？
193: ◆MONEY///WQoK
13/10/02 13:58:55.21 c9bt88M30
>>189-191
個人で使うこんな感じで↑一般的なものなら神経質にはなりませんが、
最長や最短のように変わったトリップは他にも使っている可能性もあるので、
調べてみようと思いました
データベースとグーグルを活用したいと思います
ありがとうです m(_ _)m
12Mt/s程度のPCには8完9完はきついです
見つかる気がしませんw
194:名無しさん＠お腹いっぱい。
13/10/02 14:06:57.14 ntU3OB+00
>>193
8完程度なら他の人が見つけてくれることもあるよ
それがクラスターの良いところ
＃今日は気温が上がってしまったので落ちまくりｗ
195:名無しさん＠お腹いっぱい。
13/10/02 16:30:36.74 J0NS89z00
>>192
SHA-1をBASE64にした先頭12文字らしいから、
160bitのうち6bit×12文字で72bitしか使わない計算だからねぇ…
有効空間で309485009821345068724781056分の1、かな。
誕生日のパラドックスで衝突率を求めると…どうなるんだ？
196:名無しさん＠お腹いっぱい。
13/10/02 19:41:47.15 c9bt88M30
>>194
なるほど
確かに分散処理が出来ましたね
197: ◆Urotsuki/1Ca
13/10/02 19:46:03.89 7dIRUU6o0
金さえあれば3Way CFXしてブン回せるのに…うぐぐ
198: ◆LoveNico9g
13/10/02 21:39:36.99 ElaEz5OR0
あなたは10桁トリップを発見しました。プラチナ貨8192枚が支払われます。 (19時間前)
文字数がないということは特殊なトリップかな？
あなたは8文字一致の10桁トリップを発見しました。プラチナ貨4096枚が支払われます。 (3ヶ月前)
あなたは9文字一致の10桁トリップを発見しました。プラチナ貨262144枚が支払われます。 (3ヶ月前)
8文字超、9文字未満の報酬ね
199: ◆YSRKEN.ceVZZ
13/10/03 00:57:15.45 5JFild+E0
妙な質問ですが、
URLﾘﾝｸ(tripcode.net)
って1920x1200に最適化しているんですか？
HTML Screensaverで表示させると12桁トリップのグラフと上位数名のリストしか表示されませんorz
(1366x768のノートパソコンでの話)
200:名無しさん＠お腹いっぱい。
13/10/03 01:01:16.51 6er0tSp20
>>199
893 ： ◆Meriken//XXX ：2013/09/08(日) 07:55:22.82 ID:9LBqP7z/0 (2/2)
スクリーンセーバー用のページを新しいグラフに合わせて変更してみました。
これでPCの台数が増えてもしばらくは安心です。相変わらず1920x1080専用です。
URLﾘﾝｸ(tripcode.net)
スクリーンセーバーはこちらがお勧めです。
HTML Screensaver
URLﾘﾝｸ(myweb.tiscali.co.uk)
201:名無しさん＠お腹いっぱい。
13/10/03 01:27:20.09 JxzZIhR00
>>198
過去ログにも出てるけどそれは準10連を見つけた場合の報酬
純10連だと6815744枚もらえるらしい
ところで昨日10/2の11:00頃に12桁のmaxが66.3G TPSになってるのは一体…
202:混沌 ◆Chaos/geeeIV
13/10/03 05:39:39.07 FzkRfayB0
どっかの大学か専門学校あたり教室から誰か遊んだのかなｗ
203: ◆YSRKEN.ceVZZ
13/10/03 08:54:27.00 5JFild+E0
>>202
まあでもグラフを見る限りでは50GTPSは上がってるしな……
一台あたり100MTPSでも500台は牛耳らないとああはならないはず
バグである可能性もあるが
204:名無しさん＠お腹いっぱい。
13/10/03 09:58:21.96 vduEdb0k0
>>203
そういうところだとPXEブートしてたりする。
PXEサーバへの線を切って起動後即アプリ起動するイメージ持ったPXEサーバを設置すれば、
後は片っ端から電源入れるだけで利用できるから、100台くらいは案外乗っ取れるかと。
あとはGPUの相性次第？
205:混沌 ◆Chaos/geeeIV
13/10/03 10:19:02.54 FzkRfayB0
>>204
参加者の中でばかっ速いのはほんの数人、実質Merikenさんだけで半分以上稼いでるようなもんだけどｗ
うちの１年くらい前の普及価格帯GTX660ですら、開発版MTFならGPUのみ単体でも400Mtpsくらいでるから
ちょっといいグラボ乗せていそうなところだったら教室1つで行けそうな気がするよｗ
206:shirawa@mmo ◆GTExxuWcjk/9
13/10/03 12:18:13.19 1mbRumHzP
1人で数百台所有してる方も見かけますし、あながち団体とも言い切れないのがおそろしいところｗ
案外、海外の方とかもありえる？
207: ◆LoveNico9g
13/10/03 20:04:17.29 2EEzR2Fi0
>>201
なるほどなるほどー
使うためには将来実装されるフリマ？バザー？で買い戻すしかないのかな？
しかし見つけたトリップが何かわからないからそれもかなわないのだけど…
そういえば有償版は"参加しない"設定はあるけど"参加するけどトリップは提供しない"設定は無理なのかしら？
依頼と手元の検索対象が被った場合に、手元を優先して提供しないみたいな
208:混沌 ◆Chaos/geeeIV
13/10/03 21:21:24.21 FzkRfayB0
今は丁度留守だけど
ユグドラの機能絡みの話はあっちのスレでやった方が話題を共有できるしMerikenさんもノリやすいと思うよーｗ
209:名無しさん＠お腹いっぱい。
13/10/03 22:55:31.53 PVFODAuA0
AMD Catalyst? Display Driver for Windows Vista 32-bit って、最新版は 13.4 なんですか？
検索しても、13.10 が見つからない・・・
210: ◆Meriken//XXX
13/10/03 23:48:31.78 hGyYsSenP
ようやくアリゾナへの小旅行から戻ってきました。
セドナっていうインディアンの古い聖地に行ってきたんですけど、
岩山が並ぶ景観が素晴らしかったです。
地元の人達も面白い方が多かったので、またぜひ行ってみたいですねえ。
>>183-184
彼女はころっとしてて愛嬌のある感じです。
無事に日本に辿り着ければいいんですが…
211:名無しさん＠お腹いっぱい。
13/10/03 23:54:23.91 yymlo581P
MERIKENさんおかえり！！
212: ◆Urotsuki/1Ca
13/10/03 23:57:23.45 Z2ZCk0070
おかえりー!行ってみたいなぁ…
213:名無しさん＠お腹いっぱい。
13/10/04 01:03:55.19 9T4g2abG0
>>210
> 無事に日本に辿り着ければいいんですが…
ヒッチハイクで帰国したとか？？
214: ◆Meriken//XXX
13/10/04 04:41:05.93 iHUDZBAdP
どもどもｗ
>>213
彼女、ロスの空港で1人で乗り継ぎだったんですけど、
英語が殆どできないんですよね… まあ大丈夫だとは思いますが。
215: ◆Meriken//XXX
13/10/04 04:54:13.15 iHUDZBAdP
>>184
検索エンジンのソースコードはGPLで公開されているので、
じゃんじゃん使ってやって下さいｗ
216: ◆Meriken//XXX
13/10/04 05:01:23.10 iHUDZBAdP
>>197
電気代は盲点でしたね～
私ももうちょっとお金があったら専用電源を備えたPC専用の部屋が
欲しいところですけど、先は長いですねえ。
217: ◆Meriken//XXX
13/10/04 05:08:24.51 iHUDZBAdP
>>207
これどうしようかかなり迷ったんですけど、
参加していただく以上は条件を揃えておきたかったので
こんな風になっています。
218:名無しさん＠お腹いっぱい。
13/10/04 05:39:22.35 OK0SaK/c0
誰も怒らねえからまんどくさいのでと正直に言えよw
219:やんやん ◆yanyan/Pails
13/10/04 05:44:19.39 mM382Oj10
60A契約だと不足気味になるから、75Aにしようかと思ったりしたり。
220: 忍法帖【Lv=2,xxxP】(3+0：8) ◆Meriken//XXX
13/10/04 05:48:05.07 iHUDZBAdP
R9 290Xがもう少しで発売ですね。いや～、楽しみだなあ。
しかし旅行から帰ってきたら2chの規制が更に厳しくなっていますね。
忍法帳のレベルを上げないとリンクも貼れないとか、どうかしてます。
海外規制は相変わらずだし、流出事件以降VPNも規制されて、
●で規制を回避できなくなっちゃったし…
これで公式p2も海外規制されたらどうしようかしらん。
221: 忍法帖【Lv=40,xxxPT】(1+0：8) 【東電 59.6 %】
13/10/04 06:05:56.81 rrTSneEoP
てすと
222: 忍法帖【Lv=2,xxxP】(3+0：8) ◆Meriken//XXX
13/10/04 06:07:02.04 iHUDZBAdP
>>218
実装自体は判定の処理の順番を入れ替えるだけなので、
そんなにめんどくさくないですｗ
経験値は非常に重要な指標なので、
を獲得するための条件は同じにしておきたいんですよね。
223: 忍法帖【Lv=2,xxxP】(3+0：8) ◆Meriken//XXX
13/10/04 06:17:55.03 iHUDZBAdP
>>219
いいですね～ ほんとに検索速度の限界は電気の供給によって決まってきますね。
224:名無しさん＠お腹いっぱい。
13/10/04 06:22:44.72 rrTSneEoP
半導体プロセスが28nmから20nmになったら同じ電力で倍の速度出せるようになるかな
225: 忍法帖【Lv=2,xxxP】(1+0：8) ◆Meriken//XXX
13/10/04 07:07:47.87 iHUDZBAdP
さすがにそこまではいかないでしょうけど、
確実にワットあたりの性能は上がるでしょうね。
R9 290Xが7970と比べてどれぐらい性能が上がっているのか、
非常に気になるところです。
226: 忍法帖【Lv=2,xxxP】(2+0：8) ◆Meriken//XXX
13/10/04 07:43:28.35 iHUDZBAdP
>>180の続きですが、STFのS-Boxを使わせていただいた結果、
速度は26.05M TPSまで上がりました。>>151の数字より確実に
良くなっていますが、key scheduleを命令のほうに展開してやれば
更に速くなりそうです。取りあえずMTFのルーチンで展開を試してみてから
送っていただいたSTFのルーチンを移植してみることにします。
227: 忍法帖【Lv=2,xxxP】(1+0：8) ◆Meriken//XXX
13/10/04 14:49:48.68 iHUDZBAdP
現在せっせAVXのルーチンを書き換え中。
動的書き換えを行っているルーチンを修正するのは結構大変です。
うまくいくかな～
228:名無しさん＠お腹いっぱい。
13/10/04 18:27:11.06 rrTSneEoP
URLﾘﾝｸ(www.fileformat.info)
ビットコインのクライアントのRPCを使ってブロックのハッシュ値を列挙して連続する0のビットが一番多いハッシュを探した後、
ビットコインのハッシュはSHA256(SHA256(key))なのでブロックのヘッダをblockexplorerで持ってきて
SHA256(header)を計算して 1dc72653c09d8eb383671d18bcca2d02470a3c6b43ea547bafb69c4227188498 を出して
これをHEX表示としたバイナリのSHA256ハッシュが実際に00が連続することを確認した
ちなみに73ビット0が連続する もし2chのトリップのSHA1で72ビット以上0が連続したら12連の"AAAAAAAAAAAA"になる
229:名無しさん＠お腹いっぱい。
13/10/04 18:30:52.37 rrTSneEoP
でもBitcoinは先頭と末尾が逆だった(連続する0ビットの位置の）
230:名無しさん＠お腹いっぱい。
13/10/04 19:41:03.52 QT5wWxXa0
特にエラーも出てないのに、GPU 検索が止まってる事があるけど、
エラーが出ないので情報を提供出来ない・・・
231: ◆MOYASHI/Go
13/10/04 21:14:55.45 Ohb6dumk0 BE:4454085877-2BP(7)
お、Merikenさんおかえりなさい。
>>220
2ch書き込み規制等の場合は、したらばのMerikenさんの掲示板の辺りへ移動かな？
でも、したらばって12桁トリップ使えないんでしたっけ？う～ん…
>>230
環境や状況等を詳しく書いた方がいいかも。
232: 忍法帖【Lv=3,xxxP】(1+0：8) ◆Meriken//XXX
13/10/05 01:03:32.26 V671iDXLP
>>230
こういう場合はまずハードウェアがらみなんですけど、
エラー処理を見なおしたほうがいいかもしれませんね。
ハードウェアの構成を教えていただけると助かります。
233:名無しさん＠お腹いっぱい。
13/10/05 01:07:57.88 R6g1pM6d0
7970の場合だと90℃を超えた辺りで不安定領域
95℃まで行ったらまずGPUが脱落する
保護回路かな？
動作保証のあるメーカー品でも強烈な連続負荷が掛かるので油断出来ない
234: 忍法帖【Lv=3,xxxP】(1+0：8) ◆Meriken//XXX
13/10/05 01:39:01.21 V671iDXLP
>>231
緊急時にはとりあえずしたらばに移動ですね。
2ちゃんねるVPNを使えば海外規制は回避できるんですが、
有料だし不便なのでできれば避けたいところです。
235: 忍法帖【Lv=3,xxxP】(1+0：8) ◆Meriken//XXX
13/10/05 03:21:44.19 V671iDXLP
とうとう4770とM6Eをポチってしまいました。
これで思う存分AVX2をいじれます。ぐへへへへ…
236:名無しさん＠お腹いっぱい。
13/10/05 04:34:59.02 R6g1pM6d0
私はFX-9370をポチってしまいました
TDP200Wゴクリｗ
237: ◆Meriken//XXX
13/10/05 04:55:00.35 V671iDXLP
AMDのCPUもきちんと書いてやれば>>67のようにちゃんと速度が出ますしね。
何より独立したコアが8個あるのは魅力的です。楽しみですね～
238: ◆Meriken//XXX
13/10/05 09:10:12.59 V671iDXLP
1日かけてAVXのルーチンのkey scheduleをコードに展開してみました。
で、うまく動いたのは良かったのですが、速度はかえって落ちてしまいましたorz
やはりSTFみたいにDES crypt(3)の二種類のラウンドを畳み込んでやらないと
今度はコードがキャッシュから溢れてしまうようです。
239:やんやん ◆yanyan/Pails
13/10/05 09:29:04.34 V9+sfTd+0
最近のCPUは投機的実行したりパイプライン深かったりだから、
アセンブラレベルでの高速化って大変そうだな。
240: ◆Meriken//XXX
13/10/05 11:05:48.38 V671iDXLP
確かにかなり難しいですねえ。畳み込みも試してみましたが、それでも書き換え前の
速度には届きませんでした。アセンブラのルーチンはほとんどSTFと
おなじになってしまったので、>>179で教えていただいたとおりに
やってるはずなのに速くならないのはかなり謎です。
241: ◆Meriken//XXX
13/10/05 11:17:38.50 V671iDXLP
まあいいや、また今度STFのルーチンを試してみようっと。
そうすれば少なくとも問題の切り分けはできるはず…
242: ◆JouJaku.IYSv
13/10/05 15:26:49.76 TQdt57zm0
>>235
おぉ、遂にですね。
アマゾンで購入する時には極力ゆぐ経由で注文していたのですが、少しは足しになりましたかね?
M6Eの一番下のPCIeに、2若しくは1.5スロット幅のカードが刺さるかどうか教えて下さい。
Z87 Extreme 9を使っているのですが、一番下のPCIeはスイッチケーブル等が干渉して水枕付きの7990が刺さらないのです。
243: ◆Meriken//XXX
13/10/05 18:24:43.38 V671iDXLP
>>242
確実に足しになっていますよ。ありがとうございます。
写真を見る限りでは干渉するようですが、一応届いたら確認してみます。
検索君1号でも干渉しているのですが、R.O.G.シリーズのマザボは
電源ボタンが別に付いているので私は普段はそれを使っています。
244: ◆Meriken//XXX
13/10/05 18:46:04.08 V671iDXLP
あれからいろいろ実験してみたのですが、>>179のようにL1Dキャッシュを
有効活用するためにはキー生成とヒット判定のルーチンに相当手を入れないことが
いけないことが分かりました。◆znjnB.IJwZLUさんはかなり色々工夫されているようです。
まあでも原因がわかったので、取りあえずこの件は置いておくことにして、
AVX2対応の準備を勧めることにします。
245: ◆Urotsuki/1Ca
13/10/06 22:27:59.59 on3hVRef0
着々と高速化されていて期待する日々
ちょっとだけぶん回す
246:名無しさん＠お腹いっぱい。
13/10/06 22:59:18.76 vgIX48Ma0
熱と電気代の壁を乗り越えて頑張ってください
247: ◆QZaw55cn4c
13/10/06 23:07:39.77 tfHzXDW00
熱はこれからの季節ではともかく電気代の壁には参っております，いつ脱落してもおかしくない‥‥
248: ◆Urotsuki/1Ca
13/10/07 00:02:30.75 jF8JVd0Q0
電気代のほうが深刻です
1～2時間フル稼働が限界かも
249:名無しさん＠お腹いっぱい。
13/10/07 00:24:06.99 dlpjmzEs0
ラスボス：電気代
250: ◆Meriken//XXX
13/10/07 02:29:43.10 kkyn89W/P
ハイエンドのグラボを2枚使って24時間稼働させると
電気代は月10000円前後なのでたしかに痛い出費ですねえ。
長い目で見たら1枚だけ使って電気代を抑えたほうがいいのかもしれません。
7970 1枚だけでも現在のゆぐちゃんでは十分トップクラスですしね。
私としては無理の無い範囲で長く続けていただきたいところです。
251:名無しさん＠お腹いっぱい。
13/10/07 17:32:57.57 /IUR/xz60
嫌な感じだな。
そこまでして・・
252: ◆Meriken//XXX
13/10/07 19:16:23.56 kkyn89W/P
まあもともと本格的なトリップ検索にはお金がかかりますしね。
他にもっとお金のかかる趣味なんていくらでもあるし、
人の趣味にケチを付けるのは無粋というものです。
253:名無しさん＠お腹いっぱい。
13/10/07 19:49:49.65 T8R7cFdS0
GPU を使う場合はともかく、最近の CPU は一杯コアがあるし、
PC の電源が入っている間は、一部のコアでずーっと検索させてても
全く何の問題もないよね。
２つ位コア開けておけば、通常の使用に影響出ないし。
254:SilentPC ◆SilentPCIePC
13/10/07 19:51:37.30 YIb5KFv+0
まあだからこその、分散処理なんですよね。
自分一人で1垓のトリップの中から好きなトリップ1個を探し出すのにかかる電気代と、
50人で1垓のトリップの中から好きなトリップをそれぞれ探し出すのにかかる電気代では、
単純計算で前者の50分の1の電気代で済むわけですからね。
皆で協力する事で必要経費も人数分の一に分散出来て、それでいて人数分の一の時間で必要なものも見つけられる。
お互いが得する大変良い仕組みだと思います。
開発頑張って下さい。
255:名無しさん＠お腹いっぱい。
13/10/07 19:58:08.91 T8R7cFdS0
ところで、検索は完全にランダムにやってるんだと思うけど、何故か、頻繁に見つかるトリップと、
全く、一切、全然、ちっとも見つからないトリップがあって、かなり偏るんだよね。不思議だ。
256: ◆YSRKEN.ceVZZ
13/10/07 22:05:18.86 XMrah83C0
>>255
短い回数だと乱数が偏ったように見えることはよくあること
ところで、前にも聞きましたが、この状態だと検索時間が16倍速なんですよね？
URLﾘﾝｸ(up3.viploader.net)
257:名無しさん＠お腹いっぱい。
13/10/07 22:17:15.13 ruVVZ61g0
16・倍・速！ 16・倍・速！
258: ◆Meriken//XXX
13/10/07 22:28:15.09 kkyn89W/P
>>256
なんか妙に台数が増えてた時間があったのはYSRKENさんだったんですねｗ
> この状態だと検索時間が16倍速なんですよね？
違います。同時に何台稼働しても検索時間は一緒です。
259: ◆YSRKEN.ceVZZ
13/10/07 22:32:53.07 XMrah83C0
>>258
なん、だと……！？
まあこのキャプ撮りたいがために16台を一時的に乗っ取ったのですがｗ
260: ◆Meriken//XXX
13/10/07 22:35:08.34 kkyn89W/P
>>254
分散トリップ検索は長い間あたためてきたアイディアなので、
実現できて結構嬉しいですｗ トリップ検索はパターンの数が増えても
速度は急に落ちないので、実に分散処理向きといえます。
261:名無しさん＠お腹いっぱい。
13/10/07 22:44:56.42 8uRwwq3r0
17時前後の青グラフと"max: 31"があなたの仕業ですかー！
URLﾘﾝｸ(up3.viploader.net)
262: ◆YSRKEN.ceVZZ
13/10/07 22:55:15.52 XMrah83C0
>>261
そうでーすｗ
トライして気がついたのですが、これってWeb上では同じ「4MTPS」でも、
ソートする際は小数点以下も含めているんですか？
263: ◆Meriken//XXX
13/10/08 02:44:29.87 Be50s5DTP
>>262
そうですよ。
264: ◆YSRKEN.ceVZZ
13/10/08 02:59:16.21 hGdMdaDn0
>>263
良かったです。このソフトでは小数点以下を切り捨てているわけじゃなかったんだね！
265: ◆Meriken//XXX
13/10/08 06:16:31.85 Be50s5DTP
今日あたりHaswellが届いているはずだけど、ちょっと見に行ってみるか。
266:名無しさん＠お腹いっぱい。
13/10/08 08:12:07.30 uiAIodMh0
>>256
> 短い回数だと乱数が偏ったように見えることはよくあること
いや２４時間３６５日検索してるんだけど・・・
267:ねこ ◆TheWorld.o
13/10/08 08:59:54.97 wwRsWuFO0
ロト7を毎週1年買っても当たらないようなものです
268:SilentPC ◆SilentPCIePC
13/10/08 11:37:45.44 ruHOMK/b0
>>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(ペタ)パターンのトリップを発見したとしても、それは全体の万分の一以下の数でしかない。
269: ◆Meriken//XXX
13/10/08 14:50:47.22 Be50s5DTP
>>255
もうちょっと具体的に書いてもらえれば詳しいことがわかると思いますよ。
MTFのバグという可能性もありますしね。
270:名無しさん＠お腹いっぱい。
13/10/08 15:54:01.93 U2rkGsnVO
例えば9桁完全一致トリップが欲しいとして、
12桁で検索するのと10桁で検索するのでは、
どちらが確率が高いのでしょうか？
271: ◆YSRKEN.ceVZZ
13/10/08 19:37:18.73 hGdMdaDn0
>>270
確率は同じだが普通は前者の方が高速に検索できるからお勧め
ユーYggdrasil に依頼しちゃいなYO
272:名無しさん＠お腹いっぱい。
13/10/09 00:11:52.59 qMpebiGr0
ゆぐちゃんの実績から言っても12桁ですよねー
URLﾘﾝｸ(tripcode.net)
平均検索時間(12桁):13.9日(9文字)
平均検索時間(10桁):1.4ヶ月(9文字)
273: ◆Meriken//XXX
13/10/09 01:07:35.35 lCvxi2JOP
YSRKENさん、ときどき名無しで書き込んでますね。
274: ◆Meriken//XXX
13/10/09 01:18:50.00 lCvxi2JOP
Haswellが届いたことは確認済みなので、これから取ってきます。
今日はちょっと用事があるので組み立ては明日あたりかな。
275: ◆YSRKEN.ceVZZ
13/10/09 01:31:41.77 hjmT6Azw0
>>273
えっと、はいそうです。とは言っても、
「専ブラでコテハン記憶しているはずなのになぜか消えてて面倒になった」
というのが主な理由ですが。
>>274
遂にMerikenさんがHaswellに挑戦するんですね……ﾄﾞｷﾄﾞｷ
276: ◆Meriken//XXX
13/10/09 01:47:33.39 lCvxi2JOP
>>275
そうですか。まあ何事もほどほどに、ね。
277: ◆QZschizo.ptH
13/10/09 03:59:47.55 lS/PIDax0
>>270
12桁の方がトリップ生成速度が格段にはやいし（環境によるけど）、なんだか12桁ってあんまり「安全」じゃないような気がしてきた‥‥
278:名無しさん＠お腹いっぱい。
13/10/09 04:35:29.68 wuthnGWj0
>>277
前方数文字が同じで「ぱっと見で似ている」トリップ探すなら12桁の方が危険かもしれないけれど、
完全一致なら空間的にも時間的にも12桁の方が安全性は高いと思うよ。
検索速度が何倍で、トリップ数が何倍か計算してみよう。
トリップ数ではなく使用可能な鍵空間で計算してみても良い。
あーでも捻ってないからレインボーテーブル的なアプローチには弱いかも。
279: ◆Meriken//XXX
13/10/09 04:37:19.41 lCvxi2JOP
検索速度は12桁のほうが数倍速いですけど、10桁トリップのキー空間の狭さを考えたら
12桁トリップのほうがはるかに安全ですよ。12桁トリップの数は2^72個ですけど、
10桁トリップはキーが56bitだから最大で2^56個しかありません。
キーがShift-JISの場合はさらに少なくなります。
280: ◆Meriken//XXX
13/10/09 04:55:24.64 lCvxi2JOP
>>378
2^34TPS (≒16G TPS)で検索しても12桁トリップをすべて出すには
最低で2^38秒(≒87世紀)かかるのでまあ大丈夫でしょう。
281: ◆Meriken//XXX
13/10/09 04:56:51.56 lCvxi2JOP
>>280は>>278さん宛でした。
282: ◆QZschizo.ptH
13/10/09 04:57:40.03 lS/PIDax0
確かに鍵空間的に2^16 違うのであれば、不安がる根拠はありませんね、いろいろ教えていただきありがとうございます
283:名無しさん＠お腹いっぱい。
13/10/09 08:12:00.69 c6EX+6rR0
時代は12桁
284: ◆YSRKEN.ceVZZ
13/10/09 08:15:12.78 hjmT6Azw0
>>278
>前方数文字が同じで「ぱっと見で似ている」トリップ探すなら12桁の方が危険かもしれない
前に「いや先頭合ってるだけで誤解されかねないからそれはそれでマズい」って声があったような……
でもまあ完全一致や全桁対象の酉（例：全数、二構）だと10桁の方が断然見つけやすいんですけどね
285: ◆Meriken//XXX
13/10/09 08:51:52.85 lCvxi2JOP
>>283
そのかわりきれいなトリップは10桁のほうが断然出しやすいですけどね。
一長一短といったところです。