Is it time for a 100M digit option?

[petrw1]

In the same way that Prime95 currently allows us to:
"Choose 10,000,000 digit numbers to test"

Does there now need to be an option to:
"Choose 100,000,000 digit numbers to test"

Sure it will take a LONG time but then my first 10M test 6 years ago took 15 months on my PIII-400. Would the 100M tests take any longer than that on current hardware?

OR as Mr. Silverman suggested in post #710 of the "BATMAN" thread, is it time to fill in the gaps?

[TimSorbet]

Prime95v25/PrimeNetv5 allow you to choose to search 100M digit candidates only. I think the default will still be to search the smallest first-time that are available (assuming a fast computer), i.e. filling in the gaps.

[petrw1]

My bad for not checking there first....

[Uncwilly]

I was hoping for a 100M TF option. BTW, how far would make sense and the settings for P-1 (or ECM)?

[jinydu]

Originally Posted by petrw1

Sure it will take a LONG time but then my first 10M test 6 years ago took 15 months on my PIII-400. Would the 100M tests take any longer than that on current hardware?

I think so. My test of M100,000,039 on one core of a desktop with Core 2 Duo E6700 will take over a year. Assuming that the amount of work required to complete a test is proportional to FFT size and proportional to the number of iterations, a test of M332,192,831 (the first Mersenne number above 100 million digits) would require over 11 times as much work. I think such a test would take at least 4 years on current hardware.

[Syd]

Originally Posted by jinydu

I think so. My test of M100,000,039 on one core of a desktop with Core 2 Duo E6700 will take over a year. Assuming that the amount of work required to complete a test is proportional to FFT size and proportional to the number of iterations, a test of M332,192,831 (the first Mersenne number above 100 million digits) would require over 11 times as much work. I think such a test would take at least 4 years on current hardware.

I tried M332192831 on my Q6700, with
1 Thread: 0.586 sec. per Iteration = about 6 years
2 Threads: 0.318 sec. per Iteration = 3 Years, 4 Months
3 Threads: 0.258 sec. per Iteration = 2 Years, 8 Months
4 Threads: 0.202 sec. per Iteration = 2 Years, 1 Month.

[Batalov]

Your memory chips are apparently good/fast. This is rather good scaling.
Would one expect to have no errors for 2 years on 4 cores? That is the question to ponder before embarking.

That reminds me to look for the origins of a citation that I long remembered but now completely unsure. From some sci-fi novel... It goes like this - "Should we depart for Alpha Centauri next year and arrive there in 50,000 years, or should we wait for another 50 years and then get there in 25,000 years?" (don't nitpick about the exact numbers, though, ok?)

--Serge

[ET_]

Originally Posted by Batalov

Your memory chips are apparently good/fast. This is rather good scaling.
Would one expect to have no errors for 2 years on 4 cores? That is the question to ponder before embarking.

That reminds me to look for the origins of a citation that I long remembered but now completely unsure. From some sci-fi novel... It goes like this - "Should we depart for Alpha Centauri next year and arrive there in 50,000 years, or should we wait for another 50 years and then get there in 25,000 years?" (don't nitpick about the exact numbers, though, ok?)

--Serge

Sagan's "Contact", maybe?

Luigi

[retina]

Originally Posted by Batalov

Your memory chips are apparently good/fast. This is rather good scaling.
Would one expect to have no errors for 2 years on 4 cores? That is the question to ponder before embarking.

That reminds me to look for the origins of a citation that I long remembered but now completely unsure. From some sci-fi novel... It goes like this - "Should we depart for Alpha Centauri next year and arrive there in 50,000 years, or should we wait for another 50 years and then get there in 25,000 years?" (don't nitpick about the exact numbers, though, ok?)

--Serge

I don't see this as the same thing. For the number testing we can transfer the current state of the test to a new machine and continue at a faster rate. But in contrast, for the Alpha Centauri trip the transfer of work to the new ship does not apply. So any number testing should be started now and any trips to Alpha Centauri should be started only when the expected time of arrival is at a minimum.

[xilman]

Originally Posted by retina

I don't see this as the same thing. For the number testing we can transfer the current state of the test to a new machine and continue at a faster rate. But in contrast, for the Alpha Centauri trip the transfer of work to the new ship does not apply. So any number testing should be started now and any trips to Alpha Centauri should be started only when the expected time of arrival is at a minimum.

I don't see any reason why, in principle, the faster ship should not be launched with sufficient spare capacity to pick up the occupants of the slower as it goes by.

Might not be economically viable though.

Paul

[retina]

Originally Posted by xilman

I don't see any reason why, in principle, the faster ship should not be launched with sufficient spare capacity to pick up the occupants of the slower as it goes by.

Sure, but then what was the point of the first group leaving so early? they might as will hang around partying and then jump on the second ship when it leaves.