This one did about half on the previous .04, and the second half after I switched apps - so no useful timing, but it validated OK and got granted credit.
It seems, this version is about 2 min. faster on my X2 with longer WUs:
z1_1196.5__1041_S4R2a_0: 2872.46875 sec with S40.04
z1_1196.5__1040_S4R2a_0: 2875.625 sec with S40.04
z1_1196.5__1039_S4R2a_0: 2872.640625 with S40.04
z1_1196.5__1034_S4R2a_1: 2869.46875 with S40.04
z1_1196.5__1254_S4R2a_3: 2873.71875 with S40.04
z1_1196.5__1033_S4R2a_0: 2813.78125 with S40.04/S40.12
z1_1196.5__1032_S4R2a_0: 2800.984375 with S40.04/S40.12
z1_1196.5__1031_S4R2a_0: 2749.703125 with S40.12
z1_1196.5__1030_S4R2a_0: 2753.90625 with S40.12
z1_1196.5__1029_S4R2a_0: 2750.671875 with S40.12
z1_1196.5__1028_S4R2a_0: 2753.421875 with S40.12
I've recognized, that the time to calculate WUs out of the same series might change at a sudden point, but the chance this has happened exactly when I changed the app is pretty improbable.
Wasn’t 40.12 supposed to be slower? First result with 40.12 is the fastest I have seen on this machine ever. 17seconsd faster and it will break the 4000seconds barrier. And I thought that the people over at LHC would create the first artificial black hole, but I suspect that they are going to be beaten to it by one of akosf’s hosts, then its crunch time goes towards cero and implodes. :)
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
I did not do a controlled rerun, but the first five results returned running S40.12 on my Gallatin (Northwood-descended P4 EE 8k L1, 512k L2, 2M L3 cache) are definitely slower than most recent results from the same two major datafiles.
Maybe this one is faster/slower based on processor, or maybe those of us not grabbing a trial sample and running it twice are fooling ourselves. I must say Ziegenmelker's case looks pretty persuasive because of the low noise in his before/after results.
S40.12 Observation thread
)
Ok first result thru.
http://einsteinathome.org/task/25862848
Akofs it seems to be the same ver. number (S40.04)on this exe.
Anders n
My result 25633836 shows
)
My result 25633836 shows S40.12 as expected.
This one did about half on the previous .04, and the second half after I switched apps - so no useful timing, but it validated OK and got granted credit.
So I downloaded the file
)
So I downloaded the file again and now it is the right one.
http://einsteinathome.org/task/25844876
First result fine . Crunch time about the same as S40.04
Anders n
RE: Akofs it seems to be
)
My initial partially processed result has the expected entry:
2006-04-20 12:56:23.1718 [normal]: Optimised by akosf S40.12 --> 'projects/einstein.phys.uwm.edu/albert_4.37_windows_intelx86.exe'
Dramatic increase in speed on
)
Dramatic increase in speed on my AMD 3500+ machine:
On the longer workunits, about a 17% increase versus S40.04.
Akofs is the guru of optimization! :)
It seems, this version is
)
It seems, this version is about 2 min. faster on my X2 with longer WUs:
z1_1196.5__1041_S4R2a_0: 2872.46875 sec with S40.04
z1_1196.5__1040_S4R2a_0: 2875.625 sec with S40.04
z1_1196.5__1039_S4R2a_0: 2872.640625 with S40.04
z1_1196.5__1034_S4R2a_1: 2869.46875 with S40.04
z1_1196.5__1254_S4R2a_3: 2873.71875 with S40.04
z1_1196.5__1033_S4R2a_0: 2813.78125 with S40.04/S40.12
z1_1196.5__1032_S4R2a_0: 2800.984375 with S40.04/S40.12
z1_1196.5__1031_S4R2a_0: 2749.703125 with S40.12
z1_1196.5__1030_S4R2a_0: 2753.90625 with S40.12
z1_1196.5__1029_S4R2a_0: 2750.671875 with S40.12
z1_1196.5__1028_S4R2a_0: 2753.421875 with S40.12
I've recognized, that the time to calculate WUs out of the same series might change at a sudden point, but the chance this has happened exactly when I changed the app is pretty improbable.
Wasn’t 40.12 supposed to be
)
Wasn’t 40.12 supposed to be slower? First result with 40.12 is the fastest I have seen on this machine ever. 17seconsd faster and it will break the 4000seconds barrier. And I thought that the people over at LHC would create the first artificial black hole, but I suspect that they are going to be beaten to it by one of akosf’s hosts, then its crunch time goes towards cero and implodes. :)
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
Started with s40.04 ended
)
Started with s40.04 ended with s40.12 sucessful
5.2.13
2006-04-20 23:57:42.8906 [normal]: Optimised by akosf S40.04 --> 'projects/einstein.phys.uwm.edu/albert_4.37_windows_intelx86.exe'
2006-04-20 23:57:42.8906 [normal]: Started search at lalDebugLevel = 0
2006-04-20 23:57:44.2187 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-04-20 23:57:44.2187 [normal]: No usable checkpoint found, starting from beginning.
2006-04-21 00:27:06.1406 [normal]: Optimised by akosf S40.04 --> 'projects/einstein.phys.uwm.edu/albert_4.37_windows_intelx86.exe'
2006-04-21 00:27:06.1562 [normal]: Started search at lalDebugLevel = 0
2006-04-21 00:27:07.6250 [normal]: Found checkpoint-file 'Fstat.out.ckp'
2006-04-21 00:27:07.6250 [normal]: Trying to read Fstat-file into toplist ...
2006-04-21 00:27:16.2656 [normal]: Checksum Ok. Successfully read_toplist_from_fp()
2006-04-21 00:27:16.2656 [normal]: Resuming computation at (835/218308371/4396566).
2006-04-21 00:29:23.7343 [normal]: Fstat file reached MaxFileSizeKB ==> compactifying ... done.
2006-04-21 01:33:12.1718 [normal]: Optimised by akosf S40.12 --> 'projects/einstein.phys.uwm.edu/albert_4.37_windows_intelx86.exe'
2006-04-21 01:33:12.1718 [normal]: Started search at lalDebugLevel = 0
2006-04-21 01:33:14.0312 [normal]: Found checkpoint-file 'Fstat.out.ckp'
2006-04-21 01:33:14.0312 [normal]: Trying to read Fstat-file into toplist ...
2006-04-21 01:33:19.1250 [normal]: Checksum Ok. Successfully read_toplist_from_fp()
2006-04-21 01:33:19.1250 [normal]: Resuming computation at (65102/143452553/2886824).
2006-04-21 01:56:51.4531 [normal]: Search finished successfully.
thx akosf
seti_britta (-:
RE: Wasn’t 40.12 supposed
)
I did not do a controlled rerun, but the first five results returned running S40.12 on my Gallatin (Northwood-descended P4 EE 8k L1, 512k L2, 2M L3 cache) are definitely slower than most recent results from the same two major datafiles.
Maybe this one is faster/slower based on processor, or maybe those of us not grabbing a trial sample and running it twice are fooling ourselves. I must say Ziegenmelker's case looks pretty persuasive because of the low noise in his before/after results.
I wonder if the zero credit
)
I wonder if the zero credit errors are processor specific? I haven't had a single error on my Prescott on the S39's, or the S40.x
me-[at]-rescam.org