mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2018-06-07, 18:30   #23
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

6,659 Posts
Default

Quote:
Originally Posted by preda View Post
For a new prime candidate, fast verification could be done by parallel chunk verification based on different checkpoints. (if those were available).

Let's say for a 100M exponent, there are available checkpoints saved every 10M iterations. Then 10 computers could in parallel verify the 10 chunks.
Quite right, and if I recall correctly, something very like that has been done sometimes for past newly discovered Mersenne primes. (Might not have been n=ten, but the parallel running of iteration 0 to x and check interim residue on system 1, run x to 2x from a checkpoint file and compare 2x-iteration residue on system 2, etc up to n.)

It depends on the availability of those interim save files existing, and software capable of handling them, and hardware capable of completing the task in a feasible period of time. None of those would exist in the case of the original very high exponent claim question that launched this thread. Not for quite a while yet. M41,033,333,333,323 on CUDALucas is around 36,000 times too large for its theoretical max fft length. It's also known to have an issue running high exponents within its max fft length.
kriesel is online now   Reply With Quote
Old 2018-06-08, 00:26   #24
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

3·7·13·43 Posts
Default

Quote:
Originally Posted by preda View Post
For a new prime candidate, fast verification could be done by parallel chunk verification based on different checkpoints. (if those were available).

Let's say for a 100M exponent, there are available checkpoints saved every 10M iterations. Then 10 computers could in parallel verify the 10 chunks.
My code has long done the deposit-persistent-savefiles-every-10M-iterations thing mainly on "in case the 2 redundant updated-every-checkpoint savefiles somehow both get corrupted" grounds, but I don't recall such a scheme having ever been used for a GIMPS new-prime verification. Savefile compatibility is likely the blocking issue for the independent-software verify runs.
ewmayer is offline   Reply With Quote
Old 2018-06-08, 00:42   #25
preda
 
preda's Avatar
 
"Mihai Preda"
Apr 2015

138210 Posts
Default

Quote:
Originally Posted by ewmayer View Post
My code has long done the deposit-persistent-savefiles-every-10M-iterations thing mainly on "in case the 2 redundant updated-every-checkpoint savefiles somehow both get corrupted" grounds, but I don't recall such a scheme having ever been used for a GIMPS new-prime verification. Savefile compatibility is likely the blocking issue for the independent-software verify runs.
Yes. Should we agree on a "portable savefile format" then? I have a couple starting ideas about what's needed:
- kind of test: LL or PRP (could be a string id).
- exponent (N)
- iteration

for PRP only:
- block size for Gerbicz error-check (AKA "L")
- N bits, as 32-bit words, representing the "check bits".

for LL only:
- N bits, as 32-bit words, representing the "data bits"

Note what is *not* needed in the "portable savefile":
- offset
- balanced words, or bits allocated into words according to software-specific rules.

Last fiddled with by preda on 2018-06-08 at 00:42
preda is offline   Reply With Quote
Old 2018-06-08, 00:48   #26
preda
 
preda's Avatar
 
"Mihai Preda"
Apr 2015

2·691 Posts
Default

Quote:
Originally Posted by ewmayer View Post
My code has long done the deposit-persistent-savefiles-every-10M-iterations [...] but I don't recall such a scheme having ever been used for a GIMPS new-prime verification.
This may be because for historical reasons, there is the perception that "savefiles are huge thus very difficult to transfer between computers, not to mention storing on a server".

OTOH, the savefile for a 300M exponent is 40MBytes.

Last fiddled with by preda on 2018-06-08 at 00:49
preda is offline   Reply With Quote
Old 2018-06-08, 01:54   #27
preda
 
preda's Avatar
 
"Mihai Preda"
Apr 2015

2·691 Posts
Default

Quote:
Originally Posted by preda View Post
- N bits, as 32-bit words


Scrap that -- we should store the N bits as bytes (instead of 32-bit words), and then we have a byte-oriented format and there's no need to specify endianess.
preda is offline   Reply With Quote
Old 2018-06-08, 05:52   #28
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

6,659 Posts
Default

Quote:
Originally Posted by ewmayer View Post
My code has long done the deposit-persistent-savefiles-every-10M-iterations thing mainly on "in case the 2 redundant updated-every-checkpoint savefiles somehow both get corrupted" grounds, but I don't recall such a scheme having ever been used for a GIMPS new-prime verification. Savefile compatibility is likely the blocking issue for the independent-software verify runs.
"Serge Batalov also verified it using Ernst Mayer's MLucas software on two Intel Xeon 18-core Amazon EC2 servers in 3.5 days." https://www.mersenne.org/primes/?press=M74207281
Not first and second half of iterations, but duplicate full runs?

I'd expect the n-parallel approach to work well with prime95/mprime since it is very common.
kriesel is online now   Reply With Quote
Old 2018-06-08, 06:39   #29
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

6,659 Posts
Default

Quote:
Originally Posted by preda View Post
Scrap that -- we should store the N bits as bytes (instead of 32-bit words), and then we have a byte-oriented format and there's no need to specify endianess.
Header info indicating exchange standard and version, what program generated it, program version, subversion, ISO UTC time and date, UID and system name if available. Some of that is included in such standards as IGES or STEP for CAD exchange. https://en.wikipedia.org/wiki/IGES#File_format https://en.wikipedia.org/wiki/ISO_10...HEADER_section
Definitely not a fan of the fixed-80-char-length and H format in IGES. Maybe include in the header, the list of software the particular file content was derived from. (If it's run on Prime95 a while, then continued in CUDALucas before landing in Mlucas, the list grows each time a new application is used that's not yet in the list.)

MSB first, LSB last for the full residues?
Zero-filled to int(exponent+7)/8 bytes total? (Odds of one in 256 the MSB or LSB is a zero)
From a CUDALucas run last year,

| Jun 13 10:59:11 | M79341173 7750000 0x41af53c6e9343100 | 4608K 0.05078 6.1964 309.82s | 5:03:16:48 9.76% |

Checksum (multibyte; endian-ness?)

What's the endian-ness of the exponent? (27 bits or larger, so 4 bytes)

Last fiddled with by kriesel on 2018-06-08 at 06:43
kriesel is online now   Reply With Quote
Old 2018-06-08, 07:10   #30
S485122
 
S485122's Avatar
 
"Jacob"
Sep 2006
Brussels, Belgium

25·3·19 Posts
Default

Quote:
Originally Posted by kriesel View Post
...
None of those would exist in the case of the original very high exponent claim question that launched this thread. Not for quite a while yet. M41,033,333,333,323 on CUDALucas is around 36,000 times too large for its theoretical max fft length. It's also known to have an issue running high exponents within its max fft length.
Stop hammering on that particular number and its size. The OP responded to the first remark about that at the very beginning of the thread :
Quote:
Originally Posted by ICWiener View Post
That was just a random prime number. Replace it with any number verifiable by CUDALucas.
Jacob
S485122 is offline   Reply With Quote
Old 2018-06-08, 07:54   #31
preda
 
preda's Avatar
 
"Mihai Preda"
Apr 2015

25468 Posts
Default

Quote:
Originally Posted by kriesel View Post
What's the endian-ness of the exponent? (27 bits or larger, so 4 bytes)
I was thinking the header, which could be the first line if single-line, or the first few lines otherwise, could be a textual format. So the exponent would be a string of ASCII digits, part of the header.

After the header would come the "bits" which would be binary to save space and simplify save/load.

This would allow easy human inspection of the savefile.

Last fiddled with by preda on 2018-06-08 at 07:54
preda is offline   Reply With Quote
Old 2018-06-08, 13:21   #32
Xyzzy
 
Xyzzy's Avatar
 
Aug 2002

5·1,697 Posts
Default

Quote:
Originally Posted by kriesel View Post
Not first and second half of iterations, but duplicate full runs?
Full duplicate runs.

Xyzzy is offline   Reply With Quote
Old 2018-06-08, 19:22   #33
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

1A0316 Posts
Default Result pedigree

To protect the pedigree of results reports by software with security codes, such as prime95 / mprime, maybe the result reporting mechanism would need an extension. The confidence in results produced by prime95 from start to finish is likely to be higher than that for a run that finished there but was imported from some neutral format and other software and perhaps otherwise fiddled with in various ways. If, that is, Prime95 decides to support such a feature in prime95/ mprime at all.

What I'm imagining is the various programs at least flag that there was an import from other software, or preferably the full history list of which software titles were involved to that point. That's an extension both for Primenet and the various software reporting through it. Or is the portable format only for manual operation?

To my knowledge there is not documentation of the prime95 file formats, for the various supported computation types, other than the source code itself, available generally.
kriesel is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to know if you found a mersenne prime shaytan1986 Information & Answers 1 2015-07-26 03:38
Mersenne Prime Found? No. houding PrimeNet 4 2014-09-21 15:32
How to know if you found a mersenne prime. Sutton Shin PrimeNet 7 2012-10-02 05:57
new mersenne prime found unregistered Data 25 2005-01-07 19:26
Strategies when a Mersenne prime is found GP2 Lounge 30 2003-12-02 19:45

All times are UTC. The time now is 02:57.


Thu Aug 11 02:57:18 UTC 2022 up 34 days, 21:44, 2 users, load averages: 1.04, 1.02, 1.06

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔