maybe we can do a List in this Forum. New Applications will change results in the future, but why not to do. :) If anyone wants to copy and complement the list, here we are.
GPU
CPU
CPU GHz
OS
WU
Run Time
CPU Time
Run Time WU
Application
WX 5100 AMD
E5-2690v2
3,0
Ubuntu
2
1650
115
825
Gamma-ray pulsar binary search #1 on GPUs v1.18 () x86_64-pc-linux-gnu
Vega 56 Red Dragon, Silent BIOS
E5-2690v2
3,0
Ubuntu
2
640
110
320
Gamma-ray pulsar binary search #1 on GPUs v1.18 () x86_64-pc-linux-gnu
GTX 1080 EVGA SC
TR 1950X
3,9
Ubuntu
1
500
500
500
Gamma-ray pulsar binary search #1 on GPUs v1.20 () x86_64-pc-linux-gnu
Quadro M4000
E5-1680v4
3,5
Win 10
1
1300
1300
1300
Gamma-ray pulsar binary search #1 on GPUs v1.20 () windows_x86_64
maybe we can do a List in this Forum. New Applications will change results in the future, but why not to do. :)
By all means we could do a forum based list but for one question, who is going to verify claimed compute times etc. and compile all the information to produce an accurate and worthwhile GPU lookup chart?
I still wholeheartedly support Gary Roberts suggestion of a seperate Top Hosts list dedicated to single card machines. Although such a list may not be relevant when it comes to finding the best 'bang for buck' card because high end (expensive) cards will obviously dominate that list.
Perhaps the best way forward is to start a thread petitioning the project devs to query the database and target single card machines on a quarterly or bi-annually basis to produce a snap shot chart of relative GPU performance. I've no idea how they would accomplish this but to my mind it should be possible... Provided they can find the time!
Do the GPU tasks for Einstein require or benefit from FP64 hardware? I crunch Milkyway project which relies solely on FP64 performance so I have compiled a spreadsheet of GPU cards that feature high performance FP64. I'm not sure if that would be relevant to Einstein GPU tasks?
Do they require? - No. Do they benefit? - It depends.
Until recently, GPU calculations were done in 2 stages, taking approximately 90% and 10% of the time respectively. The 90% initial stage does not require DP. The latest data seems NOT to have a 'followup' stage, the only part where DP was used. There has been no comment from the Devs - they're busy with other matters. It's anybody's guess as to what future data sets might require.
For the previous data sets where there was definitely a followup stage, the time for that stage to complete on the GPU didn't seem to be at all sensitive to the 'level of FP64 capability' of any particular card. All that was required was 'some capability' which all relatively modern and not 'basic model' cards seemed to have. If a card had zero FP64 capability, the followup stage would be performed on a CPU core so there would be a time penalty in that case.
I find that standard sources of information about the specs of various models of cards (eg. google for the AMD and NVIDIA lists on wikipedia) give useful information about how a particular model might be expected to perform in comparison to some other model. I've based quite a few decisions about what might perform efficiently on that information and it seems to work pretty well. If you want to confirm if a particular card is as good as you think it might be, try to find a host with a single instance of that card and investigate the crunch times. It's fairly straight forward to work out if multiple tasks are being run concurrently and what that concurrency might be.
Because the 'top hosts' list is quite restricted these days, it's just about impossible to find a mid-range card directly. You might be able to find multi-GPU hosts where the 'identified' GPU is the model you're interested in but there is no guarantee that all GPUs are the same or even that the best performing GPU is the one identified. What I do is look for hosts with a single 'top of the range' card for a particular architecture. There's no problem finding some of those :-). I then compare the top model with the lower model on Wikipedia. I find that gives a reliable guide as to what to expect from the lower model.
So, ultimately, my guess is that a performance chart based on DP performance at Milkyway could be a bit misleading for what to expect at Einstein. By all means publish it if you wish but include a disclaimer pointing out that MW needs strong DP but EAH doesn't.
Until recently, GPU calculations were done in 2 stages, taking approximately 90% and 10% of the time respectively. The 90% initial stage does not require DP. The latest data seems NOT to have a 'followup' stage, the only part where DP was used. There has been no comment from the Devs - they're busy with other matters. It's anybody's guess as to what future data sets might require.
When and where was this change posted. I was not aware that the tasks stopped being processed on the cpu for the DP64 calculations at 90% completion?
Keith, I'm not sure what extra you want me to say. By 'change', I assume you are referring to the fact that current GPU tasks no longer 'pause' at ~90% for a couple of minutes whilst the 'follow-up' stage is being performed? If it's something else, could you please elaborate? As I said in the snip you posted, there has been nothing official posted about this that I'm aware of. I just mentioned that this change in behaviour seems to imply there is no follow-up stage. Of course, that is just an assumption. There could quite easily be other explanations.
Quote:
I was not aware that the tasks stopped being processed on the cpu for the DP64 calculations at 90% completion?
When Bernd first announced how this GPU search would operate, he mentioned that if a GPU didn't have any FP64 capability, the app would still run on the GPU up to the ~90% mark and then switch to the CPU (only if necessary) for the follow-up stage. Since the bulk of GPUs being used on this project probably have some DP capability, the need to switch to the CPU, for any part of the calculations, is probably quite rare. In the quote I'm responding to, did you mean GPU rather than 'cpu'? If you did, my response would be that (in most cases) tasks don't stop being processed on the GPU because most GPUs being used for crunching have the required FP64 capability.
Thanks for the reply. I remember reading that the explanation for the pause at 90% was because the tasks shifted from the gpu to the cpu. That is what I have always observed. I still do. I do not ever see the tasks continue through the 90% point. The percentage updates regularly till 90%, then stops updating while the elapsed timer continues. After a minute or so, the percentage jumps to 100% and the task uploads.
I don't ever see what you describe. I have gpus with fairly good DP64 capability. At 90%, I see the utilization on the gpu drop and I see a cpu core pick up in utilization.
Does what you describe only apply to the Windows application by chance?
I don't ever see what you describe. I have gpus with fairly good DP64 capability. At 90%, I see the utilization on the gpu drop and I see a cpu core pick up in utilization.
If you run GPU-Z and then click on the small circuit board up top to the left and in them menu choose "Settings", then on the tab "Sensors" you can change the sensor refresh rate to less than 1 second. On any graphics card with DP64 capability you should see short bursts of GPU load while the follow up stage is running. If no GPU load is detected even with a 0.1 second refresh rate then the task will probably be run on the CPU only, or it's a really powerful GPU.
Will have to wait a while before any Einstein work is run again. With the 26 hour outage at Seti last Tuesday, built up quite the project deficit so none of my MW, Einstein or GPUGrid tasks are running until I repay the Seti deficit.
I'll give that GPU-Z trick a try on my one Windows machine. Can't do the same for my other crunchers which run Linux.
Hi, maybe we can do a List
)
Hi,
maybe we can do a List in this Forum. New Applications will change results in the future, but why not to do. :) If anyone wants to copy and complement the list, here we are.
Lorio wrote:Hi, maybe we can
)
By all means we could do a forum based list but for one question, who is going to verify claimed compute times etc. and compile all the information to produce an accurate and worthwhile GPU lookup chart?
I still wholeheartedly support Gary Roberts suggestion of a seperate Top Hosts list dedicated to single card machines. Although such a list may not be relevant when it comes to finding the best 'bang for buck' card because high end (expensive) cards will obviously dominate that list.
Perhaps the best way forward is to start a thread petitioning the project devs to query the database and target single card machines on a quarterly or bi-annually basis to produce a snap shot chart of relative GPU performance. I've no idea how they would accomplish this but to my mind it should be possible... Provided they can find the time!
Gav.
Do the GPU tasks for Einstein
)
Do the GPU tasks for Einstein require or benefit from FP64 hardware? I crunch Milkyway project which relies solely on FP64 performance so I have compiled a spreadsheet of GPU cards that feature high performance FP64. I'm not sure if that would be relevant to Einstein GPU tasks?
Do they require? - No. Do
)
Do they require? - No. Do they benefit? - It depends.
Until recently, GPU calculations were done in 2 stages, taking approximately 90% and 10% of the time respectively. The 90% initial stage does not require DP. The latest data seems NOT to have a 'followup' stage, the only part where DP was used. There has been no comment from the Devs - they're busy with other matters. It's anybody's guess as to what future data sets might require.
For the previous data sets where there was definitely a followup stage, the time for that stage to complete on the GPU didn't seem to be at all sensitive to the 'level of FP64 capability' of any particular card. All that was required was 'some capability' which all relatively modern and not 'basic model' cards seemed to have. If a card had zero FP64 capability, the followup stage would be performed on a CPU core so there would be a time penalty in that case.
I find that standard sources of information about the specs of various models of cards (eg. google for the AMD and NVIDIA lists on wikipedia) give useful information about how a particular model might be expected to perform in comparison to some other model. I've based quite a few decisions about what might perform efficiently on that information and it seems to work pretty well. If you want to confirm if a particular card is as good as you think it might be, try to find a host with a single instance of that card and investigate the crunch times. It's fairly straight forward to work out if multiple tasks are being run concurrently and what that concurrency might be.
Because the 'top hosts' list is quite restricted these days, it's just about impossible to find a mid-range card directly. You might be able to find multi-GPU hosts where the 'identified' GPU is the model you're interested in but there is no guarantee that all GPUs are the same or even that the best performing GPU is the one identified. What I do is look for hosts with a single 'top of the range' card for a particular architecture. There's no problem finding some of those :-). I then compare the top model with the lower model on Wikipedia. I find that gives a reliable guide as to what to expect from the lower model.
So, ultimately, my guess is that a performance chart based on DP performance at Milkyway could be a bit misleading for what to expect at Einstein. By all means publish it if you wish but include a disclaimer pointing out that MW needs strong DP but EAH doesn't.
Cheers,
Gary.
There is a breakdown of cards
)
Interesting thread to watch.
Quote:Until recently, GPU
)
When and where was this change posted. I was not aware that the tasks stopped being processed on the cpu for the DP64 calculations at 90% completion?
Keith Myers wrote:When and
)
Keith, I'm not sure what extra you want me to say. By 'change', I assume you are referring to the fact that current GPU tasks no longer 'pause' at ~90% for a couple of minutes whilst the 'follow-up' stage is being performed? If it's something else, could you please elaborate? As I said in the snip you posted, there has been nothing official posted about this that I'm aware of. I just mentioned that this change in behaviour seems to imply there is no follow-up stage. Of course, that is just an assumption. There could quite easily be other explanations.
When Bernd first announced how this GPU search would operate, he mentioned that if a GPU didn't have any FP64 capability, the app would still run on the GPU up to the ~90% mark and then switch to the CPU (only if necessary) for the follow-up stage. Since the bulk of GPUs being used on this project probably have some DP capability, the need to switch to the CPU, for any part of the calculations, is probably quite rare. In the quote I'm responding to, did you mean GPU rather than 'cpu'? If you did, my response would be that (in most cases) tasks don't stop being processed on the GPU because most GPUs being used for crunching have the required FP64 capability.
Cheers,
Gary.
Thanks for the reply. I
)
Thanks for the reply. I remember reading that the explanation for the pause at 90% was because the tasks shifted from the gpu to the cpu. That is what I have always observed. I still do. I do not ever see the tasks continue through the 90% point. The percentage updates regularly till 90%, then stops updating while the elapsed timer continues. After a minute or so, the percentage jumps to 100% and the task uploads.
I don't ever see what you describe. I have gpus with fairly good DP64 capability. At 90%, I see the utilization on the gpu drop and I see a cpu core pick up in utilization.
Does what you describe only apply to the Windows application by chance?
Keith Myers skrev:I don't
)
If you run GPU-Z and then click on the small circuit board up top to the left and in them menu choose "Settings", then on the tab "Sensors" you can change the sensor refresh rate to less than 1 second. On any graphics card with DP64 capability you should see short bursts of GPU load while the follow up stage is running. If no GPU load is detected even with a 0.1 second refresh rate then the task will probably be run on the CPU only, or it's a really powerful GPU.
Will have to wait a while
)
Will have to wait a while before any Einstein work is run again. With the 26 hour outage at Seti last Tuesday, built up quite the project deficit so none of my MW, Einstein or GPUGrid tasks are running until I repay the Seti deficit.
I'll give that GPU-Z trick a try on my one Windows machine. Can't do the same for my other crunchers which run Linux.