Some results while I was away on business:

1292 4600047853267882349
1220 4061783750035102601
1262 4602516665039101937
1320 4603114558016214631
1252 4604651964373376947

To note there was a second 1300 gap in the 4603-4604 namely

1302 4603184644444163329

I updated post 1 and 3 again

Completed 4071-4072

[code]
4071-4072e15 109 kgaps, largest 1238 @ 4071050619569958131
[/code]

reserving
[code]
4080-4081
4081-4082
[/code]

Luigi

Thank you Thomas for the linux binaries.

4470-4473 done.

[QUOTE=Thomas11;461193]

BTW.: I had a look into the intermediate assembler code as generated by the gcc compiler. It seems that apart from the bit scanning operations (ffs, clz), there is no real benefit from the additional capabilities of the newer cpus. Actually the AVX registers are only used once for the translation of the floating point input arguments (n1, n2) into integers.
So, perhaps, we could restrict ourselves to just one or two build targets, e.g. a generic one (Nehalem) and one for Haswell, which has the bit scanning operations.
At least we could skip the Ivybridge build, since it is (from the assembly side) identical to the Sandybridge.[/QUOTE]

Agree after my friend tested the client on more 2 systems E5 2695 V4 (72t) and E5 2695 V3 (56t). It confirms that the avx coding is not being fully utilized on the operations and the coding is not well parallelized. My laptop running 4 threads beats in energy efficiency his E5 2683 V4 @ 2.6G.

his 32.67e9 n/sec vs mine 18e9 n/sec

I suppose it's more efficient to run several instances of the client in parallel rather than with the -t flag.

Is there useful opportunity for avx usage? Should we be adding more asm? It is worth not using it when there is no speed benefit at that avoids the voltage increase(and hence extra power usage).

[QUOTE=pinhodecarlos;461223]Agree after my friend tested the client on more 2 systems E5 2695 V4 (72t) and E5 2695 V3 (56t). It confirms that the avx coding is not being fully utilized on the operations and the coding is not well parallelized. My laptop running 4 threads beats in energy efficiency his E5 2683 V4 @ 2.6G.

his 32.67e9 n/sec vs mine 18e9 n/sec

I suppose it's more efficient to run several instances of the client in parallel rather than with the -t flag.[/QUOTE]

From my observations on 8, 12, and 16 core Xeon systems it seems that the threads are having slightly different run times (presumably due to the calls to the prevprime/nextprime functions). The cpu waits until all threads are finished before the next cycle can be started.

If you have lots of memory in your Xeons it might indeed more efficient to run several instances with, lets say, 4 threads each.

[CODE]4082 4083 mart_r completed no 1248 4082641899811979303
[/CODE](There's something about this 1248 to me... is it because I set it as min gap now? :)

I'm feeling a bit more ambitious now and take 4690-4699.


[QUOTE=robert44444uk;461197]
Some results while I was away on business:

1292 4600047853267882349
[COLOR=Red][B]1220 4061783750035102601
[/B][/COLOR]1262 4602516665039101937
1320 4603114558016214631
1252 4604651964373376947[/QUOTE]

You might want to check this entry - it's the same for 4061 and 4601 in post # 3.

[QUOTE=Thomas11;461193]
BTW.: I had a look into the intermediate assembler code as generated by the gcc compiler. It seems that apart from the bit scanning operations (ffs, clz), there is no real benefit from the additional capabilities of the newer cpus. Actually the AVX registers are only used once for the translation of the floating point input arguments (n1, n2) into integers.
So, perhaps, we could restrict ourselves to just one or two build targets, e.g. a generic one (Nehalem) and one for Haswell, which has the bit scanning operations.
At least we could skip the Ivybridge build, since it is (from the assembly side) identical to the Sandybridge.[/QUOTE]
I just ran all 3 vesions my i5-3570k (ivybridge) is capable of on my testbed, and the results are identical within the measurement accuracy of the test:

Nehalem:...... 20.27e9 n/sec. 150 wall sec. 554.15 cpu sec. Thread Efficiency: 92.36%
Sandybridge: 20.27e9 n/sec. 149 wall sec. 553.51 cpu sec. Thread Efficiency: 92.29%
Ivybridge:...... 20.27e9 n/sec. 150 wall sec. 554.96 cpu sec. Thread Efficiency: 92.49%
Notes:
Test parameters: -n1 4248786e12 -n2 4248789e12 -gap 1250 -delta 150 -sb 24 -bs 16 -t 4 -mem 12.5
Thread Efficiency = (cpu sec.) / (threads * (wall sec.))

So it would seem that not only is AVX of no significant use, the compiler directives mtune and march have minimal/no effect either. It's the last two that are the most disappointing.

[QUOTE=mart_r;461236]

4061 4062 robert44444uk completed no 1220 4061783750035102601


You might want to check this entry - it's the same for 4061 and 4601 in post # 3.[/QUOTE]

Yes.

4601 4602 robert44444uk completed no 1220 4061783750035102601

[QUOTE=mart_r;461236][CODE]4082 4083 mart_r completed no 1248 4082641899811979303
[/CODE](There's something about this 1248 to me... is it because I set it as min gap now? :)

I'm feeling a bit more ambitious now and take 4690-4699.




You might want to check this entry - it's the same for 4061 and 4601 in post # 3.[/QUOTE]

Ahh, jet lag. I'm pleased someone is awake!

1202 4601694416273547617

4404-4416e15 completed:
[CODE]4404-4405e15 94 kgaps, largest 1240 @ 4404677506719658057
4405-4406e15 86 kgaps, largest 1194 @ 4405441151948626199
4406-4407e15 107 kgaps, largest 1220 @ 4406918130360849251
4407-4408e15 85 kgaps, largest 1226 @ 4407573986825334197
4408-4409e15 82 kgaps, largest 1206 @ 4408382343218114461
4409-4410e15 74 kgaps, largest 1216 @ 4409198449671554377
4410-4411e15 95 kgaps, largest 1236 @ 4410128630599679681
4411-4412e15 88 kgaps, largest 1150 @ 4411489680407675797
4412-4413e15 97 kgaps, largest 1182 @ 4412644078601061449
4413-4414e15 97 kgaps, largest 1178 @ 4413077442802942853
4414-4415e15 92 kgaps, largest 1218 @ 4414278965637610703
4415-4416e15 87 kgaps, largest 1186 @ 4415777808837014857
[/CODE]

Reserving 4430-4470e15.