Piddling Around With Big Compute Power

[jasonp]

Don't ask for 32 threads out of Msieve. I would limit it to 2-3 threads per physical package on the machine you are using.

[NBtarheel_33]

Originally Posted by Prime95

Fixed in 27.9. All earlier v27s had the bug. You are correct in that it does not damage the result.

The LL in question just finished. It has an error code of 08004400, which is 68 of those huge roundoff errors, and mprime catching its breath eight times long enough to say "hey, this isn't a hardware problem". Should I submit this result as a "Suspect LL" or should I send results.txt to you, so the error code can be adjusted?

[NBtarheel_33]

Originally Posted by bcp19

I don't know about mprime that much, but I doubt your best performance is using the entire CPU on a single exponent. Run a benchmark and see the iteration times for 1/2/3/4/5/6/7/8. On mine at 3072k FFT (which is around the 50M exp) I get 16.680 for 1, 8.987 for 2, 6.541 for 3 and 5.842 for all 4. This means with 2 shared cores I only get 92% of those 2 separate, and it drops to 85% with 3 and 71% with all 4.

I definitely understand that this is usually the case. But for some reason, and it may be related to my still not fully understanding how Linux pairs physical cores and logical "helper" hyperthreads, I get weird timings, e.g. for 50M exponents:

• 1 worker on 16 threads = 2.6 ms/iteration (130K sec/exponent), with fluctuations as low as 2.0 ms/iteration and as high as 3.2 ms/iteration.
• 2 workers, each 8 threads = 5.1 ms/iteration on one exponent and 3.9 ms/iteration on the other (average of 225K sec/exponent).
• 4 workers, each 4 threads = 9.4 ms/iteration on two exponents and 17.2 ms/iteration on the other two (average of 665K sec/exponent).
• 8 workers, each 2 threads = 19.5 ms/iteration on four exponents and 37.8 ms/iteration on the other four (average of 1.43M sec/exponent).
• 16 workers, each 1 thread = 30-40 ms/iteration on eight exponents and 80-90 ms/iteration on the other eight, subject to volatile fluctuation (average of 2.75M - 3.25M sec/exponent).

After extensive testing and direction of expletives at the cryptic information provided by top and /proc/cpuinfo, I found that 8 cores/16 hyperthreads for each test seemed the most efficient, offering the most stable iteration times. I can't complain about finishing an LL test on a 50M exponent in 2-1/2 days, after all.

I am curious as to what might be happening to cause the differential in iteration times between one set of eight cores and the other set of eight cores, though. As I said above, I agree 100% in all of my other experience, that maximal throughput is achieved by running one number on each core. But not so much in this case...

Would it perhaps be better to run two copies of mprime, one on each CPU? Does mprime play nicely with multi-socket (as opposed to multi-core) systems?

[bcp19]

Originally Posted by NBtarheel_33

I definitely understand that this is usually the case. But for some reason, and it may be related to my still not fully understanding how Linux pairs physical cores and logical "helper" hyperthreads, I get weird timings, e.g. for 50M exponents:

• 1 worker on 16 threads = 2.6 ms/iteration (130K sec/exponent), with fluctuations as low as 2.0 ms/iteration and as high as 3.2 ms/iteration.
• 2 workers, each 8 threads = 5.1 ms/iteration on one exponent and 3.9 ms/iteration on the other (average of 225K sec/exponent).
• 4 workers, each 4 threads = 9.4 ms/iteration on two exponents and 17.2 ms/iteration on the other two (average of 665K sec/exponent).
• 8 workers, each 2 threads = 19.5 ms/iteration on four exponents and 37.8 ms/iteration on the other four (average of 1.43M sec/exponent).
• 16 workers, each 1 thread = 30-40 ms/iteration on eight exponents and 80-90 ms/iteration on the other eight, subject to volatile fluctuation (average of 2.75M - 3.25M sec/exponent).

After extensive testing and direction of expletives at the cryptic information provided by top and /proc/cpuinfo, I found that 8 cores/16 hyperthreads for each test seemed the most efficient, offering the most stable iteration times. I can't complain about finishing an LL test on a 50M exponent in 2-1/2 days, after all.

I am curious as to what might be happening to cause the differential in iteration times between one set of eight cores and the other set of eight cores, though. As I said above, I agree 100% in all of my other experience, that maximal throughput is achieved by running one number on each core. But not so much in this case...

Would it perhaps be better to run two copies of mprime, one on each CPU? Does mprime play nicely with multi-socket (as opposed to multi-core) systems?

My first thought is you are running a hyperthreaded setup. My second thought is you are running 2 different CPUs on the board.

George's programs is so efficient that H/T can actually slow it down. Case in point: I have a 4 physical core laptop with H/T. These are the timings I get running ECM:
1 worker 1 core (affinity Logical cpu 1) = 774sec avg
1 worker 2 core (affinity Logical cpu 1,2)= 785 sec avg
1 worker 4 cores (affinity Logical cpu 1,2,3,4= 540 sec avg
If I 'trick' the program by setting affinity to CPU 2, I get:
1 worker 2 cores (affinity logical cpu 2,3 [physical cores 1,2]) = 502 sec. avg

As you can see, using both logical cores on a physical core is slower than using 1 in both instances.

To truly see how your system works, I would start by setting it to run 16 workers on 1 core each. Then start 1 core and record timings, start a second core and record timings, continue untill you have all 16 running OR you see a significant slowdown in timings.

My 2500 (it's not H/T) cannot run all 4 cores as efficiently as 3 due to a bottleneck somewhere, likely in memory bandwidth. 1 worker running = ~16.2ms/iter, 2 = ~16.4 avg, 3 = 17.2 avg, 4= 21.3 avg.

Time to complete the equiv of 1 exponent:
~9.9 days on 1 core
~5.0 days on 2 cores
~3.4 days on 3 cores
~3.2 days on 4 cores

[Prime95]

Originally Posted by NBtarheel_33

The LL in question just finished. It has an error code of 08004400, which is 68 of those huge roundoff errors, and mprime catching its breath eight times long enough to say "hey, this isn't a hardware problem". Should I submit this result as a "Suspect LL" or should I send results.txt to you, so the error code can be adjusted?

Submit the result "as is". Someone will do an early double-check.

[NBtarheel_33]

Another nice P-1, but no factor...

M93111047 completed P-1, B1=1080000, B2=33210000, E=12

Takes about 4 hours for Stage 1 and 8 hours for Stage 2, running on 8 cores/16 threads and 30GB RAM. Anyone ever seen a higher E? This is the third time I've had E=12...

[NBtarheel_33]

Originally Posted by Prime95

Submit the result "as is". Someone will do an early double-check.

Done. The exponent is 50098369, if anyone's interested...


Never mind, it's been assigned already! It's only been factored to 72, actually, so perhaps the GPUto7x folk will have a go at it. Incidentally, George, you factored it to 64 way back in 2008 (so let me say that it's an honor to have collaborated with you, sir ).

In other happenings, this post is my nth, where n is the Number of the Beast...(say, wasn't there a devilish smiley at one time?)

[xilman]

Originally Posted by NBtarheel_33

In other happenings, this post is my nth, where n is the Number of the Beast...(say, wasn't there a devilish smiley at one time?)

Like this you mean?

[Xyzzy]

This is the third time I've had E=12...

Almost all of our recent P-1 work has "E=12" because we give P-1 8GiB of memory. It is strange that every once in a while we get an "E=6" even though the memory allocated doesn't change.

UID: Xyzzy/i7, M61192819 completed P-1, B1=580000, B2=11890000, E=12, We4: ××××××××
UID: Xyzzy/i7, M61478429 completed P-1, B1=585000, B2=11992500, E=6, We4: ××××××××
UID: Xyzzy/i7, M60505889 completed P-1, B1=570000, B2=11685000, E=12, We4: ××××××××

[c10ck3r]

Xyzzy- could that be because of the size of the exponent? I noticed that only the largest one had a reduced E-value.

[NBtarheel_33]

Originally Posted by c10ck3r

Xyzzy- could that be because of the size of the exponent? I noticed that only the largest one had a reduced E-value.

Yeah, perhaps that's a breakpoint in the 61M range, between 8GB being strong enough to support E=12 vs. E=6. Maybe try another P-1 in the high 61M range with 12-16GB of RAM and see what happens.