[QUOTE=Fan Ming;539006]I know it's not hard to modify the code of gpuowl to do LL tests. I've already modified a LL version of a relative new version of gpuowl (not newest, without Jacobi check, however, if running on Google colab, the result is reliable and thus not a significant problem), and reproduced the LL residue of M1000003 successfully.[/QUOTE]
Including residue shift, or not? Residue shift in context of LL is a bit trickier than in PRP because one needs to efficiently compute the proper bit position where to inject the -2 to each iteration's autosquare result. I've only been running gpuOwl for ~1 month, so perhaps one of the old hands can tell me whether previous versions of the code which supported LL also supported shift.

[QUOTE=paulunderwood;539031]After running gpuOwl for a week or so Linux "kworker" creeps up and uses nearly a full core which detracts from LLR crunching on the CPU. A simple fix is stop gpuOwl and immediately resume it. :cool:[/QUOTE]
Thanks for the reminder - noticed this a.m. that my Mlucas job on the Haswell system which hosts my Radeon VII was running ~5% slower than it should - ad cool weather move in yesterday, so thermal throttling was not the culprit. Just did a 'top', spotted a kworker task eating ~10% CPU time.

Double check succeeded:
[M]50840131[/M]

[QUOTE=ewmayer;539042]Including residue shift, or not? Residue shift in context of LL is a bit trickier than in PRP because one needs to efficiently compute the proper bit position where to inject the -2 to each iteration's autosquare result. I've only been running gpuOwl for ~1 month, so perhaps one of the old hands can tell me whether previous versions of the code which supported LL also supported shift.
[/QUOTE]

IIRC I've ever seen some version of gpuowl support residue shift before shift to gpuowl. Residue shift is indeed a little tricky and I haven't consider about that know. I would like to wait for the "official" add back of LL :).

[QUOTE=kriesel;539036]Mihai showed a way to add the Jacobi check back at V0.6 Addition of Jacobi check to LL flavor of gpuOwL [URL="http://www.mersenneforum.org/showpost.php?p=465145&postcount=46"]http://www.mersenneforum.org/showpos...5&postcount=46[/URL] 2017-08-08[/QUOTE]

Yes, it would be not hard to port the Jacobi check to current versions, I guess.

[QUOTE=preda;538851]For what exponent range? you should use the P-1 probability calculator
[url]https://www.mersenne.ca/prob.php[/url]
to get an idea of what to expect.

For an intuition, there is a range of the ratio between B1 and B2 that makes sense. I'd say this range is 10 to 100. If B2 is much-much larger that B1, you're wasting power.

Based on that, for a B2=4'000'000'000 (i.e. around 2^32), you'd want a B1 of at least 40'000'000 (but probably B1=100'000'000 would make more sense). Now you see that probably you could do a full PRP for less than that.

So unless you have a very special reason, doing P-1 with B2 > 2^32 seems like a bad idea to me. Maybe you could explain more about what you're trying to achieve.[/QUOTE]

Good points. I was trying to factor a few already known composites that I'm interested in factoring. There is no real good reason to do so, other than for fun.

[QUOTE=mrh;539185]Good points. I was trying to factor a few already known composites that I'm interested in factoring. There is no real good reason to do so, other than for fun.[/QUOTE]

I heard that elliptic curves (ECM) are a more efficient factorization tool (compared to P-1) past a certain point; but I don't know much about that.

P-1 only finds factors where p-1 is higly composite. If you're unlucky and the factors you search for aren't p-1 higly composite, P-1 simply won't find them.

small updates
 

In recent commits, I
- dropped WORKINGOUT0,1,1A,2 because they were not "best" in any setup
- made WORKINGOUT5 the new default on AMD, because it's faster on ROCm 3.1 (one can specify -use WORKINGOUT3 to get the old behavior on AMD)
- factorized the code of fftMiddleOut() which should make future changes easier
- reported another ROCm 3.1 basic bug see [url]https://github.com/RadeonOpenCompute/ROCm/issues/1039[/url]

[QUOTE=preda;539192]I heard that elliptic curves (ECM) are a more efficient factorization tool (compared to P-1) past a certain point; but I don't know much about that.

P-1 only finds factors where p-1 is higly composite. If you're unlucky and the factors you search for aren't p-1 higly composite, P-1 simply won't find them.[/QUOTE]

If the number in question has multiple smallish factors, p-1 is a good bet to find at least one of them, though not nec. the smallest. Good way to think about p-1 is that it is like running a single super-efficient ECM curve - thus bounds can be quite a bit deeper than for each ECM curve, but unlike ECM, p-1 depends on a hoped-for smoothness property of one of factors, i.e. can't be Monte-Carlo'd like ECM can, where each distinct curve yields a different underlying group order which turns up a factor if it happens to be smooth.

By the way, what does it mean if I get a "exponent/[exponent].owl file invalid" message on program restart-after-interrupt? The run in question seemed to continue OK from where it left off, so the message has me puzzled.

[QUOTE=ewmayer;539333]By the way, what does it mean if I get a "exponent/[exponent].owl file invalid" message on program restart-after-interrupt? The run in question seemed to continue OK from where it left off, so the message has me puzzled.[/QUOTE]

What kind of interrupt? -- normal exit after Ctrl-C (or kill -INT) should not produce an invalid savefile.

Maybe the program loaded from the backup savefile (x-old.owl) and continued from there. Can you reproduce it -- do you get the "invalid" every time when you stop/restart?

Interrupt was a machine crash - this is my ever-flaky Haswell system. Here the relevant logfile excerpt, with my [crash] annotation and the error message bolded... note said annotation replaces a string of unprintable-chars my editor warns me about on opening the file:
[quote]2020-03-10 11:23:48 gfx906+sram-ecc-0 102991709 OK 10200000 9.90%; 753 us/it; ETA 0d 19:25; 36e1b632ae34878c (check 0.43s)
2020-03-10 11:26:21 gfx906+sram-ecc-0 102991709 OK 10400000 10.10%; 753 us/it; ETA 0d 19:21; 6d3f77a36e3131f3 (check 0.42s)
[crash and reboot]
2020-03-10 11:32:26 Note: not found 'config.txt'
2020-03-10 11:32:26 device 0, unique id ''
2020-03-10 11:32:27 gfx906+sram-ecc-0 102991709 FFT 5632K: Width 256x4, Height 64x4, Middle 11; 17.86 bits/word
2020-03-10 11:32:27 gfx906+sram-ecc-0 OpenCL args "-DEXP=102991709u -DWIDTH=1024u -DSMALL_HEIGHT=256u -DMIDDLE=11u -DWEIGHT_STEP=0x1.1a6c87b447f22p+0 -DIWEIGHT_STEP=0x1.d018bc69e315ep-1 -DWEIGHT_BIGSTEP=0x1.ae89f995ad3adp+0 -DIWEIGHT_BIGSTEP=0x1.306fe0a31b715p-1 -DAMDGPU=1 -I. -cl-fast-relaxed-math -cl-std=CL2.0"
2020-03-10 11:32:30 gfx906+sram-ecc-0 warning: argument unused during compilation: '-I .'

2020-03-10 11:32:30 gfx906+sram-ecc-0 OpenCL compilation in 2.68 s
[b]2020-03-10 11:32:30 gfx906+sram-ecc-0 '/home/ewmayer/gpuowl/run0/102991709/102991709.owl' invalid[/b]
2020-03-10 11:32:31 gfx906+sram-ecc-0 102991709 OK 10400000 loaded: blockSize 400, 6d3f77a36e3131f3
2020-03-10 11:32:32 gfx906+sram-ecc-0 102991709 OK 10400800 10.10%; 739 us/it; ETA 0d 19:00; 05b55ba4212cf24f (check 0.41s)
2020-03-10 11:35:02 gfx906+sram-ecc-0 102991709 OK 10600000 10.29%; 754 us/it; ETA 0d 19:22; b9ab5fb12a1b7357 (check 0.42s)
2020-03-10 11:37:33 gfx906+sram-ecc-0 102991709 OK 10800000 10.49%; 754 us/it; ETA 0d 19:18; 14d7a3f361dfd1cb (check 0.43s)[/quote]
First time I'd seen the 'invalid' error message, but now that I grep for it in the gpuowl.log file, I see 12 occurrences including the latest one above. These are far from the only programs restarts in the log, but as it happens, each of the 'invalid's coincides with a crash that left one of the aforementioned unprintable-char sequences in the log. So data corruption is likely reaponsible for the symptoms - so the 'invalid' is telling me the program found a corrupted primary restart file and is resorting to using the secondary one as a result?