mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Riesel Prime Search (https://www.mersenneforum.org/forumdisplay.php?f=59)
-   -   Post small primes and tell us about your progress here (https://www.mersenneforum.org/showthread.php?t=2150)

storm5510 2020-02-28 05:39

[QUOTE=diep;538442]I tried search exponent=733 some years ago until 4M.

If you interested you can reserve that one and continue there. If you so lucky you'll have a prime very quickly.

edit: did not finish search till 4M entirely.[/QUOTE]

I think it may simply be better to stay away from anything < 10,000.

It took me about ten minutes to write a short program to split sieves into work files of equal sizes for each machine. I was careful to make sure it did not skip anything in the source. It begins reading from the top and alternates writing each entry to one of two output files. The top line from the input is written first to both outputs since it contains needed information for [I]LLR[/I]. The work load is very balanced as they both finish running [I]LLR[/I] within a short period of time.

Nash tables: Using a looping batch process, I have generated a series of tables. It took some doing to get rid of all the extra spaces in each line. They are CSV format which can be imported into a spreadsheet to be sorted.

diep 2020-02-28 12:42

[QUOTE=storm5510;538488]I think it may simply be better to stay away from anything < 10,000.

It took me about ten minutes to write a short program to split sieves into work files of equal sizes for each machine. I was careful to make sure it did not skip anything in the source. It begins reading from the top and alternates writing each entry to one of two output files. The top line from the input is written first to both outputs since it contains needed information for [I]LLR[/I]. The work load is very balanced as they both finish running [I]LLR[/I] within a short period of time.

Nash tables: Using a looping batch process, I have generated a series of tables. It took some doing to get rid of all the extra spaces in each line. They are CSV format which can be imported into a spreadsheet to be sorted.[/QUOTE]

Note sure how far PG has sieved there. You care about this?

Myself i had reserved here k=32767

Will find a few more at later time. Much larger than this. Hopefully not too much time from now.

Yes i want search a couple of low weights at same time there, because for my gpgpu proggie i wrote half a dozen of them can be sieved at same time on the gpu. The small primes p smaller than 64 bits (63 bits in length and shorter - though for 64 bits i intend make a special kernel) get generated then fed to gpu where i wrote some code to sieve for Nvidia GPU's.

The slowest thing is the thing i didn't write - generating the small primes on the CPU. Though i did write a siever for cpu it's not ready production usage and it's single core and not using SSE2 (let alone AVX) versus what's there on the net is with SSE2 (SSSE on my oldie Xeons) and such great optimizations.

After that LLR.

Maybe i should revive my siever for cpu there and optimize it to feed faster small primes than a perfect siever there.

storm5510 2020-02-28 15:03

[QUOTE=diep;538502]Note sure how far PG has sieved there. You care about this?

Myself i had reserved here k=32767

Will find a few more at later time. Much larger than this. Hopefully not too much time from now.

Yes i want search a couple of low weights at same time there, because for my gpgpu proggie i wrote half a dozen of them can be sieved at same time on the gpu. The small primes p smaller than 64 bits (63 bits in length and shorter - though for 64 bits i intend make a special kernel) get generated then fed to gpu where i wrote some code to sieve for Nvidia GPU's.

The slowest thing is the thing i didn't write - generating the small primes on the CPU. Though i did write a siever for cpu it's not ready production usage and it's single core and not using SSE2 (let alone AVX) versus what's there on the net is with SSE2 (SSSE on my oldie Xeons) and such great optimizations.

After that LLR.

Maybe i should revive my siever for cpu there and optimize it to feed faster small primes than a perfect siever there.[/QUOTE]

PG is PrimeGrid, I take it?

My Nash tables exclude any Nash value < 1,000. The tables currently go up to [I]k[/I] = 924,000. They are divided into blocks averaging 65K bytes per file. If there is anything you would like to have, I can send it along.

I have a GTX 1080 in my i7 system which has not been used for anything in months. It would be nice to apply it to this project area. No GPU application program exists yet that I am aware of. Something similar to [I]LLR[/I] would be nice.

VBCurtis 2020-02-28 15:48

Using the primegrid sieve is a massive speed improvement; I'd stick to k under 10,000 because of that alone. Lots and lots of k's are searched to something less than a million; extending that work is a far better idea than trying so hard to find a k that nobody has yet worked on.

CUDA-LLR exists; you can find a thread about it, including source to download. It's not bug-free, but it works at least for some systems and some cards. I believe the largest k it supports is much smaller than that of regular LLR; or perhaps it was that the speed penalty for large k was much worse than that of regular LLR. Don't expect much support if you do try it- hardly anyone uses it.

diep 2020-02-28 20:07

[QUOTE=storm5510;538504]PG is PrimeGrid, I take it?

My Nash tables exclude any Nash value < 1,000. The tables currently go up to [I]k[/I] = 924,000. They are divided into blocks averaging 65K bytes per file. If there is anything you would like to have, I can send it along.

I have a GTX 1080 in my i7 system which has not been used for anything in months. It would be nice to apply it to this project area. No GPU application program exists yet that I am aware of. Something similar to [I]LLR[/I] would be nice.[/QUOTE]

If you have nashtables calculated that would be nice to see as i want to pickout a few low weight k's (not too low weight) and sieve those deep.

I wrote that gpgpu code myself in CUDA in 2016 - it's not ready for production yet as lacked priority to finish it.

GTX1080 is similar to some hundreds of cores newpgen there.

I've got a Titan Z here - also has some punch in DP.

The FFT implementation mine only exists on a cpu right now and for gpu only on paper. Sieving on gpu would be finished first with several kernels.

In all cases i go for throughput rather than latency. So running several tests at same time - to use all calculation power of the gpu rather than try to do 1 exponent as fast as possible.

Means effectively a single exponent (or a bunch) runs (run) within a single SIMD and has a very limited number of warps working at the same time for it.

So it's total different approach from what Nvidia releases.

edit: and it might not work for mersenne at all as those transforms are so huge that with that many exponents you would eat too much memory from the GPU's device RAM.

storm5510 2020-02-28 23:53

[QUOTE=diep;538545]If you have nashtables calculated that would be nice to see as i want to pickout a few low weight k's (not too low weight) and sieve those deep...[/QUOTE]

I restarted the process on my laptop. It is up to 1.5-million now. I believe I should probably stop. Send me a private message with an email address and if you have a preference of which areas are of interest, or you are welcome to the entire lot.

Thomas11 2020-02-29 13:03

[QUOTE=diep;538545]If you have nashtables calculated that would be nice to see as i want to pickout a few low weight k's (not too low weight) and sieve those deep.
[/QUOTE]

A bunch of about 4500 low weight k's can be found [URL="https://www.mersenneforum.org/showpost.php?p=78349&postcount=78"]here.[/URL]

Thomas11 2020-02-29 15:06

1 Attachment(s)
The attached file contains 322220 k (up to 100M) with Nash weight less or equal to 250.

storm5510 2020-03-01 00:37

[QUOTE=Thomas11;538588]The attached file contains 322220 k (up to 100M) with Nash weight less or equal to 250.[/QUOTE]

I am reworking mine to include [U]all[/U] [I]k'[/I]s regardless of Nash value in [I]k[/I] order. I will not need to run them again.

Thanks!

Happy5214 2020-03-01 02:43

[QUOTE=diep;538502]Yes i want search a couple of low weights at same time there, because for my gpgpu proggie i wrote half a dozen of them can be sieved at same time on the gpu. The small primes p smaller than 64 bits (63 bits in length and shorter - though for 64 bits i intend make a special kernel) get generated then fed to gpu where i wrote some code to sieve for Nvidia GPU's.

The slowest thing is the thing i didn't write - generating the small primes on the CPU. Though i did write a siever for cpu it's not ready production usage and it's single core and not using SSE2 (let alone AVX) versus what's there on the net is with SSE2 (SSSE on my oldie Xeons) and such great optimizations.

After that LLR.

Maybe i should revive my siever for cpu there and optimize it to feed faster small primes than a perfect siever there.[/QUOTE]

Is that code public? I wonder if Mark Rodenkirch (rogue, the maintainer of srsieve) would want to take a peek at that. He didn't seem to think that a GPU Riesel siever (or even AVX) would be viable due to the inconsistency in the baby-step giant-step discrete log runtimes.

storm5510 2020-03-02 13:18

98475*2^606759-1 is prime! (182658 decimal digits)

[I]k[/I] = 98475, [I]n[/I] tested to 610,000. Continuing.
No further until April.


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

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