So, did you have EAH_NO_GRAPHICS previously? If so, and you have BOINC set up as your screensaver, what about runtimes if the screensaver is disabled?
I do still have an EAH_NO_GRAPHICS file in my BOINC directory.
I don't use a BOINC-related screensaver.
I believe the EAH_NO_GRAPHICS file had no impact in my execution times.
OK... So far, my times are faster, but like I said, I have no idea where I was in the previous runtime variation and where I'm at for these results...
One curiosity is that every system that has been reported as seeming slower so far have been Pentium M / Core architecture. It would be helpful if there were reports of similar slowdowns on Pentium 4 and AMD...
So, did you have EAH_NO_GRAPHICS previously? If so, and you have BOINC set up as your screensaver, what about runtimes if the screensaver is disabled?
I do still have an EAH_NO_GRAPHICS file in my BOINC directory.
I don't use a BOINC-related screensaver.
I believe the EAH_NO_GRAPHICS file had no impact in my execution times.
OK... So far, my times are faster, but like I said, I have no idea where I was in the previous runtime variation and where I'm at for these results...
One curiosity is that every system that has been reported as seeming slower so far have been Pentium M / Core architecture. It would be helpful if there were reports of similar slowdowns on Pentium 4 and AMD...
Is it still believed that the "0" result out of the set is at the maximum runtime? From your graph, it appears that way. If so, I have h1_0712.40_S5R2__0_S5R3a as the next result in my queue after the one I'm currently working on, which is h1_0712.35_S5R2__31_S5R3a. If that 0 sequence number comes in at around or under what I had for h1_0712.35_S5R2__104_S5R3a_1 (45425.625), then that should be a good indicator...
One curiosity is that every system that has been reported as seeming slower so far have been Pentium M / Core architecture. It would be helpful if there were reports of similar slowdowns on Pentium 4 and AMD...
The 4.25 is 7% slower than 4.15 on K8 (Palermo).
It was checked with the same WU.
One curiosity is that every system that has been reported as seeming slower so far have been Pentium M / Core architecture. It would be helpful if there were reports of similar slowdowns on Pentium 4 and AMD...
The 4.25 is 7% slower than 4.15 on K8 (Palermo).
It was checked with the same WU.
OK, so why did you want this "fast" code to be in there? Does it actually end up producing more accuracy? If so, then perhaps that is a good tradeoff. If not, then I'd suggest removing it if it can't be optimized any better...
Edit: This is assuming that the current "slowdown" is attributable to the linear sin/cos code. Could I call it the tangent code then, as sin/cos=tan? (oh, the math humor!)...
The good news is that, after S5R2 and four months of S5R3 searching for bugs in the code, we are seeing now the first beta apps that are primary looking for faster code. And I'm sure we will see much faster apps soon...
I had already seen that posting, but he was talking about 4.24. 4.24 is the GNU/Linux application and I believe is compiled completely in GCC. To know if that is the same issue for the Windows app, the involvement of GCC in the compilation process needs to be known. There have been some statements that lead me to believe that the Windows app is a two-stage compilation, part in GCC and the other part in Microsoft Visual C++. If that's true, then the GCC portion would potentially still be contributing to the issue just like it is for the Linux 4.24 app. If 4.25 is compiled totally with MSVC++ and the same issue exists as does with the GCC compiled Linux application, then that would indicate that both compilers are not liking the implementation...
Quote:
The good news is that, after S5R2 and four months of S5R3 searching for bugs in the code, we are seeing now the first beta apps that are primary looking for faster code. And I'm sure we will see much faster apps soon...
This beta is not primarily searching for faster code. The main purpose of the beta is to break out the graphics from the main application to squash the "bug" with BOINC and/or the science application when it ran out of stack space within the OS while displaying graphics. If the graphics bomb, it should no longer take out the science application along with it...
RE: I think we can
)
Here's what I'm wondering... Bernd's notes say:
It has also been stated that EAH_NO_GRAPHICS has no effect now.
Both of those points infer that additional CPU load is encountered when the graphics are now being displayed.
So, did you have EAH_NO_GRAPHICS previously? If so, and you have BOINC set up as your screensaver, what about runtimes if the screensaver is disabled?
RE: So, did you have
)
I do still have an EAH_NO_GRAPHICS file in my BOINC directory.
I don't use a BOINC-related screensaver.
I believe the EAH_NO_GRAPHICS file had no impact in my execution times.
RE: RE: So, did you have
)
OK... So far, my times are faster, but like I said, I have no idea where I was in the previous runtime variation and where I'm at for these results...
One curiosity is that every system that has been reported as seeming slower so far have been Pentium M / Core architecture. It would be helpful if there were reports of similar slowdowns on Pentium 4 and AMD...
RE: RE: RE: So, did you
)
Is it still believed that the "0" result out of the set is at the maximum runtime? From your graph, it appears that way. If so, I have h1_0712.40_S5R2__0_S5R3a as the next result in my queue after the one I'm currently working on, which is h1_0712.35_S5R2__31_S5R3a. If that 0 sequence number comes in at around or under what I had for h1_0712.35_S5R2__104_S5R3a_1 (45425.625), then that should be a good indicator...
RE: One curiosity is that
)
The 4.25 is 7% slower than 4.15 on K8 (Palermo).
It was checked with the same WU.
RE: RE: One curiosity is
)
OK, so why did you want this "fast" code to be in there? Does it actually end up producing more accuracy? If so, then perhaps that is a good tradeoff. If not, then I'd suggest removing it if it can't be optimized any better...
Edit: This is assuming that the current "slowdown" is attributable to the linear sin/cos code. Could I call it the tangent code then, as sin/cos=tan? (oh, the math humor!)...
RE: OK, so why did you want
)
I did not know that how "fast" is this application.
But I'm sure the linear sin/cos is twice as fast as quadratic code.
RE: RE: OK, so why did
)
OK, so where's the slowdown coming from?
RE: OK, so why did you
)
Bernd has already explained the problem here
The good news is that, after S5R2 and four months of S5R3 searching for bugs in the code, we are seeing now the first beta apps that are primary looking for faster code. And I'm sure we will see much faster apps soon...
RE: RE: OK, so why did
)
I had already seen that posting, but he was talking about 4.24. 4.24 is the GNU/Linux application and I believe is compiled completely in GCC. To know if that is the same issue for the Windows app, the involvement of GCC in the compilation process needs to be known. There have been some statements that lead me to believe that the Windows app is a two-stage compilation, part in GCC and the other part in Microsoft Visual C++. If that's true, then the GCC portion would potentially still be contributing to the issue just like it is for the Linux 4.24 app. If 4.25 is compiled totally with MSVC++ and the same issue exists as does with the GCC compiled Linux application, then that would indicate that both compilers are not liking the implementation...
This beta is not primarily searching for faster code. The main purpose of the beta is to break out the graphics from the main application to squash the "bug" with BOINC and/or the science application when it ran out of stack space within the OS while displaying graphics. If the graphics bomb, it should no longer take out the science application along with it...