Even PRP test can create false results, most likely due to hardware issues. Even the software can create false results, but it´s very very rare.
For example: Over all I created over 250 million unique primes with 0 false results (<1,4 Million digits)

Tests with higher FFT size were more susceptible to interference.

It looks like we move forward faster for "Search 4" than for "Search 3"

Yes, that is because subfield 4 is complex, which allows for tighter search bounds compared to real subfields. It is already on the 12th of 16 tiers and has caught up to the search over subfield 3.

Maybe in this case OpenACC could help (Their slogan is: "More Science, less programming").
It is quite easy to migrate existing code.
It is not as performant as native CUDA / OpenCL, but would still be a big runtime improvement.

Take a look at https://www.openacc.org/

Thanks for the link. I will check it out.

The batch status page (https://numberfields.asu.edu/NumberFields/batch_status.html) is no longer reporting progress. The status of subfield ℚ(√-2) is no longer listed.

---

I was wondering when someone was going to notice that... We've been burning through about 50k WUs per day. This is great, but the downside is that the database transactions are getting bogged down. If you are wondering how that's related, the php scripts that create the batch_status and server_status pages are doing DB queries and so these scripts are taking a long time to complete. They are setup as cron jobs to execute periodically and these cron jobs are stepping on each other as another one starts before the previous one finishes.

In the short term I will increase the time between status updates, which should reduce the chances of the cron job race condition. Longer term, I will ask the department to order a faster SS disk. If that gets approved, it could take weeks to get installed.

The batch status page (https://numberfields.asu.edu/NumberFields/batch_status.html) is no longer reporting progress. The status of subfield ℚ(√-2) is no longer listed.

The RakeSearch project (since the Fall of 2017, and officially announced in Dec 2017) has optimized apps that improve speed by 8x to 10x over previous versions. The new apps use SSE2 and (if available) AVX instructions. And, there are new versions that work on Arm computers - getting the performance of prior x86 implementations on, for example, Raspberry Pi 2 and 3 computers that are easily 8x slower than reference x86 machines. This isn't the same as going to a GPU (except, arguably, in the case of the Arm), but it is a step in that direction. SSE2 is the double precision version of "SIMD" (Single Instruction Multiple Data) x86 vector instructions. It's limited, but SIMD is how modern GPUs work. GPUs are expected to become MIMD (Multiple Instruction Multiple Data - much like the independent cores of a multicore x86) in the next decade or less. This should make it easier to toss an app at your video card. I say easier, because you'll still have bandwidth issues at multiple levels to deal with to get good performance. Perhaps a good optimizing compiler could do much of that work for you. The RakeSearch Arm versions are very impressive to me, since you mostly have to deal with these bandwidth issues manually on that platform, and word has it, it's a nightmare. Many would call it "impossible", which for others simply means it's a bunch of hard work.