[QUOTE=SaneMur;280007]

Good news/bad news: The auto-tuned cutoffs are working well, without the need to research the initial "trial-and-error" range where there were still in the formative phase. The speedup averages 12.2x as fast for E60, 11.9x as fast for E66, but only 8.4x as fast for E58. No clue as to why.

I will move my code to a different development computer now, and rejoin running the executables. So far I am finding about 85 K's per day on E60 with the new algorithm and the faster computer. I don't know how long this trend will continue.[/QUOTE]

It might be worth switching off the smith_check when doing time trials. Effectively the check this is a brutal way to cut the field down further, but many potential candidates get lost that way. The smith_check normally used for E52 to E82 is normally the same, but actually each level has its own characteristics, as you say. Then you can see if your time trials still give spurious results.

Feel free to send me your found candidates, I have the master file of very prime k, with about 2,000 Riesels and 4,000 Sierpinskis.

[QUOTE=SaneMur;280007]
... but for some reason, the gmp.h file did not survive the port. I have no clue what happened to it!
[/QUOTE]

Note that gmp.h is part of the GMP library. It depends on the version of GMP actually installed on you system. If gmp.h is missing on you system, then most probably also the library itself is missing too.
Thus, it wouldn't make sense to place a specific gmp.h here.

Go to [URL="http://gmplib.org"]gmplib.org[/URL] to get the most recent version. Or, if you're running Windows, you may use [URL="http://mpir.org"]MPIR[/URL] instead.
For the latter, you'll need to modify the code to include "mpir.h" instead of "gmp.h".

[QUOTE=Thomas11;279802]
p0: 259.2 payam/sec
p3: 289.4 payam/sec
p4: 365.2 payam/sec
[/QUOTE]

Meanwhile I upgraded to Visual Studio 2010 and the MPIR 2.4.0 library, resulting in a 30% faster P4 binary (--> 477.2 payam/sec).

Please find it attached (named "payam_p4_240.exe" indicating the MPIR version).

UPDATE:
Somehow the whole machine seems to be faster now.
I did a quick check using the older version (payam_p4_mod.exe), which is running at 476.8 payam/sec now. Thus, no significant change in speed for the new version.
Windows Vista is quite a strange thing...

[QUOTE=Thomas11;280392]

UPDATE:
Somehow the whole machine seems to be faster now.
I did a quick check using the older version (payam_p4_mod.exe), which is running at 476.8 payam/sec now. Thus, no significant change in speed for the new version.
Windows Vista is quite a strange thing...[/QUOTE]

Thomas11 - did you run your test on the same range? It is critical to do this, because of variances in the amounts of candidates tested for primes at higher levels is highly variable, bu each constant range checks the same candidates to the same levels.

[QUOTE=robert44444uk;280522]Thomas11 - did you run your test on the same range? It is critical to do this, because of variances in the amounts of candidates tested for primes at higher levels is highly variable, bu each constant range checks the same candidates to the same levels.[/QUOTE]

Yes, I'm pretty sure that I used the same "in.txt" and "progress.txt" files (resetting the latter to start from iter=0, I=0 each time). Perhaps there was some system process in the background (e.g. the indexing process), when I did the first timings.

BTW.: I compiled the same source file on a 64 bit Linux machine and get a rate of 862.5 payam/sec. And this machine actually has a slightly slower cpu than the Windows machine (2.4 vs. 2.67 GHz). So, the 64 bit code is about twice as fast!

Unfortunately I only have the (free) "Express edition" of Visual C++, which doesn't provide a 64 bit compiler. Perhaps someone else (sanemur?) has a 64 bit C compiler on Windows...

Some records from this week:

Absolute:

24 52 82960601561481 R 52
57 389 83141430628207 R 52

Riesel:

53 338 83141430628207 R 52
54 359 83141430628207 R 52
55 374 83141430628207 R 52
56 388 83141430628207 R 52

My search for E268 will have to wait: I am not sure the software we have is the most efficient for this. After a couple of weeks I am at Iteration 675 with nary a candidate.

Also trying to find the largest very prime series through looking at E180. So far no dice. 98/10000 is the best so far.

I am going to have another bash at E162 as well,as the records there look out of sorts.

Might be worth trying mingw-64 for 64-bit windows compiles. Failing that if you can produce a visual studio 2005 solution I might be able to compile it for 64-bit. My uni has the full version of 2005.

Meanwhile I installed the full Windows SDK, which contains 64 bit compiler, linker, etc.
After some manual configuration I was able to generate a 64 bit binary (optimized for Core2 machines). Please find it attached.
Note, that you'll (most probably) need a 64 bit version of Windows (and a Core2 or better, of course).

I'm getting a rate of 672 payam/sec, which is almost a 50% speed up.
However, this is still far away from the 862 payam/sec for the 64 bit Linux binary...

UPDATE: After a little while (and after all system processes have settled) I tested the new binary again and it's now running at 805 payam/sec, coming close to the Linux version.

Please try it on your machine(s)!

[QUOTE=Thomas11;280665]Meanwhile I installed the full Windows SDK, which contains 64 bit compiler, linker, etc.
After some manual configuration I was able to generate a 64 bit binary (optimized for Core2 machines). Please find it attached.
Note, that you'll (most probably) need a 64 bit version of Windows (and a Core2 or better, of course).

I'm getting a rate of 672 payam/sec, which is almost a 50% speed up.
However, this is still far away from the 862 payam/sec for the 64 bit Linux binary...

UPDATE: After a little while (and after all system processes have settled) I tested the new binary again and it's now running at 805 payam/sec, coming close to the Linux version.

Please try it on your machine(s)![/QUOTE]

Oh no. I get a message saying "This version is not compatible with the version of windows you are running. Check you computer's system information to see whether you need an x-86 32 bit or x-64 64 bit version of the program...."

That is on my core duo running Vista Home Premium. Think I only have 32 bit capability.

Hmm, just found an E52 candidate that was only 91/6000, but went on to 125/20000. I think 34 primes in this range is something of a record. I will take it further to see what happens. Probably won't find any more!

At last: a decent Cunningham Chain, 1st kind

13 13 85029720714771 R 52

At 1.97*10^23 it falls outside the top 3 at this length, and is much larger than the smallest. So not archiveable. We need a similar performer at E60 or E66 to get this.

My other E52 candidate is now at 133/35000 and starting to break M52 records! That 42 primes between 6001 and 35000.