Prime95 Questions
 

Hello fellow prime seekers. I am new to Prime95 and I was hoping that I could get some help here. I have the following questions:

1. How can I upload my benchmark results to the website?

2. I have a quad-core machine, but it seems that I can only run the advanced primality test on a single core? Is it possible to run it on multiple cores?

3. How can I accurately measure the running time of the advanced primality test? Currently it doesn't report the running time, only whether the number was prime or not.

Thank you for your help.

[QUOTE=dimkadimon;244754]1. How can I upload my benchmark results to the website?[/QUOTE]
I think that if Prime95 is set up to communicate with PrimeNet when you run the benchmark, it will automatically upload the results when it's done. You can log in at [url]http://www.mersenne.org/report_benchmarks/[/url] to see if the website has any of your benchmarks. If Prime95 is slow in communicating, do Advanced > Manual Communication and check "Send new expected completion dates to server".
[QUOTE=dimkadimon;244754]2. I have a quad-core machine, but it seems that I can only run the advanced primality test on a single core? Is it possible to run it on multiple cores?[/QUOTE]
It runs on a single worker window. To set the worker to use more than one core, go to Test > Worker Windows and set CPUs to use.
[QUOTE=dimkadimon;244754]3. How can I accurately measure the running time of the advanced primality test? Currently it doesn't report the running time, only whether the number was prime or not.[/QUOTE]
Occasional timestamps are written to results.txt, a timestamp to the minute is shown on each screen output, (screen output interval configurable in Options > Preferences, "Iterations between screen outputs") and you can look at the number of iterations and average time per iteration and multiply appropriately. It's basically only really a problem for very small numbers, where minutes are the whole test and the iteration time is about 0.000 or 0.001 sec per iter. Prime95 isn't really tuned for small numbers anyway.

Thank you heaps!

[QUOTE=Mini-Geek;244766]I think that if Prime95 is set up to communicate with PrimeNet when you run the benchmark, it will automatically upload the results when it's done. You can log in at [URL]http://www.mersenne.org/report_benchmarks/[/URL] to see if the website has any of your benchmarks. If Prime95 is slow in communicating, do Advanced > Manual Communication and check "Send new expected completion dates to server".
[/QUOTE]

I tried Manual Communication and got the following:

CURL library error: couldn't connect to host

[QUOTE=Mini-Geek;244766]
It runs on a single worker window. To set the worker to use more than one core, go to Test > Worker Windows and set CPUs to use.
[/QUOTE]

It seems that multiple cores are used only for the LL test and not for the other tests. Is this correct? By the way I am using Prime95 version 26.4.

In the CPU affinity question there are 3 options: 1-8=specific CPU, 99=any CPU, 100=smart assignment. If I know my CPU should I use 1-8, or is 100 still the safest way to go?

[QUOTE=dimkadimon;244771]I tried Manual Communication and got the following:

CURL library error: couldn't connect to host[/QUOTE]I get that a lot, but when I simply re-try Manual Communication immediately, it succeeds on 99% of the second tries.

[QUOTE=dimkadimon;244771]It seems that multiple cores are used only for the LL test and not for the other tests. Is this correct? By the way I am using Prime95 version 26.4.

In the CPU affinity question there are 3 options: 1-8=specific CPU, 99=any CPU, 100=smart assignment. If I know my CPU should I use 1-8, or is 100 still the safest way to go?[/QUOTE]

Under the "Test" option select "Worker Windows". Post what you actually see there, like the attached. There you can chose the number of workers and what they do.

The "1-8=specific" means that you can chose CPU/core #1, 2, 3, 4, 5, 6, 7, or 8. 100 is safe to start with, there are some cases where you may chose to change it later.

[QUOTE=dimkadimon;244771]It seems that multiple cores are used only for the LL test and not for the other tests. Is this correct? By the way I am using Prime95 version 26.4.[/QUOTE]
Partially. Prime95 can only use one core for TF, and the GCD that happens after each P-1 stage. Prime95 can use any number of cores for everything else, which is everything done through FFT: LL (whether set through Advanced > Test or any other way), P-1 stage 1 and 2, ECM stage 1 and 2, and PRP.
[QUOTE=dimkadimon;244771]In the CPU affinity question there are 3 options: 1-8=specific CPU, 99=any CPU, 100=smart assignment. If I know my CPU should I use 1-8, or is 100 still the safest way to go?[/QUOTE]
[QUOTE=Uncwilly;244783]Under the "Test" option select "Worker Windows". Post what you actually see there, like the attached. There you can chose the number of workers and what they do.

The "1-8=specific" means that you can chose CPU/core #1, 2, 3, 4, 5, 6, 7, or 8. 100 is safe to start with, there are some cases where you may chose to change it later.[/QUOTE]
Note that you might want to set the affinity too, but what I meant is the actual number of threads to use, "CPUs to use (multithreading):", which in Uncwilly's picture is grayed out. It is grayed out whenever the number of worker windows is already at the number of virtual cores your CPU has, because at that time there's no benefit to making any of the workers multithreaded. You have to reduce the number of workers first.

[QUOTE=Mini-Geek;244804] Prime95 can use any number of cores for everything else, which is everything done through FFT: LL (whether set through Advanced > Test or any other way), P-1 stage 1 and 2, ECM stage 1 and 2, and PRP.[/QUOTE]
I'd like to add that it the benchmark should be executed beforehand to see what number of cores used for e.g. LL gives best timings - not always more cores is better throughput:
[QUOTE]Compare your results to other computers at [URL]http://www.mersenne.org/report_benchmarks[/URL]
Intel(R) Xeon(TM) CPU 3.20GHz
CPU speed: 3191.29 MHz, 2 hyperthreaded cores
CPU features: RDTSC, CMOV, Prefetch, MMX, SSE, SSE2
L1 cache size: 16 KB
L2 cache size: 2 MB
L1 cache line size: 64 bytes
L2 cache line size: 64 bytes
TLBS: 64
Prime95 64-bit version 25.11, RdtscTiming=1
Best time for 768K FFT length: 35.031 ms.
// snip
Best time for 8192K FFT length: 493.619 ms.
[B]Timing FFTs using 2 threads on 1 physical CPUs.
Best time for 768K FFT length: 23.501 ms.[/B]
// snip
[B]Best time for 8192K FFT length: 324.386 ms.[/B]
Timing FFTs using 4 threads on 2 physical CPUs.
Best time for 768K FFT length: 27.303 ms.
// snip
Best time for 8192K FFT length: 446.017 ms.[/QUOTE]

[QUOTE=tichy;244806]I'd like to add that it the benchmark should be executed beforehand to see what number of cores used for e.g. LL gives best timings - not always more cores is better throughput:[/QUOTE]

Good idea. Turns out that 2 cores works the best for me. Here are my results:

[CODE]
Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz
CPU speed: 2833.73 MHz, 4 hyperthreaded cores
CPU features: RDTSC, CMOV, Prefetch, MMX, SSE, SSE2, SSE4
L1 cache size: 32 KB
L2 cache size: 256 KB, L3 cache size: 8 MB
L1 cache line size: 64 bytes
L2 cache line size: 64 bytes

[Work thread Jan 7 09:54] Timing FFTs using 4 threads on 2 physical CPUs.
[Work thread Jan 7 09:54] Timing 47 iterations of 768K FFT length. Best time: 2.901 ms., avg time: 2.980 ms.
[Work thread Jan 7 09:54] Timing 40 iterations of 896K FFT length. Best time: 3.545 ms., avg time: 3.570 ms.
[Work thread Jan 7 09:54] Timing 35 iterations of 1024K FFT length. Best time: 4.034 ms., avg time: 4.140 ms.
[Work thread Jan 7 09:54] Timing 28 iterations of 1280K FFT length. Best time: 4.835 ms., avg time: 4.875 ms.
[Work thread Jan 7 09:54] Timing 23 iterations of 1536K FFT length. Best time: 5.946 ms., avg time: 6.030 ms.
[Work thread Jan 7 09:54] Timing 20 iterations of 1792K FFT length. Best time: 7.734 ms., avg time: 7.775 ms.
[Work thread Jan 7 09:54] Timing 17 iterations of 2048K FFT length. Best time: 9.311 ms., avg time: 9.335 ms.
[Work thread Jan 7 09:55] Timing 14 iterations of 2560K FFT length. Best time: 10.882 ms., avg time: 10.941 ms.
[Work thread Jan 7 09:55] Timing 11 iterations of 3072K FFT length. Best time: 14.367 ms., avg time: 14.392 ms.
[Work thread Jan 7 09:55] Timing 10 iterations of 3584K FFT length. Best time: 16.655 ms., avg time: 16.737 ms.
[Work thread Jan 7 09:55] Timing 10 iterations of 4096K FFT length. Best time: 19.697 ms., avg time: 21.520 ms.
[Work thread Jan 7 09:55] Timing 10 iterations of 5120K FFT length. Best time: 25.262 ms., avg time: 25.325 ms.
[Work thread Jan 7 09:55] Timing 10 iterations of 6144K FFT length. Best time: 32.081 ms., avg time: 32.435 ms.
[Work thread Jan 7 09:55] Timing 10 iterations of 7168K FFT length. Best time: 45.641 ms., avg time: 47.401 ms.
[Work thread Jan 7 09:55] Timing 10 iterations of 8192K FFT length. Best time: 46.616 ms., avg time: 48.491 ms.
[/CODE]I think thats pretty good no?

[QUOTE=Mini-Geek;244804]Partially. Prime95 can only use one core for TF, and the GCD that happens after each P-1 stage. Prime95 can use any number of cores for everything else, which is everything done through FFT: LL (whether set through Advanced > Test or any other way), P-1 stage 1 and 2, ECM stage 1 and 2, and PRP.
[/QUOTE]

Thanks. It makes much more sense now.

An editorial on programming:

[QUOTE]In the CPU affinity question there are 3 options: 1-8=specific CPU, 99=any CPU, 100=smart assignment.[/QUOTE]Any coding scheme that uses numbers to denote two or more different [I]types[/I] (three: specific CPU #, option for any CPU, option for smart assignment, in this case) of meaning runs the risk of a future Y2K-like situation.

When the year 1999 seemed, in the 1950, 1960s, and 1970s to be so far in the future as not to need any consideration of when "99" would refer to the current year, the code "99" was used for all sorts of purposes other than denoting the year 1999. IBM specified a dataset expiration date field with the format "yyddd", where yy = last two digits of calendar year, and ddd = day of year, BUT it also specified that the [I]special value[/I] "99365" was to mean "never expires". That was fine until December 31, 1999, at which time every IBM data set with "99365" expired, whether it was intended to or not.

"99=any CPU, 100=smart assignment" is fine until we get computers with 99 or more CPUs, but then ...

This is also an example of a violation of one of my Laws of Programming: "A bit cannot serve two masters" (adapted from a Biblical parable). Since numeric "99" or "100" could conceivably denote an individual CPU number at some time, using nonnumeric codes for nonnumeric purposes is sounder programming. The strings "99" and "100" should denote something that is of the same basic type of entity as "9" or "10" -- a specific CPU number. Observing that Law of Programming of mine keeps a programmer from creating such problems. We're long past the days when space was cramped, and doubling up on meanings for a bit (or byte, or string) was excusable in the short run.

To denote "any CPU", use something like the character string "any" or "AC" or "anyCPU" or "ANYCPU" ... but not an all-numeric string!

For "smart assignment", use a nonnumeric string like "SA" or "smart" or something like that ... but not an all-numeric string!

[QUOTE=cheesehead;245003]To denote "any CPU", use something like the character string "any" or "AC" or "anyCPU" or "ANYCPU" ... but not an all-numeric string![/QUOTE]Alpha strings work well where feasible (as in an ini file). Occasionally you need to store a pseudo-value in a numeric-only field (e.g. a database), in which case you may be able to get nearly the same effect by designating certain negative values as magic values, such as -1=ANY; -2=SMART. CPU#-2 is (currently?) just as invalid as CPU#AC (which could potentially be confused with CPU#172 :wink:) and retains compatibility with a (signed) integer database field, without the issue of conflicting with actual values in a couple years when 128-core CPUs are running Prime95.