mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Riesel Prime Search (https://www.mersenneforum.org/forumdisplay.php?f=59)
-   -   69 * 2^n - 1 (https://www.mersenneforum.org/showthread.php?t=18600)

diep 2013-09-17 20:26

69 * 2^n - 1
 
Where is the current search located at 69 * 2^n - 1?

I saw on homepage report of 2416k. I'll take over from there.
Where can i find all results so far (factorisation results, sieving results etc)?

Kind Regards,
Vincent Diepeveen
[email]diep@xs4all.nl[/email]

VBCurtis 2013-09-18 02:42

69 is part of the "First Megabit Drive", and is searched as part of that drive. If you'd like to search for primes at that level, simply reserve a file or two from that thread- it's stickied near the top of the forum.

diep 2013-09-18 09:24

[QUOTE=VBCurtis;353297]69 is part of the "First Megabit Drive", and is searched as part of that drive. If you'd like to search for primes at that level, simply reserve a file or two from that thread- it's stickied near the top of the forum.[/QUOTE]

Oh we have a few tflop idle here and like to search 1 prime deeply. Seeing megadrive not very active yet i'll pick a different one otherwise.

Kosmaj 2013-09-18 10:00

Can you start k=69 from n=2500k? We'll remove k=51 from the drive at 2500k (already being tested by Retep) and at the same time we can remove k=69 as well.

Thanks!

diep 2013-09-18 10:03

[QUOTE=Kosmaj;353313]Can you start k=69 from n=2500k? We'll remove k=51 from the drive at 2500k (already being tested by Retep) and at the same time we can remove k=69 as well.

Thanks![/QUOTE]

That's ok.
I'll start at 2500k.

diep 2013-09-18 10:06

Until where did this range get double checked or is it entirely single checked?

Kosmaj 2013-09-18 11:51

k=69 is completely checked from n=1 up to n=2416k.
Double check was done from n=1 up to n=100k by D. Broadhurst.

All known primes for all k<300 are listed [URL="http://www.15k.org/riesellist.html"]here[/URL]. Current limits are given as well (they may not be up to date for k=1, 3, 27, and 121).

Thanks for your interest and happy hunting! :smile:

ps. Please inform us about your progress from time to time, and attach your results if possible.
And we'll appreciate if you include our project RPS (Riesel Prime Search) in you prover's code when you report primes.

pinhodecarlos 2013-09-18 18:34

Why this k? :huh:

diep 2013-09-18 18:55

Wagstaff gets 69 next year, hopefully PrimeGrid will celebrate that with a massive sprint at Wagstaff to the next PRP there, directly after Jeff Gilchrist finishes 10M, we'll collect everything then and ship it to PG hoping for that anniversary celebration :)

diep 2013-09-25 16:57

Update 25 september: busy sieving 2500k - 10M.
Will take some time.

amphoria 2013-09-25 17:13

[QUOTE=diep;354132]Update 25 september: busy sieving 2500k - 10M.
Will take some time.[/QUOTE]

Primegrid have already sieved all k < 10000 to a level that you are unlikely to ever achieve on your own - N < 3M to 100P and N=3-6M currently at 314P. The files can be downloaded from this thread: [url]http://www.mersenneforum.org/showthread.php?t=18255[/url]

diep 2013-09-25 17:54

holy smoke!

Even if i would have the time to get something going at the Tesla's here i wouldn't get to those ranges any quick :)

Toying with the alphabet now, especially (un)abcd :)

diep 2013-09-25 23:43

Moved it from sieving to testing.

Using sllr64 here right now at CPU hardware (Xeon L5420),
tested as fastest at the CPU hardware.

I remember Jean Penne busy with some gpgpu software, how did that progress lately; has Riesel Prime Search already a public version of that?

Got some Tesla's here. They idle now :)

VBCurtis 2013-09-26 04:04

CUDA-LLR is available, and in my experience stable. It only uses power-of-2 FFT sizes, and speed improves with larger exponents. The main FFT jump we care about is just over 3M for k=69, so your Teslas would be most useful in the upper 2M range, or over 5M (relative to CPU workers, that is).

Check in the hardware/GPU computing forum- I didn't see the thread when I glanced, but I've been running the program for over a year, even found a prime for k=5 with it in the 3-megabit range.
-Curtis

diep 2013-09-27 01:19

[QUOTE=VBCurtis;354213]CUDA-LLR is available, and in my experience stable. It only uses power-of-2 FFT sizes, and speed improves with larger exponents. The main FFT jump we care about is just over 3M for k=69, so your Teslas would be most useful in the upper 2M range, or over 5M (relative to CPU workers, that is).

Check in the hardware/GPU computing forum- I didn't see the thread when I glanced, but I've been running the program for over a year, even found a prime for k=5 with it in the 3-megabit range.
-Curtis[/QUOTE]

Thx Curtis, i downloaded it. Will try to get it to work!

Is that power of 2 the only 'disadvantage' over the IBDWT in SSE2 i got running currently?
I tend to remember how my own FFT implementation that also used power of 2 had another few disadvantages (let's say it polite) :)

The tesla's i got here are 0.5 Tflop in theory (of course that's always 2x more than it can do in terms of instructions, they always assume you can use multiply-add, not sure whether this FFT can), looking forward benchmarking it for this code!

Note it would be possible at Nvidia to run at each SIMD a different code stream. I don't know whether it still can deliver 0.5 Tflop doing that, yet if it can, should be easier to get rid of that power of 2 sized FFT? Maybe?

VBCurtis 2013-09-27 02:55

I don't recall what msft (user name, not company) said about the limitations of his code- I believe he stopped development shortly after he got it working, in favor of an OpenCL version for the other half of the GPUniverse.

I happen to have plenty of work available near 3M, so I haven't considered alternatives.

diep 2014-01-05 15:03

hi,

I found a prime, maybe some want to verify it is prime.
How to properly report it?

69 * 2 ^ 2649939 - 1 was found prime here!

Thanks,
Vincent

[email]diep@xs4all.nl[/email] in case i don't respond quickly at forum.

Kosmaj 2014-01-05 15:56

Hi diep

Congratulations!
To report it please create a new prover's code including RPS, Psieve, Srsieve and the software you used to prove it prime like LLR.

Thanks!

diep 2014-01-05 21:11

Tried all that, let me know if worked out ok. Thanks!

Paul Underwood verified with pfgw and confirms in meantime.

pinhodecarlos 2014-01-05 21:24

[QUOTE=diep;363882]Tried all that, let me know if worked out ok. Thanks!

Paul Underwood verified with pfgw and confirms in meantime.[/QUOTE]

It's correct.
[url]http://primes.utm.edu/primes/page.php?id=116841[/url]

diep 2014-01-05 22:20

thanks for verifying!

diep 2014-01-14 17:21

At the L5420 Xeon machines i have here at home, i had seen a pretty big jump in testing time moving up from roughly 2.74Mbit to 2.76 mbit

Testing times increased roughly from 6123 seconds to 7689 seconds.

Each CPU has 12 MB L2 cache.
So to speak 3MB a core
Seems it's the transform causing it, not the hardware.

Not sure about transform size internal.

If it stores 2.75M bits and assume 18 bits per double then it would require
an array sized 2.75mbits * 64 / (18 * 8 bits per byte) = 2.75 * 8 / 18 = 1.2 MB

Even double that would easily fit in L2.

At what mbit level can i again expect a big dang like that?

Is that at double this size at 5.5 Mbit?

Kosmaj 2014-01-14 22:50

Hi diep,

Yes, there is a jump in the length of the used FF transform, from about 144k to 160k, at n=2750k.

The next jump to 192k will appear at n=3274k.

diep 2014-01-14 23:06

Ah many thanks!

So the next jump makes it extra tough to find stuff of 1M digits :)

After a slow start first few months, it's 16 cores now which went steady, yet i guess i soon have to increase that to 32+ cores to keep the momentum because of the huge slowdowns.

Too bad i can't throw into battle the gpu's yet.

Know a description of how it works with this fft len size and the used transform?

I have a book from Pomerance & Crandall, yet those descriptions are not very usable to write code from and so far it seems one of the few books at least attempting to describe something :)

The FFT i implemented a few years ago, it works in a power of 2 larger. So to calculate n limbs one needs an array sized 2n limbs, which simply would mean a single 8 core box is same speed like 1 GPU, instead of the GPU being roughly 5x faster (Tesla C2075's i have here) or more than a single 8 core Xeon box here :)

pinhodecarlos 2014-01-15 11:27

Hi diep,

I found this: 69*2^2428251-1 is prime! (730979 decimal digits) Time : 2077.484 sec.

HEHEHEHEHEHE

diep 2014-01-15 14:06

Congratulations!

diep 2014-01-15 14:14

Did you finish it now to 2.5M?

As i started at 2.5M as appointed.
It's testing to 3M here now in the current batch.

pinhodecarlos 2014-01-15 14:48

[QUOTE=diep;364613]Did you finish it now to 2.5M?

As i started at 2.5M as appointed.
It's testing to 3M here now in the current batch.[/QUOTE]

It is a RPS drive, I am not testing it alone.
Check progress here: [url]http://www.mersenneforum.org/showthread.php?t=14087[/url]

diep 2014-01-15 14:53

Maybe you find another few primes there, let's hope so!

As for 69, note after this 2.41M find i hadn't expected in the range till 3M for another 2 at least to be there!
I thought: "maybe there is one around 2.8Mbit".

Yet already 2 showed up now :)

diep 2014-04-15 23:23

Last cores will take some time to finish yet 3M nearly completed.
Divided 3M-4M into pieces. Cores already busy short while there.

Maybe the gem shows up as the last to be checked!

All machines being equipped with ECC is tough to blame on a bitflip in RAM :)

If the crashed internet machine here fixed and other IT stuff might have look at CUDA again for doing Riesel with it.

diep 2014-05-09 22:30

Prime!

69 * 2 ^ 3097340 - 1 is prime

Please can one or more try to verify?

Thanks,
Vincent

pinhodecarlos 2014-05-09 23:25

If you trust your hardware just submit it. Only within an hour I will have an open slot to test this number.

paulunderwood 2014-05-09 23:25

[CODE]69*2^3097340-1 is prime! Time : 2579.994 sec.[/CODE]

Well done! :toot:

pinhodecarlos 2014-05-09 23:31

Paul tested.
Congratulations Vincent!

diep 2014-05-09 23:50

Thanks!

diep 2014-06-13 00:11

I was so lucky again:

69 * 2^3140225 - 1

[url]http://primes.utm.edu/primes/page.php?id=118012[/url]

status : proven

Kosmaj 2014-06-13 02:35

Hi diep,

Congrats on these nice 3-M bit primes!! Wagstaff's celebration will be a blast! :smile:

Kosmaj 2014-10-05 06:25

Hi diep,

I'm updating our status page and I wonder where are you now with your k=69 tests.

Tnx!

diep 2014-10-05 10:39

yes very far in the 3.5M+ yet one node with 8 finishing cores in range 2.95M - 3.2M suffered from heat problems and it yet has to be fixed coming week or so. I expect it to be up and running next week or so. So it doesn't make sense to call it for sure there are no primes in those ranges.

Odds become very realistic though next prime is > 1M digits.

Then after that i need a check i checked all the exponents i had to check.

My machines are not networked (poor man's security against consultants sneaking around) so each core has its own job.

Of course i found already 2 more primes than i had expected to find within this range, so i'm not complaining in that sense :)

edit: checked up to 2.98M all exponents once - more info 2 weeks from now.

Kosmaj 2014-10-05 12:53

diep, thanks for your quick reply. I'll mark your limit as n=2.98M for the time being.

No problems about the way you test the numbers just be sure to test every one at least once! :smile:

diep 2014-10-05 13:38

you bet they all get tested :)

It's getting winter here soon, so in order to not catch a cold i have no option except to increase number of cores at 69 :)

diep 2014-10-08 12:28

Yo, i have 1 box do clean up of remnants (left behind because of overheated box). Expect 2 cores might take weeks doing that. If they finish everything searched one time till 3.5M here.

diep 2014-11-17 01:23

Yo cleanup goes slow. 4 cores need to finish batch there. Week from now everything should have been checked once until around 3.42M and then when some finishing core finishes its slow moving batch some months from now it's rather unlikely there is a yet undiscovered prime underneath 3.50M

So odds start to get very small now there still is a prime under 3.42M

LLR times really slowed down going from some finishing 3.0M range as compared to for example 3.68M range. About 50% slowdown. Running currently 24 cores.

diep 2015-01-08 02:31

update: everything between 2.5M to 3.57M (so not all in 3.57M have finished yet up to 3.56M has been completely finished) has been checked once.

RPS i assume has finished up to 2.5M by now meaning everything for 69 * 2^n - 1 up until 3.56M has been checked once.

Busy checking up to 4M now.
Will take many months to finish everything until 4M.

pinhodecarlos 2015-01-08 11:52

[QUOTE=diep;391911]

RPS i assume has finished up to 2.5M by now meaning everything for 69 * 2^n - 1 up until 3.56M has been checked once.
[/QUOTE]

You are right. RPS finished k=69 to n=2.5M.

diep 2015-02-17 02:03

Good Early Morning! Fearing my hack in tool producing what to test for 69 * 2^n - 1 has bug

3M - 4M had roughly 53892 exponents to test and range am starting now at a few cores
4M - 5M has roughly 53990 exponents to test

Sounds weird to me such "huge" range has more exponents to test.

[url]http://www.mersenneforum.org/showthread.php?t=18255&page=5[/url]
shows both ranges sieved to 400P.

Note i might have used tad older abcd file for 3m-4m range to do this quick compare, whereas in reality i had upgraded in between testing the abcd file, so i suddenly had less to test then.

Yet i'm bit confused why this difference is there, anyone?

VBCurtis 2015-02-17 06:27

Both ranges span 1 million, both sieved to the same level, and the number of tests differs by 100. What is it you find strange? Can you rephrase your question?

Thomas11 2015-02-17 09:27

[QUOTE=diep;395638]
3M - 4M had roughly 53892 exponents to test
4M - 5M has roughly 53990 exponents to test
[/QUOTE]

From the latest sieve file for 3M-4M I get a slightly different number: only 53812 exponents.
And (just for comparison) for the range 5M-6M there are 53731 exponents.

As VBCurtis already mentioned: The difference is quite small and is just the typical fluctuation in the distribution of surviving exponents after sieving.

unconnected 2015-02-17 10:30

[QUOTE=Thomas11;395649]As VBCurtis already mentioned: The difference is quite small and is just the typical fluctuation in the distribution of surviving exponents after sieving.[/QUOTE]

I've checked some exponents and all seems OK except k=5.

[CODE] 51323 1M/t17_b2_k5.npg
48098 2M/t17_b2_k5.npg
45757 3M/t17_b2_k5.npg
34694 4M/t17_b2_k5.npg
34752 5M/t17_b2_k5.npg
34774 6M/t17_b2_k5.npg
[/CODE]Why so much difference between 1M-3M and 4M-6M ranges? Usually difference no more than 5-7%. For example, for k=33:

[CODE] 45919 1M/t17_b2_k33.npg
46129 2M/t17_b2_k33.npg
46271 3M/t17_b2_k33.npg
44182 4M/t17_b2_k33.npg
43896 5M/t17_b2_k33.npg
43877 6M/t17_b2_k33.npg
[/CODE]

pinhodecarlos 2015-02-17 10:45

First there was some kind of sieve gap and second they forgot to take out the algebraic factors from k=5.
More in this thread: [url]http://www.mersenneforum.org/showthread.php?t=19170[/url]

Thomas11 2015-02-17 11:38

[QUOTE=unconnected;395650]Why so much difference between 1M-3M and 4M-6M ranges? Usually difference no more than 5-7%. For example, for k=33:

[CODE] 45919 1M/t17_b2_k33.npg
46129 2M/t17_b2_k33.npg
46271 3M/t17_b2_k33.npg
44182 4M/t17_b2_k33.npg
43896 5M/t17_b2_k33.npg
43877 6M/t17_b2_k33.npg
[/CODE][/QUOTE]

1M-3M was sieved to p=100P, while 4M-6M has been sieved to p=400P.

The number of factors for a given sieve range (from p1 to p2) can be estimated by N1*(1-log(p1)/log(p2)), where N1 is the number of candidates at sieve level p1. Then the number of candidates surviving the sieve up to p2 should be roughly N2 = N1*log(p1)/log(p2).

By taking N1=46000 at p1=100P (=100*10^15) we get N2=44427 at p2=400P.
This makes the counts given above for k=33 (and all the other k's except k=5) quite plausible for me...

diep 2015-02-17 14:51

Thanks for the explanations and most interesting estimation formula!

At the risk of being wrong, i tend to remember when i trial factored Wagstaff ( (2^n + 1) / 3 ) that odds dramatic low that at a reasonable large domain, less exponents would be left than in a similar domain, given the same sieve depth.

Yet quite possible that with the much tougher sieving that's needed for Riesel, that sieve depths, though impossible to do at home that deep, still aren't deep enough for statistical logics to become reality.

diep 2015-02-21 12:53

Current status.

Everything tested once up to:

69*2^3614305-1 is not prime. LLR Res64: 09A4B35ED567A38D Time : 12454.741 sec.

diep 2015-04-04 19:25

Everything tested once up to 3.79M

Odds ticking away there still is a new gem < 4M

Kosmaj 2015-04-05 06:07

Hi diep,
Congrats on your dedication and a great run from n=2.5M, approaching 4M soon.

No worries about no new primes. The more composites, the more reasons to rejoice since every new test has higher and higher probability to produce a new prime! :-)

diep 2015-04-05 07:12

Thanks for the encouragement, much appreciated! I have each of the 24 cores that run do batches of 1000, so actually i'm already busy testing into the 4M range a tad. Up to 4.22M now. Within a few weeks that'll be 4.5M.

Yet will take 6+ months for the batches there to finish. If i keep 24 cores running then by end summer 2015 majority of the cores should be far over 4.5M with up to 4.5M nearly covered entirely.

If there is a prime within a few weeks, it's 50% odds it's > 4M. After that just 1 core out of 24 still searches < 4M.
About 3 months from now the last core should have finished < 4M range.

diep 2015-04-05 07:21

4.5M however if i divide it by the last prime found n=3140225

Then 4.5 / 3.14 = (roughly) 1.43x

Knowing it used to produce on average each factor 1.2 a prime, and not seldom 2 hide nearby, i hope that it still keeps going at 1.2x by then :)

Do not forget however how lucky i was when i started the formula, finding 3 primes and all 3 were at the start of a range of 1000 exponents that each core processes :)

pinhodecarlos 2015-05-19 20:19

Vincent,

Are you running the ranges manually or with prpnet/llrnet?

Carlos

diep 2015-05-19 20:36

Hello, i have no option but to run everything manual.

Machines that are networked here are getting hacked so terrible and i need to do the security on my own of them. So the only thing that has even remotely a chance of not crashing 20 times a day is by using airgapped machines. Also this linux machine which is on the internet crashes regular.

Fighting such systematic attacks that i get over the internet against my computers as i have IP number the same for 15 years now, is total impossible.

It takes me a lot of extra time - but that's how it is.

I have written several tools, recently one to split up ranges to many cores. If i start then the cores at the same time with a script they roughly also finish at same time finishing range.

That's very useful :)

So each 8 core Xeon here then is easier to maintain.

Before that i just used big batches that run for very long time and keep on back of an envelope an administration which core to regular check for being idle first :)

So with a few tools i split up the ranges into small files that get get started manual.

I'm searching in the 4.2 million now yet it'll take months for the slowest core to finish 4M. There is very little to check up to 4M though and i'm taking into account it's possible next 2 primes are around 4.5M. Will take some time until i'm there :)

pinhodecarlos 2015-05-19 20:40

So what's the gap to complete up to 4M? Can I be of assistance after I finish my current RPS Second Megabit Drive ranges? Please let me know.

diep 2015-05-19 21:03

Feel welcome, i have about 12-24 cores that crunch at it (most of time 24 real cores).
Statistically spoken I'm closing in on 2 megaprimes so you could be very lucky even if you just crunch a handful of numbers :)
Please contact me in message or skype: diepchess
69 is very thick formula, about 55k each million to check.

pinhodecarlos 2015-05-19 21:07

[QUOTE=diep;402654]Feel welcome, i have about 12-24 cores that crunch at it (most of time 24 real cores).
Statistically spoken I'm closing in on 2 megaprimes so you could be very lucky even if you just crunch a handful of numbers :)
Please contact me in message or skype: diepchess
69 is very thick formula, about 55k each million to check.[/QUOTE]

Thank you.

diep 2018-04-15 21:03

We're searching with 2 persons now at 69. Seems there is gap after last one which is 69 * 2 ^ 3140225 - 1

We busy 5.5+ mln now and this is very fat weight.

diep 2020-11-21 15:08

finished thanks to big work of Paul until 7M. I'm still having a few cores above 7M.

If someone wants to take over let me know. For my current (outdated) hardware i'm at the limits of what is possible to achieve here for 69.

Please note the statistical math supports the idea that there should be a 3d prime not too far away from the found 2 primes at 6.8M.

So if someone has big hardware and wants a shot at it let me know will then email the LLR output files exactly which exponents above 7M have been tried (up until 7.05M i had about 28 cores running until a few hours ago, some of which finished their batches).

k=69 is kind of 'behind' in number of produced primes so it's possible there is a bunch of them at 7m - 8m range.

ryanp 2020-12-04 17:13

[QUOTE=diep;563946]finished thanks to big work of Paul until 7M. I'm still having a few cores above 7M.

If someone wants to take over let me know. For my current (outdated) hardware i'm at the limits of what is possible to achieve here for 69.[/QUOTE]

I'm taking this to n=12M now. Not much in the 7-10M range, but found this one: [url]https://primes.utm.edu/primes/page.php?id=131437[/url]

diep 2020-12-04 19:17

[QUOTE=ryanp;565252]I'm taking this to n=12M now. Not much in the 7-10M range, but found this one: [url]https://primes.utm.edu/primes/page.php?id=131437[/url][/QUOTE]

Congrats on that one!

Way further away than i had guessed!!

It had so many primes below 3.14M.

If we do math from there then it's 6.8M which is factor 2 and 11+M is really far away again. That's like factor 1.7 again.

Batalov 2020-12-04 19:24

[QUOTE=diep;563946]Please note the statistical math supports the idea that there should be a 3d prime not too far away from the found 2 primes at 6.8M. [/QUOTE]
"the statistical math" supports no such claim. Perhaps, numerology or [URL="https://en.wikipedia.org/wiki/Palmistry"]palmistry[/URL] does.

jwaltos 2020-12-05 08:26

They both do but only when Mercury is aligned with Saturn.

paulunderwood 2020-12-07 07:23

[QUOTE=jwaltos;565332]They both do but only when Mercury is aligned with Saturn.[/QUOTE]

It looks like there is a conjunction with a [URL="https://primes.utm.edu/primes/page.php?id=131439"]second 69 prime[/URL] :whistle:

paulunderwood 2021-07-29 08:22

Congrats to Ryan for a third 3 million plus digit 69 prime: [URL="https://primes.utm.edu/primes/page.php?id=132556"]69 *2^12231580 - 1[/URL] (3,682,075 decimal digits).

:banana:

mathwiz 2021-07-29 23:30

Uh oh... Is primes.utm.edu down?

Happy5214 2021-07-30 01:59

[QUOTE=mathwiz;584360]Uh oh... Is primes.utm.edu down?[/QUOTE]

PrimePages and the entire UT Martin website both appear to be down right now.

paulunderwood 2021-08-20 19:27

Another congrats to Ryan Propper for the new 69 prime: [URL="https://primes.utm.edu/primes/page.php?id=132634"]69*2^15866556-1[/URL] (4,776,312 decimal digits). :banana:

diep 2021-08-31 12:28

Yes much congrats. It's delivering less primes than i would've expected.

Last 6 primes projected after the 3.14m i found then on average each new prime is factor 1.3 further away.

That is pretty bad and way way less primes than i would've expected.


All times are UTC. The time now is 13:50.

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