EDIT : what is the best way to verify the outputs are correct when testing an app with the ref WU ?
I did some "file compare" with ought.out for example, but is seems it's timestamped so a direct ASCII/HEX/BIN compare will not help.
I tried with other files as well, but this led nowhere...
Is there a better way than just verify there's no errors in stderr.txt ?
Hmm... there's something strange here... The output in stderr.txt is NOT consistent with a 4.24 Linux app., which was released in January 2008, yet the stderr.txt contains this line:
2008-05-26 19:12:29.8275 [normal]: Built at: Feb 21 2008 15:57:05
Hmm... there's something strange here... The output in stderr.txt is NOT consistent with a 4.24 Linux app., which was released in January 2008, yet the stderr.txt contains this line:
2008-05-26 19:12:29.8275 [normal]: Built at: Feb 21 2008 15:57:05
CU
Bikeman
HeHe, well done ;)
The app was 4.35 according built date and running time.
Makes it all clearer now :D
In order to find other versions that ones on the EAH download repository, i looked a bit everywhere, including P2P networks... Maybe that's it.
Should have double checked the name according to the build date.
Thanks for the tip, will know from now.
The run time is now matching well.
Will update the plot later today.
Cheers,
A lame Alex.
God created a few good looking guys.. and for the rest he put hairs on top..
- With 4.07, I had very constant results.
4 runs within the same 4-5 sec in high priority.
But i felt it was a bit too slow compare to 4.01 (even if its not surprising 4.07 being a bit slower than 4.01)
So i made another batch of runs. Again, very same results for each run.
But, not matching the first batch results ! Not by much, around 5%.
Still confusing anyway, as I changed nothing in the testing protocol, the app exe is the same...
- With 4.49_0 (the not SSE one).
The result was surprisingly fast from the beginning. Something felt wrong.
So again, I went for another run yesterday.
As for the windows 4.07, same file, same protocol (no background BOINC, high priority, no many stuffs in memory, leave the OS alone during test... )
And now the results feel a lot more right. Non-SSE is now a lot slower than 4.49 SSE or SSE2 as it should be.
Again, results from each test run are really close to each other from the same batch.
For all the other apps i re-ran yesterday, new results match well the previous ones.
So no really answers here, just open questions.
At least, now the results seem pretty consistent.
Datas:
Graph:
Graph with logarithmic runtime-axis:
Well, we'll see if others running ref WU, will have the same experience.
Sorry for the mislead on these 3 apps results (4.07, 4.24, 4.49_0) in my initial post.
Cheers,
Alex.
God created a few good looking guys.. and for the rest he put hairs on top..
So, as expected, no changes in crunch time with S5R4 apps:
Really slight variations only, if any.
Even if i ran the WU more than once for each app and "average", there is still little glitches in measurements. That should explain the slight variations you might see.
Maybe not for Linux 6.02 SSE one, witch appears to be 3% faster, a little more than the common error between to runs with a same app.
Maybe a slight change in compilers options, or something else... or nothing :D
BernD will probably tell you more on this if there's anything to say.
Cheers,
Alex.
God created a few good looking guys.. and for the rest he put hairs on top..
And yet, having just reported my first S5R4 result with host 889490, the real-world WU timing is much longer than S5R3.
I'm comparing Windows 4.36 on Intel (between 23 and 25.5 Ksec) with 6.04 - which should be a functionally equivalent Einstein app, but registered over 48 Ksec.
It strikes me that with the DCF re-adjustment, fast hosts will over-cache when they first latch on to S5R4, but will then go quiet as soon as they return their first task and find out what they've let themselves in for. But the initial loading is likely to be nice and consecutive, as this one was.
Anyone like me to try for a 'wiggle and swoop' run with one of my standard quaddies, like we did last time?
And yet, having just reported my first S5R4 result with host 889490, the real-world WU timing is much longer than S5R3.
I'm comparing Windows 4.36 on Intel (between 23 and 25.5 Ksec) with 6.04 - which should be a functionally equivalent Einstein app, but registered over 48 Ksec.
It strikes me that with the DCF re-adjustment, fast hosts will over-cache when they first latch on to S5R4, but will then go quiet as soon as they return their first task and find out what they've let themselves in for. But the initial loading is likely to be nice and consecutive, as this one was.
Anyone like me to try for a 'wiggle and swoop' run with one of my standard quaddies, like we did last time?
No quaddie here :-(, but that should be instructive.
As to CPU time per Workunit. the WUs seem to contain "more science" per unit. As I understand this, the stretch of time (a segment of the S5 LIGO science run) that is covered in S5R4 is longer than in S5R3, and basically every workunit looks at the complete stretch of time, but only for a small frequency window.
And yet, having just reported my first S5R4 result with host 889490, the real-world WU timing is much longer than S5R3.
I'm comparing Windows 4.36 on Intel (between 23 and 25.5 Ksec) with 6.04 - which should be a functionally equivalent Einstein app, but registered over 48 Ksec.
It strikes me that with the DCF re-adjustment, fast hosts will over-cache when they first latch on to S5R4, but will then go quiet as soon as they return their first task and find out what they've let themselves in for. But the initial loading is likely to be nice and consecutive, as this one was.
Anyone like me to try for a 'wiggle and swoop' run with one of my standard quaddies, like we did last time?
No quaddie here :-(, but that should be instructive.
As to CPU time per Workunit: the WUs seem to contain "more science" per unit. As I understand this, the stretch of observation time (a segment of the S5 LIGO science run) that is covered in S5R4 is longer than in S5R3, and basically every workunit looks at the complete stretch of time, but only for a small frequency window.
Hi! RE: PS : shell
)
Hi!
Hmm... there's something strange here... The output in stderr.txt is NOT consistent with a 4.24 Linux app., which was released in January 2008, yet the stderr.txt contains this line:
CU
Bikeman
RE: Hmm... there's
)
HeHe, well done ;)
The app was 4.35 according built date and running time.
Makes it all clearer now :D
Sorry for that !
I don't know how i messed-up with the file name (as according to the log i didn't mess-up with the shell command line).
The file on the server is really the 4.24:
http://einstein.phys.uwm.edu/download/einstein_S5R3_4.24_i686-pc-linux-gnu
In order to find other versions that ones on the EAH download repository, i looked a bit everywhere, including P2P networks... Maybe that's it.
Should have double checked the name according to the build date.
Thanks for the tip, will know from now.
The run time is now matching well.
Will update the plot later today.
Cheers,
A lame Alex.
God created a few good looking guys.. and for the rest he put hairs on top..
Ahh...I see. I guess when
)
Ahh...I see.
I guess when you prepare a new chart, Gary would be delighted to see one with a logarithmic runtime-axis, if possible :-)
CU
Bikeman
Hi, I feel like I'm still
)
Hi,
I feel like I'm still missing a little something.
- With 4.07, I had very constant results.
4 runs within the same 4-5 sec in high priority.
But i felt it was a bit too slow compare to 4.01 (even if its not surprising 4.07 being a bit slower than 4.01)
So i made another batch of runs. Again, very same results for each run.
But, not matching the first batch results ! Not by much, around 5%.
Still confusing anyway, as I changed nothing in the testing protocol, the app exe is the same...
- With 4.49_0 (the not SSE one).
The result was surprisingly fast from the beginning. Something felt wrong.
So again, I went for another run yesterday.
As for the windows 4.07, same file, same protocol (no background BOINC, high priority, no many stuffs in memory, leave the OS alone during test... )
And now the results feel a lot more right. Non-SSE is now a lot slower than 4.49 SSE or SSE2 as it should be.
Again, results from each test run are really close to each other from the same batch.
For all the other apps i re-ran yesterday, new results match well the previous ones.
So no really answers here, just open questions.
At least, now the results seem pretty consistent.
Datas:
Graph:
Graph with logarithmic runtime-axis:
Well, we'll see if others running ref WU, will have the same experience.
Sorry for the mislead on these 3 apps results (4.07, 4.24, 4.49_0) in my initial post.
Cheers,
Alex.
God created a few good looking guys.. and for the rest he put hairs on top..
For the curious: The
)
For the curious: The reference workunit should still work with S5R4 Apps.
BM
BM
RE: For the curious: The
)
Thx for the info Bernd !
Will try to run it ASAP, for the same ref computer, on Windows and Linux to add it to the previous logs.
Cheers,
Alex.
God created a few good looking guys.. and for the rest he put hairs on top..
So, as expected, no changes
)
So, as expected, no changes in crunch time with S5R4 apps:
Really slight variations only, if any.
Even if i ran the WU more than once for each app and "average", there is still little glitches in measurements. That should explain the slight variations you might see.
Maybe not for Linux 6.02 SSE one, witch appears to be 3% faster, a little more than the common error between to runs with a same app.
Maybe a slight change in compilers options, or something else... or nothing :D
BernD will probably tell you more on this if there's anything to say.
Cheers,
Alex.
God created a few good looking guys.. and for the rest he put hairs on top..
And yet, having just reported
)
And yet, having just reported my first S5R4 result with host 889490, the real-world WU timing is much longer than S5R3.
I'm comparing Windows 4.36 on Intel (between 23 and 25.5 Ksec) with 6.04 - which should be a functionally equivalent Einstein app, but registered over 48 Ksec.
It strikes me that with the DCF re-adjustment, fast hosts will over-cache when they first latch on to S5R4, but will then go quiet as soon as they return their first task and find out what they've let themselves in for. But the initial loading is likely to be nice and consecutive, as this one was.
Anyone like me to try for a 'wiggle and swoop' run with one of my standard quaddies, like we did last time?
RE: And yet, having just
)
No quaddie here :-(, but that should be instructive.
As to CPU time per Workunit. the WUs seem to contain "more science" per unit. As I understand this, the stretch of time (a segment of the S5 LIGO science run) that is covered in S5R4 is longer than in S5R3, and basically every workunit looks at the complete stretch of time, but only for a small frequency window.
CU
Bikeman
RE: And yet, having just
)
No quaddie here :-(, but that should be instructive.
As to CPU time per Workunit: the WUs seem to contain "more science" per unit. As I understand this, the stretch of observation time (a segment of the S5 LIGO science run) that is covered in S5R4 is longer than in S5R3, and basically every workunit looks at the complete stretch of time, but only for a small frequency window.
CU
Bikeman