And the Riesel E28 table - truly underdeveloped:

[CODE]
1 1 6191 R 28
2 2 137805 R 28
3 3 228483 R 28
4 4 874415 R 28
5 5 874415 R 28
6 6 2972625 R 28
7 7 98776429 R 28
8 8 72167913 R 28
9 9 688241231 R 28
10 10 7915539463 R 28
11 12 709602395 R 28
12 13 709602395 R 28
13 15 7482142653 R 28
14 17 39984233659 R 28
15 18 39984233659 R 28
16 19 39984233659 R 28
17 23 3428771 R 28
18 28 1159606077 R 28
19 33 17427384519 R 28
20 42 26803514639 R 28
21 45 11498712013 R 28
22 49 199281 R 28
23 54 199281 R 28
24 60 46909222367 R 28
25 66 46909222367 R 28
26 73 46909222367 R 28
27 76 19235069 R 28
28 81 19235069 R 28
29 88 11889667797 R 28
30 90 11889667797 R 28
31 101 11889667797 R 28
32 109 19235069 R 28
33 110 19235069 R 28
34 112 19235069 R 28
35 125 19235069 R 28
36 132 19235069 R 28
37 135 19235069 R 28
38 137 19235069 R 28
39 142 19235069 R 28
40 151 19235069 R 28
41 160 19235069 R 28
42 174 19235069 R 28
43 191 19235069 R 28
44 225 19235069 R 28
45 227 19235069 R 28
46 259 19235069 R 28
47 313 19235069 R 28
48 326 19235069 R 28
49 374 33575827 R 28
50 406 33575827 R 28
51 454 19235069 R 28
52 461 33575827 R 28
53 501 8316321 R 28
54 503 8316321 R 28
55 517 8316321 R 28
56 552 8316321 R 28
57 554 8316321 R 28
58 597 8316321 R 28
59 628 8316321 R 28
60 635 8316321 R 28
61 738 46613551 R 28
62 780 46613551 R 28
63 807 46613551 R 28
64 839 46613551 R 28
65 907 46613551 R 28
66 991 8316321 R 28
67 1052 8316321 R 28
68 1245 8316321 R 28
69 1373 8316321 R 28
70 1491 8316321 R 28
71 1537 46613551 R 28
72 1594 8316321 R 28
73 1669 8316321 R 28
74 1735 8316321 R 28
75 1746 8316321 R 28
76 2410 46613551 R 28
77 2482 8316321 R 28
78 2817 34794485 R 28


[/CODE]

[QUOTE=robert44444uk;293058]

I would like to reserve Riesel E36 iteration 10...I'm assuming that Carlos is already looking at some iterations, hopefully this won't be an overlap.

[/QUOTE]

No, I am not running Riesel E36.

[QUOTE=robert44444uk;293064]A couple of pointers for the programming:

On both my computers I got the error message msvcr100.dll missing. I solved it on my vista by copying and renaming msvcr100_clr0400.dll to the required name.

On my older machine I have a variety of msvcr files, but they are only numbered up to 90.[/QUOTE]

Thanks for pointing this out. I wasn't aware of this problem.
Please test the version attached. It should only depend on msvcr90.dll.

I have been corresponding off-forum with Thomas11 on what to do about higher E.

There is a huge gap between E226 and E268 as there are many additional primes that have to be considered in the CR. There are 20 primes smaller than 10,000 with modulos between E226 and E268.

So unsurprisingly, we have found no Riesel or Sierpinski E268 despite running hundreds of cycles on each side.

Perhaps the quickest way to generate E268 would use the formula y=z*269#/2, where 269# is the primorial, z an integer variable. It is certainly not as elegant as the traditional way of generating Payam numbers, as key primes such as 7, 17, 23 etc are eliminated in the primorial rather than the CRT.

Then all you would have to do is to run a CR on integers z, to eliminate all 10000>p>269 (say) where their modular order base 2 is <269 - call these "Q1" primes. Candidates falling out here would then be tested for Q2 primes where p>10000. It should be possible to generate E268s as fast as we generate E100s I think, using this method.

Alternatively, we could adopt a concept I have used before of slightly deficient primorials, in this way, the efficiency of the eventual k are increased. Here the base form for which z would be subject to the CRT would be y=z*269#/(2*7*17*23...w), where w depends on how far you want to make the primorial deficient. The 7,17,23...w are instead loaded into the CR calculation, alongside the Q1 primes. The eventual k are 7, 119, 2737... times smaller than their primorial counterparts, and should be therefore more prime on average.

If we can generate, say, 20 to 30 E268 a second using this, then we can perhaps use the part of Robert G's software that does the prime checking, with Smith checks to take out the hopeless cases.

This approach would also allow us to look at much higher E

Grateful for views on how feasible this all is to program and if there are any volunteers.

[QUOTE=robert44444uk;293074]

Perhaps the quickest way to generate E268 would use the formula y=z*269#/2, where 269# is the primorial, z an integer variable. It is certainly not as elegant as the traditional way of generating Payam numbers, as key primes such as 7, 17, 23 etc are eliminated in the primorial rather than the CRT.
....


Alternatively, we could adopt a concept I have used before of slightly deficient primorials, in this way, the efficiency of the eventual k are increased. Here the base form for which z would be subject to the CRT would be y=z*269#/(2*7*17*23...w), where w depends on how far you want to make the primorial deficient. The 7,17,23...w are instead loaded into the CR calculation, alongside the Q1 primes. The eventual k are 7, 119, 2737... times smaller than their primorial counterparts, and should be therefore more prime on average.

[/QUOTE]

A little more thinking about using deficient primorials versus primorials.

There is a tradeoff of complexity, every time a prime is used in the CR the complexity increases and the candidate numbers will be harder to find. If primes are to be taken out of the primorial then they should have low modulo base 2 compared to their p value, as the complexity (I think) in the CR increases if the modulo value is high.

If this is the case, then the primes to remove from the primorial would be in the following order:

[CODE]
p modulo
127 7
257 16
151 15
241 24
73 9
89 11
233 29
31 5
223 37
251 50
113 28

[/CODE]

Removing the first 4 provides for E268 which are a billion times smaller than their primorial counterparts, while using all provides at 10^23 pickup.

[QUOTE=Thomas11;293073]Thanks for pointing this out. I wasn't aware of this problem.
Please test the version attached. It should only depend on msvcr90.dll.[/QUOTE]

This works, thank you!

I'm currently running some tests on E=226 (Sierpinski side).

The speed-up after just a few iterations is just exciting:

For the older code (payam.c) I've got about 5 iterations per hour.
But the new code (payam2.c) yields 2 iterations [B]per minute[/B]!

[QUOTE=Thomas11;293086]I'm currently running some tests on E=226 (Sierpinski side).

The speed-up after just a few iterations is just exciting:

For the older code (payam.c) I've got about 5 iterations per hour.
But the new code (payam2.c) yields 2 iterations [B]per minute[/B]![/QUOTE]

For E=66 Riesel side, and after 12 hours of testing, the new code is about 1.38 times faster than the old one.
Thank you Robert G for the new code and Thomas for the binaries!!

Confirmed, amazing pickup as well on the Riesel E226 side.

Did a couple of hours of E28 and E36 just to test it out. 1 absolute record (Sierpinski or Riesel) found in just that amount of time

15 17 29958874375317 R 28

But I will now move to E226 and E268 on two cores.

Thomas,

The latest 64-bit version binary is optimized for Core2 or for Nehalem" cpu architecture?

Carlos

EDIT: My question follows the comparison speed I made. I don't get as much as speed up as you get probably because I am comparing two different optimized clients. I was running the old code using the Nehalem binary...and I suppose the new binary is core2 based.

[QUOTE=pinhodecarlos;293090]
The latest 64-bit version binary is optimized for Core2 or for Nehalem" cpu architecture?[/QUOTE]

The binaries were optimized for Core2 (64 bits) and P4 (32 bits).

A "Nehalem" version is attached, but note that I don't have a Nehalem machine here for testing...

It would be nice if you could do some comparative test of the Core2 and Nehalem binaries, e.g. using the same input files (just a few sub-iterations).