GIMPS メルセンヌ素数7 結果3 [素数]
"GIMPS メルセンヌ素数6 計算量 "の続き。
・PC:h5 Core2 Q6600 @ 2.4GHz Ubuntu
丸7日、63%まで進んだ。残り3日だ。
その下は、世界記録狙いで2つ割り当てられている。
1コアしか動いていないと思い、追加でprime -mを動かした際に割り当てられたものだ。
そもそも適当に設定してしまい、CPUsで確認すると4ワーカーになっているが実際には1候補しか計算していない。1ワーカに4コアを割り当てられているのだろうか?
・PC:h6 Intel Core i7-2600 @ 3.40GHz Win7
メインPCは速い。h5が11日かかる計算を4日で終えそうだ。
こちらは1ワーカに4コアを割り当てられている。
h5,h6で同じソフトを使う機会があり、Ubuntu(h5)のほうが数倍速い印象もあったぐらいだ。やはりh5の設定が誤っているのだろうか?
次は1億桁の割り当てをもらった。4953HGz-days、388日かかる見込みだ。1年かけて合成数ではたまらない。
現在TF 2^75までパスしているので、TF 2^80まで先に探索すべきだろう。
デスクトップ1台で取り組むべき数では無さそうだ。
TF,LLはGPUの方が高速処理できるようなので、そちらを先に試そうと思う。
・PC:h7 i7-4700MQ @ 2.4GHz Win7
6/2 17:30~6/4 23:30の54時間で60個の因数探しが終了した。因数はひとつも見つけることができなかった。発見率は1.6%にも満たないということか。
Exponent Statusの読み方が段々判ってきた。
例えば、13180429は下図のとおり、P-1、LL、HIstoryの項目がある。
Typeの欄を下から順に見てゆく。
計算量を節約するならL-Lテスト前にTF 2^68やNF-ECMを通すべきだが、素数探しが優先してL-Lが先に実行されたのだろう。ちなみにL-Lテストは1stを通した人が発見者となるらしい。バグで残余値が誤る場合もあったらしく、Dで0、素数を発見できる可能性もあったのだろう。この数は1st、D、3rdまで同一の方が通している。
逆に素数で確定している13466917は、Dが実行されていない。いいのだろうか?
GIMPS Milestones Reportによれば、Dは36046457まで、LL(1st)は67364459まで検証されている。
つまり、h5~h7が現在取り組んでいる4千万台の指数は、LL(1st)が計算ミスで、実は残余が0であることを発見した場合にのみ発見者となれるのだろう。
現在、下記を計算中だが、どうしようかと思う。
・PC:h5 Core2 Q6600 @ 2.4GHz Ubuntu
41,860,141 D LL, 63.30% 7 2016-05-30 2016-06-06 2016-06-07 2016-06-10 5
75,564,319 LL 4 2016-06-02 2016-06-06 2016-06-07 2016-07-29 54
75,576,649 LL LL 3 2016-06-03 2016-06-06 2016-06-07 2016-09-16 103
丸7日、63%まで進んだ。残り3日だ。
その下は、世界記録狙いで2つ割り当てられている。
1コアしか動いていないと思い、追加でprime -mを動かした際に割り当てられたものだ。
そもそも適当に設定してしまい、CPUsで確認すると4ワーカーになっているが実際には1候補しか計算していない。1ワーカに4コアを割り当てられているのだろうか?
・PC:h6 Intel Core i7-2600 @ 3.40GHz Win7
42,773,741 D LL, 38.00% 2 2016-06-04 2016-06-05 2016-06-06 2016-06-08 2
333,012,851 LL 1 2016-06-05 2016-06-05 2016-06-06 2017-06-29 388
メインPCは速い。h5が11日かかる計算を4日で終えそうだ。
こちらは1ワーカに4コアを割り当てられている。
h5,h6で同じソフトを使う機会があり、Ubuntu(h5)のほうが数倍速い印象もあったぐらいだ。やはりh5の設定が誤っているのだろうか?
次は1億桁の割り当てをもらった。4953HGz-days、388日かかる見込みだ。1年かけて合成数ではたまらない。
現在TF 2^75までパスしているので、TF 2^80まで先に探索すべきだろう。
デスクトップ1台で取り組むべき数では無さそうだ。
TF,LLはGPUの方が高速処理できるようなので、そちらを先に試そうと思う。
・PC:h7 i7-4700MQ @ 2.4GHz Win7
6/2 17:30~6/4 23:30の54時間で60個の因数探しが終了した。因数はひとつも見つけることができなかった。発見率は1.6%にも満たないということか。
Exponent Statusの読み方が段々判ってきた。
例えば、13180429は下図のとおり、P-1、LL、HIstoryの項目がある。
Typeの欄を下から順に見てゆく。
Type | テスト内容 | 結果 | 計算量(GHz-Days) |
NF | TF | Trial Factory法因数探索:2^64までに因数は無い | 0.149 |
NF-PM1 | PM | Pollard法因数探索:B1=205000, B2=20500の範囲に因数は無い | 0.121 |
C | L-L(1st)Lucas-Lehmer素数判定:Residue(残余)が0とならない=合成数 | 5.385 | |
C | D(L-L) | Lucas-Lehmer素数判定:Residue(残余)が1stと一致=合成数確定 | 5.385 |
NF | TF | TF法2^65までに因数は無い | 0.283 |
NF | TF | TF法2^66までに因数は無い | 0.567 |
NF | TF | TF法2^67までに因数は無い | 1.134 |
NF | TF | TF法2^68までに因数は無い | 2.267 |
NF | TF | TF法2^69までに因数は無い | 4.534 |
NF | TF | TF法2^70までに因数は無い | 9.069 |
NF-ECM | ECM | Elliptic Curve法:1曲線B1=50000、B2=5000000の範囲に因数は無い | 0.621 |
計算量を節約するならL-Lテスト前にTF 2^68やNF-ECMを通すべきだが、素数探しが優先してL-Lが先に実行されたのだろう。ちなみにL-Lテストは1stを通した人が発見者となるらしい。バグで残余値が誤る場合もあったらしく、Dで0、素数を発見できる可能性もあったのだろう。この数は1st、D、3rdまで同一の方が通している。
逆に素数で確定している13466917は、Dが実行されていない。いいのだろうか?
GIMPS Milestones Reportによれば、Dは36046457まで、LL(1st)は67364459まで検証されている。
つまり、h5~h7が現在取り組んでいる4千万台の指数は、LL(1st)が計算ミスで、実は残余が0であることを発見した場合にのみ発見者となれるのだろう。
現在、下記を計算中だが、どうしようかと思う。
h7 2 42,930,721 D LL, 8.50% 3 2016-06-03 2016-06-05 2016-06-06 2016-06-15 10
h7 1 42,932,167 D LL, 8.80% 3 2016-06-03 2016-06-05 2016-06-06 2016-06-15 10
h7 3 42,932,363 D LL, 8.90% 3 2016-06-03 2016-06-05 2016-06-06 2016-06-15 9
h7 4 42,934,103 D LL, 8.10% 3 2016-06-03 2016-06-05 2016-06-06 2016-06-15 10
コメント 0