Primes in π

[ATH]

Be careful with the -o output file. I tested the very first version you added to this thread on May 14th and I tested on the first 1000000 digits of pi and it created a huge output file which was > 50 GB in a few minutes before I noticed it and stopped it.

[J F]

Mhm, this is not the only case where it is better to break a big range into some chunks
instead of doing it in one run. Learned long time ago that stopping/restarting PFGW often
with multi-GB files is not the smart thing do to, for instance.

[J F]

ETA 29 Mar 22:47

But, what year?

[rogue]

Originally Posted by J F

Cool toy!

Note: v2.0 complained 3 DLLs missing (libgcc_s_seh-1, libstdc++-6
and libwinpthread-1 - someting MinGW-ish?). I could use the ones
from my SMPlayer (portable, so no DLLs registered system-wide)
Don't know how common these are on a non-programmers machine,
static link might be better for others who want to use this too.

Yes, it was built with MinGW64. I wasn't aware of dependencies. 1.2 was built with the same compiler, but doesn't requires those libraries. 2.0 uses C++ and 1.2 uses C.

[rogue]

Originally Posted by J F

Mhm, this is not the only case where it is better to break a big range into some chunks
instead of doing it in one run. Learned long time ago that stopping/restarting PFGW often
with multi-GB files is not the smart thing do to, for instance.

Agreed. Since the run time of PRP tests varies significantly, doing it in chunks makes a lot more sense WRT the desired removal rate.

[rogue]

Originally Posted by ATH

Be careful with the -o output file. I tested the very first version you added to this thread on May 14th and I tested on the first 1000000 digits of pi and it created a huge output file which was > 50 GB in a few minutes before I noticed it and stopped it.

One advantage of 2.0 is that it only writes at the end, but it will still write those massive strings. I could add a feature to pfgw to take a file, like an ABC file, and use it. The first line would be the decimal representation and the subsequent lines would have an offset and length of each term for the one specified on the first line.

[J F]

Originally Posted by rogue

One advantage of 2.0 is that it only writes at the end, but it will still write those massive strings. I could add a feature to pfgw to take a file, like an ABC file, and use it. The first line would be the decimal representation and the subsequent lines would have an offset and length of each term for the one specified on the first line.

Does this have other uses than cutting down file size (which we just agreed shouldn't be
too large anyway)?

[rogue]

Originally Posted by J F

Does this have other uses than cutting down file size (which we just agreed shouldn't be
too large anyway)?

I don't know. I can make it only so generic.

[J F]

Uhhh, composites...
command line
pixsieve -sPi1M.txt -S380 -P1e13 -l275500 -L280K -o_NoF -m1e16 -f20 -t3 -C5K
I did let it run for a while, ctrl-C, waiting for threads to finish and output
written, hand _NoF over to pfgw64 -i -V -l -f2 _NoF ... tons of small factors.
Trying good old -S10 -L20K: the same

I hope I'm doing something wrong with my parameters.

[rogue]

Originally Posted by J F

Uhhh, composites...
command line
pixsieve -sPi1M.txt -S380 -P1e13 -l275500 -L280K -o_NoF -m1e16 -f20 -t3 -C5K
I did let it run for a while, ctrl-C, waiting for threads to finish and output
written, hand _NoF over to pfgw64 -i -V -l -f2 _NoF ... tons of small factors.
Trying good old -S10 -L20K: the same

I hope I'm doing something wrong with my parameters.

The last byte in the output file with terms is truncated. I'll fix that tomorrow.

[rogue]

Fixed. I also fixed a threading issue where it wouldn't terminate very quickly if you had many threads.

In the next version I hope to have this working nicely with the pfgw changes I am working on. Those changes will reduce the size of the factor file and the terms file. I'll put those updates in this thread when they are ready.