mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Information & Answers (https://www.mersenneforum.org/forumdisplay.php?f=38)
-   -   100M exponent idea (https://www.mersenneforum.org/showthread.php?t=10791)

MrOzzy 2008-10-16 12:52

100M exponent idea
 
We all know with the current technology and software it will take sevral years to test an 100M candidate.
Since it takes so long for someone to complete the test chances someone gives up someware down the line are rather high.
People also will use mutiple cores and waste a lot of cpu time to the overhead trying to finish the LL test as fast as they can. It is a lot more efficient testing multiple candidates at once. So why doesnt GIMPS split up the work? For example someone runs a LL test on an exponent for 1 month. The results of this test are checked in and uploaded to the GIMPS servers. Now the person checking the exponent can continue testing it or pick something else.
If eventually a prime is found everyone working on a specific exponent will be credited according to the amount of work they contributed.
I'm not sure this is technically possible, but if one single computer can continue where it left off another computer also can.
It also will allow double checking someone else work before a complete exponent is finished.

Mini-Geek 2008-10-16 12:59

Technically this is possible, but would require transferring files that are several megabytes, so probably won't be done.

jrk 2008-10-16 15:27

Yeah the smallest 100M digit Mersennes would take about 40 MB of storage and bandwidth to store an interim file.

henryzz 2008-10-16 19:03

40mb would take me about 20min to upload i think currently although in the future i could see a plan like this working

potonono 2008-10-16 23:18

Is that theoretical 40 Mb compress, or uncompressed?

axn 2008-10-16 23:25

[QUOTE=potonono;145589]Is that theoretical 40 Mb compress, or uncompressed?[/QUOTE]

Theoretically, the intermediate values of the LL test should be fairly random and thus compress poorly (less than 5% reduction).

/SWAG

retina 2008-10-16 23:43

I cant see how this "idea" would encourage people to run 100M numbers in any way. Someone runs, say, the first million iterations then uploads the residue file to somewhere, then another person downloads it and runs another million, etc. How does that help towards running it any faster? How does that stop people being bored with it? There are still no final results for many years and people just see numbers (and large data files) coming and going for years with seemingly no conclusion. What happens when a final test is returned with a bad residue? After all the hard work everyone does and one bad CPU/MOBO has ruined the result for all! Who provides the huge bandwidth and disc space to store the interim files? That is not going to be cheap.

joblack 2008-10-16 23:46

There would be also the problem whom to give the 75.000 USD (from the EFF price).

Does prime95 support the nehalem 12 (/24) Core architecture. It should be possible to shorten the time for one 100m digital number under 1 year?!

jrk 2008-10-17 00:00

[quote=potonono;145589]Is that theoretical 40 Mb compress, or uncompressed?[/quote]

The big numbers in the interim files are not compressible at all (well, it could theoretically be compressed very small, if your compression algorithm includes a Lucas-Lehmer function to decompress it :smile: but that would be defeating the purpose of storing the interim file in the first place...).

Just for fun I compressed some interim files with gzip and bzip2.

Gzip [B]inflates[/B] the files by 0.016%.

Bzip2 [B]inflates[/B] the files by 0.44% and takes 6 times as long as gzip to do so.

ATH 2008-10-17 00:11

Savefile for my 46M exponent (13.87M digits) takes 5.76Mb, so that is around 41.5% of the digits in bytes, so if this holds a 100M digit exponent would take 41.5Mb.

Batalov 2008-10-17 00:47

Dudes, the save file simply contains a 64-byte header with the status data and then the (rotated) residue modulo your number (that is [B]p[/B] bits). That means that the size of the savefile is 64+[B]p[/B]/8 bytes (=40551Kb for the lowest number), and it is surely incompressible (because it is essentially random noise).


All times are UTC. The time now is 05:40.

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