On Riesel E268 I managed 100 iterations in 2,046 seconds, or 3 a minute, and that is on my very old slow laptop so approximately 60 times faster

[QUOTE=Thomas11;293093]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).[/QUOTE]

Ok. I'll give it a 12 hour run, then I will check speed.

[QUOTE=pinhodecarlos;293090]I don't get as much as speed up as you get...[/QUOTE]

The speed-up depends on the E level. The new code gains speed at the higher E levels (e.g. E>=82), but may be of similar speed as the older one at lower E levels.

[QUOTE=robert44444uk;293094]On Riesel E268 I managed 100 iterations in 2,046 seconds...[/QUOTE]

On the Sierpinski side for E268 I've got 170 iterations in 1,018 seconds, which is due to 64 bits and probably also a higher clock speed.

On my test system (Core2 machine) the 64bit binary (Core2) is about 70% faster than the 32bit binary (P4). So you might consider an upgrade to 64 bits... :smile:

[QUOTE=Thomas11;293097]The speed-up depends on the E level. The new code gains speed at the higher E levels (e.g. E>=82), but may be of similar speed as the older one at lower E levels.[/QUOTE]

I am experience that.

The old code was running at 2304 subIteration per hour and the new code runs at 5715 subIteration per hour. I used the values of one core while the other three were also running. Because subIteration increased from 120960 to 217728 I only get a speed gain of 38%.
I'm using the 64-bit version.

After speed stabilization I got:

core 0 - from 427 payam/sec to 601 payam/sec
core 1 - from 424 payam/sec to 636 payam/sec
core 2 - from 468 payam/sec to 641 payam/sec
core 3 - from 474 payam/sec to 661 payam/sec

A World record for Afghanistan! The first E268 known.

R 3580685860863131 268 1/18 44/3000 K=11293462131474072432084161218594796622170910194557498554618585 iteration=1247 I=170180 Thu Mar 15 20:38:55 2012

Doing E268 was always like watching paint dry. I am just watching paint dry 60 times faster!

[QUOTE=robert44444uk;293107]A World record for Afghanistan! The first E268 known.
[/QUOTE]

Mr. Sierpinski came just a little too late:

S 2366134570006943 268 10/82 68/10000 K=7462774508206577586723646283413443004723568310610078922920005 iteration=824 I=159589 Thu Mar 15 16:58:23 2012

I wish I hadn't stopped the older client at iteration=800...

Nevertheless, big congrats to Robert!

My in.txt content is:

[code]maxn 10000
hashsize 65536
sievelimit 134217728
timesave 60
boundforquickcheck 4096
vpscount 100
nashsievelimit 500

c0 1.5
c1 5.0
nash_check 1
number_of_sievebits 7
11 64
13 128
15 256
18 512
21 1024
24 2048
27 4096

smith_check 1
number_of_levels 8
5 50
12 100
22 200
35 500
55 1000
67 2000
75 3000
91 6000
[/code]Can it be changed to increase client speed without penalize the results/search?

[QUOTE=pinhodecarlos;293114]My in.txt content is:

[code]
...

smith_check 1
number_of_levels 8
5 50
12 100
22 200
35 500
55 1000
67 2000
75 3000
91 6000
[/code]Can it be changed to increase client speed without penalize the results/search?[/QUOTE]

Well, in principle you could slightly adjust (raise) the levels of the Smith check.
But if you set them just a little too high, you may loose quite a few of your sequences.
And those levels also depend on the E value.

Actually I wouldn't suggest to touch any of those parameters at the current stage.
Once we've collected enough sequences and analyzed them, we can (will) do some statistics and carefully optimize those levels.

Your current E=66 runs will be a very useful source for this purpose.

(The current Smith check parameters are derived from E=58 data and should be valid also for E=52, 60, and 66).

[QUOTE=robert44444uk;293107]A World record for Afghanistan! The first E268 known.
[/QUOTE]

Mr. Sierpinski strikes again:

S 4156394079195633 268 1/2 60/10000 K=13109242463834549987260380771213679821898504223414228480434155 iteration=1448 I=151561 Thu Mar 15 18:06:13 2012

[QUOTE=pinhodecarlos;293114]My in.txt content is:

[code]
...

smith_check 1
number_of_levels 8
5 50
12 100
22 200
35 500
55 1000
67 2000
75 3000
91 6000
[/code]Can it be changed to increase client speed without penalize the results/search?[/QUOTE]

Just an additional note:

Of course you could add additional lines to the Smith check, e.g. something like:
[CODE]96 8000
99 9000[/CODE]
This will skip some of the sequences that wouldn't reach the target of 105+/10000.

Note that you also need to adjust the number of Smith check levels.