CPU time compared, Gravitational Wave S6 GC search v1.01 (SSE2)
versus Gamma-ray pulsar search #1 v0.23
Intel Core 2 Duo E8200, overclocked, running at 3 GHz.
My ratio is 1.54, based on 18 Gravitationals an 9 Gammas.
Nice speedup in last version!
My CPU time on LAT WUs drops from ~50.5k sec to ~31k sec (63% faster!).
Ratio between Fermi LAT and GW S6 now is 1.48:1
With new credit amount (337 vs 251) it give near parity in credit/hour(day).
There was a mention that the project were working on getting a cuda app going for these gamma-ray tasks, although I can't recall the exact message now. Is there any progress on that front?
Are there any more efforts being made to reduce the cross-validation problems? My poor mac has had dismal luck with, I think, six out of seven eventually being deemed invalid. Should I expect 10% invalids over the long term (just hang in there) or is my machine really producing something significantly different from the others? I can't help but wonder if it wouldn't be a better use of everyone's resources if I uncheck the gamma-ray search in my preferences. Any advice?
I wouldn't pin my hopes on waiting for a fix. There aren't enough Mac participants to warrant it.
I unchecked the box after having lost hundreds of hours of computer time. It's a disservice to yourself and the overall project goals to end up with validation errors.
All these issues are still on my todo list; I just didn't find the time to work on these in the past few weeks due to more urgent matters. I hope to get back to working on the FGRP app in the next few days.
At least I wrote a small tool that quantifies the cross-application validation rate, allowing me to measure success in that area. However I suspect the problem to be in some (barycentering) library about which I don't have much knowledge or control.
As for a GPU version: I won't have much time to spend on a CUDA version, but go directly for OpenCL instead. This will, however, require some support from the BOINC Client (and possibly server) side. We are actively developing this with the BOINC devs, but is also still work in progress and not finished yet.
However I suspect the problem to be in some (barycentering) library about which I don't have much knowledge or control.
Who maintains the library? I would assume that they don't want their library to produce different results on MacOS either :) Alternatively, if the library is old and no longer being maintained, how hard do you think the functionality would be to reproduce?
However I suspect the problem to be in some (barycentering) library about which I don't have much knowledge or control.
Who maintains the library? I would assume that they don't want their library to produce different results on MacOS either :) Alternatively, if the library is old and no longer being maintained, how hard do you think the functionality would be to reproduce?
The problem with that library is that it uses "long double", which is not a standard C datatype and is handled differently depending on compiler, compiler version, platform and options used.
All these issues are still on my todo list; I just didn't find the time to work on these in the past few weeks due to more urgent matters. I hope to get back to working on the FGRP app in the next few days.
At least I wrote a small tool that quantifies the cross-application validation rate, allowing me to measure success in that area. However I suspect the problem to be in some (barycentering) library about which I don't have much knowledge or control.
As for a GPU version: I won't have much time to spend on a CUDA version, but go directly for OpenCL instead. This will, however, require some support from the BOINC Client (and possibly server) side. We are actively developing this with the BOINC devs, but is also still work in progress and not finished yet.
BM
Thank you for the reply. I'll keep an eye on this thread for any further developments.
As for a GPU version: I won't have much time to spend on a CUDA version, but go directly for OpenCL instead. This will, however, require some support from the BOINC Client (and possibly server) side. We are actively developing this with the BOINC devs, but is also still work in progress and not finished yet.
BM
You might want to contact the POEM@HOME developers. They already have their application converted to OpenCL, but currently CPU only. They are also waiting for a BOINC version that can handle OpenCL GPU applications.
CPU time compared,
)
CPU time compared, Gravitational Wave S6 GC search v1.01 (SSE2)
versus Gamma-ray pulsar search #1 v0.23
Intel Core 2 Duo E8200, overclocked, running at 3 GHz.
My ratio is 1.54, based on 18 Gravitationals an 9 Gammas.
Nice speedup in last version!
)
Nice speedup in last version!
My CPU time on LAT WUs drops from ~50.5k sec to ~31k sec (63% faster!).
Ratio between Fermi LAT and GW S6 now is 1.48:1
With new credit amount (337 vs 251) it give near parity in credit/hour(day).
There was a mention that the
)
There was a mention that the project were working on getting a cuda app going for these gamma-ray tasks, although I can't recall the exact message now. Is there any progress on that front?
BOINC blog
Are there any more efforts
)
Are there any more efforts being made to reduce the cross-validation problems? My poor mac has had dismal luck with, I think, six out of seven eventually being deemed invalid. Should I expect 10% invalids over the long term (just hang in there) or is my machine really producing something significantly different from the others? I can't help but wonder if it wouldn't be a better use of everyone's resources if I uncheck the gamma-ray search in my preferences. Any advice?
Best,
Snags
I wouldn't pin my hopes on
)
I wouldn't pin my hopes on waiting for a fix. There aren't enough Mac participants to warrant it.
I unchecked the box after having lost hundreds of hours of computer time. It's a disservice to yourself and the overall project goals to end up with validation errors.
All these issues are still on
)
All these issues are still on my todo list; I just didn't find the time to work on these in the past few weeks due to more urgent matters. I hope to get back to working on the FGRP app in the next few days.
At least I wrote a small tool that quantifies the cross-application validation rate, allowing me to measure success in that area. However I suspect the problem to be in some (barycentering) library about which I don't have much knowledge or control.
As for a GPU version: I won't have much time to spend on a CUDA version, but go directly for OpenCL instead. This will, however, require some support from the BOINC Client (and possibly server) side. We are actively developing this with the BOINC devs, but is also still work in progress and not finished yet.
BM
BM
RE: However I suspect the
)
Who maintains the library? I would assume that they don't want their library to produce different results on MacOS either :) Alternatively, if the library is old and no longer being maintained, how hard do you think the functionality would be to reproduce?
RE: RE: However I suspect
)
The problem with that library is that it uses "long double", which is not a standard C datatype and is handled differently depending on compiler, compiler version, platform and options used.
BM
BM
RE: All these issues are
)
Thank you for the reply. I'll keep an eye on this thread for any further developments.
Best,
Snags
RE: As for a GPU version: I
)
You might want to contact the POEM@HOME developers. They already have their application converted to OpenCL, but currently CPU only. They are also waiting for a BOINC version that can handle OpenCL GPU applications.