Each time An Amicable Numbers 10^21 task is run, all the prime numbers < 10^11 need to be stored in memory.

Are all the prime numbers < 10^11 computed each time a 10^21 task is run?
If so, is it possible to store all the prime numbers < 10^11 in a file, such as Primes.txt at c:\ProgramData\BOINC\projects\sech.me_boinc_Amicable?

Under Amicable Number preferences, there would be 3 choices
- Amicable Numbers up to 10^21, create Prime Table --- This task would be run only once
- Amicable Numbers up to 10^21 --- Each task would compute all the prime numbers < 10^11
- Amicable Numbers up to 10^21, Prime Table Exists --- The logic would have to be modified to access the Prime Table rather than compute all the prime numbers < 10^11.

I prefer not to store prime table on disc as it can get corrupt/overwritten either occasionally or maliciously.

I understand your concerns regarding corruption/overwriting of a prime table; however, there are steps which can be taken to manage this and minimize the possibility of corruption/overwriting occurring.

- When the prime table is loaded into an Amicable Numbers task, verify that the number of prime numbers is correct and utilize some type of check sum.
If the number of prime numbers or check sum is incorrect, regenerate the prime table.
- Automatically replace and regenerate the prime table on a specific interval, such as when you encounter a prime table that is older than 7, 14 or 28, etc. days.
The date and time of when the prime table was generated can be the first record on the prime table.
- Each Amicable Numbers task is run twice, as a double check.
When the double check task doesn't agree with the first run, run the task a third time.

When I think of how much time my computer spends each month generating the same prime table for each Amicable Numbers task, it is a huge amount of my computer's CPU time. Yes, it is possible that a minimal number of Amicable Pairs may not be found; however, it will really speed up 10^21 and allow getting to 10^22 much faster.

however, it will really speed up 10^21 and allow getting to 10^22 much faster.

Alan how much quicker do you think it would allow us to move onto 10^22? I am not sure that speed is the name of the game here

You asked a good question. This is hard to estimate because an Amicable Numbers task does not provide any information regarding when it's computing and loading the prime table vs. when it's searching for amicable pairs.

I run Amicable Numbers on two PCs in CPU mode, each using 3 CPUs. Each task requires about 6 hours elapsed time to run, so 8 tasks are run daily across the 2 PCs. I run 8 tasks daily, 56 runs weekly, 240 tasks monthly.

At least for the first hour of each CPU task, if not longer, the prime table is being computed and loaded. During this time period on my PC, my memory utilization is very high and other apps response time is very slow. If the first hour of each task is computing and loading the prime table, then 1 hour could be saved on each task if the prime table were just simply loaded. This would result in a 16.7% reduction in CPU time per task, allowing me to run 288 tasks monthly vs. 240 monthly. If the CPU time to compute and load the prime table is longer than 1 hour, then the savings would be greater.

For a GPU task, it is my understanding that the prime table is loaded using CPU, then the search for amicable pairs is done using GPU. The savings for loading the prime table directly into a GPU task may be more significant.

If it takes 1 hour to compute prime table, you're doing something seriously wrong. It usually takes no more than 1 minute and is done on a single CPU core, then it starts using all CPU cores, so it's easy to notice how much time it takes.

If it takes 1 hour to compute prime table, you're doing something seriously wrong. It usually takes no more than 1 minute and is done on a single CPU core, then it starts using all CPU cores, so it's easy to notice how much time it takes.

Thanks Alan for your detailed description below. I honestly cannot see task processing been increased a a lot because of the message above.