Thomas 11 - tested on my machine and works well.

Would help if the file is called something like payamthomas11 or something like that, so as not to mix up with axn's software of the same name.

1. The next stage is to create the record table file to carry the best at all E levels, for both S and R, so that all information is kept in the same file.

2. The stage after that is 100 best file at each p and E level. The logic here is to create a simple database with fields as in the recordtable file... p:n:y:R/S:E, but with additional (optional) fields:

position within p:R/S:E up to 100 from lowest n upwards to the 100th place
time/ date
machine core ref/ finder

the file would have approx 48,000 records, 120(p)*2(R/S)*20(E)*100

3. the stage after that is to create a separate dos program with the merging capability that takes two recordtable files and just keeps the best 100 n at each p:R/S:E

The reason for my madness here is that it would set the ground for a automating record keeping if we made this a distributed project as well as attributing records.

The routines could be kept for incorporation into Sanemur's program when it is done.

[QUOTE=robert44444uk;279783]Thomas 11 - tested on my machine and works well.[/QUOTE]

Please do some timings and compare to the original version.
BTW.: axn's software is even older (called payamx.exe), you are refering to Robert Gerbicz's program...

The MPIR library comes with multiple build targets (optimized for P3 or P4 machines). So far I used a generic one which should run on any kind of Intel or AMD machines (even a 486).
If you tell me your cpu type(s), I could try to build one specific for you hardware.

Regarding the "next stages":
I already made Perl scripts for most of the topics you mentioned, e.g. merging two or multiple recordtables and the like.
In my opinion (and for our purposes) scripts are much easier to handle and to modify. But this would require to install Perl on your Windows machines.

[QUOTE=Thomas11;279789]In my opinion (and for our purposes) scripts are much easier to handle and to modify. But this would require to install Perl on your Windows machines.[/QUOTE]

For such requirements I use awk for WIN: gawk.exe is only 350kB in size and nothing to install.

[QUOTE=kar_bon;279792]For such requirements I use awk for WIN: gawk.exe is only 350kB in size and nothing to install.[/QUOTE]

Thanks for this hint! I will give it a try. Shouldn't be a major undertaking to convert from Perl to awk.

[QUOTE=Thomas11;279789]Please do some timings and compare to the original version.
BTW.: axn's software is even older (called payamx.exe), you are refering to Robert Gerbicz's program...

The MPIR library comes with multiple build targets (optimized for P3 or P4 machines). So far I used a generic one which should run on any kind of Intel or AMD machines (even a 486).


[/QUOTE]

[B]Program Name[/B]
Robert G's programs are called payamathlon and payampentium, Axn's were called payam, payamx, and payambase I think. Anyway, would still help to have a new name!!!

[B]Performance[/B]
Running on a laptop pentium chip (I think) - this is an HP ACPI x86-base PC

E60, Riesel stating from iteration =0, i=0

payam.exe
134 sec to get to i=85, 64214 payams checked (no star performer checked)
604 sec to get to i=102, 76956 checked (1 star performer checked)

payampentium.exe
129 sec to get to i=86, 64969 payams checked
549 sec to get to i=101, 76185 checked

So a slight deterioration of performance.

[B]Recordtable when E changes[/B]

I looked again at the recordtable when I changed E value, and noticed that at present it does not update the E value in the recordtable, i.e. you need to save the record file for that E level with a different name, if you want to collect records on the new E level.

Here is what I did:
[LIST][*]Ran E52 from iteration=0,i=0 to 0,50 changed name of recordtable to recordtable52 (i'e' no recordtable.txt carrid forward[*]ran E60 from 0,0 to 0,110 and copied that recordtable to recordtable60, but keeping recordtable.txt (recordtable hence has only E60 values)[*]Ran E52 to 0,0 to 0,50 again[/LIST]
There are problems with the overwritten file. Here the correct y and n is kept, but the E value is unchanged. For example the best to 13 primes:

13 28 1625513295369 R 60 from run 2
13 24 1861999421785 R 52 from run 1

But the spurious

13 24 1861999421785 R 60 from run 3

Oh, you're right. Since I never used the Robert Gerbicz's Windows binaries, I wasn't aware of their names. The C code was just "payam.c".

Please note that this is still Robert Gerbicz's code. I just modified the "recordtable" stuff. Therefore I wouldn't use a different name for it.
But you're free to rename the binaries at your discretion.

I created two new binaries -- payam_p3.exe and payam_p4.exe -- using the "p3" and "p4" optimized MPIR libraries (the former one was for "p0"). Actually I don't really know what they mean by "p3" and "p4". But I assume that it stands for Pentium3 and PentiumIV.

Here are some timings I got for the new binaries (for E=60):

p0: 259.2 payam/sec
p3: 289.4 payam/sec
p4: 365.2 payam/sec

So, the p3 and p4 versions are about 10% or 30% percent faster than the "p0" version you already have. However, the timings are for a Core2 machine. The relative timings may be different on yours.

Please try if you get them running on your machine(s).

I'm attaching the p4 variant in a separate post (both together are to large)...

And here comes the "p4" binary.

[QUOTE=robert44444uk;279795]
There are problems with the overwritten file. Here the correct y and n is kept, but the E value is unchanged. For example the best to 13 primes:

13 28 1625513295369 R 60 from run 2
13 24 1861999421785 R 52 from run 1

But the spurious

13 24 1861999421785 R 60 from run 3[/QUOTE]

This is to be expected, since the program assumes that the existing recordtable.txt and the progress.txt share the same E level.
Keeping recordtables for all possible E levels would require some major rewriting of the code (which I still not fully understand). In my opinion it is much easier to manage the recordtables outside the cruncher program, e.g. with some scripts (as I did for the Sierpinski side).

Thus, in short: you should not mix different E levels.
Simply use individual directories for each E level.

Perhaps I should add some abort option for the case that the recordtable file uses a different E than the progress file...

[QUOTE=Thomas11;279802]

So, the p3 and p4 versions are about 10% or 30% percent faster than the "p0" version you already have. However, the timings are for a Core2 machine. The relative timings may be different on yours.

Please try if you get them running on your machine(s).

[/QUOTE]

On the same laptop as before:

E60, Riesel stating from iteration =0, i=0

payam.exe
134 sec to get to i=85, 64214 payams checked (no star performer checked)
604 sec to get to i=102, 76956 checked (1 star performer checked)

payampentium.exe
129 sec to get to i=86, 64969 checked
549 sec to get to i=101, 76185 checked

payam_p4
104 sec to get to i=87, 65731 checked
527 sec to get to i=105, 79190 checked

Great, got a good pick up there! Found out I have a core duo chip on this machine.

I changed the recordtable code a bit:
To avoid confusion or data file corruption the program will now use file names like "recordtable_S60.txt" or "recordtable_R148.txt".

The new P4 binary is build using version 2.2.1 of the MPIR library (the former binaries used the outdated version 1.3.1). 2.2.1 is still not the latest version, but the newer ones only support Visual C++ 2010 (I still have only 2008 here).

So far I haven't noticed any differences in speed between the 2.2.1 and 1.3.1 variants.

Since you have a dual core machine, you should also check the behavior of your system when running two instances of the program. My quad core machine felt a bit sluggish using 4 instances of Robert Gerbicz's binaries.

Let me know if there is some need for a P3 (maybe for Athlon machines) and/or a generic (p0) binary anymore.

Well that will teach me for staying away for a few days!
 

Wow, looks like a lot going on here. Now we are running into "version control" issues potentially. I'm sure we'll be able to sort it out.

I wrote a "record sorting" macro in Excel which can merge the previously_existing_version of the Record Tables and produce the new, integrated record. Let me know if any of you would like to adopt it, or just forego it since this has been replaced by some of the newer code.

As for optimizations: I moved the code onto my faster 5.0 GHz i7-980X this weekend, but for some reason, the gmp.h file did not survive the port. I have no clue what happened to it! Ugh! So, I will need a new one to conitnue to move this project forward. If anyone has a copy, feel free to post it for downloading.

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. And the bad news: Every exponent has its own "formative stage learning curve," so there is no way to predict when this part is complete. It takes 4 hours on my machine for E60, so the 12.2x payoff is worth it. But, it takes 22 hours to complete for E58, and the 8.4x payoff is not as good. I don't have a clear understanding of why this is so. Obviously, I need to tune the algorithm a little tighter and create a logging mechanism to see what is going on on the inside while it is percolating.

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.